| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <507D0109.1010103@snapgear.com>
Date: Tue, 16 Oct 2012 16:39:05 +1000
From: Greg Ungerer <gerg@...pgear.com>
To: Philippe De Muyter <phdm@...qel.be>
CC: uClinux development list <uclinux-dev@...inux.org>,
<stany.marcel@...asys-ingenierie.com>,
<linux-kernel@...r.kernel.org>, <linuxppc-dev@...ts.ozlabs.org>,
<netdev@...r.kernel.org>, <linux-m68k@...ts.linux-m68k.org>
Subject: Re: [m68k,powerpc,dma,ethernet,freescale RFA] Coldfire m54xx FEC
ethernet driver
Hi Philippe,
On 09/10/12 19:07, Philippe De Muyter wrote:
> [CCing lkml, linux-ppc, netdev, linux-m68k]
>
> Hello kernel sources architects
>
> I have a working driver for the m54xx FEC ethernet driver that I
> would like to integrate in the kernel tree. Problems are that
> - this driver needs an associated DMA driver (provided by FreeScale)
> wich is not dma-engine enabled
> - they're are already many fec drivers in the kernel tree, and
> at least one, fec_mpc52xx.c, seems to be very similar (information
> below), to the one for the mcf54xx, except it uses a differently
> named associated DMA driver (BestComm/SmartDma/SDMA) which is also
> not dma-engine enabled, and even kept hidden in /arch/powerpc where
> it is inaccessible when compiling for m68k. The underlying DMA part
> from Freescale however seems similar to the one used in the
> m54xx. (again, see information below)
>
> So, now I am lost, what should I do ?
>
> The current state of my patches
> [http://mailman.uclinux.org/pipermail/uclinux-dev/2012-September/052147.html]
> is pushing the freescale provided MCD_DMA dma driver to /drivers/dma,
> without adding the dma-engine compatibility layer, and adding the specific
> fec_m54xx ethernet driver to /drivers/net/ethernet/freescale
Do you get any responses?
I didn't see any...
Regards
Greg
> On Tue, Oct 09, 2012 at 04:12:44PM +1000, Greg Ungerer wrote:
>> Hi Philippe,
>>
>> On 05/10/12 01:03, Philippe De Muyter wrote:
>>> On Thu, Oct 04, 2012 at 04:56:01PM +0200, Philippe De Muyter wrote:
>>>> On Thu, Oct 04, 2012 at 11:33:32PM +1000, Greg Ungerer wrote:
>>>>>
>>>>> My biggest concern is the amount of MCD/DMA support code. And it is
>>>>> all done quite differently to everything else in the kernel. We may
>>>>> get a bit of push back from kernel folk who look after DMA.
>>>>
>>>> Actually, there is already a similar code in arch/powerpc/sysdev/bestcomm
>>>> (also from freescale, maybe an identical part, but I did not find any
>>>> usable doc), but the powerpc folks kept that hidden in the arch/powerpc
>>>> tree, instead of installing it in drivers/dma.
>>>
>>> The MCD DMA or DMA FEC code from freescale has a comment implying that
>>> this
>>> was first used in the MPC8220 part. And Montavista has a MPC8220 port,
>>> but
>>> I did not find it, so I do not know where they installed the MCD DMA
>>> driver.
>>
>> Ok, looks like there is a bit a variance in all this.
>
> I also began to read the mpc5200 user's guide parts about the fec and
> BestComm/SmartDma/SDMA (not sure which one is the official FreeScale name)
> and they look very similar, but not identical, to their m54xx counterparts.
>
> It seems possible to make the fec_mpc52xx.c driver work for the m54xx
> but that needs at least:
> - moving some files or part of them from /arch/powerpc/sysdev and
> /arch/powerpc/include/asm to /drivers/dma and /include/linux,
> - renaming the fec_mpc52xx files to a more sensible name,
> - providing out_be32 and in_be32 in /arch/m68k/include/asm/io.h,
> - and then unifying the interface to BestComm/SmartDma/SDMA and MCD_DMA
> in mcf_52xx.c.
>
> An additional problem is that the freescale docs for powerpcs and for
> coldfires do not use the same mnemonics for the same registers.
>
> e.g. FEC registers
> offset MPC5200 MCF5484
> ====== ======= =======
> 000 FEC_ID n/a
> 004 IEVENT EIR
> 008 IMASK EIMR
> 010 R_DES_ACTIVE n/a
> 014 X_DES_ACTIVE n/a
> 024 ECNTRL ECR
> 040 MII_DATA MDATA
> 044 MII_SPEED MSCR
> 064 MIB_CONTROL MIBC
> 084 R_CNTRL RCR
> 088 R_HASH RHR
> 0C4 X_CNTRL TCR
> 0E4 PADDR1 PALR
> 0E8 PADDR2 PAHR
> 0EC OP_PAUSE OPD
> 118 IADDR1 IAUR
> 11C IADDR1 IALR
> 120 GADDR1 GAUR
> 124 GADDR2 GALR
> 144 X_WMRK FECTFWR
> 184 RFIFO_DATA FECRFDR
> 188 RFIFO_STATUS FECRFSR
> 18C RFIFO_CONTROL FECRFCR
> 190 RFIFO_LRF_PTR FECRLRFP
> 194 RFIFO_LWF_PTR FECRLWFP
> 198 RFIFO_ALARM FECRFAR
> 19C RFIFO_RDPTR FECRFRP
> 1A0 RFIFO_WRPTR FECRFWP
> 1A4 TFIFO_DATA FECTFDR
> 1A8 TFIFO_STATUS FECTFSR
> 1AC TFIFO_CONTROL FECTFCR
> 1B0 TFIFO_LRF_PTR FECTLRFP
> 1B4 TFIFO_LWF_PTR FECTLWFP
> 1B8 TFIFO_ALARM FECTFAR
> 1BC TFIFO_RDPTR FECTFRP
> 1C0 TFIFO_WRPTR FECTFWP
> 1C4 RESET_CNTRL FECFRST
> 1C8 XMIT_FSM FECCTCWR
>
>> Probably the best thing to do is post the patches on the linux kernel
>> mailing list then, asking for direction on a dma driver.
>>
>> I have no problem with it going into the arch/m68k area. So that is
>> always an option.
>
> For the dma engines, the similarity is also obvious. For example, find
> below side by side mpc52xx and m54xx definitions for the
> main DMA registers :
>
> from mpc52xx.h from MCD_dma.h
> /* SDMA */ /* MCD_DMA */
> struct mpc52xx_sdma { struct dmaRegs {
> u32 taskBar; /* 0x00 */ u32 taskbar;
> u32 currentPointer; /* 0x04 */ u32 currPtr;
> u32 endPointer; /* 0x08 */ u32 endPtr;
> u32 variablePointer; /* 0x0c */ u32 varTablePtr;
>
> u8 IntVect1; /* 0x10 */ u16 dma_rsvd0;
> u8 IntVect2; /* 0x11 */
> u16 PtdCntrl; /* 0x12 */ u16 ptdControl;
>
> u32 IntPend; /* 0x14 */ u32 intPending;
> u32 IntMask; /* 0x18 */ u32 intMask;
>
> u16 tcr[16]; /* 0x1c .. 0x3a */ u16 taskControl[16];
>
> u8 ipr[32]; /* 0x3c .. 0x5b */ u8 priority[32];
>
> u32 cReqSelect; /* 0x5c */ u32 initiatorMux;
> u32 task_size0; /* 0x60 */ u32 taskSize0;
> u32 task_size1; /* 0x64 */ u32 taskSize1;
> u32 MDEDebug; /* 0x68 */ u32 dma_rsvd1;
> u32 ADSDebug; /* 0x6c */ u32 dma_rsvd2;
> u32 Value1; /* 0x70 */ u32 debugComp1;
> u32 Value2; /* 0x74 */ u32 debugComp2;
> u32 Control; /* 0x78 */ u32 debugControl;
> u32 Status; /* 0x7c */ u32 debugStatus;
> u32 PTDDebug; /* 0x80 */ u32 ptdDebug;
> }; };
>
>
>
>
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@...pgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists