Skip to contentSkip to conversation

net: asix: don't pad odd-length TX packets

PATCH In review Stephen Warren 6 participants 8 messages Feb 27, 2014 – Mar 10, 2014 USB

lore
Share & tools
lore

Stephen Warren

author
#0 lore raw

PATCH 1/1 net: asix: don't pad odd-length TX packets

From: Stephen Warren <[email protected]>

For Ethernet/USB RX packets, the ASIX HW pads odd-sized packets so that they have an even size. Currently, asix_recv() does remove this padding, and asic_send() adds equivalent padding in the TX path. However, the HW does not appear to need this packing for TX packets in practical testing with "ASIX Elec. Corp. AX88x72A 000001" Vendor: 0x0b95 Product 0x7720 Version 0.1. The Linux kernel does no such padding for the TX path.

Remove the padding from the TX path:

* For consistency with the Linux kernel.
* NVIDIA has a Tegra simulator which validates that the length of USB packets sent to an ASIX device matches the packet length value inside the packet data. Having U-Boot and the kernel do the same thing when creating the TX packets simplifies the simulator's validation.

Cc Lucas Stach <[email protected]>
Cc Marek Vasut <[email protected]>
Cc Simon Glass <[email protected]>
Signed-off-by Stephen Warren <[email protected]>
---
 drivers/usb/eth/asix.c | 2 --
 1 file changed, 2 deletions(-)
drivers/usb/eth/asix.c +0 -2
index 659533a8d4e4..ce133f00698d 100644
@@ -468,8 +468,6 @@ static int asix_send(struct eth_device *eth, void *packet, int length)
 
 	memcpy(msg, &packet_len, sizeof(packet_len));
 	memcpy(msg + sizeof(packet_len), (void *)packet, length);
-	if (length & 1)
-		length++;
 
 	err = usb_bulk_msg(dev->pusb_dev,
 				usb_sndbulkpipe(dev->pusb_dev, dev->ep_out),
Signature · 1 line
1.8.1.5
#1 lore raw

PATCH 1/1 net: asix: don't pad odd-length TX packets

Hi Stephen,

Quoted 17 lines · Stephen Warren

From: Stephen Warren <[email protected]>

For Ethernet/USB RX packets, the ASIX HW pads odd-sized packets so that they have an even size. Currently, asix_recv() does remove this padding, and asic_send() adds equivalent padding in the TX path. However, the HW does not appear to need this packing for TX packets in practical testing with "ASIX Elec. Corp. AX88x72A 000001" Vendor: 0x0b95 Product 0x7720 Version 0.1. The Linux kernel does no such padding for the TX path.

Remove the padding from the TX path:

* For consistency with the Linux kernel.
* NVIDIA has a Tegra simulator which validates that the length of USB packets sent to an ASIX device matches the packet length value inside the packet data. Having U-Boot and the kernel do the same thing when creating the TX packets simplifies the simulator's validation.

Quoted 5 lines
Cc Lucas Stach <[email protected]>
Cc Marek Vasut <[email protected]>
Cc Simon Glass <[email protected]>
Signed-off-by Stephen Warren <[email protected]>

My notes indicate I added this due to a problem I had at the time with bootp. However, since you have tested it, perhaps the root cause was somewhere else.

Acked-by Simon Glass <[email protected]>
Quoted 23 lines
---
 drivers/usb/eth/asix.c | 2 --
 1 file changed, 2 deletions(-)
drivers/usb/eth/asix.c +0 -2
index 659533a8d4e4..ce133f00698d 100644
@@ -468,8 +468,6 @@ static int asix_send(struct eth_device *eth, void
 *packet, int length)
 
        memcpy(msg, &packet_len, sizeof(packet_len));
        memcpy(msg + sizeof(packet_len), (void *)packet, length);
-       if (length & 1)
-               length++;
 
        err = usb_bulk_msg(dev->pusb_dev,

                                usb_sndbulkpipe(dev->pusb_dev,

dev->ep_out),
--
1.8.1.5

#2 lore raw

PATCH 1/1 net: asix: don't pad odd-length TX packets

Quoted 26 lines · Simon Glass

Hi Stephen,

Quoted 14 lines · Stephen Warren

From: Stephen Warren <[email protected]>

For Ethernet/USB RX packets, the ASIX HW pads odd-sized packets so that they have an even size. Currently, asix_recv() does remove this padding, and asic_send() adds equivalent padding in the TX path. However, the HW does not appear to need this packing for TX packets in practical testing with "ASIX Elec. Corp. AX88x72A 000001" Vendor: 0x0b95 Product 0x7720 Version 0.1. The Linux kernel does no such padding for the TX path.

Remove the padding from the TX path:

* For consistency with the Linux kernel.
* NVIDIA has a Tegra simulator which validates that the length of USB

Quoted 8 lines

packets sent to an ASIX device matches the packet length value inside the packet data. Having U-Boot and the kernel do the same thing when creating the TX packets simplifies the simulator's validation.

Cc Lucas Stach <[email protected]>
Cc Marek Vasut <[email protected]>
Cc Simon Glass <[email protected]>
Signed-off-by Stephen Warren <[email protected]>
Quoted 5 lines

My notes indicate I added this due to a problem I had at the time with bootp. However, since you have tested it, perhaps the root cause was somewhere else.

Acked-by Simon Glass <[email protected]>

Tested on two different ASIX dongles:

0x2001:0x3c05 ; DUB-E100 ; D-Link Corporation
0x0b95:0x7720 ; ZoWii ; Zoltan Tech

Acked-by Marek Vasut <[email protected]>
Tested-by Marek Vasut <[email protected]>

Best regards,
Marek Vasut

#3 lore raw

PATCH 1/1 net: asix: don't pad odd-length TX packets

Quoted 34 lines · Marek Vasut
Quoted 26 lines · Simon Glass

Hi Stephen,

Quoted 14 lines · Stephen Warren

From: Stephen Warren <[email protected]>

For Ethernet/USB RX packets, the ASIX HW pads odd-sized packets so that they have an even size. Currently, asix_recv() does remove this padding, and asic_send() adds equivalent padding in the TX path. However, the HW does not appear to need this packing for TX packets in practical testing with "ASIX Elec. Corp. AX88x72A 000001" Vendor: 0x0b95 Product 0x7720 Version 0.1. The Linux kernel does no such padding for the TX path.

Remove the padding from the TX path:

* For consistency with the Linux kernel.
* NVIDIA has a Tegra simulator which validates that the length of USB

Quoted 8 lines

packets sent to an ASIX device matches the packet length value inside the packet data. Having U-Boot and the kernel do the same thing when creating the TX packets simplifies the simulator's validation.

Cc Lucas Stach <[email protected]>
Cc Marek Vasut <[email protected]>
Cc Simon Glass <[email protected]>
Signed-off-by Stephen Warren <[email protected]>
Quoted 5 lines

My notes indicate I added this due to a problem I had at the time with bootp. However, since you have tested it, perhaps the root cause was somewhere else.

Acked-by Simon Glass <[email protected]>
Quoted 7 lines

Tested on two different ASIX dongles:

0x2001:0x3c05 ; DUB-E100 ; D-Link Corporation
0x0b95:0x7720 ; ZoWii ; Zoltan Tech

Acked-by Marek Vasut <[email protected]>
Tested-by Marek Vasut <[email protected]>

Tested with TFTP over a "Logilink UA0144" dongle ('usb info' says "ASIX Elec. Corp. AX88772B 000001", vendor 0x0b95, prod 0x772b) and "Edimax EU-4208" ("ASIX Elec. Corp. AX88772B 0E62D5", 0x0b95, 0x772b).

Tested-by Gerhard Sittig <[email protected]>

virtually yours
Gerhard Sittig

Signature · 3 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
#4 lore raw

PATCH 1/1 net: asix: don't pad odd-length TX packets

Quoted 44 lines · Gerhard Sittig
Quoted 35 lines · Marek Vasut
Quoted 28 lines · Simon Glass

Hi Stephen,

Quoted 20 lines · Stephen Warren

From: Stephen Warren <[email protected]>

For Ethernet/USB RX packets, the ASIX HW pads odd-sized packets so that they have an even size. Currently, asix_recv() does remove this padding, and asic_send() adds equivalent padding in the TX path. However, the HW does not appear to need this packing for TX packets in practical testing with "ASIX Elec. Corp. AX88x72A 000001" Vendor:
0x0b95 Product 0x7720 Version 0.1. The Linux kernel does no such padding for the TX path.

Remove the padding from the TX path:

* For consistency with the Linux kernel.
* NVIDIA has a Tegra simulator which validates that the length of USB

packets sent to an ASIX device matches the packet length value inside the packet data. Having U-Boot and the kernel do the same thing when creating the TX packets simplifies the simulator's validation.

Quoted 4 lines
Cc Lucas Stach <[email protected]>
Cc Marek Vasut <[email protected]>
Cc Simon Glass <[email protected]>
Signed-off-by Stephen Warren <[email protected]>
Quoted 5 lines

My notes indicate I added this due to a problem I had at the time with bootp. However, since you have tested it, perhaps the root cause was somewhere else.

Acked-by Simon Glass <[email protected]>
Quoted 7 lines

Tested on two different ASIX dongles:

0x2001:0x3c05 ; DUB-E100 ; D-Link Corporation
0x0b95:0x7720 ; ZoWii ; Zoltan Tech

Acked-by Marek Vasut <[email protected]>
Tested-by Marek Vasut <[email protected]>
Quoted 6 lines

Tested with TFTP over a "Logilink UA0144" dongle ('usb info' says "ASIX Elec. Corp. AX88772B 000001", vendor 0x0b95, prod 0x772b) and "Edimax EU-4208" ("ASIX Elec. Corp. AX88772B 0E62D5", 0x0b95, 0x772b).

Tested-by Gerhard Sittig <[email protected]>

Putting Joe back on CC. Joe, can you please pick this one ?

Thanks!

Best regards,
Marek Vasut

#5 lore raw
In reply to Stephen Warren
Quoted 17 lines · Stephen Warren

From: Stephen Warren <[email protected]>

For Ethernet/USB RX packets, the ASIX HW pads odd-sized packets so that they have an even size. Currently, asix_recv() does remove this padding, and asic_send() adds equivalent padding in the TX path. However, the HW does not appear to need this packing for TX packets in practical testing with "ASIX Elec. Corp. AX88x72A 000001" Vendor: 0x0b95 Product 0x7720 Version 0.1. The Linux kernel does no such padding for the TX path.

Remove the padding from the TX path:

* For consistency with the Linux kernel.
* NVIDIA has a Tegra simulator which validates that the length of USB packets sent to an ASIX device matches the packet length value inside the packet data. Having U-Boot and the kernel do the same thing when creating the TX packets simplifies the simulator's validation.

Quoted 8 lines
Cc Lucas Stach <[email protected]>
Cc Marek Vasut <[email protected]>
Cc Simon Glass <[email protected]>
Signed-off-by Stephen Warren <[email protected]>
Acked-by Simon Glass <[email protected]>
Acked-by Marek Vasut <[email protected]>
Tested-by Marek Vasut <[email protected]>
Tested-by Gerhard Sittig <[email protected]>

Applied to u-boot/master, thanks!

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140307/f49d5567/attachment.pgp>
#6 lore raw
Quoted 28 lines · Tom Rini
Quoted 18 lines · Stephen Warren

From: Stephen Warren <[email protected]>

For Ethernet/USB RX packets, the ASIX HW pads odd-sized packets so that they have an even size. Currently, asix_recv() does remove this padding, and asic_send() adds equivalent padding in the TX path. However, the HW does not appear to need this packing for TX packets in practical testing with "ASIX Elec. Corp. AX88x72A 000001" Vendor: 0x0b95 Product 0x7720 Version 0.1. The Linux kernel does no such padding for the TX path.

Remove the padding from the TX path:

* For consistency with the Linux kernel.
* NVIDIA has a Tegra simulator which validates that the length of USB

packets sent to an ASIX device matches the packet length value inside the packet data. Having U-Boot and the kernel do the same thing when creating the TX packets simplifies the simulator's validation.

Quoted 8 lines
Cc Lucas Stach <[email protected]>
Cc Marek Vasut <[email protected]>
Cc Simon Glass <[email protected]>
Signed-off-by Stephen Warren <[email protected]>
Acked-by Simon Glass <[email protected]>
Acked-by Marek Vasut <[email protected]>
Tested-by Marek Vasut <[email protected]>
Tested-by Gerhard Sittig <[email protected]>
Quoted 1 line

Applied to u-boot/master, thanks!

Uh, where did Joe disappear to anyway ?

Best regards,
Marek Vasut

#7 lore raw

Hi Marek,

Quoted 9 lines · Marek Vasut
Quoted 2 lines · Tom Rini

Applied to u-boot/master, thanks!

Uh, where did Joe disappear to anyway ?

Best regards,
Marek Vasut

I've been traveling a lot recently and have not had much time for reviewing and testing patches. I expect to get back into it u-boot more heavily in a few months.

Regards,
-Joe