Lennert Buytenhek <buytenh@wantstofly.org> writes:

quoted text
> The board support code knows such things as that the "front ethernet
> port" on the board is connected to the CPU's MII port number #2, but
> the board support code does _not_ know that MII port number #2
> corresponds to "ixp4xx hardware queue #5."

Sure. And I don't want it to know.

It has to pick up any available queue for RX, that is. If the
board code knows it uses ETH connected to NPE-B and NPE-C, and
HSS-0 connected (obviously) to NPE-A, and it wants some crypto
functions etc., it can pick a queue which normally belongs to
HSS-1. If the code knows the board has both HSS and only NPE-B
Ethernet, it can use one of NPE-C Ethernet's queues. It's that
simple.

The Ethernet (and HSS etc.) driver knows it has to use queue 24 for
NPE-B Ethernet's TX and 27 for TX and so on, this is fixed in the
firmware so I don't let the board code mess with that. The
Ethernet RX queue is different, we can just make something up and
tell NPE about that.

That's BTW the same thing you would want to do with SRAM - except
that the SRAM allocator is technically possible, while making
queue assignments needs knowledge about the hardware.

quoted text
> If Intel puts out a firmware update next month, and your ethernet
> driver is modified to take advantage of the new features in that
> firmware and starts depending on the newer version of that firmware,
> we will have to modify every ixp4xx board support file in case the
> firmware update modifies the ixp4xx queue numbers in use.

Nope, we just modify Ethernet driver:
drivers/net/arm/ixp4xx_eth.c:
#define TX_QUEUE(plat)          (NPE_ID(port) + 23)
#define RXFREE_QUEUE(plat)      (NPE_ID(port) + 26)
#define TXDONE_QUEUE            31

quoted text
> The
> mapping from hardware ports (MII port #0, MII port #6, HSS port
> #42, whatever) to ixp4xx hardware queue numbers (0-63) should _not_
> be put in every single ixp4xx board support file.

I've never considered doing that :-)

drivers/net/wan/ixp4xx_hss.c:
/* Queue IDs */
#define HSS0_CHL_RXTRIG_QUEUE   12      /* orig size = 32 dwords */
#define HSS0_PKT_RX_QUEUE       13      /* orig size = 32 dwords */
#define HSS0_PKT_TX0_QUEUE      14      /* orig size = 16 dwords */
#define HSS0_PKT_TX1_QUEUE      15
#define HSS0_PKT_TX2_QUEUE      16
#define HSS0_PKT_TX3_QUEUE      17
#define HSS0_PKT_RXFREE0_QUEUE  18      /* orig size = 16 dwords */
#define HSS0_PKT_RXFREE1_QUEUE  19
#define HSS0_PKT_RXFREE2_QUEUE  20
#define HSS0_PKT_RXFREE3_QUEUE  21
#define HSS0_PKT_TXDONE_QUEUE   22      /* orig size = 64 dwords */

#define HSS1_CHL_RXTRIG_QUEUE   10
#define HSS1_PKT_RX_QUEUE       0
#define HSS1_PKT_TX0_QUEUE      5
#define HSS1_PKT_TX1_QUEUE      6
#define HSS1_PKT_TX2_QUEUE      7
#define HSS1_PKT_TX3_QUEUE      8
#define HSS1_PKT_RXFREE0_QUEUE  1
#define HSS1_PKT_RXFREE1_QUEUE  2
#define HSS1_PKT_RXFREE2_QUEUE  3
#define HSS1_PKT_RXFREE3_QUEUE  4
#define HSS1_PKT_TXDONE_QUEUE   9

quoted text
>> Without them the code in question is hardly readable,
>
> You can read Polish, how can you complain about code readability. :-))

Well, you may have the point, but I also care about others :-)
-- 
Krzysztof Halasa
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/