Re: [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci
Hi, On Monday 15 September 2014 05:36 PM, Heikki Krogerus wrote: On Fri, Sep 12, 2014 at 07:41:56PM +0530, Kishon Vijay Abraham I wrote: I don't think create lookup should be in host init. If it's dt boot, the binding should be in dt data or for other boot modes the bindig should be done in the board file. This just seems hacky to me. So are you now suggesting that instead of using platform independent solution of sharing the PHYs here, you would have us add platform specific quirks? That would be totally wrong! No. The binding between the controller and the PHY is done in hardware design and it would be wrong to create such a binding in drivers/* IMO. And kernel of course always knows the hardware design when it's being booted, wrong! Exactly my point. By creating the binding in drivers/*, you are directly telling the driver of the hardware design whereas it should have come from dt or platform data or .. (ACPI?). Firstly, don't assume this kind of controllers are always part of some SoC or chip set. They could easily be on a PCI card for example. Agreed. Not convinced the current phy-core could handle it well. Secondly, don't assume we could tell all the details about the board based on some identifiers. Fox example, at least with our SoCs we won't be able to differentiate the boards. And it's not like every board using the same SoC uses the same USB2 PHY for example. That kind of things are up to the manufacturers. right. In dt, generally we have different dt files for different boards, similarly we have different board files for different boards where those bindings can be created. Again not sure about ACPI. By default we have to rely on hardware descriptions like DT and ACPI tables or being able to runtime detect (ULPI). If those things don't work, we live without PHY in this case. We add board specific quirks _only_ in case of exceptions, where we simply have no other way. If it's possible to avoid them, especially with something as simple as this, we avoid them! And please don't even consider use of board files especially if there is an option. They are the one thing that we are meant to avoid if possible! No? For dt yes, I'm not sure about other modes. So in the case of dt boot, I'd prefer giving the binding in dt file than anywhere else. I don't know how dt works, but at least in case of ACPI we still need to deliver the PHY to xHCI here, even when dwc3 is provided bindings to a PHY(s). Agreed. But can't we have the bindings for xHCI in ACPI itself? 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
Re: [PATCH] usb: gadget: udc_core: Use right kobj when calling sysfs_notify
On 2014-09-16 07:15, Felipe Balbi wrote:
Hi,
On Tue, Sep 16, 2014 at 10:02:25AM +0800, Peter Chen wrote:
On Mon, Sep 15, 2014 at 12:42:27PM +0200, Andreas Larsson wrote:
The state attribute is connected to the kobj of the udc, not the gadget.
Signed-off-by: Andreas Larsson andr...@gaisler.com
---
drivers/usb/gadget/udc/udc-core.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index b0d9817..37c129a 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -109,8 +109,20 @@ EXPORT_SYMBOL_GPL(usb_gadget_unmap_request);
static void usb_gadget_state_work(struct work_struct *work)
{
struct usb_gadget *gadget = work_to_gadget(work);
+ struct usb_udc *udc = NULL;
+
+ mutex_lock(udc_lock);
+ list_for_each_entry(udc, udc_list, list)
+ if (udc-gadget == gadget)
+ goto found;
+ mutex_unlock(udc_lock);
+
+ return;
+
+found:
+ mutex_unlock(udc_lock);
- sysfs_notify(gadget-dev.kobj, NULL, state);
+ sysfs_notify(udc-dev.kobj, NULL, state);
}
void usb_gadget_set_state(struct usb_gadget *gadget,
What's the user mode difference with and without this patch?
poll() will actually wakeup ?
Yes, that is indeed the difference.
Cheers,
Andreas Larsson
--
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: XHCI, brain-dead scanner, and microframe rounding
On 09/16/2014 12:29 AM, Gunter Königsmann wrote: If after applying the patch I still get the warning and the scanner still isn't working - did I do something wrong? cat /proc/version is telling me I'm running the kernel I have compiled. Thanks a lot, and You got two warnings previously, one for IN endpoint 0x81, and one for OUT endpoint 0x02: [ 582.704873] usb 2-1: ep 0x81 - rounding interval to 128 microframes, ep desc says 255 microframes [ 582.704898] usb 2-1: ep 0x2 - rounding interval to 128 microframes, ep desc says 255 microframes If you now only get one warning, then patch is applied, I'll need to make another patch that addresses the points Alan made -Mathias -- 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: XHCI, brain-dead scanner, and microframe rounding
On 09/15/2014 10:50 PM, Alan Stern wrote:
On Mon, 15 Sep 2014, Mathias Nyman wrote:
I haven't had time to dig into the usbmon traces, but I just got another
report from Gunter K�ningsmann about similar scanner problem, and I just
noticed
that in both cases we round the interval for high speed bulk _IN_ endpoint,
which should not have interval set at all.
The interval value should be ignored by host, but maybe setting it still
could cause some issues.
I don't have high hopes for this patch, but it's worth a shot.
Can you try this out and see if it makes any difference?
-Mathias
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 8936211..7f21b77 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1291,7 +1291,8 @@ static unsigned int xhci_get_endpoint_interval(struct
usb_device *udev,
/* Max NAK rate */
if (usb_endpoint_xfer_control(ep-desc) ||
usb_endpoint_xfer_bulk(ep-desc)) {
- interval = xhci_parse_microframe_interval(udev, ep);
+ if (!usb_endpoint_dir_in(ep-desc))
+ interval =
xhci_parse_microframe_interval(udev, ep);
It's not a good idea to test the direction of control endpoints, since
they are bi-directional.
Thats right, thanks, I only wanted the bulk endpoints checked here, I need to
change that.
Also, xhci_parse_microframe_interval assumes the value is stored with
an exponential encoding, but the NAK rate value for control and
bulk-OUT endpoints is stored in the endpoint descriptor directly as a
number of microframes (not exponential).
It's not fully clear how xHCI controllers use the Interval field in the
Endpoint Context. Table 65 notably fails to include a line for HS
bulk-OUT/control endpoints, and the text isn't clear as to whether the
field is interpreted using exponential coding for non-periodic
endpoints. As near as I can tell, it is -- which means you should call
xhci_microframes_to_exponent() here, not
xhci_parse_microframe_interval().
Alan Stern
I think this is correct now as it is, assuming xhci Interval field for HS
bulk-OUT/control endpoint context uses the same exponential coding as for all
other endpoints.
flow goes:
if (HS bulk or control ep)//endpoints bInterval is in
number of microframes here,
xhci_parse_microframe_interval()
xhci_microframes_to_exponent(bInterval, ...)
interval = fls(bInterval) - 1;// interval is now in
exponent form
-Mathias
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] usb: hub: convert khubd into workqueue
On Fri 12-09-14 11:44:14, Alan Stern wrote:
On Fri, 12 Sep 2014, Petr Mladek wrote:
I don't think you can eliminate the lock quite so easily. This patch
introduces some nasty races.
@@ -577,18 +571,20 @@ static int hub_port_status(struct usb_hub *hub,
int port1,
static void kick_khubd(struct usb_hub *hub)
{
- unsigned long flags;
-
- spin_lock_irqsave(hub_event_lock, flags);
- if (!hub-disconnected list_empty(hub-event_list)) {
- list_add_tail(hub-event_list, hub_event_list);
-
- /* Suppress autosuspend until khubd runs */
+ if (!hub-disconnected !work_pending(hub-events)) {
Here you test hub-disconnected, with no lock for protection.
This should not be that big problem. It will schedule hub_event() but
it will do basically nothing. This is why I thought that the lock was
not needed.
What do you mean basically nothing? hub_event will be scheduled, via
a work_struct that is embedded in the usb_hub structure. But that
structure will be deallocated by hub_disconnect, so you will create a
use after free bug.
Sigh, I feel like an idiot. The code is not easy but still. I hope
that it was just a temporary parental dementia that I got when taking
care of our new born twins.
Feel free to ask me to send another version of the patch set if you
are getting lost in this Xth reply.
Anyway, the solution for the race between kick_hub_wq() and
hub_event() might be to get the reference already in kick_hub_wq().
I mean something like:
static void kick_hub_wq(struct usb_hub *hub)
{
if (hub-disconnected || work_pending(hub-events))
return;
/*
* Suppress autosuspend until the event is proceed.
*
* Be careful and make sure that the symmetric operation is
* always called. We are here only when there is no pending
* work for this hub. Therefore put the interface either when
* the new work is called or when it is canceled.
*/
usb_autopm_get_interface_no_resume(to_usb_interface(hub-intfdev));
kref_get(hub-kref);
if (queue_work(hub_wq, hub-events))
return;
/* the work could not be scheduled twice */
kref_put(hub-kref, hub_release);
usb_autopm_put_interface_no_suspend(intf);
}
And test for hub-disconnected at the very beginning of hub_event().
Also we would need to put the reference when the work is canceled in
hub_disconnect().
Hmm, I am not 100% sure if we could call
usb_autopm_get_interface_no_resume() without any lock here.
I guess so because otherwise the original code would not work.
The check for hub-disconnected would fail if the struct was freed
before the lock was taken.
It looks promissing. hub-intfdev is released together with hub in
hub_release(). Also it seems that kick_* and *disconnect functions
are called with some top level lock. For example, there is used dev
lock in drivers/usb/core/device.c.
(Also, note that work_pending is not synchronized with anything. What
happens if two threads call this routine at the same time?)
You are right! This is a real problem because it might call
usb_autopm_put_interface_no_suspend() twice but it might schedule
hub_event() and call usb_autopm_put_interface() only once.
Well, it might be possible to check the return value of
queue_work and do something like:
if (!hub-disconnected !work_pending(hub-events)) {
usb_autopm_get_interface_no_resume(
to_usb_interface(hub-intfdev));
if (!queue_work(hub_wq, hub-events))
usb_autopm_put_interface_no_suspend(intf);
}
But there is still problem that we need to call
INIT_WORK(hub-events, hub_event) somewhere and do it only once
before calling kick_hub_wq(). I wonder if it might be safe to do
so in hub_activate().
If I thought this was the right way to go, I would suggest initializing
hub-events in hub_probe, where the structure is created.
Thanks for hint.
Hmm, I am not longer that optimistic about it. After all, it might
be better to put the lock back. Would you prefer it, please?
Here's what I think. If you want to make khubd into a work queue
thread, you can. But it should be invoked only once,
sure
and the routine it runs should be hub_thread, not hub_events.
Yes, but most of the hub_thread() content is handled by the
workqueue() framework. In fact, after I removed all the obsolete stuff
then only hub_events() call was left. So, there was no reason to keep it.
Overall I don't see any advantage in making this change.
There are several motivations:
First, workqueues have clean and rich API for all basic operations.
The code is usually easier and better readable. For example, see how we
reduced hub_thread() and avoided operations with hub_event_list.
Also it should be more safe
Re: [PATCH v3 0/9] Tegra xHCI support
On 15 September 2014 19:06, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and USB3.0 memory sticks and ethernet dongles using controller firmware recently posted by Andrew Chew [2]. I have had mixed results when testing this on a Jetson TK1 board. Of 8 USB devices I tested with, about half where probed correctly, but the other half repeatedly fail in hub_port_init because in the GET_STATUS right after the reset, the C_PORT_CONNECTION bit is set. I don't see any correlation between the failure and the kind of usb device, but I don't have much experience with USB implementations either. Hmm... I haven't seen that before. Which particular devices were you using? Here they are: work: Genius keyboard: 05d5:6782 Logitech mouse: 046d:c06a Denver MP3 player: 10d6:1100 Atheros Bluetooth dongle: 0cf3:3005 don't work: MCS7830 ethernet dongle: 9710:7830 Genesys Logic hub: 05e3:0608 I tried the hub and it works just fine for me... Have you tried this on any other boards like Big or Blaze? I have a Blaze here, but haven't been able to get the external ports to power up. I don't have schematics nor a strong interest to get that fixed myself, as I can test my code just fine with the Blaze's internal camera and the devices that do work on the Jetson. Ok, since Blaze has been announced, hopefully we can post a device-tree for it soon. I'm using the firmware file that was posted recently: xhci-tegra 7009.usb: Firmware timestamp: 2014-05-02 02:22:50 UTC, Falcon state 0x20 Yup, I'm using the same firmware. If things work for you with the same sources, .config and firmware, I can only think of the hw being different (other hw revision?). That, or perhaps bootloader differences? I'm using mainline U-Boot. Also mainline here: U-Boot 2014.10-rc1-00136-g7bee1c9 (Aug 28 2014 - 15:22:05) Don't know how to check what revision of the hw I have, though. Regards, Tomeu Stephen, Thierry, have either of you had a chance to test this series? -- 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 6/6] usb: dwc3: host: convey the PHYs to xhci
On Tue, Sep 16, 2014 at 12:07:00PM +0530, Kishon Vijay Abraham I wrote: Hi, On Monday 15 September 2014 05:36 PM, Heikki Krogerus wrote: On Fri, Sep 12, 2014 at 07:41:56PM +0530, Kishon Vijay Abraham I wrote: I don't think create lookup should be in host init. If it's dt boot, the binding should be in dt data or for other boot modes the bindig should be done in the board file. This just seems hacky to me. So are you now suggesting that instead of using platform independent solution of sharing the PHYs here, you would have us add platform specific quirks? That would be totally wrong! No. The binding between the controller and the PHY is done in hardware design and it would be wrong to create such a binding in drivers/* IMO. And kernel of course always knows the hardware design when it's being booted, wrong! Exactly my point. By creating the binding in drivers/*, you are directly telling the driver of the hardware design whereas it should have come from dt or platform data or .. (ACPI?). Man, you are not getting this... We want to avoid the damn platform data!!! If you are not using devicetree it doesn't mean the same as something like board files or some other platform specific quirks are suddenly acceptable. I'm giving you a way of avoiding those things, basically a way ignoring the platform completely in this case, but you are saying no no no, we need to have board files. C'mon! And I'm pretty sure you misspelled this sentence ..you are directly telling the driver of the hardware design... I believe you meant to say Wau! With this we newer have to care about the hardware design with this driver!. Note. That and some other things that we can always simply ignore here with this approach include: - How were we enumerated (DT, ACPI, PCI...) - Do some other bindings exist (DT) - Do we even have PHYs to convey - Does xHCI have any use for the PHYs - What is the platform we are running on in general Firstly, don't assume this kind of controllers are always part of some SoC or chip set. They could easily be on a PCI card for example. Agreed. Not convinced the current phy-core could handle it well. If there is ever a PHY that needs OS control in this case, it will almost certainly be possible to runtime detected somehow like ULPI PHYs can be. Secondly, don't assume we could tell all the details about the board based on some identifiers. Fox example, at least with our SoCs we won't be able to differentiate the boards. And it's not like every board using the same SoC uses the same USB2 PHY for example. That kind of things are up to the manufacturers. right. In dt, generally we have different dt files for different boards, similarly we have different board files for different boards where those bindings can be created. Again not sure about ACPI. I'll repeat what I said below - If we don't have description of the hardware from something like DT or ACPI, and that includes the bindings, or we can't runtime detect the underlying hardware, by default it means we live without PHYs. Quirks you add only in case of exceptions, but I actually think there will never be need for them... If we are not using ACPI, we are using devicetree and otherwise we can runtime detect the PHYs one way or the other. And again, if no PHY is found it simply means the PHYs are autonomous. So as you can see, it's possible we will newer need any kind of platform data in order to provide dwc3 the correct PHYs, no matter what kind of platform we are running on, so it makes no sense of having them just for dwc3 host. Do you not agree? I don't know how dt works, but at least in case of ACPI we still need to deliver the PHY to xHCI here, even when dwc3 is provided bindings to a PHY(s). Agreed. But can't we have the bindings for xHCI in ACPI itself? No. ACPI will never provide separate object for the xHCI that is part of DWC3. There is nothing the PHYs could be bound to. -- heikki -- 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 v5 07/12] usb: chipidea: add a usb2 driver for ci13xxx
On Tue, Sep 16, 2014 at 08:51:30AM +0800, Peter Chen wrote: On Mon, Sep 15, 2014 at 12:36:13PM +0200, Antoine Tenart wrote: Add a USB2 ChipIdea driver for ci13xxx, with optional PHY, clock and DMA mask, to support USB2 ChipIdea controllers that don't need specific functions. Tested on the Marvell Berlin SoCs USB controllers. Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com --- drivers/usb/chipidea/Makefile | 1 + drivers/usb/chipidea/ci_hdrc_usb2.c | 137 2 files changed, 138 insertions(+) create mode 100644 drivers/usb/chipidea/ci_hdrc_usb2.c compile error: /home/peter/work/projects/usb/drivers/usb/chipidea/ci_hdrc_usb2.c: In function 'ci_hdrc_usb2_dt_probe': /home/peter/work/projects/usb/drivers/usb/chipidea/ci_hdrc_usb2.c:30:2: error: implicit declaration of function 'of_phy_get' [-Werror=implicit-function-declaration] /home/peter/work/projects/usb/drivers/usb/chipidea/ci_hdrc_usb2.c:30:16: warning: assignment makes pointer from integer without a cast [enabled by default] Did you apply the series introducing the support for the generic PHY framework in the USB subsystem first? One of the patches includes 'linux/phy/phy.h' in 'linux/usb/otg.h'. That's why I did not encounter this error. Anyway, you're right and 'linux/phy/phy.h' should be explicitly included here. Antoine -- Antoine Ténart, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hitting unused qh not empty BUG in qh_destroy
On Mon, 15 Sep 2014 11:59:15 -0400 Alan Stern st...@rowland.harvard.edu wrote: On Sat, 13 Sep 2014, Joe Lawrence wrote: Hi Alan, I've collected 16 crashes since kicking off automated tests a little over 24 hrs ago. Each crash hit the BUG in qh_destroy() and the only unique debugging printk from ehci_stop() was: ehci_stop: ehci-num_async = 0. What about error messages from the check_async_ring routine? In the crash instances, the error messages never occurred. (I had added a BUG() in that code block, just to be really clear if/when that event occurred). You can check for this. Sprinkle ehci_info messages throughout ehci_stop, printing the value of ehci-async-qh_next.qh. It should be NULL the entire time. I re-ran the tests with the following changes: - moved num_async debug up above struct ehci_hcd.priv[0] :) - added verbose debug msg in check_async_ring to display the new num_async value - added ehci_info to every other line in ehci_stop % grep ':66:00.1' vmcore-dmesg.txt [ 4936.956739] pci :66:00.1: [8086:1d2d] type 00 class 0x0c0320 [ 4936.956789] pci :66:00.1: reg 0x10: [mem 0xa400-0xa7ff] [ 4936.957019] pci :66:00.1: PME# supported from D0 D3hot D3cold [ 4939.564933] ehci-pci :66:00.1: EHCI Host Controller [ 4939.565462] ehci-pci :66:00.1: new USB bus registered, assigned bus number 4 [ 4939.565498] ehci-pci :66:00.1: debug port 2 [ 4939.569466] ehci-pci :66:00.1: cache line size of 64 is not supported [ 4939.569533] ehci-pci :66:00.1: irq 13, io mem 0xa400 [ 4939.574794] ehci-pci :66:00.1: USB 2.0 started, EHCI 1.00 [ 4939.575410] usb usb4: SerialNumber: :66:00.1 [ 4940.089044] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 1, qh=88083d6b4558 [ 4941.795700] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 0, qh= (null) [ 4941.895713] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 1, qh=88083d6b4558 [ 4941.943761] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 0, qh= (null) [ 4942.002715] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 1, qh=88083d6b4558 [ 4942.064346] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 0, qh= (null) [ 4942.156646] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 1, qh=88083d6b4558 [ 4942.226028] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 0, qh= (null) [ 4942.274185] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 1, qh=88083d6b4558 [ 4942.329196] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 0, qh= (null) [ 4942.391055] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 1, qh=88083d6b4558 [ 4942.629653] ehci-pci :66:00.1: HC died; cleaning up [ 4945.663153] ehci-pci :66:00.1: remove, state 1 [ 4945.733934] ehci-pci :66:00.1: ehci_stop:420 ehci(8808419839d0)-num_async = 1 [ 4945.774242] ehci-pci :66:00.1: ehci_stop:427 ehci(8808419839d0)-num_async = 1 [ 4945.814791] ehci-pci :66:00.1: ehci_stop:429 ehci(8808419839d0)-num_async = 1 [ 4945.855938] ehci-pci :66:00.1: ehci_stop:431 ehci(8808419839d0)-num_async = 1 [ 4945.897145] ehci-pci :66:00.1: ehci_stop:433 ehci(8808419839d0)-num_async = 1 [ 4945.938791] ehci-pci :66:00.1: ehci_stop:436 ehci(8808419839d0)-num_async = 1 [ 4945.980491] ehci-pci :66:00.1: ehci_stop:438 ehci(8808419839d0)-num_async = 1 [ 4946.01] ehci-pci :66:00.1: ehci_stop:440 ehci(8808419839d0)-num_async = 1 [ 4946.063936] ehci-pci :66:00.1: ehci_stop:444 ehci(8808419839d0)-num_async = 1 [ 4946.105631] ehci-pci :66:00.1: ehci_stop:446 ehci(8808419839d0)-num_async = 1 [ 4946.241802] ehci-pci :66:00.1: ehci_stop:448 ehci(8808419839d0)-num_async = 1 where ehci_stop line 420 is function entry and line 448 function return. Notice that check_async_ring incremented num_async just before the HC died/removed and then num_async was 1 throughout ehci_stop. qh_destroy then BUGs with a struct ehci_hcd *ehci of 8808419839d0. -- Joe -- 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 v5 9/9] usb: chipidea: add support to the generic PHY framework in ChipIdea
On Tue, Sep 16, 2014 at 08:07:21AM +0800, Peter Chen wrote: On Mon, Sep 15, 2014 at 12:35:09PM +0200, Antoine Tenart wrote: diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c index 8f437e1512fa..999e9d683d7a 100644 --- a/drivers/usb/chipidea/debug.c +++ b/drivers/usb/chipidea/debug.c @@ -220,7 +220,7 @@ static int ci_otg_show(struct seq_file *s, void *unused) /* -- State - */ seq_printf(s, OTG state: %s\n\n, - usb_otg_state_string(ci-usb_phy-otg.state)); + usb_otg_state_string(ci-otg.state)); This one should be at your 8th patch, isn't it? Right. Antoine -- Antoine Ténart, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/9] usb: rename phy to usb_phy in HCD
On Mon, Sep 15, 2014 at 09:09:06PM +0300, Sergei Shtylyov wrote: On 9/15/2014 1:35 PM, Antoine Tenart wrote: The USB PHY member of the HCD structure is renamed to 'usb_phy' and modifications are done in all drivers accessing it. Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com Acked-by: Alan Stern st...@rowland.harvard.edu --- drivers/usb/chipidea/host.c | 2 +- drivers/usb/core/hcd.c| 20 ++-- drivers/usb/core/hub.c| 8 drivers/usb/host/ehci-fsl.c | 16 drivers/usb/host/ehci-hub.c | 2 +- drivers/usb/host/ehci-msm.c | 4 ++-- drivers/usb/host/ehci-tegra.c | 16 drivers/usb/host/ohci-omap.c | 20 ++-- drivers/usb/misc/lvstest.c| 8 I have already re-posted this patch (adding it to my generic PHY patch to form a short series) with this file added, and CC'ed you. I haven't heard any protest (perhaps I missed it?), why reiterate with this patch instead of basing the patchset on my most recent posting? Well, I can only return the question. Anyway, this is not really important. I'll let the maintainers decide which series they want this patch in, and I'll make the needed modifications if needed. Antoine -- Antoine Ténart, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/9] usb: rename phy to usb_phy in HCD
On Tue, Sep 16, 2014 at 03:53:47PM +0200, Antoine Tenart wrote: On Mon, Sep 15, 2014 at 09:09:06PM +0300, Sergei Shtylyov wrote: On 9/15/2014 1:35 PM, Antoine Tenart wrote: The USB PHY member of the HCD structure is renamed to 'usb_phy' and modifications are done in all drivers accessing it. Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com Acked-by: Alan Stern st...@rowland.harvard.edu --- drivers/usb/chipidea/host.c | 2 +- drivers/usb/core/hcd.c| 20 ++-- drivers/usb/core/hub.c| 8 drivers/usb/host/ehci-fsl.c | 16 drivers/usb/host/ehci-hub.c | 2 +- drivers/usb/host/ehci-msm.c | 4 ++-- drivers/usb/host/ehci-tegra.c | 16 drivers/usb/host/ohci-omap.c | 20 ++-- drivers/usb/misc/lvstest.c| 8 I have already re-posted this patch (adding it to my generic PHY patch to form a short series) with this file added, and CC'ed you. I haven't heard any protest (perhaps I missed it?), why reiterate with this patch instead of basing the patchset on my most recent posting? Well, I can only return the question. Anyway, this is not really important. I'll let the maintainers decide which series they want this patch in, and I'll make the needed modifications if needed. Oh, I see. I mixed up some series. Well, I'll drop this patch in the next version. Antoine -- Antoine Ténart, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 07/12] usb: chipidea: add a usb2 driver for ci13xxx
On Tue, Sep 16, 2014 at 03:38:41PM +0200, Antoine Tenart wrote: On Tue, Sep 16, 2014 at 08:51:30AM +0800, Peter Chen wrote: On Mon, Sep 15, 2014 at 12:36:13PM +0200, Antoine Tenart wrote: Add a USB2 ChipIdea driver for ci13xxx, with optional PHY, clock and DMA mask, to support USB2 ChipIdea controllers that don't need specific functions. Tested on the Marvell Berlin SoCs USB controllers. Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com --- drivers/usb/chipidea/Makefile | 1 + drivers/usb/chipidea/ci_hdrc_usb2.c | 137 2 files changed, 138 insertions(+) create mode 100644 drivers/usb/chipidea/ci_hdrc_usb2.c compile error: /home/peter/work/projects/usb/drivers/usb/chipidea/ci_hdrc_usb2.c: In function 'ci_hdrc_usb2_dt_probe': /home/peter/work/projects/usb/drivers/usb/chipidea/ci_hdrc_usb2.c:30:2: error: implicit declaration of function 'of_phy_get' [-Werror=implicit-function-declaration] /home/peter/work/projects/usb/drivers/usb/chipidea/ci_hdrc_usb2.c:30:16: warning: assignment makes pointer from integer without a cast [enabled by default] Did you apply the series introducing the support for the generic PHY framework in the USB subsystem first? One of the patches includes 'linux/phy/phy.h' in 'linux/usb/otg.h'. That's why I did not encounter this error. Anyway, you're right and 'linux/phy/phy.h' should be explicitly included here. Let me know if you want me to quickly cook up a new version fixing this. Antoine -- Antoine Ténart, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XHCI, brain-dead scanner, and microframe rounding
On Tue, 16 Sep 2014, Mathias Nyman wrote: It's not fully clear how xHCI controllers use the Interval field in the Endpoint Context. Table 65 notably fails to include a line for HS bulk-OUT/control endpoints, and the text isn't clear as to whether the field is interpreted using exponential coding for non-periodic endpoints. As near as I can tell, it is -- which means you should call xhci_microframes_to_exponent() here, not xhci_parse_microframe_interval(). Alan Stern I think this is correct now as it is, assuming xhci Interval field for HS bulk-OUT/control endpoint context uses the same exponential coding as for all other endpoints. flow goes: if (HS bulk or control ep)//endpoints bInterval is in number of microframes here, xhci_parse_microframe_interval() xhci_microframes_to_exponent(bInterval, ...) interval = fls(bInterval) - 1;// interval is now in exponent form Yes, you're right -- I misread the code. Sorry. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] usb: gadget: uvc: Simplify uvcg_video_pump by using local variable
Use the local queue variable instead of computing it every time.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/usb/gadget/function/uvc_video.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/function/uvc_video.c
b/drivers/usb/gadget/function/uvc_video.c
index b0528e8..c3e1f27 100644
--- a/drivers/usb/gadget/function/uvc_video.c
+++ b/drivers/usb/gadget/function/uvc_video.c
@@ -309,10 +309,10 @@ int uvcg_video_pump(struct uvc_video *video)
/* Retrieve the first available video buffer and fill the
* request, protected by the video queue irqlock.
*/
- spin_lock_irqsave(video-queue.irqlock, flags);
- buf = uvcg_queue_head(video-queue);
+ spin_lock_irqsave(queue-irqlock, flags);
+ buf = uvcg_queue_head(queue);
if (buf == NULL) {
- spin_unlock_irqrestore(video-queue.irqlock, flags);
+ spin_unlock_irqrestore(queue-irqlock, flags);
break;
}
@@ -323,11 +323,11 @@ int uvcg_video_pump(struct uvc_video *video)
if (ret 0) {
printk(KERN_INFO Failed to queue request (%d)\n, ret);
usb_ep_set_halt(video-ep);
- spin_unlock_irqrestore(video-queue.irqlock, flags);
+ spin_unlock_irqrestore(queue-irqlock, flags);
uvcg_queue_cancel(queue, 0);
break;
}
- spin_unlock_irqrestore(video-queue.irqlock, flags);
+ spin_unlock_irqrestore(queue-irqlock, flags);
}
spin_lock_irqsave(video-req_lock, flags);
--
1.8.5.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 2/3] usb: gadget: uvc: Fix endianness mismatches
The struct usb_endpoint_descriptor wMaxPacketSize field the struct usb_ss_ep_comp_descriptor wBytesPerInterval field are stored in little-endian format. Convert the values from CPU order to little endian before storing the values. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/usb/gadget/function/f_uvc.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/usb/gadget/function/f_uvc.c b/drivers/usb/gadget/function/f_uvc.c index bf9abf4..e126439 100644 --- a/drivers/usb/gadget/function/f_uvc.c +++ b/drivers/usb/gadget/function/f_uvc.c @@ -596,19 +596,20 @@ uvc_function_bind(struct usb_configuration *c, struct usb_function *f) } uvc_fs_streaming_ep.wMaxPacketSize = - min(opts-streaming_maxpacket, 1023U); + cpu_to_le16(min(opts-streaming_maxpacket, 1023U)); uvc_fs_streaming_ep.bInterval = opts-streaming_interval; - uvc_hs_streaming_ep.wMaxPacketSize = max_packet_size; - uvc_hs_streaming_ep.wMaxPacketSize |= ((max_packet_mult - 1) 11); + uvc_hs_streaming_ep.wMaxPacketSize = + cpu_to_le16(max_packet_size | ((max_packet_mult - 1) 11)); uvc_hs_streaming_ep.bInterval = opts-streaming_interval; - uvc_ss_streaming_ep.wMaxPacketSize = max_packet_size; + uvc_ss_streaming_ep.wMaxPacketSize = cpu_to_le16(max_packet_size); uvc_ss_streaming_ep.bInterval = opts-streaming_interval; uvc_ss_streaming_comp.bmAttributes = max_packet_mult - 1; uvc_ss_streaming_comp.bMaxBurst = opts-streaming_maxburst; uvc_ss_streaming_comp.wBytesPerInterval = - max_packet_size * max_packet_mult * opts-streaming_maxburst; + cpu_to_le16(max_packet_size * max_packet_mult * + opts-streaming_maxburst); /* Allocate endpoints. */ ep = usb_ep_autoconfig(cdev-gadget, uvc_control_ep); -- 1.8.5.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 0/3] USB gadget UVC function fixes
Hello, This patch set fixes small issues with the UVC function driver. The first patch has been received as part of one of Fengguang's 0day warning report, I've just added a commit message body and collected acked-by's. The other two patches are new, they fix an endianness problem on big-endian systems and slightly simplify an internal driver function. Fengguang Wu (1): usb: gadget: uvc: uvc_alloc() can be static Laurent Pinchart (2): usb: gadget: uvc: Fix endianness mismatches usb: gadget: uvc: Simplify uvcg_video_pump by using local variable drivers/usb/gadget/function/f_uvc.c | 13 +++-- drivers/usb/gadget/function/uvc_video.c | 10 +- 2 files changed, 12 insertions(+), 11 deletions(-) -- Regards, Laurent Pinchart -- 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: Hitting unused qh not empty BUG in qh_destroy
On Tue, 16 Sep 2014, Joe Lawrence wrote: You can check for this. Sprinkle ehci_info messages throughout ehci_stop, printing the value of ehci-async-qh_next.qh. It should be NULL the entire time. I re-ran the tests with the following changes: - moved num_async debug up above struct ehci_hcd.priv[0] :) - added verbose debug msg in check_async_ring to display the new num_async value - added ehci_info to every other line in ehci_stop % grep ':66:00.1' vmcore-dmesg.txt [ 4936.956739] pci :66:00.1: [8086:1d2d] type 00 class 0x0c0320 [ 4936.956789] pci :66:00.1: reg 0x10: [mem 0xa400-0xa7ff] [ 4936.957019] pci :66:00.1: PME# supported from D0 D3hot D3cold [ 4939.564933] ehci-pci :66:00.1: EHCI Host Controller [ 4939.565462] ehci-pci :66:00.1: new USB bus registered, assigned bus number 4 [ 4939.565498] ehci-pci :66:00.1: debug port 2 [ 4939.569466] ehci-pci :66:00.1: cache line size of 64 is not supported [ 4939.569533] ehci-pci :66:00.1: irq 13, io mem 0xa400 [ 4939.574794] ehci-pci :66:00.1: USB 2.0 started, EHCI 1.00 [ 4939.575410] usb usb4: SerialNumber: :66:00.1 [ 4940.089044] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 1, qh=88083d6b4558 [ 4941.795700] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 0, qh= (null) [ 4941.895713] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 1, qh=88083d6b4558 [ 4941.943761] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 0, qh= (null) [ 4942.002715] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 1, qh=88083d6b4558 [ 4942.064346] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 0, qh= (null) [ 4942.156646] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 1, qh=88083d6b4558 [ 4942.226028] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 0, qh= (null) [ 4942.274185] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 1, qh=88083d6b4558 [ 4942.329196] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 0, qh= (null) [ 4942.391055] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 1, qh=88083d6b4558 [ 4942.629653] ehci-pci :66:00.1: HC died; cleaning up [ 4945.663153] ehci-pci :66:00.1: remove, state 1 [ 4945.733934] ehci-pci :66:00.1: ehci_stop:420 ehci(8808419839d0)-num_async = 1 [ 4945.774242] ehci-pci :66:00.1: ehci_stop:427 ehci(8808419839d0)-num_async = 1 [ 4945.814791] ehci-pci :66:00.1: ehci_stop:429 ehci(8808419839d0)-num_async = 1 [ 4945.855938] ehci-pci :66:00.1: ehci_stop:431 ehci(8808419839d0)-num_async = 1 [ 4945.897145] ehci-pci :66:00.1: ehci_stop:433 ehci(8808419839d0)-num_async = 1 [ 4945.938791] ehci-pci :66:00.1: ehci_stop:436 ehci(8808419839d0)-num_async = 1 [ 4945.980491] ehci-pci :66:00.1: ehci_stop:438 ehci(8808419839d0)-num_async = 1 [ 4946.01] ehci-pci :66:00.1: ehci_stop:440 ehci(8808419839d0)-num_async = 1 [ 4946.063936] ehci-pci :66:00.1: ehci_stop:444 ehci(8808419839d0)-num_async = 1 [ 4946.105631] ehci-pci :66:00.1: ehci_stop:446 ehci(8808419839d0)-num_async = 1 [ 4946.241802] ehci-pci :66:00.1: ehci_stop:448 ehci(8808419839d0)-num_async = 1 where ehci_stop line 420 is function entry and line 448 function return. Notice that check_async_ring incremented num_async just before the HC died/removed and then num_async was 1 throughout ehci_stop. qh_destroy then BUGs with a struct ehci_hcd *ehci of 8808419839d0. This says that ehci-num_async ended up equal to 1. But in your previous email, you said the final printout indicated it was equal to 0. Did something change in the meantime? Anyway, the log above means that a QH was linked before the HC died, but then it was never unlinked. Please add a line at the start of ehci_endpoint_disable, printing out the value of ep-hcpriv for comparison with the values listed above. Also, let's see the contents of *qh and *(qh-hw) for the left-over QH at *(ehci-async-qh_next.qh). You can get those right away from your crash dump data, right? 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 0/3] USB gadget UVC function fixes
On Tue, Sep 16, 2014 at 05:26:45PM +0300, Laurent Pinchart wrote: Hello, This patch set fixes small issues with the UVC function driver. The first patch has been received as part of one of Fengguang's 0day warning report, I've just added a commit message body and collected acked-by's. The other two patches are new, they fix an endianness problem on big-endian systems and slightly simplify an internal driver function. looks they all fall into has never worked before category, so I'll send them for v3.18 merge window. -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/3] USB gadget UVC function fixes
On Tuesday 16 September 2014 09:56:51 Felipe Balbi wrote: On Tue, Sep 16, 2014 at 05:26:45PM +0300, Laurent Pinchart wrote: Hello, This patch set fixes small issues with the UVC function driver. The first patch has been received as part of one of Fengguang's 0day warning report, I've just added a commit message body and collected acked-by's. The other two patches are new, they fix an endianness problem on big-endian systems and slightly simplify an internal driver function. looks they all fall into has never worked before category, so I'll send them for v3.18 merge window. Yes, v3.18 is fine, I should have mentioned that, sorry. -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part.
Re: Ability to specify SCM_MULT_TARG quirk on command line
Hi, On Mon, 15 Sep 2014 11:01:33 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: On Sun, 14 Sep 2014, Mark wrote: Shuttle Technology/SCM Microsystems was the OEM manufacturer of SCSI-USB converter cables sold by various companies including Adaptec [untested patch posted recently], Ariston Technologies, Belkin [*], Buffalo, Entrega/Xircom [patch posted recently], Microtech [*], Newer Technology [*], Olympus[*] *: quirk already in unusual-devs.h The ability to specify the SCM_MULT_TARG quirk on the command line could be useful. At least the Ariston and Buffalo products don't have entries in unusual-devs.h. I hope to write a patch, but would like some advice on the best approach. Devices with this capability are so rare, it didn't seem worthwhile adding it to the list of recognized quirks for the module parameter. ... Is one of those options preferable? Or maybe something else? It's probably better just to rely on entries to the unusual_devs.h file. Those are automatically be available to anyone with an up-to-date kernel, with no need for messing around with module parameters. The trouble is though, that requires the user compile their own kernel. Which may not be practical due to lack of knowledge or e.g. booting from a live CD. I can submit patches for devices I don't own to cover more (hopefully almost all) SCM-based devices, e.g. the USBConnect 2000 patch I submitted recently. But I wasn't sure what values to use for bcdDeviceMin and bcdDeviceMax. 0 and 0x would probably be best, so I'll repost the patch with that change. Another issue relates to manufacturer USB ID screw-ups. The Buffalo USB-SCSI cable is a good example. According to the Windows INF file available from http://buffalo.jp/download/driver/hd/mos-s640usb.html its USB ID is 0411:0001. However, according to the INF file from http://buffalo.jp/download/driver/lan/lua-tx.html the LUA-TX USB-Ethernet adapter can have ID 0411:0005 or 0411:0001... sigh. Given that, would it be possible/advisable to have an unusual-devs.h entry for the Buffalo USB-SCSI cable? Mark -- 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] storage: Add quirk for Adaptec USBConnect 2000 USB-to-SCSI Adapter
Hi, [This is revised over the patch I posted previously.] The Adaptec USBConnect 2000 is another SCSI-USB converter which uses Shuttle Technology/SCM Microsystems chips. The US_FL_SCM_MULT_TARG quirk is required to use SCSI devices with ID other than 0. I don't have a USBConnect 2000, but based on the other entries for Shuttle/ SCM-based converters this patch is very likely correct. I used 0x and 0x for bcdDeviceMin and bcdDeviceMax because I'm not sure which bcdDevice value the product uses. Signed-off-by: Mark Knibbs ma...@clara.co.uk --- diff -up linux-3.17-rc4/drivers/usb/storage/unusual_devs.h.orig linux-3.17-rc4/drivers/usb/storage/unusual_devs.h --- linux-3.17-rc4/drivers/usb/storage/unusual_devs.h.orig 2014-09-08 00:09:43.0 +0100 +++ linux-3.17-rc4/drivers/usb/storage/unusual_devs.h 2014-09-13 20:47:01.0 +0100 @@ -101,6 +101,12 @@ UNUSUAL_DEV( 0x03f0, 0x4002, 0x0001, 0x PhotoSmart R707, USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_FIX_CAPACITY), +UNUSUAL_DEV( 0x03f3, 0x0001, 0x, 0x, + Adaptec, + USBConnect 2000, + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_euscsi_init, + US_FL_SCM_MULT_TARG ), + /* Reported by Sebastian Kapfer sebastian_kap...@gmx.net * and Olaf Hering o...@suse.de (different bcd's, same vendor/product) * for USB floppies that need the SINGLE_LUN enforcement. -- 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 0/9] Tegra xHCI support
On 09/15/2014 01:30 PM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 11:09 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 11:06 AM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and USB3.0 memory sticks and ethernet dongles using controller firmware recently posted by Andrew Chew [2]. ... Stephen, Thierry, have either of you had a chance to test this series? I haven't had a chance to yet. I just went to try it out, and found that it depends on a whole slew of other patches that I don't have. Is there a git branch somewhere to save me having to track down all the dependencies? Yes, Tomeu has the branch he used for testing here: http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=3.17rc4-xhci Hmm. That git server was quite reluctant to cough up its bits, but it did eventually. You'll also need the firmware Andrew Chew posted: https://patchwork.ozlabs.org/patch/384013/ The XHCI driver can't load its firmware unless it's a module; if I make it built-in, it fails immediately with error -2 during Direct firmware loading. The driver needs to work with either immediate or deferred firmware loading. I tried three USB3 mass storage devices, and they all appeared to work without issue. 0781:5581 SanDisk Corp. 154b:fa0a PNY 0781:5580 SanDisk Corp. I tried the following USB2 devices without issue: 0781:5575 SanDisk Corp. 0b95:7720 ASIX Electronics Corp. AX88772 045e:0095 Microsoft Corp. IntelliMouse Explorer 4.0 (IntelliPoint) 046d:c313 Logitech, Inc. Internet 350 Keyboard The following USB2 devices had problems: 0b95:7720 ASIX Electronics Corp. AX88772 [ 489.140536] usb 1-3: new high-speed USB device number 81 using xhci-tegra [ 489.260860] usb 1-3: device descriptor read/64, error -71 [ 489.370804] xhci-tegra 7009.usb: Setup ERROR: setup context command for slot 1. [ 489.378463] usb 1-3: hub failed to enable device, error -22 [ 489.500531] usb 1-3: new high-speed USB device number 82 using xhci-tegra [ 489.655708] usb 1-3: can't set config #1, error -71 [ 489.661231] usb 1-3: USB disconnect, device number 82 [ 489.940531] usb 1-3: new high-speed USB device number 83 using xhci-tegra [ 490.060860] usb 1-3: device descriptor read/64, error -71 [ 490.170805] xhci-tegra 7009.usb: Setup ERROR: setup context command for slot 1. [ 490.178462] usb 1-3: hub failed to enable device, error -22 (repeats over and over) 15a4:1336 Afatech Technologies, Inc. SDHC/MicroSD/MMC/MS/M2/CF/XD Flash Card Reader The power light comes on, and the activity light just keeps flashing fast. Usually the activity light flashes a couple times and then turns off. There is nothing in dmesg at all for this device. 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Not detected. There is nothing in dmesg at all for this device. 1bcf:0c31 Sunplus Innovation Technology Inc. SPIF30x Serial-ATA bridge Not detected. There is nothing in dmesg at all for this device. -- 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: Hitting unused qh not empty BUG in qh_destroy
On Tue, 16 Sep 2014 10:44:45 -0400 Alan Stern st...@rowland.harvard.edu wrote: On Tue, 16 Sep 2014, Joe Lawrence wrote: You can check for this. Sprinkle ehci_info messages throughout ehci_stop, printing the value of ehci-async-qh_next.qh. It should be NULL the entire time. I re-ran the tests with the following changes: - moved num_async debug up above struct ehci_hcd.priv[0] :) - added verbose debug msg in check_async_ring to display the new num_async value - added ehci_info to every other line in ehci_stop % grep ':66:00.1' vmcore-dmesg.txt [ 4936.956739] pci :66:00.1: [8086:1d2d] type 00 class 0x0c0320 [ 4936.956789] pci :66:00.1: reg 0x10: [mem 0xa400-0xa7ff] [ 4936.957019] pci :66:00.1: PME# supported from D0 D3hot D3cold [ 4939.564933] ehci-pci :66:00.1: EHCI Host Controller [ 4939.565462] ehci-pci :66:00.1: new USB bus registered, assigned bus number 4 [ 4939.565498] ehci-pci :66:00.1: debug port 2 [ 4939.569466] ehci-pci :66:00.1: cache line size of 64 is not supported [ 4939.569533] ehci-pci :66:00.1: irq 13, io mem 0xa400 [ 4939.574794] ehci-pci :66:00.1: USB 2.0 started, EHCI 1.00 [ 4939.575410] usb usb4: SerialNumber: :66:00.1 [ 4940.089044] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 1, qh=88083d6b4558 [ 4941.795700] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 0, qh= (null) [ 4941.895713] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 1, qh=88083d6b4558 [ 4941.943761] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 0, qh= (null) [ 4942.002715] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 1, qh=88083d6b4558 [ 4942.064346] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 0, qh= (null) [ 4942.156646] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 1, qh=88083d6b4558 [ 4942.226028] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 0, qh= (null) [ 4942.274185] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 1, qh=88083d6b4558 [ 4942.329196] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 0, qh= (null) [ 4942.391055] ehci-pci :66:00.1: check_async_ring:970 ehci(8808419839d0)-num_async = 1, qh=88083d6b4558 [ 4942.629653] ehci-pci :66:00.1: HC died; cleaning up [ 4945.663153] ehci-pci :66:00.1: remove, state 1 [ 4945.733934] ehci-pci :66:00.1: ehci_stop:420 ehci(8808419839d0)-num_async = 1 [ 4945.774242] ehci-pci :66:00.1: ehci_stop:427 ehci(8808419839d0)-num_async = 1 [ 4945.814791] ehci-pci :66:00.1: ehci_stop:429 ehci(8808419839d0)-num_async = 1 [ 4945.855938] ehci-pci :66:00.1: ehci_stop:431 ehci(8808419839d0)-num_async = 1 [ 4945.897145] ehci-pci :66:00.1: ehci_stop:433 ehci(8808419839d0)-num_async = 1 [ 4945.938791] ehci-pci :66:00.1: ehci_stop:436 ehci(8808419839d0)-num_async = 1 [ 4945.980491] ehci-pci :66:00.1: ehci_stop:438 ehci(8808419839d0)-num_async = 1 [ 4946.01] ehci-pci :66:00.1: ehci_stop:440 ehci(8808419839d0)-num_async = 1 [ 4946.063936] ehci-pci :66:00.1: ehci_stop:444 ehci(8808419839d0)-num_async = 1 [ 4946.105631] ehci-pci :66:00.1: ehci_stop:446 ehci(8808419839d0)-num_async = 1 [ 4946.241802] ehci-pci :66:00.1: ehci_stop:448 ehci(8808419839d0)-num_async = 1 where ehci_stop line 420 is function entry and line 448 function return. Notice that check_async_ring incremented num_async just before the HC died/removed and then num_async was 1 throughout ehci_stop. qh_destroy then BUGs with a struct ehci_hcd *ehci of 8808419839d0. This says that ehci-num_async ended up equal to 1. But in your previous email, you said the final printout indicated it was equal to 0. Did something change in the meantime? I just double checked the logs, and that is correct. However, the earlier reports of a dozen or so crashes included num_async at the end of struct ehci_hcd. Perhaps the priv[] array clobbered the value? Sorry for the confusion. Anyway, the log above means that a QH was linked before the HC died, but then it was never unlinked. Please add a line at the start of ehci_endpoint_disable, printing out the value of ep-hcpriv for comparison with the values listed above. Will do. Also, let's see the contents of *qh and *(qh-hw) for the left-over QH at *(ehci-async-qh_next.qh). You can get those right away from your crash dump data, right? Yep, interestingly enough, *(ehci-async-qh_next.qh) appears to be mostly full of zeros:
Re: [PATCH 1/4] usb: hub: convert khubd into workqueue
On Tue, 16 Sep 2014, Petr [iso-8859-1] Ml�dek wrote:
Anyway, the solution for the race between kick_hub_wq() and
hub_event() might be to get the reference already in kick_hub_wq().
Yes, this probably would work.
I mean something like:
static void kick_hub_wq(struct usb_hub *hub)
{
if (hub-disconnected || work_pending(hub-events))
return;
/*
* Suppress autosuspend until the event is proceed.
*
* Be careful and make sure that the symmetric operation is
* always called. We are here only when there is no pending
* work for this hub. Therefore put the interface either when
* the new work is called or when it is canceled.
*/
usb_autopm_get_interface_no_resume(to_usb_interface(hub-intfdev));
kref_get(hub-kref);
if (queue_work(hub_wq, hub-events))
return;
/* the work could not be scheduled twice */
kref_put(hub-kref, hub_release);
usb_autopm_put_interface_no_suspend(intf);
This should be usb_autopm_put_interface_async, not *_no_suspend,
because you don't know at this point whether the runtime PM usage
counter is 1. (You do know it was 1 at the time queue_work was
called, but it may have changed since then.)
}
And test for hub-disconnected at the very beginning of hub_event().
No, that's no good. The value isn't fully meaningful unless you are
holding the device lock. That's why the test for hub-disconnected is
placed where it is in hub_events.
Also we would need to put the reference when the work is canceled in
hub_disconnect().
You can't cancel the work in hub_disconnect. That's because cancelling
a work item is always synchronous -- there's no cancel_work, only
cancel_work_sync.
This is okay; removing items from the hub_event_list was only a minor
optimization anyway. There's no harm in letting the work item go ahead
and run.
Hmm, I am not 100% sure if we could call
usb_autopm_get_interface_no_resume() without any lock here.
I guess so because otherwise the original code would not work.
The check for hub-disconnected would fail if the struct was freed
before the lock was taken.
The caller of kick_khubd has to guarantee that the hub structure hasn't
been deallocated.
It looks promissing. hub-intfdev is released together with hub in
hub_release(). Also it seems that kick_* and *disconnect functions
are called with some top level lock. For example, there is used dev
lock in drivers/usb/core/device.c.
There's one more improvement you could make. It's not necessary to
call usb_get_dev and usb_put_dev every time hub_events runs.
Instead, we can call usb_get_dev once when the hub structure is created
and usb_put_dev in hub_release.
But you ignored what the comment says about don't let it be added
again.
If we increase the reference in kick_hub_wq() and test
hub-disconnected at the very beginning of hub_event() it
should not cause real problem. In the worst case, it will release
struct usb_hub there instead of in hub_disconnect(). It already happens
with the original code in some circumstances.
If you think that this is too tricky, I will put the lock back.
It's probably okay without the lock. Please post an updated patch
(just the first one in the series; the later ones will remain the same)
with the changes discussed here so I can review it.
Or better yet, rearrange the patch series. Make the first patch be the
one that removes the useless loop in hub_events. That patch will be
acceptable in any case, regardless of what happens with the workqueue
change. Then the second patch can be the conversion to a workqueue.
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
[ANNOUNCE] Tree closed for v3.18
Alright folks, we have -rc5 and I have applied the last 5 patches which were pending. My tree is now closed for v3.18 merge window with 87 non-merge commits. If your patches aren't there, good luck next time :-) Now, please, refrain from sending patches because I won't look much at them until v3.18-rc1 is out. cheers -- balbi signature.asc Description: Digital signature
Re: Ability to specify SCM_MULT_TARG quirk on command line
On Tue, 16 Sep 2014, Mark wrote: It's probably better just to rely on entries to the unusual_devs.h file. Those are automatically be available to anyone with an up-to-date kernel, with no need for messing around with module parameters. The trouble is though, that requires the user compile their own kernel. Which may not be practical due to lack of knowledge or e.g. booting from a live CD. This arises only if somebody has a device with multi-target capability that isn't already listed in unusual_devs.h. Since such devices are so rare, we shouldn't have to worry about this possibility. I can submit patches for devices I don't own to cover more (hopefully almost all) SCM-based devices, e.g. the USBConnect 2000 patch I submitted recently. But I wasn't sure what values to use for bcdDeviceMin and bcdDeviceMax. 0 and 0x would probably be best, so I'll repost the patch with that change. Another issue relates to manufacturer USB ID screw-ups. The Buffalo USB-SCSI cable is a good example. According to the Windows INF file available from http://buffalo.jp/download/driver/hd/mos-s640usb.html its USB ID is 0411:0001. However, according to the INF file from http://buffalo.jp/download/driver/lan/lua-tx.html the LUA-TX USB-Ethernet adapter can have ID 0411:0005 or 0411:0001... sigh. Given that, would it be possible/advisable to have an unusual-devs.h entry for the Buffalo USB-SCSI cable? It would be nice to get confirmation first from somebody who has one of those cables. 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: Hitting unused qh not empty BUG in qh_destroy
On Tue, 16 Sep 2014, Joe Lawrence wrote:
Anyway, the log above means that a QH was linked before the HC died,
but then it was never unlinked. Please add a line at the start of
ehci_endpoint_disable, printing out the value of ep-hcpriv for
comparison with the values listed above.
Will do.
Also, let's see the contents of *qh and *(qh-hw) for the left-over QH
at *(ehci-async-qh_next.qh). You can get those right away from your
crash dump data, right?
Yep, interestingly enough, *(ehci-async-qh_next.qh) appears to be
mostly full of zeros:
crash struct ehci_qh 0x88083d6b4558 *(ehci-async-qh_next.qh)
struct ehci_qh {
hw = 0x0,
qh_dma = 0x0,
qh_next = {
qh = 0x0,
itd = 0x0,
sitd = 0x0,
fstn = 0x0,
hw_next = 0x0,
ptr = 0x0
},
qtd_list = {
next = 0x0,
prev = 0x0
},
intr_node = {
next = 0x0,
prev = 0x0
},
dummy = 0x0,
unlink_node = {
next = 0x0,
prev = 0x0
},
unlink_cycle = 0x6,
qh_state = 0x0,
xacterrs = 0x0,
usecs = 0x0,
gap_uf = 0x0,
c_usecs = 0x0,
tt_usecs = 0x0,
period = 0x0,
start = 0x0,
dev = 0x6,
is_out = 0x0,
clearing_tt = 0x0,
dequeue_during_giveback = 0x0,
exception = 0x0
}
So this QH was destroyed properly, but somehow the link pointer in
ehci-async continued to point at it. And it got destroyed without
passing through single_unlink_async.
Maybe you should also add a check at the end of ehci_endpoint_disable,
just before the done: label. For example,
BUG_ON(ehci-async-qh_next.qh == qh);
Then if you really want to be thorough, in single_unlink_async, just
after the while loop, print the values of prev, prev-qh_next.qh, qh,
and qh-qh_next.qh. And in qh_link_async, just after the wmb(), print
the values of head-qh_next.qh and qh. (This could end up generating
quite a lot of output...)
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] storage: Add quirk for Ariston Technologies iConnect USB to SCSI adapter
Hi, The Ariston Technologies iConnect 025 and iConnect 050 (also known as e.g. iSCSI-50) are SCSI-USB converters which use Shuttle Technology/SCM Microsystems chips. Only the connectors differ; both have the same USB ID. The US_FL_SCM_MULT_TARG quirk is required to use SCSI devices with ID other than 0. I don't have one of these, but based on the other entries for Shuttle/ SCM-based converters this patch is very likely correct. I used 0x and 0x for bcdDeviceMin and bcdDeviceMax because I'm not sure which bcdDevice value the products use. Signed-off-by: Mark Knibbs ma...@clara.co.uk --- diff -up linux-3.17-rc4/drivers/usb/storage/unusual_devs.h.orig linux-3.17-rc4/drivers/usb/storage/unusual_devs.h --- linux-3.17-rc4/drivers/usb/storage/unusual_devs.h.orig 2014-09-08 00:09:43.0 +0100 +++ linux-3.17-rc4/drivers/usb/storage/unusual_devs.h 2014-09-16 16:35:14.0 +0100 @@ -1980,6 +1980,12 @@ UNUSUAL_DEV( 0x177f, 0x0400, 0x, 0x USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_BULK_IGNORE_TAG | US_FL_MAX_SECTORS_64 ), +UNUSUAL_DEV( 0x1822, 0x0001, 0x, 0x, + Ariston Technologies, + iConnect USB to SCSI adapter, + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_euscsi_init, + US_FL_SCM_MULT_TARG ), + /* Reported by Hans de Goede hdego...@redhat.com * These Appotech controllers are found in Picture Frames, they provide a * (buggy) emulation of a cdrom drive which contains the windows software -- 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: am335x musb_hdrc broken(?)
2014-09-11 0:32 GMT+04:00 Alan Stern st...@rowland.harvard.edu: If all else fails, git bisect might pinpoint the cause of the problem. Alan Stern I would have need config bisect. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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 fix for 3.17 0/1] uas: Add no-report-opcodes quirk
Hi Greg, et al, Another day, another uas quirk. Although you may not see it that way, this is actually a good thing :) With the new uas error handling code (which users are testing through a stand-alone version of the uas driver), people are now actually sending me logs with useful error messages instead of complaining uas crashes their system. These error logs allow me to figure out the right quirks for various models (which unfortunately are necessary), and get more uas disk enclosures to work properly in uas mode. 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 fix for 3.17] uas: Add no-report-opcodes quirk
Besides the ASM1051 (*) needing sdev-no_report_opcodes = 1, it turns out that
the JMicron JMS567 also needs it to work properly with uas (usb-storage always
sets it). Since some of the scsi devs were not to keen on the idea to
outrightly set sdev-no_report_opcodes = 1 for all uas devices, so add a quirk
for this, and set it for the JMS567.
*) Which has become a non-issue since we've completely blacklisted uas on
the ASM1051 for other reasons
Cc: sta...@vger.kernel.org
Reported-and-tested-by: Claudio Bizzarri claudio.bizza...@gmail.com
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Documentation/kernel-parameters.txt | 2 ++
drivers/usb/storage/uas.c | 4
drivers/usb/storage/unusual_uas.h | 7 +++
drivers/usb/storage/usb.c | 5 -
include/linux/usb_usual.h | 2 ++
5 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index dd4fe98..1edd5fd 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3522,6 +3522,8 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
READ_DISC_INFO command);
e = NO_READ_CAPACITY_16 (don't use
READ_CAPACITY_16 command);
+ f = NO_REPORT_OPCODES (don't use report opcodes
+ command, uas only);
h = CAPACITY_HEURISTICS (decrease the
reported device capacity by one
sector if the number is odd);
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 75d2ccd..2713693 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -961,6 +961,10 @@ static int uas_slave_alloc(struct scsi_device *sdev)
static int uas_slave_configure(struct scsi_device *sdev)
{
struct uas_dev_info *devinfo = sdev-hostdata;
+
+ if (devinfo-flags US_FL_NO_REPORT_OPCODES)
+ sdev-no_report_opcodes = 1;
+
scsi_set_tag_type(sdev, MSG_ORDERED_TAG);
scsi_activate_tcq(sdev, devinfo-qdepth - 2);
return 0;
diff --git a/drivers/usb/storage/unusual_uas.h
b/drivers/usb/storage/unusual_uas.h
index 3ff2dd4..3e62437 100644
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -53,3 +53,10 @@ UNUSUAL_DEV(0x0bc2, 0x3312, 0x, 0x,
Expansion Desk,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_NO_ATA_1X),
+
+/* Reported-by: Claudio Bizzarri claudio.bizza...@gmail.com */
+UNUSUAL_DEV(0x152d, 0x0567, 0x, 0x,
+ JMicron,
+ JMS567,
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_NO_REPORT_OPCODES),
diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index b9d1b93..f60e7d4 100644
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -479,7 +479,7 @@ void usb_stor_adjust_quirks(struct usb_device *udev,
unsigned long *fflags)
US_FL_SINGLE_LUN | US_FL_NO_WP_DETECT |
US_FL_NO_READ_DISC_INFO | US_FL_NO_READ_CAPACITY_16 |
US_FL_INITIAL_READ10 | US_FL_WRITE_CACHE |
- US_FL_NO_ATA_1X);
+ US_FL_NO_ATA_1X | US_FL_NO_REPORT_OPCODES);
p = quirks;
while (*p) {
@@ -517,6 +517,9 @@ void usb_stor_adjust_quirks(struct usb_device *udev,
unsigned long *fflags)
case 'e':
f |= US_FL_NO_READ_CAPACITY_16;
break;
+ case 'f':
+ f |= US_FL_NO_REPORT_OPCODES;
+ break;
case 'h':
f |= US_FL_CAPACITY_HEURISTICS;
break;
diff --git a/include/linux/usb_usual.h b/include/linux/usb_usual.h
index d271f88..a7f2604 100644
--- a/include/linux/usb_usual.h
+++ b/include/linux/usb_usual.h
@@ -75,6 +75,8 @@
/* Cannot handle FUA in WRITE or READ CDBs */ \
US_FLAG(NO_ATA_1X, 0x0200) \
/* Cannot handle ATA_12 or ATA_16 CDBs */ \
+ US_FLAG(NO_REPORT_OPCODES, 0x0400) \
+ /* Cannot handle MI_REPORT_SUPPORTED_OPERATION_CODES */ \
#define US_FLAG(name, value) US_FL_##name = value ,
enum { US_DO_ALL_FLAGS };
--
2.1.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
Re: am335x musb_hdrc broken(?)
2014-09-10 23:50 GMT+04:00 Felipe Balbi ba...@ti.com: hmmm, protocol error. Hi, I've found the root of the problem. CONFIG_USB_MUSB_TUSB6010=m affects the code inside musb_hdrc inspite of tusb6010 not loaded at all. When I disable CONFIG_USB_MUSB_TUSB6010 in my configuration, everything works fine. After the following modification, usb seems to be semi-working with CONFIG_USB_MUSB_TUSB6010=m. diff --git a/drivers/usb/musb/musb_regs.h b/drivers/usb/musb/musb_regs.h index 03f2655..a146b9a 100644 --- a/drivers/usb/musb/musb_regs.h +++ b/drivers/usb/musb/musb_regs.h @@ -234,12 +234,7 @@ #define MUSB_TESTMODE 0x0F/* 8 bit */ /* Get offset for a given FIFO from musb-mregs */ -#if defined(CONFIG_USB_MUSB_TUSB6010) || \ - defined(CONFIG_USB_MUSB_TUSB6010_MODULE) -#define MUSB_FIFO_OFFSET(epnum)(0x200 + ((epnum) * 0x20)) -#else #define MUSB_FIFO_OFFSET(epnum)(0x20 + ((epnum) * 4)) -#endif I am still testing, and suspect that musb_readb/musb_writeb stuff in musb_io.h is also the subject. The question is how to fix all this in correct way. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: am335x musb_hdrc broken(?)
Hi, On Tue, Sep 16, 2014 at 08:40:14PM +0400, Matwey V. Kornilov wrote: 2014-09-10 23:50 GMT+04:00 Felipe Balbi ba...@ti.com: hmmm, protocol error. Hi, I've found the root of the problem. CONFIG_USB_MUSB_TUSB6010=m affects the code inside musb_hdrc inspite of tusb6010 not loaded at all. When I disable CONFIG_USB_MUSB_TUSB6010 in my configuration, everything works fine. hmm, true we still have some brain farts wrt tusb6010 support. After the following modification, usb seems to be semi-working with CONFIG_USB_MUSB_TUSB6010=m. diff --git a/drivers/usb/musb/musb_regs.h b/drivers/usb/musb/musb_regs.h index 03f2655..a146b9a 100644 --- a/drivers/usb/musb/musb_regs.h +++ b/drivers/usb/musb/musb_regs.h @@ -234,12 +234,7 @@ #define MUSB_TESTMODE 0x0F/* 8 bit */ /* Get offset for a given FIFO from musb-mregs */ -#if defined(CONFIG_USB_MUSB_TUSB6010) || \ - defined(CONFIG_USB_MUSB_TUSB6010_MODULE) -#define MUSB_FIFO_OFFSET(epnum)(0x200 + ((epnum) * 0x20)) -#else #define MUSB_FIFO_OFFSET(epnum)(0x20 + ((epnum) * 4)) -#endif this can't be applied as it would break tusb6010. I am still testing, and suspect that musb_readb/musb_writeb stuff in musb_io.h is also the subject. The question is how to fix all this in correct way. the correct way would be very involved. Basically we need to strip musb core of tusb6010 specific code and move all that to the tusb6010 glue layer. -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 0/9] Tegra xHCI support
On Tue, Sep 16, 2014 at 8:26 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 01:30 PM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 11:09 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 11:06 AM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and USB3.0 memory sticks and ethernet dongles using controller firmware recently posted by Andrew Chew [2]. ... Stephen, Thierry, have either of you had a chance to test this series? I haven't had a chance to yet. I just went to try it out, and found that it depends on a whole slew of other patches that I don't have. Is there a git branch somewhere to save me having to track down all the dependencies? Yes, Tomeu has the branch he used for testing here: http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=3.17rc4-xhci Hmm. That git server was quite reluctant to cough up its bits, but it did eventually. You'll also need the firmware Andrew Chew posted: https://patchwork.ozlabs.org/patch/384013/ The XHCI driver can't load its firmware unless it's a module; if I make it built-in, it fails immediately with error -2 during Direct firmware loading. The driver needs to work with either immediate or deferred firmware loading. If you want the driver to be built-in, you'll either need to build the firmware in as well (i.e. EXTRA_FIRMWARE) or enable FW_LOADER_USER_HELPER_FALLBACK to load with userspace/uevent (though apparently this is deprecated). The following USB2 devices had problems: 0b95:7720 ASIX Electronics Corp. AX88772 [ 489.140536] usb 1-3: new high-speed USB device number 81 using xhci-tegra [ 489.260860] usb 1-3: device descriptor read/64, error -71 [ 489.370804] xhci-tegra 7009.usb: Setup ERROR: setup context command for slot 1. [ 489.378463] usb 1-3: hub failed to enable device, error -22 [ 489.500531] usb 1-3: new high-speed USB device number 82 using xhci-tegra [ 489.655708] usb 1-3: can't set config #1, error -71 [ 489.661231] usb 1-3: USB disconnect, device number 82 [ 489.940531] usb 1-3: new high-speed USB device number 83 using xhci-tegra [ 490.060860] usb 1-3: device descriptor read/64, error -71 [ 490.170805] xhci-tegra 7009.usb: Setup ERROR: setup context command for slot 1. [ 490.178462] usb 1-3: hub failed to enable device, error -22 (repeats over and over) 15a4:1336 Afatech Technologies, Inc. SDHC/MicroSD/MMC/MS/M2/CF/XD Flash Card Reader The power light comes on, and the activity light just keeps flashing fast. Usually the activity light flashes a couple times and then turns off. There is nothing in dmesg at all for this device. 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Not detected. There is nothing in dmesg at all for this device. 1bcf:0c31 Sunplus Innovation Technology Inc. SPIF30x Serial-ATA bridge Not detected. There is nothing in dmesg at all for this device. Thanks, I'll try to figure out what's going on here. -- 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: am335x musb_hdrc broken(?)
2014-09-16 20:51 GMT+04:00 Felipe Balbi ba...@ti.com: this can't be applied as it would break tusb6010. Sure. MUSB_FIFO_OFFSET is used only in musb_core_init to set endpoints. Can not understand whether endpoint setup can be moved to musb_platform_init. Or yet another callback to musb_platform_ops has to be introduced? -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: am335x musb_hdrc broken(?)
Hi, On Tue, Sep 16, 2014 at 09:08:17PM +0400, Matwey V. Kornilov wrote: 2014-09-16 20:51 GMT+04:00 Felipe Balbi ba...@ti.com: this can't be applied as it would break tusb6010. Sure. MUSB_FIFO_OFFSET is used only in musb_core_init to set endpoints. Can not understand whether endpoint setup can be moved to musb_platform_init. Or yet another callback to musb_platform_ops has to be introduced? we could, perhaps, pass a flag to change those offsets, but not a new callback, I'm trying to get rid of some of them :-) -- balbi signature.asc Description: Digital signature
Re: am335x musb_hdrc broken(?)
2014-09-16 21:25 GMT+04:00 Felipe Balbi ba...@ti.com: we could, perhaps, pass a flag to change those offsets, but not a new callback, I'm trying to get rid of some of them :-) We could have a tool musb_is_tusb(musb) (like dev_is_pci(dev)) instead of just a flag. But it is also a leakage in abstraction. I see also that void* private is required both by struct musb_hw_ep and struct musb. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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: am335x musb_hdrc broken(?)
Ok. What is about musb_io.h? What does it mean TUSB6010 doesn't allow 8-bit access; 16-bit access is the minimum.? I think __raw_readb is kind of return *(u8_t*)(addr), but this is CPU stuff as far as I understand. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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 v9 1/3] usb: dwc3: qcom: Add device tree binding
Hi Andy,
On Fri, Sep 12, 2014 at 02:28:06PM -0500, Andy Gross wrote:
+Example device nodes:
+
+ hs_phy: phy@100f8800 {
+ compatible = qcom,dwc3-hs-usb-phy;
+ reg = 0x100f8800 0x30;
Just wanted to point out that in our downstream code, the glue
device/driver, i.e. qcom,dwc3, does claim an entire register region
that encompasses the same registers used by these PHYs. I noticed you're
not adding a reg resource to the glue node below in this patchset. In
order to allow multiple devices to use the overlapping regions, we avoid
calling devm_ioremap_resource() and instead call devm_ioremap_nocache()
directly which bypasses the request_mem_region() call, which I don't
think is an entirely correct thing to do.
On the other hand I'm trying to think of use cases on our other SOCs
(MSM8974, APQ8084) where the glue actually would need access to the same
or adjacent IO registers that couldn't just be handled directly by these
PHY drivers. Should we accommodate for the potential of overlapping
regions or should we just hold the line here and maybe only expose with
finer granularity the registers that will actually be needed by the PHYs
glue respectively?
+ clocks = gcc USB30_0_UTMI_CLK;
+ clock-names = ref;
+ #phy-cells = 0;
+
+ status = ok;
+ };
+
+ ss_phy: phy@100f8830 {
+ compatible = qcom,dwc3-ss-usb-phy;
+ reg = 0x100f8830 0x30;
+ clocks = gcc USB30_0_MASTER_CLK;
+ clock-names = ref;
+ #phy-cells = 0;
+
+ status = ok;
+ };
+
+ usb3_0: usb30@0 {
+ compatible = qcom,dwc3;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = gcc USB30_0_MASTER_CLK;
+ clock-names = core;
+
+ ranges;
+
+ status = ok;
+
+ dwc3@1000 {
+ compatible = snps,dwc3;
+ reg = 0x1000 0xcd00;
+ interrupts = 0 205 0x4;
+ phys = hs_phy, ss_phy;
+ phy-names = usb2-phy, usb3-phy;
+ tx-fifo-resize;
+ dr_mode = host;
+ };
+ };
+
Thanks,
Jack
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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: Hitting unused qh not empty BUG in qh_destroy
On Tue, 16 Sep 2014 11:56:14 -0400
Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 16 Sep 2014, Joe Lawrence wrote:
Anyway, the log above means that a QH was linked before the HC died,
but then it was never unlinked. Please add a line at the start of
ehci_endpoint_disable, printing out the value of ep-hcpriv for
comparison with the values listed above.
Will do.
Also, let's see the contents of *qh and *(qh-hw) for the left-over QH
at *(ehci-async-qh_next.qh). You can get those right away from your
crash dump data, right?
Yep, interestingly enough, *(ehci-async-qh_next.qh) appears to be
mostly full of zeros:
crash struct ehci_qh 0x88083d6b4558
*(ehci-async-qh_next.qh)
struct ehci_qh {
hw = 0x0,
qh_dma = 0x0,
qh_next = {
qh = 0x0,
itd = 0x0,
sitd = 0x0,
fstn = 0x0,
hw_next = 0x0,
ptr = 0x0
},
qtd_list = {
next = 0x0,
prev = 0x0
},
intr_node = {
next = 0x0,
prev = 0x0
},
dummy = 0x0,
unlink_node = {
next = 0x0,
prev = 0x0
},
unlink_cycle = 0x6,
qh_state = 0x0,
xacterrs = 0x0,
usecs = 0x0,
gap_uf = 0x0,
c_usecs = 0x0,
tt_usecs = 0x0,
period = 0x0,
start = 0x0,
dev = 0x6,
is_out = 0x0,
clearing_tt = 0x0,
dequeue_during_giveback = 0x0,
exception = 0x0
}
So this QH was destroyed properly, but somehow the link pointer in
ehci-async continued to point at it. And it got destroyed without
passing through single_unlink_async.
Maybe you should also add a check at the end of ehci_endpoint_disable,
just before the done: label. For example,
BUG_ON(ehci-async-qh_next.qh == qh);
Then if you really want to be thorough, in single_unlink_async, just
after the while loop, print the values of prev, prev-qh_next.qh, qh,
and qh-qh_next.qh. And in qh_link_async, just after the wmb(), print
the values of head-qh_next.qh and qh. (This could end up generating
quite a lot of output...)
Alan Stern
Quick turn around on this one :)
crash log | grep :2c:00.0
pci :2c:00.0: [8086:1d26] type 00 class 0x0c0320
pci :2c:00.0: reg 0x10: [mem 0x9000-0x93ff]
pci :2c:00.0: PME# supported from D0 D3hot D3cold
ehci-pci :2c:00.0: EHCI Host Controller
ehci-pci :2c:00.0: new USB bus registered, assigned bus number 1
ehci-pci :2c:00.0: debug port 2
ehci-pci :2c:00.0: cache line size of 64 is not supported
ehci-pci :2c:00.0: irq 10, io mem 0x9000
ehci-pci :2c:00.0: USB 2.0 started, EHCI 1.00
usb usb1: SerialNumber: :2c:00.0
ehci-pci :2c:00.0: qh_link_async:1003 ehci = 88084ff1b088,
head-qh_next.qh = (null), qh = 88083eacae50
ehci-pci :2c:00.0: HC died; cleaning up
ehci-pci :2c:00.0: ehci_endpoint_disable:944 ep-hcpriv = 88083eacae50,
ehci(88084ff1b088)-num_async = 1, ehci-async-qh_next.qh =
88083eacae50
[ cut here ]
kernel BUG at drivers/usb/host/ehci-hcd.c:1002!
invalid opcode: [#1] SMP
...
CPU: 0 PID: 207 Comm: khubd Tainted: PF O--
3.10.0-123.6.3.el7.bigphysarea_expedient1_usb4.x86_64 #1
Hardware name: Stratus ftServer 6400/G7LAZ, BIOS BIOS Version 6.3:57 12/25/2013
task: 880853ff8cb0 ti: 880853434000 task.ti: 880853434000
RIP: 0010:[814157c6] [814157c6]
ehci_endpoint_disable+0x1f6/0x200
RSP: 0018:880853435ca0 EFLAGS: 00010046
RAX: 8800372cc720 RBX: 88083eacae50 RCX: dead00200200
RDX: 88085f800710 RSI: 0047 RDI: 0047
RBP: 880853435ce0 R08: 88085f800710 R09: 000100230022
R10: 88085f807600 R11: 81412158 R12: 88084ff1ae68
R13: 88084ff1b174 R14: 880851914a88 R15: 0246
FS: () GS:88085fc0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7ffc501a2000 CR3: 000850402000 CR4: 000407f0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Stack:
88080001 88083eacae50 88084ff1b088 880851914a40
880851914a88 0001 880851914a40 ff00
880853435d00 813fabf3 880851914a40 880851914a88
Call Trace:
[813fabf3] usb_hcd_disable_endpoint+0x33/0x40
[813fd8b9] usb_disable_endpoint+0x69/0x90
[813effbc] usb_ep0_reinit+0x1c/0x40
[813f4fba] hub_port_connect_change+0x33a/0xb50
[813f5b49] hub_events+0x379/0xa30
[813f6245] hub_thread+0x45/0x1a0
[81086ac0] ? wake_up_bit+0x30/0x30
[813f6200] ? hub_events+0xa30/0xa30
[81085aff] kthread+0xcf/0xe0
[81085a30] ? kthread_create_on_node+0x140/0x140
[815f31ec] ret_from_fork+0x7c/0xb0
[81085a30] ? kthread_create_on_node+0x140/0x140
Just
Re: [Patch v9 1/3] usb: dwc3: qcom: Add device tree binding
Hi,
On Tue, Sep 16, 2014 at 11:15:43AM -0700, Jack Pham wrote:
Hi Andy,
On Fri, Sep 12, 2014 at 02:28:06PM -0500, Andy Gross wrote:
+Example device nodes:
+
+ hs_phy: phy@100f8800 {
+ compatible = qcom,dwc3-hs-usb-phy;
+ reg = 0x100f8800 0x30;
Just wanted to point out that in our downstream code, the glue
device/driver, i.e. qcom,dwc3, does claim an entire register region
that encompasses the same registers used by these PHYs. I noticed you're
not adding a reg resource to the glue node below in this patchset. In
order to allow multiple devices to use the overlapping regions, we avoid
calling devm_ioremap_resource() and instead call devm_ioremap_nocache()
directly which bypasses the request_mem_region() call, which I don't
think is an entirely correct thing to do.
On the other hand I'm trying to think of use cases on our other SOCs
(MSM8974, APQ8084) where the glue actually would need access to the same
or adjacent IO registers that couldn't just be handled directly by these
PHY drivers. Should we accommodate for the potential of overlapping
regions or should we just hold the line here and maybe only expose with
finer granularity the registers that will actually be needed by the PHYs
glue respectively?
I prefer to keep things separated. Glue only needs to access whatever
belongs to glue. If a register related to PHY settings, it should be in
the PHY address space.
cheers
--
balbi
signature.asc
Description: Digital signature
Re: [Patch v9 3/3] phy: Add Qualcomm DWC3 HS/SS PHY driver
Hi Andy,
On Fri, Sep 12, 2014 at 02:28:08PM -0500, Andy Gross wrote:
+static int qcom_dwc3_hs_phy_init(struct qcom_dwc3_usb_phy *phy_dwc3)
+{
+ u32 val;
+
+ /*
+ * HSPHY Initialization: Enable UTMI clock, select 19.2MHz fsel
+ * enable clamping, and disable RETENTION (power-on default is ENABLED)
+ */
+ val = HSUSB_CTRL_DPSEHV_CLAMP | HSUSB_CTRL_DMSEHV_CLAMP |
+ HSUSB_CTRL_RETENABLEN | HSUSB_CTRL_COMMONONN |
+ HSUSB_CTRL_OTGSESSVLD_CLAMP | HSUSB_CTRL_ID_HV_CLAMP |
+ HSUSB_CTRL_DPSEHV_CLAMP | HSUSB_CTRL_UTMI_OTG_VBUS_VALID |
+ HSUSB_CTRL_UTMI_CLK_EN | HSUSB_CTRL_CLAMP_EN | 0x70;
+
+ /* use core clock if external reference is not present */
+ if (!phy_dwc3-xo_clk)
+ val |= HSUSB_CTRL_USE_CLKCORE;
+
+ writel(val, phy_dwc3-base + HSUSB_PHY_CTRL_REG);
+ usleep_range(2000, 2200);
+
+ /* Disable (bypass) VBUS and ID filters */
+ writel(HSUSB_GCFG_XHCI_REV, phy_dwc3-base + QSCRATCH_GENERAL_CFG);
Is this comment accurate? I believe this bit forces the IP to behave in
XHCI rev 1.0. In which case, shouldn't it be done in the glue driver?
Jack
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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: am335x musb_hdrc broken(?)
Hi, (man, talk about trimming... leave some context ;-) On Tue, Sep 16, 2014 at 10:06:33PM +0400, Matwey V. Kornilov wrote: Ok. What is about musb_io.h? What does it mean TUSB6010 doesn't allow 8-bit access; 16-bit access is the minimum.? it means that readb() won't work. I think __raw_readb is kind of return *(u8_t*)(addr), but this is CPU stuff as far as I understand. tusb6010 is a discrete device connected through GPMC (general purpose memory controller). Basically, this tells you that tusb6010 cannot understand 8-bit accesses through gpmc. -- balbi signature.asc Description: Digital signature
Re: Ability to specify SCM_MULT_TARG quirk on command line
On Tue, 16 Sep 2014 11:40:03 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: On Tue, 16 Sep 2014, Mark wrote: ... Another issue relates to manufacturer USB ID screw-ups. The Buffalo USB-SCSI cable is a good example. According to the Windows INF file available from http://buffalo.jp/download/driver/hd/mos-s640usb.html its USB ID is 0411:0001. However, according to the INF file from http://buffalo.jp/download/driver/lan/lua-tx.html the LUA-TX USB-Ethernet adapter can have ID 0411:0005 or 0411:0001... sigh. Given that, would it be possible/advisable to have an unusual-devs.h entry for the Buffalo USB-SCSI cable? It would be nice to get confirmation first from somebody who has one of those cables. Someone reported an issue related to that in 2006 on the Japanese debian-users list: http://lists.debian.or.jp/debian-users/200608/msg00010.html They were using a Debian kernel based on 2.6.17, and based on the dmesg output both usb-storage and pegasus drivers try to claim the device. I'll paste some excerpts below. Since a quirk entry in unusual-devs.h would only apply to usb-storage, it should not cause additional problems for a USB-Ethernet device with the same ID, right? I guess it would be necessary to blacklist the pegasus module in order to use a Buffalo USB-SCSI cable (with or without quirk). usb 2-1: new full speed USB device using uhci_hcd and address 4 usb 2-1: configuration #1 chosen from 1 choice Initializing USB Mass Storage driver... scsi0 : SCSI emulation for USB Mass Storage devices usbcore: registered new driver usb-storage USB Mass Storage support registered. usb-storage: device found at 4 usb-storage: waiting for device to settle before scanning pegasus: v0.6.13 (2005/11/13), Pegasus/Pegasus II USB Ethernet driver usbcore: registered new driver pegasus usb 2-1: reset full speed USB device using uhci_hcd and address 4 usb 2-1: reset full speed USB device using uhci_hcd and address 4 usb 2-1: reset full speed USB device using uhci_hcd and address 4 usb 2-1: reset full speed USB device using uhci_hcd and address 4 usb-storage: device scan complete lsusb reported Bus 002 Device 010: ID 0411:0001 MelCo., Inc. LUA-TX Ethernet [pegasus] (because that's what's in the usb.ids list for product 0411:0001) From /proc/bus/usb/devices T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0411 ProdID=0001 Rev= 1.00 S: Manufacturer=Shuttle Technology Inc. S: Product=eUSCSI Bridge Ver 1.11 S: SerialNumber=07 ... Mark -- 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: Hitting unused qh not empty BUG in qh_destroy
On Tue, 16 Sep 2014, Joe Lawrence wrote: Quick turn around on this one :) crash log | grep :2c:00.0 pci :2c:00.0: [8086:1d26] type 00 class 0x0c0320 pci :2c:00.0: reg 0x10: [mem 0x9000-0x93ff] pci :2c:00.0: PME# supported from D0 D3hot D3cold ehci-pci :2c:00.0: EHCI Host Controller ehci-pci :2c:00.0: new USB bus registered, assigned bus number 1 ehci-pci :2c:00.0: debug port 2 ehci-pci :2c:00.0: cache line size of 64 is not supported ehci-pci :2c:00.0: irq 10, io mem 0x9000 ehci-pci :2c:00.0: USB 2.0 started, EHCI 1.00 usb usb1: SerialNumber: :2c:00.0 ehci-pci :2c:00.0: qh_link_async:1003 ehci = 88084ff1b088, head-qh_next.qh = (null), qh = 88083eacae50 ehci-pci :2c:00.0: HC died; cleaning up ehci-pci :2c:00.0: ehci_endpoint_disable:944 ep-hcpriv = 88083eacae50, ehci(88084ff1b088)-num_async = 1, ehci-async-qh_next.qh = 88083eacae50 [ cut here ] kernel BUG at drivers/usb/host/ehci-hcd.c:1002! Aha! So we triggered the BUG_ON you added to ehci_endpoint_disable. invalid opcode: [#1] SMP ... CPU: 0 PID: 207 Comm: khubd Tainted: PF O-- 3.10.0-123.6.3.el7.bigphysarea_expedient1_usb4.x86_64 #1 Hardware name: Stratus ftServer 6400/G7LAZ, BIOS BIOS Version 6.3:57 12/25/2013 task: 880853ff8cb0 ti: 880853434000 task.ti: 880853434000 RIP: 0010:[814157c6] [814157c6] ehci_endpoint_disable+0x1f6/0x200 This means we have to check what's going on inside ehci_endpoint_disable. We know qh wasn't NULL and we know that qh-hw wasn't NULL (otherwise we would have jumped over the BUG_ON). In particular, which case of the switch statement did we hit? ... And now I see the problem. It's these two lines just before the switch: if (ehci-rh_state EHCI_RH_RUNNING) qh-qh_state = QH_STATE_IDLE; That undoubtedly caused us to destroy the QH directly without unlinking it first. I'm pretty sure those two lines aren't needed any more. Try removing them and see if the problem persists. Just to review, I pasted the USB related patches to this kernel below. The drivers/usb/core/hub.c changes include: d8521af usb: assign default peer ports for root hubs (maxchild parts) c605f3c usb: hub: take hub-hdev reference when processing from eventlist the rest are debugging for the qh_destroy BUG. Yes, the patches look fine. 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: Ability to specify SCM_MULT_TARG quirk on command line
On Tue, 16 Sep 2014, Mark wrote: On Tue, 16 Sep 2014 11:40:03 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: On Tue, 16 Sep 2014, Mark wrote: ... Another issue relates to manufacturer USB ID screw-ups. The Buffalo USB-SCSI cable is a good example. According to the Windows INF file available from http://buffalo.jp/download/driver/hd/mos-s640usb.html its USB ID is 0411:0001. However, according to the INF file from http://buffalo.jp/download/driver/lan/lua-tx.html the LUA-TX USB-Ethernet adapter can have ID 0411:0005 or 0411:0001... sigh. Given that, would it be possible/advisable to have an unusual-devs.h entry for the Buffalo USB-SCSI cable? It would be nice to get confirmation first from somebody who has one of those cables. Someone reported an issue related to that in 2006 on the Japanese debian-users list: http://lists.debian.or.jp/debian-users/200608/msg00010.html They were using a Debian kernel based on 2.6.17, and based on the dmesg output both usb-storage and pegasus drivers try to claim the device. I'll paste some excerpts below. Was the device a USB-SCSI cable or a USB-Ethernet adapter? If it was an ethernet adapter then we don't want to include it in unusual_devs.h. If it was a SCSI cable then we do. Since a quirk entry in unusual-devs.h would only apply to usb-storage, it should not cause additional problems for a USB-Ethernet device with the same ID, right? It would, because it would cause usb-storage to try to bind to the ethernet device, thereby preventing the pegasus driver from binding. I guess it would be necessary to blacklist the pegasus module in order to use a Buffalo USB-SCSI cable (with or without quirk). Yes, apparently so. lsusb reported Bus 002 Device 010: ID 0411:0001 MelCo., Inc. LUA-TX Ethernet [pegasus] (because that's what's in the usb.ids list for product 0411:0001) From /proc/bus/usb/devices T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0411 ProdID=0001 Rev= 1.00 S: Manufacturer=Shuttle Technology Inc. S: Product=eUSCSI Bridge Ver 1.11 S: SerialNumber=07 Okay, so it was a SCSI cable. In that case, go ahead and add it to unusual_devs.h. Do you know what product ID the ethernet adapter actually uses? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] usb: dwc2: driver updates for 3.18
This is a series of updates to the dwc2 driver, all related to the handling of non-dword-aligned transfers. I have tested all of these on the Raspberry Pi and Altera SOCFPGA platform, and have not seen any regressions. v2: Remove pass gfp_t flags down to dwc2_hc_setup_align_buf() patch, since it had a fatal flaw. Reword the commit message for patch 2/2. Greg, can you apply this series to usb-next, please? Thanks. -- Paul Paul Zimmerman (2): usb: dwc2: clip max_transfer_size to 65535 usb: dwc2: handle DMA buffer unmapping sanely drivers/usb/dwc2/core.c | 7 +++ drivers/usb/dwc2/hcd.c | 42 +- drivers/usb/dwc2/hcd.h | 4 +++- drivers/usb/dwc2/hcd_intr.c | 22 -- 4 files changed, 39 insertions(+), 36 deletions(-) -- 2.1.0.24.g4109c28 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] usb: dwc2: handle DMA buffer unmapping sanely
The driver's handling of DMA buffers for non-aligned transfers
was kind of nuts. For IN transfers, it left the URB DMA buffer
mapped until the transfer completed, then synced it, copied the
data from the bounce buffer, then synced it again.
Instead of that, just call usb_hcd_unmap_urb_for_dma() to unmap
the buffer before starting the transfer. Then no syncing is
required when doing the copy. This should also allow handling of
other types of mappings besides just dma_map_single() ones.
Tested on Raspberry Pi and Altera SOCFPGA.
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
drivers/usb/dwc2/hcd.c | 42 +-
drivers/usb/dwc2/hcd.h | 4 +++-
drivers/usb/dwc2/hcd_intr.c | 22 --
3 files changed, 32 insertions(+), 36 deletions(-)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 4d918ed..0a0e6f0 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -697,29 +697,45 @@ static void *dwc2_hc_init_xfer(struct dwc2_hsotg *hsotg,
}
static int dwc2_hc_setup_align_buf(struct dwc2_hsotg *hsotg, struct dwc2_qh
*qh,
- struct dwc2_host_chan *chan, void *bufptr)
+ struct dwc2_host_chan *chan,
+ struct dwc2_hcd_urb *urb, void *bufptr)
{
u32 buf_size;
-
- if (chan-ep_type != USB_ENDPOINT_XFER_ISOC)
- buf_size = hsotg-core_params-max_transfer_size;
- else
- buf_size = 4096;
+ struct urb *usb_urb;
+ struct usb_hcd *hcd;
if (!qh-dw_align_buf) {
+ if (chan-ep_type != USB_ENDPOINT_XFER_ISOC)
+ buf_size = hsotg-core_params-max_transfer_size;
+ else
+ /* 3072 = 3 max-size Isoc packets */
+ buf_size = 3072;
+
qh-dw_align_buf = dma_alloc_coherent(hsotg-dev, buf_size,
qh-dw_align_buf_dma,
GFP_ATOMIC);
if (!qh-dw_align_buf)
return -ENOMEM;
+ qh-dw_align_buf_size = buf_size;
}
- if (!chan-ep_is_in chan-xfer_len) {
- dma_sync_single_for_cpu(hsotg-dev, chan-xfer_dma, buf_size,
- DMA_TO_DEVICE);
- memcpy(qh-dw_align_buf, bufptr, chan-xfer_len);
- dma_sync_single_for_device(hsotg-dev, chan-xfer_dma, buf_size,
- DMA_TO_DEVICE);
+ if (chan-xfer_len) {
+ dev_vdbg(hsotg-dev, %s(): non-aligned buffer\n, __func__);
+ usb_urb = urb-priv;
+
+ if (usb_urb) {
+ if (usb_urb-transfer_flags
+ (URB_SETUP_MAP_SINGLE | URB_DMA_MAP_SG |
+URB_DMA_MAP_PAGE | URB_DMA_MAP_SINGLE)) {
+ hcd = dwc2_hsotg_to_hcd(hsotg);
+ usb_hcd_unmap_urb_for_dma(hcd, usb_urb);
+ }
+ if (!chan-ep_is_in)
+ memcpy(qh-dw_align_buf, bufptr,
+ chan-xfer_len);
+ } else {
+ dev_warn(hsotg-dev, no URB in dwc2_urb\n);
+ }
}
chan-align_buf = qh-dw_align_buf_dma;
@@ -828,7 +844,7 @@ static int dwc2_assign_and_init_hc(struct dwc2_hsotg
*hsotg, struct dwc2_qh *qh)
/* Non DWORD-aligned buffer case */
if (bufptr) {
dev_vdbg(hsotg-dev, Non-aligned buffer\n);
- if (dwc2_hc_setup_align_buf(hsotg, qh, chan, bufptr)) {
+ if (dwc2_hc_setup_align_buf(hsotg, qh, chan, urb, bufptr)) {
dev_err(hsotg-dev,
%s: Failed to allocate memory to handle
non-dword aligned buffer\n,
__func__);
diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h
index fdc6d48..a12bb15 100644
--- a/drivers/usb/dwc2/hcd.h
+++ b/drivers/usb/dwc2/hcd.h
@@ -243,7 +243,8 @@ enum dwc2_transaction_type {
* @ntd:Actual number of transfer descriptors in a list
* @dw_align_buf: Used instead of original buffer if its physical address
* is not dword-aligned
- * @dw_align_buf_dma: DMA address for align_buf
+ * @dw_align_buf_size: Size of dw_align_buf
+ * @dw_align_buf_dma: DMA address for dw_align_buf
* @qtd_list: List of QTDs for this QH
* @channel:Host channel currently processing transfers for this QH
* @qh_list_entry: Entry for QH in either the periodic or non-periodic
@@ -276,6 +277,7 @@ struct dwc2_qh {
u16 start_split_frame;
u16 ntd;
u8 *dw_align_buf;
+ int dw_align_buf_size;
dma_addr_t dw_align_buf_dma;
struct
[PATCH v2 1/2] usb: dwc2: clip max_transfer_size to 65535
Clip max_transfer_size to 65535 for host. dwc2_hc_setup_align_buf() allocates coherent buffers with this size, and if it's too large we can exhaust the coherent DMA pool. Tested on Raspberry Pi and Altera SOCFPGA. Signed-off-by: Paul Zimmerman pa...@synopsys.com --- drivers/usb/dwc2/core.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c index ea0048a..d926945 100644 --- a/drivers/usb/dwc2/core.c +++ b/drivers/usb/dwc2/core.c @@ -2743,6 +2743,13 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg) width = (hwcfg3 GHWCFG3_XFER_SIZE_CNTR_WIDTH_MASK) GHWCFG3_XFER_SIZE_CNTR_WIDTH_SHIFT; hw-max_transfer_size = (1 (width + 11)) - 1; + /* +* Clip max_transfer_size to 65535. dwc2_hc_setup_align_buf() allocates +* coherent buffers with this size, and if it's too large we can +* exhaust the coherent DMA pool. +*/ + if (hw-max_transfer_size 65535) + hw-max_transfer_size = 65535; width = (hwcfg3 GHWCFG3_PACKET_SIZE_CNTR_WIDTH_MASK) GHWCFG3_PACKET_SIZE_CNTR_WIDTH_SHIFT; hw-max_packet_count = (1 (width + 4)) - 1; -- 2.1.0.24.g4109c28 -- 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: Ability to specify SCM_MULT_TARG quirk on command line
On Tue, 16 Sep 2014 15:36:42 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: On Tue, 16 Sep 2014, Mark wrote: On Tue, 16 Sep 2014 11:40:03 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: On Tue, 16 Sep 2014, Mark wrote: ... Another issue relates to manufacturer USB ID screw-ups. The Buffalo USB-SCSI cable is a good example. According to the Windows INF file available from http://buffalo.jp/download/driver/hd/mos-s640usb.html its USB ID is 0411:0001. However, according to the INF file from http://buffalo.jp/download/driver/lan/lua-tx.html the LUA-TX USB-Ethernet adapter can have ID 0411:0005 or 0411:0001... sigh. Given that, would it be possible/advisable to have an unusual-devs.h entry for the Buffalo USB-SCSI cable? It would be nice to get confirmation first from somebody who has one of those cables. Someone reported an issue related to that in 2006 on the Japanese debian-users list: http://lists.debian.or.jp/debian-users/200608/msg00010.html They were using a Debian kernel based on 2.6.17, and based on the dmesg output both usb-storage and pegasus drivers try to claim the device. I'll paste some excerpts below. Was the device a USB-SCSI cable or a USB-Ethernet adapter? If it was an ethernet adapter then we don't want to include it in unusual_devs.h. If it was a SCSI cable then we do. Since a quirk entry in unusual-devs.h would only apply to usb-storage, it should not cause additional problems for a USB-Ethernet device with the same ID, right? It would, because it would cause usb-storage to try to bind to the ethernet device, thereby preventing the pegasus driver from binding. I guess it would be necessary to blacklist the pegasus module in order to use a Buffalo USB-SCSI cable (with or without quirk). Yes, apparently so. lsusb reported Bus 002 Device 010: ID 0411:0001 MelCo., Inc. LUA-TX Ethernet [pegasus] (because that's what's in the usb.ids list for product 0411:0001) From /proc/bus/usb/devices T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0411 ProdID=0001 Rev= 1.00 S: Manufacturer=Shuttle Technology Inc. S: Product=eUSCSI Bridge Ver 1.11 S: SerialNumber=07 Okay, so it was a SCSI cable. In that case, go ahead and add it to unusual_devs.h. Do you know what product ID the ethernet adapter actually uses? Sadly, I think versions exist with *both* IDs 0411:0001 and 0411:0005, and the Windows INF file mentions both. Some searching gave related results... Post to linux-usb on 2000-04-02, About MELCO LUA-TX USB LAN ADAPTOR: https://www.mail-archive.com/linux-usb@suse.com/msg00569.html That's a patch to add support to the pegasus driver for Buffalo LUA-TX with ID 0411:0001. Post to freebsd-bugs on 2000-12-12, kern/11711: USB Ethernet LUA-TX product ID: http://marc.info/?l=netbsd-bugsm=97665695908785 The poster has an LUA-TX with ID 0411:0005. Is it possible to add an entry to unusual-devs.h, but have usb-storage only bind to the device if it reports itself as being a USB mass storage device? Or maybe to match the manufacturer or product string? Otherwise, if I add an entry for the Buffalo USB-SCSI cable, anyone who still uses an 0411:0001 LUA-TX would have to blacklist usb-storage (or disable the quirk on the kernel command line??). Mark -- 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/3] uwb: line length cleanup
Fix line length in uwb-internal.h
Signed-off-by: Thomas Pugliese thomas.pugli...@gmail.com
---
drivers/uwb/uwb-internal.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/uwb/uwb-internal.h b/drivers/uwb/uwb-internal.h
index 9a103b1..6d1bed1 100644
--- a/drivers/uwb/uwb-internal.h
+++ b/drivers/uwb/uwb-internal.h
@@ -172,7 +172,8 @@ struct uwb_rsv_alloc_info {
int interval;
};
-int uwb_rsv_find_best_allocation(struct uwb_rsv *rsv, struct uwb_mas_bm
*available,
+int uwb_rsv_find_best_allocation(struct uwb_rsv *rsv,
+struct uwb_mas_bm *available,
struct uwb_mas_bm *result);
void uwb_rsv_handle_drp_avail_change(struct uwb_rc *rc);
/*
--
1.8.3.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 v9 3/3] phy: Add Qualcomm DWC3 HS/SS PHY driver
On Tue, Sep 16, 2014 at 11:27:52AM -0700, Jack Pham wrote:
Hi Andy,
On Fri, Sep 12, 2014 at 02:28:08PM -0500, Andy Gross wrote:
+static int qcom_dwc3_hs_phy_init(struct qcom_dwc3_usb_phy *phy_dwc3)
+{
+ u32 val;
+
+ /*
+* HSPHY Initialization: Enable UTMI clock, select 19.2MHz fsel
+* enable clamping, and disable RETENTION (power-on default is ENABLED)
+*/
+ val = HSUSB_CTRL_DPSEHV_CLAMP | HSUSB_CTRL_DMSEHV_CLAMP |
+ HSUSB_CTRL_RETENABLEN | HSUSB_CTRL_COMMONONN |
+ HSUSB_CTRL_OTGSESSVLD_CLAMP | HSUSB_CTRL_ID_HV_CLAMP |
+ HSUSB_CTRL_DPSEHV_CLAMP | HSUSB_CTRL_UTMI_OTG_VBUS_VALID |
+ HSUSB_CTRL_UTMI_CLK_EN | HSUSB_CTRL_CLAMP_EN | 0x70;
+
+ /* use core clock if external reference is not present */
+ if (!phy_dwc3-xo_clk)
+ val |= HSUSB_CTRL_USE_CLKCORE;
+
+ writel(val, phy_dwc3-base + HSUSB_PHY_CTRL_REG);
+ usleep_range(2000, 2200);
+
+ /* Disable (bypass) VBUS and ID filters */
+ writel(HSUSB_GCFG_XHCI_REV, phy_dwc3-base + QSCRATCH_GENERAL_CFG);
Is this comment accurate? I believe this bit forces the IP to behave in
XHCI rev 1.0. In which case, shouldn't it be done in the glue driver?
I'll double check. I was taking the bit values and converting them to names.
If this is doing that, then I'll move it to the glue.
--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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 3/3] uwb: remove UWB build dependency on PCI
UWB does not require PCI to be enabled so remove build dependency. Signed-off-by: Thomas Pugliese thomas.pugli...@gmail.com --- drivers/uwb/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/uwb/Kconfig b/drivers/uwb/Kconfig index 2431eed..c204094 100644 --- a/drivers/uwb/Kconfig +++ b/drivers/uwb/Kconfig @@ -4,7 +4,6 @@ menuconfig UWB tristate Ultra Wideband devices - depends on PCI default n help UWB is a high-bandwidth, low-power, point-to-point radio -- 1.8.3.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/3] uwb: update uwb device prints to be more useful
Print info about the radio controller device instead of the its parent when UWB devices connect and disconnect. Signed-off-by: Thomas Pugliese thomas.pugli...@gmail.com --- drivers/uwb/lc-dev.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/uwb/lc-dev.c b/drivers/uwb/lc-dev.c index d0303f0..ba76810 100644 --- a/drivers/uwb/lc-dev.c +++ b/drivers/uwb/lc-dev.c @@ -365,8 +365,8 @@ int __uwb_dev_offair(struct uwb_dev *uwb_dev, struct uwb_rc *rc) uwb_dev_addr_print(devbuf, sizeof(devbuf), uwb_dev-dev_addr); dev_info(dev, uwb device (mac %s dev %s) disconnected from %s %s\n, macbuf, devbuf, -rc ? rc-uwb_dev.dev.parent-bus-name : n/a, -rc ? dev_name(rc-uwb_dev.dev.parent) : ); +uwb_dev-dev.bus-name, +rc ? dev_name((rc-uwb_dev.dev)) : ); uwb_dev_rm(uwb_dev); list_del(uwb_dev-bce-node); uwb_bce_put(uwb_dev-bce); @@ -445,8 +445,8 @@ void uwbd_dev_onair(struct uwb_rc *rc, struct uwb_beca_e *bce) } dev_info(dev, uwb device (mac %s dev %s) connected to %s %s\n, -macbuf, devbuf, rc-uwb_dev.dev.parent-bus-name, -dev_name(rc-uwb_dev.dev.parent)); +macbuf, devbuf, uwb_dev-dev.bus-name, +dev_name((rc-uwb_dev.dev))); uwb_notify(rc, uwb_dev, UWB_NOTIF_ONAIR); return; -- 1.8.3.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 0/3] uwb: minor cleanups
Some UWB cleanups for 3.18 Thomas Pugliese (3): uwb: line length cleanup uwb: update uwb device prints to be more useful uwb: remove UWB build dependency on PCI drivers/uwb/Kconfig| 1 - drivers/uwb/lc-dev.c | 8 drivers/uwb/uwb-internal.h | 3 ++- 3 files changed, 6 insertions(+), 6 deletions(-) -- 1.8.3.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 v3 0/2] usb: dwc2: driver updates for 3.18
Sigh. Not my week for submitting patches, I guess. Patch #2 was missing the freeing of the bounce buffers. I didn't notice the leak in my testing. This is a series of updates to the dwc2 driver, all related to the handling of non-dword-aligned transfers. I have tested all of these on the Raspberry Pi and Altera SOCFPGA platform, and have not seen any regressions. v3: Add missing free of the bounce buffers. v2: Remove pass gfp_t flags down to dwc2_hc_setup_align_buf() patch, since it had a fatal flaw. Reword the commit message for patch 2/2. Greg, can you apply this series to usb-next, please? Thanks. -- Paul Paul Zimmerman (2): usb: dwc2: clip max_transfer_size to 65535 usb: dwc2: handle DMA buffer unmapping sanely drivers/usb/dwc2/core.c | 7 +++ drivers/usb/dwc2/hcd.c | 42 +- drivers/usb/dwc2/hcd.h | 4 +++- drivers/usb/dwc2/hcd_intr.c | 22 -- drivers/usb/dwc2/hcd_queue.c | 16 5 files changed, 43 insertions(+), 48 deletions(-) -- 2.1.0.24.g4109c28 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] usb: dwc2: handle DMA buffer unmapping sanely
The driver's handling of DMA buffers for non-aligned transfers
was kind of nuts. For IN transfers, it left the URB DMA buffer
mapped until the transfer completed, then synced it, copied the
data from the bounce buffer, then synced it again.
Instead of that, just call usb_hcd_unmap_urb_for_dma() to unmap
the buffer before starting the transfer. Then no syncing is
required when doing the copy. This should also allow handling of
other types of mappings besides just dma_map_single() ones.
Also reduce the size of the bounce buffer allocation for Isoc
endpoints to 3K, since that's the largest possible transfer size.
Tested on Raspberry Pi and Altera SOCFPGA.
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
drivers/usb/dwc2/hcd.c | 42 +-
drivers/usb/dwc2/hcd.h | 4 +++-
drivers/usb/dwc2/hcd_intr.c | 22 --
drivers/usb/dwc2/hcd_queue.c | 16
4 files changed, 36 insertions(+), 48 deletions(-)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 4d918ed..0a0e6f0 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -697,29 +697,45 @@ static void *dwc2_hc_init_xfer(struct dwc2_hsotg *hsotg,
}
static int dwc2_hc_setup_align_buf(struct dwc2_hsotg *hsotg, struct dwc2_qh
*qh,
- struct dwc2_host_chan *chan, void *bufptr)
+ struct dwc2_host_chan *chan,
+ struct dwc2_hcd_urb *urb, void *bufptr)
{
u32 buf_size;
-
- if (chan-ep_type != USB_ENDPOINT_XFER_ISOC)
- buf_size = hsotg-core_params-max_transfer_size;
- else
- buf_size = 4096;
+ struct urb *usb_urb;
+ struct usb_hcd *hcd;
if (!qh-dw_align_buf) {
+ if (chan-ep_type != USB_ENDPOINT_XFER_ISOC)
+ buf_size = hsotg-core_params-max_transfer_size;
+ else
+ /* 3072 = 3 max-size Isoc packets */
+ buf_size = 3072;
+
qh-dw_align_buf = dma_alloc_coherent(hsotg-dev, buf_size,
qh-dw_align_buf_dma,
GFP_ATOMIC);
if (!qh-dw_align_buf)
return -ENOMEM;
+ qh-dw_align_buf_size = buf_size;
}
- if (!chan-ep_is_in chan-xfer_len) {
- dma_sync_single_for_cpu(hsotg-dev, chan-xfer_dma, buf_size,
- DMA_TO_DEVICE);
- memcpy(qh-dw_align_buf, bufptr, chan-xfer_len);
- dma_sync_single_for_device(hsotg-dev, chan-xfer_dma, buf_size,
- DMA_TO_DEVICE);
+ if (chan-xfer_len) {
+ dev_vdbg(hsotg-dev, %s(): non-aligned buffer\n, __func__);
+ usb_urb = urb-priv;
+
+ if (usb_urb) {
+ if (usb_urb-transfer_flags
+ (URB_SETUP_MAP_SINGLE | URB_DMA_MAP_SG |
+URB_DMA_MAP_PAGE | URB_DMA_MAP_SINGLE)) {
+ hcd = dwc2_hsotg_to_hcd(hsotg);
+ usb_hcd_unmap_urb_for_dma(hcd, usb_urb);
+ }
+ if (!chan-ep_is_in)
+ memcpy(qh-dw_align_buf, bufptr,
+ chan-xfer_len);
+ } else {
+ dev_warn(hsotg-dev, no URB in dwc2_urb\n);
+ }
}
chan-align_buf = qh-dw_align_buf_dma;
@@ -828,7 +844,7 @@ static int dwc2_assign_and_init_hc(struct dwc2_hsotg
*hsotg, struct dwc2_qh *qh)
/* Non DWORD-aligned buffer case */
if (bufptr) {
dev_vdbg(hsotg-dev, Non-aligned buffer\n);
- if (dwc2_hc_setup_align_buf(hsotg, qh, chan, bufptr)) {
+ if (dwc2_hc_setup_align_buf(hsotg, qh, chan, urb, bufptr)) {
dev_err(hsotg-dev,
%s: Failed to allocate memory to handle
non-dword aligned buffer\n,
__func__);
diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h
index fdc6d48..a12bb15 100644
--- a/drivers/usb/dwc2/hcd.h
+++ b/drivers/usb/dwc2/hcd.h
@@ -243,7 +243,8 @@ enum dwc2_transaction_type {
* @ntd:Actual number of transfer descriptors in a list
* @dw_align_buf: Used instead of original buffer if its physical address
* is not dword-aligned
- * @dw_align_buf_dma: DMA address for align_buf
+ * @dw_align_buf_size: Size of dw_align_buf
+ * @dw_align_buf_dma: DMA address for dw_align_buf
* @qtd_list: List of QTDs for this QH
* @channel:Host channel currently processing transfers for this QH
* @qh_list_entry: Entry for QH in either the periodic or non-periodic
@@ -276,6
[PATCH v3 1/2] usb: dwc2: clip max_transfer_size to 65535
Clip max_transfer_size to 65535 for host. dwc2_hc_setup_align_buf() allocates coherent buffers with this size, and if it's too large we can exhaust the coherent DMA pool. Tested on Raspberry Pi and Altera SOCFPGA. Signed-off-by: Paul Zimmerman pa...@synopsys.com --- drivers/usb/dwc2/core.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c index ea0048a..d926945 100644 --- a/drivers/usb/dwc2/core.c +++ b/drivers/usb/dwc2/core.c @@ -2743,6 +2743,13 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg) width = (hwcfg3 GHWCFG3_XFER_SIZE_CNTR_WIDTH_MASK) GHWCFG3_XFER_SIZE_CNTR_WIDTH_SHIFT; hw-max_transfer_size = (1 (width + 11)) - 1; + /* +* Clip max_transfer_size to 65535. dwc2_hc_setup_align_buf() allocates +* coherent buffers with this size, and if it's too large we can +* exhaust the coherent DMA pool. +*/ + if (hw-max_transfer_size 65535) + hw-max_transfer_size = 65535; width = (hwcfg3 GHWCFG3_PACKET_SIZE_CNTR_WIDTH_MASK) GHWCFG3_PACKET_SIZE_CNTR_WIDTH_SHIFT; hw-max_packet_count = (1 (width + 4)) - 1; -- 2.1.0.24.g4109c28 -- 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] uwb: create a uwb bus type and add in-range peer devices to it
Documentation/usb/WUSB-Design-overview.txt states that UWB devices seen
by a UWB radio controller are added to /sys/bus/uwb/devices, but this
was not actually being done. This functionality is needed in order for
UWB peer devices to be enumerated by user mode tools. This patch
creates a uwb bus type and adds UWB peer devices to it as they are
discovered by the radio controller.
Signed-off-by: Thomas Pugliese thomas.pugli...@gmail.com
---
drivers/uwb/driver.c | 11 +++
drivers/uwb/lc-dev.c | 11 +++
drivers/uwb/uwb-internal.h | 1 +
3 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/uwb/driver.c b/drivers/uwb/driver.c
index 3e5454a..776bcb3 100644
--- a/drivers/uwb/driver.c
+++ b/drivers/uwb/driver.c
@@ -121,9 +121,19 @@ static int __init uwb_subsys_init(void)
result = class_register(uwb_rc_class);
if (result 0)
goto error_uwb_rc_class_register;
+
+ /* Register the UWB bus */
+ result = bus_register(uwb_bus_type);
+ if (result) {
+ pr_err(%s - registering bus driver failed\n, __func__);
+ goto exit_bus;
+ }
+
uwb_dbg_init();
return 0;
+exit_bus:
+ class_unregister(uwb_rc_class);
error_uwb_rc_class_register:
uwb_est_destroy();
error_est_init:
@@ -134,6 +144,7 @@ module_init(uwb_subsys_init);
static void __exit uwb_subsys_exit(void)
{
uwb_dbg_exit();
+ bus_unregister(uwb_bus_type);
class_unregister(uwb_rc_class);
uwb_est_destroy();
return;
diff --git a/drivers/uwb/lc-dev.c b/drivers/uwb/lc-dev.c
index ba76810..8c7cfab 100644
--- a/drivers/uwb/lc-dev.c
+++ b/drivers/uwb/lc-dev.c
@@ -255,6 +255,12 @@ static struct attribute *uwb_dev_attrs[] = {
};
ATTRIBUTE_GROUPS(uwb_dev);
+/* UWB bus type. */
+struct bus_type uwb_bus_type = {
+ .name = uwb,
+ .dev_groups = uwb_dev_groups,
+};
+
/**
* Device SYSFS registration
*/
@@ -263,10 +269,6 @@ static int __uwb_dev_sys_add(struct uwb_dev *uwb_dev,
struct device *parent_dev)
struct device *dev;
dev = uwb_dev-dev;
- /* Device sysfs files are only useful for neighbor devices not
- local radio controllers. */
- if (uwb_dev-rc-uwb_dev != uwb_dev)
- dev-groups = uwb_dev_groups;
dev-parent = parent_dev;
dev_set_drvdata(dev, uwb_dev);
@@ -428,6 +430,7 @@ void uwbd_dev_onair(struct uwb_rc *rc, struct uwb_beca_e
*bce)
return;
}
uwb_dev_init(uwb_dev); /* This sets refcnt to one, we own it */
+ uwb_dev-dev.bus = uwb_bus_type;
uwb_dev-mac_addr = *bce-mac_addr;
uwb_dev-dev_addr = bce-dev_addr;
dev_set_name(uwb_dev-dev, %s, macbuf);
diff --git a/drivers/uwb/uwb-internal.h b/drivers/uwb/uwb-internal.h
index 6d1bed1..353c055 100644
--- a/drivers/uwb/uwb-internal.h
+++ b/drivers/uwb/uwb-internal.h
@@ -314,6 +314,7 @@ int uwb_radio_force_channel(struct uwb_rc *rc, int channel);
/* -- UWB Sysfs representation */
extern struct class uwb_rc_class;
+extern struct bus_type uwb_bus_type;
extern struct device_attribute dev_attr_mac_address;
extern struct device_attribute dev_attr_beacon;
extern struct device_attribute dev_attr_scan;
--
1.8.3.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] uwb: doc: bring uwb documentation up to date
The existing UWB documentation states that UWB devices show up in /sys/class/uwb and /sys/bus/uwb/devices. Up until the most recent changes to add uwb devices to their own bus, neither of these statements were actually true. Now, UWB devices do show up in /sys/bus/uwb/devices so the documentation has been updated to reflect that and removed references to /sys/class/uwb. The existing documentation also states that local UWB radio controller (RC) devices also show up as UWB devices along with their wireless peer UWB devices under /sys/class/uwb. This is not true so that statement has been removed. Signed-off-by: Thomas Pugliese thomas.pugli...@gmail.com --- Documentation/usb/WUSB-Design-overview.txt | 17 - 1 file changed, 4 insertions(+), 13 deletions(-) diff --git a/Documentation/usb/WUSB-Design-overview.txt b/Documentation/usb/WUSB-Design-overview.txt index 1cd07c0..512238c 100644 --- a/Documentation/usb/WUSB-Design-overview.txt +++ b/Documentation/usb/WUSB-Design-overview.txt @@ -161,19 +161,10 @@ now on), such as to start/stop beaconing, scan, allocate bandwidth, etc. The main building block here is the UWB device (struct uwb_dev). For each device that pops up in radio presence (ie: the UWB host receives a beacon from it) you get a struct uwb_dev that will show up in -/sys/class/uwb and in /sys/bus/uwb/devices. +/sys/bus/uwb/devices. -For each RC that is detected, a new struct uwb_rc is created. In turn, a -RC is also a device, so they also show in /sys/class/uwb and -/sys/bus/uwb/devices, but at the same time, only radio controllers show -up in /sys/class/uwb_rc. - -* - - [*] The reason for RCs being also devices is that not only we can - see them while enumerating the system device tree, but also on the - radio (their beacons and stuff), so the handling has to be - likewise to that of a device. +For each RC that is detected, a new struct uwb_rc and struct uwb_dev are +created. An entry is also created in /sys/class/uwb_rc for each RC. Each RC driver is implemented by a separate driver that plugs into the interface that the UWB stack provides through a struct uwb_rc_ops. The @@ -246,7 +237,7 @@ the beacon cache of dead devices]. Device lists -All UWB devices are kept in the list of the struct bus_type uwb_bus. +All UWB devices are kept in the list of the struct bus_type uwb_bus_type. Bandwidth allocation -- 1.8.3.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 0/2] uwb: add a bus for uwb devices
Create a system bus for UWB devices and add in-range UWB devices to it as they are detected. Prior to this change, UWB devices were added to the device tree, but since they did not exist on a bus, they would be enumerated by udev. Thomas Pugliese (2): uwb: create a uwb bus type and add in-range peer devices to it uwb: doc: bring uwb documentation up to date Documentation/usb/WUSB-Design-overview.txt | 17 - drivers/uwb/driver.c | 11 +++ drivers/uwb/lc-dev.c | 11 +++ drivers/uwb/uwb-internal.h | 1 + 4 files changed, 23 insertions(+), 17 deletions(-) -- 1.8.3.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 0/2] add an ASIE sysfs attribute to uwb_rc devices
Add an ASIE sysfs attribute to uwb_rc devices. This allows user mode to add and remove application specific information elements (ASIEs) to the beacon of a uwb_rc device. Thomas Pugliese (2): uwb: add an ASIE sysfs attribute to uwb_rc devices uwb: doc: add documentation for ASIE sysfs attribute Documentation/ABI/testing/sysfs-class-uwb_rc | 13 drivers/uwb/lc-rc.c | 99 2 files changed, 112 insertions(+) -- 1.8.3.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] uwb: doc: add documentation for ASIE sysfs attribute
Document the /sys/class/uwb_rc/uwbN/ASIE sysfs attribute Signed-off-by: Thomas Pugliese thomas.pugli...@gmail.com --- Documentation/ABI/testing/sysfs-class-uwb_rc | 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-class-uwb_rc b/Documentation/ABI/testing/sysfs-class-uwb_rc index 6a5fd07..85f4875 100644 --- a/Documentation/ABI/testing/sysfs-class-uwb_rc +++ b/Documentation/ABI/testing/sysfs-class-uwb_rc @@ -43,6 +43,19 @@ Description: Reading returns the currently active channel, or -1 if the radio controller is not beaconing. +What: /sys/class/uwb_rc/uwbN/ASIE +Date: August 2014 +KernelVersion: 3.18 +Contact:linux-usb@vger.kernel.org +Description: + +The application-specific information element (ASIE) +included in this device's beacon, in space separated +hex octets. + +Reading returns the current ASIE. Writing replaces +the current ASIE with the one written. + What: /sys/class/uwb_rc/uwbN/scan Date: July 2008 KernelVersion: 2.6.27 -- 1.8.3.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 1/2] uwb: add an ASIE sysfs attribute to uwb_rc devices
Allow user mode to add and remove application specific information
elements (ASIEs) to the beacon of a uwb_rc device.
Signed-off-by: Thomas Pugliese thomas.pugli...@gmail.com
---
drivers/uwb/lc-rc.c | 99 +
1 file changed, 99 insertions(+)
diff --git a/drivers/uwb/lc-rc.c b/drivers/uwb/lc-rc.c
index 3eca6ce..d059ad4 100644
--- a/drivers/uwb/lc-rc.c
+++ b/drivers/uwb/lc-rc.c
@@ -119,10 +119,109 @@ struct uwb_rc *uwb_rc_alloc(void)
}
EXPORT_SYMBOL_GPL(uwb_rc_alloc);
+/*
+ * Show the ASIE that is broadcast in the UWB beacon by this uwb_rc device.
+ */
+static ssize_t ASIE_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct uwb_dev *uwb_dev = to_uwb_dev(dev);
+ struct uwb_rc *rc = uwb_dev-rc;
+ struct uwb_ie_hdr *ie;
+ void *ptr;
+ size_t len;
+ int result = 0;
+
+ /* init empty buffer. */
+ result = scnprintf(buf, PAGE_SIZE, \n);
+ mutex_lock(rc-ies_mutex);
+ /* walk IEData looking for an ASIE. */
+ ptr = rc-ies-IEData;
+ len = le16_to_cpu(rc-ies-wIELength);
+ for (;;) {
+ ie = uwb_ie_next(ptr, len);
+ if (!ie)
+ break;
+ if (ie-element_id == UWB_APP_SPEC_IE) {
+ result = uwb_ie_dump_hex(ie,
+ ie-length + sizeof(struct uwb_ie_hdr),
+ buf, PAGE_SIZE);
+ break;
+ }
+ }
+ mutex_unlock(rc-ies_mutex);
+
+ return result;
+}
+
+/*
+ * Update the ASIE that is broadcast in the UWB beacon by this uwb_rc device.
+ */
+static ssize_t ASIE_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t size)
+{
+ struct uwb_dev *uwb_dev = to_uwb_dev(dev);
+ struct uwb_rc *rc = uwb_dev-rc;
+ char ie_buf[255];
+ int result, ie_len = 0;
+ const char *cur_ptr = buf;
+ struct uwb_ie_hdr *ie;
+
+ /* empty string means clear the ASIE. */
+ if (strlen(buf) = 1) {
+ uwb_rc_ie_rm(rc, UWB_APP_SPEC_IE);
+ return size;
+ }
+
+ /* if non-empty string, convert string of hex chars to binary. */
+ while (ie_len sizeof(ie_buf)) {
+ int char_count;
+
+ if (sscanf(cur_ptr, %02hhX %n,
+ (ie_buf[ie_len]), char_count) 0) {
+ ++ie_len;
+ /* skip chars read from cur_ptr. */
+ cur_ptr += char_count;
+ } else {
+ break;
+ }
+ }
+
+ /* validate IE length and type. */
+ if (ie_len sizeof(struct uwb_ie_hdr)) {
+ dev_err(dev, %s: Invalid ASIE size %d.\n, __func__, ie_len);
+ return -EINVAL;
+ }
+
+ ie = (struct uwb_ie_hdr *)ie_buf;
+ if (ie-element_id != UWB_APP_SPEC_IE) {
+ dev_err(dev, %s: Invalid IE element type size = 0x%02X.\n,
+ __func__, ie-element_id);
+ return -EINVAL;
+ }
+
+ /* bounds check length field from user. */
+ if (ie-length (ie_len - sizeof(struct uwb_ie_hdr)))
+ ie-length = ie_len - sizeof(struct uwb_ie_hdr);
+
+ /*
+* Valid ASIE received. Remove current ASIE then add the new one using
+* uwb_rc_ie_add.
+*/
+ uwb_rc_ie_rm(rc, UWB_APP_SPEC_IE);
+
+ result = uwb_rc_ie_add(rc, ie, ie-length + sizeof(struct uwb_ie_hdr));
+
+ return result = 0 ? size : result;
+}
+static DEVICE_ATTR_RW(ASIE);
+
static struct attribute *rc_attrs[] = {
dev_attr_mac_address.attr,
dev_attr_scan.attr,
dev_attr_beacon.attr,
+ dev_attr_ASIE.attr,
NULL,
};
--
1.8.3.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/3] usb: wusbcore: remove USB_WUSB build dependency on PCI
Wireless USB does not require PCI so remove USB_WUSB build dependency on PCI. Signed-off-by: Thomas Pugliese thomas.pugli...@gmail.com --- drivers/usb/wusbcore/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/wusbcore/Kconfig b/drivers/usb/wusbcore/Kconfig index 0e17b96..f5c92f6 100644 --- a/drivers/usb/wusbcore/Kconfig +++ b/drivers/usb/wusbcore/Kconfig @@ -3,7 +3,6 @@ # config USB_WUSB tristate Enable Wireless USB extensions - depends on PCI depends on UWB select CRYPTO select CRYPTO_BLKCIPHER -- 1.8.3.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 3/3] usb: wusbcore: USB_WUSB_CBAF depends on USB
Add USB build dependency for USB_WUSB_CBAF. Signed-off-by: Thomas Pugliese thomas.pugli...@gmail.com --- drivers/usb/wusbcore/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/wusbcore/Kconfig b/drivers/usb/wusbcore/Kconfig index f5c92f6..348de1d 100644 --- a/drivers/usb/wusbcore/Kconfig +++ b/drivers/usb/wusbcore/Kconfig @@ -17,6 +17,7 @@ config USB_WUSB config USB_WUSB_CBAF tristate Support WUSB Cable Based Association (CBA) + depends on USB help Some WUSB devices support Cable Based Association. It's used to enable the secure communication between the host and the -- 1.8.3.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 1/3] usb: hwa: add USB build dependency for USB_HWA_HCD
An HWA is a USB device so it depends on USB. Signed-off-by: Thomas Pugliese thomas.pugli...@gmail.com --- drivers/usb/host/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 82800a7..64805d9 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -709,7 +709,7 @@ config USB_WHCI_HCD config USB_HWA_HCD tristate Host Wire Adapter (HWA) driver - depends on UWB + depends on USB UWB select USB_WUSB select UWB_HWA help -- 1.8.3.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 0/3] wusb build dependency fixes
Fix build dependencies for WUSB devices. Thomas Pugliese (3): usb: hwa: add USB build dependency for USB_HWA_HCD usb: wusbcore: remove USB_WUSB build dependency on PCI usb: wusbcore: USB_WUSB_CBAF depends on USB drivers/usb/host/Kconfig | 2 +- drivers/usb/wusbcore/Kconfig | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 1.8.3.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] usb: wusbcore: skip done segs before completing aborted transfer
When completing an aborted transfer, skip done segs before calling
wa_complete_remaining_xfer_segs to avoid a runtime warning. The warning
is harmless in this case but avoiding it prevents false error reports.
Signed-off-by: Thomas Pugliese thomas.pugli...@gmail.com
---
drivers/usb/wusbcore/wa-xfer.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/wusbcore/wa-xfer.c b/drivers/usb/wusbcore/wa-xfer.c
index e279015..69af4fd 100644
--- a/drivers/usb/wusbcore/wa-xfer.c
+++ b/drivers/usb/wusbcore/wa-xfer.c
@@ -459,14 +459,25 @@ static void __wa_xfer_abort_cb(struct urb *urb)
__func__, urb-status);
if (xfer) {
unsigned long flags;
- int done;
+ int done, seg_index = 0;
struct wa_rpipe *rpipe = xfer-ep-hcpriv;
dev_err(dev, %s: cleaning up xfer %p ID 0x%08X.\n,
__func__, xfer, wa_xfer_id(xfer));
spin_lock_irqsave(xfer-lock, flags);
- /* mark all segs as aborted. */
- wa_complete_remaining_xfer_segs(xfer, 0,
+ /* skip done segs. */
+ while (seg_index xfer-segs) {
+ struct wa_seg *seg = xfer-seg[seg_index];
+
+ if ((seg-status == WA_SEG_DONE) ||
+ (seg-status == WA_SEG_ERROR)) {
+ ++seg_index;
+ } else {
+ break;
+ }
+ }
+ /* mark remaining segs as aborted. */
+ wa_complete_remaining_xfer_segs(xfer, seg_index,
WA_SEG_ABORTED);
done = __wa_xfer_is_done(xfer);
spin_unlock_irqrestore(xfer-lock, flags);
--
1.8.3.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
xhci_hcd resets device when qemu USB passthrough is attempted
Hello, I'm experiencing an issue on a MacBook Pro 11,1 (late 2013 model, 13) with kernel 3.16.2, libusb-1.0.19, using qemu-2.1.1 (I tried qemu git master as well) where my USB devices get reset a bunch of times when I attach them to a guest/vm, and eventually completely disconnect from both the guest/vm and the host machine when I try to access them from the guest/vm. Here is a bit of info to indicate what is happening: QEMU command: qemu-system-x86_64 -cpu host -smp cores=2,threads=2 -boot menu=on -m 6144 -soundhw ac97 -drive file=win7.raw,if=virtio -cdrom virtio-win-0.1-81.iso -display gtk,grab_on_hover=on -vga std -usb -device nec-usb-xhci,id=xhci -monitor stdio -enable-kvm Command I give to qemu console to attach the device to the guest: device_add usb-host,hostbus=1,hostaddr=15,bus=xhci.0 dmesg when i add the device via qemu console: [17289.738785] usb 1-1: new full-speed USB device number 15 using xhci_hcd [17296.466090] usb 1-1: reset full-speed USB device number 15 using xhci_hcd [17296.466118] xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 16. [17296.466121] usb 1-1: hub failed to enable device, error -22 [17296.619018] usb 1-1: reset full-speed USB device number 15 using xhci_hcd [17296.619041] xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 16. [17296.619044] usb 1-1: hub failed to enable device, error -22 [17296.772140] usb 1-1: reset full-speed USB device number 15 using xhci_hcd [17296.792402] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8803dd525d08 [17296.792406] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8803dd525cc0 [17297.185665] usb 1-1: reset full-speed USB device number 15 using xhci_hcd [17297.185693] xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 16. [17297.185696] usb 1-1: hub failed to enable device, error -22 [17297.338569] usb 1-1: reset full-speed USB device number 15 using xhci_hcd [17297.338591] xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 16. [17297.338594] usb 1-1: hub failed to enable device, error -22 [17297.491689] usb 1-1: reset full-speed USB device number 15 using xhci_hcd [17297.511965] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8803dd525d08 [17297.511968] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8803dd525cc0 [17297.902166] usb 1-1: reset full-speed USB device number 15 using xhci_hcd [17297.902192] xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 16. [17297.902195] usb 1-1: hub failed to enable device, error -22 [17298.055109] usb 1-1: reset full-speed USB device number 15 using xhci_hcd [17298.055134] xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 16. [17298.055137] usb 1-1: hub failed to enable device, error -22 [17298.208225] usb 1-1: reset full-speed USB device number 15 using xhci_hcd [17298.228750] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8803dd525d08 [17298.228754] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8803dd525cc0 dmesg when i try to communicate with the device - device disconnects from guest AND host: [17428.259434] usb 1-1: USB disconnect, device number 15 [17428.568947] usb 1-1: new full-speed USB device number 16 using xhci_hcd QEMU error message when i try to access the device: libusb_release_interface: -4 [NO_DEVICE] libusb: error [_open_sysfs_attr] open /sys/bus/usb/devices/1-1/bConfigurationValue failed ret=-1 errno=2 Just for good measure, I'll attach a (slightly redacted) plain-text version of my kernel config to this email. Please let me know if you need any other information from me. Here's to hoping you can help... Cheers, uriah # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.16.2 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf64-x86-64 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_HAVE_INTEL_TXT=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx
Re: [PATCH v3 0/9] Tegra xHCI support
On 09/16/2014 10:57 AM, Andrew Bresticker wrote: On Tue, Sep 16, 2014 at 8:26 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 01:30 PM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 11:09 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 11:06 AM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and USB3.0 memory sticks and ethernet dongles using controller firmware recently posted by Andrew Chew [2]. ... Stephen, Thierry, have either of you had a chance to test this series? I haven't had a chance to yet. I just went to try it out, and found that it depends on a whole slew of other patches that I don't have. Is there a git branch somewhere to save me having to track down all the dependencies? Yes, Tomeu has the branch he used for testing here: http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=3.17rc4-xhci Hmm. That git server was quite reluctant to cough up its bits, but it did eventually. You'll also need the firmware Andrew Chew posted: https://patchwork.ozlabs.org/patch/384013/ The XHCI driver can't load its firmware unless it's a module; if I make it built-in, it fails immediately with error -2 during Direct firmware loading. The driver needs to work with either immediate or deferred firmware loading. If you want the driver to be built-in, you'll either need to build the firmware in as well (i.e. EXTRA_FIRMWARE) or enable FW_LOADER_USER_HELPER_FALLBACK to load with userspace/uevent (though apparently this is deprecated). Hmm. I didn't have to do that for the Atmel touchpad driver to work, but perhaps it's just ignoring a firmware loading error, and continuing with whatever is in the device's flash already. It seems odd that such a fundamental feature would require a deprecated Kconfig option. Is there some replacement that does the same thing that isn't deprecated? The Kconfig help for the option doesn't say anything useful... Oh, this option doesn't actually seem to work. I see the following in dmesg: [root@swarren-dt ~]# dmesg|grep -i -e xhci -e firmware [1.461773] xhci-tegra 7009.usb: Failed to get supply 'avddio-pex': -517 [1.468930] platform 7009.usb: Driver xhci-tegra requests probe deferral [2.567966] xhci-tegra 7009.usb: Direct firmware load for nvidia/tegra124/xusb.bin failed with error -2 [2.577786] xhci-tegra 7009.usb: Falling back to user helper ... but: [root@swarren-dt ~]# lsusb unable to initialize libusb: -99 Perhaps systemd-udevd doesn't implement firmware loading; is it user-space udev that's deprecated implementing user-space firmware loading, rather than the kernel deprecating support for calling out to user space? This sucks, because now I can't just TFTP boot kernels but somehow have to get updated kernel modules onto my device every time before testing a new kernel build. That's a huge time-sink, unless I work out NFS root, which probably isn't properly or easily supported by any distro. -- 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 0/9] Tegra xHCI support
On Tue, Sep 16, 2014 at 9:57 AM, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 16, 2014 at 8:26 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 01:30 PM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 11:09 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 11:06 AM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and USB3.0 memory sticks and ethernet dongles using controller firmware recently posted by Andrew Chew [2]. ... Stephen, Thierry, have either of you had a chance to test this series? I haven't had a chance to yet. I just went to try it out, and found that it depends on a whole slew of other patches that I don't have. Is there a git branch somewhere to save me having to track down all the dependencies? Yes, Tomeu has the branch he used for testing here: http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=3.17rc4-xhci Hmm. That git server was quite reluctant to cough up its bits, but it did eventually. You'll also need the firmware Andrew Chew posted: https://patchwork.ozlabs.org/patch/384013/ The XHCI driver can't load its firmware unless it's a module; if I make it built-in, it fails immediately with error -2 during Direct firmware loading. The driver needs to work with either immediate or deferred firmware loading. If you want the driver to be built-in, you'll either need to build the firmware in as well (i.e. EXTRA_FIRMWARE) or enable FW_LOADER_USER_HELPER_FALLBACK to load with userspace/uevent (though apparently this is deprecated). The following USB2 devices had problems: 0b95:7720 ASIX Electronics Corp. AX88772 [ 489.140536] usb 1-3: new high-speed USB device number 81 using xhci-tegra [ 489.260860] usb 1-3: device descriptor read/64, error -71 [ 489.370804] xhci-tegra 7009.usb: Setup ERROR: setup context command for slot 1. [ 489.378463] usb 1-3: hub failed to enable device, error -22 [ 489.500531] usb 1-3: new high-speed USB device number 82 using xhci-tegra [ 489.655708] usb 1-3: can't set config #1, error -71 [ 489.661231] usb 1-3: USB disconnect, device number 82 [ 489.940531] usb 1-3: new high-speed USB device number 83 using xhci-tegra [ 490.060860] usb 1-3: device descriptor read/64, error -71 [ 490.170805] xhci-tegra 7009.usb: Setup ERROR: setup context command for slot 1. [ 490.178462] usb 1-3: hub failed to enable device, error -22 (repeats over and over) 15a4:1336 Afatech Technologies, Inc. SDHC/MicroSD/MMC/MS/M2/CF/XD Flash Card Reader The power light comes on, and the activity light just keeps flashing fast. Usually the activity light flashes a couple times and then turns off. There is nothing in dmesg at all for this device. 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Not detected. There is nothing in dmesg at all for this device. 1bcf:0c31 Sunplus Innovation Technology Inc. SPIF30x Serial-ATA bridge Not detected. There is nothing in dmesg at all for this device. Thanks, I'll try to figure out what's going on here. Grr... this is due to the unfortunate UTMI pad controller design on Tegra. Here's the issue: When UTMI pad 0 is assigned to the EHCI controller (as is currently the case on Jetson-TK1), the UTMI parameters from UTMIP_BIAS_CFG0 in the global UTMI pad register space are used regardless of the owner of the UTMI pads. If pad 0 is assigned to the XUSB controller, then parameters in USB2_BIAS_PAD_CTL0 in the XUSB register space are used for all UTMI pads (again, regardless of ownership). I wasn't able to reproduce before because I always TFTP booted and U-Boot programs the UTMI parameters correctly when starting the EHCI controllers. I suspect you and Tomeu were booting without starting the EHCI controllers and thus were stuck with the POR values. The easiest way to fix this is to just assign UTMI port 0 (i.e. the OTG port) to the XUSB controller. AFAIK, device mode on Tegra isn't supported yet in the kernel, so this shouldn't break any existing use cases. If we wanted to support device mode in the future, it would just have to be done with the XUSB controller instead. The alternative is some ugly driver that programs the correct register set depending on which controller UTMI port 0 is assigned to. BTW, here's a patch to assign UTMI port 0 to XUSB: diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts b/arch/arm/boot/dts/tegra124-jetson-tk1.dts index a473750..dacb0d0 100644 ---
Re: [PATCH v3 0/9] Tegra xHCI support
On Tue, Sep 16, 2014 at 3:40 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/16/2014 10:57 AM, Andrew Bresticker wrote: On Tue, Sep 16, 2014 at 8:26 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 01:30 PM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 11:09 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 11:06 AM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and USB3.0 memory sticks and ethernet dongles using controller firmware recently posted by Andrew Chew [2]. ... Stephen, Thierry, have either of you had a chance to test this series? I haven't had a chance to yet. I just went to try it out, and found that it depends on a whole slew of other patches that I don't have. Is there a git branch somewhere to save me having to track down all the dependencies? Yes, Tomeu has the branch he used for testing here: http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=3.17rc4-xhci Hmm. That git server was quite reluctant to cough up its bits, but it did eventually. You'll also need the firmware Andrew Chew posted: https://patchwork.ozlabs.org/patch/384013/ The XHCI driver can't load its firmware unless it's a module; if I make it built-in, it fails immediately with error -2 during Direct firmware loading. The driver needs to work with either immediate or deferred firmware loading. If you want the driver to be built-in, you'll either need to build the firmware in as well (i.e. EXTRA_FIRMWARE) or enable FW_LOADER_USER_HELPER_FALLBACK to load with userspace/uevent (though apparently this is deprecated). Hmm. I didn't have to do that for the Atmel touchpad driver to work, but perhaps it's just ignoring a firmware loading error, and continuing with whatever is in the device's flash already. It seems odd that such a fundamental feature would require a deprecated Kconfig option. Is there some replacement that does the same thing that isn't deprecated? The Kconfig help for the option doesn't say anything useful... Oh, this option doesn't actually seem to work. I see the following in dmesg: [root@swarren-dt ~]# dmesg|grep -i -e xhci -e firmware [1.461773] xhci-tegra 7009.usb: Failed to get supply 'avddio-pex': -517 [1.468930] platform 7009.usb: Driver xhci-tegra requests probe deferral [2.567966] xhci-tegra 7009.usb: Direct firmware load for nvidia/tegra124/xusb.bin failed with error -2 [2.577786] xhci-tegra 7009.usb: Falling back to user helper ... but: [root@swarren-dt ~]# lsusb unable to initialize libusb: -99 Perhaps systemd-udevd doesn't implement firmware loading; is it user-space udev that's deprecated implementing user-space firmware loading, rather than the kernel deprecating support for calling out to user space? I believe it is userspace udev that has deprecated user firmware loading. The kernel still does call out to userspace. Alternatively, you could use the firmware_class loading interface described in Documentation/firmware_class/README, but that kind of sucks too. This sucks, because now I can't just TFTP boot kernels but somehow have to get updated kernel modules onto my device every time before testing a new kernel build. Yeah... it does. I get around this by building the firmware into the kernel image (i.e. CONFIG_EXTRA_FIRMWARE), which is also your only option if the root device happens to be on USB. Unfortunately, I'm not aware of any other alternatives. -- 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 0/9] Tegra xHCI support
On 09/16/2014 04:46 PM, Andrew Bresticker wrote: On Tue, Sep 16, 2014 at 9:57 AM, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 16, 2014 at 8:26 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 01:30 PM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 11:09 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 11:06 AM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and USB3.0 memory sticks and ethernet dongles using controller firmware recently posted by Andrew Chew [2]. ... Stephen, Thierry, have either of you had a chance to test this series? I haven't had a chance to yet. I just went to try it out, and found that it depends on a whole slew of other patches that I don't have. Is there a git branch somewhere to save me having to track down all the dependencies? Yes, Tomeu has the branch he used for testing here: http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=3.17rc4-xhci Hmm. That git server was quite reluctant to cough up its bits, but it did eventually. You'll also need the firmware Andrew Chew posted: https://patchwork.ozlabs.org/patch/384013/ The XHCI driver can't load its firmware unless it's a module; if I make it built-in, it fails immediately with error -2 during Direct firmware loading. The driver needs to work with either immediate or deferred firmware loading. If you want the driver to be built-in, you'll either need to build the firmware in as well (i.e. EXTRA_FIRMWARE) or enable FW_LOADER_USER_HELPER_FALLBACK to load with userspace/uevent (though apparently this is deprecated). The following USB2 devices had problems: 0b95:7720 ASIX Electronics Corp. AX88772 [ 489.140536] usb 1-3: new high-speed USB device number 81 using xhci-tegra [ 489.260860] usb 1-3: device descriptor read/64, error -71 [ 489.370804] xhci-tegra 7009.usb: Setup ERROR: setup context command for slot 1. [ 489.378463] usb 1-3: hub failed to enable device, error -22 [ 489.500531] usb 1-3: new high-speed USB device number 82 using xhci-tegra [ 489.655708] usb 1-3: can't set config #1, error -71 [ 489.661231] usb 1-3: USB disconnect, device number 82 [ 489.940531] usb 1-3: new high-speed USB device number 83 using xhci-tegra [ 490.060860] usb 1-3: device descriptor read/64, error -71 [ 490.170805] xhci-tegra 7009.usb: Setup ERROR: setup context command for slot 1. [ 490.178462] usb 1-3: hub failed to enable device, error -22 (repeats over and over) 15a4:1336 Afatech Technologies, Inc. SDHC/MicroSD/MMC/MS/M2/CF/XD Flash Card Reader The power light comes on, and the activity light just keeps flashing fast. Usually the activity light flashes a couple times and then turns off. There is nothing in dmesg at all for this device. 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Not detected. There is nothing in dmesg at all for this device. 1bcf:0c31 Sunplus Innovation Technology Inc. SPIF30x Serial-ATA bridge Not detected. There is nothing in dmesg at all for this device. Thanks, I'll try to figure out what's going on here. Grr... this is due to the unfortunate UTMI pad controller design on Tegra. Here's the issue: When UTMI pad 0 is assigned to the EHCI controller (as is currently the case on Jetson-TK1), the UTMI parameters from UTMIP_BIAS_CFG0 in the global UTMI pad register space are used regardless of the owner of the UTMI pads. If pad 0 is assigned to the XUSB controller, then parameters in USB2_BIAS_PAD_CTL0 in the XUSB register space are used for all UTMI pads (again, regardless of ownership). I wasn't able to reproduce before because I always TFTP booted and U-Boot programs the UTMI parameters correctly when starting the EHCI controllers. I suspect you and Tomeu were booting without starting the EHCI controllers and thus were stuck with the POR values. I am loading the kernel over the PCIe Ethernet on Jetson TK1. However, the U-Boot boot scripts do usb start first, so I would assume all the USB set is already done either way, before U-Boot attempts to probe USB devices. The easiest way to fix this is to just assign UTMI port 0 (i.e. the OTG port) to the XUSB controller. AFAIK, device mode on Tegra isn't supported yet in the kernel, so this shouldn't break any existing use cases. If we wanted to support device mode in the future, it would just have to be done with the XUSB controller instead. The alternative is some ugly driver that programs the correct register set depending on which controller UTMI port 0
Re: [PATCH v4 1/3] mfd: add support for Diolan DLN-2 devices
On Tue, 09 Sep 2014, Octavian Purdila wrote:
This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
Master Adapter DLN-2. Details about the device can be found here:
https://www.diolan.com/i2c/i2c_interface.html.
Information about the USB protocol can be found in the Programmer's
Reference Manual [1], see section 1.7.
This driver really needs a USB Ack before I can accept it.
Because the hardware has a single transmit endpoint and a single
receive endpoint the communication between the various DLN2 drivers
and the hardware will be muxed/demuxed by this driver.
Each DLN2 module will be identified by the handle field within the DLN2
message header. If a DLN2 module issues multiple commands in parallel
they will be identified by the echo counter field in the message header.
The DLN2 modules can use the dln2_transfer() function to issue a
command and wait for its response. They can also register a callback
that is going to be called when a specific event id is generated by
the device (e.g. GPIO interrupts). The device uses handle 0 for
sending events.
[1] https://www.diolan.com/downloads/dln-api-manual.pdf
Signed-off-by: Octavian Purdila octavian.purd...@intel.com
---
drivers/mfd/Kconfig | 9 +
drivers/mfd/Makefile | 1 +
drivers/mfd/dln2.c | 681
+++
include/linux/mfd/dln2.h | 71 +
4 files changed, 762 insertions(+)
create mode 100644 drivers/mfd/dln2.c
create mode 100644 include/linux/mfd/dln2.h
[...]
diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
new file mode 100644
index 000..b551b5e
--- /dev/null
+++ b/drivers/mfd/dln2.c
@@ -0,0 +1,681 @@
+/*
+ * Driver for the Diolan DLN-2 USB adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * Derived from:
+ * i2c-diolan-u2c.c
+ * Copyright (c) 2010-2011 Ericsson AB
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include linux/kernel.h
+#include linux/errno.h
What are you using this for?
+#include linux/module.h
+#include linux/types.h
+#include linux/slab.h
+#include linux/usb.h
+#include linux/i2c.h
+#include linux/mutex.h
+#include linux/platform_device.h
+#include linux/mfd/core.h
+#include linux/mfd/dln2.h
+
+#define DRIVER_NAME usb-dln2
Don't do this, just use usb-dln2 where it needs to be used.
[...]
+static struct usb_driver dln2_driver = {
+ .name = DRIVER_NAME,
+ .probe = dln2_probe,
+ .disconnect = dln2_disconnect,
+ .id_table = dln2_table,
+};
+
+module_usb_driver(dln2_driver);
+
+MODULE_AUTHOR(Octavian Purdila octavian.purd...@intel.com);
+MODULE_DESCRIPTION(DRIVER_NAME driver);
This is not a description.
+MODULE_LICENSE(GPL);
Header says v2.
diff --git a/include/linux/mfd/dln2.h b/include/linux/mfd/dln2.h
new file mode 100644
index 000..197565d
--- /dev/null
+++ b/include/linux/mfd/dln2.h
@@ -0,0 +1,71 @@
+#ifndef __LINUX_USB_DLN2_H
+#define __LINUX_USB_DLN2_H
+
+#define DLN2_CMD(cmd, id)((cmd) | ((id) 8))
+
+struct dln2_platform_data {
+ u16 handle;
+ union {
+ struct {
+ u8 port;
+ } i2c;
+ };
+};
Why this complexity?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 0/9] Tegra xHCI support
On Tue, Sep 16, 2014 at 4:15 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/16/2014 04:46 PM, Andrew Bresticker wrote: On Tue, Sep 16, 2014 at 9:57 AM, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 16, 2014 at 8:26 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 01:30 PM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 11:09 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/15/2014 11:06 AM, Andrew Bresticker wrote: On Mon, Sep 15, 2014 at 12:00 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 12 September 2014 18:37, Andrew Bresticker abres...@chromium.org wrote: On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 8 September 2014 18:22, Andrew Bresticker abres...@chromium.org wrote: On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On 2 September 2014 23:34, Andrew Bresticker abres...@chromium.org wrote: Tested on Venice2, Jetson TK1, and Big with a variety of USB2.0 and USB3.0 memory sticks and ethernet dongles using controller firmware recently posted by Andrew Chew [2]. ... Stephen, Thierry, have either of you had a chance to test this series? I haven't had a chance to yet. I just went to try it out, and found that it depends on a whole slew of other patches that I don't have. Is there a git branch somewhere to save me having to track down all the dependencies? Yes, Tomeu has the branch he used for testing here: http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=3.17rc4-xhci Hmm. That git server was quite reluctant to cough up its bits, but it did eventually. You'll also need the firmware Andrew Chew posted: https://patchwork.ozlabs.org/patch/384013/ The XHCI driver can't load its firmware unless it's a module; if I make it built-in, it fails immediately with error -2 during Direct firmware loading. The driver needs to work with either immediate or deferred firmware loading. If you want the driver to be built-in, you'll either need to build the firmware in as well (i.e. EXTRA_FIRMWARE) or enable FW_LOADER_USER_HELPER_FALLBACK to load with userspace/uevent (though apparently this is deprecated). The following USB2 devices had problems: 0b95:7720 ASIX Electronics Corp. AX88772 [ 489.140536] usb 1-3: new high-speed USB device number 81 using xhci-tegra [ 489.260860] usb 1-3: device descriptor read/64, error -71 [ 489.370804] xhci-tegra 7009.usb: Setup ERROR: setup context command for slot 1. [ 489.378463] usb 1-3: hub failed to enable device, error -22 [ 489.500531] usb 1-3: new high-speed USB device number 82 using xhci-tegra [ 489.655708] usb 1-3: can't set config #1, error -71 [ 489.661231] usb 1-3: USB disconnect, device number 82 [ 489.940531] usb 1-3: new high-speed USB device number 83 using xhci-tegra [ 490.060860] usb 1-3: device descriptor read/64, error -71 [ 490.170805] xhci-tegra 7009.usb: Setup ERROR: setup context command for slot 1. [ 490.178462] usb 1-3: hub failed to enable device, error -22 (repeats over and over) 15a4:1336 Afatech Technologies, Inc. SDHC/MicroSD/MMC/MS/M2/CF/XD Flash Card Reader The power light comes on, and the activity light just keeps flashing fast. Usually the activity light flashes a couple times and then turns off. There is nothing in dmesg at all for this device. 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Not detected. There is nothing in dmesg at all for this device. 1bcf:0c31 Sunplus Innovation Technology Inc. SPIF30x Serial-ATA bridge Not detected. There is nothing in dmesg at all for this device. Thanks, I'll try to figure out what's going on here. Grr... this is due to the unfortunate UTMI pad controller design on Tegra. Here's the issue: When UTMI pad 0 is assigned to the EHCI controller (as is currently the case on Jetson-TK1), the UTMI parameters from UTMIP_BIAS_CFG0 in the global UTMI pad register space are used regardless of the owner of the UTMI pads. If pad 0 is assigned to the XUSB controller, then parameters in USB2_BIAS_PAD_CTL0 in the XUSB register space are used for all UTMI pads (again, regardless of ownership). I wasn't able to reproduce before because I always TFTP booted and U-Boot programs the UTMI parameters correctly when starting the EHCI controllers. I suspect you and Tomeu were booting without starting the EHCI controllers and thus were stuck with the POR values. I am loading the kernel over the PCIe Ethernet on Jetson TK1. However, the U-Boot boot scripts do usb start first, so I would assume all the USB set is already done either way, before U-Boot attempts to probe USB devices. Interesting - just doing usb start made the difference for me. The easiest way to fix this is to just assign UTMI port 0 (i.e. the OTG port) to the XUSB controller. AFAIK, device mode on Tegra isn't supported yet in the kernel, so this shouldn't break any existing use
RE: [PATCH v5 07/12] usb: chipidea: add a usb2 driver for ci13xxx
Tested on the Marvell Berlin SoCs USB controllers. Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com --- drivers/usb/chipidea/Makefile | 1 + drivers/usb/chipidea/ci_hdrc_usb2.c | 137 2 files changed, 138 insertions(+) create mode 100644 drivers/usb/chipidea/ci_hdrc_usb2.c compile error: /home/peter/work/projects/usb/drivers/usb/chipidea/ci_hdrc_usb2.c: In function 'ci_hdrc_usb2_dt_probe': /home/peter/work/projects/usb/drivers/usb/chipidea/ci_hdrc_usb2.c:30 :2: error: implicit declaration of function 'of_phy_get' [-Werror=implicit-function-declaration] /home/peter/work/projects/usb/drivers/usb/chipidea/ci_hdrc_usb2.c:30 :16: warning: assignment makes pointer from integer without a cast [enabled by default] Did you apply the series introducing the support for the generic PHY framework in the USB subsystem first? One of the patches includes 'linux/phy/phy.h' in 'linux/usb/otg.h'. That's why I did not encounter this error. Anyway, you're right and 'linux/phy/phy.h' should be explicitly included here. Let me know if you want me to quickly cook up a new version fixing this. You can send this fix if you don't want to get comments for other parts in this series. I also see other dependencies like generic phy support for chipidea with this one. I think the 7th and 8th in this series are ok after adding 'linux/phy/phy.h', but you generic phy support series should be queued before this one. Peter -- 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 04/17] usb: gadget: net2280: use udc-core's reset notifier
From: Alan Stern st...@rowland.harvard.edu
This patch adds support for the new udc-core reset notifier to the
net2280 driver.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/gadget/udc/net2280.c | 45 +-
1 file changed, 35 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
index f4eac11..e25a782 100644
--- a/drivers/usb/gadget/udc/net2280.c
+++ b/drivers/usb/gadget/udc/net2280.c
@@ -3318,17 +3318,42 @@ static void handle_stat1_irqs(struct net2280 *dev, u32
stat)
* only indicates a change in the reset state).
*/
if (stat tmp) {
+ boolreset = false;
+ booldisconnect = false;
+
+ /*
+* Ignore disconnects and resets if the speed hasn't been set.
+* VBUS can bounce and there's always an initial reset.
+*/
writel(tmp, dev-regs-irqstat1);
- if stat BIT(ROOT_PORT_RESET_INTERRUPT))
- (readl(dev-usb-usbstat) mask)) ||
- ((readl(dev-usb-usbctl)
- BIT(VBUS_PIN)) == 0))
- (dev-gadget.speed != USB_SPEED_UNKNOWN)) {
- ep_dbg(dev, disconnect %s\n,
- dev-driver-driver.name);
- stop_activity(dev, dev-driver);
- ep0_start(dev);
- return;
+ if (dev-gadget.speed != USB_SPEED_UNKNOWN) {
+ if ((stat BIT(VBUS_INTERRUPT))
+ (readl(dev-usb-usbctl)
+ BIT(VBUS_PIN)) == 0) {
+ disconnect = true;
+ ep_dbg(dev, disconnect %s\n,
+ dev-driver-driver.name);
+ } else if ((stat BIT(ROOT_PORT_RESET_INTERRUPT))
+ (readl(dev-usb-usbstat) mask)
+ == 0) {
+ reset = true;
+ ep_dbg(dev, reset %s\n,
+ dev-driver-driver.name);
+ }
+
+ if (disconnect || reset) {
+ stop_activity(dev, dev-driver);
+ ep0_start(dev);
+ spin_unlock(dev-lock);
+ if (reset)
+ usb_gadget_udc_reset
+ (dev-gadget, dev-driver);
+ else
+ (dev-driver-disconnect)
+ (dev-gadget);
+ spin_lock(dev-lock);
+ return;
+ }
}
stat = ~tmp;
--
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 08/17] usb: gadget: m66592-udc: use udc-core's reset notifier
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/gadget/udc/m66592-udc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/m66592-udc.c
b/drivers/usb/gadget/udc/m66592-udc.c
index de88d33..625701f 100644
--- a/drivers/usb/gadget/udc/m66592-udc.c
+++ b/drivers/usb/gadget/udc/m66592-udc.c
@@ -1142,7 +1142,7 @@ static void irq_device_state(struct m66592 *m66592)
m66592_write(m66592, ~M66592_DVST, M66592_INTSTS0);
if (dvsq == M66592_DS_DFLT) { /* bus reset */
- m66592-driver-disconnect(m66592-gadget);
+ usb_gadget_udc_reset(m66592-gadget, m66592-driver);
m66592_update_usb_speed(m66592);
}
if (m66592-old_dvsq == M66592_DS_CNFG dvsq != M66592_DS_CNFG)
--
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 12/17] usb: gadget: fsl_qe_udc: use udc-core's reset notifier
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at bus reset handler. Signed-off-by: Peter Chen peter.c...@freescale.com --- drivers/usb/gadget/udc/fsl_qe_udc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c b/drivers/usb/gadget/udc/fsl_qe_udc.c index 7324308..0f0892a 100644 --- a/drivers/usb/gadget/udc/fsl_qe_udc.c +++ b/drivers/usb/gadget/udc/fsl_qe_udc.c @@ -1921,7 +1921,7 @@ static int reset_queues(struct qe_udc *udc) /* report disconnect; the driver is already quiesced */ spin_unlock(udc-lock); - udc-driver-disconnect(udc-gadget); + usb_gadget_udc_reset(udc-gadget, udc-driver); spin_lock(udc-lock); return 0; -- 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 02/17] usb: musb: gadget: use udc-core's reset notifier
From: Felipe Balbi ba...@ti.com
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/musb/musb_gadget.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index d4aa779..542ad53 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -2090,9 +2090,12 @@ __acquires(musb-lock)
: NULL
);
- /* report disconnect, if we didn't already (flushing EP state) */
- if (musb-g.speed != USB_SPEED_UNKNOWN)
- musb_g_disconnect(musb);
+ /* report reset, if we didn't already (flushing EP state) */
+ if (musb-gadget_driver musb-g.speed != USB_SPEED_UNKNOWN) {
+ spin_unlock(musb-lock);
+ usb_gadget_udc_reset(musb-g, musb-gadget_driver);
+ spin_lock(musb-lock);
+ }
/* clear HR */
else if (devctl MUSB_DEVCTL_HR)
--
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 07/17] usb: gadget: pxa25x_udc: use udc-core's reset notifier
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/gadget/udc/pxa25x_udc.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/pxa25x_udc.c
b/drivers/usb/gadget/udc/pxa25x_udc.c
index 251e4d5..4c62781 100644
--- a/drivers/usb/gadget/udc/pxa25x_udc.c
+++ b/drivers/usb/gadget/udc/pxa25x_udc.c
@@ -1285,6 +1285,33 @@ bind_fail:
}
static void
+reset_gadget(struct pxa25x_udc *dev, struct usb_gadget_driver *driver)
+{
+ int i;
+
+ /* don't disconnect drivers more than once */
+ if (dev-gadget.speed == USB_SPEED_UNKNOWN)
+ driver = NULL;
+ dev-gadget.speed = USB_SPEED_UNKNOWN;
+
+ /* prevent new request submissions, kill any outstanding requests */
+ for (i = 0; i PXA_UDC_NUM_ENDPOINTS; i++) {
+ struct pxa25x_ep *ep = dev-ep[i];
+
+ ep-stopped = 1;
+ nuke(ep, -ESHUTDOWN);
+ }
+ del_timer_sync(dev-timer);
+
+ /* report disconnect; the driver is already quiesced */
+ if (driver)
+ usb_gadget_udc_reset(dev-gadget, driver);
+
+ /* re-init driver-visible data structures */
+ udc_reinit(dev);
+}
+
+static void
stop_activity(struct pxa25x_udc *dev, struct usb_gadget_driver *driver)
{
int i;
@@ -1723,7 +1750,7 @@ pxa25x_udc_irq(int irq, void *_dev)
/* reset driver and endpoints,
* in case that's not yet done
*/
- stop_activity (dev, dev-driver);
+ reset_gadget(dev, dev-driver);
} else {
DBG(DBG_VERBOSE, USB reset end\n);
--
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 03/17] usb: gadget: dummy-hcd: use udc-core's reset notifier
From: Alan Stern st...@rowland.harvard.edu
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Peter chen peter.c...@freescale.com
---
drivers/usb/gadget/udc/dummy_hcd.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/gadget/udc/dummy_hcd.c
b/drivers/usb/gadget/udc/dummy_hcd.c
index 2b54955..91f6881 100644
--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -367,19 +367,22 @@ static void set_link_state(struct dummy_hcd *dum_hcd)
dum_hcd-active)
dum_hcd-resuming = 0;
- /* if !connected or reset */
+ /* Currently !connected or in reset */
if ((dum_hcd-port_status USB_PORT_STAT_CONNECTION) == 0 ||
(dum_hcd-port_status USB_PORT_STAT_RESET) != 0) {
- /*
-* We're connected and not reset (reset occurred now),
-* and driver attached - disconnect!
-*/
- if ((dum_hcd-old_status USB_PORT_STAT_CONNECTION) != 0
- (dum_hcd-old_status USB_PORT_STAT_RESET) == 0
- dum-driver) {
+ unsigned disconnect = USB_PORT_STAT_CONNECTION
+ dum_hcd-old_status (~dum_hcd-port_status);
+ unsigned reset = USB_PORT_STAT_RESET
+ (~dum_hcd-old_status) dum_hcd-port_status;
+
+ /* Report reset and disconnect events to the driver */
+ if (dum-driver (disconnect || reset)) {
stop_activity(dum);
spin_unlock(dum-lock);
- dum-driver-disconnect(dum-gadget);
+ if (reset)
+ usb_gadget_udc_reset(dum-gadget, dum-driver);
+ else
+ dum-driver-disconnect(dum-gadget);
spin_lock(dum-lock);
}
} else if (dum_hcd-active != dum_hcd-old_active) {
--
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 01/17] usb: dwc3: gadget: use udc-core's reset notifier
From: Felipe Balbi ba...@ti.com
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/dwc3/gadget.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index f2dbaca..90544a2 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2032,6 +2032,17 @@ static void dwc3_resume_gadget(struct dwc3 *dwc)
if (dwc-gadget_driver dwc-gadget_driver-resume) {
spin_unlock(dwc-lock);
dwc-gadget_driver-resume(dwc-gadget);
+ }
+}
+
+static void dwc3_reset_gadget(struct dwc3 *dwc)
+{
+ if (!dwc-gadget_driver)
+ return;
+
+ if (dwc-gadget.speed != USB_SPEED_UNKNOWN) {
+ spin_unlock(dwc-lock);
+ usb_gadget_udc_reset(dwc-gadget, dwc-gadget_driver);
spin_lock(dwc-lock);
}
}
@@ -2175,11 +2186,7 @@ static void dwc3_gadget_reset_interrupt(struct dwc3 *dwc)
dwc3_gadget_disconnect_interrupt(dwc);
}
- /* after reset - Default State */
- usb_gadget_set_state(dwc-gadget, USB_STATE_DEFAULT);
-
- if (dwc-gadget.speed != USB_SPEED_UNKNOWN)
- dwc3_disconnect_gadget(dwc);
+ dwc3_reset_gadget(dwc);
reg = dwc3_readl(dwc-regs, DWC3_DCTL);
reg = ~DWC3_DCTL_TSTCTRL_MASK;
--
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 06/17] usb: chipidea: gadget: use udc-core's reset notifier
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/udc.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index b8125aa..5ca3711 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -692,10 +692,8 @@ __acquires(ci-lock)
int retval;
spin_unlock(ci-lock);
- if (ci-gadget.speed != USB_SPEED_UNKNOWN) {
- if (ci-driver)
- ci-driver-disconnect(ci-gadget);
- }
+ if (ci-gadget.speed != USB_SPEED_UNKNOWN)
+ usb_gadget_udc_reset(ci-gadget, ci-driver);
retval = _gadget_stop_activity(ci-gadget);
if (retval)
@@ -709,8 +707,6 @@ __acquires(ci-lock)
if (ci-status == NULL)
retval = -ENOMEM;
- usb_gadget_set_state(ci-gadget, USB_STATE_DEFAULT);
-
done:
spin_lock(ci-lock);
--
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 10/17] usb: gadget: at91_udc: use udc-core's reset notifier
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/gadget/udc/at91_udc.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/at91_udc.c
b/drivers/usb/gadget/udc/at91_udc.c
index cfd18bc..ab4c7de 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -840,6 +840,31 @@ static void udc_reinit(struct at91_udc *udc)
}
}
+static void reset_gadget(struct at91_udc *udc)
+{
+ struct usb_gadget_driver *driver = udc-driver;
+ int i;
+
+ if (udc-gadget.speed == USB_SPEED_UNKNOWN)
+ driver = NULL;
+ udc-gadget.speed = USB_SPEED_UNKNOWN;
+ udc-suspended = 0;
+
+ for (i = 0; i NUM_ENDPOINTS; i++) {
+ struct at91_ep *ep = udc-ep[i];
+
+ ep-stopped = 1;
+ nuke(ep, -ESHUTDOWN);
+ }
+ if (driver) {
+ spin_unlock(udc-lock);
+ usb_gadget_udc_reset(udc-gadget, driver);
+ spin_lock(udc-lock);
+ }
+
+ udc_reinit(udc);
+}
+
static void stop_activity(struct at91_udc *udc)
{
struct usb_gadget_driver *driver = udc-driver;
@@ -1426,7 +1451,7 @@ static irqreturn_t at91_udc_irq (int irq, void *_udc)
at91_udp_write(udc, AT91_UDP_ICR, AT91_UDP_ENDBUSRES);
VDBG(end bus reset\n);
udc-addr = 0;
- stop_activity(udc);
+ reset_gadget(udc);
/* enable ep0 */
at91_udp_write(udc, AT91_UDP_CSR(0),
--
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 00/17] usb: gadget: convert udc driver to use udc-core's reset notifier
Hi Felipe, In this series, I convert udc driver to use udc-core's reset notifier which has added recently, I only change the drivers which has bus reset handler and call usb_gadget_driver's -disconnect in it. For five you and Alan's patches, I cherry-pick them from your gadget-add-reset-method branch and change some code and comments for using udc-core's reset notifier. This series is based on yours next tree, and pass the compile test and checkpatch.pl. Alan Stern (3): usb: gadget: dummy-hcd: use udc-core's reset notifier usb: gadget: net2280: use udc-core's reset notifier usb: gadget: net2272: use udc-core's reset notifier Felipe Balbi (2): usb: dwc3: gadget: use udc-core's reset notifier usb: musb: gadget: use udc-core's reset notifier Peter Chen (12): usb: chipidea: gadget: use udc-core's reset notifier usb: gadget: pxa25x_udc: use udc-core's reset notifier usb: gadget: m66592-udc: use udc-core's reset notifier usb: gadget: fsl_udc_core: use udc-core's reset notifier usb: gadget: at91_udc: use udc-core's reset notifier usb: gadget: mv_udc_core: use udc-core's reset notifier usb: gadget: fsl_qe_udc: use udc-core's reset notifier usb: gadget: pch_udc: use udc-core's reset notifier usb: gadget: amd5536udc: use udc-core's reset notifier usb: gadget: r8a66597-udc: use udc-core's reset notifier usb: gadget: bcm63xx_udc: use udc-core's reset notifier usb: gadget: atmel_usba_udc: use udc-core's reset notifier drivers/usb/chipidea/udc.c |8 ++ drivers/usb/dwc3/gadget.c | 17 drivers/usb/gadget/udc/amd5536udc.c |2 +- drivers/usb/gadget/udc/at91_udc.c | 27 ++- drivers/usb/gadget/udc/atmel_usba_udc.c |5 ++-- drivers/usb/gadget/udc/bcm63xx_udc.c|6 +++-- drivers/usb/gadget/udc/dummy_hcd.c | 21 --- drivers/usb/gadget/udc/fsl_qe_udc.c |2 +- drivers/usb/gadget/udc/fsl_udc_core.c | 11 +--- drivers/usb/gadget/udc/m66592-udc.c |2 +- drivers/usb/gadget/udc/mv_udc_core.c| 19 - drivers/usb/gadget/udc/net2272.c| 45 --- drivers/usb/gadget/udc/net2280.c| 45 --- drivers/usb/gadget/udc/pch_udc.c|4 +-- drivers/usb/gadget/udc/pxa25x_udc.c | 29 +++- drivers/usb/gadget/udc/r8a66597-udc.c |2 +- drivers/usb/musb/musb_gadget.c |9 --- 17 files changed, 193 insertions(+), 61 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
[PATCH 05/17] usb: gadget: net2272: use udc-core's reset notifier
From: Alan Stern st...@rowland.harvard.edu
This patch adds support for the new udc-core reset notifier to the
net2272 driver.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/gadget/udc/net2272.c | 45 +-
1 file changed, 35 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/udc/net2272.c b/drivers/usb/gadget/udc/net2272.c
index 059cfe5..d828680 100644
--- a/drivers/usb/gadget/udc/net2272.c
+++ b/drivers/usb/gadget/udc/net2272.c
@@ -1987,17 +1987,42 @@ net2272_handle_stat1_irqs(struct net2272 *dev, u8 stat)
mask = (1 USB_HIGH_SPEED) | (1 USB_FULL_SPEED);
if (stat tmp) {
+ boolreset = false;
+ booldisconnect = false;
+
+ /*
+* Ignore disconnects and resets if the speed hasn't been set.
+* VBUS can bounce and there's always an initial reset.
+*/
net2272_write(dev, IRQSTAT1, tmp);
- if stat (1 ROOT_PORT_RESET_INTERRUPT))
- ((net2272_read(dev, USBCTL1) mask) == 0))
- || ((net2272_read(dev, USBCTL1) (1 VBUS_PIN))
- == 0))
-(dev-gadget.speed != USB_SPEED_UNKNOWN)) {
- dev_dbg(dev-dev, disconnect %s\n,
- dev-driver-driver.name);
- stop_activity(dev, dev-driver);
- net2272_ep0_start(dev);
- return;
+ if (dev-gadget.speed != USB_SPEED_UNKNOWN) {
+ if ((stat (1 VBUS_INTERRUPT))
+ (net2272_read(dev, USBCTL1)
+ (1 VBUS_PIN)) == 0) {
+ disconnect = true;
+ dev_dbg(dev-dev, disconnect %s\n,
+ dev-driver-driver.name);
+ } else if ((stat (1 ROOT_PORT_RESET_INTERRUPT))
+ (net2272_read(dev, USBCTL1) mask)
+ == 0) {
+ reset = true;
+ dev_dbg(dev-dev, reset %s\n,
+ dev-driver-driver.name);
+ }
+
+ if (disconnect || reset) {
+ stop_activity(dev, dev-driver);
+ net2272_ep0_start(dev);
+ spin_unlock(dev-lock);
+ if (reset)
+ usb_gadget_udc_reset
+ (dev-gadget, dev-driver);
+ else
+ (dev-driver-disconnect)
+ (dev-gadget);
+ spin_lock(dev-lock);
+ return;
+ }
}
stat = ~tmp;
--
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 11/17] usb: gadget: mv_udc_core: use udc-core's reset notifier
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/gadget/udc/mv_udc_core.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/mv_udc_core.c
b/drivers/usb/gadget/udc/mv_udc_core.c
index 040fb16..406d213 100644
--- a/drivers/usb/gadget/udc/mv_udc_core.c
+++ b/drivers/usb/gadget/udc/mv_udc_core.c
@@ -1311,6 +1311,23 @@ static void nuke(struct mv_ep *ep, int status)
}
}
+static void gadget_reset(struct mv_udc *udc, struct usb_gadget_driver *driver)
+{
+ struct mv_ep*ep;
+
+ nuke(udc-eps[0], -ESHUTDOWN);
+
+ list_for_each_entry(ep, udc-gadget.ep_list, ep.ep_list) {
+ nuke(ep, -ESHUTDOWN);
+ }
+
+ /* report disconnect; the driver is already quiesced */
+ if (driver) {
+ spin_unlock(udc-lock);
+ usb_gadget_udc_reset(udc-gadget, driver);
+ spin_lock(udc-lock);
+ }
+}
/* stop all USB activities */
static void stop_activity(struct mv_udc *udc, struct usb_gadget_driver *driver)
{
@@ -1886,7 +1903,7 @@ static void irq_process_reset(struct mv_udc *udc)
dev_info(udc-dev-dev, usb bus reset\n);
udc-usb_state = USB_STATE_DEFAULT;
/* reset all the queues, stop all USB activities */
- stop_activity(udc, udc-driver);
+ gadget_reset(udc, udc-driver);
} else {
dev_info(udc-dev-dev, USB reset portsc 0x%x\n,
readl(udc-op_regs-portsc));
--
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 09/17] usb: gadget: fsl_udc_core: use udc-core's reset notifier
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/gadget/udc/fsl_udc_core.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c
b/drivers/usb/gadget/udc/fsl_udc_core.c
index 75b23ea..a59d37c 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -1774,7 +1774,7 @@ static void bus_resume(struct fsl_udc *udc)
}
/* Clear up all ep queues */
-static int reset_queues(struct fsl_udc *udc)
+static int reset_queues(struct fsl_udc *udc, bool bus_reset)
{
u8 pipe;
@@ -1783,7 +1783,10 @@ static int reset_queues(struct fsl_udc *udc)
/* report disconnect; the driver is already quiesced */
spin_unlock(udc-lock);
- udc-driver-disconnect(udc-gadget);
+ if (bus_reset)
+ usb_gadget_udc_reset(udc-gadget, udc-driver);
+ else
+ udc-driver-disconnect(udc-gadget);
spin_lock(udc-lock);
return 0;
@@ -1837,7 +1840,7 @@ static void reset_irq(struct fsl_udc *udc)
udc-bus_reset = 1;
/* Reset all the queues, include XD, dTD, EP queue
* head and TR Queue */
- reset_queues(udc);
+ reset_queues(udc, true);
udc-usb_state = USB_STATE_DEFAULT;
} else {
VDBG(Controller reset);
@@ -1846,7 +1849,7 @@ static void reset_irq(struct fsl_udc *udc)
dr_controller_setup(udc);
/* Reset all internal used Queues */
- reset_queues(udc);
+ reset_queues(udc, false);
ep0_setup(udc);
--
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 16/17] usb: gadget: bcm63xx_udc: use udc-core's reset notifier
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/gadget/udc/bcm63xx_udc.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc/bcm63xx_udc.c
b/drivers/usb/gadget/udc/bcm63xx_udc.c
index e969eb8..871039e 100644
--- a/drivers/usb/gadget/udc/bcm63xx_udc.c
+++ b/drivers/usb/gadget/udc/bcm63xx_udc.c
@@ -1963,7 +1963,7 @@ static irqreturn_t bcm63xx_udc_ctrl_isr(int irq, void
*dev_id)
{
struct bcm63xx_udc *udc = dev_id;
u32 stat;
- bool disconnected = false;
+ bool disconnected = false, bus_reset = false;
stat = usbd_readl(udc, USBD_EVENT_IRQ_STATUS_REG)
usbd_readl(udc, USBD_EVENT_IRQ_MASK_REG);
@@ -1991,7 +1991,7 @@ static irqreturn_t bcm63xx_udc_ctrl_isr(int irq, void
*dev_id)
udc-ep0_req_reset = 1;
schedule_work(udc-ep0_wq);
- disconnected = true;
+ bus_reset = true;
}
if (stat BIT(USBD_EVENT_IRQ_SETUP)) {
if (bcm63xx_update_link_speed(udc)) {
@@ -2014,6 +2014,8 @@ static irqreturn_t bcm63xx_udc_ctrl_isr(int irq, void
*dev_id)
if (disconnected udc-driver)
udc-driver-disconnect(udc-gadget);
+ else if (bus_reset udc-driver)
+ usb_gadget_udc_reset(udc-gadget, udc-driver);
return IRQ_HANDLED;
}
--
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 14/17] usb: gadget: amd5536udc: use udc-core's reset notifier
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at bus reset handler. Signed-off-by: Peter Chen peter.c...@freescale.com --- drivers/usb/gadget/udc/amd5536udc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/amd5536udc.c b/drivers/usb/gadget/udc/amd5536udc.c index 41b062e..5134467 100644 --- a/drivers/usb/gadget/udc/amd5536udc.c +++ b/drivers/usb/gadget/udc/amd5536udc.c @@ -2873,7 +2873,7 @@ __acquires(dev-lock) dev-driver-resume(dev-gadget); dev-sys_suspended = 0; } - dev-driver-disconnect(dev-gadget); + usb_gadget_udc_reset(dev-gadget, dev-driver); spin_lock(dev-lock); /* disable ep0 to empty req queue */ -- 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 15/17] usb: gadget: r8a66597-udc: use udc-core's reset notifier
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/gadget/udc/r8a66597-udc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/r8a66597-udc.c
b/drivers/usb/gadget/udc/r8a66597-udc.c
index de9c400..22a826f 100644
--- a/drivers/usb/gadget/udc/r8a66597-udc.c
+++ b/drivers/usb/gadget/udc/r8a66597-udc.c
@@ -1345,7 +1345,7 @@ static void irq_device_state(struct r8a66597 *r8a66597)
if (dvsq == DS_DFLT) {
/* bus reset */
spin_unlock(r8a66597-lock);
- r8a66597-driver-disconnect(r8a66597-gadget);
+ usb_gadget_udc_reset(r8a66597-gadget, r8a66597-driver);
spin_lock(r8a66597-lock);
r8a66597_update_usb_speed(r8a66597);
}
--
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 17/17] usb: gadget: atmel_usba_udc: use udc-core's reset notifier
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/gadget/udc/atmel_usba_udc.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index c9fe67e..affbb8d 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1685,11 +1685,10 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
usba_writel(udc, INT_CLR, USBA_END_OF_RESET);
reset_all_endpoints(udc);
- if (udc-gadget.speed != USB_SPEED_UNKNOWN
-udc-driver udc-driver-disconnect) {
+ if (udc-gadget.speed != USB_SPEED_UNKNOWN udc-driver) {
udc-gadget.speed = USB_SPEED_UNKNOWN;
spin_unlock(udc-lock);
- udc-driver-disconnect(udc-gadget);
+ usb_gadget_udc_reset(udc-gadget, udc-driver);
spin_lock(udc-lock);
}
--
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 13/17] usb: gadget: pch_udc: use udc-core's reset notifier
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/gadget/udc/pch_udc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc/pch_udc.c b/drivers/usb/gadget/udc/pch_udc.c
index 460d953..a021b6b 100644
--- a/drivers/usb/gadget/udc/pch_udc.c
+++ b/drivers/usb/gadget/udc/pch_udc.c
@@ -2592,9 +2592,9 @@ static void pch_udc_svc_ur_interrupt(struct pch_udc_dev
*dev)
/* Complete request queue */
empty_req_queue(ep);
}
- if (dev-driver dev-driver-disconnect) {
+ if (dev-driver) {
spin_unlock(dev-lock);
- dev-driver-disconnect(dev-gadget);
+ usb_gadget_udc_reset(dev-gadget, dev-driver);
spin_lock(dev-lock);
}
}
--
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 00/17] usb: gadget: convert udc driver to use udc-core's reset notifier
Hi, On Wed, Sep 17, 2014 at 09:13:53AM +0800, Peter Chen wrote: Hi Felipe, In this series, I convert udc driver to use udc-core's reset notifier which has added recently, I only change the drivers which has bus reset handler and call usb_gadget_driver's -disconnect in it. For five you and Alan's patches, I cherry-pick them from your gadget-add-reset-method branch and change some code and comments for using udc-core's reset notifier. This series is based on yours next tree, and pass the compile test and checkpatch.pl. Alan Stern (3): usb: gadget: dummy-hcd: use udc-core's reset notifier usb: gadget: net2280: use udc-core's reset notifier usb: gadget: net2272: use udc-core's reset notifier Felipe Balbi (2): usb: dwc3: gadget: use udc-core's reset notifier usb: musb: gadget: use udc-core's reset notifier Peter Chen (12): usb: chipidea: gadget: use udc-core's reset notifier usb: gadget: pxa25x_udc: use udc-core's reset notifier usb: gadget: m66592-udc: use udc-core's reset notifier usb: gadget: fsl_udc_core: use udc-core's reset notifier usb: gadget: at91_udc: use udc-core's reset notifier usb: gadget: mv_udc_core: use udc-core's reset notifier usb: gadget: fsl_qe_udc: use udc-core's reset notifier usb: gadget: pch_udc: use udc-core's reset notifier usb: gadget: amd5536udc: use udc-core's reset notifier usb: gadget: r8a66597-udc: use udc-core's reset notifier usb: gadget: bcm63xx_udc: use udc-core's reset notifier usb: gadget: atmel_usba_udc: use udc-core's reset notifier thanks, but I'll have to defer this one for v3.19. I already closed my tree. I'll ask you to resend these once v3.18-rc1 is tagged, until them I'm dropping them from my queue otherwise I'll go a little nuts. In any case, this gives people some time to review and ack your patches. cheers -- balbi signature.asc Description: Digital signature
[PATCH 1/1] usb: xhci: fix comment for PORT_DEV_REMOVE
According to xHCI specification, PORT_DEV_REMOVE(bit 30) in PORTSC
true means Device is non-removable.
Reported-by: Juro Bystricky jurobystri...@hotmail.com
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index dace515..2682f18 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -358,7 +358,7 @@ struct xhci_op_regs {
/* wake on over-current (enable) */
#define PORT_WKOC_E(1 27)
/* bits 28:29 reserved */
-/* true: device is removable - for USB 3.0 roothub emulation */
+/* true: device is non-removable - for USB 3.0 roothub emulation */
#define PORT_DEV_REMOVE(1 30)
/* Initiate a warm port reset - complete when PORT_WRC is '1' */
#define PORT_WR(1 31)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
