On Thu, May 12, 2016 at 3:48 PM, Justin DeFields <justindefields@xxxxxxxxx> wrote: > On Thu, May 12, 2016 at 6:27 PM, Tim Harvey <tharvey@xxxxxxxxxxxxx> wrote: >> On Tue, Jan 26, 2016 at 6:40 AM, Justin DeFields >> <justindefields@xxxxxxxxx> wrote: >>> I spoke with the Avago/PLX FAE, and they said that the PLX software >>> team that worked on this driver is no longer with the company, so they >>> cannot offer support :( >>> >>> I'm not sure there is going to be a good answer for this issue. >>> Hopefully someone here can help me evaluate the "/* paranoia */" code >>> to determine if/why/when it's necessary? >>> >>> On Fri, Jan 22, 2016 at 10:46 AM, Justin DeFields >>> <justindefields@xxxxxxxxx> wrote: >>>> >>>> It turns out that I had a filesystem issue on my target when testing >>>> my removal of the /* paranoia */ block. I thought I was writing the >>>> file to NAND, when in fact it was being written over NFS to my Virtual >>>> Machine!!! After resolving this issue, and with the removal of the >>>> paranoia logic, the transfer completes as expected very quickly and >>>> reliably (20/20 transfers completed successfully). >>>> >>>> Can anyone here help me determine if that paranoia loop is still >>>> necessary for the PCIE cards, or what the purpose of it was in the >>>> first place? >>>> >> >> Justin, >> >> Did you ever get anywhere with this? I have an ARM based board with a >> USB2380 on-board (-AA rev by the way) and gave it a try with the Linux >> 4.4 kernel today without any luck (I couldn't get g_serial, >> g_mass_storage, or g_ether to work for me). >> >> The USB2380 product brief I have states that it can be used with >> existing NET 2280/2282 software drivers with no change but of course >> at least the PCI ID's are missing. What patch/patches do you have thus >> far to add USB2380 support to net2280? >> >> Regards, >> >> Tim > > I've never received any answers for my questions unfortunately :(. If > I remember correctly, just to get the deivce working (though I'm not > sure how stable) I added a new structure for the 2380, and gave it all > the same options as the 3380, except that I split the PLX_SUPERSPEED > into 2 flags (PLX_SUPERSPEED and PLX_PCIE_MSI) to avoid setting the > super speed for the 2380 in this line: > > http://lxr.free-electrons.com/source/drivers/usb/gadget/udc/net2280.c#L3553 > > Everywhere except for that line, I replaced instances of > PLX_SUPERSPEED with PLX_PCIE_MSI (a new flag I created). > Justin, thanks for the info. I've done what you suggested and have tested with g_serial, g_mass_storage, g_ncm, and g_ether against a Linux target with a USB host controller. I don't see anything misbehaving as far as I can tell and I don't fall into the paranoia block. g_serial - no issues using serial g_ether - no issues using usb0, iperf TCP performance test yields ~75mbps g_ncm - no issues using usb0, ieprf TCP performance test yeilds ~98mbps g_usb_mass_storage - I see 6 occurrences of net2280_set_halt_and_wedge returning -EAGAIN at the beginning (which may be ok?) but my tests pass fine # insmod g_mass_storage file=/tmp/backing_file [ 770.180000] Mass Storage Function, version: 2009/09/11 [ 770.190000] LUN: removable file: (no medium) [ 770.190000] LUN: file: /tmp/backing_file [ 770.200000] Number of LUNs=1 [ 770.200000] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11 [ 770.210000] g_mass_storage gadget: userspace failed to provide iSerialNumber [ 770.220000] g_mass_storage gadget: g_mass_storage ready [ 770.220000] net2280 0000:01:00.0: Operate Defect 7374 workaround soft this time [ 770.230000] net2280 0000:01:00.0: It will operate on cold-reboot and SS connect [ 770.830000] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage [ 771.880000] net2280 0000:01:00.0: net2280_set_halt_and_wedge: error=-11 [ 771.990000] net2280 0000:01:00.0: net2280_set_halt_and_wedge: error=-11 [ 772.120000] net2280 0000:01:00.0: net2280_set_halt_and_wedge: error=-11 [ 772.230000] net2280 0000:01:00.0: net2280_set_halt_and_wedge: error=-11 [ 772.340000] net2280 0000:01:00.0: net2280_set_halt_and_wedge: error=-11 [ 772.450000] net2280 0000:01:00.0: net2280_set_halt_and_wedge: error=-11 ^^^^ these are -EAGAIN returned because the ep->queue was empty I'm assuming these messages are benign. I'll post a patch to add USB3280 support to net2280 and see if there is any additional feedback. Regards, Tim -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
