Re: [PATCH 0/2] USB 2.0 Link PM is broken
> My hypothesis is that the Synopsys host doesn't go into L1 if the device > NAKs a transfer, only when the bus is idle. That way, it doesn't have > to depend on L1 remote wakeup, which is broken for these devices. I > don't have a way to confirm that though. Paul, is the Synopsys host > working around these broken devices? I think the device actually NAKs the IN transfer of the MSC command in my test, the same way it does on Haswell. It does go into L1, but then there is a resume just a few dozen microseconds later. Unfortunately its very hard to differentiate between device and host-initiated resume in USB 2.0... but maybe the Synopsys controller just wakes stuff up on its own in some circumstances? There doesn't seem to be a clear guideline in the spec for when to trigger a host-initiated resume, so maybe they just do it whenever there are transfers queued up for a slot or something. Also, I only know that the device doesn't fail, I'm not that convinced that the LPM really works as it should. I see a lot of L1-suspends that only last for a few dozen microseconds (and the resume signalling after that takes more than a millisecond), which probably doesn't really save power. In some of those cases the host waits a few frames before scheduling a new command after resume, which suggests that the wakeup was earlier than necessary. > I do want to allow the Synopsys host to have USB 2.0 Link PM enabled if > the host has a way to work around these broken devices. Paul and > Julius, let's work out a solution to do this on top of these patches. > I suspect that the solution may be to add an update_device method to > xhci-plat that sets udev->usb2_hw_lpm_allowed, calls xhci_update_device, > and then calls usb_set_usb2_hardware_lpm(). We'll have to wait for the > updated patches from Mathias though. I'm not sure if it's necessary to make this decision in the kernel, since this seems to be very specific to a particular controller (we maybe should try out some external PCI controllers if anyone has one). I would be fine with just turning this on from user-space as we already do with autosuspend, where we can implement arbitrary policies for any particular HC/device combination. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/2] usb: implement AMD remote wakeup quirk
On Tue, Sep 24, 2013 at 10:21:32AM -0400, Alan Stern wrote:
> On Tue, 24 Sep 2013, Huang Rui wrote:
>
> > Hi Sarah and Alan,
> >
> > On Mon, Sep 23, 2013 at 05:14:02PM -0700, Sarah Sharp wrote:
> > > On Mon, Sep 23, 2013 at 12:43:15PM -0400, Alan Stern wrote:
> > > > This version of the patch set looks good.
> > > >
> > > > Alan Stern
> > >
> > > Looks fine to me as well.
> > >
> > > Acked-by: Sarah Sharp
> > >
> >
> > Thank you for acked-by :)
> > Would I better use new chipset type intead of filtering with revision
> > by hand for special generation in old AMD xhci/ehci/ohci quirks. If
> > OK, I will do this work after the quirk is applied.
>
> I think the patch is probably okay as it stands. The chipset type and
> revision values in the code should match the names chosen by the
> manufacturer.
>
Yes, the patch set refactors chipset type for AMD chipset
genernations, this type is appropriate for all AMD platforms including
the previous.
For example, below quirk for amd700 with SB800 chipsets, actually I
can only use: amd_chipset.sb_type.gen == AMD_CHIPSET_SB800 in
pci-quirks.c instead.
static int ohci_quirk_amd700(struct usb_hcd *hcd)
{
...
amd_smbus_dev = pci_get_device(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_SBX00_SMBUS, NULL);
if (!amd_smbus_dev)
return 0;
rev = amd_smbus_dev->revision;
/* SB800 needs pre-fetch fix */
if ((rev >= 0x40) && (rev <= 0x4f)) {
ohci->flags |= OHCI_QUIRK_AMD_PREFETCH;
ohci_dbg(ohci, "enabled AMD prefetch quirk\n");
}
pci_dev_put(amd_smbus_dev);
amd_smbus_dev = NULL;
...
}
So I mean whether I should do this updates for old AMD quirks in
future after this patch set is applied.
Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] USB 2.0 Link PM is broken
> From: Sarah Sharp [mailto:sarah.a.sh...@linux.intel.com] > Sent: Tuesday, September 24, 2013 2:29 PM > > Sigh. It looks like yet another aspect of USB power management is > broken. If you plug in a USB 3.0 device into a USB 2.0 port on Intel > Haswell-ULT systems, many devices fail to enumerate, or stop responding > to SCSI commands. > > The end result is that many USB 3.0 devices simply don't work when > plugged into USB 2.0 ports, on either Ubuntu or ChromeOS (or any distro > that has the BESL support patches). Bus traces are here, if anyone is > interested: > > https://plus.google.com/photos/116960357493251979546/albums/5927302519338721425 ... > Julius reported that the same devices that fail under the Intel > Haswell-ULT host work fine under the Synopsys DesignWare3 xHCI host > controller, when the unmerged patch to enable USB 2.0 Link PM for > xhci-platform devices is applied: > > http://marc.info/?l=linux-kernel&m=137704093406359&w=2 Did Julius verify with a USB analyzer that the LPM transactions are actually happening when using our host? I wasn't able to access the USB traces you pointed to above to see if there's a trace there. > My hypothesis is that the Synopsys host doesn't go into L1 if the device > NAKs a transfer, only when the bus is idle. That way, it doesn't have > to depend on L1 remote wakeup, which is broken for these devices. I > don't have a way to confirm that though. Paul, is the Synopsys host > working around these broken devices? Not that I know of. I don't think we have done much LPM testing with USB 3.0 devices connected at USB 2.0 speeds. Glad to hear it works with the Linux driver. -- Paul -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: Don't enable USB 2.0 Link PM by default.
How it's supposed to work:
--
USB 2.0 Link PM is a lower power state that some newer USB 2.0 devices
support. USB 3.0 devices certified by the USB-IF are required to
support it if they are plugged into a USB 2.0 only port, or a USB 2.0
cable is used. USB 2.0 Link PM requires both a USB device and a host
controller that supports USB 2.0 hardware-enabled LPM.
USB 2.0 Link PM is designed to be enabled once by software, and the host
hardware handles transitions to the L1 state automatically. The premise
of USB 2.0 Link PM is to be able to put the device into a lower power
link state when the bus is idle or the device NAKs USB IN transfers for
a specified amount of time.
...but hardware is broken:
--
It turns out many USB 3.0 devices claim to support USB 2.0 Link PM (by
setting the LPM bit in their USB 2.0 BOS descriptor), but they don't
actually implement it correctly. This manifests as the USB device
refusing to respond to transfers when it is plugged into a USB 2.0 only
port under the Haswell-ULT/Lynx Point LP xHCI host.
These devices pass the xHCI driver's simple test to enable USB 2.0 Link
PM, wait for the port to enter L1, and then bring it back into L0. They
only start to break when L1 entry is interleaved with transfers.
Some devices then fail to respond to the next control transfer (usually
a Set Configuration). This results in devices never enumerating.
Other mass storage devices (such as a later model Western Digital My
Passport USB 3.0 hard drive) respond fine to going into L1 between
control transfers. They ACK the entry, come out of L1 when the host
needs to send a control transfer, and respond properly to those control
transfers. However, when the first READ10 SCSI command is sent, the
device NAKs the data phase while it's reading from the spinning disk.
Eventually, the host requests to put the link into L1, and the device
ACKs that request. Then it never responds to the data phase of the
READ10 command. This results in not being able to read from the drive.
Some mass storage devices (like the Corsair Survivor USB 3.0 flash
drive) are well behaved. They ACK the entry into L1 during control
transfers, and when SCSI commands start coming in, they NAK the requests
to go into L1, because they need to be at full power.
Not all USB 3.0 devices advertise USB 2.0 link PM support. My Point
Grey USB 3.0 webcam advertises itself as a USB 2.1 device, but doesn't
have a USB 2.0 BOS descriptor, so we don't enable USB 2.0 Link PM. I
suspect that means the device isn't certified.
What do we do about it?
---
There's really no good way for the kernel to test these devices.
Therefore, the kernel needs to disable USB 2.0 Link PM by default, and
distros will have to enable it by writing 1 to the sysfs file
/sys/bus/usb/devices/../power/usb2_hardware_lpm. Rip out the xHCI Link
PM test, since it's not sufficient to detect these buggy devices, and
don't automatically enable LPM after the device is addressed.
This patch should be backported to kernels as old as 3.11, that
contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci:
add USB2 Link power management BESL support". Without this fix, some
USB 3.0 devices will not enumerate or work properly under USB 2.0 ports
on Haswell-ULT systems.
Signed-off-by: Sarah Sharp
Cc: sta...@vger.kernel.org
---
drivers/usb/core/driver.c | 3 +
drivers/usb/core/sysfs.c| 1 +
drivers/usb/host/xhci-mem.c | 10 ---
drivers/usb/host/xhci.c | 152 +++-
include/linux/usb.h | 4 +-
5 files changed, 16 insertions(+), 154 deletions(-)
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index f7841d4..689433c 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -1790,6 +1790,9 @@ int usb_set_usb2_hardware_lpm(struct usb_device *udev,
int enable)
struct usb_hcd *hcd = bus_to_hcd(udev->bus);
int ret = -EPERM;
+ if (enable && !udev->usb2_hw_lpm_allowed)
+ return 0;
+
if (hcd->driver->set_usb2_hw_lpm) {
ret = hcd->driver->set_usb2_hw_lpm(hcd, udev, enable);
if (!ret)
diff --git a/drivers/usb/core/sysfs.c b/drivers/usb/core/sysfs.c
index 6d2c8ed..76bce3a 100644
--- a/drivers/usb/core/sysfs.c
+++ b/drivers/usb/core/sysfs.c
@@ -469,6 +469,7 @@ static ssize_t usb2_hardware_lpm_store(struct device *dev,
ret = strtobool(buf, &value);
+ udev->usb2_hw_lpm_allowed = value;
if (!ret)
ret = usb_set_usb2_hardware_lpm(udev, value);
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 83bcd13..49b8bd0 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1693,9 +1693,7 @@ void xhci_free_command(struct xhci_hcd *xhci,
void xhci_mem_cleanup(struct xhci_hcd *xhci)
{
struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.con
[PATCH 2/2] usb: Disable USB 2.0 Link PM before device reset.
Before the USB core resets a device, we need to disable the L1 timeout for the roothub, if USB 2.0 Link PM is enabled. Otherwise the port may transition into L1 in between descriptor fetches, before we know if the USB device descriptors changed. LPM will be re-enabled after the full device descriptors are fetched, and we can confirm the device still supports USB 2.0 LPM after the reset. We don't need to wait for the USB device to exit L1 before resetting the device, since the xHCI roothub port diagrams show a transition to the Reset state from any of the Ux states (see Figure 34 in the 2012-08-14 xHCI specification update). Signed-off-by: Sarah Sharp --- drivers/usb/core/hub.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index e6b682c..cfb31a2 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -5086,6 +5086,12 @@ static int usb_reset_and_verify_device(struct usb_device *udev) } parent_hub = usb_hub_to_struct_hub(parent_hdev); + /* Disable USB2 hardware LPM. +* It will be re-enabled by the enumeration process. +*/ + if (udev->usb2_hw_lpm_enabled == 1) + usb_set_usb2_hardware_lpm(udev, 0); + bos = udev->bos; udev->bos = NULL; -- 1.8.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] USB 2.0 Link PM is broken
Sigh. It looks like yet another aspect of USB power management is broken. If you plug in a USB 3.0 device into a USB 2.0 port on Intel Haswell-ULT systems, many devices fail to enumerate, or stop responding to SCSI commands. The end result is that many USB 3.0 devices simply don't work when plugged into USB 2.0 ports, on either Ubuntu or ChromeOS (or any distro that has the BESL support patches). Bus traces are here, if anyone is interested: https://plus.google.com/photos/116960357493251979546/albums/5927302519338721425 This issue also shows up under Windows, and their solution was to disable USB 2.0 Link PM for all devices, except for those that are on internal ports, or external devices that advertise BESL support instead of the older HIRD support in their USB 2.0 BOS descriptor. The first patch disables USB 2.0 Link PM by default, and only re-enables it when userspace writes 1 to /sys/bus/usb/devices/../power/usb2_hardware_lpm. Mathias is working on a further patch to enable USB 2.0 Link PM for internal devices or devices that have BESL support. Julius reported that the same devices that fail under the Intel Haswell-ULT host work fine under the Synopsys DesignWare3 xHCI host controller, when the unmerged patch to enable USB 2.0 Link PM for xhci-platform devices is applied: http://marc.info/?l=linux-kernel&m=137704093406359&w=2 My hypothesis is that the Synopsys host doesn't go into L1 if the device NAKs a transfer, only when the bus is idle. That way, it doesn't have to depend on L1 remote wakeup, which is broken for these devices. I don't have a way to confirm that though. Paul, is the Synopsys host working around these broken devices? I do want to allow the Synopsys host to have USB 2.0 Link PM enabled if the host has a way to work around these broken devices. Paul and Julius, let's work out a solution to do this on top of these patches. I suspect that the solution may be to add an update_device method to xhci-plat that sets udev->usb2_hw_lpm_allowed, calls xhci_update_device, and then calls usb_set_usb2_hardware_lpm(). We'll have to wait for the updated patches from Mathias though. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove VLAIS usage from gadget code - alternate patch
On 09/24/13 13:56, charl...@gmail.com wrote: From: Mark Charlebois The use of variable length arrays in structs (VLAIS) in the Linux Kernel code precludes the use of compilers which don't implement VLAIS (for instance the Clang compiler). This alternate patch calculates offsets into the kmalloc-ed memory buffer using macros. The previous patch required multiple kmalloc and kfree calls. Signed-off-by: Mark Charlebois Signed-off-by: Behan Webster This one uses macros and carves up a single piece of memory from one kmalloc. Behan -- Behan Webster beh...@converseincode.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problematic device
On Tue, 24 Sep 2013, folkert wrote: > > Then the problem is most likely in the device or the firmware. If you > > get a usbmon trace, it might provide more information. > > > You asked what the firmware is doing wrong, but you already know the > > answer: It disconnects the device every 6-7 seconds. Perhaps it does > > this because it doesn't like the commands it receives from the > > computer. > > In this logging I plugged-in the device and waited for it to disconnect > and reconnect again. > I googled but did not find something that translates this logging into > human readable format. Are there any that you know of? No. But I can interpret it for you. > 88044d799980 4062710749 S Ci:3:001:0 s a3 00 0001 0004 4 < > 88044d799980 4062710758 C Ci:3:001:0 0 4 = 0001 > 88044d799980 4062710768 S Ci:3:001:0 s a3 00 0002 0004 4 < > 88044d799980 4062710770 C Ci:3:001:0 0 4 = 0001 > 88044d799980 4062710770 S Ci:3:001:0 s a3 00 0003 0004 4 < > 88044d799980 4062710780 C Ci:3:001:0 0 4 = 0001 > 88044d799980 4062710781 S Ci:3:001:0 s a3 00 0004 0004 4 < > 88044d799980 4062710782 C Ci:3:001:0 0 4 = 01030100 > 88044d799980 4062710783 S Co:3:001:0 s 23 01 0010 0004 0 > 88044d799980 4062710786 C Co:3:001:0 0 0 > 880449ee9600 4062814544 S Ii:3:001:1 -115:2048 4 < > 8803b4a1d300 4062814640 S Ci:3:001:0 s a3 00 0004 0004 4 < > 8803b4a1d300 4062814645 C Ci:3:001:0 0 4 = 0103 > 8803b4a1d300 4062814686 S Co:3:001:0 s 23 03 0004 0004 0 > 8803b4a1d300 4062814690 C Co:3:001:0 0 0 > 8803b4a1d300 4062870540 S Ci:3:001:0 s a3 00 0004 0004 4 < > 8803b4a1d300 4062870551 C Ci:3:001:0 0 4 = 03031000 > 8803b4a1d300 4062926555 S Co:3:001:0 s 23 01 0014 0004 0 > 8803b4a1d300 4062926583 C Co:3:001:0 0 0 The part above is normal device detection and reset. > 8803b4a1d300 4062942522 S Ci:3:123:0 s 80 06 0100 0008 8 < > 8803b4a1d300 4062942946 C Ci:3:123:0 0 8 = 12010002 0008 > 8803b4a1d300 4062943053 S Ci:3:123:0 s 80 06 0100 0012 18 < > 8803b4a1d300 4062943699 C Ci:3:123:0 0 18 = 12010002 0008 500d1000 > 07000102 0301 > 8803b4a1d300 4062943846 S Ci:3:123:0 s 80 06 0200 0009 9 < > 8803b4a1d300 4062944426 C Ci:3:123:0 0 9 = 09022900 01010080 32 > 8803b4a1d300 4062944543 S Ci:3:123:0 s 80 06 0200 0029 41 < > 8803b4a1d300 4062945716 C Ci:3:123:0 0 41 = 09022900 01010080 32090400 > 00020300 0921 11010001 2237 05810308 > 8803b4a1d300 4062945841 S Ci:3:123:0 s 80 06 0300 00ff 255 < > 8803b4a1d300 4062946185 C Ci:3:123:0 0 4 = 04030704 > 8803b4a1d300 4062946297 S Ci:3:123:0 s 80 06 0302 0407 00ff 255 < > 8803b4a1d300 4062946920 C Ci:3:123:0 0 18 = 12035500 53004200 2d005400 > 65006d00 7000 > 8803b4a1d300 4062947054 S Ci:3:123:0 s 80 06 0301 0407 00ff 255 < > 8803b4a1d300 4062947836 C Ci:3:123:0 0 26 = 1a034300 6c006500 77006100 > 72006500 20004700 6d006200 4800 > 8803b4a1d300 4062947884 S Ci:3:123:0 s 80 06 0303 0407 00ff 255 < > 8803b4a1d300 4062948549 C Ci:3:123:0 0 12 = 0c033600 33003800 31003300 This is normal enumeration (reading the device's descriptors). > 8803b4a1d900 4062948944 S Co:3:123:0 s 00 09 0001 0 > 8803b4a1d900 4062949285 C Co:3:123:0 0 0 > 8803b4a1d180 4062949459 S Ci:3:123:0 s 80 06 0303 0407 00ff 255 < > 8803b4a1d180 4062949988 C Ci:3:123:0 0 12 = 0c033600 33003800 31003300 This installs the HID configuration and re-reads a string descriptor. > 8803b4a1d180 4062950110 S Co:3:123:0 s 21 0a 0 > 8803b4a1d180 4062950425 C Co:3:123:0 0 0 > 8803b4a1d180 4062950455 S Ci:3:123:0 s 81 06 2200 0030 48 < > 8803b4a1d180 4062951755 C Ci:3:123:0 0 48 = 06a0ff09 01a10109 02a10006 > a1ff0903 1580257f 350045ff 75089506 81020904 > 88044bad9c80 4062951977 S Ci:3:123:0 s a1 01 0100 0006 8 < > 88044bad9c80 4062952411 C Ci:3:123:0 0 6 = This is normal HID initialization: setting the Idle delay to 0, reading the report descriptor, and issuing a Get-Report request. > 880449ee9600 4069614870 C Ii:3:001:1 0:2048 1 = 10 > 880449ee9600 4069614889 S Ii:3:001:1 -115:2048 4 < > 88029ca33980 4069614999 S Ci:3:001:0 s a3 00 0004 0004 4 < > 88029ca33980 4069615003 C Ci:3:001:0 0 4 = 00010100 > 88029ca33980 4069615007 S Co:3:001:0 s 23 01 0010 0004 0 > 88029ca33980 4069615010 C Co:3:001:0 0 0 > 8803b4a1d300 4069615639 S Ci:3:001:0 s a3 00 0004 0004 4 < > 8803b4a1d300 4069615651 C Ci:3:001:0 0 4 = 0001 > 8803b4a1d300 4069646488 S Ci:3:001:0 s a3 00 0004 0004 4 < > 8803b4a1d300 4069646493 C Ci:3:001:0 0 4 = 0001 > 8803b4a1d300 4069678554 S Ci:3:001:0 s a3 00 0004 0004 4 < > 8803b4a1d300 4069678564 C Ci:3:001:0 0 4 = 0001 > 8803b4a1d300 4069710551 S Ci:3:001:0 s a3 00 0004 0004 4 < > 8803b4a1d300 4069710562 C Ci:3:001:0 0 4
Re: problematic device
> Then the problem is most likely in the device or the firmware. If you > get a usbmon trace, it might provide more information. > You asked what the firmware is doing wrong, but you already know the > answer: It disconnects the device every 6-7 seconds. Perhaps it does > this because it doesn't like the commands it receives from the > computer. In this logging I plugged-in the device and waited for it to disconnect and reconnect again. I googled but did not find something that translates this logging into human readable format. Are there any that you know of? 88044d799980 4062710749 S Ci:3:001:0 s a3 00 0001 0004 4 < 88044d799980 4062710758 C Ci:3:001:0 0 4 = 0001 88044d799980 4062710768 S Ci:3:001:0 s a3 00 0002 0004 4 < 88044d799980 4062710770 C Ci:3:001:0 0 4 = 0001 88044d799980 4062710770 S Ci:3:001:0 s a3 00 0003 0004 4 < 88044d799980 4062710780 C Ci:3:001:0 0 4 = 0001 88044d799980 4062710781 S Ci:3:001:0 s a3 00 0004 0004 4 < 88044d799980 4062710782 C Ci:3:001:0 0 4 = 01030100 88044d799980 4062710783 S Co:3:001:0 s 23 01 0010 0004 0 88044d799980 4062710786 C Co:3:001:0 0 0 880449ee9600 4062814544 S Ii:3:001:1 -115:2048 4 < 8803b4a1d300 4062814640 S Ci:3:001:0 s a3 00 0004 0004 4 < 8803b4a1d300 4062814645 C Ci:3:001:0 0 4 = 0103 8803b4a1d300 4062814686 S Co:3:001:0 s 23 03 0004 0004 0 8803b4a1d300 4062814690 C Co:3:001:0 0 0 8803b4a1d300 4062870540 S Ci:3:001:0 s a3 00 0004 0004 4 < 8803b4a1d300 4062870551 C Ci:3:001:0 0 4 = 03031000 8803b4a1d300 4062926555 S Co:3:001:0 s 23 01 0014 0004 0 8803b4a1d300 4062926583 C Co:3:001:0 0 0 8803b4a1d300 4062942522 S Ci:3:123:0 s 80 06 0100 0008 8 < 8803b4a1d300 4062942946 C Ci:3:123:0 0 8 = 12010002 0008 8803b4a1d300 4062943053 S Ci:3:123:0 s 80 06 0100 0012 18 < 8803b4a1d300 4062943699 C Ci:3:123:0 0 18 = 12010002 0008 500d1000 07000102 0301 8803b4a1d300 4062943846 S Ci:3:123:0 s 80 06 0200 0009 9 < 8803b4a1d300 4062944426 C Ci:3:123:0 0 9 = 09022900 01010080 32 8803b4a1d300 4062944543 S Ci:3:123:0 s 80 06 0200 0029 41 < 8803b4a1d300 4062945716 C Ci:3:123:0 0 41 = 09022900 01010080 32090400 00020300 0921 11010001 2237 05810308 8803b4a1d300 4062945841 S Ci:3:123:0 s 80 06 0300 00ff 255 < 8803b4a1d300 4062946185 C Ci:3:123:0 0 4 = 04030704 8803b4a1d300 4062946297 S Ci:3:123:0 s 80 06 0302 0407 00ff 255 < 8803b4a1d300 4062946920 C Ci:3:123:0 0 18 = 12035500 53004200 2d005400 65006d00 7000 8803b4a1d300 4062947054 S Ci:3:123:0 s 80 06 0301 0407 00ff 255 < 8803b4a1d300 4062947836 C Ci:3:123:0 0 26 = 1a034300 6c006500 77006100 72006500 20004700 6d006200 4800 8803b4a1d300 4062947884 S Ci:3:123:0 s 80 06 0303 0407 00ff 255 < 8803b4a1d300 4062948549 C Ci:3:123:0 0 12 = 0c033600 33003800 31003300 8803b4a1d900 4062948944 S Co:3:123:0 s 00 09 0001 0 8803b4a1d900 4062949285 C Co:3:123:0 0 0 8803b4a1d180 4062949459 S Ci:3:123:0 s 80 06 0303 0407 00ff 255 < 8803b4a1d180 4062949988 C Ci:3:123:0 0 12 = 0c033600 33003800 31003300 8803b4a1d180 4062950110 S Co:3:123:0 s 21 0a 0 8803b4a1d180 4062950425 C Co:3:123:0 0 0 8803b4a1d180 4062950455 S Ci:3:123:0 s 81 06 2200 0030 48 < 8803b4a1d180 4062951755 C Ci:3:123:0 0 48 = 06a0ff09 01a10109 02a10006 a1ff0903 1580257f 350045ff 75089506 81020904 88044bad9c80 4062951977 S Ci:3:123:0 s a1 01 0100 0006 8 < 88044bad9c80 4062952411 C Ci:3:123:0 0 6 = 880449ee9600 4069614870 C Ii:3:001:1 0:2048 1 = 10 880449ee9600 4069614889 S Ii:3:001:1 -115:2048 4 < 88029ca33980 4069614999 S Ci:3:001:0 s a3 00 0004 0004 4 < 88029ca33980 4069615003 C Ci:3:001:0 0 4 = 00010100 88029ca33980 4069615007 S Co:3:001:0 s 23 01 0010 0004 0 88029ca33980 4069615010 C Co:3:001:0 0 0 8803b4a1d300 4069615639 S Ci:3:001:0 s a3 00 0004 0004 4 < 8803b4a1d300 4069615651 C Ci:3:001:0 0 4 = 0001 8803b4a1d300 4069646488 S Ci:3:001:0 s a3 00 0004 0004 4 < 8803b4a1d300 4069646493 C Ci:3:001:0 0 4 = 0001 8803b4a1d300 4069678554 S Ci:3:001:0 s a3 00 0004 0004 4 < 8803b4a1d300 4069678564 C Ci:3:001:0 0 4 = 0001 8803b4a1d300 4069710551 S Ci:3:001:0 s a3 00 0004 0004 4 < 8803b4a1d300 4069710562 C Ci:3:001:0 0 4 = 0001 880449ee9600 4069717392 C Ii:3:001:1 0:2048 1 = 10 880449ee9600 4069717408 S Ii:3:001:1 -115:2048 4 < 8803b4a1d300 4069742523 S Ci:3:001:0 s a3 00 0004 0004 4 < 8803b4a1d300 4069742536 C Ci:3:001:0 0 4 = 01030100 8803b4a1d300 4069742540 S Co:3:001:0 s 23 01 0010 0004 0 8803b4a1d300 4069742544 C Co:3:001:0 0 0 8803b4a1d300 4069774556 S Ci:3:001:0 s a3 00 0004 0004 4 < 8803b4a1d300 4069774566 C Ci:3:001:0 0 4 = 0103 8803b4a1d300 4069806559 S Ci:3:001:0 s a3 00 0004 0004 4 < fff
[PATCH] USB: iMX21: accept very late isochronous URBs
Commit 24f531371de1 (USB: EHCI: accept very late isochronous URBs)
changed the isochronous API provided by ehci-hcd. URBs submitted too
late, so that the time slots for all their packets have already
expired, are no longer rejected outright. Instead the submission is
accepted, and the URB completes normally with a -EXDEV error for each
packet. This is what client drivers expect.
The same policy should be implemented in imx21-hcd, but I don't know
enough about the hardware to do it. As a second-best substitute, this
patch treats very late isochronous submissions as though the
URB_ISO_ASAP flag were set. I don't have any way to test this change,
unfortunately.
Signed-off-by: Alan Stern
CC: Sascha Hauer
CC: Martin Fuzzey
---
[as1713]
drivers/usb/host/imx21-hcd.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
Index: usb-3.11/drivers/usb/host/imx21-hcd.c
===
--- usb-3.11.orig/drivers/usb/host/imx21-hcd.c
+++ usb-3.11/drivers/usb/host/imx21-hcd.c
@@ -824,13 +824,13 @@ static int imx21_hc_urb_enqueue_isoc(str
i = DIV_ROUND_UP(wrap_frame(
cur_frame - urb->start_frame),
urb->interval);
- if (urb->transfer_flags & URB_ISO_ASAP) {
+
+ /* Treat underruns as if URB_ISO_ASAP was set */
+ if ((urb->transfer_flags & URB_ISO_ASAP) ||
+ i >= urb->number_of_packets) {
urb->start_frame = wrap_frame(urb->start_frame
+ i * urb->interval);
i = 0;
- } else if (i >= urb->number_of_packets) {
- ret = -EXDEV;
- goto alloc_dmem_failed;
}
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: UHCI: accept very late isochronous URBs
Commit 24f531371de1 (USB: EHCI: accept very late isochronous URBs)
changed the isochronous API provided by ehci-hcd. URBs submitted too
late, so that the time slots for all their packets have already
expired, are no longer rejected outright. Instead the submission is
accepted, and the URB completes normally with a -EXDEV error for each
packet. This is what client drivers expect.
This patch implements the same policy in uhci-hcd. It should be
applied to all kernels containing commit c44b225077bb (UHCI: implement
new semantics for URB_ISO_ASAP).
Signed-off-by: Alan Stern
CC:
---
[as1711]
drivers/usb/host/uhci-q.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
Index: usb-3.11/drivers/usb/host/uhci-q.c
===
--- usb-3.11.orig/drivers/usb/host/uhci-q.c
+++ usb-3.11/drivers/usb/host/uhci-q.c
@@ -1303,7 +1303,7 @@ static int uhci_submit_isochronous(struc
}
/* Fell behind? */
- if (uhci_frame_before_eq(frame, next)) {
+ if (!uhci_frame_before_eq(next, frame)) {
/* USB_ISO_ASAP: Round up to the first available slot */
if (urb->transfer_flags & URB_ISO_ASAP)
@@ -1311,13 +1311,17 @@ static int uhci_submit_isochronous(struc
-qh->period;
/*
-* Not ASAP: Use the next slot in the stream. If
-* the entire URB falls before the threshold, fail.
+* Not ASAP: Use the next slot in the stream,
+* no matter what.
*/
else if (!uhci_frame_before_eq(next,
frame + (urb->number_of_packets - 1) *
qh->period))
- return -EXDEV;
+ dev_dbg(uhci_dev(uhci), "iso underrun %p (%u+%u
< %u)\n",
+ urb, frame,
+ (urb->number_of_packets - 1) *
+ qh->period,
+ next);
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: OHCI: accept very late isochronous URBs
Commit 24f531371de1 (USB: EHCI: accept very late isochronous URBs)
changed the isochronous API provided by ehci-hcd. URBs submitted too
late, so that the time slots for all their packets have already
expired, are no longer rejected outright. Instead the submission is
accepted, and the URB completes normally with a -EXDEV error for each
packet. This is what client drivers expect.
This patch implements the same policy in ohci-hcd. The change is more
complicated than it was in ehci-hcd, because ohci-hcd doesn't scan for
isochronous completions in the same way as ehci-hcd does. Rather, it
depends on the hardware adding completed TDs to a "done queue". Some
OHCI controller don't handle this properly when a TD's time slot has
already expired, so we have to avoid adding such TDs to the schedule
in the first place. As a result, if the URB was submitted too late
then none of its TDs will get put on the schedule, so none of them
will end up on the done queue, so the driver will never realize that
the URB should be completed.
To solve this problem, the patch adds one to urb_priv->td_cnt for such
URBs, making it larger than urb_priv->length (td_cnt already gets set
to the number of TD's that had to be skipped because their slots have
expired). Each time an URB is given back, the finish_urb() routine
looks to see if urb_priv->td_cnt for the next URB on the same endpoint
is marked in this way. If so, it gives back the next URB right away.
This should be applied to all kernels containing commit 815fa7b91761
(USB: OHCI: fix logic for scheduling isochronous URBs).
Signed-off-by: Alan Stern
CC:
---
[as1710]
drivers/usb/host/ohci-hcd.c | 22 --
drivers/usb/host/ohci-q.c | 26 ++
2 files changed, 34 insertions(+), 14 deletions(-)
Index: usb-3.11/drivers/usb/host/ohci-hcd.c
===
--- usb-3.11.orig/drivers/usb/host/ohci-hcd.c
+++ usb-3.11/drivers/usb/host/ohci-hcd.c
@@ -216,31 +216,26 @@ static int ohci_urb_enqueue (
frame &= ~(ed->interval - 1);
frame |= ed->branch;
urb->start_frame = frame;
+ ed->last_iso = frame + ed->interval * (size - 1);
}
} else if (ed->type == PIPE_ISOCHRONOUS) {
u16 next = ohci_frame_no(ohci) + 1;
u16 frame = ed->last_iso + ed->interval;
+ u16 length = ed->interval * (size - 1);
/* Behind the scheduling threshold? */
if (unlikely(tick_before(frame, next))) {
- /* USB_ISO_ASAP: Round up to the first available slot */
+ /* URB_ISO_ASAP: Round up to the first available slot */
if (urb->transfer_flags & URB_ISO_ASAP) {
frame += (next - frame + ed->interval - 1) &
-ed->interval;
/*
-* Not ASAP: Use the next slot in the stream. If
-* the entire URB falls before the threshold, fail.
+* Not ASAP: Use the next slot in the stream,
+* no matter what.
*/
} else {
- if (tick_before(frame + ed->interval *
- (urb->number_of_packets - 1), next)) {
- retval = -EXDEV;
- usb_hcd_unlink_urb_from_ep(hcd, urb);
- goto fail;
- }
-
/*
* Some OHCI hardware doesn't handle late TDs
* correctly. After retiring them it proceeds
@@ -251,9 +246,16 @@ static int ohci_urb_enqueue (
urb_priv->td_cnt = DIV_ROUND_UP(
(u16) (next - frame),
ed->interval);
+ if (urb_priv->td_cnt >= urb_priv->length) {
+ ++urb_priv->td_cnt; /* Mark it */
+ ohci_dbg(ohci, "iso underrun %p (%u+%u
< %u)\n",
+ urb, frame, length,
+ next);
+ }
}
}
urb->start_frame = frame;
+ ed->last_iso = frame + length;
}
/* fill the TDs and link them to the ed; and
Index: usb-3.11/drivers/usb/host/ohci-q.c
===
--- usb-3.11.orig/drivers/usb/host/ohci-q.c
+++ usb-3.11/drivers/usb/host/ohci-q.c
@@ -41,9
[PATCH] USB: fix PM config symbol in uhci-hcd, ehci-hcd, and xhci-hcd
Since uhci-hcd, ehci-hcd, and xhci-hcd support runtime PM, the .pm
field in their pci_driver structures should be protected by CONFIG_PM
rather than CONFIG_PM_SLEEP. The corresponding change has already
been made for ohci-hcd.
Without this change, controllers won't do runtime suspend if system
suspend or hibernation isn't enabled.
Signed-off-by: Alan Stern
CC: Sarah Sharp
CC:
---
[as1708]
drivers/usb/host/ehci-pci.c |2 +-
drivers/usb/host/uhci-pci.c |2 +-
drivers/usb/host/xhci-pci.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
Index: usb-3.11/drivers/usb/host/ehci-pci.c
===
--- usb-3.11.orig/drivers/usb/host/ehci-pci.c
+++ usb-3.11/drivers/usb/host/ehci-pci.c
@@ -361,7 +361,7 @@ static struct pci_driver ehci_pci_driver
.remove = usb_hcd_pci_remove,
.shutdown = usb_hcd_pci_shutdown,
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM
.driver = {
.pm = &usb_hcd_pci_pm_ops
},
Index: usb-3.11/drivers/usb/host/uhci-pci.c
===
--- usb-3.11.orig/drivers/usb/host/uhci-pci.c
+++ usb-3.11/drivers/usb/host/uhci-pci.c
@@ -293,7 +293,7 @@ static struct pci_driver uhci_pci_driver
.remove = usb_hcd_pci_remove,
.shutdown = uhci_shutdown,
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM
.driver = {
.pm = &usb_hcd_pci_pm_ops
},
Index: usb-3.11/drivers/usb/host/xhci-pci.c
===
--- usb-3.11.orig/drivers/usb/host/xhci-pci.c
+++ usb-3.11/drivers/usb/host/xhci-pci.c
@@ -351,7 +351,7 @@ static struct pci_driver xhci_pci_driver
/* suspend and resume implemented later */
.shutdown = usb_hcd_pci_shutdown,
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM
.driver = {
.pm = &usb_hcd_pci_pm_ops
},
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: fix substandard locking for the sysfs files
This patch straightens out some locking issues in the USB sysfs
interface:
Deauthorization will destroy existing configurations.
Attributes that read from udev->actconfig need to lock the
device to prevent races. Likewise for the rawdescriptor
values.
Attributes that access an interface's current alternate
setting should use ACCESS_ONCE() to obtain the cur_altsetting
pointer, to protect against concurrent altsetting changes.
The supports_autosuspend() attribute routine accesses values
from an interface's driver, so it should lock the interface
(rather than the usb_device) to protect against concurrent
unbinds. Once this is done, the routine can be simplified
considerably.
Scalar values that are stored directly in the usb_device structure are
always available. They do not require any locking. The same is true
of the cached interface string descriptor, because it is not
deallocated until the usb_host_interface structure is destroyed.
Signed-off-by: Alan Stern
CC: Hans de Goede
---
In theory, this could be applied to the stable kernels. In practice, I
doubt that it matters much.
[as1546]
drivers/usb/core/sysfs.c | 53 +++
1 file changed, 26 insertions(+), 27 deletions(-)
Index: usb-3.11/drivers/usb/core/sysfs.c
===
--- usb-3.11.orig/drivers/usb/core/sysfs.c
+++ usb-3.11/drivers/usb/core/sysfs.c
@@ -23,14 +23,16 @@ static ssize_t field##_show(struct devic
{ \
struct usb_device *udev;\
struct usb_host_config *actconfig; \
+ ssize_t rc = 0; \
\
udev = to_usb_device(dev); \
+ usb_lock_device(udev); \
actconfig = udev->actconfig;\
if (actconfig) \
- return sprintf(buf, format_string, \
+ rc = sprintf(buf, format_string,\
actconfig->desc.field); \
- else\
- return 0; \
+ usb_unlock_device(udev);\
+ return rc; \
} \
#define usb_actconfig_attr(field, format_string) \
@@ -45,12 +47,15 @@ static ssize_t bMaxPower_show(struct dev
{
struct usb_device *udev;
struct usb_host_config *actconfig;
+ ssize_t rc = 0;
udev = to_usb_device(dev);
+ usb_lock_device(udev);
actconfig = udev->actconfig;
- if (!actconfig)
- return 0;
- return sprintf(buf, "%dmA\n", usb_get_max_power(udev, actconfig));
+ if (actconfig)
+ rc = sprintf(buf, "%dmA\n", usb_get_max_power(udev, actconfig));
+ usb_unlock_device(udev);
+ return rc;
}
static DEVICE_ATTR_RO(bMaxPower);
@@ -59,12 +64,15 @@ static ssize_t configuration_show(struct
{
struct usb_device *udev;
struct usb_host_config *actconfig;
+ ssize_t rc = 0;
udev = to_usb_device(dev);
+ usb_lock_device(udev);
actconfig = udev->actconfig;
- if ((!actconfig) || (!actconfig->string))
- return 0;
- return sprintf(buf, "%s\n", actconfig->string);
+ if (actconfig && actconfig->string)
+ rc = sprintf(buf, "%s\n", actconfig->string);
+ usb_unlock_device(udev);
+ return rc;
}
static DEVICE_ATTR_RO(configuration);
@@ -764,6 +772,7 @@ read_descriptors(struct file *filp, stru
* Following that are the raw descriptor entries for all the
* configurations (config plus subsidiary descriptors).
*/
+ usb_lock_device(udev);
for (cfgno = -1; cfgno < udev->descriptor.bNumConfigurations &&
nleft > 0; ++cfgno) {
if (cfgno < 0) {
@@ -784,6 +793,7 @@ read_descriptors(struct file *filp, stru
off -= srclen;
}
}
+ usb_unlock_device(udev);
return count - nleft;
}
@@ -870,9 +880,7 @@ static ssize_t interface_show(struct dev
char *string;
intf = to_usb_interface(dev);
- string = intf->cur_altsetting->string;
- barrier(); /* The altsetting might change! */
-
+ string = ACCESS_ONCE(intf->cur_altsetting->strin
Re: [PATCH] Memory mapping for USBFS
On Tue, Sep 24, 2013 at 9:12 PM, Markus Rechberger
wrote:
> This patch adds memory mapping support to USBFS for isochronous and bulk
> data transfers, it allows to pre-allocate usb transfer buffers.
>
> The CPU usage decreases 1-2% on my 1.3ghz U7300 notebook when
> transferring 20mbyte/sec, it should be more interesting to see those
> statistics on embedded systems where copying data is more expensive.
>
> Usage from userspace:
> allocation:
>rv = ioctl(priv->usbfd, USBDEVFS_ALLOC_MEMORY, &mem);
> if (rv == 0)
> buffer = mmap(NULL, size, PROT_READ|PROT_WRITE,
> MAP_SHARED, priv->usbfd, mem.offset);
> use the mapped buffer with urb->buffer.
> release:
> rv = munmap(buffer, size);
> memset(&mem, 0x0, sizeof(struct usbdevfs_memory));
> mem.buffer = buffer;
> rv = ioctl(priv->usbfd, USBDEVFS_RELEASE_MEMORY, &mem);
>
> non freed memory buffers are collected and will be released when closing
> the node.
>
> I tested this patch with Bulk and Isochronous, with and without memory
> mapping (applications which don't use mmap will just fall back to the
> legacy mechanism).
>
> Version 0.3:
> * Removed comment
> * Renamed USBDEVFS_FREE_MEMORY to USBDEVFS_ALLOC_MEMORY
* Renamed USBDEVFS_FREE_MEMORY to USBDEVFS_RELEASE_MEMORY of course
> * Clearing allocated memory
>
> Signed-off-by: Markus Rechberger
>
>
> diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> index 737e3c1..584253b 100644
> --- a/drivers/usb/core/devio.c
> +++ b/drivers/usb/core/devio.c
> @@ -69,6 +69,7 @@ struct dev_state {
> spinlock_t lock;/* protects the async urb lists */
> struct list_head async_pending;
> struct list_head async_completed;
> + struct list_head memory_list;
> wait_queue_head_t wait; /* wake up if a request completed */
> unsigned int discsignr;
> struct pid *disc_pid;
> @@ -96,6 +97,16 @@ struct async {
> u8 bulk_status;
> };
>
> +struct usb_memory {
> + struct list_head memlist;
> + int vma_use_count;
> + int usb_use_count;
> + u32 offset;
> + u32 size;
> + void *mem;
> + unsigned long vm_start;
> +};
> +
> static bool usbfs_snoop;
> module_param(usbfs_snoop, bool, S_IRUGO | S_IWUSR);
> MODULE_PARM_DESC(usbfs_snoop, "true to log all usbfs traffic");
> @@ -288,6 +299,9 @@ static struct async *alloc_async(unsigned int
> numisoframes)
>
> static void free_async(struct async *as)
> {
> + struct usb_memory *usbm = NULL, *usbm_iter;
> + unsigned long flags;
> + struct dev_state *ps = as->ps;
> int i;
>
> put_pid(as->pid);
> @@ -297,8 +311,22 @@ static void free_async(struct async *as)
> if (sg_page(&as->urb->sg[i]))
> kfree(sg_virt(&as->urb->sg[i]));
> }
> +
> + spin_lock_irqsave(&ps->lock, flags);
> + list_for_each_entry(usbm_iter, &ps->memory_list, memlist) {
> + if (usbm_iter->mem == as->urb->transfer_buffer) {
> + usbm = usbm_iter;
> + break;
> + }
> + }
> + spin_unlock_irqrestore(&ps->lock, flags);
> +
> kfree(as->urb->sg);
> - kfree(as->urb->transfer_buffer);
> + if (usbm == NULL)
> + kfree(as->urb->transfer_buffer);
> + else
> + usbm->usb_use_count--;
> +
> kfree(as->urb->setup_packet);
> usb_free_urb(as->urb);
> usbfs_decrease_memory_usage(as->mem_usage);
> @@ -811,6 +839,7 @@ static int usbdev_open(struct inode *inode, struct file
> *file)
> INIT_LIST_HEAD(&ps->list);
> INIT_LIST_HEAD(&ps->async_pending);
> INIT_LIST_HEAD(&ps->async_completed);
> + INIT_LIST_HEAD(&ps->memory_list);
> init_waitqueue_head(&ps->wait);
> ps->discsignr = 0;
> ps->disc_pid = get_pid(task_pid(current));
> @@ -839,6 +868,8 @@ static int usbdev_release(struct inode *inode, struct
> file *file)
> struct dev_state *ps = file->private_data;
> struct usb_device *dev = ps->dev;
> unsigned int ifnum;
> + struct list_head *p, *q;
> + struct usb_memory *tmp;
> struct async *as;
>
> usb_lock_device(dev);
> @@ -863,6 +894,14 @@ static int usbdev_release(struct inode *inode, struct
> file *file)
> free_async(as);
> as = async_getcompleted(ps);
> }
> +
> + list_for_each_safe(p, q, &ps->memory_list) {
> + tmp = list_entry(p, struct usb_memory, memlist);
> + list_del(p);
> + if (tmp->mem)
> + free_pages_exact(tmp->mem, tmp->size);
> + kfree(tmp);
> + }
> kfree(ps);
> return 0;
> }
> @@ -1173,6 +1212,7 @@ static int proc_do_submiturb(struct dev_state *ps,
> struct usbdevfs_urb *uurb,
> struct usb_host_endpoint *ep;
driver request
Hello, Can you add the startech.com usb to serial adapter to a proper driver. I am using the command sudo modprobe usbserial vendor=0x14b0 product=0x3410 It works on my ubuntu 12.04 AMD 64 desktop system but my linux mint 15 netbook AOD270 will not get me to console into my Cisco hardware. I am doing this to study for my CCNA. Thanks for any assistance you may provide. -Alex M -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Memory mapping for USBFS
This patch adds memory mapping support to USBFS for isochronous and bulk
data transfers, it allows to pre-allocate usb transfer buffers.
The CPU usage decreases 1-2% on my 1.3ghz U7300 notebook when
transferring 20mbyte/sec, it should be more interesting to see those
statistics on embedded systems where copying data is more expensive.
Usage from userspace:
allocation:
rv = ioctl(priv->usbfd, USBDEVFS_ALLOC_MEMORY, &mem);
if (rv == 0)
buffer = mmap(NULL, size, PROT_READ|PROT_WRITE,
MAP_SHARED, priv->usbfd, mem.offset);
use the mapped buffer with urb->buffer.
release:
rv = munmap(buffer, size);
memset(&mem, 0x0, sizeof(struct usbdevfs_memory));
mem.buffer = buffer;
rv = ioctl(priv->usbfd, USBDEVFS_RELEASE_MEMORY, &mem);
non freed memory buffers are collected and will be released when closing
the node.
I tested this patch with Bulk and Isochronous, with and without memory
mapping (applications which don't use mmap will just fall back to the
legacy mechanism).
Version 0.3:
* Removed comment
* Renamed USBDEVFS_FREE_MEMORY to USBDEVFS_ALLOC_MEMORY
* Clearing allocated memory
Signed-off-by: Markus Rechberger
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 737e3c1..584253b 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -69,6 +69,7 @@ struct dev_state {
spinlock_t lock;/* protects the async urb lists */
struct list_head async_pending;
struct list_head async_completed;
+ struct list_head memory_list;
wait_queue_head_t wait; /* wake up if a request completed */
unsigned int discsignr;
struct pid *disc_pid;
@@ -96,6 +97,16 @@ struct async {
u8 bulk_status;
};
+struct usb_memory {
+ struct list_head memlist;
+ int vma_use_count;
+ int usb_use_count;
+ u32 offset;
+ u32 size;
+ void *mem;
+ unsigned long vm_start;
+};
+
static bool usbfs_snoop;
module_param(usbfs_snoop, bool, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(usbfs_snoop, "true to log all usbfs traffic");
@@ -288,6 +299,9 @@ static struct async *alloc_async(unsigned int numisoframes)
static void free_async(struct async *as)
{
+ struct usb_memory *usbm = NULL, *usbm_iter;
+ unsigned long flags;
+ struct dev_state *ps = as->ps;
int i;
put_pid(as->pid);
@@ -297,8 +311,22 @@ static void free_async(struct async *as)
if (sg_page(&as->urb->sg[i]))
kfree(sg_virt(&as->urb->sg[i]));
}
+
+ spin_lock_irqsave(&ps->lock, flags);
+ list_for_each_entry(usbm_iter, &ps->memory_list, memlist) {
+ if (usbm_iter->mem == as->urb->transfer_buffer) {
+ usbm = usbm_iter;
+ break;
+ }
+ }
+ spin_unlock_irqrestore(&ps->lock, flags);
+
kfree(as->urb->sg);
- kfree(as->urb->transfer_buffer);
+ if (usbm == NULL)
+ kfree(as->urb->transfer_buffer);
+ else
+ usbm->usb_use_count--;
+
kfree(as->urb->setup_packet);
usb_free_urb(as->urb);
usbfs_decrease_memory_usage(as->mem_usage);
@@ -811,6 +839,7 @@ static int usbdev_open(struct inode *inode, struct file
*file)
INIT_LIST_HEAD(&ps->list);
INIT_LIST_HEAD(&ps->async_pending);
INIT_LIST_HEAD(&ps->async_completed);
+ INIT_LIST_HEAD(&ps->memory_list);
init_waitqueue_head(&ps->wait);
ps->discsignr = 0;
ps->disc_pid = get_pid(task_pid(current));
@@ -839,6 +868,8 @@ static int usbdev_release(struct inode *inode, struct file
*file)
struct dev_state *ps = file->private_data;
struct usb_device *dev = ps->dev;
unsigned int ifnum;
+ struct list_head *p, *q;
+ struct usb_memory *tmp;
struct async *as;
usb_lock_device(dev);
@@ -863,6 +894,14 @@ static int usbdev_release(struct inode *inode, struct file
*file)
free_async(as);
as = async_getcompleted(ps);
}
+
+ list_for_each_safe(p, q, &ps->memory_list) {
+ tmp = list_entry(p, struct usb_memory, memlist);
+ list_del(p);
+ if (tmp->mem)
+ free_pages_exact(tmp->mem, tmp->size);
+ kfree(tmp);
+ }
kfree(ps);
return 0;
}
@@ -1173,6 +1212,7 @@ static int proc_do_submiturb(struct dev_state *ps, struct
usbdevfs_urb *uurb,
struct usb_host_endpoint *ep;
struct async *as = NULL;
struct usb_ctrlrequest *dr = NULL;
+ struct usb_memory *usbm = NULL, *iter = NULL;
unsigned int u, totlen, isofrmlen;
int i, ret, is_in, num_sgs = 0, ifnum = -1;
void *buf;
@@ -1323,6 +1363,8 @@ static int proc_do_submiturb(struct dev_state *ps, struct
usbdevfs_urb *uurb,
goto error;
}
+
[PATCH] Remove VLAIS usage from gadget code - alternate patch
From: Mark Charlebois
The use of variable length arrays in structs (VLAIS) in the Linux Kernel code
precludes the use of compilers which don't implement VLAIS (for instance the
Clang compiler). This alternate patch calculates offsets into the kmalloc-ed
memory buffer using macros. The previous patch required multiple kmalloc and
kfree calls.
Signed-off-by: Mark Charlebois
Signed-off-by: Behan Webster
---
--- linux.orig/drivers/usb/gadget/f_fs.c
+++ linux/drivers/usb/gadget/f_fs.c
@@ -30,6 +30,21 @@
#define FUNCTIONFS_MAGIC 0xa647361 /* Chosen by a honest dice roll ;) */
+/* Variable Length Array Macros **/
+#define vla_struct(structname) size_t structname##__##next = 0
+#define vla_struct_size(structname) structname##__##next
+
+#define vla_item(structname, type, name, n) \
+ type * structname##_##name; \
+ size_t structname##_##name##__##offset = \
+ (structname##__##next + __alignof__(type) - 1) & \
+ ~(__alignof__(type) - 1); \
+ size_t structname##_##name##__##sz = n * sizeof(type); \
+ structname##__##next = structname##_##name##__##offset + \
+ structname##_##name##__##sz;
+
+#define vla_ptr(ptr,structname,name) structname##_##name = \
+ (__typeof__(structname##_##name))&ptr[structname##_##name##__##offset]
/* Debugging /
@@ -1909,30 +1924,38 @@
/* Allocate everything in one chunk so there's less maintenance. */
{
- struct {
- struct usb_gadget_strings *stringtabs[lang_count + 1];
- struct usb_gadget_strings stringtab[lang_count];
- struct usb_string strings[lang_count*(needed_count+1)];
- } *d;
unsigned i = 0;
+ vla_struct(d);
+ vla_item(d, struct usb_gadget_strings *, stringtabs,
+ lang_count + 1);
+ vla_item(d, struct usb_gadget_strings, stringtab, lang_count);
+ vla_item(d, struct usb_string, strings,
+ lang_count*(needed_count+1));
+
+ char *vlabuf = kmalloc(vla_struct_size(d), GFP_KERNEL);
- d = kmalloc(sizeof *d, GFP_KERNEL);
- if (unlikely(!d)) {
+ if (unlikely(!vlabuf)) {
kfree(_data);
return -ENOMEM;
}
- stringtabs = d->stringtabs;
- t = d->stringtab;
+ /* Initialize the VLA pointers */
+ vla_ptr(vlabuf, d, stringtabs);
+ vla_ptr(vlabuf, d, stringtab);
+ vla_ptr(vlabuf, d, strings);
+
+ stringtabs = d_stringtabs;
+ t = d_stringtab;
i = lang_count;
do {
*stringtabs++ = t++;
} while (--i);
*stringtabs = NULL;
- stringtabs = d->stringtabs;
- t = d->stringtab;
- s = d->strings;
+ /* stringtabs = vlabuf = d_stringtabs for later free */
+ stringtabs = d_stringtabs;
+ t = d_stringtab;
+ s = d_strings;
strings = s;
}
@@ -2208,16 +2231,15 @@
int ret;
/* Make it a single chunk, less management later on */
- struct {
- struct ffs_ep eps[ffs->eps_count];
- struct usb_descriptor_header
- *fs_descs[full ? ffs->fs_descs_count + 1 : 0];
- struct usb_descriptor_header
- *hs_descs[high ? ffs->hs_descs_count + 1 : 0];
- short inums[ffs->interfaces_count];
- char raw_descs[high ? ffs->raw_descs_length
- : ffs->raw_fs_descs_length];
- } *data;
+ vla_struct(d);
+ vla_item(d, struct ffs_ep, eps, ffs->eps_count);
+ vla_item(d, struct usb_descriptor_header *, fs_descs,
+ full ? ffs->fs_descs_count + 1 : 0);
+ vla_item(d, struct usb_descriptor_header *, hs_descs,
+ high ? ffs->hs_descs_count + 1 : 0);
+ vla_item(d, short, inums, ffs->interfaces_count);
+ vla_item(d, char, raw_descs,
+ high ? ffs->raw_descs_length : ffs->raw_fs_descs_length);
ENTER();
@@ -2225,21 +2247,30 @@
if (unlikely(!(full | high)))
return -ENOTSUPP;
- /* Allocate */
- data = kmalloc(sizeof *data, GFP_KERNEL);
- if (unlikely(!data))
+ /* Allocate a single chunk, less management later on */
+ char *vlabuf = kmalloc(vla_struct_size(d), GFP_KERNEL);
+ if (unlikely(!vlabuf))
return -ENOMEM;
+ /* Initialize each struct member pointer in the allocated memory */
+ vla_ptr(vlabuf, d, eps);
+ vla_ptr(vlabuf, d, fs_descs);
+ vl
Re: [PATCH v3 1/2] staging: dwc2: validate urb->actual_length for OUT endpoints
Hi, On Mon, Sep 23, 2013 at 09:53:49PM +, Paul Zimmerman wrote: > > From: Felipe Balbi [mailto:ba...@ti.com] > > Sent: Monday, September 23, 2013 2:45 PM > > > > On Mon, Sep 23, 2013 at 02:23:33PM -0700, Paul Zimmerman wrote: > > > In dwc2_assign_and_init_hc(), validate urb->actual_length for OUT > > > endpoints before using the value. This fix is from the Synopsys > > > vendor driver. > > > > > > Signed-off-by: Paul Zimmerman > > > --- > > > drivers/staging/dwc2/hcd.c | 4 > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/drivers/staging/dwc2/hcd.c b/drivers/staging/dwc2/hcd.c > > > index da0d35c..b245405 100644 > > > --- a/drivers/staging/dwc2/hcd.c > > > +++ b/drivers/staging/dwc2/hcd.c > > > @@ -780,6 +780,10 @@ static void dwc2_assign_and_init_hc(struct > > > dwc2_hsotg *hsotg, > > > chan->data_pid_start = qh->data_toggle; > > > chan->multi_count = 1; > > > > > > + if ((urb->actual_length < 0 || urb->actual_length > urb->length) && > > > + !dwc2_hcd_is_pipe_in(&urb->pipe_info)) > > > + urb->actual_length = urb->length; > > > > weird, why would actual_length be less than zero or greather than > > urb->length ? I guess you need some more "meat" in your commit log. > > I assume it was to fix some issue seen by our developers. We don't have > detailed commit logs for that driver, so I am unable to say for certain. > But since it is part of the downstream RaspberryPi driver, which has > seen a lot of testing, I thought it best to include it. Maybe RPi folks can give some details ? Because I really wonder if we'd not be masking a bug somewhere else and this would make it a lot harder to pin-point that bug. -- balbi signature.asc Description: Digital signature
Re: Cannot load snd-usb-audio on 3.12-rc2
Hi Sarah, On 24.09.2013 01:41, Sarah Sharp wrote: > The snd-usb-audio driver no longer loads properly on 3.12-rc2 when I > plug in my USB headset. It worked fine on 3.11-rc4 (not sure about > vanilla 3.11). > > Trying to manually load the driver fails: > > sarah@xanatos:~$ sudo modprobe snd-usb-audio > FATAL: Error inserting snd_usb_audio > (/lib/modules/3.12.0-rc2/kernel/sound/usb/snd-usb-audio.ko): Invalid argument > > dmesg shows: > > [ 44.231668] snd_usb_audio: `-2' invalid for parameter `index' That's really strange. I just tested on an ARM board where I currently run 3.12-rc2 as well, and I can load the module without problems. Also, sound/usb/card.c (where the params are declared) hasn't seen an update in 3.12. I suspect your OS is passing "index=-2" from something like /etc/modprobe.d/* or cmdline settings. Could you investigate in that direction? HTH, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: EHCI bus glue driver works for storage, fails for a WiFi module
On Mon, 23 Sep 2013, Arokux X wrote: > Hi, > > recently I was working on porting EHCI HCD bus glue driver from the > vendors kernel tree to the mainline [1]. I've got the storage (USB > stick and USB external hard drive) working and was happy. However it > does not work completely. Specifically something goes wrong if WiFi > module is talked to. This WiFi module is on-board and connected > through USB. The WiFi module is correctly identified and the rtl8192cu > driver manages to output something, but issuing > > ip link set wlan0 up > > will cause an error, see the output of the dmesg [2]. > > Note, the same hardware works with vendor's tree EHCI bus glue driver > and rtl8192cu, so hardware is ok. > > Maybe using a fact that my driver works for the storage but fails for > the WiFi module you could help me identify the problem in it? Nope. Not without comparing it to the vendor's driver. > By the way, the output of the lsusb - looks identical in both > cases (with my driver and vendor's) [3]. One problem is the part of the patch that changes ehci-hcd.c. That hunk should be removed (it caused the "Error: Driver 'sunxi-ehci' is already registered, aborting..." message at timestamp 0.781332 in your log). If usb_add_hcd() fails, you don't call sunxi_ehci_disable(). There's another problem in sunxi_ehci_remove(). The routine accesses sunxi_ehci after it has been deallocated by the call to usb_put_hcd(). The line where sunxi_ehci_init_module() assigns a string to sunxi_ehci_hc_driver.product_desc should be removed. What is the meaning of the "FIXME: Should there be two of those?" comment on line 215? Two of what? Why does the sunxi_ehci_hcd structure contain an "hcd" member? This member is used in only one function, and you could easily pass it as a function argument instead. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some questions about ehci period scheduling
On Tue, 24 Sep 2013, vichy wrote:
> hi Alan:
> > > BTW, I have another question about iso_stream_schedule.
> > > When if (likely (!list_empty (&stream->td_list))) happen,
> > > why don't we just take last scheduled microframe, stream->next_uframe
> > > as start point directly?
> >
> > We do exactly that if URB_ISO_ASAP isn't set. But first the routine
> > has to check and see if the schedule is already full, and it prints a
> > debugging message if all the assigned microframes have already expired.
> Does below source show us what you mean?
> if (unlikely(start < period)) {
> ehci_dbg(ehci, "iso sched full %p (%u-%u < %u mod %u)\n",
> urb, stream->next_uframe, base,
> period, mod);
> status = -ENOSPC;
> goto fail;
> }
That's the first part (checking if the schedule is already full).
This is the second part (printing a debug message if all the assigned
microframes have already expired):
/*
* Not ASAP: Use the next slot in the stream,
* no matter what.
*/
else if (start + span - period < now2) {
ehci_dbg(ehci, "iso underrun %p (%u+%u < %u)\n",
urb, start + base,
span - period, now2 + base);
}
> if so, I have one question, why we use ( (last scan frame and last
> schedule frame) < end point interval) to determine schedule is full?
If start < period, it means that the last packet on the schedule (which
is assigned to uframe start - period) comes before base. The only way
this can happen is if the packets occupy the entire schedule and wrap
around.
If you think about a few examples, you'll understand. Suppose the
endpoint's interval is 8 uframes, starting from uframe 3. Suppose base
is 500, and suppose the schedule really is full. Then there will be
packets scheduled for uframes 507, 515, ..., 8187, 3, 11, ..., 491, 499
(note that 499 is slightly before 500), and stream->next_uframe will be
507. So start will be set to (507 - 500) & 8191 = 7. The fact that 7
< 8 indicates the schedule is full.
Now suppose everything else is the same, but the schedule isn't
completely full. For this example, let's suppose the last scheduled
packet is in uframe 491, so stream->next_uframe is equal to 499. Then
start will be set to (499 - 500) & 8191 = 8191. The fact that 8191 >=
8 indicates the schedule isn't full.
Consider one more example: Everything else is the same, but there's
only one packet in the schedule. It is assigned to uframe 507, and
stream->next_uframe is 515. Then start will be set to (515 - 500) &
8191 = 15, and the fact that 15 >= 8 indicates the schedule isn't full.
Does this help?
> Below is where we handle URB_ISO_ASAP,
> if (urb->transfer_flags & URB_ISO_ASAP)
> start += (next - start + period - 1) & -period;
>
> Why don't we just use start as next?
If start < next then we don't want to use it. Packets scheduled before
next might not be seen by the hardware, because of the isochronous
scheduling threshold (see section 4.7.2.1 in the EHCI spec).
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/2] usb: implement AMD remote wakeup quirk
On Tue, 24 Sep 2013, Huang Rui wrote: > Hi Sarah and Alan, > > On Mon, Sep 23, 2013 at 05:14:02PM -0700, Sarah Sharp wrote: > > On Mon, Sep 23, 2013 at 12:43:15PM -0400, Alan Stern wrote: > > > This version of the patch set looks good. > > > > > > Alan Stern > > > > Looks fine to me as well. > > > > Acked-by: Sarah Sharp > > > > Thank you for acked-by :) > Would I better use new chipset type intead of filtering with revision > by hand for special generation in old AMD xhci/ehci/ohci quirks. If > OK, I will do this work after the quirk is applied. I think the patch is probably okay as it stands. The chipset type and revision values in the code should match the names chosen by the manufacturer. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] usb: hub_activate kill an 'else'
On Mon, 23 Sep 2013, Dan Williams wrote:
> Remove a few extra lines and make it clear that all implementations
> disable the port by sharing the same line of code.
>
> Cc: Alan Stern
> Signed-off-by: Dan Williams
> ---
> drivers/usb/core/hub.c | 11 ---
> 1 files changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 5d859fc..69bbb51 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1107,16 +1107,13 @@ static void hub_activate(struct usb_hub *hub, enum
> hub_activation_type type)
> /*
>* USB3 protocol ports will automatically transition
>* to Enabled state when detect an USB3.0 device attach.
> - * Do not disable USB3 protocol ports.
> + * Do not disable USB3 protocol ports, just pretend
> + * power was lost
>*/
> - if (!hub_is_superspeed(hdev)) {
> + portstatus &= ~USB_PORT_STAT_ENABLE;
> + if (!hub_is_superspeed(hdev))
> usb_clear_port_feature(hdev, port1,
> USB_PORT_FEAT_ENABLE);
> - portstatus &= ~USB_PORT_STAT_ENABLE;
> - } else {
> - /* Pretend that power was lost for USB3 devs */
> - portstatus &= ~USB_PORT_STAT_ENABLE;
> - }
> }
>
> /* Clear status-change flags; we'll debounce later */
Acked-by: Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] usb: xhci: change enumeration scheme to 'new scheme' by default
On Mon, 23 Sep 2013, Dan Williams wrote: > Change the enumeration scheme for xhci attached devices from: > >SetAddress >GetDescriptor(8) >GetDescriptor(18) > > ...to: > >GetDescriptor(64) >SetAddress >GetDescriptor(18) > > ...as some devices misbehave when encountering a SetAddress command > prior to GetDescriptor. There are known devices that require this > enumeration scheme but is unknown how much, if any, regression there > will be of xhci-attached devices that can not tolerate the change. For > now, follow the ehci case and enable 'new scheme' by default. Of course > the existing 'old_scheme_first' and 'use_both_schemes' usbcore module > parameters are available to debug / workaround regressions. > > To support this enumeration scheme on xhci the AddressDevice operation > needs to be performed twice. The first instance of the command enables > the HC's device and slot context info for the device, but omits sending > the device a SetAddress command (BSR == block set address request). > Then, after GetDescriptor completes, follow up with the full > AddressDevice+SetAddress operation. > > Reported-by: David Moore > Suggested-by: Sarah Sharp > Signed-off-by: Dan Williams The usbcore parts look okay to me. Did you test this to make sure the GetDescriptor(64) request is sent to address 0 properly? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ehci-pci D3cold logspam
On Mon, 23 Sep 2013, Bjorn Helgaas wrote:
> d010e5769 ("PCI / ACPI: Use dev_dbg() instead of dev_info() in
> acpi_pci_set_power_state()") might be part of the solution. That was
> done in response to https://bugzilla.kernel.org/show_bug.cgi?id=60636,
> which looks basically the same as your complaint.
>
> But if we are indeed polling every two seconds, even a dev_dbg() seems
> like overkill to me. Rafael or Lan can probably provide a better
> answer here.
>
> As for the "setting latency timer" messages, I really doubt those are
> useful to anybody. If nobody objects, I'll just drop it, e.g.:
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b821a62..55a947b 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2854,7 +2854,7 @@ void __weak pcibios_set_master(struct pci_dev *dev)
> lat = pcibios_max_latency;
> else
> return;
> - dev_printk(KERN_DEBUG, &dev->dev, "setting latency timer to %d\n",
> lat);
> +
> pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
> }
No objection from me.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb/core/devio.c: Don't reject control message to endpoint with wrong direction bit
Hi,
this has been discussed on linux-usb and Alan Stern provided very
helpful feedback.
Please merge this patch ...
From: Kurt Garloff
Date: Mon, 23 Sep 2013 14:19:02 +0200
Subject: Tolerate wrong direction bit in endpoint address for control messages
Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101)
[1] with the Windows App (EasyNote) works natively but fails when
Windows is running under KVM (and the USB device handed to KVM).
The reason is a USB control message
usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001
wLength=0008
This goes to endpoint address 0x01 (wIndex); however, endpoint address
0x01 does not exist. There is an endpoint 0x81 though (same number,
but other direction); the app may have meant that endpoint instead.
The kernel thus rejects the IO and thus we see the failure.
Apparently, Linux is more strict here than Windows ... we can't change
the Win app easily, so that's a problem.
It seems that the Win app/driver is buggy here and the driver does not
behave fully according to the USB HID class spec that it claims to
belong to. The device seems to happily deal with that though (and
seems to not really care about this value much).
So the question is whether the Linux kernel should filter here.
Rejecting has the risk that somewhat non-compliant userspace apps/
drivers (most likely in a virtual machine) are prevented from working.
Not rejecting has the risk of confusing an overly sensitive device with
such a transfer. Given the fact that Windows does not filter it makes
this risk rather small though.
The patch makes the kernel more tolerant: If the endpoint address in
wIndex does not exist, but an endpoint with toggled direction bit does,
it will let the transfer through. (It does NOT change the message.)
With attached patch, the app in Windows in KVM works.
usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but
needs 81
I suspect this will mostly affect apps in virtual environments; as on
Linux the apps would have been adapted to the stricter handling of the
kernel. I have done that for mine[2].
[1] http://www.pegatech.com/
[2] https://sourceforge.net/projects/notetakerpen/
Signed-off-by: Kurt Garloff
Acked-by: Alan Stern
Cc: sta...@vger.kernel.org
---
drivers/usb/core/devio.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 737e3c1..71dc5d7 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -742,6 +742,22 @@ static int check_ctrlrecip(struct dev_state *ps, unsigned
int requesttype,
if ((index & ~USB_DIR_IN) == 0)
return 0;
ret = findintfep(ps->dev, index);
+ if (ret < 0) {
+ /*
+* Some not fully compliant Win apps seem to get
+* index wrong and have the endpoint number here
+* rather than the endpoint address (with the
+* correct direction). Win does let this through,
+* so we'll not reject it here but leave it to
+* the device to not break KVM. But we warn.
+*/
+ ret = findintfep(ps->dev, index ^ 0x80);
+ if (ret >= 0)
+ dev_info(&ps->dev->dev,
+ "%s: process %i (%s) requesting ep %02x
but needs %02x\n",
+ __func__, task_pid_nr(current),
+ current->comm, index, index ^ 0x80);
+ }
if (ret >= 0)
ret = checkintf(ps, ret);
break;
--
Kurt Garloff [Koeln, Germany]
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hid-elo: some systems cannot stomach work around
On Mon, 9 Sep 2013, oli...@neukum.org wrote:
> From: Oliver Neukum
>
> Some systems although they have firmware class 'M', which usually
> needs a work around to not crash, must not be subjected to the
> work around because the work around crashes them. They cannot be
> told apart by their own device descriptor, but as they are part
> of compound devices can be identified by looking at their siblings.
What a mess ... :/
>
> Signed-off-by: Oliver Neukum
> ---
> drivers/hid/hid-elo.c | 35 ++-
> 1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-elo.c b/drivers/hid/hid-elo.c
> index f042a6c..64ac53e 100644
> --- a/drivers/hid/hid-elo.c
> +++ b/drivers/hid/hid-elo.c
> @@ -181,7 +181,40 @@ fail:
> */
> static bool elo_broken_firmware(struct usb_device *dev)
> {
> - return use_fw_quirk && le16_to_cpu(dev->descriptor.bcdDevice) == 0x10d;
> + struct usb_device *hub = dev->parent;
> + struct usb_device *child = NULL;
> + u16 fw_lvl = le16_to_cpu(dev->descriptor.bcdDevice);
> + u16 child_vid, child_pid;
> + int i;
> +
> + if (!use_fw_quirk)
> + return false;
> + if (fw_lvl != 0x10d)
> + return false;
> +
> + /*iterate sibling devices of the touch controller*/
Could you please resubmit with comment reformated (spaces before/after
asterisk)?
> + usb_hub_for_each_child(hub, i, child) {
> + child_vid = le16_to_cpu(child->descriptor.idVendor);
> + child_pid = le16_to_cpu(child->descriptor.idProduct);
> +
> + /*
> + * If one of the devices below is present attached as a sibling
> of
> + * the touch controller then this is a newer IBM 4820 monitor
> that
> + * does not need the IBM-requested workaround if fw level is
> + * 0x010d - aka 'M'.
> + * No other HW can have this combination.
> + */
> + if (child_vid==0x04b3) {
> + switch (child_pid) {
> + case 0x4676: /*4820 21x Video*/
> + case 0x4677: /*4820 51x Video*/
> + case 0x4678: /*4820 2Lx Video*/
> + case 0x4679: /*4820 5Lx Video*/
Here as well.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] USB: gadget: s3c-hsotg: add isochronous transfers support
Hello,
This is update for my proposal for isochronous transfers support in s3c-hsotg
driver. I've fixed issuses pointed by Bartlomiej Zolnierkiewicz. For more
information, please check the change log at the end of the mail.
This patch adds isochronous transfer support. It adds few modifications:
- Modify s3c_hsotg_write_fifo() function. It actually calculates transfer
size, taking into account Multi Count value, which indicates number of
transactions per microframe.
- Fix s3c_hsotg_start_req() function by setting number of packets to Multi
Count field in DIEPTSIZ register for isochronous endpoints.
- Fix s3c_hsotg_set_ep_maxpacket() function. Field wMaxPacketSize of endpoint
descriptor is now splitted into maximum packet size value and number of
additional transaction per microframe.
- Modify s3c_hsotg_epint() function. Some interrupts are ignored for
isochronous endpoints, (e.g. INTknTXFEmpMsk) becouse isochronous request is
always transfered in single transaction, which ends with XferCompl interrupt.
Add Odd/Even microframe toggle to allow data transfering in each microframe.
- Fix s3c_hsotg_ep_enable() function by supporting isochronous endpoint type.
Signed-off-by: Robert Baldyga
Signed-off-by: Kyungmin Park
Changelog:
v2:
- moved bugfix affecting to the other features to separated patch
- changed conditions order in request length checking in s3c_hsotg_start_req
function, as Bartlomiej Zolnierkiewicz suggested
- fixed typos
v1: https://lkml.org/lkml/2013/9/23/72
- initial proposal
---
drivers/usb/gadget/s3c-hsotg.c | 72 +++-
1 file changed, 56 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index 2b9c446..ded9cb4 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -82,9 +82,12 @@ struct s3c_hsotg_req;
* @dir_in: Set to true if this endpoint is of the IN direction, which
* means that it is sending data to the Host.
* @index: The index for the endpoint registers.
+ * @mc: Multi Count - number of transactions per microframe
+ * @interval - Interval for periodic endpoints
* @name: The name array passed to the USB core.
* @halted: Set if the endpoint has been halted.
* @periodic: Set if this is a periodic ep, such as Interrupt
+ * @isochronous: Set if this is a isochronous ep
* @sent_zlp: Set if we've sent a zero-length packet.
* @total_data: The total number of data bytes done.
* @fifo_size: The size of the FIFO (for periodic IN endpoints)
@@ -120,9 +123,12 @@ struct s3c_hsotg_ep {
unsigned char dir_in;
unsigned char index;
+ unsigned char mc;
+ unsigned char interval;
unsigned inthalted:1;
unsigned intperiodic:1;
+ unsigned intisochronous:1;
unsigned intsent_zlp:1;
charname[10];
@@ -467,6 +473,7 @@ static int s3c_hsotg_write_fifo(struct s3c_hsotg *hsotg,
void *data;
int can_write;
int pkt_round;
+ int max_transfer;
to_write -= (buf_pos - hs_ep->last_load);
@@ -534,8 +541,10 @@ static int s3c_hsotg_write_fifo(struct s3c_hsotg *hsotg,
can_write *= 4; /* fifo size is in 32bit quantities. */
}
- dev_dbg(hsotg->dev, "%s: GNPTXSTS=%08x, can=%d, to=%d, mps %d\n",
-__func__, gnptxsts, can_write, to_write, hs_ep->ep.maxpacket);
+ max_transfer = hs_ep->ep.maxpacket * hs_ep->mc;
+
+ dev_dbg(hsotg->dev, "%s: GNPTXSTS=%08x, can=%d, to=%d, max_transfer
%d\n",
+__func__, gnptxsts, can_write, to_write, max_transfer);
/*
* limit to 512 bytes of data, it seems at least on the non-periodic
@@ -550,8 +559,8 @@ static int s3c_hsotg_write_fifo(struct s3c_hsotg *hsotg,
* the transfer to return that it did not run out of fifo space
* doing it.
*/
- if (to_write > hs_ep->ep.maxpacket) {
- to_write = hs_ep->ep.maxpacket;
+ if (to_write > max_transfer) {
+ to_write = max_transfer;
/* it's needed only when we do not use dedicated fifos */
if (!hsotg->dedicated_fifos)
@@ -564,7 +573,7 @@ static int s3c_hsotg_write_fifo(struct s3c_hsotg *hsotg,
if (to_write > can_write) {
to_write = can_write;
- pkt_round = to_write % hs_ep->ep.maxpacket;
+ pkt_round = to_write % max_transfer;
/*
* Round the write down to an
@@ -730,8 +739,16 @@ static void s3c_hsotg_start_req(struct s3c_hsotg *hsotg,
else
packets = 1;/* send one packet if length is zero. */
+ if (hs_ep->isochronous && length > (hs_ep->mc * hs_ep->ep.maxpacket)) {
+ dev_err(hsotg->dev, "req length > maxpacket*mc\n");
+ return;
+ }
+
USB/IP: sharing USB device disappearing at client side
Hi, On KVM platform, I try to share an USB Mass Storage device from On host SUSE11SP2/usbip 1.1.1 (linux-3.11.1-stable)server to another host SUSE11SP2/usbip 1.1.1 client, creation of tunnel is successful: the drive shows up in lsusb on client. When I attach the usb device to a VM on the client side, the following error occurs on the client host side, with no new messages by usbipd on server side: Cannot enable port 1. Maybe the USB cable is bad? [repeat ...] unable to enumerate USB device on port 1 ...and the drive disappears from lsusb on client side. Here is key log: The Server: linux-xAuOMu:# usbip list -l Local USB devices = - busid 1-1 (12d1:0003) Huawei Technologies Co., Ltd. : unknown product (12d1:0003) 1-1:1.0 -> usbhid 1-1:1.1 -> usbhid - busid 6-1 (0951:1642) Kingston Technology : unknown product (0951:1642) 6-1:1.0 -> usbip-host - busid 6-2 (18a5:0302) Verbatim, Ltd : unknown product (18a5:0302) 6-2:1.0 -> usb-storage - busid 7-1 (0951:1642) Kingston Technology : unknown product (0951:1642) 7-1:1.0 -> usb-storage The Client: linux-166:# usbip list -l Local USB devices = - busid 1-1 (12d1:0003) Huawei Technologies Co., Ltd. : unknown product (12d1:0003) 1-1:1.0 -> usbhid 1-1:1.1 -> usbhid - busid 7-1 (0951:1642) Kingston Technology : unknown product (0951:1642) 7-1:1.0 -> usb-storage linux-166:# virsh attach-device suse usb.xml Device attached successfully linux-166:# cat usb.xml Dmesg log : [13603.742271] vhci_hcd vhci_hcd: USB/IP Virtual Host Controller [13603.742278] vhci_hcd vhci_hcd: new USB bus registered, assigned bus number 7 [13603.743117] usb usb7: New USB device found, idVendor=1d6b, idProduct=0002 [13603.743122] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [13603.743126] usb usb7: Product: USB/IP Virtual Host Controller [13603.743129] usb usb7: Manufacturer: Linux 3.11.1-0.27-default vhci_hcd [13603.743132] usb usb7: SerialNumber: vhci_hcd [13603.743407] hub 7-0:1.0: USB hub found [13603.743418] hub 7-0:1.0: 8 ports detected [13603.743699] vhci_hcd: USB/IP 'Virtual' Host Controller (VHCI) Driver v1.0.0 [13603.842177] vhci_hcd: changed 0 [13712.269544] vhci_hcd vhci_hcd: rhport(0) sockfd(3) devid(393218) speed(3) [13712.269960] vhci_hcd: changed 1 [13712.377570] vhci_hcd: changed 0 [13712.485620] usb 7-1: new high-speed USB device number 2 using vhci_hcd [13712.709569] usb 7-1: new high-speed USB device number 3 using vhci_hcd [13712.933515] usb 7-1: new high-speed USB device number 4 using vhci_hcd [13712.933521] usb 7-1: SetAddress Request (4) to port 0 [13712.954506] usb 7-1: New USB device found, idVendor=0951, idProduct=1642 [13712.954511] usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [13712.954514] usb 7-1: Product: DT 101 G2 [13712.954517] usb 7-1: Manufacturer: KINGSTON [13712.954520] usb 7-1: SerialNumber: 001CC05FE92EAC70B9246527 [13712.955497] usb-storage 7-1:1.0: USB Mass Storage device detected [13712.955919] scsi8 : usb-storage 7-1:1.0 [13713.964778] scsi 8:0:0:0: Direct-Access KINGSTON DT 101 G21.00 PQ: 0 ANSI: 4 [13713.965125] sd 8:0:0:0: Attached scsi generic sg1 type 0 [13713.967811] sd 8:0:0:0: [sdb] 15400960 512-byte logical blocks: (7.88 GB/7.34 GiB) [13713.970983] sd 8:0:0:0: [sdb] Write Protect is off [13713.970988] sd 8:0:0:0: [sdb] Mode Sense: 2f 00 00 00 [13713.973986] sd 8:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [13713.986227] sdb: [13713.997454] sd 8:0:0:0: [sdb] Attached SCSI removable disk ... ... [13547.998718] vhci_hcd: changed 1 [13548.002628] vhci_hcd: changed 0 [13541.896080] hub 7-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [13542.767879] hub 7-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [13543.639684] hub 7-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [13544.511484] hub 7-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [13544.511492] hub 7-0:1.0: unable to enumerate USB device on port 1 [13544.511508] vhci_hcd: changed 1 [13544.515415] vhci_hcd: changed 0 [13545.383295] hub 7-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [13546.255099] hub 7-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [13547.126898] hub 7-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [13547.998693] hub 7-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [13547.998702] hub 7-0:1.0: unable to enumerate USB device on port 1 The USB device vanishes from the client side: linux-166:# usbip list -l Local USB devices = - busid 1-1 (12d1:0003) Huawei Technologies Co., Ltd. : unknown product (12d1:0003) 1-1:1.0 -> usbhid 1-1:1.1 -> usbhid And I try the linux-3.12-rc2 on both server and client, but the problem remain. Anyone have any ideas? Thanks in
Re: [PATCH v2 1/1] usb: gadget: f_fs: Add support for SuperSpeed Mode
Hi Felipe,
I wanted to mention one point with respect to this patch:
Below changes in the functionfs.h to add ss_count (super speed
descriptors count) in desc_header (which is passed from userspace) make
the driver incompatible with existing userspace applications compiled
against old header file. Let me know if that is acceptable.
We are using this driver with Android for adbd (android debug bridge)
and these changes are required to support adb over Super Speed
controllers e.g. DWC3 along with changed in adbd to pass SS EP and
companion descriptors.
Regards,
Manu
On 9/20/2013 5:25 PM, Manu Gautam wrote:
diff --git a/include/uapi/linux/usb/functionfs.h
b/include/uapi/linux/usb/functionfs.h
index d6b0128..d6940d7 100644
--- a/include/uapi/linux/usb/functionfs.h
+++ b/include/uapi/linux/usb/functionfs.h
@@ -37,6 +37,7 @@ struct usb_functionfs_descs_head {
__le32 length;
__le32 fs_count;
__le32 hs_count;
+ __le32 ss_count;
} __attribute__((packed));
/*
@@ -48,8 +49,10 @@ struct usb_functionfs_descs_head {
* | 4 | length| LE32 | length of the whole data chunk |
* | 8 | fs_count | LE32 | number of full-speed descriptors |
* | 12 | hs_count | LE32 | number of high-speed descriptors |
- * | 16 | fs_descrs | Descriptor[] | list of full-speed descriptors |
+ * | 16 | ss_count | LE32 | number of super-speed descriptors|
+ * | 20 | fs_descrs | Descriptor[] | list of full-speed descriptors |
* | | hs_descrs | Descriptor[] | list of high-speed descriptors |
+ * | | ss_descrs | Descriptor[] | list of super-speed descriptors |
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: gadget: s3c-hsotg: fix can_write limit for non-periodic endpoints
Value of can_write variable in s3c_hsotg_write_fifo function should be limited to 512 only for non-periodic endpoints. There was some discrepancy between comment and code, becouse comment suggests correct behavior, but in the code limit was applied to periodic endpoints too. So there is additional check causing the limitation concerns only non-periodic endpoints. Signed-off-by: Robert Baldyga Signed-off-by: Kyungmin Park --- drivers/usb/gadget/s3c-hsotg.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) I have found one small bug in s3c_hsotg_write_fifo function which doesn't allow to perform transfers greater than 512 bytes. diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c index d5d951d..2b9c446 100644 --- a/drivers/usb/gadget/s3c-hsotg.c +++ b/drivers/usb/gadget/s3c-hsotg.c @@ -542,7 +542,7 @@ static int s3c_hsotg_write_fifo(struct s3c_hsotg *hsotg, * FIFO, requests of >512 cause the endpoint to get stuck with a * fragment of the end of the transfer in it. */ - if (can_write > 512) + if (can_write > 512 && !periodic) can_write = 512; /* -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 00/10] USB: phy: phy-nop: Manage RESET GPIO in the driver
Hi, Modelling the RESET line as a regulator supply wasn't a good idea as it abuses the regulator framework and makes adaptation code/data more complex. Instead, manage the RESET gpio line directly in the driver. This also makes us easy to migrate to a dedicated GPIO RESET controller whenever it becomes available. Apart from RESET line changes this series also adds USB host support fro beagle-xm and fixes USB OTG port on beagle. The full series is avilable at git://github.com/rogerq/linux.git in branch phy-reset *NOTE:* As there are changes to platform data, Patch 1 needs to be shared between the arm-soc tree and usb tree. Patch 1 is available at repo git://github.com/rogerq/linux.git in branch phy-reset-common Patch 2 contains the phy-nop driver changes Patches 3 and 4 adapt legacy boot code to the phy-nop driver changes. Patches 5, 6 and 7 adapt DT data to the binding changes. Patch 8 is cleanup of omap3-beagle DT. Patch 9 adds USB host support to omap3-beagle-xm using the new binding. Patch 10 fixes USB OTG port on beagle. Patches are based on v3.12-rc1 Tested leacy boot on omap3-beagle and omap3-beagle-xm Tested DT boot on omap3-beagle, omap3-beagle-xm and omap4-panda-es v3: - Fix the Initial state of RESET line at probe time. - Update hsusb3_reset line on omap5-uevm as well. - Add patch 10 that fixes USB OTG port on beagle. v2: - Added RESET GPIO polarity feature - Changed to gpio_set_value_cansleep() cheers, -roger Roger Quadros (10): usb: phy: generic: Add gpio_reset to platform data usb: phy: generic: Don't use regulator framework for RESET line ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct usbhs_phy_data ARM: OMAP2+: usb-host: Adapt to USB phy-nop RESET line changes ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset ARM: dts: omap4-panda: Use reset-gpios for hsusb1_reset ARM: dts: omap5-uevm: Use reset-gpios for hsusb2/3_reset ARM: dts: omap3-beagle: Make USB host pin naming consistent ARM: dts: omap3-beagle-xm: Add USB Host support ARM: dts: omap3-beagle: Add USB OTG PHY details .../devicetree/bindings/usb/usb-nop-xceiv.txt |7 +- arch/arm/boot/dts/omap3-beagle-xm.dts | 65 +-- arch/arm/boot/dts/omap3-beagle.dts | 44 +-- arch/arm/boot/dts/omap4-panda-common.dtsi | 18 + arch/arm/boot/dts/omap5-uevm.dts | 26 +-- arch/arm/mach-omap2/board-omap3beagle.c|6 -- arch/arm/mach-omap2/usb-host.c | 18 ++-- arch/arm/mach-omap2/usb.h |1 - drivers/usb/phy/phy-am335x.c |2 +- drivers/usb/phy/phy-generic.c | 84 +--- drivers/usb/phy/phy-generic.h |6 +- include/linux/usb/usb_phy_gen_xceiv.h |3 +- 12 files changed, 153 insertions(+), 127 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 05/10] ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts "reset-gpios" property.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index dfd8310..71bde47 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -44,17 +44,6 @@
};
};
- /* HS USB Port 2 RESET */
- hsusb2_reset: hsusb2_reset_reg {
- compatible = "regulator-fixed";
- regulator-name = "hsusb2_reset";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- gpio = <&gpio5 19 0>; /* gpio_147 */
- startup-delay-us = <7>;
- enable-active-high;
- };
-
/* HS USB Port 2 Power */
hsusb2_power: hsusb2_power_reg {
compatible = "regulator-fixed";
@@ -68,7 +57,7 @@
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
- reset-supply = <&hsusb2_reset>;
+ reset-gpios = <&gpio5 19 GPIO_ACTIVE_LOW>; /* gpio_147 */
vcc-supply = <&hsusb2_power>;
};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 10/10] ARM: dts: omap3-beagle: Add USB OTG PHY details
Add information about the USB OTG PHY. Without this
the OTG port on beagle will not work.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 1237822..7669c16 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -169,3 +169,10 @@
pinctrl-names = "default";
pinctrl-0 = <&gpio1_pins>;
};
+
+&usb_otg_hs {
+ interface-type = <0>;
+ usb-phy = <&usb2_phy>;
+ mode = <3>;
+ power = <50>;
+};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 08/10] ARM: dts: omap3-beagle: Make USB host pin naming consistent
Use a common naming scheme "mode0name.modename flags" for the
USB host pins to be consistent.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 71bde47..1237822 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -90,18 +90,18 @@
hsusbb2_pins: pinmux_hsusbb2_pins {
pinctrl-single,pins = <
- 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_clk */
- 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_stp */
- 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dir */
- 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_nxt */
- 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat0 */
- 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat1 */
- 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat2 */
- 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat3 */
- 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat4 */
- 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat5 */
- 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat6 */
- 0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat7 */
+ 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
+ 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
+ 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d12.hsusb2_dir */
+ 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d13.hsusb2_nxt */
+ 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d14.hsusb2_data0 */
+ 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d15.hsusb2_data1 */
+ 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi1_cs3.hsusb2_data2 */
+ 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_clk.hsusb2_data7 */
+ 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_simo.hsusb2_data4 */
+ 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_somi.hsusb2_data5 */
+ 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs0.hsusb2_data6 */
+ 0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs1.hsusb2_data3 */
>;
};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 06/10] ARM: dts: omap4-panda: Use reset-gpios for hsusb1_reset
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts "reset-gpios" property.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 18 +-
1 files changed, 1 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..c60ebd0 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -60,22 +60,6 @@
"AFMR", "Line In";
};
- /*
-* Temp hack: Need to be replaced with the proper gpio-controlled
-* reset driver as soon it will be merged.
-* http://thread.gmane.org/gmane.linux.drivers.devicetree/36830
-*/
- /* HS USB Port 1 RESET */
- hsusb1_reset: hsusb1_reset_reg {
- compatible = "regulator-fixed";
- regulator-name = "hsusb1_reset";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- gpio = <&gpio2 30 0>; /* gpio_62 */
- startup-delay-us = <7>;
- enable-active-high;
- };
-
/* HS USB Port 1 Power */
hsusb1_power: hsusb1_power_reg {
compatible = "regulator-fixed";
@@ -97,7 +81,7 @@
/* HS USB Host PHY on PORT 1 */
hsusb1_phy: hsusb1_phy {
compatible = "usb-nop-xceiv";
- reset-supply = <&hsusb1_reset>;
+ reset-gpios = <&gpio2 30 GPIO_ACTIVE_LOW>; /* gpio_62 */
vcc-supply = <&hsusb1_power>;
/**
* FIXME:
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 02/10] usb: phy: generic: Don't use regulator framework for RESET line
Modelling the RESET line as a regulator supply wasn't a good idea
as it kind of abuses the regulator framework and also makes adaptation
code more complex.
Instead, manage the RESET gpio line directly in the driver. Update
the device tree binding information.
This also makes us easy to migrate to a dedicated GPIO RESET controller
whenever it becomes available.
Signed-off-by: Roger Quadros
---
.../devicetree/bindings/usb/usb-nop-xceiv.txt |7 +-
drivers/usb/phy/phy-am335x.c |2 +-
drivers/usb/phy/phy-generic.c | 84 +---
drivers/usb/phy/phy-generic.h |6 +-
4 files changed, 63 insertions(+), 36 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
index d7e2726..1bd37fa 100644
--- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
@@ -15,7 +15,7 @@ Optional properties:
- vcc-supply: phandle to the regulator that provides RESET to the PHY.
-- reset-supply: phandle to the regulator that provides power to the PHY.
+- reset-gpios: Should specify the GPIO for reset.
Example:
@@ -25,10 +25,9 @@ Example:
clocks = <&osc 0>;
clock-names = "main_clk";
vcc-supply = <&hsusb1_vcc_regulator>;
- reset-supply = <&hsusb1_reset_regulator>;
+ reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
};
hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
-hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
-controls RESET.
+hsusb1_vcc_regulator provides power to the PHY and GPIO 7 controls RESET.
diff --git a/drivers/usb/phy/phy-am335x.c b/drivers/usb/phy/phy-am335x.c
index c4d614d..fb4bf28 100644
--- a/drivers/usb/phy/phy-am335x.c
+++ b/drivers/usb/phy/phy-am335x.c
@@ -53,7 +53,7 @@ static int am335x_phy_probe(struct platform_device *pdev)
}
ret = usb_phy_gen_create_phy(dev, &am_phy->usb_phy_gen,
- USB_PHY_TYPE_USB2, 0, false, false);
+ USB_PHY_TYPE_USB2, 0, false);
if (ret)
return ret;
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index efe59f3..36d7071 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -35,6 +35,9 @@
#include
#include
#include
+#include
+#include
+#include
#include "phy-generic.h"
@@ -64,6 +67,23 @@ static int nop_set_suspend(struct usb_phy *x, int suspend)
return 0;
}
+static void nop_reset_set(struct usb_phy_gen_xceiv *nop, int asserted)
+{
+ int value;
+
+ if (!gpio_is_valid(nop->gpio_reset))
+ return;
+
+ value = asserted;
+ if (nop->reset_active_low)
+ value = !value;
+
+ gpio_set_value_cansleep(nop->gpio_reset, value);
+
+ if (!asserted)
+ usleep_range(1, 2);
+}
+
int usb_gen_phy_init(struct usb_phy *phy)
{
struct usb_phy_gen_xceiv *nop = dev_get_drvdata(phy->dev);
@@ -76,11 +96,8 @@ int usb_gen_phy_init(struct usb_phy *phy)
if (!IS_ERR(nop->clk))
clk_enable(nop->clk);
- if (!IS_ERR(nop->reset)) {
- /* De-assert RESET */
- if (regulator_enable(nop->reset))
- dev_err(phy->dev, "Failed to de-assert reset\n");
- }
+ /* De-assert RESET */
+ nop_reset_set(nop, 0);
return 0;
}
@@ -90,11 +107,8 @@ void usb_gen_phy_shutdown(struct usb_phy *phy)
{
struct usb_phy_gen_xceiv *nop = dev_get_drvdata(phy->dev);
- if (!IS_ERR(nop->reset)) {
- /* Assert RESET */
- if (regulator_disable(nop->reset))
- dev_err(phy->dev, "Failed to assert reset\n");
- }
+ /* Assert RESET */
+ nop_reset_set(nop, 1);
if (!IS_ERR(nop->clk))
clk_disable(nop->clk);
@@ -136,8 +150,7 @@ static int nop_set_host(struct usb_otg *otg, struct usb_bus
*host)
}
int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_gen_xceiv *nop,
- enum usb_phy_type type, u32 clk_rate, bool needs_vcc,
- bool needs_reset)
+ enum usb_phy_type type, u32 clk_rate, bool needs_vcc)
{
int err;
@@ -176,12 +189,22 @@ int usb_phy_gen_create_phy(struct device *dev, struct
usb_phy_gen_xceiv *nop,
return -EPROBE_DEFER;
}
- nop->reset = devm_regulator_get(dev, "reset");
- if (IS_ERR(nop->reset)) {
- dev_dbg(dev, "Error getting reset regulator: %ld\n",
- PTR_ERR(nop->reset));
- if (needs_reset)
- return -EPROBE_DEFER;
+ if (gpio_is_valid(nop->gpi
[PATCH v3 07/10] ARM: dts: omap5-uevm: Use reset-gpios for hsusb2/3_reset
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts "reset-gpios" property.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap5-uevm.dts | 26 ++
1 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 65d7b60..506bdc2 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -27,21 +27,10 @@
regulator-max-microvolt = <300>;
};
- /* HS USB Port 2 RESET */
- hsusb2_reset: hsusb2_reset_reg {
- compatible = "regulator-fixed";
- regulator-name = "hsusb2_reset";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- gpio = <&gpio3 16 GPIO_ACTIVE_HIGH>; /* gpio3_80 HUB_NRESET */
- startup-delay-us = <7>;
- enable-active-high;
- };
-
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
- reset-supply = <&hsusb2_reset>;
+ reset-gpios = <&gpio3 16 GPIO_ACTIVE_LOW>; /* gpio3_80
HUB_NRESET */
/**
* FIXME
* Put the right clock phandle here when available
@@ -51,21 +40,10 @@
clock-frequency = <1920>;
};
- /* HS USB Port 3 RESET */
- hsusb3_reset: hsusb3_reset_reg {
- compatible = "regulator-fixed";
- regulator-name = "hsusb3_reset";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- gpio = <&gpio3 15 GPIO_ACTIVE_HIGH>; /* gpio3_79 ETH_NRESET */
- startup-delay-us = <7>;
- enable-active-high;
- };
-
/* HS USB Host PHY on PORT 3 */
hsusb3_phy: hsusb3_phy {
compatible = "usb-nop-xceiv";
- reset-supply = <&hsusb3_reset>;
+ reset-gpios = <&gpio3 15 GPIO_ACTIVE_LOW>; /* gpio3_79
ETH_NRESET */
};
leds {
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 04/10] ARM: OMAP2+: usb-host: Adapt to USB phy-nop RESET line changes
The USB phy-nop nop driver expects the RESET line information
to be sent as a GPIO number via platform data. Adapt to that.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/usb-host.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 78ac1c2..10855eb 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -460,8 +460,7 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int
num_phys)
memset(&nop_pdata, 0, sizeof(nop_pdata));
if (gpio_is_valid(phy->vcc_gpio))
nop_pdata.needs_vcc = true;
- if (gpio_is_valid(phy->reset_gpio))
- nop_pdata.needs_reset = true;
+ nop_pdata.gpio_reset = phy->reset_gpio;
nop_pdata.type = USB_PHY_TYPE_USB2;
/* create a NOP PHY device */
@@ -483,14 +482,6 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int
num_phys)
usb_bind_phy("ehci-omap.0", phy->port - 1, phy_id);
- /* Do we need RESET regulator ? */
- if (gpio_is_valid(phy->reset_gpio)) {
- scnprintf(rail_name, MAX_STR,
- "hsusb%d_reset", phy->port);
- usbhs_add_regulator(rail_name, phy_id, "reset",
- phy->reset_gpio, 1);
- }
-
/* Do we need VCC regulator ? */
if (gpio_is_valid(phy->vcc_gpio)) {
scnprintf(rail_name, MAX_STR, "hsusb%d_vcc", phy->port);
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 01/10] usb: phy: generic: Add gpio_reset to platform data
The GPIO number of the RESET line can be passed to the
driver using the gpio_reset member.
Signed-off-by: Roger Quadros
---
include/linux/usb/usb_phy_gen_xceiv.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/include/linux/usb/usb_phy_gen_xceiv.h
b/include/linux/usb/usb_phy_gen_xceiv.h
index f9a7e7b..42f3b71 100644
--- a/include/linux/usb/usb_phy_gen_xceiv.h
+++ b/include/linux/usb/usb_phy_gen_xceiv.h
@@ -9,7 +9,8 @@ struct usb_phy_gen_xceiv_platform_data {
/* if set fails with -EPROBE_DEFER if can't get regulator */
unsigned int needs_vcc:1;
- unsigned int needs_reset:1;
+ unsigned int needs_reset:1; /* deprecated */
+ int gpio_reset;
};
#if IS_ENABLED(CONFIG_NOP_USB_XCEIV)
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 09/10] ARM: dts: omap3-beagle-xm: Add USB Host support
Provide RESET GPIO and Power regulator for the USB PHY,
the USB Host port mode and the PHY device for the controller.
Also provide pin multiplexer information for USB host pins.
We also relocate omap3_pmx_core pin definations so that they
are close to omap3_pmx_wkup pin definations.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 65 -
1 files changed, 56 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index afdb164..b081f5a 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -69,6 +69,23 @@
};
};
+
+ /* HS USB Port 2 Power */
+ hsusb2_power: hsusb2_power_reg {
+ compatible = "regulator-fixed";
+ regulator-name = "hsusb2_vbus";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&twl_gpio 18 0>;/* GPIO LEDA */
+ startup-delay-us = <7>;
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = "usb-nop-xceiv";
+ reset-gpios = <&gpio5 19 GPIO_ACTIVE_LOW>; /* gpio_147 */
+ vcc-supply = <&hsusb2_power>;
+ };
};
&omap3_pmx_wkup {
@@ -79,6 +96,37 @@
};
};
+&omap3_pmx_core {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &hsusbb2_pins
+ >;
+
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins = <
+ 0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
+ 0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */
+ >;
+ };
+
+ hsusbb2_pins: pinmux_hsusbb2_pins {
+ pinctrl-single,pins = <
+ 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
+ 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
+ 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d12.hsusb2_dir */
+ 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d13.hsusb2_nxt */
+ 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d14.hsusb2_data0 */
+ 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d15.hsusb2_data1 */
+ 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi1_cs3.hsusb2_data2 */
+ 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_clk.hsusb2_data7 */
+ 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_simo.hsusb2_data4 */
+ 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_somi.hsusb2_data5 */
+ 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs0.hsusb2_data6 */
+ 0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs1.hsusb2_data3 */
+ >;
+ };
+};
+
&i2c1 {
clock-frequency = <260>;
@@ -148,15 +196,6 @@
power = <50>;
};
-&omap3_pmx_core {
- uart3_pins: pinmux_uart3_pins {
- pinctrl-single,pins = <
- 0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
- 0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */
- >;
- };
-};
-
&uart3 {
pinctrl-names = "default";
pinctrl-0 = <&uart3_pins>;
@@ -166,3 +205,11 @@
pinctrl-names = "default";
pinctrl-0 = <&gpio1_pins>;
};
+
+&usbhshost {
+ port2-mode = "ehci-phy";
+};
+
+&usbhsehci {
+ phys = <0 &hsusb2_phy>;
+};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 03/10] ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct usbhs_phy_data
The platform data bits can be inferred from the other members of
struct usbhs_phy_data. So get rid of the platform_data member.
Build the platform data for the PHY device in usbhs_init_phys() instead.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3beagle.c |6 --
arch/arm/mach-omap2/usb-host.c | 11 ++-
arch/arm/mach-omap2/usb.h |1 -
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index f269184..8b9cd06 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -289,18 +289,12 @@ static struct regulator_consumer_supply
beagle_vsim_supply[] = {
static struct gpio_led gpio_leds[];
-/* PHY's VCC regulator might be added later, so flag that we need it */
-static struct usb_phy_gen_xceiv_platform_data hsusb2_phy_data = {
- .needs_vcc = true,
-};
-
static struct usbhs_phy_data phy_data[] = {
{
.port = 2,
.reset_gpio = 147,
.vcc_gpio = -1, /* updated in beagle_twl_gpio_setup */
.vcc_polarity = 1, /* updated in beagle_twl_gpio_setup */
- .platform_data = &hsusb2_phy_data,
},
};
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index e83a6a4..78ac1c2 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -435,6 +435,7 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int
num_phys)
struct platform_device *pdev;
char *phy_id;
struct platform_device_info pdevinfo;
+ struct usb_phy_gen_xceiv_platform_data nop_pdata;
for (i = 0; i < num_phys; i++) {
@@ -455,11 +456,19 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int
num_phys)
return -ENOMEM;
}
+ /* set platform data */
+ memset(&nop_pdata, 0, sizeof(nop_pdata));
+ if (gpio_is_valid(phy->vcc_gpio))
+ nop_pdata.needs_vcc = true;
+ if (gpio_is_valid(phy->reset_gpio))
+ nop_pdata.needs_reset = true;
+ nop_pdata.type = USB_PHY_TYPE_USB2;
+
/* create a NOP PHY device */
memset(&pdevinfo, 0, sizeof(pdevinfo));
pdevinfo.name = nop_name;
pdevinfo.id = phy->port;
- pdevinfo.data = phy->platform_data;
+ pdevinfo.data = &nop_pdata;
pdevinfo.size_data =
sizeof(struct usb_phy_gen_xceiv_platform_data);
scnprintf(phy_id, MAX_STR, "usb_phy_gen_xceiv.%d",
diff --git a/arch/arm/mach-omap2/usb.h b/arch/arm/mach-omap2/usb.h
index e7261eb..4ba2ae7 100644
--- a/arch/arm/mach-omap2/usb.h
+++ b/arch/arm/mach-omap2/usb.h
@@ -58,7 +58,6 @@ struct usbhs_phy_data {
int reset_gpio;
int vcc_gpio;
bool vcc_polarity; /* 1 active high, 0 active low */
- void *platform_data;
};
extern void usb_musb_init(struct omap_musb_board_data *board_data);
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/6] uas: make work list per-device
On Wed, Sep 18, 2013 at 09:33:04AM +0200, Gerd Hoffmann wrote: > > > While being at it rename the list head from "list" to "work", preparing > > > for the addition of a second list. > > > > Why do you even the list? > > The list was already there when I took over maintainance ... > > > What would a ordered per-device workqueue not > > provide? > > Had no reason to look into replacing the list with something else so > far. Why do you suggest using a workqueue instead? > > Note that the list is not used in a typical request workflow. Only in > case queuing an usb urb failed the request is linked into the list and > the worker will try to submit the usb urb again. The driver is only using the list to queue up things into workqueue context as far as I can see. Which means it's far easier to leave that to the workqueue. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some questions about ehci period scheduling
hi Alan:
> > BTW, I have another question about iso_stream_schedule.
> > When if (likely (!list_empty (&stream->td_list))) happen,
> > why don't we just take last scheduled microframe, stream->next_uframe
> > as start point directly?
>
> We do exactly that if URB_ISO_ASAP isn't set. But first the routine
> has to check and see if the schedule is already full, and it prints a
> debugging message if all the assigned microframes have already expired.
Does below source show us what you mean?
if (unlikely(start < period)) {
ehci_dbg(ehci, "iso sched full %p (%u-%u < %u mod %u)\n",
urb, stream->next_uframe, base,
period, mod);
status = -ENOSPC;
goto fail;
}
if so, I have one question, why we use ( (last scan frame and last
schedule frame) < end point interval) to determine schedule is full?
Below is where we handle URB_ISO_ASAP,
if (urb->transfer_flags & URB_ISO_ASAP)
start += (next - start + period - 1) & -period;
Why don't we just use start as next?
Appreciate your kind help,
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
