RE: PROBLEM: XHCI Host Controller on Intel Panther Point with CDC/ACM dead after massive NAK
>> I saw the in the device endpoint ep82/ep83 at wMaxPacketSize a size "0040". >> >> As far as I understand the "packet 7092" in wireshark with URB data >> length 128 should not possible? What happens at such packets sizes? >> Or does wireshark just joking me -- > > Wireshark adds 64 bytes of overhead to each packet it captures. > Yes Alan, overall wireshark shows 192 byte for that packet. -- 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: Re: [PATCH] USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800Device Driver Support
Dear Miller :
Thanks a lot.
2014-02-11
liujunliang_ljl
发件人： David Miller
发送时间： 2014-02-11 08:54:00
收件人： liujunliang_ljl
抄送： joe; horms; romieu; gregkh; netdev; linux-usb; linux-kernel; sunhecheng
主题： Re: [PATCH] USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800Device Driver
Support
From: liujunliang_...@163.com
Date: Mon, 10 Feb 2014 14:31:42 +0800
> From: Liu Junliang
>
>
> Signed-off-by: Liu Junliang
Applied, thanks.
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{焙柒��^n�r■�z���h�ㄨ��&Ⅷ �G���h�(�茛j"���m赇z罐��帼f＂�h���~�m�
Re: [RFC] usb: option: blacklist ZTE MF667 net interface
Sorry, first time, meant to be "PATCH". On Sun, Feb 9, 2014 at 7:31 PM, Greg KH wrote: > On Sun, Feb 09, 2014 at 11:59:46AM +0300, Raymond Wanyoike wrote: >> Interface #5 of 19d2:1270 is a net interface which has been submitted to the >> qmi_wwan driver so consequently remove it from the option driver. >> >> Signed-off-by: Raymond Wanyoike >> --- >> drivers/usb/serial/option.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) > > Why is this patch a "RFC"? -- Raymond -- 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 1/1] USB: EHCI: wait more than 3ms until the device enters full-speed idle
On Mon, Feb 10, 2014 at 11:40:25AM -0500, Alan Stern wrote:
> On Fri, 7 Feb 2014, Peter Chen wrote:
>
> > If the high-speed device does not enter full-speed idle after
> > wakeup on disconnect logic has effected, there will be an
> > unexpected disconnect wakeup interrupt due to the bus is still SE0.
> >
> > Signed-off-by: Peter Chen
> >
> > Hi Alan,
> >
> > If you can't met this issue, it may due to your hardware enables
> > WKDN after detecting full-speed idle or the time between stop
> > SoF and enable WKDN is more than 3ms (You need to know when
> > the WKDN has really taken effect).
>
> Yes. However, I don't like the way your patch can increase the total
> time if several ports have to be put into suspend. Consider this patch
> instead.
>
> Alan Stern
>
>
>
> Index: usb-3.14/drivers/usb/host/ehci-hub.c
> ===
> --- usb-3.14.orig/drivers/usb/host/ehci-hub.c
> +++ usb-3.14/drivers/usb/host/ehci-hub.c
> @@ -238,6 +238,7 @@ static int ehci_bus_suspend (struct usb_
> int port;
> int mask;
> int changed;
> + unsignedwant_WKDISC;
Not sure mixed uppercase letters and lowercase letters into a
single variable is a good idea.
>
> ehci_dbg(ehci, "suspend root hub\n");
>
> @@ -272,6 +273,7 @@ static int ehci_bus_suspend (struct usb_
> ehci->bus_suspended = 0;
> ehci->owned_ports = 0;
> changed = 0;
> + want_WKDISC = 0;
> port = HCS_N_PORTS(ehci->hcs_params);
> while (port--) {
> u32 __iomem *reg = &ehci->regs->port_status [port];
> @@ -300,16 +302,48 @@ static int ehci_bus_suspend (struct usb_
> }
>
> if (t1 != t2) {
> + /*
> + * Don't enable wake-on-disconnect until the bus has
> + * switched over to full-speed idle.
> + */
> + if ((t2 & PORT_WKDISC_E) &&
> + ehci_port_speed(ehci, t2) ==
> + USB_PORT_STAT_HIGH_SPEED) {
> + t2 &= ~PORT_WKDISC_E;
> + want_WKDISC |= (1 << port);
> + }
> ehci_writel(ehci, t2, reg);
> changed = 1;
> }
> }
> + spin_unlock_irq(&ehci->lock);
>
> - if (changed && ehci->has_tdi_phy_lpm) {
> - spin_unlock_irq(&ehci->lock);
> - msleep(5); /* 5 ms for HCD to enter low-power mode */
> + if ((changed && ehci->has_tdi_phy_lpm) || want_WKDISC) {
> + /*
> + * Wait for HCD to enter low-power mode or for the bus
> + * to switch to full-speed idle.
> + */
> + usleep_range(5000, 5500);
> + }
> +
> + if (want_WKDISC) {
> spin_lock_irq(&ehci->lock);
> + port = HCS_N_PORTS(ehci->hcs_params);
> + while (port--) {
> + u32 __iomem *reg;
> + u32 t2;
>
> + if (!(want_WKDISC & (1 << port)))
> + continue;
> + reg = &ehci->regs->port_status[port];
> + t2 = ehci_readl(ehci, reg) & ~PORT_RWC_BITS;
Why it needs to re-do clear PORT_RWC_BITS?
> + ehci_writel(ehci, t2 | PORT_WKDISC_E, reg);
> + }
> + spin_unlock_irq(&ehci->lock);
> + }
> +
> + if (changed && ehci->has_tdi_phy_lpm) {
> + spin_lock_irq(&ehci->lock);
> port = HCS_N_PORTS(ehci->hcs_params);
> while (port--) {
> u32 __iomem *hostpc_reg = &ehci->regs->hostpc[port];
> @@ -322,8 +356,8 @@ static int ehci_bus_suspend (struct usb_
> port, (t3 & HOSTPC_PHCD) ?
> "succeeded" : "failed");
> }
> + spin_unlock_irq(&ehci->lock);
> }
> - spin_unlock_irq(&ehci->lock);
How about adding spin_lock_irq and spin_unlock_irq only one time,
I mean not add them into the two if () conditional statement.
>
> /* Apparently some devices need a >= 1-uframe delay here */
> if (ehci->bus_suspended)
>
>
>
--
Best Regards,
Peter Chen
--
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 13/14] usb: force warm reset to break resume livelock
On Mon, Feb 10, 2014 at 1:26 PM, Alan Stern wrote: > On Fri, 31 Jan 2014, Dan Williams wrote: > >> Resuming a powered down port sometimes results in the port state being >> stuck in USB_SS_PORT_LS_POLLING: >> >> hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 >> port1: can't get reconnection after setting port power on, status -110 >> hub 3-0:1.0: port 1 status .02e0 after resume, -19 >> usb 3-1: can't resume, status -19 >> hub 3-0:1.0: logical disconnect on port 1 > > It's not obvious that this illustrates your point. Are we supposed to > know offhand that 0x2e0 means USB_SS_PORT_LS_POLLING? Hmm, no, I'll make the clearer in the revised change log. > >> In the case above we wait 2 seconds for the port to reconnect and for >> that entire time the port remained in the polling state. A warm reset >> triggers the device to reconnect and resume as normal. With this patch >> we get: >> >> hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 >> usb usb3: port1 usb_port_runtime_resume requires warm reset >> hub 3-0:1.0: port 1 not warm reset yet, waiting 50ms >> usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd > > Could this be improved? We still spent 2 seconds waiting for a port > that remained in the polling state. So this and at least one other question is why this cc list includes the participants from the thread "[PATCH] USB: core: Add warm reset while reset-resuming SuperSpeed HUBs": http://marc.info/?l=linux-usb&m=138678842000703&w=2 I believe I am seeing a "polling livelock" scenario as described by Julius. > >> With this in place we may want to consider reducing the timeout and >> relying on warm reset for recovery. > > Why? I'm not familiar with the intricacies of USB-3 link state > changes, but there seem to be only two possibilities: > > Either PORT_LS_POLLING is a valid state to be in while > trying to establish a SuperSpeed connection, in which case > we don't want to reduce the timeout, > > Or it isn't a valid state, in which case we should abort > the debounce immediately. > > One other thought (I don't know if it is the right thing to do) is that > we might _always_ perform a warm reset after powering-on a SuperSpeed > port, without bothering to call hub_port_debounce_be_connected. I'm leaning in that direction. However, the decision comes down to the relative occurrence frequency of devices that fall into this trap vs those that successfully recover and would suffer the additional latency of a warm reset. There's just no way to know if the device on the other side is legitimately causing a polling condition or whether this is a result of the aforementioned live lock. So far I only have one USB3 device that requires this, our favorite ax88179_178a net adapter. The spec says that the only way to reliably sync the state machines is to remove power from the device, but we have no real way from the kernel to force and know a port is physically powered off. I'll look and see how imposing latency-wise it would be to always warm reset, but we may want to just quirk temperamental devices and hosts as we find them and use the timeout as a backstop. > >> Other xHCs that fail to propagate >> warm resets on hub resume may want to trigger this behavior via a quirk. > > What do you mean by "other xHCs"? Other than what? > Other "xHCs" referring again to that warm reset thread and the hypothesis that the Synopsys xHC is not propagating warm resets on host resume. > I don't want to go over this patch in detail, because it's pretty > confusing and the code is messy. Still, it seems odd to add all those > port status manipulations in usb_port_runtime_resume, when > hub_port_debounce_be_connected is already doing them. > > And why do we need another special flag to indicate that a warm reset > is needed? Can't check_port_resume_type figure that out from the port > status? That routine was meant for exactly this sort of thing. > check_port_resume_type() does not have the context to make the determination. LS_POLLING is a valid state, we only know that a warm reset is required when it has been in this state for "too long". Unfortunately, the timeout needs to consider that the device is coming from physically powered off condition (rather than just logical) so it at least needs to be 2 seconds for a connection (per commit ad493e5 usb: add usb port auto power off mechanism). -- 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: regression(ti platforms): next-20140210 (ehci?)
Nishanth Menon writes:
> On 02/10/2014 12:28 PM, Kevin Hilman wrote:
>> Roger Quadros writes:
>>
>>> +devicetree
>>>
>>> On 02/10/2014 05:59 PM, Nishanth Menon wrote:
>>>> Hi,
>>>>
>>>> A quick note to report that I saw regression in today's next tag (logs
>>>> indicate around EHCI) boot on various TI platforms:
>>>>
>>>> Note: crane and sdp2430 are not expected to pass with
>>>> multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane
>>>> but USB is disabled there)
>>>>
>>>> next-20140210-multi_v7_defconfig
>>>> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zYHdPb94
>>>> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2UChLyzSE
>>>> 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s20Br9XLO1
>>>> around ehci
>>>>
>>>> 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20mVz9Wc7
>>>> around ehci
>>>>
>>>> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2byveBYtT
>>>> 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21sOgJNwK
>>>> around ehci
>>>>
>>>> 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2ovVNAmO7
>>>> 8: crane: No Image built - Missing platform support?:
>>>> 9: dra7: Boot PASS: http://slexy.org/raw/s217qwaXsM
>>>> 10:ldp: Boot FAIL: http://slexy.org/raw/s203IvjE23
>>>> around ehci
>>>>
>>>> 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ
>>>> around ehci
>>>
>>> I think the problem is that ehci-platform driver gets loaded instead of
>>> ehci-omap.
>>>
>>> In the DT node we have compatible ids for both. e.g. for omap4.dtsi
>>>
>>> usbhsehci: ehci@4a064c00 {
>>> compatible = "ti,ehci-omap", "usb-ehci";
>>> reg = <0x4a064c00 0x400>;
>>> interrupt-parent = <&gic>;
>>> interrupts = >> IRQ_TYPE_LEVEL_HIGH>;
>>> };
>>>
>>> Shouldn't ehci-omap driver be getting a higher priority than usb-ehci?
>>>
>>> A quick fix would be to eliminate "usb-ehci" from the DT node of all
>>> failing platforms.
>>
>> I can confirm that simply remvoing usb-ehci from omap[34].dtsi nodes
>> fixed the problem for me on 3530/overo, 3730/beagle-xM and
>> 4460/panda-es. But I don't think that's the right fix. First we have
>> to figure out why ehci-omap stopped getting loaded first.
>
> Wont that depend on driver probe order? of_match_device is fairly
> simple compatible walk through without looking at other drivers which
> might also be compatible, but not yet probed?
>
> The issue started I think with the following patch getting merged:
> ehci-platform: Add support for clks and phy passed through devicetree
> some version of http://www.spinics.net/lists/linux-usb/msg101061.html
> introduced { .compatible = "usb-ehci", },
This is what I was getting at: an understanding of what caused the
failue in the first place.
> Now, in the build we have two drivers which dts claims compatibility
> with, but only 1 driver actually works (drivers/usb/host/ehci-omap.c)
> for the platform. Thinking that way, in fact, the current
> compatibility even matches drivers/usb/host/ehci-ppc-of.c which
> obviously wont work either.
Right, so I agree that it makes sense to remove a compatible string
where there is no compatability, but a couple other things should happen
here.
1) changelog should describe why this compatible string is in the omap
dtsi files in first place.
2) investigation into the patch that introduced this change to double
check it's not introducing other breakage as well.
Kevin
--
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] USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800 Device Driver Support
From: liujunliang_...@163.com Date: Mon, 10 Feb 2014 14:31:42 +0800 > From: Liu Junliang > > > Signed-off-by: Liu Junliang Applied, thanks. -- 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/2] usb/host/Kconfig: ohci- / ehci-platform make sure PHY_GENERIC is available
Alam, All, On 2014-02-10 11:04 -0500, Alan Stern spake thusly: > On Mon, 10 Feb 2014, Hans de Goede wrote: > > > Disallow ohci- / ehci-platform being built-in, when the phy core is build as > > a module. > > > > Signed-off-by: Hans de Goede > > --- > > drivers/usb/host/Kconfig | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > > index e28cbe0..1dd73e3 100644 > > --- a/drivers/usb/host/Kconfig > > +++ b/drivers/usb/host/Kconfig > > @@ -255,7 +255,7 @@ config USB_EHCI_ATH79 > > > > config USB_EHCI_HCD_PLATFORM > > tristate "Generic EHCI driver for a platform device" > > - depends on !PPC_OF > > + depends on !PPC_OF && (GENERIC_PHY || !GENERIC_PHY) > > default n > > ---help--- > > Adds an EHCI host driver for a generic platform device, which > > @@ -512,6 +512,7 @@ config USB_CNS3XXX_OHCI > > > > config USB_OHCI_HCD_PLATFORM > > tristate "Generic OHCI driver for a platform device" > > + depends on GENERIC_PHY || !GENERIC_PHY > > default n > > ---help--- > > Adds an OHCI host driver for a generic platform device, which > > I would very much like to know of a more straightforward way to do > this. Yann, can you suggest anything? Unfortunately, I don't have a better solution at hand... :-/ IIRC, this issue (or a similar issue) was discussed here on linux-kbuild, but no better alternative was found at the time either. At least, this construct should be documented, I think, since it is not so obvious. Regards, Yann E. MORIN. -- .-..--.. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `.---: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL| v conspiracy. | '--^---^--^' -- 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 13/14] usb: force warm reset to break resume livelock
On Fri, 31 Jan 2014, Dan Williams wrote: > Resuming a powered down port sometimes results in the port state being > stuck in USB_SS_PORT_LS_POLLING: > > hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 > port1: can't get reconnection after setting port power on, status -110 > hub 3-0:1.0: port 1 status .02e0 after resume, -19 > usb 3-1: can't resume, status -19 > hub 3-0:1.0: logical disconnect on port 1 It's not obvious that this illustrates your point. Are we supposed to know offhand that 0x2e0 means USB_SS_PORT_LS_POLLING? > In the case above we wait 2 seconds for the port to reconnect and for > that entire time the port remained in the polling state. A warm reset > triggers the device to reconnect and resume as normal. With this patch > we get: > > hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0 > usb usb3: port1 usb_port_runtime_resume requires warm reset > hub 3-0:1.0: port 1 not warm reset yet, waiting 50ms > usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd Could this be improved? We still spent 2 seconds waiting for a port that remained in the polling state. > With this in place we may want to consider reducing the timeout and > relying on warm reset for recovery. Why? I'm not familiar with the intricacies of USB-3 link state changes, but there seem to be only two possibilities: Either PORT_LS_POLLING is a valid state to be in while trying to establish a SuperSpeed connection, in which case we don't want to reduce the timeout, Or it isn't a valid state, in which case we should abort the debounce immediately. One other thought (I don't know if it is the right thing to do) is that we might _always_ perform a warm reset after powering-on a SuperSpeed port, without bothering to call hub_port_debounce_be_connected. > Other xHCs that fail to propagate > warm resets on hub resume may want to trigger this behavior via a quirk. What do you mean by "other xHCs"? Other than what? I don't want to go over this patch in detail, because it's pretty confusing and the code is messy. Still, it seems odd to add all those port status manipulations in usb_port_runtime_resume, when hub_port_debounce_be_connected is already doing them. And why do we need another special flag to indicate that a warm reset is needed? Can't check_port_resume_type figure that out from the port status? That routine was meant for exactly this sort of thing. 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 12/14] usb: guarantee child device resume on port poweron
The patch description here could be improved substantially. It should
start out with an explanation of the basic reason for the patch and a
clear indication of what the patch does.
On Fri, 31 Jan 2014, Dan Williams wrote:
> Make port power recovery behave similarly to the power session recovery
> that occurs after a system / hub suspend event. Arrange for a
That is not clear to me, mostly because of its lack of specificity. I
would phrase it more like this:
Whenever a USB port is powered back on (runtime resumed),
ask khubd to do an autoresume of the attached child device as
soon as possible.
> usb_device to always complete a usb_port_resume() run prior to the next
> khubd run. This serves several purposes:
"Prior to the next khubd run" is misleading. khubd may run several
times, for other purposes, before it gets around to handling this
particular port. "As soon as possible" is better.
> 1/ The device may need a reset on power-session loss, without this
>change port power-on recovery exposes khubd to scenarios that
>usb_port_resume() is set to handle.
What scenarios? Wouldn't khubd handle them by doing a runtime resume
anyway?
> Also, testing showed that USB3
>devices that are not reset on power-session loss may eventually
>downgrade their connection to the USB2 pins.
What do you mean by "eventually"? The delay before the reset is too
long? Or the port power-cycles too many times?
> 2/ This mechanism rate limits port power toggling. The minimum port
>power on/off period is now gated by the child device suspend/resume
>latency. This mitigates devices downgrading their connection on
>perceived instability of the host connection. This ratelimiting is
>really only relevant to port power control testing, but it is a nice
>side effect of closing the above race.
What race?
This reminds me... In the case of a tier mismatch, is it possible that
the USB-3 root hub will be capable of switching off power to its ports
but the integrated USB-2 hub won't? In that situation, the device is
virtually certain to change over to high speed.
> 3/ Going forward if we find that power-session recovery requires
>warm-resets (http://marc.info/?t=13865923293&r=1&w=2) that is
>something usb_port_resume() can drive and handle before khubd's next
>evaluation of the portstatus.
Isn't this more or less the case right now? In the current code, the
only reason the hub driver would look at a port that had recently been
powered back on is if the attached device was undergoing a runtime
resume.
> 4/ If the device *was* disconnected the only time we'll know for sure is
>after a failed resume, so it's necessary for
>usb_port_runtime_resume() to expedite a usb_port_resume() to clean up
>the removed device.
I don't follow the reasoning. Even granting that we want to find out
about the disconnection, we have already waited an indefinitely long
time for the port to be powered back on. What harm is there in waiting
another indefinitely long time for the device to be runtime-resumed?
Also, usb_port_runtime_resume _already_ includes code to check for a
disconnection. Currently all it does is log a debugging message if the
device is gone, but it could easily do more.
> 1, 2, and 4 are not a problem in the system resume case because,
> although the power-session is lost, khubd is frozen until after device
> resume. For the runtime pm case we can use runtime-pm-synchronization
> to guarantee the same sequence of events. When a ->resume_child request
> is set in usb_port_runtime_resume() the port device is in the
> RPM_RESUMING state. khubd executes a pm_runtime_barrier() on the port
> device to flush the port recovery, holds the port active while it
> resumes the child, and completes child device resume before acting on
> the current portstatus.
>
> Signed-off-by: Dan Williams
> ---
> drivers/usb/core/hub.c | 17 +
> drivers/usb/core/hub.h |2 ++
> drivers/usb/core/port.c |7 +++
> 3 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index a310028e210d..9a505978ab92 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -4767,6 +4767,23 @@ static void port_event(struct usb_hub *hub, int port1)
> pm_runtime_barrier(&port_dev->dev);
> usb_lock_port(port_dev);
> do if (pm_runtime_active(&port_dev->dev)) {
> +
> + /* service child resume requests on behalf of
> + * usb_port_runtime_resume()
> + */
> + if (port_dev->resume_child && udev) {
> + usb_unlock_port(port_dev);
> +
> + usb_lock_device(udev);
> + usb_autoresume_device(udev);
> + usb_autosuspend_device(udev);
> + usb_unlock_device(udev);
> +
> + pm_runtime_put(&port_dev
Re: regression(ti platforms): next-20140210 (ehci?)
On 02/10/2014 12:28 PM, Kevin Hilman wrote:
> Roger Quadros writes:
>
>> +devicetree
>>
>> On 02/10/2014 05:59 PM, Nishanth Menon wrote:
>>> Hi,
>>>
>>> A quick note to report that I saw regression in today's next tag (logs
>>> indicate around EHCI) boot on various TI platforms:
>>>
>>> Note: crane and sdp2430 are not expected to pass with
>>> multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane
>>> but USB is disabled there)
>>>
>>> next-20140210-multi_v7_defconfig
>>> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zYHdPb94
>>> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2UChLyzSE
>>> 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s20Br9XLO1
>>> around ehci
>>>
>>> 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20mVz9Wc7
>>> around ehci
>>>
>>> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2byveBYtT
>>> 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21sOgJNwK
>>> around ehci
>>>
>>> 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2ovVNAmO7
>>> 8: crane: No Image built - Missing platform support?:
>>> 9: dra7: Boot PASS: http://slexy.org/raw/s217qwaXsM
>>> 10:ldp: Boot FAIL: http://slexy.org/raw/s203IvjE23
>>> around ehci
>>>
>>> 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ
>>> around ehci
>>
>> I think the problem is that ehci-platform driver gets loaded instead of
>> ehci-omap.
>>
>> In the DT node we have compatible ids for both. e.g. for omap4.dtsi
>>
>> usbhsehci: ehci@4a064c00 {
>> compatible = "ti,ehci-omap", "usb-ehci";
>> reg = <0x4a064c00 0x400>;
>> interrupt-parent = <&gic>;
>> interrupts = > IRQ_TYPE_LEVEL_HIGH>;
>> };
>>
>> Shouldn't ehci-omap driver be getting a higher priority than usb-ehci?
>>
>> A quick fix would be to eliminate "usb-ehci" from the DT node of all failing
>> platforms.
>
> I can confirm that simply remvoing usb-ehci from omap[34].dtsi nodes
> fixed the problem for me on 3530/overo, 3730/beagle-xM and
> 4460/panda-es. But I don't think that's the right fix. First we have
> to figure out why ehci-omap stopped getting loaded first.
Wont that depend on driver probe order? of_match_device is fairly
simple compatible walk through without looking at other drivers which
might also be compatible, but not yet probed?
The issue started I think with the following patch getting merged:
ehci-platform: Add support for clks and phy passed through devicetree
some version of http://www.spinics.net/lists/linux-usb/msg101061.html
introduced { .compatible = "usb-ehci", },
Now, in the build we have two drivers which dts claims compatibility
with, but only 1 driver actually works (drivers/usb/host/ehci-omap.c)
for the platform. Thinking that way, in fact, the current
compatibility even matches drivers/usb/host/ehci-ppc-of.c which
obviously wont work either.
--
Regards,
Nishanth Menon
--
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: [BUG] FL1009: xHCI host not responding to stop endpoint command.
Hi Sarah, Sarah Sharp writes: > On Wed, Jan 22, 2014 at 11:43:16PM +0100, Arnaud Ebalard wrote: >> Hi Jason, >> >> Jason Cooper writes: >> >> > On Wed, Jan 22, 2014 at 11:23:23PM +0100, Arnaud Ebalard wrote: >> >> With the patch applied on top of 3.13.0 kernel recompiled w/ >> >> CONFIG_PCI_MSI enabled, I cannot reproduce the bug. I guess >> >> you can add my: >> >> >> >> Reported-and-tested-By: Arnaud Ebalard >> >> >> >> Since you'll have to push the patch to -stable team at least for 3.13, >> >> I wonder if it would not make sense to extend that at least to 3.12. >> >> and possibly 3.10 (3.2 is still widely used but I wonder if it makes >> >> sense to go that far). >> > >> > Can you pinpoint the commit that introduced the regression? >> >> f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some Fresco >> Logic hosts." >> >> Technically, this is not per se the commit which introduced the >> regression but the one that *partially* fixed it by introducing the XHCI >> quirk to skip MSI enabling for Fresco Logic chips. The thing is it >> should have included the FL1009 in the targets. Sarah, can you confirm >> this? > > I don't know if it should have included FL1009, it was just a guess, > based on the fact that the 0x1000 and 0x1400 devices did need MSI > disabled. I can attempt to ask the Fresco Logic folks I know, but I'm > not sure if/when I'll get a response back. > > That still doesn't necessarily rule out MSI issues in the Marvell PCI > host controller code. Can you attach another PCI device with MSI > support under the host and see if it works? Unless you have some objections or some positive feedback from Fresco Logic people, can you queue your quirks for FL1009 for 3.14-rc* and -stable? Note that I am just asking, i.e. if you want to wait a bit more, I am not that in a hurry. Cheers, a+ -- 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: USB storage vanilla kernel 3.13 hang on DELL PRECISION M6400
On Mon, 10 Feb 2014, Stefani Seibold wrote: > > > One interesting thing was that the bus in 3.12.7 was sometimes 6 and > > > sometimes 2. > > > > The bus number doesn't matter; it's allowed to change every time you > > reboot. > > The bus change without a reboot! What? I don't understand. Can you post some files to demonstrate what you mean? > I have more information about the bug. I tested with a USB 3.0 > Expresscard and this works with 3.13. > > I also found an old USB 1.1 HUB in my USB gadget box. When i attach the > USB flash storage to the USB 1.1 hub there is also no problem. > > Since the USB 1.1 Hub is attached to the EHCI we can assume that the bug > is not in the phy support nor in the USB storage driver. > > So i thing the bug must be located in the EHCI HC driver. Yes, it probably is. Can you build 3.13 with CONFIG_USB_DEBUG enabled? Maybe some debugging information will show up in the dmesg log and provide a clue. 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: regression(ti platforms): next-20140210 (ehci?)
Roger Quadros writes:
> +devicetree
>
> On 02/10/2014 05:59 PM, Nishanth Menon wrote:
>> Hi,
>>
>> A quick note to report that I saw regression in today's next tag (logs
>> indicate around EHCI) boot on various TI platforms:
>>
>> Note: crane and sdp2430 are not expected to pass with
>> multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane
>> but USB is disabled there)
>>
>> next-20140210-multi_v7_defconfig
>> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zYHdPb94
>> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2UChLyzSE
>> 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s20Br9XLO1
>> around ehci
>>
>> 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20mVz9Wc7
>> around ehci
>>
>> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2byveBYtT
>> 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21sOgJNwK
>> around ehci
>>
>> 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2ovVNAmO7
>> 8: crane: No Image built - Missing platform support?:
>> 9: dra7: Boot PASS: http://slexy.org/raw/s217qwaXsM
>> 10:ldp: Boot FAIL: http://slexy.org/raw/s203IvjE23
>> around ehci
>>
>> 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ
>> around ehci
>
> I think the problem is that ehci-platform driver gets loaded instead of
> ehci-omap.
>
> In the DT node we have compatible ids for both. e.g. for omap4.dtsi
>
> usbhsehci: ehci@4a064c00 {
> compatible = "ti,ehci-omap", "usb-ehci";
> reg = <0x4a064c00 0x400>;
> interrupt-parent = <&gic>;
> interrupts = ;
> };
>
> Shouldn't ehci-omap driver be getting a higher priority than usb-ehci?
>
> A quick fix would be to eliminate "usb-ehci" from the DT node of all failing
> platforms.
I can confirm that simply remvoing usb-ehci from omap[34].dtsi nodes
fixed the problem for me on 3530/overo, 3730/beagle-xM and
4460/panda-es. But I don't think that's the right fix. First we have
to figure out why ehci-omap stopped getting loaded first.
Kevin
--
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: regression(ti platforms): next-20140210 (ehci?)
On 02/10/2014 08:02 PM, Nishanth Menon wrote:
> On 02/10/2014 11:50 AM, Roger Quadros wrote:
>> +devicetree
>>
> [...]
>> In the DT node we have compatible ids for both. e.g. for omap4.dtsi
>>
>> usbhsehci: ehci@4a064c00 {
>> compatible = "ti,ehci-omap", "usb-ehci";
>> reg = <0x4a064c00 0x400>;
>> interrupt-parent = <&gic>;
>> interrupts = > IRQ_TYPE_LEVEL_HIGH>;
>> };
>>
>> Shouldn't ehci-omap driver be getting a higher priority than usb-ehci?
>>
>> A quick fix would be to eliminate "usb-ehci" from the DT node of all failing
>> platforms.
>
> If the driver is not compatible with "usb-ehci", not sure why do we
> even state that in dts node?
>
>
I'm not sure either. Let's get rid of it.
Patch to fix the reported issue.
http://article.gmane.org/gmane.linux.drivers.devicetree/61204
cheers,
-roger
--
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: USB storage vanilla kernel 3.13 hang on DELL PRECISION M6400
Am Montag, den 10.02.2014, 12:09 -0500 schrieb Alan Stern: > On Mon, 10 Feb 2014, Stefani Seibold wrote: > > > Am Montag, den 10.02.2014, 10:56 -0500 schrieb Alan Stern: > > > On Mon, 10 Feb 2014, Stefani Seibold wrote: > > > > > > > Hi, > > > > > > > > the USB storage does not longer work on my DELL PRECISION M6400 with a > > > > plain vanilla 3.13 kernel. > > > > > > > > When i attach a USB storage flash memory the system freeze immediately > > > > or after accessing the flash. It makes not difference mounting via a > > > > GNOME desktop or mounting as root in a text console. > > > > > > > > There is no problem with all previous kernel like 3.12.7, everything is > > > > okay. > > > > > > > > All of the previous vanilla kernels works perfectly since nearly six > > > > years on my workstation. > > > > > > > > What kind of information do you need to figure out the problem and fix > > > > this regression? > > > > > > It would help to see a usbmon trace from 3.13 together with a usbmon > > > trace from an earlier, working kernel. (The instructions are in > > > Documentation/usb/usbmon.txt.) Start the usbmon trace just before you > > > plug in the flash device. > > > > > > Alan Stern > > > > > > > I did and attached the USB trace for 3.13.2 and for 3.12.7. > > > > One interesting thing was that the bus in 3.12.7 was sometimes 6 and > > sometimes 2. > I have more information about the bug. I tested with a USB 3.0 Expresscard and this works with 3.13. I also found an old USB 1.1 HUB in my USB gadget box. When i attach the USB flash storage to the USB 1.1 hub there is also no problem. Since the USB 1.1 Hub is attached to the EHCI we can assume that the bug is not in the phy support nor in the USB storage driver. So i thing the bug must be located in the EHCI HC driver. - Stefani -- 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: regression(ti platforms): next-20140210 (ehci?)
On 02/10/2014 11:50 AM, Roger Quadros wrote:
> +devicetree
>
[...]
> In the DT node we have compatible ids for both. e.g. for omap4.dtsi
>
> usbhsehci: ehci@4a064c00 {
> compatible = "ti,ehci-omap", "usb-ehci";
> reg = <0x4a064c00 0x400>;
> interrupt-parent = <&gic>;
> interrupts = ;
> };
>
> Shouldn't ehci-omap driver be getting a higher priority than usb-ehci?
>
> A quick fix would be to eliminate "usb-ehci" from the DT node of all failing
> platforms.
If the driver is not compatible with "usb-ehci", not sure why do we
even state that in dts node?
--
Regards,
Nishanth Menon
--
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: USB storage vanilla kernel 3.13 hang on DELL PRECISION M6400
Am Montag, den 10.02.2014, 12:09 -0500 schrieb Alan Stern: > On Mon, 10 Feb 2014, Stefani Seibold wrote: > > > Am Montag, den 10.02.2014, 10:56 -0500 schrieb Alan Stern: > > > On Mon, 10 Feb 2014, Stefani Seibold wrote: > > > > > > > Hi, > > > > > > > > the USB storage does not longer work on my DELL PRECISION M6400 with a > > > > plain vanilla 3.13 kernel. > > > > > > > > When i attach a USB storage flash memory the system freeze immediately > > > > or after accessing the flash. It makes not difference mounting via a > > > > GNOME desktop or mounting as root in a text console. > > > > > > > > There is no problem with all previous kernel like 3.12.7, everything is > > > > okay. > > > > > > > > All of the previous vanilla kernels works perfectly since nearly six > > > > years on my workstation. > > > > > > > > What kind of information do you need to figure out the problem and fix > > > > this regression? > > > > > > It would help to see a usbmon trace from 3.13 together with a usbmon > > > trace from an earlier, working kernel. (The instructions are in > > > Documentation/usb/usbmon.txt.) Start the usbmon trace just before you > > > plug in the flash device. > > > > > > Alan Stern > > > > > > > I did and attached the USB trace for 3.13.2 and for 3.12.7. > > > > One interesting thing was that the bus in 3.12.7 was sometimes 6 and > > sometimes 2. > > The bus number doesn't matter; it's allowed to change every time you > reboot. The bus change without a reboot! > > The two traces are almost identical. This is puzzling; I don't see any > significant differences at all. > The problem is that the machine complete freeze, so the dump stops. I get no crash log or anything else. The computer is still dead. Only the LED of the usb flash storage is very fast flashing. > It looks like you will have to use git bisect to find the change that > caused the regression. > That's to dangerous for me, because it is a production machine. - Stefani -- 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/misc/usbled: Add Riso Kagaku Webmail Notifier
Add support for the "Webmail Notifier" (USB powered LED for signaling
new emails) made by Riso Kagaku Corp. which displays 7 distinct colors.
USB Protocol initially reverse engineered by
https://code.google.com/p/usbmailnotifier/.
Signed-off-by: Christian Vogel
---
drivers/usb/misc/usbled.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/usb/misc/usbled.c b/drivers/usb/misc/usbled.c
index 12d03e7..8765fd6 100644
--- a/drivers/usb/misc/usbled.c
+++ b/drivers/usb/misc/usbled.c
@@ -23,8 +23,27 @@
enum led_type {
DELCOM_VISUAL_SIGNAL_INDICATOR,
DREAM_CHEEKY_WEBMAIL_NOTIFIER,
+ RISO_KAGAKU_LED
};
+/* the Webmail LED made by RISO KAGAKU CORP. decodes a color index
+ internally, we want to keep the red+green+blue sysfs api, so we decode
+ from 1-bit RGB to the riso kagaku color index according to this table... */
+
+static unsigned const char riso_kagaku_tbl[] = {
+/* R+2G+4B -> riso kagaku color index */
+ [0] = 0, /* black */
+ [1] = 2, /* red */
+ [2] = 1, /* green */
+ [3] = 5, /* yellow */
+ [4] = 3, /* blue*/
+ [5] = 6, /* magenta */
+ [6] = 4, /* cyan*/
+ [7] = 7 /* white */
+};
+
+#define RISO_KAGAKU_IX(r,g,b) riso_kagaku_tbl[((r)?1:0)+((g)?2:0)+((b)?4:0)]
+
/* table of devices that work with this driver */
static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x0fc5, 0x1223),
@@ -33,6 +52,8 @@ static const struct usb_device_id id_table[] = {
.driver_info = DREAM_CHEEKY_WEBMAIL_NOTIFIER },
{ USB_DEVICE(0x1d34, 0x000a),
.driver_info = DREAM_CHEEKY_WEBMAIL_NOTIFIER },
+ { USB_DEVICE(0x1294, 0x1320),
+ .driver_info = RISO_KAGAKU_LED },
{ },
};
MODULE_DEVICE_TABLE(usb, id_table);
@@ -49,6 +70,7 @@ static void change_color(struct usb_led *led)
{
int retval = 0;
unsigned char *buffer;
+ int actlength;
buffer = kmalloc(8, GFP_KERNEL);
if (!buffer) {
@@ -105,6 +127,18 @@ static void change_color(struct usb_led *led)
2000);
break;
+ case RISO_KAGAKU_LED:
+ buffer[0] = RISO_KAGAKU_IX(led->red, led->green, led->blue);
+ buffer[1] = 0;
+ buffer[2] = 0;
+ buffer[3] = 0;
+ buffer[4] = 0;
+
+ retval = usb_interrupt_msg(led->udev,
+ usb_sndctrlpipe(led->udev, 2),
+ buffer, 5, &actlength, 1000 /*ms timeout*/);
+ break;
+
default:
dev_err(&led->udev->dev, "unknown device type %d\n", led->type);
}
--
1.8.5.4
--
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: regression(ti platforms): next-20140210 (ehci?)
+devicetree
On 02/10/2014 05:59 PM, Nishanth Menon wrote:
> Hi,
>
> A quick note to report that I saw regression in today's next tag (logs
> indicate around EHCI) boot on various TI platforms:
>
> Note: crane and sdp2430 are not expected to pass with
> multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane
> but USB is disabled there)
>
> next-20140210-multi_v7_defconfig
> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zYHdPb94
> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2UChLyzSE
> 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s20Br9XLO1
> around ehci
>
> 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20mVz9Wc7
> around ehci
>
> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2byveBYtT
> 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21sOgJNwK
> around ehci
>
> 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2ovVNAmO7
> 8: crane: No Image built - Missing platform support?:
> 9: dra7: Boot PASS: http://slexy.org/raw/s217qwaXsM
> 10:ldp: Boot FAIL: http://slexy.org/raw/s203IvjE23
> around ehci
>
> 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ
> around ehci
I think the problem is that ehci-platform driver gets loaded instead of
ehci-omap.
In the DT node we have compatible ids for both. e.g. for omap4.dtsi
usbhsehci: ehci@4a064c00 {
compatible = "ti,ehci-omap", "usb-ehci";
reg = <0x4a064c00 0x400>;
interrupt-parent = <&gic>;
interrupts = ;
};
Shouldn't ehci-omap driver be getting a higher priority than usb-ehci?
A quick fix would be to eliminate "usb-ehci" from the DT node of all failing
platforms.
cheers,
-roger
>
> 12:sdp2430: Boot FAIL: expected (v6 platform)
> 13:sdp3430: Boot FAIL: http://slexy.org/raw/s21cwW7PqH
> around ehci
>
> 14:sdp4430: Boot PASS: http://slexy.org/raw/s2hL39Pyl9
> 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s20UsDeuVB
> TOTAL = 15 boards, Booted Boards = 7, No Boot boards = 8
>
> next-20140207-multi_v7_defconfig
> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2yo795okf
> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2TfAOi6XP
> 3: am3517-evm: Boot PASS: http://slexy.org/raw/s21sKT3pFN
> 4: am37x-evm: Boot PASS: http://slexy.org/raw/s21nCiNjAR
> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21uEu69lC
> 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s21SklkJs7
> 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s21aYZvPl7
> 8: crane: No Image built - Missing platform support?:
> 9: dra7: Boot PASS: http://slexy.org/raw/s20soGBbYz
> 10:ldp: Boot PASS: http://slexy.org/raw/s20lDIIwgN
> 11: PandaBoard-ES: Boot PASS: http://slexy.org/raw/s2a5NWPUtE
> 12:sdp2430: Boot FAIL: expected (v6 platform)
> 13:sdp3430: Boot PASS: http://slexy.org/raw/s2osagMVWZ
> 14:sdp4430: Boot PASS: http://slexy.org/raw/s2NxmpHFaW
> 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2PMcXzAUP
> TOTAL = 15 boards, Booted Boards = 13, No Boot boards = 2
>
> in comparison:
> v3.14-rc2-multi_v7_defconfig
> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2NWCJQczI
> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2566ZAl5d
> 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2msKg3ZQ9
> 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2898HemYQ
> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s20ajDkVgM
> 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s20YmD8SSG
> 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2sXDV7x0T
> 8: crane: No Image built - Missing platform support?:
> 9: dra7: Boot PASS: http://slexy.org/raw/s21Zz8NJrj
> 10:ldp: Boot PASS: http://slexy.org/raw/s21NANMvTx
> 11: PandaBoard-ES: Boot PASS: http://slexy.org/raw/s20NER4paD
> 12:sdp2430: Boot FAIL: expected (v6 platform)
> 13:sdp3430: Boot PASS: http://slexy.org/raw/s2WCHUl033
> 14:sdp4430: Boot PASS: http://slexy.org/raw/s21ySru6J1
> 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2kztuFoSu
> TOTAL = 15 boards, Booted Boards = 13, No Boot boards = 2
>
--
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 2/2] usbhid/quirks: Ignore Riso Kagaku Webmail Notifier
The "Webmail Notifier" is a USB controlled LED that appears as a HID
device. When trying to change the LED via hidraw it returns malformed
reports. As "usbled" supports it, we blacklist it in usbhid.
Signed-off-by: Christian Vogel
---
drivers/hid/hid-ids.h | 3 +++
drivers/hid/usbhid/hid-quirks.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index f9304cb..d936a9d 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -942,4 +942,7 @@
#define USB_VENDOR_ID_SIS 0x0457
#define USB_DEVICE_ID_SIS_TS 0x1013
+#define USB_VENDOR_ID_RISO_KAGAKU 0x1294 /* Riso Kagaku Corp. */
+#define USB_DEVICE_ID_RI_KA_WEBMAIL0x1320 /* Webmail Notifier */
+
#endif
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 0db9a67..0da367c 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -116,6 +116,8 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_SYNAPTICS, USB_DEVICE_ID_SYNAPTICS_LTS2,
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_SIS, USB_DEVICE_ID_SIS_TS, HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_RISO_KAGAKU, USB_DEVICE_ID_RI_KA_WEBMAIL,
HID_QUIRK_IGNORE }, /* handled by usbled */
+
{ 0, 0 }
};
--
1.8.5.4
--
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
Riso Kagaku Webmail Notifier: add to usbled, ignore in usbhid
Hi everyone, here's a updated patch. Part one adds the "Riso Kagaku Webmail Notifier" (a USB connected RGB-LED that pretends to be a HID) to the usbled.c module. Part two adds a USB quirk that makes the real usbhid ignore it. Greetings, Chris -- 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: USB storage vanilla kernel 3.13 hang on DELL PRECISION M6400
On Mon, 10 Feb 2014, Stefani Seibold wrote: > Am Montag, den 10.02.2014, 10:56 -0500 schrieb Alan Stern: > > On Mon, 10 Feb 2014, Stefani Seibold wrote: > > > > > Hi, > > > > > > the USB storage does not longer work on my DELL PRECISION M6400 with a > > > plain vanilla 3.13 kernel. > > > > > > When i attach a USB storage flash memory the system freeze immediately > > > or after accessing the flash. It makes not difference mounting via a > > > GNOME desktop or mounting as root in a text console. > > > > > > There is no problem with all previous kernel like 3.12.7, everything is > > > okay. > > > > > > All of the previous vanilla kernels works perfectly since nearly six > > > years on my workstation. > > > > > > What kind of information do you need to figure out the problem and fix > > > this regression? > > > > It would help to see a usbmon trace from 3.13 together with a usbmon > > trace from an earlier, working kernel. (The instructions are in > > Documentation/usb/usbmon.txt.) Start the usbmon trace just before you > > plug in the flash device. > > > > Alan Stern > > > > I did and attached the USB trace for 3.13.2 and for 3.12.7. > > One interesting thing was that the bus in 3.12.7 was sometimes 6 and > sometimes 2. The bus number doesn't matter; it's allowed to change every time you reboot. The two traces are almost identical. This is puzzling; I don't see any significant differences at all. It looks like you will have to use git bisect to find the change that caused the regression. 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 v3 1/1] USB: EHCI: wait more than 3ms until the device enters full-speed idle
On Fri, 7 Feb 2014, Peter Chen wrote:
> If the high-speed device does not enter full-speed idle after
> wakeup on disconnect logic has effected, there will be an
> unexpected disconnect wakeup interrupt due to the bus is still SE0.
>
> Signed-off-by: Peter Chen
>
> Hi Alan,
>
> If you can't met this issue, it may due to your hardware enables
> WKDN after detecting full-speed idle or the time between stop
> SoF and enable WKDN is more than 3ms (You need to know when
> the WKDN has really taken effect).
Yes. However, I don't like the way your patch can increase the total
time if several ports have to be put into suspend. Consider this patch
instead.
Alan Stern
Index: usb-3.14/drivers/usb/host/ehci-hub.c
===
--- usb-3.14.orig/drivers/usb/host/ehci-hub.c
+++ usb-3.14/drivers/usb/host/ehci-hub.c
@@ -238,6 +238,7 @@ static int ehci_bus_suspend (struct usb_
int port;
int mask;
int changed;
+ unsignedwant_WKDISC;
ehci_dbg(ehci, "suspend root hub\n");
@@ -272,6 +273,7 @@ static int ehci_bus_suspend (struct usb_
ehci->bus_suspended = 0;
ehci->owned_ports = 0;
changed = 0;
+ want_WKDISC = 0;
port = HCS_N_PORTS(ehci->hcs_params);
while (port--) {
u32 __iomem *reg = &ehci->regs->port_status [port];
@@ -300,16 +302,48 @@ static int ehci_bus_suspend (struct usb_
}
if (t1 != t2) {
+ /*
+* Don't enable wake-on-disconnect until the bus has
+* switched over to full-speed idle.
+*/
+ if ((t2 & PORT_WKDISC_E) &&
+ ehci_port_speed(ehci, t2) ==
+ USB_PORT_STAT_HIGH_SPEED) {
+ t2 &= ~PORT_WKDISC_E;
+ want_WKDISC |= (1 << port);
+ }
ehci_writel(ehci, t2, reg);
changed = 1;
}
}
+ spin_unlock_irq(&ehci->lock);
- if (changed && ehci->has_tdi_phy_lpm) {
- spin_unlock_irq(&ehci->lock);
- msleep(5); /* 5 ms for HCD to enter low-power mode */
+ if ((changed && ehci->has_tdi_phy_lpm) || want_WKDISC) {
+ /*
+* Wait for HCD to enter low-power mode or for the bus
+* to switch to full-speed idle.
+*/
+ usleep_range(5000, 5500);
+ }
+
+ if (want_WKDISC) {
spin_lock_irq(&ehci->lock);
+ port = HCS_N_PORTS(ehci->hcs_params);
+ while (port--) {
+ u32 __iomem *reg;
+ u32 t2;
+ if (!(want_WKDISC & (1 << port)))
+ continue;
+ reg = &ehci->regs->port_status[port];
+ t2 = ehci_readl(ehci, reg) & ~PORT_RWC_BITS;
+ ehci_writel(ehci, t2 | PORT_WKDISC_E, reg);
+ }
+ spin_unlock_irq(&ehci->lock);
+ }
+
+ if (changed && ehci->has_tdi_phy_lpm) {
+ spin_lock_irq(&ehci->lock);
port = HCS_N_PORTS(ehci->hcs_params);
while (port--) {
u32 __iomem *hostpc_reg = &ehci->regs->hostpc[port];
@@ -322,8 +356,8 @@ static int ehci_bus_suspend (struct usb_
port, (t3 & HOSTPC_PHCD) ?
"succeeded" : "failed");
}
+ spin_unlock_irq(&ehci->lock);
}
- spin_unlock_irq(&ehci->lock);
/* Apparently some devices need a >= 1-uframe delay here */
if (ehci->bus_suspended)
--
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: regression(ti platforms): next-20140210 (ehci?)
On 02/10/2014 10:11 AM, Roger Quadros wrote: > On 02/10/2014 05:59 PM, Nishanth Menon wrote: >> Hi, >> >> A quick note to report that I saw regression in today's next tag (logs >> indicate around EHCI) boot on various TI platforms: >> >> Note: crane and sdp2430 are not expected to pass with >> multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane >> but USB is disabled there) > > I'll take a look what's happening. Thanks. > Funny thing is that am335x doesn't even have an EHCI controller. I dont think any of the am335x platforms fail - just OMAP3,4 platforms which do fail. Side note: all platforms are tested with device tree boot (not the legacy boot). -- Regards, Nishanth Menon -- 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: To what repository do you commit your patches to?
On Mon, Feb 10, 2014 at 04:27:30PM +0100, Marco Zamponi wrote: > I looked the official linux kernel repo: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git Please look in the MAINTAINERS file for where the different subsystem git trees are located. greg k-h -- 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: regression(ti platforms): next-20140210 (ehci?)
Nishant, On 02/10/2014 05:59 PM, Nishanth Menon wrote: > Hi, > > A quick note to report that I saw regression in today's next tag (logs > indicate around EHCI) boot on various TI platforms: > > Note: crane and sdp2430 are not expected to pass with > multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane > but USB is disabled there) I'll take a look what's happening. Funny thing is that am335x doesn't even have an EHCI controller. cheers, -roger > > next-20140210-multi_v7_defconfig > 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zYHdPb94 > 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2UChLyzSE > 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s20Br9XLO1 > around ehci > > 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20mVz9Wc7 > around ehci > > 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2byveBYtT > 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21sOgJNwK > around ehci > > 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2ovVNAmO7 > 8: crane: No Image built - Missing platform support?: > 9: dra7: Boot PASS: http://slexy.org/raw/s217qwaXsM > 10:ldp: Boot FAIL: http://slexy.org/raw/s203IvjE23 > around ehci > > 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ > around ehci > > 12:sdp2430: Boot FAIL: expected (v6 platform) > 13:sdp3430: Boot FAIL: http://slexy.org/raw/s21cwW7PqH > around ehci > > 14:sdp4430: Boot PASS: http://slexy.org/raw/s2hL39Pyl9 > 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s20UsDeuVB > TOTAL = 15 boards, Booted Boards = 7, No Boot boards = 8 > > next-20140207-multi_v7_defconfig > 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2yo795okf > 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2TfAOi6XP > 3: am3517-evm: Boot PASS: http://slexy.org/raw/s21sKT3pFN > 4: am37x-evm: Boot PASS: http://slexy.org/raw/s21nCiNjAR > 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21uEu69lC > 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s21SklkJs7 > 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s21aYZvPl7 > 8: crane: No Image built - Missing platform support?: > 9: dra7: Boot PASS: http://slexy.org/raw/s20soGBbYz > 10:ldp: Boot PASS: http://slexy.org/raw/s20lDIIwgN > 11: PandaBoard-ES: Boot PASS: http://slexy.org/raw/s2a5NWPUtE > 12:sdp2430: Boot FAIL: expected (v6 platform) > 13:sdp3430: Boot PASS: http://slexy.org/raw/s2osagMVWZ > 14:sdp4430: Boot PASS: http://slexy.org/raw/s2NxmpHFaW > 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2PMcXzAUP > TOTAL = 15 boards, Booted Boards = 13, No Boot boards = 2 > > in comparison: > v3.14-rc2-multi_v7_defconfig > 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2NWCJQczI > 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2566ZAl5d > 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2msKg3ZQ9 > 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2898HemYQ > 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s20ajDkVgM > 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s20YmD8SSG > 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2sXDV7x0T > 8: crane: No Image built - Missing platform support?: > 9: dra7: Boot PASS: http://slexy.org/raw/s21Zz8NJrj > 10:ldp: Boot PASS: http://slexy.org/raw/s21NANMvTx > 11: PandaBoard-ES: Boot PASS: http://slexy.org/raw/s20NER4paD > 12:sdp2430: Boot FAIL: expected (v6 platform) > 13:sdp3430: Boot PASS: http://slexy.org/raw/s2WCHUl033 > 14:sdp4430: Boot PASS: http://slexy.org/raw/s21ySru6J1 > 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2kztuFoSu > TOTAL = 15 boards, Booted Boards = 13, No Boot boards = 2 > -- 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/2] usb/host/Kconfig: ohci- / ehci-platform make sure PHY_GENERIC is available
On Mon, 10 Feb 2014, Hans de Goede wrote: > Disallow ohci- / ehci-platform being built-in, when the phy core is build as > a module. > > Signed-off-by: Hans de Goede > --- > drivers/usb/host/Kconfig | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > index e28cbe0..1dd73e3 100644 > --- a/drivers/usb/host/Kconfig > +++ b/drivers/usb/host/Kconfig > @@ -255,7 +255,7 @@ config USB_EHCI_ATH79 > > config USB_EHCI_HCD_PLATFORM > tristate "Generic EHCI driver for a platform device" > - depends on !PPC_OF > + depends on !PPC_OF && (GENERIC_PHY || !GENERIC_PHY) > default n > ---help--- > Adds an EHCI host driver for a generic platform device, which > @@ -512,6 +512,7 @@ config USB_CNS3XXX_OHCI > > config USB_OHCI_HCD_PLATFORM > tristate "Generic OHCI driver for a platform device" > + depends on GENERIC_PHY || !GENERIC_PHY > default n > ---help--- > Adds an OHCI host driver for a generic platform device, which I would very much like to know of a more straightforward way to do this. Yann, can you suggest anything? 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
regression(ti platforms): next-20140210 (ehci?)
Hi, A quick note to report that I saw regression in today's next tag (logs indicate around EHCI) boot on various TI platforms: Note: crane and sdp2430 are not expected to pass with multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane but USB is disabled there) next-20140210-multi_v7_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zYHdPb94 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2UChLyzSE 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s20Br9XLO1 around ehci 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20mVz9Wc7 around ehci 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2byveBYtT 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21sOgJNwK around ehci 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2ovVNAmO7 8: crane: No Image built - Missing platform support?: 9: dra7: Boot PASS: http://slexy.org/raw/s217qwaXsM 10:ldp: Boot FAIL: http://slexy.org/raw/s203IvjE23 around ehci 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ around ehci 12:sdp2430: Boot FAIL: expected (v6 platform) 13:sdp3430: Boot FAIL: http://slexy.org/raw/s21cwW7PqH around ehci 14:sdp4430: Boot PASS: http://slexy.org/raw/s2hL39Pyl9 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s20UsDeuVB TOTAL = 15 boards, Booted Boards = 7, No Boot boards = 8 next-20140207-multi_v7_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2yo795okf 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2TfAOi6XP 3: am3517-evm: Boot PASS: http://slexy.org/raw/s21sKT3pFN 4: am37x-evm: Boot PASS: http://slexy.org/raw/s21nCiNjAR 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21uEu69lC 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s21SklkJs7 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s21aYZvPl7 8: crane: No Image built - Missing platform support?: 9: dra7: Boot PASS: http://slexy.org/raw/s20soGBbYz 10:ldp: Boot PASS: http://slexy.org/raw/s20lDIIwgN 11: PandaBoard-ES: Boot PASS: http://slexy.org/raw/s2a5NWPUtE 12:sdp2430: Boot FAIL: expected (v6 platform) 13:sdp3430: Boot PASS: http://slexy.org/raw/s2osagMVWZ 14:sdp4430: Boot PASS: http://slexy.org/raw/s2NxmpHFaW 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2PMcXzAUP TOTAL = 15 boards, Booted Boards = 13, No Boot boards = 2 in comparison: v3.14-rc2-multi_v7_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2NWCJQczI 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2566ZAl5d 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2msKg3ZQ9 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2898HemYQ 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s20ajDkVgM 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s20YmD8SSG 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2sXDV7x0T 8: crane: No Image built - Missing platform support?: 9: dra7: Boot PASS: http://slexy.org/raw/s21Zz8NJrj 10:ldp: Boot PASS: http://slexy.org/raw/s21NANMvTx 11: PandaBoard-ES: Boot PASS: http://slexy.org/raw/s20NER4paD 12:sdp2430: Boot FAIL: expected (v6 platform) 13:sdp3430: Boot PASS: http://slexy.org/raw/s2WCHUl033 14:sdp4430: Boot PASS: http://slexy.org/raw/s21ySru6J1 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2kztuFoSu TOTAL = 15 boards, Booted Boards = 13, No Boot boards = 2 -- Regards, Nishanth Menon -- 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: USB storage vanilla kernel 3.13 hang on DELL PRECISION M6400
On Mon, 10 Feb 2014, Stefani Seibold wrote: > Hi, > > the USB storage does not longer work on my DELL PRECISION M6400 with a > plain vanilla 3.13 kernel. > > When i attach a USB storage flash memory the system freeze immediately > or after accessing the flash. It makes not difference mounting via a > GNOME desktop or mounting as root in a text console. > > There is no problem with all previous kernel like 3.12.7, everything is > okay. > > All of the previous vanilla kernels works perfectly since nearly six > years on my workstation. > > What kind of information do you need to figure out the problem and fix > this regression? It would help to see a usbmon trace from 3.13 together with a usbmon trace from an earlier, working kernel. (The instructions are in Documentation/usb/usbmon.txt.) Start the usbmon trace just before you plug in the flash device. 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/2 v2] usbnet: fix bad header length bug
On Mon, Feb 10, 2014 at 02:05:20PM +0100, Bjørn Mork wrote: > Oliver Neukum writes: > > On Mon, 2014-02-10 at 13:00 +0100, Emil Goode wrote: > >> On Mon, Feb 10, 2014 at 07:40:58AM +0100, Oliver Neukum wrote: > > > >> > Well, then how about simply removing the check? > >> > It seems to have outlived its usefulness. > >> > > >> > Regards > >> > Oliver > >> > > >> > > >> > >> I did consider that and I think it is probably the best thing to do. > >> However, I think the removal of the check could have negative effects > >> on the other minidrivers, at least the qmi_wwan minidriver explicitly > >> states that it is depending on this check to be made in rx_complete(). > > > > . > > No need to do that. I had the exact same reaction myself :-) > > Anyway, I put that comment there mostly as a note to myself why the > check would be redundant at that point. I don't see any problem with > removing the generic check in usbnet as long as we add similar checks > whereever they are needed, like in qmi_wwan. I think it could be worth the trouble of removing the generic check in the usbnet module. I believe that if you define your own rx_fixup callback then the usbnet module should not make it's own assumptions on what packets to discard. Since the checks that need to be added in various places are all in the same subsystem I think it could be done in as little as one patch? > Note that usbnet_skb_return will be one of those places. It calls > eth_type_trans() on the skb, so it should verify that the length is at > least ETH_HLEN first. > > > Oh well. But how about merging it with FLAG_MULTI_PACKET? > > I really don't want to add more flags. There is a point where enough > > flags make absurd having a common code. We are closing in on that point. > > Agreed. I would even say we are past that point... If nobody have any objections I will try removing the generic check and introduce checks where nessecary. Best regards, Emil Goode -- 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 bandwidth calculation
On Mon, 10 Feb 2014, vichy wrote:
> >> 2. in tt_available, below is used to check whether tt time is bigger than
> >> 125us
> >> if (125 < usecs) {
> >> int ufs = (usecs / 125);
> >> int i;
> >> for (i = uframe; i < (uframe + ufs) && i < 8; i++)
> >> if (0 < tt_usecs[i]) {
> >> ehci_vdbg(ehci,
> >> "multi-uframe xfer can't fit "
> >> "in frame %d uframe %d\n",
> >> frame, i);
> >> return 0;
> >> }
> >> }
> >> is it possible tt time bigger than 1 uframe?
> >
> > Yes. Any isochronous transfer that is longer than 188 bytes will
> > require more than one uframe.
>
> from spec's explanation, the usecs in the above source is the budget
> calculated with Maxp instead of bandwidth indeed we need to transfer.
> Why it is still possible over 125us?
> for the case the ep max packet size over 188 bytes?
I don't understand your question.
At full speed (12 Mb/s), the time required to transfer 188 bytes is
(188 bytes) * (8 bits/byte) / (12 b/us) = 125.33 us,
which is greater than 125 us.
> > For each packet (token, data, and handshake), the overhead includes
> > inter-packet delay, cable delay, SYNC, bit-stuffing, and End-Of-Packet
> > -- all in addition to the PID, token, and CRC bytes.
> >
> > I don't know where you got that "13" from. If you assume the
> The 13 bytes I see is from usb spec section 5.8.4.
Then you must have noticed the sentence just above Table 5-9:
The table does not include the overhead associated with bit
stuffing.
The table also doesn't include the overhead associated with cable
delay and intermediate hubs.
> > inter-packet delays always require 1 byte time and count up the
> > inter-packet delays (3), SYNCs (3), token bytes (3), PID and CRC hytes
> > (3), and handshake (1), that adds up to 13 bytes of protocol overhead.
> > But it leaves out cable delay, bit-stuffing, and End-Of-Packet signals.
> >
> > You also have to remember that the spec allows the clock rate on
> > Full-Speed devices to vary by up to 0.25% of the nominal rate.
> so you mean FS speed will be 12M bits/s +- 3 bits/s?(3/12M = 0.25%)
That's right. Also, Low-Speed devices are allowed to vary by up to
1.5%, and High-Speed devices are allowed to vary by up to 0.05%.
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: PROBLEM: XHCI Host Controller on Intel Panther Point with CDC/ACM dead after massive NAK
On Mon, 10 Feb 2014, Kasberger Andreas wrote: > I saw the in the device endpoint ep82/ep83 at wMaxPacketSize a size "0040".� > > As far as I understand the "packet 7092" in wireshark with URB data > length 128 should not possible? What happens at such packets sizes? > Or does wireshark just joking me -- Wireshark adds 64 bytes of overhead to each packet it captures. 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: USB/IP
From: Greg KH > > I found it much easier to build a non-initrd kernel (ie one that > > has all the devices needed to boot builtin) than to work out > > how to build one that contains an initrd image. > > Then you are using the wrong distro, as a simple 'make install' in the > kernel directory should build the initrd for the kernel you are > installing, and install it in the bootloader properly. > > I suggest switching distros :) I want to build the kernel on a different system, not the one I'm doing the testing on. At one point I was copying test kernels out to several other systems. It is a bit 'fubar' because I have to run 'make install' and 'make modules-install' (specifying a specific target directory) to generate the files I need to copy to the test machine. Fortunately 'make install' generates everything before erroring out because it doesn't have root access. David -- 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: To what repository do you commit your patches to?
I looked the official linux kernel repo: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git On Fri, Feb 7, 2014 at 3:15 PM, Greg KH wrote: > On Fri, Feb 07, 2014 at 10:08:58AM +0100, Marco Zamponi wrote: >> I can't seem to find the place... > > Where did you look? -- 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: USB/IP
On Mon, Feb 10, 2014 at 09:52:52AM +, David Laight wrote: > From: Peter Stuge > > konst...@ngs.ru wrote: > > > If so, which linux distro is worth being chosen for > > > building and testing that custom kernel and, especially, > > > usbip, in particular, and does distro really matter? > > > > It depends on how much "value add" the distribution has around the > > kernel. > > > > The well-known distributions all use an initrd to bring userland up > > and they also have more or less distribution-specific bootloader > > management methods. > > I found it much easier to build a non-initrd kernel (ie one that > has all the devices needed to boot builtin) than to work out > how to build one that contains an initrd image. Then you are using the wrong distro, as a simple 'make install' in the kernel directory should build the initrd for the kernel you are installing, and install it in the bootloader properly. I suggest switching distros :) greg k-h -- 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] tools: usb: aio example applications
On Mon, Feb 10 2014, Robert Baldyga wrote:
> This patch adds two example applications showing usage of Asynchronous I/O API
> of FunctionFS. First one (aio_simple) is simple example of bidirectional data
> transfer. Second one (aio_multibuff) shows multi-buffer data transfer, which
> may to be used in high performance applications.
>
> Both examples contains userspace applications for device and for host.
> It needs libaio library on the device, and libusb library on host.
>
> Signed-off-by: Robert Baldyga
> ---
>
> Hello,
>
> This is fourth version of patch adding examples of use AIO API of FunctionFS.
>
> In this version I have solved active polling problem replaceing it with select
> function. It's possible because AIO API supports eventfd notification when
> events are available to read. Using selecti() on ep0 file need wait_queue
> support in its poll funcion. It's done in v5 of my patchset adding AIO support
> to FunctionFS.
Thanks, this looks much better!
> I have also fixed error handling in host application, and add some
> modifications to get rid of duplicated code.
>
> tools/usb/aio_multibuff/device_app/aio_multibuff.c | 335
>
> tools/usb/aio_multibuff/host_app/Makefile | 13 +
> tools/usb/aio_multibuff/host_app/test.c| 146 +
> tools/usb/aio_simple/device_app/aio_simple.c | 325 +++
> tools/usb/aio_simple/host_app/Makefile | 13 +
> tools/usb/aio_simple/host_app/test.c | 148 +
Perhaps a single
tools/usb/ffs-aio-example
directory would be better? It's not really clear what “aio_simple”
means and that it relates to FFS.
> diff --git a/tools/usb/aio_multibuff/device_app/aio_multibuff.c
> b/tools/usb/aio_multibuff/device_app/aio_multibuff.c
> +int main(int argc, char *argv[])
> +{
> + int ret;
> + unsigned i, j;
> + char *ep_path;
> +
> + int ep0, ep1;
> +
> + io_context_t ctx;
> +
> + int evfd;
> + fd_set rfds;
> +
> + struct io_buffer iobuf[2];
> + int actual;
> + bool ready;
> +
> + if (argc != 2) {
> + printf("ffs directory not specified!\n");
> + return 1;
> + }
> +
> + ep_path = malloc(strlen(argv[1]) + 4 /* "/ep#" */ + 1 /* '\0' */);
> + if (!ep_path) {
> + perror("malloc");
> + return 1;
> + }
> +
> + /* open endpoint files */
> + sprintf(ep_path, "%s/ep0", argv[1]);
> + ep0 = open(ep_path, O_RDWR);
> + if (ep0 < 0) {
> + perror("unable to open ep0");
> + return 1;
> + }
> + if (write(ep0, &descriptors, sizeof(descriptors)) < 0) {
> + perror("unable do write descriptors");
> + return 1;
> + }
> + if (write(ep0, &strings, sizeof(strings)) < 0) {
> + perror("unable to write strings");
> + return 1;
> + }
> + sprintf(ep_path, "%s/ep1", argv[1]);
> + ep1 = open(ep_path, O_RDWR);
> + if (ep1 < 0) {
> + perror("unable to open ep1");
> + return 1;
> + }
> +
> + free(ep_path);
> +
> + memset(&ctx, 0, sizeof(ctx));
> + /* setup aio context to handle up to AIO_MAX requests */
> + if (io_setup(AIO_MAX, &ctx) < 0) {
> + perror("unable to setup aio");
> + return 1;
> + }
> +
> + evfd = eventfd(0, 0);
> + if (evfd < 0) {
> + perror("unable to open eventfd");
> + return 1;
> + }
> +
> + for (i = 0; i < sizeof(iobuf)/sizeof(*iobuf); ++i)
> + init_bufs(&iobuf[i], BUFS_MAX, BUF_LEN);
> +
> + while (1) {
> + FD_ZERO(&rfds);
> + FD_SET(ep0, &rfds);
> + FD_SET(evfd, &rfds);
> +
> + ret = select(((ep0 > evfd) ? ep0 : evfd)+1,
> + &rfds, NULL, NULL, NULL);
> + if (ret < 0)
> + continue;
Perhaps
+ if (ret < 0) {
+ if (errno == EINTR)
+ continue;
+ perror("select");
+ return 1;
+ }
or something similar.
> +
> + if (FD_ISSET(ep0, &rfds))
> + handle_ep0(ep0, &ready);
> +
> + /* we are waiting for function ENABLE */
> + if (!ready)
> + continue;
> +
> + /*
> + * when we're preparing new data to submit,
> + * second buffer being transmitted
> + */
> + for (i = 0; i < sizeof(iobuf)/sizeof(*iobuf); ++i) {
> + if (iobuf[i].requested)
> + continue;
> + /* if all req's from iocb1 completed */
“1” in the comment is not needed now, i.e. it should be:
+/* if all reqs from iocb completed */
> + actual = (i+1)%(sizeof(iobuf)/sizeof(*iobuf));
I'm confused. Why is actual set
[PATCH 2/2] usb/host/Kconfig: Ensure all deps are met when selecting USB_HCD_?HCI_PLATFORM
Kconfig entries selecting another option must make sure all the selected options deps are met to avoid warnings like: warning: (USB_HCD_BCMA && USB_HCD_SSB && USB_CNS3XXX_EHCI && USB_EHCI_ATH79) selects USB_EHCI_HCD_PLATFORM which has unmet direct dependencies (USB_SUPPORT && USB && USB_EHCI_HCD && !PPC_OF) Signed-off-by: Hans de Goede --- drivers/usb/host/Kconfig | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 1dd73e3..0df261a 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -230,7 +230,7 @@ config USB_W90X900_EHCI config USB_CNS3XXX_EHCI bool "Cavium CNS3XXX EHCI Module (DEPRECATED)" - depends on ARCH_CNS3XXX + depends on ARCH_CNS3XXX && !PPC_OF && (GENERIC_PHY || !GENERIC_PHY) select USB_EHCI_HCD_PLATFORM ---help--- This option is deprecated now and the driver was removed, use @@ -243,6 +243,7 @@ config USB_CNS3XXX_EHCI config USB_EHCI_ATH79 bool "EHCI support for AR7XXX/AR9XXX SoCs (DEPRECATED)" depends on (SOC_AR71XX || SOC_AR724X || SOC_AR913X || SOC_AR933X) + depends on !PPC_OF && (GENERIC_PHY || !GENERIC_PHY) select USB_EHCI_ROOT_HUB_TT select USB_EHCI_HCD_PLATFORM default y @@ -709,7 +710,7 @@ config USB_OCTEON2_COMMON config USB_HCD_BCMA tristate "BCMA usb host driver" - depends on BCMA + depends on BCMA && !PPC_OF && (GENERIC_PHY || !GENERIC_PHY) select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD select USB_EHCI_HCD_PLATFORM if USB_EHCI_HCD help @@ -721,7 +722,7 @@ config USB_HCD_BCMA config USB_HCD_SSB tristate "SSB usb host driver" - depends on SSB + depends on SSB && !PPC_OF && (GENERIC_PHY || !GENERIC_PHY) select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD select USB_EHCI_HCD_PLATFORM if USB_EHCI_HCD help -- 1.8.5.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/host/Kconfig: Fix issues caused by recent ?hci-platform changes
Hi Greg et al, Here are 2 patches fixing Kconfig issues introduced by my ?hci-platform changes and found by the kbuild test robot. Note Kconfig is not my forte, so these patches may benefit from a review before you apply them. Thanks & Regards, Hans -- 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/host/Kconfig: ohci- / ehci-platform make sure PHY_GENERIC is available
Disallow ohci- / ehci-platform being built-in, when the phy core is build as a module. Signed-off-by: Hans de Goede --- drivers/usb/host/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index e28cbe0..1dd73e3 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -255,7 +255,7 @@ config USB_EHCI_ATH79 config USB_EHCI_HCD_PLATFORM tristate "Generic EHCI driver for a platform device" - depends on !PPC_OF + depends on !PPC_OF && (GENERIC_PHY || !GENERIC_PHY) default n ---help--- Adds an EHCI host driver for a generic platform device, which @@ -512,6 +512,7 @@ config USB_CNS3XXX_OHCI config USB_OHCI_HCD_PLATFORM tristate "Generic OHCI driver for a platform device" + depends on GENERIC_PHY || !GENERIC_PHY default n ---help--- Adds an OHCI host driver for a generic platform device, which -- 1.8.5.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
Re: [PATCH] UAS: fallback to storage if no streams are available
On Mon, 2014-02-10 at 14:55 +0100, Hans de Goede wrote: > Hi, > > On 02/10/2014 01:26 PM, Oliver Neukum wrote: > > On Mon, 2014-02-10 at 12:58 +0100, Hans de Goede wrote: > >> Hi, > >> > >> On 02/10/2014 07:32 AM, Oliver Neukum wrote: > >>> On Fri, 2014-02-07 at 10:18 -0500, Alan Stern wrote: > On Fri, 7 Feb 2014, Oliver Neukum wrote: > > > Hi, > > > > something like this? > > Patches in attachments are hard to review in email replies. > >>> > >>> Sorry. > >>> > Isn't this overkill? All you want to know is whether the bus supports > bulk streams. A single flag bit in the hcd structure would suffice; > you don't need to add a whole new method. > >>> > >>> You have a point. > >> > >> So I assume you're going to do a v2 moving to the flag construct? > > > > Yes, I am. I have a tendency to overengineer. But now I know > > what to do. > > Great, thanks! > > >> Having a fix ready for merging when this series gets merged into > >> 3.15 would be good. > > > > Understood. However, I request that you take the patch against UAS. > > It is conceptually a different bug, as it would be a bug (albeit minor) > > even if the storage driver didn't exist. > > uas_probe already calls uas_use_uas_driver() and if that fails already returns > -ENODEV, so as soon as you've fixed uas_use_uas_driver() to do the right > thing on xhci controllers which don't support streams, uas_probe will > correctly return -ENODEV for such controllers. OK, I see. I am making a patch and am going to test it. Regards Oliver -- 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 2/2] storage: accept some UAS devices if streams are unavailable
Hi,
On 02/10/2014 02:58 PM, oli...@neukum.org wrote:
> From: Oliver Neukum
>
> On some older XHCIs streams are not supported and the UAS driver
> will fail at probe time. For those devices storage should try
> to bind to UAS devices.
> This patch adds a flag for stream support to HCDs and evaluates
> it.
>
> Signed-off-by: Oliver Neukum
Looks good:
Acked-by: Hans de Goede
Sarah can you add this to the bulk-stream + uas patch-series for
3.15 please ?
Thanks & Regards,
Hans
> ---
> drivers/usb/host/xhci-pci.c | 3 +++
> drivers/usb/host/xhci-plat.c | 3 +++
> drivers/usb/storage/uas-detect.h | 4
> include/linux/usb/hcd.h | 1 +
> 4 files changed, 11 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index 73f5208..93d4895 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -223,6 +223,9 @@ static int xhci_pci_probe(struct pci_dev *dev, const
> struct pci_device_id *id)
> if (xhci->quirks & XHCI_LPM_SUPPORT)
> hcd_to_bus(xhci->shared_hcd)->root_hub->lpm_capable = 1;
>
> + if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
> + hcd->can_do_streams = 1;
> +
> return 0;
>
> put_usb3_hcd:
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index d9c169f..6e328ec 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -156,6 +156,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
>*/
> *((struct xhci_hcd **) xhci->shared_hcd->hcd_priv) = xhci;
>
> + if (HCC_MAX_PSA(xhci->hcc_params) >=4)
> + hcd->can_do_streams = 1;
> +
> ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
> if (ret)
> goto put_usb3_hcd;
> diff --git a/drivers/usb/storage/uas-detect.h
> b/drivers/usb/storage/uas-detect.h
> index b8a02e1..bb05b98 100644
> --- a/drivers/usb/storage/uas-detect.h
> +++ b/drivers/usb/storage/uas-detect.h
> @@ -72,6 +72,7 @@ static int uas_use_uas_driver(struct usb_interface *intf,
> {
> struct usb_host_endpoint *eps[4] = { };
> struct usb_device *udev = interface_to_usbdev(intf);
> + struct usb_hcd *hcd = bus_to_hcd(udev->bus);
> unsigned long flags = id->driver_info;
> int r, alt;
>
> @@ -80,6 +81,9 @@ static int uas_use_uas_driver(struct usb_interface *intf,
> if (flags & US_FL_IGNORE_UAS)
> return 0;
>
> + if (udev->speed >= USB_SPEED_SUPER && !hcd->can_do_streams)
> + return 0;
> +
> alt = uas_find_uas_alt_setting(intf);
> if (alt < 0)
> return 0;
> diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
> index fc64b68..c13024f 100644
> --- a/include/linux/usb/hcd.h
> +++ b/include/linux/usb/hcd.h
> @@ -142,6 +142,7 @@ struct usb_hcd {
> unsignedauthorized_default:1;
> unsignedhas_tt:1; /* Integrated TT in root hub */
> unsignedamd_resume_bug:1; /* AMD remote wakeup quirk */
> + unsignedcan_do_streams:1; /* HC supports streams */
>
> unsigned intirq;/* irq allocated */
> void __iomem*regs; /* device memory/io */
>
--
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 2/2] storage: accept some UAS devices if streams are unavailable
From: Oliver Neukum
On some older XHCIs streams are not supported and the UAS driver
will fail at probe time. For those devices storage should try
to bind to UAS devices.
This patch adds a flag for stream support to HCDs and evaluates
it.
Signed-off-by: Oliver Neukum
---
drivers/usb/host/xhci-pci.c | 3 +++
drivers/usb/host/xhci-plat.c | 3 +++
drivers/usb/storage/uas-detect.h | 4
include/linux/usb/hcd.h | 1 +
4 files changed, 11 insertions(+)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 73f5208..93d4895 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -223,6 +223,9 @@ static int xhci_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
if (xhci->quirks & XHCI_LPM_SUPPORT)
hcd_to_bus(xhci->shared_hcd)->root_hub->lpm_capable = 1;
+ if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
+ hcd->can_do_streams = 1;
+
return 0;
put_usb3_hcd:
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index d9c169f..6e328ec 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -156,6 +156,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
*/
*((struct xhci_hcd **) xhci->shared_hcd->hcd_priv) = xhci;
+ if (HCC_MAX_PSA(xhci->hcc_params) >=4)
+ hcd->can_do_streams = 1;
+
ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
if (ret)
goto put_usb3_hcd;
diff --git a/drivers/usb/storage/uas-detect.h b/drivers/usb/storage/uas-detect.h
index b8a02e1..bb05b98 100644
--- a/drivers/usb/storage/uas-detect.h
+++ b/drivers/usb/storage/uas-detect.h
@@ -72,6 +72,7 @@ static int uas_use_uas_driver(struct usb_interface *intf,
{
struct usb_host_endpoint *eps[4] = { };
struct usb_device *udev = interface_to_usbdev(intf);
+ struct usb_hcd *hcd = bus_to_hcd(udev->bus);
unsigned long flags = id->driver_info;
int r, alt;
@@ -80,6 +81,9 @@ static int uas_use_uas_driver(struct usb_interface *intf,
if (flags & US_FL_IGNORE_UAS)
return 0;
+ if (udev->speed >= USB_SPEED_SUPER && !hcd->can_do_streams)
+ return 0;
+
alt = uas_find_uas_alt_setting(intf);
if (alt < 0)
return 0;
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index fc64b68..c13024f 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -142,6 +142,7 @@ struct usb_hcd {
unsignedauthorized_default:1;
unsignedhas_tt:1; /* Integrated TT in root hub */
unsignedamd_resume_bug:1; /* AMD remote wakeup quirk */
+ unsignedcan_do_streams:1; /* HC supports streams */
unsigned intirq;/* irq allocated */
void __iomem*regs; /* device memory/io */
--
1.8.4
--
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] UAS: fallback to storage if no streams are available
Hi, On 02/10/2014 01:26 PM, Oliver Neukum wrote: > On Mon, 2014-02-10 at 12:58 +0100, Hans de Goede wrote: >> Hi, >> >> On 02/10/2014 07:32 AM, Oliver Neukum wrote: >>> On Fri, 2014-02-07 at 10:18 -0500, Alan Stern wrote: On Fri, 7 Feb 2014, Oliver Neukum wrote: > Hi, > > something like this? Patches in attachments are hard to review in email replies. >>> >>> Sorry. >>> Isn't this overkill? All you want to know is whether the bus supports bulk streams. A single flag bit in the hcd structure would suffice; you don't need to add a whole new method. >>> >>> You have a point. >> >> So I assume you're going to do a v2 moving to the flag construct? > > Yes, I am. I have a tendency to overengineer. But now I know > what to do. Great, thanks! >> Having a fix ready for merging when this series gets merged into >> 3.15 would be good. > > Understood. However, I request that you take the patch against UAS. > It is conceptually a different bug, as it would be a bug (albeit minor) > even if the storage driver didn't exist. uas_probe already calls uas_use_uas_driver() and if that fails already returns -ENODEV, so as soon as you've fixed uas_use_uas_driver() to do the right thing on xhci controllers which don't support streams, uas_probe will correctly return -ENODEV for such controllers. Regards, Hans -- 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: [RFC 1/2] usb: gadget: zero: Add support for interrupt EP
W dniu 10.02.2014 14:45, Andrzej Pietrasiewicz pisze:
W dniu 10.02.2014 14:16, Amit Virdi pisze:
/*
*and then attach the attributes to the config item;
* which translates to making new files appear in their
* directory
*/
static struct configfs_attribute *ss_attrs[] = {
&f_ss_opts_pattern.attr,
&f_ss_opts_isoc_interval.attr,
&f_ss_opts_isoc_maxpacket.attr,
&f_ss_opts_isoc_mult.attr,
&f_ss_opts_isoc_maxburst.attr,
&f_ss_opts_bulk_buflen.attr,
/* HERE */
&f_ss_opts_isoc_interval.attr,
of course:
&f_ss_opts_int_interval.attr,
NULL,
};
AP
--
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
--
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: [RFC 1/2] usb: gadget: zero: Add support for interrupt EP
W dniu 10.02.2014 14:16, Amit Virdi pisze:
Interrupt endpoints behave quite similar to the bulk endpoints with the
difference that the endpoints expect data sending/reception request at
particular intervals till the whole data has not been transmitted.
The interrupt EP support is added to gadget zero. A new alternate setting (=2)
has been added. It has 6 endpoints (2-BULK, 2-ISOC, 2-INTERRUPT). The default
parameters are set as:
bInterval: 4
wMaxPacketSize: 1024
However, the same can be overridden through the module parameter interface.
The module parameter interface is available only in legacy mode,
that is using g_zero.ko. Both sourcesink and loopback now support
configfs.
The code is tested for HS and SS on a platform having DWC3 controller.
Signed-off-by: Amit Virdi
+static unsigned int_interval;
+static unsigned int_maxpacket;
+static unsigned int_mult;
+static unsigned int_maxburst;
For these you need appropriate configfs attributes (files).
Below there is a typical way to create the attributes.
/*
* "show" means to copy data from kernel to user;
* you get the opts pointer and copy the relevant data to the page
*/
static ssize_t f_ss_opts_pattern_show(struct f_ss_opts *opts, char *page)
{
int result;
mutex_lock(&opts->lock);
result = sprintf(page, "%d", opts->pattern);
mutex_unlock(&opts->lock);
return result;
}
/*
* "store" means to copy data from user to the kernel;
* you take data from the page and interpret it;
* if it is ok, you store it in the opts
*/
static ssize_t f_ss_opts_pattern_store(struct f_ss_opts *opts,
const char *page, size_t len)
{
int ret;
u8 num;
mutex_lock(&opts->lock);
if (opts->refcnt) {
ret = -EBUSY;
goto end;
}
ret = kstrtou8(page, 0, &num);
if (ret)
goto end;
if (num != 0 && num != 1 && num != 2) {
ret = -EINVAL;
goto end;
}
opts->pattern = num;
ret = len;
end:
mutex_unlock(&opts->lock);
return ret;
}
static struct f_ss_opts_attribute f_ss_opts_pattern =
__CONFIGFS_ATTR(pattern, S_IRUGO | S_IWUSR,
f_ss_opts_pattern_show,
f_ss_opts_pattern_store);
/*
* definitions of f_ss_opts_isoc_interval & co follow
*/
...
/*
* hereyou should create your implementations of
* f_ss_opts_int_interval_show/store & co
*/
/*
*and then attach the attributes to the config item;
* which translates to making new files appear in their
* directory
*/
static struct configfs_attribute *ss_attrs[] = {
&f_ss_opts_pattern.attr,
&f_ss_opts_isoc_interval.attr,
&f_ss_opts_isoc_maxpacket.attr,
&f_ss_opts_isoc_mult.attr,
&f_ss_opts_isoc_maxburst.attr,
&f_ss_opts_bulk_buflen.attr,
/* HERE */
&f_ss_opts_isoc_interval.attr,
NULL,
};
AP
--
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
[RFC 2/2] usbtest: Add interrupt EP testcases
Two simple test cases for interrupt endpoints are added to the usbtest.c file.
These are simple non-queued interrupt IN and interrupt OUT transfers. Currently,
only gadget zero is capable of executing the interrupt EP test cases. However,
extending the same to other gadgets is extremely simple and can be done
on-demand.
This code has been tested only with gadget zero and care has been taken so as to
not break the existing functionality. However, if anyone can test with other
gadgets then that would be great!
Signed-off-by: Amit Virdi
---
drivers/usb/misc/usbtest.c | 112 +++--
1 file changed, 97 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index f6568b5..8b96235 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -54,6 +54,7 @@ struct usbtest_info {
unsignedautoconf:1;
unsignedctrl_out:1;
unsignediso:1; /* try iso in/out */
+ unsignedintr:1; /* try interrupt in/out */
int alt;
};
@@ -70,7 +71,10 @@ struct usbtest_dev {
int out_pipe;
int in_iso_pipe;
int out_iso_pipe;
+ int in_int_pipe;
+ int out_int_pipe;
struct usb_endpoint_descriptor *iso_in, *iso_out;
+ struct usb_endpoint_descriptor *int_in, *int_out;
struct mutexlock;
#define TBUF_SIZE 256
@@ -101,6 +105,7 @@ get_endpoints(struct usbtest_dev *dev, struct usb_interface
*intf)
struct usb_host_interface *alt;
struct usb_host_endpoint*in, *out;
struct usb_host_endpoint*iso_in, *iso_out;
+ struct usb_host_endpoint*int_in, *int_out;
struct usb_device *udev;
for (tmp = 0; tmp < intf->num_altsetting; tmp++) {
@@ -108,6 +113,7 @@ get_endpoints(struct usbtest_dev *dev, struct usb_interface
*intf)
in = out = NULL;
iso_in = iso_out = NULL;
+ int_in = int_out = NULL;
alt = intf->altsetting + tmp;
if (override_alt >= 0 &&
@@ -124,6 +130,9 @@ get_endpoints(struct usbtest_dev *dev, struct usb_interface
*intf)
switch (usb_endpoint_type(&e->desc)) {
case USB_ENDPOINT_XFER_BULK:
break;
+ case USB_ENDPOINT_XFER_INT:
+ if (dev->info->intr)
+ goto try_intr;
case USB_ENDPOINT_XFER_ISOC:
if (dev->info->iso)
goto try_iso;
@@ -139,6 +148,14 @@ get_endpoints(struct usbtest_dev *dev, struct
usb_interface *intf)
out = e;
}
continue;
+try_intr:
+ if (usb_endpoint_dir_in(&e->desc)) {
+ if (!int_in)
+ int_in = e;
+ } else {
+ if (!int_out)
+ int_out = e;
+ }
try_iso:
if (usb_endpoint_dir_in(&e->desc)) {
if (!iso_in)
@@ -148,7 +165,7 @@ try_iso:
iso_out = e;
}
}
- if ((in && out) || iso_in || iso_out)
+ if ((in && out) || iso_in || iso_out || int_in || int_out)
goto found;
}
return -EINVAL;
@@ -183,6 +200,20 @@ found:
iso_out->desc.bEndpointAddress
& USB_ENDPOINT_NUMBER_MASK);
}
+
+ if (int_in) {
+ dev->int_in = &int_in->desc;
+ dev->in_int_pipe = usb_rcvintpipe(udev,
+ int_in->desc.bEndpointAddress
+ & USB_ENDPOINT_NUMBER_MASK);
+ }
+
+ if (int_out) {
+ dev->int_out = &int_out->desc;
+ dev->out_int_pipe = usb_sndintpipe(udev,
+ int_out->desc.bEndpointAddress
+ & USB_ENDPOINT_NUMBER_MASK);
+ }
return 0;
}
@@ -205,14 +236,22 @@ static struct urb *usbtest_alloc_urb(
int pipe,
unsigned long bytes,
unsignedtransfer_flags,
- unsignedoffset)
+ unsignedoffset,
+ u8 bInterval)
{
struct urb *urb;
urb = usb_alloc_urb(0, GFP_KERNEL);
if (!urb)
[RFC 0/2] usb: g_zero: Add support for interrupt EP
This patchset adds interrupt EP support to gadget zero and subsequently adds corresponding test cases to usbtest.c Amit Virdi (2): usb: gadget: zero: Add support for interrupt EP usbtest: Add interrupt EP testcases drivers/usb/gadget/f_loopback.c | 3 +- drivers/usb/gadget/f_sourcesink.c | 339 +++--- drivers/usb/gadget/g_zero.h | 13 +- drivers/usb/gadget/zero.c | 21 +++ drivers/usb/misc/usbtest.c| 112 +++-- 5 files changed, 450 insertions(+), 38 deletions(-) -- 1.8.0 -- 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
[RFC 1/2] usb: gadget: zero: Add support for interrupt EP
Interrupt endpoints behave quite similar to the bulk endpoints with the
difference that the endpoints expect data sending/reception request at
particular intervals till the whole data has not been transmitted.
The interrupt EP support is added to gadget zero. A new alternate setting (=2)
has been added. It has 6 endpoints (2-BULK, 2-ISOC, 2-INTERRUPT). The default
parameters are set as:
bInterval: 4
wMaxPacketSize: 1024
However, the same can be overridden through the module parameter interface.
The code is tested for HS and SS on a platform having DWC3 controller.
Signed-off-by: Amit Virdi
---
drivers/usb/gadget/f_loopback.c | 3 +-
drivers/usb/gadget/f_sourcesink.c | 339 +++---
drivers/usb/gadget/g_zero.h | 13 +-
drivers/usb/gadget/zero.c | 21 +++
4 files changed, 353 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/gadget/f_loopback.c b/drivers/usb/gadget/f_loopback.c
index 4557cd0..bf04389 100644
--- a/drivers/usb/gadget/f_loopback.c
+++ b/drivers/usb/gadget/f_loopback.c
@@ -298,7 +298,8 @@ static void disable_loopback(struct f_loopback *loop)
struct usb_composite_dev*cdev;
cdev = loop->function.config->cdev;
- disable_endpoints(cdev, loop->in_ep, loop->out_ep, NULL, NULL);
+ disable_endpoints(cdev, loop->in_ep, loop->out_ep, NULL, NULL, NULL,
+ NULL);
VDBG(cdev, "%s disabled\n", loop->function.name);
}
diff --git a/drivers/usb/gadget/f_sourcesink.c
b/drivers/usb/gadget/f_sourcesink.c
index d3cd52d..89e 100644
--- a/drivers/usb/gadget/f_sourcesink.c
+++ b/drivers/usb/gadget/f_sourcesink.c
@@ -23,6 +23,13 @@
#include "gadget_chips.h"
#include "u_f.h"
+enum eptype {
+ EP_CONTROL = 0,
+ EP_BULK,
+ EP_ISOC,
+ EP_INTERRUPT,
+};
+
/*
* SOURCE/SINK FUNCTION ... a primary testing vehicle for USB peripheral
* controller drivers.
@@ -55,6 +62,8 @@ struct f_sourcesink {
struct usb_ep *out_ep;
struct usb_ep *iso_in_ep;
struct usb_ep *iso_out_ep;
+ struct usb_ep *int_in_ep;
+ struct usb_ep *int_out_ep;
int cur_alt;
};
@@ -68,6 +77,10 @@ static unsigned isoc_interval;
static unsigned isoc_maxpacket;
static unsigned isoc_mult;
static unsigned isoc_maxburst;
+static unsigned int_interval;
+static unsigned int_maxpacket;
+static unsigned int_mult;
+static unsigned int_maxburst;
static unsigned buflen;
/*-*/
@@ -92,6 +105,16 @@ static struct usb_interface_descriptor
source_sink_intf_alt1 = {
/* .iInterface = DYNAMIC */
};
+static struct usb_interface_descriptor source_sink_intf_alt2 = {
+ .bLength = USB_DT_INTERFACE_SIZE,
+ .bDescriptorType = USB_DT_INTERFACE,
+
+ .bAlternateSetting =2,
+ .bNumEndpoints =6,
+ .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
+ /* .iInterface = DYNAMIC */
+};
+
/* full speed support: */
static struct usb_endpoint_descriptor fs_source_desc = {
@@ -130,6 +153,26 @@ static struct usb_endpoint_descriptor fs_iso_sink_desc = {
.bInterval =4,
};
+static struct usb_endpoint_descriptor fs_int_source_desc = {
+ .bLength = USB_DT_ENDPOINT_SIZE,
+ .bDescriptorType = USB_DT_ENDPOINT,
+
+ .bEndpointAddress = USB_DIR_IN,
+ .bmAttributes = USB_ENDPOINT_XFER_INT,
+ .wMaxPacketSize = cpu_to_le16(1023),
+ .bInterval =4,
+};
+
+static struct usb_endpoint_descriptor fs_int_sink_desc = {
+ .bLength = USB_DT_ENDPOINT_SIZE,
+ .bDescriptorType = USB_DT_ENDPOINT,
+
+ .bEndpointAddress = USB_DIR_OUT,
+ .bmAttributes = USB_ENDPOINT_XFER_INT,
+ .wMaxPacketSize = cpu_to_le16(1023),
+ .bInterval =4,
+};
+
static struct usb_descriptor_header *fs_source_sink_descs[] = {
(struct usb_descriptor_header *) &source_sink_intf_alt0,
(struct usb_descriptor_header *) &fs_sink_desc,
@@ -140,6 +183,14 @@ static struct usb_descriptor_header
*fs_source_sink_descs[] = {
(struct usb_descriptor_header *) &fs_source_desc,
(struct usb_descriptor_header *) &fs_iso_sink_desc,
(struct usb_descriptor_header *) &fs_iso_source_desc,
+ (struct usb_descriptor_header *) &source_sink_intf_alt2,
+#define FS_ALT_IFC_2_OFFSET8
+ (struct usb_descriptor_header *) &fs_sink_desc,
+ (struct usb_descriptor_header *) &fs_source_desc,
+ (struct usb_descriptor_header *) &fs_iso_sink_desc,
+ (struct usb_descriptor_header *) &fs_iso_source_desc,
+ (struct usb_descriptor_header *) &fs_int_sink_desc,
+ (struct usb_descriptor_header *) &fs_int_source_desc,
NULL,
};
@@ -179,6 +230,24 @@ static struct usb_
Re: [PATCH 1/2 v2] usbnet: fix bad header length bug
Oliver Neukum writes: > On Mon, 2014-02-10 at 13:00 +0100, Emil Goode wrote: >> On Mon, Feb 10, 2014 at 07:40:58AM +0100, Oliver Neukum wrote: > >> > Well, then how about simply removing the check? >> > It seems to have outlived its usefulness. >> > >> >Regards >> >Oliver >> > >> > >> >> I did consider that and I think it is probably the best thing to do. >> However, I think the removal of the check could have negative effects >> on the other minidrivers, at least the qmi_wwan minidriver explicitly >> states that it is depending on this check to be made in rx_complete(). > > . No need to do that. I had the exact same reaction myself :-) Anyway, I put that comment there mostly as a note to myself why the check would be redundant at that point. I don't see any problem with removing the generic check in usbnet as long as we add similar checks whereever they are needed, like in qmi_wwan. Note that usbnet_skb_return will be one of those places. It calls eth_type_trans() on the skb, so it should verify that the length is at least ETH_HLEN first. > Oh well. But how about merging it with FLAG_MULTI_PACKET? > I really don't want to add more flags. There is a point where enough > flags make absurd having a common code. We are closing in on that point. Agreed. I would even say we are past that point... Bjørn -- 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 bandwidth calculation
hi Alan:
2014-02-07 23:40 GMT+08:00 Alan Stern :
> On Fri, 7 Feb 2014, vichy wrote:
>
>> Hi Alan:
>>
>> 2014-01-31 2:23 GMT+08:00 Alan Stern :
>> > On Fri, 31 Jan 2014, vichy wrote:
>> >
>> >> Hi all:
>> >> I have some questions about bandwidth calculation
>> >> 1. why tt time need to include one maxp bus time ?
>> >> qh->tt_usecs = NS_TO_US (think_time +
>> >> usb_calc_bus_time (urb->dev->speed,
>> >> is_input, 0, max_packet (maxp)));
>> >
>> > Because tt_usecs is the time required to send a maximum-size packet.
>> > So of course you have to include the maxp bus time.
>> is it the requirement defined in spec?
>> if so, would you please tell me where I can find it?
>
> Section 11.18.2 (last paragraph on p. 373):
>
> The host always uses the maximum data payload size for a
> full-/low-speed endpoint in doing its budgeting.
>> 2. in tt_available, below is used to check whether tt time is bigger than
>> 125us
>> if (125 < usecs) {
>> int ufs = (usecs / 125);
>> int i;
>> for (i = uframe; i < (uframe + ufs) && i < 8; i++)
>> if (0 < tt_usecs[i]) {
>> ehci_vdbg(ehci,
>> "multi-uframe xfer can't fit "
>> "in frame %d uframe %d\n",
>> frame, i);
>> return 0;
>> }
>> }
>> is it possible tt time bigger than 1 uframe?
>
> Yes. Any isochronous transfer that is longer than 188 bytes will
> require more than one uframe.
from spec's explanation, the usecs in the above source is the budget
calculated with Maxp instead of bandwidth indeed we need to transfer.
Why it is still possible over 125us?
for the case the ep max packet size over 188 bytes?
>
>> >> 3. below is the fomula to calculate bus time
>> >> Full-speed (Input)
>> >> Non-Isochronous Transfer (Handshake Included)
>> >> = 9107 + (83.54 * Floor(3.167 + BitStuffTime(Data_bc))) + Host_Delay
>> >> what is 9107 and 3.167 used for?
>> >> (9102 is not equal to FS bit time * FS protocol overhead)
>> >
>> > 9107 is the overhead. It includes things like inter-packet delays, the
>> > IN or OUT token packet, the ACK packet, and so on.
>> in spec I only find the formula, but spec didn't tell where this 9107 come
>> from?
>
> No, it doesn't. And in fact, the values in the spec are wrong because
> they don't take into account the delays caused by intermediate hubs.
>
>> take Full buck for example, which is non-iso, the protocol overhead is
>> only 13Bytes.
>
> What do you mean by "Full buck"?
sorry it is my typo, I mean FS bulk.
>
> For each packet (token, data, and handshake), the overhead includes
> inter-packet delay, cable delay, SYNC, bit-stuffing, and End-Of-Packet
> -- all in addition to the PID, token, and CRC bytes.
>
> I don't know where you got that "13" from. If you assume the
The 13 bytes I see is from usb spec section 5.8.4.
> inter-packet delays always require 1 byte time and count up the
> inter-packet delays (3), SYNCs (3), token bytes (3), PID and CRC hytes
> (3), and handshake (1), that adds up to 13 bytes of protocol overhead.
> But it leaves out cable delay, bit-stuffing, and End-Of-Packet signals.
>
> You also have to remember that the spec allows the clock rate on
> Full-Speed devices to vary by up to 0.25% of the nominal rate.
so you mean FS speed will be 12M bits/s +- 3 bits/s?(3/12M = 0.25%)
Appreciate your 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
RE: [PATCH 1/2 v2] usbnet: fix bad header length bug
From: Oliver Neukum > . Oh well. But how about merging it with FLAG_MULTI_PACKET? > I really don't want to add more flags. There is a point where enough > flags make absurd having a common code. We are closing in on that point. Any sub-driver that supports multi-packet either has to use stupidly long URB and/or set the rx_urb_size to a multiple of the usb transfer size. It will also have to detect illegal short headers. Actually it might be worth double-checking the encapsulations used. IIRC the ax88179_178a uses different headers for tx and rx. So there might be some that support multi-packet but still have a short(ish) limit on the bulk receive size (before the short fragment). I'm sat at the wrong desk to look at the code... David
Re: [PATCH] UAS: fallback to storage if no streams are available
On Mon, 2014-02-10 at 12:58 +0100, Hans de Goede wrote: > Hi, > > On 02/10/2014 07:32 AM, Oliver Neukum wrote: > > On Fri, 2014-02-07 at 10:18 -0500, Alan Stern wrote: > >> On Fri, 7 Feb 2014, Oliver Neukum wrote: > >> > >>> Hi, > >>> > >>> something like this? > >> > >> Patches in attachments are hard to review in email replies. > > > > Sorry. > > > >> Isn't this overkill? All you want to know is whether the bus supports > >> bulk streams. A single flag bit in the hcd structure would suffice; > >> you don't need to add a whole new method. > > > > You have a point. > > So I assume you're going to do a v2 moving to the flag construct? Yes, I am. I have a tendency to overengineer. But now I know what to do. > Having a fix ready for merging when this series gets merged into > 3.15 would be good. Understood. However, I request that you take the patch against UAS. It is conceptually a different bug, as it would be a bug (albeit minor) even if the storage driver didn't exist. Regards Oliver -- 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/2 v2] usbnet: fix bad header length bug
On Mon, 2014-02-10 at 13:00 +0100, Emil Goode wrote: > On Mon, Feb 10, 2014 at 07:40:58AM +0100, Oliver Neukum wrote: > > On Mon, 2014-02-10 at 00:06 +0100, Emil Goode wrote: > > > The AX88772B occasionally send rx packets that cross urb boundaries > > > and the remaining partial packet is sent with no hardware header. > > > When the buffer with a partial packet is of less number of octets > > > than the value of hard_header_len the buffer is discarded by the > > > usbnet module. This is causing dropped packages and error messages > > > in dmesg. > > > > > > This can be reproduced by using ping with a packet size > > > between 1965-1976. > > > > Well, then how about simply removing the check? > > It seems to have outlived its usefulness. > > > > Regards > > Oliver > > > > > > I did consider that and I think it is probably the best thing to do. > However, I think the removal of the check could have negative effects > on the other minidrivers, at least the qmi_wwan minidriver explicitly > states that it is depending on this check to be made in rx_complete(). . Oh well. But how about merging it with FLAG_MULTI_PACKET? I really don't want to add more flags. There is a point where enough flags make absurd having a common code. We are closing in on that point. Regards Oliver -- 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] UAS: fallback to storage if no streams are available
Hi, On 02/10/2014 07:32 AM, Oliver Neukum wrote: > On Fri, 2014-02-07 at 10:18 -0500, Alan Stern wrote: >> On Fri, 7 Feb 2014, Oliver Neukum wrote: >> >>> Hi, >>> >>> something like this? >> >> Patches in attachments are hard to review in email replies. > > Sorry. > >> Isn't this overkill? All you want to know is whether the bus supports >> bulk streams. A single flag bit in the hcd structure would suffice; >> you don't need to add a whole new method. > > You have a point. So I assume you're going to do a v2 moving to the flag construct? Having a fix ready for merging when this series gets merged into 3.15 would be good. Thanks & Regards, Hans -- 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/2 v2] usbnet: fix bad header length bug
On Mon, Feb 10, 2014 at 07:40:58AM +0100, Oliver Neukum wrote: > On Mon, 2014-02-10 at 00:06 +0100, Emil Goode wrote: > > The AX88772B occasionally send rx packets that cross urb boundaries > > and the remaining partial packet is sent with no hardware header. > > When the buffer with a partial packet is of less number of octets > > than the value of hard_header_len the buffer is discarded by the > > usbnet module. This is causing dropped packages and error messages > > in dmesg. > > > > This can be reproduced by using ping with a packet size > > between 1965-1976. > > Well, then how about simply removing the check? > It seems to have outlived its usefulness. > > Regards > Oliver > > I did consider that and I think it is probably the best thing to do. However, I think the removal of the check could have negative effects on the other minidrivers, at least the qmi_wwan minidriver explicitly states that it is depending on this check to be made in rx_complete(). For safety the check could be added at the top of the rx_fixup callback of the affected minidrivers. There are devices that depend on the usbnet module that do not have a rx_fixup callback assigned to it's driver_info struct, the check could be added for these in the rx_process function. This led me to think it would be a lot of noise about a small check :) My conclusion is that 12 rx_fixup callbacks might need the check to be added. There are 18 driver_info structs with no rx_fixup callback assigned, these devices might need the check to be added to the rx_process function. Patches could be sent out to notify the affected minidrivers of the change and hopefully someone has the hardware to test if it's necessary to add the check to the minidriver? I'm happy to do this if it seem like a good idea. Best regards, Emil Goode -- 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: PROBLEM: XHCI Host Controller on Intel Panther Point with CDC/ACM dead after massive NAK
I saw the in the device endpoint ep82/ep83 at wMaxPacketSize a size "0040". As far as I understand the "packet 7092" in wireshark with URB data length 128 should not possible? What happens at such packets sizes? Or does wireshark just joking me -- 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 v4] tools: usb: aio example applications
This patch adds two example applications showing usage of Asynchronous I/O API
of FunctionFS. First one (aio_simple) is simple example of bidirectional data
transfer. Second one (aio_multibuff) shows multi-buffer data transfer, which
may to be used in high performance applications.
Both examples contains userspace applications for device and for host.
It needs libaio library on the device, and libusb library on host.
Signed-off-by: Robert Baldyga
---
Hello,
This is fourth version of patch adding examples of use AIO API of FunctionFS.
In this version I have solved active polling problem replaceing it with select
function. It's possible because AIO API supports eventfd notification when
events are available to read. Using selecti() on ep0 file need wait_queue
support in its poll funcion. It's done in v5 of my patchset adding AIO support
to FunctionFS.
I have also fixed error handling in host application, and add some
modifications to get rid of duplicated code.
Best regards
Robert Baldyga
Samsung R&D Institute Poland
Changelog:
v4:
- fix error handling in host applications
- replace busy waiting with select function
- cleanup code, remove duplicated code, move structure definitions
and #defines to top on file
v3: http://www.spinics.net/lists/linux-usb/msg101723.html
- get rid of global variables
- add missing error handling
- fix some style problems
v2: http://www.spinics.net/lists/linux-usb/msg101650.html
- cleanup code
- a lot of small fixes
v1: http://www.spinics.net/lists/linux-usb/msg101614.html
tools/usb/aio_multibuff/device_app/aio_multibuff.c | 335
tools/usb/aio_multibuff/host_app/Makefile | 13 +
tools/usb/aio_multibuff/host_app/test.c| 146 +
tools/usb/aio_simple/device_app/aio_simple.c | 325 +++
tools/usb/aio_simple/host_app/Makefile | 13 +
tools/usb/aio_simple/host_app/test.c | 148 +
6 files changed, 980 insertions(+)
create mode 100644 tools/usb/aio_multibuff/device_app/aio_multibuff.c
create mode 100644 tools/usb/aio_multibuff/host_app/Makefile
create mode 100644 tools/usb/aio_multibuff/host_app/test.c
create mode 100644 tools/usb/aio_simple/device_app/aio_simple.c
create mode 100644 tools/usb/aio_simple/host_app/Makefile
create mode 100644 tools/usb/aio_simple/host_app/test.c
diff --git a/tools/usb/aio_multibuff/device_app/aio_multibuff.c
b/tools/usb/aio_multibuff/device_app/aio_multibuff.c
new file mode 100644
index 000..66d6f2c
--- /dev/null
+++ b/tools/usb/aio_multibuff/device_app/aio_multibuff.c
@@ -0,0 +1,335 @@
+#define _BSD_SOURCE /* for endian.h */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "libaio.h"
+#define IOCB_FLAG_RESFD (1 << 0)
+
+#include
+
+#define BUF_LEN8192
+#define BUFS_MAX 128
+#define AIO_MAX(BUFS_MAX*2)
+
+/ Descriptors and Strings ***/
+
+static const struct {
+ struct usb_functionfs_descs_head header;
+ struct {
+ struct usb_interface_descriptor intf;
+ struct usb_endpoint_descriptor_no_audio bulk_sink;
+ struct usb_endpoint_descriptor_no_audio bulk_source;
+ } __attribute__ ((__packed__)) fs_descs, hs_descs;
+} __attribute__ ((__packed__)) descriptors = {
+ .header = {
+ .magic = htole32(FUNCTIONFS_DESCRIPTORS_MAGIC),
+ .length = htole32(sizeof(descriptors)),
+ .fs_count = 3,
+ .hs_count = 3,
+ },
+ .fs_descs = {
+ .intf = {
+ .bLength = sizeof(descriptors.fs_descs.intf),
+ .bDescriptorType = USB_DT_INTERFACE,
+ .bNumEndpoints = 2,
+ .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
+ .iInterface = 1,
+ },
+ .bulk_sink = {
+ .bLength = sizeof(descriptors.fs_descs.bulk_sink),
+ .bDescriptorType = USB_DT_ENDPOINT,
+ .bEndpointAddress = 1 | USB_DIR_IN,
+ .bmAttributes = USB_ENDPOINT_XFER_BULK,
+ },
+ .bulk_source = {
+ .bLength = sizeof(descriptors.fs_descs.bulk_source),
+ .bDescriptorType = USB_DT_ENDPOINT,
+ .bEndpointAddress = 2 | USB_DIR_OUT,
+ .bmAttributes = USB_ENDPOINT_XFER_BULK,
+ },
+ },
+ .hs_descs = {
+ .intf = {
+ .bLength = sizeof(descriptors.hs_descs.intf),
+ .bDescriptorType = USB_DT_INTERFACE,
+ .bNumEndpoints = 2,
+ .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
+ .iInterface
Re: [Bug 68161] Unstable work of xhci with USB3.0 card reader and UDMA7 CompactFlash card.
On 01/14/2014 11:54 PM, tatxarata wrote: Update on my current research status. 3. Also when I build kernel without CONFIG_PM option all works fine without mount option "usefree". I've managed to test my card reader and CF card with NEC xhci controller. In that case all works fine. Wireshark capture looks pretty same, however on NEC controller capture doesn't contain SET_FEATURE requests with values 0x17 and 0x18. I'm not sure but it seems that I've seen some topic on this list about differences in power management on intel and other controllers. So maybe my card reader has some issues with power management? Is there any way to disable power management only for xhci without disabling it for the whole kernel with CONFIG_PM (I prefer to put my notebook to suspend to ram instead of powering it off)? -- 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: USB/IP
From: Peter Stuge > konst...@ngs.ru wrote: > > If so, which linux distro is worth being chosen for > > building and testing that custom kernel and, especially, > > usbip, in particular, and does distro really matter? > > It depends on how much "value add" the distribution has around the > kernel. > > The well-known distributions all use an initrd to bring userland up > and they also have more or less distribution-specific bootloader > management methods. I found it much easier to build a non-initrd kernel (ie one that has all the devices needed to boot builtin) than to work out how to build one that contains an initrd image. David -- 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 v5 4/5] usb: gadget: f_fs: add poll for endpoint 0
This patch adds poll function for file representing ep0.
Ability of read from or write to ep0 file is related with actual state of ffs:
- When desctiptors or strings are not written yet, POLLOUT flag is set.
- If there is any event to read, POLLIN flag is set.
- If setup request was read, POLLIN and POLLOUT flag is set, to allow
send response (by performing I/O operation consistent with setup request
direction) or set stall (by performing I/O operation opposite setup
request direction).
Signed-off-by: Robert Baldyga
Acked-by: Michal Nazarewicz
---
drivers/usb/gadget/f_fs.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 853f88a..a229659 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -28,6 +28,8 @@
#include
#include
+#include
+
#include "u_fs.h"
#include "configfs.h"
@@ -568,6 +570,45 @@ static long ffs_ep0_ioctl(struct file *file, unsigned
code, unsigned long value)
return ret;
}
+static unsigned int ffs_ep0_poll(struct file *file, poll_table *wait)
+{
+ struct ffs_data *ffs = file->private_data;
+ unsigned int mask = POLLWRNORM;
+ int ret;
+
+ poll_wait(file, &ffs->ev.waitq, wait);
+
+ ret = ffs_mutex_lock(&ffs->mutex, file->f_flags & O_NONBLOCK);
+ if (unlikely(ret < 0))
+ return mask;
+
+ switch (ffs->state) {
+ case FFS_READ_DESCRIPTORS:
+ case FFS_READ_STRINGS:
+ mask |= POLLOUT;
+ break;
+
+ case FFS_ACTIVE:
+ switch (ffs->setup_state) {
+ case FFS_NO_SETUP:
+ if (ffs->ev.count)
+ mask |= POLLIN;
+ break;
+
+ case FFS_SETUP_PENDING:
+ case FFS_SETUP_CANCELLED:
+ mask |= (POLLIN | POLLOUT);
+ break;
+ }
+ case FFS_CLOSING:
+ break;
+ }
+
+ mutex_unlock(&ffs->mutex);
+
+ return mask;
+}
+
static const struct file_operations ffs_ep0_operations = {
.llseek = no_llseek,
@@ -576,6 +617,7 @@ static const struct file_operations ffs_ep0_operations = {
.read = ffs_ep0_read,
.release = ffs_ep0_release,
.unlocked_ioctl = ffs_ep0_ioctl,
+ .poll = ffs_ep0_poll,
};
--
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 v5 5/5] usb: gadget: f_fs: add aio support
This patch adds asynchronous I/O support for FunctionFS endpoint files.
It adds ffs_epfile_aio_write() and ffs_epfile_aio_read() functions responsible
for preparing AIO operations.
It also modifies ffs_epfile_io() function, adding aio handling code. Instead
of extending list of parameters of this function, there is new struct
ffs_io_data which contains all information needed to perform I/O operation.
Pointer to this struct replaces "buf" and "len" parameters of ffs_epfile_io()
function. Allocated buffer is freed immediately only after sync operation,
because in async IO it's freed in complete funcion. For each async operation
an USB request is allocated, because it allows to have more than one request
queued on single endpoint.
According to changes in ffs_epfile_io() function, functions ffs_epfile_write()
and ffs_epfile_read() are updated to use new API.
For asynchronous I/O operations there is new request complete function named
ffs_epfile_async_io_complete(), which completes AIO operation, and frees
used memory.
Signed-off-by: Robert Baldyga
Acked-by: Michal Nazarewicz
---
drivers/usb/gadget/f_fs.c | 265 -
1 file changed, 239 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index a229659..c8f666a 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -28,6 +28,8 @@
#include
#include
+#include
+#include
#include
#include "u_fs.h"
@@ -158,6 +160,25 @@ struct ffs_epfile {
unsigned char _pad;
};
+/* ffs_io_data structure ***/
+
+struct ffs_io_data {
+ bool aio;
+ bool read;
+
+ struct kiocb *kiocb;
+ const struct iovec *iovec;
+ unsigned long nr_segs;
+ char __user *buf;
+ size_t len;
+
+ struct mm_struct *mm;
+ struct work_struct work;
+
+ struct usb_ep *ep;
+ struct usb_request *req;
+};
+
static int __must_check ffs_epfiles_create(struct ffs_data *ffs);
static void ffs_epfiles_destroy(struct ffs_epfile *epfiles, unsigned count);
@@ -633,8 +654,52 @@ static void ffs_epfile_io_complete(struct usb_ep *_ep,
struct usb_request *req)
}
}
-static ssize_t ffs_epfile_io(struct file *file,
-char __user *buf, size_t len, int read)
+static void ffs_user_copy_worker(struct work_struct *work)
+{
+ struct ffs_io_data *io_data = container_of(work, struct ffs_io_data,
+ work);
+ int ret = io_data->req->status ? io_data->req->status :
+io_data->req->actual;
+
+ if (io_data->read && ret > 0) {
+ int i;
+ size_t pos = 0;
+ use_mm(io_data->mm);
+ for (i = 0; i < io_data->nr_segs; i++) {
+ if (unlikely(copy_to_user(io_data->iovec[i].iov_base,
+&io_data->buf[pos],
+io_data->iovec[i].iov_len))) {
+ ret = -EFAULT;
+ break;
+ }
+ pos += io_data->iovec[i].iov_len;
+ }
+ unuse_mm(io_data->mm);
+ }
+
+ aio_complete(io_data->kiocb, ret, ret);
+
+ usb_ep_free_request(io_data->ep, io_data->req);
+
+ io_data->kiocb->private = NULL;
+ if (io_data->read)
+ kfree(io_data->iovec);
+ kfree(io_data->buf);
+ kfree(io_data);
+}
+
+static void ffs_epfile_async_io_complete(struct usb_ep *_ep,
+struct usb_request *req)
+{
+ struct ffs_io_data *io_data = req->context;
+
+ ENTER();
+
+ INIT_WORK(&io_data->work, ffs_user_copy_worker);
+ schedule_work(&io_data->work);
+}
+
+static ssize_t ffs_epfile_io(struct file *file, struct ffs_io_data *io_data)
{
struct ffs_epfile *epfile = file->private_data;
struct usb_gadget *gadget = epfile->ffs->gadget;
@@ -665,7 +730,7 @@ static ssize_t ffs_epfile_io(struct file *file,
}
/* Do we halt? */
- halt = !read == !epfile->in;
+ halt = (!io_data->read == !epfile->in);
if (halt && epfile->isoc) {
ret = -EINVAL;
goto error;
@@ -677,15 +742,32 @@ static ssize_t ffs_epfile_io(struct file *file,
* Controller may require buffer size to be aligned to
* maxpacketsize of an out endpoint.
*/
- data_len = read ? usb_ep_align_maybe(gadget, ep->ep, len) : len;
+ data_len = io_data->read ?
+ usb_ep_align_maybe(gadget, ep->ep, io_data->len) :
+ io_data->len;
data = kmalloc(data_len, GFP_KERNEL);
if (unlikely(!data))
retur
[PATCH v5 1/5] usb: gadget: functionfs: fix typo in the enum variable
From: Michal Nazarewicz
Since “cancelled” is spelled with two “l”s, rename FFS_SETUP_CANCELED
to FFS_SETUP_CANCELLED.
Signed-off-by: Michal Nazarewicz
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/f_fs.c | 16
drivers/usb/gadget/u_fs.h | 12 ++--
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 306a2b5..4010332 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -244,7 +244,7 @@ static ssize_t ffs_ep0_write(struct file *file, const char
__user *buf,
ENTER();
/* Fast check if setup was canceled */
- if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELED)
+ if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELLED)
return -EIDRM;
/* Acquire mutex */
@@ -311,7 +311,7 @@ static ssize_t ffs_ep0_write(struct file *file, const char
__user *buf,
*/
spin_lock_irq(&ffs->ev.waitq.lock);
switch (FFS_SETUP_STATE(ffs)) {
- case FFS_SETUP_CANCELED:
+ case FFS_SETUP_CANCELLED:
ret = -EIDRM;
goto done_spin;
@@ -346,7 +346,7 @@ static ssize_t ffs_ep0_write(struct file *file, const char
__user *buf,
/*
* We are guaranteed to be still in FFS_ACTIVE state
* but the state of setup could have changed from
-* FFS_SETUP_PENDING to FFS_SETUP_CANCELED so we need
+* FFS_SETUP_PENDING to FFS_SETUP_CANCELLED so we need
* to check for that. If that happened we copied data
* from user space in vain but it's unlikely.
*
@@ -355,7 +355,7 @@ static ssize_t ffs_ep0_write(struct file *file, const char
__user *buf,
* transition can be performed and it's protected by
* mutex.
*/
- if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELED) {
+ if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELLED) {
ret = -EIDRM;
done_spin:
spin_unlock_irq(&ffs->ev.waitq.lock);
@@ -421,7 +421,7 @@ static ssize_t ffs_ep0_read(struct file *file, char __user
*buf,
ENTER();
/* Fast check if setup was canceled */
- if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELED)
+ if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELLED)
return -EIDRM;
/* Acquire mutex */
@@ -442,7 +442,7 @@ static ssize_t ffs_ep0_read(struct file *file, char __user
*buf,
spin_lock_irq(&ffs->ev.waitq.lock);
switch (FFS_SETUP_STATE(ffs)) {
- case FFS_SETUP_CANCELED:
+ case FFS_SETUP_CANCELLED:
ret = -EIDRM;
break;
@@ -489,7 +489,7 @@ static ssize_t ffs_ep0_read(struct file *file, char __user
*buf,
spin_lock_irq(&ffs->ev.waitq.lock);
/* See ffs_ep0_write() */
- if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELED) {
+ if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELLED) {
ret = -EIDRM;
break;
}
@@ -1784,7 +1784,7 @@ static void __ffs_event_add(struct ffs_data *ffs,
* the source does nothing.
*/
if (ffs->setup_state == FFS_SETUP_PENDING)
- ffs->setup_state = FFS_SETUP_CANCELED;
+ ffs->setup_state = FFS_SETUP_CANCELLED;
switch (type) {
case FUNCTIONFS_RESUME:
diff --git a/drivers/usb/gadget/u_fs.h b/drivers/usb/gadget/u_fs.h
index bc2d371..3c0cd3f 100644
--- a/drivers/usb/gadget/u_fs.h
+++ b/drivers/usb/gadget/u_fs.h
@@ -125,7 +125,7 @@ enum ffs_setup_state {
* setup. If this state is set read/write on ep0 return
* -EIDRM. This state is only set when adding event.
*/
- FFS_SETUP_CANCELED
+ FFS_SETUP_CANCELLED
};
struct ffs_data {
@@ -168,18 +168,18 @@ struct ffs_data {
/*
* Possible transitions:
-* + FFS_NO_SETUP -> FFS_SETUP_PENDING -- P: ev.waitq.lock
+* + FFS_NO_SETUP-> FFS_SETUP_PENDING -- P: ev.waitq.lock
* happens only in ep0 read which is P: mutex
-* + FFS_SETUP_PENDING -> FFS_NO_SETUP -- P: ev.waitq.lock
+* + FFS_SETUP_PENDING -> FFS_NO_SETUP -- P: ev.waitq.lock
* happens only in ep0 i/o which is P: mutex
-* + FFS_SETUP_PENDING -> FFS_SETUP_CANCELED -- P: ev.waitq.lock
-* + FFS_SETUP_CANCELED -> FFS_NO_SETUP -- cmpxchg
+* + FFS_SETUP_PENDING -> FFS_SETUP_CANCELLED -- P: ev.waitq.lock
+* + FFS_SETUP_CANCELLED -> FFS_NO_SETUP-- cmpxchg
*/
enum ffs_setup_statesetup_state;
#define FFS_SETUP_STATE(ffs) \
((enum ffs_setup_state)cmpxchg(&(ffs)->setup_state, \
-
[PATCH v5 2/5] usb: gadget: functionfs: replace FFS_SETUP_STATUS with an inline function
From: Michal Nazarewicz
The FFS_SETUP_STATUS macro could be trivialy replaced with an static
inline function but more importantly its name was tad confusing.
The name suggested it was a simple accessor macro but it actually
did change the state of the ffs_data structure perfomring
a FFS_SETUP_CANCELLED -> FFS_NO_SETUP transition. The name of the
function -- ffs_setup_state_clear_cancelled -- should better
describe what the function actually does.
Signed-off-by: Michal Nazarewicz
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/f_fs.c | 22 --
drivers/usb/gadget/u_fs.h |7 +++
2 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 4010332..6267fb0 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -99,6 +99,14 @@ static struct ffs_function *ffs_func_from_usb(struct
usb_function *f)
}
+static inline enum ffs_setup_state
+ffs_setup_state_clear_cancelled(struct ffs_data *ffs)
+{
+ return (enum ffs_setup_state)
+ cmpxchg(&ffs->setup_state, FFS_SETUP_CANCELLED, FFS_NO_SETUP);
+}
+
+
static void ffs_func_eps_disable(struct ffs_function *func);
static int __must_check ffs_func_eps_enable(struct ffs_function *func);
@@ -244,7 +252,7 @@ static ssize_t ffs_ep0_write(struct file *file, const char
__user *buf,
ENTER();
/* Fast check if setup was canceled */
- if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELLED)
+ if (ffs_setup_state_clear_cancelled(ffs) == FFS_SETUP_CANCELLED)
return -EIDRM;
/* Acquire mutex */
@@ -310,7 +318,7 @@ static ssize_t ffs_ep0_write(struct file *file, const char
__user *buf,
* rather then _irqsave
*/
spin_lock_irq(&ffs->ev.waitq.lock);
- switch (FFS_SETUP_STATE(ffs)) {
+ switch (ffs_setup_state_clear_cancelled(ffs)) {
case FFS_SETUP_CANCELLED:
ret = -EIDRM;
goto done_spin;
@@ -355,7 +363,8 @@ static ssize_t ffs_ep0_write(struct file *file, const char
__user *buf,
* transition can be performed and it's protected by
* mutex.
*/
- if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELLED) {
+ if (ffs_setup_state_clear_cancelled(ffs) ==
+ FFS_SETUP_CANCELLED) {
ret = -EIDRM;
done_spin:
spin_unlock_irq(&ffs->ev.waitq.lock);
@@ -421,7 +430,7 @@ static ssize_t ffs_ep0_read(struct file *file, char __user
*buf,
ENTER();
/* Fast check if setup was canceled */
- if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELLED)
+ if (ffs_setup_state_clear_cancelled(ffs) == FFS_SETUP_CANCELLED)
return -EIDRM;
/* Acquire mutex */
@@ -441,7 +450,7 @@ static ssize_t ffs_ep0_read(struct file *file, char __user
*buf,
*/
spin_lock_irq(&ffs->ev.waitq.lock);
- switch (FFS_SETUP_STATE(ffs)) {
+ switch (ffs_setup_state_clear_cancelled(ffs)) {
case FFS_SETUP_CANCELLED:
ret = -EIDRM;
break;
@@ -489,7 +498,8 @@ static ssize_t ffs_ep0_read(struct file *file, char __user
*buf,
spin_lock_irq(&ffs->ev.waitq.lock);
/* See ffs_ep0_write() */
- if (FFS_SETUP_STATE(ffs) == FFS_SETUP_CANCELLED) {
+ if (ffs_setup_state_clear_cancelled(ffs) ==
+ FFS_SETUP_CANCELLED) {
ret = -EIDRM;
break;
}
diff --git a/drivers/usb/gadget/u_fs.h b/drivers/usb/gadget/u_fs.h
index 3c0cd3f..ab3de01 100644
--- a/drivers/usb/gadget/u_fs.h
+++ b/drivers/usb/gadget/u_fs.h
@@ -174,13 +174,12 @@ struct ffs_data {
* happens only in ep0 i/o which is P: mutex
* + FFS_SETUP_PENDING -> FFS_SETUP_CANCELLED -- P: ev.waitq.lock
* + FFS_SETUP_CANCELLED -> FFS_NO_SETUP-- cmpxchg
+*
+* This field should never be accessed directly and instead
+* ffs_setup_state_clear_cancelled function should be used.
*/
enum ffs_setup_statesetup_state;
-#define FFS_SETUP_STATE(ffs) \
- ((enum ffs_setup_state)cmpxchg(&(ffs)->setup_state, \
- FFS_SETUP_CANCELLED, FFS_NO_SETUP))
-
/* Events & such. */
struct {
u8 types[4];
--
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 v5 3/5] usb: gadget: f_fs: fix setup request handling
This patch fixes __ffs_ep0_queue_wait() function, which now returns number of
bytes transferred in USB request or error code in case of failure. This is
needed by ffs_ep0_read() function, when read data is copied to userspace.
It also cleans up code by removing usused variable ep0req_status.
Signed-off-by: Robert Baldyga
Acked-by: Michal Nazarewicz
---
drivers/usb/gadget/f_fs.c |2 +-
drivers/usb/gadget/u_fs.h |1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 6267fb0..853f88a 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -226,7 +226,7 @@ static int __ffs_ep0_queue_wait(struct ffs_data *ffs, char
*data, size_t len)
}
ffs->setup_state = FFS_NO_SETUP;
- return ffs->ep0req_status;
+ return req->status ? req->status : req->actual;
}
static int __ffs_ep0_stall(struct ffs_data *ffs)
diff --git a/drivers/usb/gadget/u_fs.h b/drivers/usb/gadget/u_fs.h
index ab3de01..bccfe5b 100644
--- a/drivers/usb/gadget/u_fs.h
+++ b/drivers/usb/gadget/u_fs.h
@@ -156,7 +156,6 @@ struct ffs_data {
*/
struct usb_request *ep0req;/* P: mutex */
struct completion ep0req_completion; /* P: mutex */
- int ep0req_status; /* P: mutex */
/* reference counter */
atomic_tref;
--
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 v5 0/5] usb: gadget: f_fs: add asynchronous I/O support
Hello, This is fourth version of patches containing improvements for FunctionFS which allows to use it with asynchronous I/O interface. It also adds poll function for ep0, to make it usable without creating additional thread, needed by blocking I/O. This version adds wait_queue support in ep0 poll funciton, to make it usable with select(). This patchset contains two patches with fixes, created by Michal Nazarewicz. More details in commit messages. Best regards Robert Baldyga Samsung R&D Institute Poland Changelog: v5: - add wait_queue support in ffs_ep0_poll() function v4: http://www.spinics.net/lists/linux-usb/msg101606.html - move completion code into worker to make cancel function asynchronous v3: http://www.spinics.net/lists/linux-usb/msg101324.html - clean up code - add allocation result checks - fix FFS_SETUP_CANCELLED state handling in ffs_ep0_poll() function - aio_complete() function is not called if request was cancelled v2: http://www.spinics.net/lists/linux-usb/msg101104.html - fix style problems - add error handling in ffs_user_copy_worker() - fix paremeters of aio_complete() in ffs_epfile_async_io_complete() - in ffs_epfile_io() do copy_from_user() calls with spinlock unlocked - in ffs_ep0_poll() remove "default" from switch-case block and add case for each enum value - fix returned value in __ffs_ep0_queue_wait() funcion v1: http://www.spinics.net/lists/linux-usb/msg100969.html - initial proposal Michal Nazarewicz (2): usb: gadget: functionfs: fix typo in the enum variable usb: gadget: functionfs: replace FFS_SETUP_STATUS with an inline function Robert Baldyga (3): usb: gadget: f_fs: fix setup request handling usb: gadget: f_fs: add poll for endpoint 0 usb: gadget: f_fs: add aio support drivers/usb/gadget/f_fs.c | 339 - drivers/usb/gadget/u_fs.h | 18 ++- 2 files changed, 310 insertions(+), 47 deletions(-) -- 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
Re: [PATCH v3] phy: Add new Exynos5 USB 3.0 PHY driver
Hi, On Thursday 06 February 2014 07:37 PM, Tomasz Figa wrote: > Hi Vivek, > > This patch is just adding the PHY driver. I would also like to look at some > users of it, to see how this works when put together. > > For now, please see my comments inline. > > On 20.01.2014 14:42, Vivek Gautam wrote: >> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs. >> The new driver uses the generic PHY framework and will interact >> with DWC3 controller present on Exynos5 series of SoCs. >> Thereby, removing old phy-samsung-usb3 driver and related code >> used untill now which was based on usb/phy framework. >> >> Signed-off-by: Vivek Gautam >> --- >> >> Changes from v2: >> 1) Added support for multiple PHYs (UTMI+ and PIPE3) and >> related changes in the driver structuring. > > I'm a bit skeptical about this separation. Can the PHY operate with just the > UTMI+ or PIPE3 part enabled alone without the other? Can any PHY consumer > operate this way? Theoretically yes. If the USB controller should operate only in high-speed mode, the PIPE3 part is not required at all. However for super speed mode both PIPE3 part and UTMI part should be enabled. Maybe it doesn't work that way with all SoCs because of some HW bug. > > Introducing separation of something that can't exist alone doesn't add any > value, but instead makes things more difficult to work with. Of course, it's IMO separating it into different parts adds more clarity to the driver. Thanks Kishon -- 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
