Re: [PATCH 3/3] Intel IXP4xx network drivers

2007-05-08 Thread Lennert Buytenhek
On Mon, May 07, 2007 at 02:07:16AM +0200, Krzysztof Halasa wrote:

 + * Ethernet port config (0x00 is not present on IXP42X):
 + *
 + * logical port  0x000x100x20
 + * NPE   0 (NPE-A)   1 (NPE-B)   2 (NPE-C)
 + * physical PortId   2   0   1
 + * TX queue  23  24  25
 + * RX-free queue 26  27  28
 + * TX-done queue is always 31, RX queue is configurable

(Note that this assignment depends on the firmware, and different
firmware versions use different queues -- you might want to add a
note about which firmware version this holds for.)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] Intel IXP4xx network drivers

2007-05-08 Thread Lennert Buytenhek
On Mon, May 07, 2007 at 09:18:00PM +0100, Michael-Luke Jones wrote:

 Well, I'm told that (compatible) NPEs are present on other IXP CPUs.
 Not sure about details.
 
 If, by a combined effort, we ever manage to create a generic NPE  
 driver for the NPEs found in IXP42x/43x/46x/2000/23xx then the driver  
 should go in arch/arm/npe.c

(Note that the ixp2000 doesn't have NPEs.)

(Both the 2000 and the 23xx have microengines, which are both
supported by arch/arm/common/uengine.c.)


 It's possible, but hard due to the differences in hardware design

The ixp23xx NPEs seem pretty much identical to me to the ixp4xx
NPEs.  There are some minor differences between the ixp2000 and
ixp23xx uengines, but those are easy enough to deal with.


 and the fact that boards based on anything other than 42x are few
 and far between. The vast majority of 'independent' users following
 mainline are likely running on 42x boards.

Sure, ixp23xx hardware is harder to get.  I'm not sure what you mean
by 'independent' users, though.  Are people with non-42x hardware
'dependent' users, and why?


 Thus, for now, I would drop the NPE / QMGR code in arch/arm/mach- 
 ixp4xx/ and concentrate on making it 42x/43x/46x agnostic. One step  
 at a time :)

I'd say that it's up to those who are interested in ixp23xx support
(probably only myself at this point) to add ixp23xx support.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] Intel IXP4xx network drivers

2007-05-08 Thread Lennert Buytenhek
On Mon, May 07, 2007 at 10:00:20PM +0200, Krzysztof Halasa wrote:

  - the NPE can also be used as DMA engine and for crypto operations.
Both are not network related.
Additionally, the NPE is not only ixp4xx related, but is
also used in IXP23xx CPUs, so it could be placed in
arch/arm/common or arch/arm/xscale ?
 
  - The MAC is used on IXP23xx, too. So the drivers for
both CPU familys only differ in the way they exchange
network packets between the NPE and the kernel.
 
 Hmm... perhaps someone have a spare device with such IXP23xx
 and wants to make it a donation for science? :-)

I have a couple of ixp23xx boards at home, but I'm not sure whether I
can give them away.  I can give you remote access to them, though.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] Intel IXP4xx network drivers

2007-05-08 Thread Krzysztof Halasa
Lennert Buytenhek [EMAIL PROTECTED] writes:

 I have a couple of ixp23xx boards at home, but I'm not sure whether I
 can give them away.  I can give you remote access to them, though.

Hmm, may be interesting some day.
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] Intel IXP4xx network drivers

2007-05-07 Thread Michael-Luke Jones

On 7 May 2007, at 01:07, Krzysztof Halasa wrote:


Adds IXP4xx drivers for built-in CPU components:
- hardware queue manager
- NPE (network coprocessors),
- Ethernet ports,
- HSS (sync serial) ports (currently only non-channelized HDLC).

Both Ethernet and HSS drivers use queue manager and NPE driver and
require external firmware file(s) available from www.intel.com.

Platform device definitions for Ethernet ports on IXDP425  
development

platform are provided (though it has been tested on not yet available
IXP425-based hardware only)

Signed-off-by: Krzysztof Halasa [EMAIL PROTECTED]


Immediate comments as follows:

(Krzysztof has already seen them in a private email but I'm putting  
them out so people can publically disagree with me if I have got this  
wrong.)


Code placement:
Queue Manager  NPE code = arch/arm/mach-ixp4xx
WAN driver code = drivers/net/wan
Eth code = drivers/net/arm

Kconfig:
I'm not convinced about 'config IXP4XX_NETDEVICES'. I'd lose it  
together with the drivers/net/ixp4xx directory
Ethernet  HSS code should probably select NPE and QMGR (rather than  
depend) but these options should still be exposed in arch/arm/mach- 
ixp4xx/Kconfig


Michael-Luke Jones

PS: Please cc me on replies as I only subscribe to l-a-k.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] Intel IXP4xx network drivers

2007-05-07 Thread Krzysztof Halasa
Michael-Luke Jones [EMAIL PROTECTED] writes:

 Code placement:
 Queue Manager  NPE code = arch/arm/mach-ixp4xx
 WAN driver code = drivers/net/wan
 Eth code = drivers/net/arm

Why would you want such placement?
Potential problems: header files would have to be moved to
include/asm-arm = headers pollution.
All 4 drivers are, in fact, network (related) drivers.

drivers/net/arm would probably make (some) sense if it was
a single (or not so single) Ethernet driver.

 Kconfig:
 I'm not convinced about 'config IXP4XX_NETDEVICES'. I'd lose it
 together with the drivers/net/ixp4xx directory

It wouldn't make sense without the directory, no doubt.

 Ethernet  HSS code should probably select NPE and QMGR (rather than
 depend)

Actually, that's exactly what this patch do.

 but these options should still be exposed in arch/arm/mach-
 ixp4xx/Kconfig

Why exactly? They are network devices, who would expect them there?
How about the dependency mess (NET_ETHERNET etc.) that would be
created?
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] Intel IXP4xx network drivers

2007-05-07 Thread Christian Hohnstaedt
On Mon, May 07, 2007 at 07:12:49PM +0200, Krzysztof Halasa wrote:
 Michael-Luke Jones [EMAIL PROTECTED] writes:
 
  Code placement:
  Queue Manager  NPE code = arch/arm/mach-ixp4xx
  WAN driver code = drivers/net/wan
  Eth code = drivers/net/arm
 
 Why would you want such placement?
 Potential problems: header files would have to be moved to
 include/asm-arm = headers pollution.
 All 4 drivers are, in fact, network (related) drivers.
No.

- qmgr is a versatile hardware fifo stack, that is currently
  used to exchange data with the NPE.

- the NPE can also be used as DMA engine and for crypto operations.
  Both are not network related.
  Additionally, the NPE is not only ixp4xx related, but is
  also used in IXP23xx CPUs, so it could be placed in
  arch/arm/common or arch/arm/xscale ?

- The MAC is used on IXP23xx, too. So the drivers for
  both CPU familys only differ in the way they exchange
  network packets between the NPE and the kernel.
  
 
 drivers/net/arm would probably make (some) sense if it was
 a single (or not so single) Ethernet driver.
If Queue Manager  NPE move to arch/ , it can be a single file.

Christian Hohnstaedt

-- 
Christian Hohnstaedt
Software Engineer

Innominate Security Technologies AG  /protecting industrial networks/
tel: +49.30.6392-3285 fax: +49.30.6392-3307
Albert-Einstein-Strasse 14, D-12489 Berlin, Germany
http://www.innominate.com

Register Court: AG Charlottenburg, HR B 81603
Management Board: Joachim Fietz, Dirk Seewald
Chairman of the Supervisory Board: Edward M. Stadum
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] Intel IXP4xx network drivers

2007-05-07 Thread Michael-Luke Jones

[Added Lennert Buytenhek to CC list]

Hey again,


Code placement:
Queue Manager  NPE code = arch/arm/mach-ixp4xx
WAN driver code = drivers/net/wan
Eth code = drivers/net/arm


Why would you want such placement?
Potential problems: header files would have to be moved to
include/asm-arm = headers pollution.


Headers for ixp4xx-specific hardware can surely live in the include/ 
asm-arm/arch-ixp4xx/ quite happily.



All 4 drivers are, in fact, network (related) drivers.


Despite their name, Network Processing Engines are independent  
coprocessors which are only coincidentally attached to MACs for  
ethernet / WAN purposes. If Intel would allow us to compile code for  
these coprocessors, we could get them to do lots of things other than  
networking.


In fact, we already kind of can. Crypto is not networking, and if the  
kernel gains ixp4xx crypto support, that should be possible to enable  
independently of networking. They can also function as DMA engines,  
which should also be independent of networking functionality.


So, the NPE driver (which is basically ixp4xx specific) should be,  
for practical purposes, networking-code agnostic. As it is a lump of  
code talking to an architecture specific piece of hardware, it should  
live in arch/arm/ rather than arch-independent drivers/


(NB: the publically reviewed version of Christian's ixp4xx_net driver  
had exactly this file layout, see below)



Ethernet  HSS code should probably select NPE and QMGR (rather than
depend)


Actually, that's exactly what this patch do.


but these options should still be exposed in arch/arm/mach-
ixp4xx/Kconfig


Sorry, unclear. That sentence was meant as a coherent whole -  
agreeing with you that the NPE dependency should use select but then  
pointing out that you should still be able to turn NPE support on in  
arch/arm/mach/ixp4xx/Kconfig even without selecting any of the  
network drivers.



Why exactly? They are network devices, who would expect them there?
How about the dependency mess (NET_ETHERNET etc.) that would be
created?


For networking devices point, see above.

I don't fully understand the specifics, but Christian appeared to  
avoid any dependency mess in the publically reviewed version of his  
driver (as below).


As I understand it, functions to talk to the NPE should appear in the  
NPE driver. The NPE driver should then be called by ethernet/wan/ 
crypto/dma(?) drivers to carry out the specific firmware-dependent  
tasks. I haven't reviewed your code in detail, so I can't comment on  
whether this is what you actually do or not.


==Links to the review of Christian's driver==
[1/7] Register  NPE definitions:
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 
038082.html

[2/7] Platform devices (thought unnecessary by Lennert in his review):
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 
038086.html

[3/7] Stub for Data/Address-Coherent mode setup:
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 
038083.html

[4/7] QMGR driver:
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 
038278.html

[5/7] NPE driver:
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 
038085.html

[6/7] Ethernet driver:
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 
038087.html

[7/7] Documentation:
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 
038088.html


Sorry if I'm stating the obvious, but this is a public discussion and  
I want to make sure everyone who reads this can see what I mean. If  
they disagree with me despite this, so be it :)


Mike-Luke

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] Intel IXP4xx network drivers

2007-05-07 Thread Krzysztof Halasa
Having thought about it a bit more, a layout similar to the one
proposed by you may make sense.

Michael-Luke Jones [EMAIL PROTECTED] writes:

 Despite their name, Network Processing Engines are independent
 coprocessors which are only coincidentally attached to MACs for
 ethernet / WAN purposes. If Intel would allow us to compile code for
 these coprocessors, we could get them to do lots of things other than
 networking.

Not sure about that. Intel doesn't say much about it, but I think
one can safely assume that while NPEs can probably be programmed
to do other things, their performance comes not from NPE firmware
but from specialized network coprocessors (not NPEs) which can only
do (in hardware) things like Ethernet, HDLC, bit sync, CRC16/32,
and MD5/SHA-1/DES/AES.

I think you can even use MD5 and SHA-1 without any firmware (but
would have to check this info).

Note that while certain CPUs have the same set of NPEs, they are
missing some network coprocessors and can't do, for example, crypto.

OTOH, yes, they are not, strictly speaking, only network processors.

 Crypto is not networking, and if the
 kernel gains ixp4xx crypto support, that should be possible to enable
 independently of networking.

Yep. Unfortunately I don't know in-kernel crypto code.

 They can also function as DMA engines,
 which should also be independent of networking functionality.

That's what the docs say. Not sure about real-life purpose of
such DMA engine, though.

 So, the NPE driver (which is basically ixp4xx specific) should be,
 for practical purposes, networking-code agnostic. As it is a lump of
 code talking to an architecture specific piece of hardware, it should
 live in arch/arm/ rather than arch-independent drivers/

Well, I'm told that (compatible) NPEs are present on other IXP CPUs.
Not sure about details.

 As I understand it, functions to talk to the NPE should appear in the
 NPE driver. The NPE driver should then be called by ethernet/wan/
 crypto/dma(?) drivers to carry out the specific firmware-dependent
 tasks.

Actually, the NPE code does two things:
a) initialized NPEs and downloades the firmware
b) exchanges control messages with NPEs.
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] Intel IXP4xx network drivers

2007-05-07 Thread Krzysztof Halasa
Christian Hohnstaedt [EMAIL PROTECTED] writes:

 - the NPE can also be used as DMA engine and for crypto operations.
   Both are not network related.
   Additionally, the NPE is not only ixp4xx related, but is
   also used in IXP23xx CPUs, so it could be placed in
   arch/arm/common or arch/arm/xscale ?

 - The MAC is used on IXP23xx, too. So the drivers for
   both CPU familys only differ in the way they exchange
   network packets between the NPE and the kernel.

Hmm... perhaps someone have a spare device with such IXP23xx
and wants to make it a donation for science? :-)
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html