Re: [BUG] USB 3.0 device "lost for good" when in SS.inactive or Compliance Mode during hub_port_reset()
Thanks for the reply, Alan.
The USB device is initially in link state 0, and only after the "cold"
reset in link state SS.inactive. After the following warm reset, it is
in link state 0 again.
> ... but the code is in the wrong place. The check needs to occur
> before hub_port_finish_reset, not after. It's a bug to call
> hub_port_finish_reset before the retry loop is over; that call should
> happen after the end of the loop.
Looking at the code, I'd say the hub_port_finish_reset() call is actually
in the _right_ place, because that's where we know that a reset was really
initiated (that step could have errored out) and the reset _try_ should be
finished before the next retry.
What is in the wrong place is coincidentally that code fragment at the
end of hub_port_finish_reset() which I had quoted last time:
> if (udev)
> usb_set_device_state(udev, *status
> ? USB_STATE_NOTATTACHED
> : USB_STATE_DEFAULT);
That part should be done after the retry loop, because the device state
should not be set based on the result of an "interim" reset result
(especially not when the setting may be irrevocable), but rather based
on the final reset result.
So I moved this code fragment from hub_port_finish_reset() to the end of
hub_port_reset() and made sure it only gets there when a reset attempt
was actually made. The following diff is based on kernel sources 3.19.8:
diff -c -r a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
*** a/drivers/usb/core/hub.c2015-05-21 00:11:25.0 +0200
--- b/drivers/usb/core/hub.c2015-05-21 00:19:38.471481393 +0200
***
*** 2736,2745
usb_clear_port_feature(hub->hdev, port1,
USB_PORT_FEAT_C_CONNECTION);
}
- if (udev)
- usb_set_device_state(udev, *status
- ? USB_STATE_NOTATTACHED
- : USB_STATE_DEFAULT);
break;
}
}
--- 2736,2741
***
*** 2770,2781
status = hub_port_status(hub, port1,
&portstatus, &portchange);
if (status < 0)
! goto done;
if (hub_port_warm_reset_required(hub, port1, portstatus))
warm = true;
}
clear_bit(port1, hub->warm_reset_bits);
/* Reset the port */
for (i = 0; i < PORT_RESET_TRIES; i++) {
--- 2766,2778
status = hub_port_status(hub, port1,
&portstatus, &portchange);
if (status < 0)
! return status;
if (hub_port_warm_reset_required(hub, port1, portstatus))
warm = true;
}
clear_bit(port1, hub->warm_reset_bits);
+ status = 0;
/* Reset the port */
for (i = 0; i < PORT_RESET_TRIES; i++) {
***
*** 2836,2841
--- 2833,2843
dev_err(&port_dev->dev, "Cannot enable. Maybe the USB cable is bad?\n");
done:
+ if (udev)
+ usb_set_device_state(udev, status
+ ? USB_STATE_NOTATTACHED
+ : USB_STATE_DEFAULT);
+
if (!hub_is_superspeed(hub->hdev))
up_read(&ehci_cf_port_reset_rwsem);
That also alters the handling of some errors which before the patch caused
hub_port_finish_reset() never to be called and thus the USB device state
not to be altered, but I think it is actually more appropriate to set a
USB device to NOTATTACHED if the reset could not even be initiated, e.g.
because of ENODEV...
It will still leave the USB device state unchanged if it errors out at the
initial "double check" if a warm reset is needed, as the current code
does. It might be more appropriate to just skip the double check rather
than exiting, though...
What do you think, is that an appropriate fix?
Best Regards,
Robert Schlabbach
--
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: Running ADB on a "stock" distribution (g_ffs)
On Thu, 2015-05-21 at 08:42 +0200, Krzysztof Opasiak wrote: > On 05/20/2015 06:42 PM, Bastien Nocera wrote: > > Hey, > > > > After discussing this with Andrzej, I'm no closer to being able to > > get > > this working... > > > > I'm trying to run adbd (the service that would usually run on an > > Android phone in developer mode) on a stock distribution, on a > > device > > that used to run Windows 8 (and now a Fedora). > > > > This is my version of adbd: > > https://github.com/hadess/adbd/ > > > > This is the systemd service file I eventually want to use, but I'm > > running those commands "by hand" right now, and they fail in the > > same > > way. > > > > https://github.com/hadess/adbd/blob/master/adbd.service > > > > I'm getting this error from adbd: > > OPENING /dev/usb-ffs/adb/ep0 [ /dev/usb-ffs/adb/ep0: writing > > strings failed: errno=16] Using ffs-test from tools/usb/ffs-test.c I have the same problem. Writing descriptors works, but writing strings throws -EBUSY. Those are the options used (from /boot/config-4.1.0 -0.rc0.git13.2.fc22.i686) CONFIG_USB_GADGET=m CONFIG_USB_FUNCTIONFS_GENERIC=y CONFIG_USB_GADGET_VBUS_DRAW=2 CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2 CONFIG_USB_LIBCOMPOSITE=m CONFIG_USB_F_ACM=m CONFIG_USB_U_SERIAL=m CONFIG_USB_F_SERIAL=m CONFIG_USB_F_OBEX=m CONFIG_USB_F_FS=m CONFIG_USB_CONFIGFS=m CONFIG_USB_CONFIGFS_F_FS=y CONFIG_USB_FUNCTIONFS=m CONFIG_USB_FUNCTIONFS_GENERIC=y CONFIG_USB_G_SERIAL=m > > Which comes from this error message: > > https://github.com/hadess/adbd/blob/master/adb/usb_linux_client.c#L > > 275 > > > > It looks like this can only happen if the gadget FS was already > > registered: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tre > > e/drivers/usb/gadget/legacy/g_ffs.c#n301 > > > > Any ideas? > > > > Could you please try to use ConfigFS interface instead of using > g_ffs? Could you explain how I would set that up? Is that the way: http://www.spinics.net/lists/linux-usb/msg96121.html ? > I have used this setup some time ago and it worked fine, so it > should be > a good method of checking if adbd is working properly. > > (tools/usb/ffs-aio-example) with g_ffs instead of adbd and see what > happen. ffs-test fails in the same way, as mentioned above. Does one need specific hardware to make this work? This is a tablet, so I usually use a USB OTG adapter to plug in keyboard/mouse/network, but I unplug all this to run the test tool, or adbd. > BTW. > Which kernel version do you use? I'm still on Linus' 4.1.0-rc0, but if anything relevant changed, I can certainly update to a newer version. Cheers -- 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 v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
On Wed, May 20, 2015 at 4:52 PM, Thierry Reding
wrote:
> I'm a little confused by the simple-mfd approach. The only code I see in
> linux-next for this is a single line that adds the "simple-mfd" string
> to the OF device ID table in drivers/of/platform.c. As far as I can tell
> this will merely cause child devices to be created. There won't be a
> shared regmap and resources won't be set up properly either.
That is correct. The simple-mfd is a two-component approach.
Ideally, in the simplest case, you combine simple-mfd with syscon.
foo@0 {
compatible = "foo", "syscon", "simple-mfd";
reg = <0x1000 0x1000>;
bar@1 {
compatible = "bar";
};
baz@2 {
compatible = "baz";
};
};
This will instantiate bar and baz.
These subdrivers then probe and:
probe() {
struct regmap *map;
map = syscon_node_to_regmap(parent->of_node);
(...)
}
Simple, syscon is the MFD hub.
Yours,
Linus Walleij
--
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: ulpi: don't register drivers if bus doesn't exist
> >>ULPI registers it's bus at module_init so if the bus fails to register, the > >A minor comment: s/it's/its/ > > > >>module will fail to load and all will be well in the world. > >> > >>However, if the ULPI code is built-in rather than a module, the bus > >>initialization may fail but we'd still try to register drivers later onto > >>a non-existant bus, which will panic the kernel. > >> > >>Fix that by checking that the bus was indeed initialized before trying to > >>register drivers on top of it. > >> > >>Signed-off-by: Sasha Levin > >>--- > >> drivers/usb/common/ulpi.c |4 > >> 1 file changed, 4 insertions(+) > >> > >>diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c > >>index 0e6f968..0b0a5e7 100644 > >>--- a/drivers/usb/common/ulpi.c > >>+++ b/drivers/usb/common/ulpi.c > >>@@ -132,6 +132,10 @@ int ulpi_register_driver(struct ulpi_driver *drv) > >>if (!drv->probe) > >>return -EINVAL; > >>+ /* Was the bus registered successfully? */ > >>+ if (!ulpi_bus.p) > >>+ return -ENODEV; I think we need to warn in this case. How about: if (unlikely(WARN_ON(!ulpi_bus.p))) return -ENODEV; > >Good catch. Otherwise it may trigger BUG() on driver_register(). > >I wonder if it would be nice to have a macro for that checking :) > > > >Anyway, > > > >Reviewed-by: David Cohen > > Well, I was also encountering panic issue when running it on > Intel Bay Trail tablets. In my case, it's due to the execution > sequence. When ulpi bus is built-in, driver or device registered > before ulpi bus registration. This patch will fix the panic you saw as well, but of course we still want the ulpi phy drivers to load successfully even if they and the bus are build-in, so we need your patch as well. Thanks, -- 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 1/1] usb: ulpi: ulpi_init should be used in subsys_initcall
On Thu, May 21, 2015 at 01:40:43PM +0800, Lu Baolu wrote: > The intention of this change is to fix below kernel panic when > USB_ULPI_BUS was configured as buildin. That is actually incorrect. Having the bus build-in does not cause this panic.. > [0.746856] kernel BUG at drivers/base/driver.c:153! > [0.752418] invalid opcode: [#1] PREEMPT SMP > [0.757804] Modules linked in: > [0.893985] Call Trace: > [0.896729] [] ? ulpi_register_driver+0x21/0x30 > [0.903654] [] tusb1210_driver_init+0x10/0x12 > [0.910386] [] do_one_initcall+0xd8/0x200 > [0.916729] [] kernel_init_freeable+0x196/0x21e > [0.923655] [] ? rest_init+0x90/0x90 > [0.929509] [] kernel_init+0xe/0xf0 > [0.935266] [] ret_from_fork+0x42/0x70 > [0.941315] [] ? rest_init+0x90/0x90 This happens if the PHY drivers are build-in. If the bus is build-in, but the drivers are modules, you are still fine. Maybe it would have been better to explain that this is addressing an issue with the execution sequence, and consider Sasha's patch as the actual fix for panic. Thanks guys, -- 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: Running ADB on a "stock" distribution (g_ffs)
On 05/21/2015 09:18 AM, Bastien Nocera wrote: On Thu, 2015-05-21 at 08:42 +0200, Krzysztof Opasiak wrote: On 05/20/2015 06:42 PM, Bastien Nocera wrote: Hey, After discussing this with Andrzej, I'm no closer to being able to get this working... I'm trying to run adbd (the service that would usually run on an Android phone in developer mode) on a stock distribution, on a device that used to run Windows 8 (and now a Fedora). This is my version of adbd: https://github.com/hadess/adbd/ This is the systemd service file I eventually want to use, but I'm running those commands "by hand" right now, and they fail in the same way. https://github.com/hadess/adbd/blob/master/adbd.service I'm getting this error from adbd: OPENING /dev/usb-ffs/adb/ep0 [ /dev/usb-ffs/adb/ep0: writing strings failed: errno=16] Using ffs-test from tools/usb/ffs-test.c I have the same problem. Writing descriptors works, but writing strings throws -EBUSY. Those are the options used (from /boot/config-4.1.0 -0.rc0.git13.2.fc22.i686) CONFIG_USB_GADGET=m CONFIG_USB_FUNCTIONFS_GENERIC=y CONFIG_USB_GADGET_VBUS_DRAW=2 CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2 CONFIG_USB_LIBCOMPOSITE=m CONFIG_USB_F_ACM=m CONFIG_USB_U_SERIAL=m CONFIG_USB_F_SERIAL=m CONFIG_USB_F_OBEX=m CONFIG_USB_F_FS=m CONFIG_USB_CONFIGFS=m CONFIG_USB_CONFIGFS_F_FS=y CONFIG_USB_FUNCTIONFS=m CONFIG_USB_FUNCTIONFS_GENERIC=y CONFIG_USB_G_SERIAL=m Everything looks good. Before doing what I described below please remember to $ modprobe libcomposite $ mount none -t configfs /sys/kernel/config Which comes from this error message: https://github.com/hadess/adbd/blob/master/adb/usb_linux_client.c#L 275 It looks like this can only happen if the gadget FS was already registered: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tre e/drivers/usb/gadget/legacy/g_ffs.c#n301 Any ideas? Could you please try to use ConfigFS interface instead of using g_ffs? Could you explain how I would set that up? Is that the way: http://www.spinics.net/lists/linux-usb/msg96121.html ? Yes, you can use this instruction but I think that using libusbg[1] would be easier. Just edit gadget-ffs example to create only one instance of ffs function and pass adb as instance name. if you have this ready you should run as follows: $ gadget-ffs $ mount adb -t functionfs $ adbd $ sleep 1 $ echo `ls /sys/class/udc | tail -n 1` > /sys/kernel/config/usb_gadget/g1/UDC Here are also some presentations[2][3] on how to use configfs/libusbg. I have used this setup some time ago and it worked fine, so it should be a good method of checking if adbd is working properly. (tools/usb/ffs-aio-example) with g_ffs instead of adbd and see what happen. ffs-test fails in the same way, as mentioned above. Does one need specific hardware to make this work? This is a tablet, so I usually use a USB OTG adapter to plug in keyboard/mouse/network, but I unplug all this to run the test tool, or adbd. Nope. hardware is being automatically selected (we simply take first free udc or return -ENODEV if no free udc). You may check if you have an UDC in your system (check if /sys/class/udc dir is not empty) BTW. Which kernel version do you use? I'm still on Linus' 4.1.0-rc0, but if anything relevant changed, I can certainly update to a newer version. Should be fine. Footnotes: 1 - https://github.com/kopasiak/libusbg/ 2 - http://events.linuxfoundation.org/sites/events/files/slides/Tame_the_USB_gadgets_takative_beast_Opasiak_Krzysztof_0.pdf 3 - http://events.linuxfoundation.org/sites/events/files/slides/LinuxConNA-Make-your-own-USB-gadget-Andrzej.Pietrasiewicz.pdf -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -- 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: Running ADB on a "stock" distribution (g_ffs)
On Thu, 2015-05-21 at 09:38 +0200, Krzysztof Opasiak wrote: > On 05/21/2015 09:18 AM, Bastien Nocera wrote: > > > > Does one need specific hardware to make this work? This is a > > tablet, > > so I usually use a USB OTG adapter to plug in > > keyboard/mouse/network, > > but I unplug all this to run the test tool, or adbd. > > > > Nope. hardware is being automatically selected (we simply take first > free udc or return -ENODEV if no free udc). > > You may check if you have an UDC in your system (check if > /sys/class/udc > dir is not empty) Huh. It there, but it *is* empty on that tablet. But my config says: # CONFIG_USB_BDC_UDC is not set I guess I should turn that on, right? -- 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: Running ADB on a "stock" distribution (g_ffs)
On 05/21/2015 09:50 AM, Bastien Nocera wrote: On Thu, 2015-05-21 at 09:38 +0200, Krzysztof Opasiak wrote: On 05/21/2015 09:18 AM, Bastien Nocera wrote: Does one need specific hardware to make this work? This is a tablet, so I usually use a USB OTG adapter to plug in keyboard/mouse/network, but I unplug all this to run the test tool, or adbd. Nope. hardware is being automatically selected (we simply take first free udc or return -ENODEV if no free udc). You may check if you have an UDC in your system (check if /sys/class/udc dir is not empty) Huh. It there, but it *is* empty on that tablet. But my config says: # CONFIG_USB_BDC_UDC is not set I guess I should turn that on, right? So this may be quite a good reason why it is not working;) You should check what UDC is in your tablet and turn on its driver in kernel config. Best regards, -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -- 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: Running ADB on a "stock" distribution (g_ffs)
On Thu, 2015-05-21 at 09:50 +0200, Bastien Nocera wrote: > On Thu, 2015-05-21 at 09:38 +0200, Krzysztof Opasiak wrote: > > On 05/21/2015 09:18 AM, Bastien Nocera wrote: > > > > > > > Does one need specific hardware to make this work? This is a > > > tablet, > > > so I usually use a USB OTG adapter to plug in > > > keyboard/mouse/network, > > > but I unplug all this to run the test tool, or adbd. > > > > > > > Nope. hardware is being automatically selected (we simply take > > first > > free udc or return -ENODEV if no free udc). > > > > You may check if you have an UDC in your system (check if > > /sys/class/udc > > dir is not empty) > > Huh. It there, but it *is* empty on that tablet. > > But my config says: > # CONFIG_USB_BDC_UDC is not set > > I guess I should turn that on, right? Should have read the Kconfig, that's for: "Broadcom USB3.0 device controller IP driver(BDC)" So not what I'm looking for. But this is a Bay Trail tablet, so unless the firmware is doing stupid things, the functionality should surely be available, as Android runs on some of that SoC. -- 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: Running ADB on a "stock" distribution (g_ffs)
On 05/21/2015 10:00 AM, Bastien Nocera wrote: On Thu, 2015-05-21 at 09:50 +0200, Bastien Nocera wrote: On Thu, 2015-05-21 at 09:38 +0200, Krzysztof Opasiak wrote: On 05/21/2015 09:18 AM, Bastien Nocera wrote: Does one need specific hardware to make this work? This is a tablet, so I usually use a USB OTG adapter to plug in keyboard/mouse/network, but I unplug all this to run the test tool, or adbd. Nope. hardware is being automatically selected (we simply take first free udc or return -ENODEV if no free udc). You may check if you have an UDC in your system (check if /sys/class/udc dir is not empty) Huh. It there, but it *is* empty on that tablet. But my config says: # CONFIG_USB_BDC_UDC is not set I guess I should turn that on, right? Should have read the Kconfig, that's for: "Broadcom USB3.0 device controller IP driver(BDC)" So not what I'm looking for. But this is a Bay Trail tablet, so unless the firmware is doing stupid things, the functionality should surely be available, as Android runs on some of that SoC. Could you specify exactly the model? If android is running fine on it you may check android kernel config for this device and check which udc is enabled. -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -- 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/1] usb: ulpi: ulpi_init should be used in subsys_initcall
On 05/21/2015 03:33 PM, Heikki Krogerus wrote: On Thu, May 21, 2015 at 01:40:43PM +0800, Lu Baolu wrote: The intention of this change is to fix below kernel panic when USB_ULPI_BUS was configured as buildin. That is actually incorrect. Having the bus build-in does not cause this panic.. [0.746856] kernel BUG at drivers/base/driver.c:153! [0.752418] invalid opcode: [#1] PREEMPT SMP [0.757804] Modules linked in: [0.893985] Call Trace: [0.896729] [] ? ulpi_register_driver+0x21/0x30 [0.903654] [] tusb1210_driver_init+0x10/0x12 [0.910386] [] do_one_initcall+0xd8/0x200 [0.916729] [] kernel_init_freeable+0x196/0x21e [0.923655] [] ? rest_init+0x90/0x90 [0.929509] [] kernel_init+0xe/0xf0 [0.935266] [] ret_from_fork+0x42/0x70 [0.941315] [] ? rest_init+0x90/0x90 This happens if the PHY drivers are build-in. If the bus is build-in, but the drivers are modules, you are still fine. I ever tried the config of bus "=y" and driver "=n". It results in panic as well. The call trace looks like below. 1.058876] [] device_add+0x402/0x640 [1.064829] [] device_register+0x1e/0x30 [1.071072] [] ulpi_register_interface+0x14c/0x1f0 [1.078291] [] dwc3_ulpi_init+0x24/0x60 [1.084437] [] dwc3_probe+0x802/0x1650 [1.090487] [] platform_drv_probe+0x34/0xa0 [1.097022] [] driver_probe_device+0x209/0x4b0 [1.103850] [] ? driver_probe_device+0x4b0/0x4b0 [1.110871] [] __device_attach+0x3b/0x40 [1.117114] [] bus_for_each_drv+0x63/0xa0 [1.123454] [] device_attach+0x98/0xb0 [1.129503] [] bus_probe_device+0xa0/0xc0 [1.135843] [] device_add+0x46f/0x640 [1.141799] [] ? __insert_resource+0x60/0x150 [1.148530] [] platform_device_add+0xd0/0x2b0 [1.155260] [] dwc3_pci_probe+0xf6/0x2c0 [1.161505] [] pci_device_probe+0x8c/0xf0 [1.167846] [] driver_probe_device+0x209/0x4b0 [1.174673] [] __driver_attach+0x9b/0xa0 [1.180917] [] ? __device_attach+0x40/0x40 [1.187354] [] bus_for_each_dev+0x6b/0xb0 [1.193694] [] driver_attach+0x1e/0x20 [1.199742] [] bus_add_driver+0x180/0x250 [1.206086] [] ? ftrace_define_fields_dwc3_log_trb+0x126/0x126 [1.214474] [] driver_register+0x64/0xf0 [1.220718] [] __pci_register_driver+0x4b/0x50 [1.227546] [] dwc3_pci_driver_init+0x19/0x1b [1.234277] [] do_one_initcall+0xd8/0x200 [1.240619] [] kernel_init_freeable+0x196/0x21e [1.247545] [] ? rest_init+0x90/0x90 [1.253399] [] kernel_init+0xe/0xf0 [1.259156] [] ret_from_fork+0x42/0x70 [1.265205] [] ? rest_init+0x90/0x90 Maybe it would have been better to explain that this is addressing an issue with the execution sequence, and consider Sasha's patch as the actual fix for panic. Fair enough. I will resend the patch. Thanks guys, Thanks, Baolu -- 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: Running ADB on a "stock" distribution (g_ffs)
On Thu, 2015-05-21 at 10:09 +0200, Krzysztof Opasiak wrote: > Could you specify exactly the model? Onda v975w > If android is running fine on it you may check android kernel config > for > this device and check which udc is enabled. No kernel sources from this Chinese vendor. But it looks like the USB_DWC3 config is the one to enable. In the meantime, shouldn't the ffs-test and adbd have failed with ENOTSUPP instead of EBUSY if no hardware support was available? -- 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 v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
On Wed, 20 May 2015, Thierry Reding wrote:
> On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > On Tue, 19 May 2015, Andrew Bresticker wrote:
> > > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > > wrote:
> > > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones
> > > > wrote:
> > > >> On Thu, 14 May 2015, Jon Hunter wrote:
> > > >>> On 13/05/15 15:39, Lee Jones wrote:
> > > >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> > > >>> >
> > > >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> > > >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> > > >>> >> communication with the XUSB micro-controller and an xHCI
> > > >>> >> host-controller.
> > > >>> >>
> > > >>> >> Signed-off-by: Andrew Bresticker
> > > >>> >> Cc: Rob Herring
> > > >>> >> Cc: Pawel Moll
> > > >>> >> Cc: Mark Rutland
> > > >>> >> Cc: Ian Campbell
> > > >>> >> Cc: Kumar Gala
> > > >>> >> Cc: Samuel Ortiz
> > > >>> >> Cc: Lee Jones
> > > >>> >> ---
> > > >>> >> Changes from v7:
> > > >>> >> - Move non-shared resources into child nodes.
> > > >>> >> New for v7.
> > > >>> >> ---
> > > >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37
> > > >>> >> ++
> > > >>> >> 1 file changed, 37 insertions(+)
> > > >>> >> create mode 100644
> > > >>> >> Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > >>> >>
> > > >>> >> diff --git
> > > >>> >> a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > >>> >> b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > >>> >> new file mode 100644
> > > >>> >> index 000..bc50110
> > > >>> >> --- /dev/null
> > > >>> >> +++
> > > >>> >> b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > >>> >> @@ -0,0 +1,37 @@
> > > >>> >> +NVIDIA Tegra XUSB host copmlex
> > > >>> >> +==
> > > >>> >> +
> > > >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI
> > > >>> >> host
> > > >>> >> +controller and a mailbox for communication with the XUSB
> > > >>> >> micro-controller.
> > > >>> >> +
> > > >>> >> +Required properties:
> > > >>> >> +
> > > >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> > > >>> >> + Otherwise, must contain '"nvidia,-xusb",
> > > >>> >> "nvidia,tegra124-xusb"'
> > > >>> >> + where is tegra132.
> > > >>> >> + - reg: Must contain the base and length of the XUSB FPCI
> > > >>> >> registers.
> > > >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty
> > > >>> >> since the
> > > >>> >> + mapping is 1:1.
> > > >>> >> + - #address-cells: Must be 2.
> > > >>> >> + - #size-cells: Must be 2.
> > > >>> >> +
> > > >>> >> +Example:
> > > >>> >> +
> > > >>> >> + usb@0,70098000 {
> > > >>> >> + compatible = "nvidia,tegra124-xusb";
> > > >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> > > >>> >> + ranges;
> > > >>> >> +
> > > >>> >> + #address-cells = <2>;
> > > >>> >> + #size-cells = <2>;
> > > >>> >> +
> > > >>> >> + usb-host@0,7009 {
> > > >>> >> + compatible = "nvidia,tegra124-xhci";
> > > >>> >> + ...
> > > >>> >> + };
> > > >>> >> +
> > > >>> >> + mailbox {
> > > >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> > > >>> >> + ...
> > > >>> >> + };
> > > >>> >
> > > >>> > This doesn't appear to be a proper MFD. I would have the USB and
> > > >>> > Mailbox devices probe seperately and use a phandle to point the USB
> > > >>> > device to its Mailbox.
> > > >>> >
> > > >>> > usb@xyz {
> > > >>> > mboxes = <&xusb-mailbox, [chan]>;
> > > >>> > };
> > > >>> >
> > > >>>
> > > >>> I am assuming that Andrew had laid it out like this to reflect the hw
> > > >>> structure. The mailbox and xhci controller are part of the xusb
> > > >>> sub-system and hence appear as child nodes. My understanding is that
> > > >>> for
> > > >>> device-tree we want the device-tree structure to reflect the actual
> > > >>> hw.
> > > >>> Is this not the case?
> > > >>
> > > >> Yes, the DT files should reflect h/w. I have requested to see what
> > > >> the memory map looks like, so I might provide a more appropriate
> > > >> solution to accepting a pretty pointless MFD.
> > > >
> > > > FWIW, the address map for XUSB looks like this:
> > > >
> > > > XUSB_HOST: 0x7009 - 0x7009a000
> > > > xHCI registers: 0x7009 - 0x70098000
> > > > FPCI configuration registers: 0x70098000 - 0x70099000
> > > > IPFS configuration registers: 0x70099000 - 0x7009a000
> > > >
> > > >> Two solutions spring to mind. You can either call
> > > >> of_platform_populate() from the USB driver, as some already do:
> > > >>
> > > >> drivers/usb/dwc3/dwc3-exynos.c:
> > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > >> drivers/usb/dwc3/dwc3-keystone.c:
> > > >> err
[PATCH 1/1] usb: ulpi: don't register drivers if bus doesn't exist
ULPI registers its bus at module_init, so if the bus fails to register, the
module will fail to load and all will be well in the world.
However, if the ULPI code is built-in rather than a module, the bus
initialization may fail, but we'd still try to register drivers later onto
a non-existent bus, which will panic the kernel.
Fix that by checking that the bus was indeed initialized before trying to
register drivers on top of it.
Signed-off-by: Sasha Levin
Signed-off-by: Heikki Krogerus
Signed-off-by: Lu Baolu
Reported-by: Zhuo Qiuxu
Reviewed-by: David Cohen
---
drivers/usb/common/ulpi.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 0e6f968..af52b46 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -132,6 +132,10 @@ int ulpi_register_driver(struct ulpi_driver *drv)
if (!drv->probe)
return -EINVAL;
+ /* Was the bus registered successfully? */
+ if (unlikely(WARN_ON(!ulpi_bus.p)))
+ return -ENODEV;
+
drv->driver.bus = &ulpi_bus;
return driver_register(&drv->driver);
@@ -242,7 +246,7 @@ static int __init ulpi_init(void)
{
return bus_register(&ulpi_bus);
}
-module_init(ulpi_init);
+subsys_initcall(ulpi_init);
static void __exit ulpi_exit(void)
{
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Running ADB on a "stock" distribution (g_ffs)
On 05/21/2015 10:39 AM, Bastien Nocera wrote:
On Thu, 2015-05-21 at 10:09 +0200, Krzysztof Opasiak wrote:
Could you specify exactly the model?
Onda v975w
If android is running fine on it you may check android kernel config
for
this device and check which udc is enabled.
No kernel sources from this Chinese vendor. But it looks like the
USB_DWC3 config is the one to enable.
I see that this tablet is running windows by default so just flash it
with stock image and check what device manager says about udc;)
In the meantime, shouldn't the ffs-test and adbd have failed with
ENOTSUPP instead of EBUSY if no hardware support was available?
As far as I understand the code it should fail with -ENODEV and debug
message:
pr_debug("couldn't find an available UDC\n");
Have you tried loading other gadget modules? If not, maybe try to load
g_ether and check what dmesg says.
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
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] extcon: fix phy-tahvo driver for extcon API change
Today, the API for the extcon drivers was changed, along
with all drivers in drivers/extcon. However, one extcon driver
instead lives in drivers/usb/phy/ and did not get change.
Gcc warns about the now incorrect API usage:
drivers/usb/phy/phy-tahvo.c: In function 'tahvo_usb_probe':
drivers/usb/phy/phy-tahvo.c:368:29: warning: assignment from incompatible
pointer type [-Wincompatible-pointer-types]
tu->extcon.supported_cable = tahvo_cable;
This changes the API in the same way as the other drivers.
Signed-off-by: Arnd Bergmann
Fixes: 17cd440c9acc ("extcon: Update the prototype of
extcon_register_notifier() with enum extcon")
---
As the API change is only present in the extcon tree, this patch should get
merged there as well, not in the usb-phy tree.
If possible, please fold into the original commit.
diff --git a/drivers/usb/phy/phy-tahvo.c b/drivers/usb/phy/phy-tahvo.c
index 845f658276b1..1d1bb9ad8ccf 100644
--- a/drivers/usb/phy/phy-tahvo.c
+++ b/drivers/usb/phy/phy-tahvo.c
@@ -60,10 +60,11 @@ struct tahvo_usb {
struct extcon_dev extcon;
};
-static const char *tahvo_cable[] = {
- "USB-HOST",
- "USB",
- NULL,
+static const enum extcon tahvo_cable[] = {
+ EXTCON_USB,
+ EXTCON_USB_HOST,
+
+ EXTCON_NONE,
};
static ssize_t vbus_state_show(struct device *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: [PATCH v2 6/6] usb: chipidea: add work-around for Marvell HSIC PHY startup
> > On Wed, May 20, 2015 at 10:13 PM, Peter Chen > wrote: > > On Tue, May 19, 2015 at 09:10:05PM -0500, Rob Herring wrote: > >> The Marvell 28nm HSIC PHY requires the port to be forced to HS mode > >> after the port power is applied. This is done using the test mode in > >> the PORTSC register. > >> > >> As HSIC is always HS, this work-around should be safe to do with all > >> HSIC PHYs. If not, a flag can also be added. > > > > I think a flag is needed, not sure all vendors can work well with that. > > Only i.MX6Sx uses HSIC in mainline. Is that something you can test? It would > be > better to not add flags unless they are really needed. > Otherwise you end up with dozens of flags like SDHCI drivers have. > I will have a test for this, and show you the result later. Peter
Re: [PATCH 1/1] usb: ulpi: don't register drivers if bus doesn't exist
Hi Heikki, Sasha and others,
Please ignore this patch. I should not squash these two patches into one and
sign it off behalf of other people. I apologize for this and I'm sorry
if this lets
you feel affronted.
Thanks,
Baolu
On 05/21/2015 04:57 PM, Lu Baolu wrote:
ULPI registers its bus at module_init, so if the bus fails to register, the
module will fail to load and all will be well in the world.
However, if the ULPI code is built-in rather than a module, the bus
initialization may fail, but we'd still try to register drivers later onto
a non-existent bus, which will panic the kernel.
Fix that by checking that the bus was indeed initialized before trying to
register drivers on top of it.
Signed-off-by: Sasha Levin
Signed-off-by: Heikki Krogerus
Signed-off-by: Lu Baolu
Reported-by: Zhuo Qiuxu
Reviewed-by: David Cohen
---
drivers/usb/common/ulpi.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 0e6f968..af52b46 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -132,6 +132,10 @@ int ulpi_register_driver(struct ulpi_driver *drv)
if (!drv->probe)
return -EINVAL;
+ /* Was the bus registered successfully? */
+ if (unlikely(WARN_ON(!ulpi_bus.p)))
+ return -ENODEV;
+
drv->driver.bus = &ulpi_bus;
return driver_register(&drv->driver);
@@ -242,7 +246,7 @@ static int __init ulpi_init(void)
{
return bus_register(&ulpi_bus);
}
-module_init(ulpi_init);
+subsys_initcall(ulpi_init);
static void __exit ulpi_exit(void)
{
--
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 v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
On Thu, May 21, 2015 at 09:40:01AM +0100, Lee Jones wrote:
> On Wed, 20 May 2015, Thierry Reding wrote:
> > On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > > On Tue, 19 May 2015, Andrew Bresticker wrote:
> > > > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > > > wrote:
> > > > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones
> > > > > wrote:
> > > > >> On Thu, 14 May 2015, Jon Hunter wrote:
> > > > >>> On 13/05/15 15:39, Lee Jones wrote:
> > > > >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> > > > >>> >
> > > > >>> >> Add a binding document for the XUSB host complex on NVIDIA
> > > > >>> >> Tegra124
> > > > >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> > > > >>> >> communication with the XUSB micro-controller and an xHCI
> > > > >>> >> host-controller.
> > > > >>> >>
> > > > >>> >> Signed-off-by: Andrew Bresticker
> > > > >>> >> Cc: Rob Herring
> > > > >>> >> Cc: Pawel Moll
> > > > >>> >> Cc: Mark Rutland
> > > > >>> >> Cc: Ian Campbell
> > > > >>> >> Cc: Kumar Gala
> > > > >>> >> Cc: Samuel Ortiz
> > > > >>> >> Cc: Lee Jones
> > > > >>> >> ---
> > > > >>> >> Changes from v7:
> > > > >>> >> - Move non-shared resources into child nodes.
> > > > >>> >> New for v7.
> > > > >>> >> ---
> > > > >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37
> > > > >>> >> ++
> > > > >>> >> 1 file changed, 37 insertions(+)
> > > > >>> >> create mode 100644
> > > > >>> >> Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > >>> >>
> > > > >>> >> diff --git
> > > > >>> >> a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > >>> >> b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > >>> >> new file mode 100644
> > > > >>> >> index 000..bc50110
> > > > >>> >> --- /dev/null
> > > > >>> >> +++
> > > > >>> >> b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > >>> >> @@ -0,0 +1,37 @@
> > > > >>> >> +NVIDIA Tegra XUSB host copmlex
> > > > >>> >> +==
> > > > >>> >> +
> > > > >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an
> > > > >>> >> xHCI host
> > > > >>> >> +controller and a mailbox for communication with the XUSB
> > > > >>> >> micro-controller.
> > > > >>> >> +
> > > > >>> >> +Required properties:
> > > > >>> >> +
> > > > >>> >> + - compatible: For Tegra124, must contain
> > > > >>> >> "nvidia,tegra124-xusb".
> > > > >>> >> + Otherwise, must contain '"nvidia,-xusb",
> > > > >>> >> "nvidia,tegra124-xusb"'
> > > > >>> >> + where is tegra132.
> > > > >>> >> + - reg: Must contain the base and length of the XUSB FPCI
> > > > >>> >> registers.
> > > > >>> >> + - ranges: Bus address mapping for the XUSB block. Can be
> > > > >>> >> empty since the
> > > > >>> >> + mapping is 1:1.
> > > > >>> >> + - #address-cells: Must be 2.
> > > > >>> >> + - #size-cells: Must be 2.
> > > > >>> >> +
> > > > >>> >> +Example:
> > > > >>> >> +
> > > > >>> >> + usb@0,70098000 {
> > > > >>> >> + compatible = "nvidia,tegra124-xusb";
> > > > >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> > > > >>> >> + ranges;
> > > > >>> >> +
> > > > >>> >> + #address-cells = <2>;
> > > > >>> >> + #size-cells = <2>;
> > > > >>> >> +
> > > > >>> >> + usb-host@0,7009 {
> > > > >>> >> + compatible = "nvidia,tegra124-xhci";
> > > > >>> >> + ...
> > > > >>> >> + };
> > > > >>> >> +
> > > > >>> >> + mailbox {
> > > > >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> > > > >>> >> + ...
> > > > >>> >> + };
> > > > >>> >
> > > > >>> > This doesn't appear to be a proper MFD. I would have the USB and
> > > > >>> > Mailbox devices probe seperately and use a phandle to point the
> > > > >>> > USB
> > > > >>> > device to its Mailbox.
> > > > >>> >
> > > > >>> > usb@xyz {
> > > > >>> > mboxes = <&xusb-mailbox, [chan]>;
> > > > >>> > };
> > > > >>> >
> > > > >>>
> > > > >>> I am assuming that Andrew had laid it out like this to reflect the
> > > > >>> hw
> > > > >>> structure. The mailbox and xhci controller are part of the xusb
> > > > >>> sub-system and hence appear as child nodes. My understanding is
> > > > >>> that for
> > > > >>> device-tree we want the device-tree structure to reflect the actual
> > > > >>> hw.
> > > > >>> Is this not the case?
> > > > >>
> > > > >> Yes, the DT files should reflect h/w. I have requested to see what
> > > > >> the memory map looks like, so I might provide a more appropriate
> > > > >> solution to accepting a pretty pointless MFD.
> > > > >
> > > > > FWIW, the address map for XUSB looks like this:
> > > > >
> > > > > XUSB_HOST: 0x7009 - 0x7009a000
> > > > > xHCI registers: 0x7009 - 0x70098000
> > > > > FPCI configuration registers: 0x70098000 - 0x70099000
> > > > > IPFS configuration register
Re: [PATCH 1/1] usb: ulpi: don't register drivers if bus doesn't exist
On Thu, May 21, 2015 at 06:07:25PM +0800, Lu, Baolu wrote: > Hi Heikki, Sasha and others, > > Please ignore this patch. I should not squash these two patches into one and > sign it off behalf of other people. I apologize for this and I'm sorry if > this lets > you feel affronted. No worries. So we'll use patch from Sasha to fix the panic when the bus is missing, and your's to fix the execution order. If you prepare v2 of your original patch, I'll ACK it. Thanks, -- 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
[PATCH v2 1/3] usb: dwc3: gadget: Fix incorrect DEPCMD and DGCMD status macros
Fixed the incorrect macro definitions correctly as per databook. Signed-off-by: Subbaraya Sundeep Bhatta Fixes: b09bb64239c8 (usb: dwc3: gadget: implement Global Command support) Cc: #v3.5+ --- v2 changes: Added Fixes and Cc in commit message. drivers/usb/dwc3/core.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index fdab715..c0eafa6 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -339,7 +339,7 @@ #define DWC3_DGCMD_SET_ENDPOINT_NRDY 0x0c #define DWC3_DGCMD_RUN_SOC_BUS_LOOPBACK0x10 -#define DWC3_DGCMD_STATUS(n) (((n) >> 15) & 1) +#define DWC3_DGCMD_STATUS(n) (((n) >> 12) & 0x0F) #define DWC3_DGCMD_CMDACT (1 << 10) #define DWC3_DGCMD_CMDIOC (1 << 8) @@ -355,7 +355,7 @@ #define DWC3_DEPCMD_PARAM_SHIFT16 #define DWC3_DEPCMD_PARAM(x) ((x) << DWC3_DEPCMD_PARAM_SHIFT) #define DWC3_DEPCMD_GET_RSC_IDX(x) (((x) >> DWC3_DEPCMD_PARAM_SHIFT) & 0x7f) -#define DWC3_DEPCMD_STATUS(x) (((x) >> 15) & 1) +#define DWC3_DEPCMD_STATUS(x) (((x) >> 12) & 0x0F) #define DWC3_DEPCMD_HIPRI_FORCERM (1 << 11) #define DWC3_DEPCMD_CMDACT (1 << 10) #define DWC3_DEPCMD_CMDIOC (1 << 8) -- 1.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] usb: dwc3: gadget: return error if command sent to DGCMD register fails
We need to return error to caller if command is not sent to controller succesfully. Signed-off-by: Subbaraya Sundeep Bhatta Fixes: b09bb64239c8 (usb: dwc3: gadget: implement Global Command support) Cc: #v3.5+ --- v2 changes: Added Fixes and Cc in commit message. drivers/usb/dwc3/gadget.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 8946c32..fcbe120 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -291,6 +291,8 @@ int dwc3_send_gadget_generic_command(struct dwc3 *dwc, unsigned cmd, u32 param) dwc3_trace(trace_dwc3_gadget, "Command Complete --> %d", DWC3_DGCMD_STATUS(reg)); + if (DWC3_DGCMD_STATUS(reg)) + return -EINVAL; return 0; } -- 1.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] usb: dwc3: gadget: return error if command sent to DEPCMD register fails
We need to return error to caller if command is not sent to controller succesfully. Signed-off-by: Subbaraya Sundeep Bhatta Fixes: 72246da40f37 (usb: Introduce DesignWare USB3 DRD Driver) Cc: --- v2 changes: Added Fixes and Cc in commit message. drivers/usb/dwc3/gadget.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index fcbe120..55b5edc 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -330,6 +330,8 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep, dwc3_trace(trace_dwc3_gadget, "Command Complete --> %d", DWC3_DEPCMD_STATUS(reg)); + if (DWC3_DEPCMD_STATUS(reg)) + return -EINVAL; return 0; } -- 1.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XHCI, "brain-dead scanner", and microframe rounding
Dear Mathias, just a heads up: retesting with 4.0.4 revealed, that this issue isn't fixed for my scanner still. To recap: driving the scanner through a ehci port is fine, and fails miserably with xhci. OK: T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 4 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev=04.00 S: Manufacturer=Linux 4.0.4-2.g4f5e0d5-desktop ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=:06:04.2 C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1 P: Vendor=04b8 ProdID=0119 Rev=01.00 S: Manufacturer=EPSON S: Product=EPSON Scanner C: #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=2mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) NOT OK: T: Bus=06 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh=14 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev=04.00 S: Manufacturer=Linux 4.0.4-2.g4f5e0d5-desktop xhci-hcd S: Product=xHCI Host Controller S: SerialNumber=:00:14.0 C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub T: Bus=06 Lev=01 Prnt=01 Port=10 Cnt=02 Dev#= 10 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1 P: Vendor=04b8 ProdID=0119 Rev=01.00 S: Manufacturer=EPSON S: Product=EPSON Scanner C: #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=2mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbfs Additional notes: xsane scanner discovery takes ages (20-30 secs) to find the scanner in the failing case. After selecting the correct device, it takes another delay of 20-30 secs. for presenting the error dialog: error during device I/O. The same procedure with ehci takes about a second until the device selection is shown, and another 0.5 secs later it presents the fully functional scanning UI. This behavior persists since Linux 3.16.x (where I setup this box). Please let me know, if I can be of any help for you for resolving this issue. I find it a little sad, that at the dawn of USB 3.1, we still fight with such issues on the linux USB 3.0 front. Don't forget the many frustrated users observing this, that will not speak up. Cheers, Pete On Donnerstag, 29. Januar 2015 18:42:05 Mathias Nyman wrote: > On 27.01.2015 14:12, Gunter Königsmann wrote: > > That's very good news indeed. > > > > Will re-run the tests on my scanner and looking forward to the fix > > entering mainline. In the meantime I can acknowledge that with the fix my > > computer accepts USB memory sticks that normally didn't work. > > > > Kind regards, > > > > Gunter. > > Did some cleaning of the patch, and noticed it still had a few bits wrong, > but apparently it worked anyway. > > I added the fixes on top of the ep_reset_halt_test branch. > > Can any of you with a failing scanner test that it still works? > > git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git > and the ep_reset_halt_test branch, > > Thanks > > -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
Hi The fix went upstream, but caused regression for other users, and had to be reverted. The cause of the regression was found but the new version was never properly tested and got left behind as more urgent issues arrived. I still need to attend a few other issues before taking up this again -Mathias On 21.05.2015 13:38, Hans-Peter Jansen wrote: > Dear Mathias, > > just a heads up: retesting with 4.0.4 revealed, that this issue isn't fixed > for my scanner still. To recap: driving the scanner through a ehci port is > fine, and fails miserably with xhci. > > OK: > > T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 4 > D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=1d6b ProdID=0002 Rev=04.00 > S: Manufacturer=Linux 4.0.4-2.g4f5e0d5-desktop ehci_hcd > S: Product=EHCI Host Controller > S: SerialNumber=:06:04.2 > C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA > I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub > > T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=480 MxCh= 0 > D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1 > P: Vendor=04b8 ProdID=0119 Rev=01.00 > S: Manufacturer=EPSON > S: Product=EPSON Scanner > C: #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=2mA > I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) > > NOT OK: > > T: Bus=06 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh=14 > D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=1d6b ProdID=0002 Rev=04.00 > S: Manufacturer=Linux 4.0.4-2.g4f5e0d5-desktop xhci-hcd > S: Product=xHCI Host Controller > S: SerialNumber=:00:14.0 > C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA > I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub > > T: Bus=06 Lev=01 Prnt=01 Port=10 Cnt=02 Dev#= 10 Spd=480 MxCh= 0 > D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1 > P: Vendor=04b8 ProdID=0119 Rev=01.00 > S: Manufacturer=EPSON > S: Product=EPSON Scanner > C: #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=2mA > I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbfs > > Additional notes: > > xsane scanner discovery takes ages (20-30 secs) to find the scanner in the > failing case. After selecting the correct device, it takes another delay of > 20-30 secs. for presenting the error dialog: error during device I/O. The > same > procedure with ehci takes about a second until the device selection is shown, > and another 0.5 secs later it presents the fully functional scanning UI. > > This behavior persists since Linux 3.16.x (where I setup this box). > > Please let me know, if I can be of any help for you for resolving this issue. > I find it a little sad, that at the dawn of USB 3.1, we still fight with such > > issues on the linux USB 3.0 front. Don't forget the many frustrated users > observing this, that will not speak up. > > Cheers, > Pete > > On Donnerstag, 29. Januar 2015 18:42:05 Mathias Nyman wrote: >> On 27.01.2015 14:12, Gunter Königsmann wrote: >>> That's very good news indeed. >>> >>> Will re-run the tests on my scanner and looking forward to the fix >>> entering mainline. In the meantime I can acknowledge that with the fix my >>> computer accepts USB memory sticks that normally didn't work. >>> >>> Kind regards, >>> >>> Gunter. >> >> Did some cleaning of the patch, and noticed it still had a few bits wrong, >> but apparently it worked anyway. >> >> I added the fixes on top of the ep_reset_halt_test branch. >> >> Can any of you with a failing scanner test that it still works? >> >> git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git >> and the ep_reset_halt_test branch, >> >> Thanks >> >> -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 > -- 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: [RESEND][PATCH] Bluetooth: Make request workqueue freezable
Hi Takashi, >> The data is cached in RAM. More specifically, the former loaded >> firmware files are reloaded and saved at suspend for each device >> object. See fw_pm_notify() in firmware_class.c. > > OK, this may be a stupid idea, but do we know the firmware > was successfully loaded in the first place? > Also btusb is in the habit of falling back to a generic > firmware in some places. It seems to me that caching > firmware is conceptually not enough, but we'd also need > to record the absence of firmware images. in a lot of cases the firmware is optional. The device will operate fine without the firmware. There are a few devices where the firmware is required, but for many it just contains patches. It would be nice if we could tell request_firmware() if it is optional or mandatory firmware. Or if it should just cache the status of a missing firmware as well. >>> >>> OK, below is a quick hack to record the failed f/w files, too. >>> Not sure whether this helps, though. Proper tests are appreciated. >>> >>> >> >> This doesn't quite work. We end up with the name on fw_names but >> the firmware isn't actually on the firmware cache list. >> >> If request_firmware fails to get the firmware from the filesystem, >> release firmware will be called which is going to free the >> firmware_buf which has been marked as failed anyway. The only >> way to make this work would be to always piggy back and increase >> the ref so it always stays around. But this also marks the firmware >> as a permanent failure. There would need to be a hook somewhere >> to force a cache drop, else there would be no way to add new >> firmware to a running system without a reboot. >> >> Perhaps we split the difference: keep a list of firmware images >> that failed to load in the past and if one is requested during >> a time when usermodehelper isn't available, silently return an >> error? This way, if correct firmware is loaded at a regular time >> the item can be removed from the list. > > Well, IMO, it's way too much expectation for the generic f/w loader. > The driver itself must know already which should be really loaded. > The fact is that it's the driver who calls the function that might not > work in the resume path. So the driver can deal with such exceptions > at best. I keep repeating myself here. From the driver point of view it goes via probe() callback of the USB driver. So the driver does not know. For the driver it looks like a brand new device. There are platforms that might decide to just kill the power to the USB bus where the Bluetooth controller sits on. It gets the power back on resume. However this means it is a brand new device at that point. So the driver should not have to remember everything. Regards Marcel -- 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 3/5] phy: Add Marvell USB 2.0 OTG 28nm PHY
Hi, On Thursday 14 May 2015 04:18 AM, Rob Herring wrote: Add driver for USB PHY found in Marvell PXA1928 SOC. Signed-off-by: Rob Herring Cc: Kishon Vijay Abraham I --- drivers/phy/Kconfig | 10 ++ drivers/phy/Makefile | 1 + drivers/phy/phy-mv-usb2.c | 329 ++ 3 files changed, 340 insertions(+) create mode 100644 drivers/phy/phy-mv-usb2.c diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index a53bd5b..ef7634f 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -52,6 +52,16 @@ config PHY_EXYNOS_MIPI_VIDEO Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung S5P and EXYNOS SoCs. +config PHY_MV_USB2 + tristate "Marvell USB 2.0 28nm PHY Driver" + select GENERIC_PHY + help + Enable this to support Marvell USB 2.0 PHY driver for Marvell + SoC. This driver will do the PHY initialization and shutdown. + The PHY driver will be used by Marvell udc/ehci/otg driver. + + To compile this driver as a module, choose M here. + config PHY_MVEBU_SATA def_bool y depends on ARCH_DOVE || MACH_DOVE || MACH_KIRKWOOD diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index f126251..768e55a 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -10,6 +10,7 @@ obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY)+= phy-armada375-usb2.o obj-$(CONFIG_BCM_KONA_USB2_PHY) += phy-bcm-kona-usb2.o obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o +obj-$(CONFIG_PHY_MV_USB2) += phy-mv-usb2.o obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o obj-$(CONFIG_PHY_MIPHY28LP) += phy-miphy28lp.o obj-$(CONFIG_PHY_MIPHY365X) += phy-miphy365x.o diff --git a/drivers/phy/phy-mv-usb2.c b/drivers/phy/phy-mv-usb2.c new file mode 100644 index 000..c48d111 --- /dev/null +++ b/drivers/phy/phy-mv-usb2.c @@ -0,0 +1,329 @@ +/* + * Copyright (C) 2015 Linaro, Ltd. + * Rob Herring + * + * Based on vendor driver: + * Copyright (C) 2013 Marvell Inc. + * Author: Chao Xie + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* USB PXA1928 PHY mapping */ +#define PHY_28NM_PLL_REG0 0x0 +#define PHY_28NM_PLL_REG1 0x4 +#define PHY_28NM_CAL_REG 0x8 +#define PHY_28NM_TX_REG0 0x0c +#define PHY_28NM_TX_REG1 0x10 +#define PHY_28NM_RX_REG0 0x14 +#define PHY_28NM_RX_REG1 0x18 +#define PHY_28NM_DIG_REG0 0x1c +#define PHY_28NM_DIG_REG1 0x20 +#define PHY_28NM_TEST_REG0 0x24 +#define PHY_28NM_TEST_REG1 0x28 +#define PHY_28NM_MOC_REG 0x2c +#define PHY_28NM_PHY_RESERVE 0x30 +#define PHY_28NM_OTG_REG 0x34 +#define PHY_28NM_CHRG_DET 0x38 +#define PHY_28NM_CTRL_REG0 0xc4 +#define PHY_28NM_CTRL_REG1 0xc8 +#define PHY_28NM_CTRL_REG2 0xd4 +#define PHY_28NM_CTRL_REG3 0xdc + +/* PHY_28NM_PLL_REG0 */ +#define PHY_28NM_PLL_READY BIT(31) + +#define PHY_28NM_PLL_SELLPFR_SHIFT 28 +#define PHY_28NM_PLL_SELLPFR_MASK (0x3 << 28) + +#define PHY_28NM_PLL_FBDIV_SHIFT 16 +#define PHY_28NM_PLL_FBDIV_MASK(0x1ff << 16) + +#define PHY_28NM_PLL_ICP_SHIFT 8 +#define PHY_28NM_PLL_ICP_MASK (0x7 << 8) + +#define PHY_28NM_PLL_REFDIV_SHIFT 0 +#define PHY_28NM_PLL_REFDIV_MASK 0x7f + +/* PHY_28NM_PLL_REG1 */ +#define PHY_28NM_PLL_PU_BY_REG BIT(1) + +#define PHY_28NM_PLL_PU_PLLBIT(0) + +/* PHY_28NM_CAL_REG */ +#define PHY_28NM_PLL_PLLCAL_DONE BIT(31) + +#define PHY_28NM_PLL_IMPCAL_DONE BIT(23) + +#define PHY_28NM_PLL_KVCO_SHIFT16 +#define PHY_28NM_PLL_KVCO_MASK (0x7 << 16) + +#define PHY_28NM_PLL_CAL12_SHIFT 20 +#define PHY_28NM_PLL_CAL12_MASK(0x3 << 20) + +#define PHY_28NM_IMPCAL_VTH_SHIFT 8 +#define PHY_28NM_IMPCAL_VTH_MASK (0x7 << 8) + +#define PHY_28NM_PLLCAL_
Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable
At Thu, 21 May 2015 14:07:11 +0200,
Marcel Holtmann wrote:
>
> Hi Takashi,
>
> >> The data is cached in RAM. More specifically, the former loaded
> >> firmware files are reloaded and saved at suspend for each device
> >> object. See fw_pm_notify() in firmware_class.c.
> >
> > OK, this may be a stupid idea, but do we know the firmware
> > was successfully loaded in the first place?
> > Also btusb is in the habit of falling back to a generic
> > firmware in some places. It seems to me that caching
> > firmware is conceptually not enough, but we'd also need
> > to record the absence of firmware images.
>
> in a lot of cases the firmware is optional. The device will operate fine
> without the firmware. There are a few devices where the firmware is
> required, but for many it just contains patches.
>
> It would be nice if we could tell request_firmware() if it is optional
> or mandatory firmware. Or if it should just cache the status of a
> missing firmware as well.
> >>>
> >>> OK, below is a quick hack to record the failed f/w files, too.
> >>> Not sure whether this helps, though. Proper tests are appreciated.
> >>>
> >>>
> >>
> >> This doesn't quite work. We end up with the name on fw_names but
> >> the firmware isn't actually on the firmware cache list.
> >>
> >> If request_firmware fails to get the firmware from the filesystem,
> >> release firmware will be called which is going to free the
> >> firmware_buf which has been marked as failed anyway. The only
> >> way to make this work would be to always piggy back and increase
> >> the ref so it always stays around. But this also marks the firmware
> >> as a permanent failure. There would need to be a hook somewhere
> >> to force a cache drop, else there would be no way to add new
> >> firmware to a running system without a reboot.
> >>
> >> Perhaps we split the difference: keep a list of firmware images
> >> that failed to load in the past and if one is requested during
> >> a time when usermodehelper isn't available, silently return an
> >> error? This way, if correct firmware is loaded at a regular time
> >> the item can be removed from the list.
> >
> > Well, IMO, it's way too much expectation for the generic f/w loader.
> > The driver itself must know already which should be really loaded.
> > The fact is that it's the driver who calls the function that might not
> > work in the resume path. So the driver can deal with such exceptions
> > at best.
>
> I keep repeating myself here. From the driver point of view it goes
> via probe() callback of the USB driver. So the driver does not
> know. For the driver it looks like a brand new device. There are
> platforms that might decide to just kill the power to the USB bus
> where the Bluetooth controller sits on. It gets the power back on
> resume. However this means it is a brand new device at that
> point. So the driver should not have to remember everything.
Then avoiding the failed firmware is no solution, indeed.
If it's a new probe, it should be never executed during resume.
That is, either freeze the work like Laura's patch or explicitly allow
the UMH lock wait like my patch. Laura's patch has a merit that it's
much simpler. OTOH, if you want to keep the changes only in
request_firmware() call, you can think of changes like my patch; a
revised version is attached below.
Takashi
---
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 171841ad1008..87157f557263 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -97,21 +97,6 @@ static inline long firmware_loading_timeout(void)
return loading_timeout > 0 ? loading_timeout * HZ : MAX_JIFFY_OFFSET;
}
-/* firmware behavior options */
-#define FW_OPT_UEVENT (1U << 0)
-#define FW_OPT_NOWAIT (1U << 1)
-#ifdef CONFIG_FW_LOADER_USER_HELPER
-#define FW_OPT_USERHELPER (1U << 2)
-#else
-#define FW_OPT_USERHELPER 0
-#endif
-#ifdef CONFIG_FW_LOADER_USER_HELPER_FALLBACK
-#define FW_OPT_FALLBACKFW_OPT_USERHELPER
-#else
-#define FW_OPT_FALLBACK0
-#endif
-#define FW_OPT_NO_WARN (1U << 3)
-
struct firmware_cache {
/* firmware_buf instance will be added into the below list */
spinlock_t lock;
@@ -1085,8 +1070,7 @@ static int assign_firmware_buf(struct firmware *fw,
struct device *device,
}
/* called from request_firmware() and request_firmware_work_func() */
-static int
-_request_firmware(const struct firmware **firmware_p, const char *name,
+int _request_firmware(const struct firmware **firmware_p, const char *name,
struct device *device, unsigned int opt_flags)
{
struct firmware *fw;
@@ -1099,13 +1083,15 @@ _request_firmware(const struct firmware **firmware_p,
const char *name,
if (!name || name[0] == '\0')
return -EINVAL;
+ /* Need to pin this module until return */
+ _
Re: [PATCH 4/5] phy: add Marvell HSIC 28nm PHY
Hi,
On Thursday 14 May 2015 04:18 AM, Rob Herring wrote:
Add PHY driver for the Marvell HSIC 28nm PHY. This PHY is found in PXA1928
SOC.
Signed-off-by: Rob Herring
Cc: Kishon Vijay Abraham I
---
drivers/phy/Kconfig | 10 +++
drivers/phy/Makefile | 1 +
drivers/phy/phy-mv-hsic.c | 208 ++
3 files changed, 219 insertions(+)
create mode 100644 drivers/phy/phy-mv-hsic.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ef7634f..cfcae72 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -52,6 +52,16 @@ config PHY_EXYNOS_MIPI_VIDEO
Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung S5P
and EXYNOS SoCs.
+config PHY_MV_HSIC
+ tristate "Marvell USB HSIC 28nm PHY Driver"
+ select GENERIC_PHY
+ help
+ Enable this to support Marvell USB HSIC PHY driver for Marvell
+ SoC. This driver will do the PHY initialization and shutdown.
+ The PHY driver will be used by Marvell ehci driver.
+
+ To compile this driver as a module, choose M here.
+
config PHY_MV_USB2
tristate "Marvell USB 2.0 28nm PHY Driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 768e55a..472bf0a 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY)+=
phy-armada375-usb2.o
obj-$(CONFIG_BCM_KONA_USB2_PHY) += phy-bcm-kona-usb2.o
obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
+obj-$(CONFIG_PHY_MV_HSIC) += phy-mv-hsic.o
obj-$(CONFIG_PHY_MV_USB2) += phy-mv-usb2.o
obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o
obj-$(CONFIG_PHY_MIPHY28LP) += phy-miphy28lp.o
diff --git a/drivers/phy/phy-mv-hsic.c b/drivers/phy/phy-mv-hsic.c
new file mode 100644
index 000..aa6cccd
--- /dev/null
+++ b/drivers/phy/phy-mv-hsic.c
@@ -0,0 +1,208 @@
+/*
+ * Copyright (C) 2015 Linaro, Ltd.
+ * Rob Herring
+ *
+ * Based on vendor driver:
+ * Copyright (C) 2013 Marvell Inc.
+ * Author: Chao Xie
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PHY_28NM_HSIC_CTRL 0x08
+#define PHY_28NM_HSIC_IMPCAL_CAL 0x18
+#define PHY_28NM_HSIC_PLL_CTRL01 0x1c
+#define PHY_28NM_HSIC_PLL_CTRL20x20
+#define PHY_28NM_HSIC_INT 0x28
+
+#define PHY_28NM_HSIC_PLL_SELLPFR_SHIFT26
+#define PHY_28NM_HSIC_PLL_FBDIV_SHIFT 0
+#define PHY_28NM_HSIC_PLL_REFDIV_SHIFT 9
+
+#define PHY_28NM_HSIC_S2H_PU_PLL BIT(10)
+#define PHY_28NM_HSIC_H2S_PLL_LOCK BIT(15)
+#define PHY_28NM_HSIC_S2H_HSIC_EN BIT(7)
+#define S2H_DRV_SE0_4RESUMEBIT(14)
+#define PHY_28NM_HSIC_H2S_IMPCAL_DONE BIT(27)
+
+#define PHY_28NM_HSIC_CONNECT_INT BIT(1)
+#define PHY_28NM_HSIC_HS_READY_INT BIT(2)
+
+struct mv_hsic_phy {
+ struct phy *phy;
+ struct platform_device *pdev;
+ void __iomem*base;
+ struct clk *clk;
+};
+
+static bool wait_for_reg(void __iomem *reg, u32 mask, unsigned long timeout)
+{
+ timeout += jiffies;
+ while (time_is_after_eq_jiffies(timeout)) {
+ if ((readl(reg) & mask) == mask)
+ return true;
+ msleep(1);
+ }
+ return false;
+}
+
+static int mv_hsic_phy_init(struct phy *phy)
+{
+ struct mv_hsic_phy *mv_phy = phy_get_drvdata(phy);
+ struct platform_device *pdev = mv_phy->pdev;
+ void __iomem *base = mv_phy->base;
+
+ clk_prepare_enable(mv_phy->clk);
+
+ /* Set reference clock */
+ writel(0x1 << PHY_28NM_HSIC_PLL_SELLPFR_SHIFT |
+ 0xf0 << PHY_28NM_HSIC_PLL_FBDIV_SHIFT |
+ 0xd << PHY_28NM_HSIC_PLL_REFDIV_SHIFT,
+ base + PHY_28NM_HSIC_PLL_CTRL01);
+
+ /* Turn on PLL */
+ writel(readl(base + PHY_28NM_HSIC_PLL_CTRL2) |
+ PHY_28NM_HSIC_S2H_PU_PLL,
+ base + PHY_28NM_HSIC_PLL_CTRL2);
+
+ /* Make sure PHY PLL is locked */
+ if (!wait_for_reg(base + PHY_28NM_HSIC_PLL_CTRL2,
+ PHY_28NM_HSIC_H2S_PLL_LOCK, HZ / 10)) {
+ dev_err(&pdev->dev, "HSIC PHY PLL not locked after 100mS.
Re: [PATCH 4/5] phy: add Marvell HSIC 28nm PHY
On Thursday 21 May 2015 06:15 PM, Kishon Vijay Abraham I wrote:
Hi,
On Thursday 14 May 2015 04:18 AM, Rob Herring wrote:
Add PHY driver for the Marvell HSIC 28nm PHY. This PHY is found in PXA1928
SOC.
Signed-off-by: Rob Herring
Cc: Kishon Vijay Abraham I
---
drivers/phy/Kconfig | 10 +++
drivers/phy/Makefile | 1 +
drivers/phy/phy-mv-hsic.c | 208
++
3 files changed, 219 insertions(+)
create mode 100644 drivers/phy/phy-mv-hsic.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ef7634f..cfcae72 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -52,6 +52,16 @@ config PHY_EXYNOS_MIPI_VIDEO
Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung S5P
and EXYNOS SoCs.
+config PHY_MV_HSIC
+ tristate "Marvell USB HSIC 28nm PHY Driver"
+ select GENERIC_PHY
+ help
+ Enable this to support Marvell USB HSIC PHY driver for Marvell
+ SoC. This driver will do the PHY initialization and shutdown.
+ The PHY driver will be used by Marvell ehci driver.
+
+ To compile this driver as a module, choose M here.
+
config PHY_MV_USB2
tristate "Marvell USB 2.0 28nm PHY Driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 768e55a..472bf0a 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY)+=
phy-armada375-usb2.o
obj-$(CONFIG_BCM_KONA_USB2_PHY) += phy-bcm-kona-usb2.o
obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)+= phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
+obj-$(CONFIG_PHY_MV_HSIC) += phy-mv-hsic.o
obj-$(CONFIG_PHY_MV_USB2)+= phy-mv-usb2.o
obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o
obj-$(CONFIG_PHY_MIPHY28LP) += phy-miphy28lp.o
diff --git a/drivers/phy/phy-mv-hsic.c b/drivers/phy/phy-mv-hsic.c
new file mode 100644
index 000..aa6cccd
--- /dev/null
+++ b/drivers/phy/phy-mv-hsic.c
@@ -0,0 +1,208 @@
+/*
+ * Copyright (C) 2015 Linaro, Ltd.
+ * Rob Herring
+ *
+ * Based on vendor driver:
+ * Copyright (C) 2013 Marvell Inc.
+ * Author: Chao Xie
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PHY_28NM_HSIC_CTRL 0x08
+#define PHY_28NM_HSIC_IMPCAL_CAL 0x18
+#define PHY_28NM_HSIC_PLL_CTRL01 0x1c
+#define PHY_28NM_HSIC_PLL_CTRL20x20
+#define PHY_28NM_HSIC_INT 0x28
+
+#define PHY_28NM_HSIC_PLL_SELLPFR_SHIFT26
+#define PHY_28NM_HSIC_PLL_FBDIV_SHIFT 0
+#define PHY_28NM_HSIC_PLL_REFDIV_SHIFT 9
+
+#define PHY_28NM_HSIC_S2H_PU_PLL BIT(10)
+#define PHY_28NM_HSIC_H2S_PLL_LOCK BIT(15)
+#define PHY_28NM_HSIC_S2H_HSIC_EN BIT(7)
+#define S2H_DRV_SE0_4RESUMEBIT(14)
+#define PHY_28NM_HSIC_H2S_IMPCAL_DONE BIT(27)
+
+#define PHY_28NM_HSIC_CONNECT_INT BIT(1)
+#define PHY_28NM_HSIC_HS_READY_INT BIT(2)
+
+struct mv_hsic_phy {
+ struct phy *phy;
+ struct platform_device *pdev;
+ void __iomem*base;
+ struct clk *clk;
+};
+
+static bool wait_for_reg(void __iomem *reg, u32 mask, unsigned long timeout)
+{
+ timeout += jiffies;
+ while (time_is_after_eq_jiffies(timeout)) {
+ if ((readl(reg) & mask) == mask)
+ return true;
+ msleep(1);
+ }
+ return false;
+}
+
+static int mv_hsic_phy_init(struct phy *phy)
+{
+ struct mv_hsic_phy *mv_phy = phy_get_drvdata(phy);
+ struct platform_device *pdev = mv_phy->pdev;
+ void __iomem *base = mv_phy->base;
+
+ clk_prepare_enable(mv_phy->clk);
+
+ /* Set reference clock */
+ writel(0x1 << PHY_28NM_HSIC_PLL_SELLPFR_SHIFT |
+ 0xf0 << PHY_28NM_HSIC_PLL_FBDIV_SHIFT |
+ 0xd << PHY_28NM_HSIC_PLL_REFDIV_SHIFT,
+ base + PHY_28NM_HSIC_PLL_CTRL01);
+
+ /* Turn on PLL */
+ writel(readl(base + PHY_28NM_HSIC_PLL_CTRL2) |
+ PHY_28NM_HSIC_S2H_PU_PLL,
+ base + PHY_28NM_HSIC_PLL_CTRL2);
+
+ /* Make sure PHY PLL is locked */
+ if (!wait_for_reg(base + PHY_28NM_HSIC_PLL_CTRL2,
+ PHY_28NM_HSIC_H2S_PLL_LOCK, HZ / 10)) {
Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable
On Thu, 21 May 2015, Takashi Iwai wrote: > Then avoiding the failed firmware is no solution, indeed. > If it's a new probe, it should be never executed during resume. Can you expand this comment? What's wrong with probing during resume? The USB stack does carry out probes during resume under certain circumstances. A driver lacking a reset_resume callback is one of those circumstances. 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: [BUG] USB 3.0 device "lost for good" when in SS.inactive or Compliance Mode during hub_port_reset()
On Thu, 21 May 2015, Robert Schlabbach wrote: > Thanks for the reply, Alan. > > The USB device is initially in link state 0, and only after the "cold" > reset in link state SS.inactive. After the following warm reset, it is > in link state 0 again. > > > ... but the code is in the wrong place. The check needs to occur > > before hub_port_finish_reset, not after. It's a bug to call > > hub_port_finish_reset before the retry loop is over; that call should > > happen after the end of the loop. > > Looking at the code, I'd say the hub_port_finish_reset() call is actually > in the _right_ place, because that's where we know that a reset was really > initiated (that step could have errored out) and the reset _try_ should be > finished before the next retry. On closer inspection, the situation looks rather mixed up. hub_port_finish_reset() does two types of things: Things that need to happen after each reset in a retry sequence (like clearing USB_PORT_FEAT_C_RESET); Things that need to happen after the entire retry sequence is over (like the TRSTRCY delay and calling usb_set_device_state). These shouldn't all be in the same subroutine. Maybe the first class of actions should be moved into hub_port_wait_reset. Or maybe the second class should be moved into hub_port_reset. > What is in the wrong place is coincidentally that code fragment at the > end of hub_port_finish_reset() which I had quoted last time: > > > if (udev) > > usb_set_device_state(udev, *status > > ? USB_STATE_NOTATTACHED > > : USB_STATE_DEFAULT); > > That part should be done after the retry loop, because the device state > should not be set based on the result of an "interim" reset result > (especially not when the setting may be irrevocable), but rather based > on the final reset result. > > So I moved this code fragment from hub_port_finish_reset() to the end of > hub_port_reset() and made sure it only gets there when a reset attempt > was actually made. The following diff is based on kernel sources 3.19.8: Kernel hackers always use the unified diff format. We are so used it that we can't even read the old format. :-) > That also alters the handling of some errors which before the patch caused > hub_port_finish_reset() never to be called and thus the USB device state > not to be altered, but I think it is actually more appropriate to set a > USB device to NOTATTACHED if the reset could not even be initiated, e.g. > because of ENODEV... > > It will still leave the USB device state unchanged if it errors out at the > initial "double check" if a warm reset is needed, as the current code > does. It might be more appropriate to just skip the double check rather > than exiting, though... > > What do you think, is that an appropriate fix? I suspect you have not divided up all the actions in the correct way. Look at everything in hub_port_finish_reset and think carefully about where each one belongs. 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: [RESEND][PATCH] Bluetooth: Make request workqueue freezable
Hi Alan, >> Then avoiding the failed firmware is no solution, indeed. >> If it's a new probe, it should be never executed during resume. > > Can you expand this comment? What's wrong with probing during resume? > > The USB stack does carry out probes during resume under certain > circumstances. A driver lacking a reset_resume callback is one of > those circumstances. in case the platform kills the power to the USB lines, we can never do anything about this. I do not want to hack around this in the driver. What are the cases where we should implement reset_resume and would it really help here. Since the btusb.ko driver implements suspend/resume support, would reset_resume ever be called? However I get the feeling someone needs to go back and see if the device is the same one and just gets probed again or if it is a new one from the USB host stack perspective. Regards Marcel -- 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/1] usb: Remove Vernier devices from lsusb and hid_ignore_list
From: Dennis O'Brien
Removes Vernier Software & Technology devices from the ldusb
driver and the hid_ignore_list table of the usbhid driver in the
Linux tree. These devices will now be supported via the hidraw
driver.
A user space driver for these devices will be found in the
Go! Software Development Kit from Vernier at
http://www.vernier.com/downloads/software-development-kits/go-sdk/.
These devices are also be supported by the LabQuest2 standalone
interface shown at http://www.vernier.com/products/interfaces/labq2/
and the LoggerPro for Linux software shown at
http://www.vernier.com/downloads/logger-pro-linux/.
Signed-off-by: Dennis O'Brien
---
drivers/hid/hid-core.c |5 -
drivers/hid/hid-ids.h|7 ---
drivers/usb/misc/ldusb.c | 10 --
3 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 722a925..3a9abfe 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2399,11 +2399,6 @@ static const struct hid_device_id
hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_SYNAPTICS,
USB_DEVICE_ID_SYNAPTICS_WTP) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SYNAPTICS,
USB_DEVICE_ID_SYNAPTICS_DPAD) },
#endif
-{ HID_USB_DEVICE(USB_VENDOR_ID_VERNIER,
USB_DEVICE_ID_VERNIER_LABPRO) },
-{ HID_USB_DEVICE(USB_VENDOR_ID_VERNIER,
USB_DEVICE_ID_VERNIER_GOTEMP) },
-{ HID_USB_DEVICE(USB_VENDOR_ID_VERNIER, USB_DEVICE_ID_VERNIER_SKIP) },
-{ HID_USB_DEVICE(USB_VENDOR_ID_VERNIER,
USB_DEVICE_ID_VERNIER_CYCLOPS) },
-{ HID_USB_DEVICE(USB_VENDOR_ID_VERNIER,
USB_DEVICE_ID_VERNIER_LCSPEC) },
{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP,
USB_DEVICE_ID_4_PHIDGETSERVO_20) },
{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP,
USB_DEVICE_ID_1_PHIDGETSERVO_20) },
{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP,
USB_DEVICE_ID_8_8_4_IF_KIT) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 41f167e..9036beb 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -957,13 +957,6 @@
#define USB_DEVICE_ID_VELLEMAN_K8061_FIRST0x8061
#define USB_DEVICE_ID_VELLEMAN_K8061_LAST0x8068
-#define USB_VENDOR_ID_VERNIER0x08f7
-#define USB_DEVICE_ID_VERNIER_LABPRO0x0001
-#define USB_DEVICE_ID_VERNIER_GOTEMP0x0002
-#define USB_DEVICE_ID_VERNIER_SKIP0x0003
-#define USB_DEVICE_ID_VERNIER_CYCLOPS0x0004
-#define USB_DEVICE_ID_VERNIER_LCSPEC0x0006
-
#define USB_VENDOR_ID_VTL0x0306
#define USB_DEVICE_ID_VTL_MULTITOUCH_FF3F0xff3f
diff --git a/drivers/usb/misc/ldusb.c b/drivers/usb/misc/ldusb.c
index 82503a7..cce22ff 100644
--- a/drivers/usb/misc/ldusb.c
+++ b/drivers/usb/misc/ldusb.c
@@ -69,12 +69,6 @@
#define USB_DEVICE_ID_LD_HYBRID0x2090/* USB Product ID of
Automotive Hybrid */
#define USB_DEVICE_ID_LD_HEATCONTROL0x20A0/* USB Product ID of
Heat control */
-#define USB_VENDOR_ID_VERNIER0x08f7
-#define USB_DEVICE_ID_VERNIER_GOTEMP0x0002
-#define USB_DEVICE_ID_VERNIER_SKIP0x0003
-#define USB_DEVICE_ID_VERNIER_CYCLOPS0x0004
-#define USB_DEVICE_ID_VERNIER_LCSPEC0x0006
-
#ifdef CONFIG_USB_DYNAMIC_MINORS
#define USB_LD_MINOR_BASE0
#else
@@ -115,10 +109,6 @@ static const struct usb_device_id ld_usb_table[] = {
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_MCT) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_HYBRID) },
{ USB_DEVICE(USB_VENDOR_ID_LD, USB_DEVICE_ID_LD_HEATCONTROL) },
-{ USB_DEVICE(USB_VENDOR_ID_VERNIER, USB_DEVICE_ID_VERNIER_GOTEMP) },
-{ USB_DEVICE(USB_VENDOR_ID_VERNIER, USB_DEVICE_ID_VERNIER_SKIP) },
-{ USB_DEVICE(USB_VENDOR_ID_VERNIER, USB_DEVICE_ID_VERNIER_CYCLOPS) },
-{ USB_DEVICE(USB_VENDOR_ID_VERNIER, USB_DEVICE_ID_VERNIER_LCSPEC) },
{ }/* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, ld_usb_table);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: serial: ftdi_sio: Add support for a Motion Tracker Development Board
On Tue, May 19, 2015 at 10:03:01AM +0200, Patrick Riphagen wrote: > This adds support for new Xsens device, Motion Tracker Development Board, > using Xsens' own Vendor ID > > Signed-off-by: Patrick Riphagen Applied, thanks. Johan -- 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: [RESEND][PATCH] Bluetooth: Make request workqueue freezable
At Thu, 21 May 2015 10:18:08 -0400 (EDT), Alan Stern wrote: > > On Thu, 21 May 2015, Takashi Iwai wrote: > > > Then avoiding the failed firmware is no solution, indeed. > > If it's a new probe, it should be never executed during resume. > > Can you expand this comment? What's wrong with probing during resume? Well, if the probe requires the access to a user-space file, it can't be done during resume. That's the very problem we're seeing now. The firmware loader can't help much alone if it's a new device object. > The USB stack does carry out probes during resume under certain > circumstances. A driver lacking a reset_resume callback is one of > those circumstances. So, having a proper reset_resume in btusb would help in the end? Takashi -- 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: [RESEND][PATCH] Bluetooth: Make request workqueue freezable
On Thu, 21 May 2015, Marcel Holtmann wrote: > Hi Alan, > > >> Then avoiding the failed firmware is no solution, indeed. > >> If it's a new probe, it should be never executed during resume. > > > > Can you expand this comment? What's wrong with probing during resume? > > > > The USB stack does carry out probes during resume under certain > > circumstances. A driver lacking a reset_resume callback is one of > > those circumstances. > > in case the platform kills the power to the USB lines, we can never > do anything about this. I do not want to hack around this in the > driver. > > What are the cases where we should implement reset_resume and would > it really help here. Since the btusb.ko driver implements > suspend/resume support, would reset_resume ever be called? One of those cases is exactly what you have been talking about: when the platform kills power to the USB lines during suspend. The driver's reset_resume routine will be called during resume, as opposed to the probe routine being called. Therefore the driver will be able to tell that this is not a new device instance. The other cases are less likely to occur: a device is unable to resume normally and requires a reset before it will start working again, or something else goes wrong along those lines. > However I get the feeling someone needs to go back and see if the > device is the same one and just gets probed again or if it is a new > one from the USB host stack perspective. That can be done easily enough by enabling usbcore debugging before carrying out the system suspend: echo 'module usbcore =p' >/debug/dynamic_debug/control The debugging information in the kernel log will tell just what happened. On Thu, 21 May 2015, Takashi Iwai wrote: > At Thu, 21 May 2015 10:18:08 -0400 (EDT), > Alan Stern wrote: > > > > On Thu, 21 May 2015, Takashi Iwai wrote: > > > > > Then avoiding the failed firmware is no solution, indeed. > > > If it's a new probe, it should be never executed during resume. > > > > Can you expand this comment? What's wrong with probing during resume? > > Well, if the probe requires the access to a user-space file, it can't > be done during resume. That's the very problem we're seeing now. > The firmware loader can't help much alone if it's a new device > object. But the same thing happens during early boot, if the driver is built into the kernel. When the probe occurs, userspace isn't up and running yet, so the firmware loader can't do anything. Why should probe during resume be any worse than probe during early boot? > > The USB stack does carry out probes during resume under certain > > circumstances. A driver lacking a reset_resume callback is one of > > those circumstances. > > So, having a proper reset_resume in btusb would help in the end? It might, depending on how the driver is written. I don't know enough about the details of btusb to say. 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: [RESEND][PATCH] Bluetooth: Make request workqueue freezable
At Thu, 21 May 2015 11:26:17 -0400 (EDT), Alan Stern wrote: > > On Thu, 21 May 2015, Takashi Iwai wrote: > > > At Thu, 21 May 2015 10:18:08 -0400 (EDT), > > Alan Stern wrote: > > > > > > On Thu, 21 May 2015, Takashi Iwai wrote: > > > > > > > Then avoiding the failed firmware is no solution, indeed. > > > > If it's a new probe, it should be never executed during resume. > > > > > > Can you expand this comment? What's wrong with probing during resume? > > > > Well, if the probe requires the access to a user-space file, it can't > > be done during resume. That's the very problem we're seeing now. > > The firmware loader can't help much alone if it's a new device > > object. > > But the same thing happens during early boot, if the driver is built > into the kernel. When the probe occurs, userspace isn't up and running > yet, so the firmware loader can't do anything. > > Why should probe during resume be any worse than probe during early > boot? The early boot has initrd, so the files can be there. But the resume has no way to fetch the file except for cached data. Takashi -- 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: Running ADB on a "stock" distribution (g_ffs)
On Thu, 2015-05-21 at 11:08 +0200, Krzysztof Opasiak wrote:
> On 05/21/2015 10:39 AM, Bastien Nocera wrote:
> > On Thu, 2015-05-21 at 10:09 +0200, Krzysztof Opasiak wrote:
> > > Could you specify exactly the model?
> >
> > Onda v975w
> >
> > > If android is running fine on it you may check android kernel
> > > config
> > > for
> > > this device and check which udc is enabled.
> >
> > No kernel sources from this Chinese vendor. But it looks like the
> > USB_DWC3 config is the one to enable.
> >
>
> I see that this tablet is running windows by default so just flash
> it
> with stock image and check what device manager says about udc;)
The Baytrail UDC driver is supposed to be a DWC3 PCI device, but it
doesn't show up in lspci at all. Given that I managed to make an NFC
chip show up that I didn't know was in the machine, I guess it's
possibly hidden in the firmware somewhere.
> > In the meantime, shouldn't the ffs-test and adbd have failed with
> > ENOTSUPP instead of EBUSY if no hardware support was available?
> >
>
> As far as I understand the code it should fail with -ENODEV and
> debug
> message:
>
> pr_debug("couldn't find an available UDC\n");
I get that stack trace when writing is attempted:
[ 122.362269] [ cut here ]
[ 122.362287] WARNING: CPU: 2 PID: 2384 at
drivers/usb/gadget/function/f_fs.c:3417 ffs_ep0_write+0x730/0x810 [usb_f_fs]()
[ 122.362292] Modules linked in: g_ffs usb_f_fs libcomposite udc_core bnep
bluetooth fuse hid_logitech_hidpp uvcvideo videobuf2_vmalloc snd_usb_audio
videobuf2_core videobuf2_memops v4l2_common snd_usbmidi_lib videodev snd_hwdep
snd_rawmidi media hid_multitouch hid_logitech_dj nf_conntrack_netbios_ns
nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack
ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat
nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security
ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security
iptable_raw vfat pn544_mei fat mei_phy pn544 intel_rapl hci
intel_soc_dts_thermal coretemp nfc gpio_keys snd_soc_sst_baytrail_pcm
[ 122.362412] kvm_intel iTCO_wdt snd_soc_sst_ipc iTCO_vendor_support
snd_soc_sst_dsp kvm snd_soc_sst_byt_rt5640_mach crc32_pclmul crc32c_intel
snd_intel_sst_acpi snd_intel_sst_core snd_soc_sst_mfld_platform snd_soc_rt5640
snd_soc_rl6231 snd_soc_core snd_compress snd_pcm_dmaengine tpm_crb snd_seq tpm
dw_dmac int3402_thermal dw_dmac_core snd_seq_device int3400_thermal kxcjk_1013
soc_button_array snd_pcm processor_thermal_device int3403_thermal
acpi_thermal_rel int340x_thermal_zone mei_txe industrialio_triggered_buffer
goodix mei snd_timer lpc_ich ac i2c_hid kfifo_buf acpi_pad dell_smo8800
iosf_mbi industrialio snd soundcore pwm_lpss_platform rfkill_gpio battery
regmap_i2c pwm_lpss i2c_designware_platform rfkill snd_soc_sst_acpi
i2c_designware_core nfsd auth_rpcgss nfs_acl lockd grace sunrpc dm9601 usbnet
[ 122.362529] mii i915 mmc_block i2c_algo_bit drm_kms_helper drm video
sdhci_acpi sdhci mmc_core
[ 122.362555] CPU: 2 PID: 2384 Comm: adbd Tainted: GW
4.1.0-0.rc4.git0.1.1.fc22.i686 #1
[ 122.362561] Hardware name: To be filled by O.E.M. To be filled by
O.E.M./Aptio CRB, BIOS 5.6.5 07/25/2014
[ 122.362567] c0d1f947 415badfa d1029e64 c0a86e54 d1029e94
c045b937
[ 122.362584] c0c37f94 0002 0950 f9b313d4 0d59 f9b2ebf0 f9b2ebf0
fff0
[ 122.362600] 0003 deb53d00 d1029ea4 c045ba42 0009 d1029f08
f9b2ebf0
[ 122.362617] Call Trace:
[ 122.362633] [] dump_stack+0x41/0x52
[ 122.362645] [] warn_slowpath_common+0x87/0xc0
[ 122.362658] [] ? ffs_ep0_write+0x730/0x810 [usb_f_fs]
[ 122.362668] [] ? ffs_ep0_write+0x730/0x810 [usb_f_fs]
[ 122.362678] [] warn_slowpath_null+0x22/0x30
[ 122.362689] [] ffs_ep0_write+0x730/0x810 [usb_f_fs]
[ 122.362702] [] ? ffs_ep0_read+0x380/0x380 [usb_f_fs]
[ 122.362712] [] __vfs_write+0x2f/0x100
[ 122.362722] [] ? __sb_start_write+0x52/0x110
[ 122.362731] [] vfs_write+0x94/0x1b0
[ 122.362740] [] ? mutex_lock+0x10/0x30
[ 122.362749] [] SyS_write+0x51/0xb0
[ 122.362759] [] sysenter_do_call+0x12/0x12
[ 122.362766] ---[ end trace 0673d3467cecf8db ]---
> Have you tried loading other gadget modules?
No, I didn't try.
> If not, maybe try to load
> g_ether and check what dmesg says.
I didn't have g_ether built, so tried with g_serial:
# modprobe g_serial
modprobe: ERROR: could not insert 'g_serial': No such device
Cheers
--
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: Running ADB on a "stock" distribution (g_ffs)
Hi Bastien, Could you specify exactly the model? >>> >>> Onda v975w >>> If android is running fine on it you may check android kernel config for this device and check which udc is enabled. >>> >>> No kernel sources from this Chinese vendor. But it looks like the >>> USB_DWC3 config is the one to enable. >>> >> >> I see that this tablet is running windows by default so just flash >> it >> with stock image and check what device manager says about udc;) > > The Baytrail UDC driver is supposed to be a DWC3 PCI device, but it > doesn't show up in lspci at all. Given that I managed to make an NFC > chip show up that I didn't know was in the machine, I guess it's > possibly hidden in the firmware somewhere. not all devices enumerate via PCI. Some of them only enumerate via ACPI. Regards Marcel -- 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: [RESEND][PATCH] Bluetooth: Make request workqueue freezable
On 05/21/15 17:35, Takashi Iwai wrote: At Thu, 21 May 2015 11:26:17 -0400 (EDT), Alan Stern wrote: On Thu, 21 May 2015, Takashi Iwai wrote: At Thu, 21 May 2015 10:18:08 -0400 (EDT), Alan Stern wrote: On Thu, 21 May 2015, Takashi Iwai wrote: Then avoiding the failed firmware is no solution, indeed. If it's a new probe, it should be never executed during resume. Can you expand this comment? What's wrong with probing during resume? Well, if the probe requires the access to a user-space file, it can't be done during resume. That's the very problem we're seeing now. The firmware loader can't help much alone if it's a new device object. But the same thing happens during early boot, if the driver is built into the kernel. When the probe occurs, userspace isn't up and running yet, so the firmware loader can't do anything. Why should probe during resume be any worse than probe during early boot? The early boot has initrd, so the files can be there. But the resume has no way to fetch the file except for cached data. but initrd is optional so without initrd it is pretty much the same. Regards, Arend Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable
At Thu, 21 May 2015 19:27:41 +0200, Arend van Spriel wrote: > > On 05/21/15 17:35, Takashi Iwai wrote: > > At Thu, 21 May 2015 11:26:17 -0400 (EDT), > > Alan Stern wrote: > >> > >> On Thu, 21 May 2015, Takashi Iwai wrote: > >> > >>> At Thu, 21 May 2015 10:18:08 -0400 (EDT), > >>> Alan Stern wrote: > > On Thu, 21 May 2015, Takashi Iwai wrote: > > > Then avoiding the failed firmware is no solution, indeed. > > If it's a new probe, it should be never executed during resume. > > Can you expand this comment? What's wrong with probing during resume? > >>> > >>> Well, if the probe requires the access to a user-space file, it can't > >>> be done during resume. That's the very problem we're seeing now. > >>> The firmware loader can't help much alone if it's a new device > >>> object. > >> > >> But the same thing happens during early boot, if the driver is built > >> into the kernel. When the probe occurs, userspace isn't up and running > >> yet, so the firmware loader can't do anything. > >> > >> Why should probe during resume be any worse than probe during early > >> boot? > > > > The early boot has initrd, so the files can be there. But the resume > > has no way to fetch the file except for cached data. > > but initrd is optional so without initrd it is pretty much the same. User can build the firmware into the kernel. Takashi -- 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: [RESEND][PATCH] Bluetooth: Make request workqueue freezable
On Thu, 21 May 2015, Takashi Iwai wrote: > At Thu, 21 May 2015 11:26:17 -0400 (EDT), > Alan Stern wrote: > > > > On Thu, 21 May 2015, Takashi Iwai wrote: > > > > > At Thu, 21 May 2015 10:18:08 -0400 (EDT), > > > Alan Stern wrote: > > > > > > > > On Thu, 21 May 2015, Takashi Iwai wrote: > > > > > > > > > Then avoiding the failed firmware is no solution, indeed. > > > > > If it's a new probe, it should be never executed during resume. > > > > > > > > Can you expand this comment? What's wrong with probing during resume? > > > > > > Well, if the probe requires the access to a user-space file, it can't > > > be done during resume. That's the very problem we're seeing now. > > > The firmware loader can't help much alone if it's a new device > > > object. > > > > But the same thing happens during early boot, if the driver is built > > into the kernel. When the probe occurs, userspace isn't up and running > > yet, so the firmware loader can't do anything. > > > > Why should probe during resume be any worse than probe during early > > boot? > > The early boot has initrd, so the files can be there. But the resume > has no way to fetch the file except for cached data. I suppose USB could delay re-probing until userspace is running again, if we knew when that was. But it would be awkward and prone to races. It also would leave a user-visible window of time during which the device does not exist, which we want to avoid. (This may not matter for bluetooth, but it does matter for other kinds of devices.) I would prefer to solve this problem in a different way, if possible. 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] HID: usbhid: add Chicony/Pixart usb optical mouse that needs QUIRK_ALWAYS_POLL
I received a report from an user of following mouse which needs this quirk:
usb 1-1.6: USB disconnect, device number 58
usb 1-1.6: new low speed USB device number 59 using ehci_hcd
usb 1-1.6: New USB device found, idVendor=04f2, idProduct=1053
usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.6: Product: USB Optical Mouse
usb 1-1.6: Manufacturer: PixArt
usb 1-1.6: configuration #1 chosen from 1 choice
input: PixArt USB Optical Mouse as
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/input/input5887
generic-usb 0003:04F2:1053.16FE: input,hidraw2: USB HID v1.11 Mouse [PixArt USB
Optical Mouse] on usb-:00:1a.0-1.6/input0
The quirk was tested by the reporter and it fixed the frequent disconnections
etc.
Signed-off-by: Herton R. Krzesinski
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 41f167e..b5ff1d0 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -223,6 +223,7 @@
#define USB_DEVICE_ID_CHIC_GAMEPAD 0x0014
#define USB_VENDOR_ID_CHICONY 0x04f2
+#define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE 0x1053
#define USB_DEVICE_ID_CHICONY_TACTICAL_PAD 0x0418
#define USB_DEVICE_ID_CHICONY_MULTI_TOUCH 0xb19d
#define USB_DEVICE_ID_CHICONY_WIRELESS 0x0618
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index a775143..b0f7e9f4 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -69,6 +69,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_PRO_PEDALS, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_3AXIS_5BUTTON_STICK,
HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_AXIS_295, HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE, HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_009B,
HID_QUIRK_ALWAYS_POLL },
--
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: [RESEND][PATCH] Bluetooth: Make request workqueue freezable
At Thu, 21 May 2015 13:37:56 -0400 (EDT), Alan Stern wrote: > > On Thu, 21 May 2015, Takashi Iwai wrote: > > > At Thu, 21 May 2015 11:26:17 -0400 (EDT), > > Alan Stern wrote: > > > > > > On Thu, 21 May 2015, Takashi Iwai wrote: > > > > > > > At Thu, 21 May 2015 10:18:08 -0400 (EDT), > > > > Alan Stern wrote: > > > > > > > > > > On Thu, 21 May 2015, Takashi Iwai wrote: > > > > > > > > > > > Then avoiding the failed firmware is no solution, indeed. > > > > > > If it's a new probe, it should be never executed during resume. > > > > > > > > > > Can you expand this comment? What's wrong with probing during resume? > > > > > > > > Well, if the probe requires the access to a user-space file, it can't > > > > be done during resume. That's the very problem we're seeing now. > > > > The firmware loader can't help much alone if it's a new device > > > > object. > > > > > > But the same thing happens during early boot, if the driver is built > > > into the kernel. When the probe occurs, userspace isn't up and running > > > yet, so the firmware loader can't do anything. > > > > > > Why should probe during resume be any worse than probe during early > > > boot? > > > > The early boot has initrd, so the files can be there. But the resume > > has no way to fetch the file except for cached data. > > I suppose USB could delay re-probing until userspace is running again, > if we knew when that was. But it would be awkward and prone to races. > It also would leave a user-visible window of time during which the > device does not exist, which we want to avoid. (This may not matter > for bluetooth, but it does matter for other kinds of devices.) Right. > I would prefer to solve this problem in a different way, if possible. Well, we're back in square again :) But, before going further the discussion in loop again, I'd like to know which firmware file actually hits. Is it a non-existing firmware? Or is it a firmware that should have been cached? In the latter case, why it isn't used? Takashi -- 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: [RESEND][PATCH] Bluetooth: Make request workqueue freezable
On 05/21/2015 11:11 AM, Takashi Iwai wrote: At Thu, 21 May 2015 13:37:56 -0400 (EDT), Alan Stern wrote: On Thu, 21 May 2015, Takashi Iwai wrote: At Thu, 21 May 2015 11:26:17 -0400 (EDT), Alan Stern wrote: On Thu, 21 May 2015, Takashi Iwai wrote: At Thu, 21 May 2015 10:18:08 -0400 (EDT), Alan Stern wrote: On Thu, 21 May 2015, Takashi Iwai wrote: Then avoiding the failed firmware is no solution, indeed. If it's a new probe, it should be never executed during resume. Can you expand this comment? What's wrong with probing during resume? Well, if the probe requires the access to a user-space file, it can't be done during resume. That's the very problem we're seeing now. The firmware loader can't help much alone if it's a new device object. But the same thing happens during early boot, if the driver is built into the kernel. When the probe occurs, userspace isn't up and running yet, so the firmware loader can't do anything. Why should probe during resume be any worse than probe during early boot? The early boot has initrd, so the files can be there. But the resume has no way to fetch the file except for cached data. I suppose USB could delay re-probing until userspace is running again, if we knew when that was. But it would be awkward and prone to races. It also would leave a user-visible window of time during which the device does not exist, which we want to avoid. (This may not matter for bluetooth, but it does matter for other kinds of devices.) Right. I would prefer to solve this problem in a different way, if possible. Well, we're back in square again :) But, before going further the discussion in loop again, I'd like to know which firmware file actually hits. Is it a non-existing firmware? Or is it a firmware that should have been cached? In the latter case, why it isn't used? Non-existent firmware. The firmware was never present in the system and was never loaded at all. Takashi Thanks, Laura -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] HID: usbhid: add Chicony/Pixart usb optical mouse that needs QUIRK_ALWAYS_POLL
Hi Herton,
On Thu, May 21, 2015 at 2:04 PM, Herton R. Krzesinski wrote:
> I received a report from an user of following mouse which needs this quirk:
>
> usb 1-1.6: USB disconnect, device number 58
> usb 1-1.6: new low speed USB device number 59 using ehci_hcd
> usb 1-1.6: New USB device found, idVendor=04f2, idProduct=1053
> usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> usb 1-1.6: Product: USB Optical Mouse
> usb 1-1.6: Manufacturer: PixArt
> usb 1-1.6: configuration #1 chosen from 1 choice
> input: PixArt USB Optical Mouse as
> /devices/pci:00/:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/input/input5887
> generic-usb 0003:04F2:1053.16FE: input,hidraw2: USB HID v1.11 Mouse [PixArt
> USB Optical Mouse] on usb-:00:1a.0-1.6/input0
>
> The quirk was tested by the reporter and it fixed the frequent disconnections
> etc.
>
> Signed-off-by: Herton R. Krzesinski
> ---
> drivers/hid/hid-ids.h | 1 +
> drivers/hid/usbhid/hid-quirks.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 41f167e..b5ff1d0 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -223,6 +223,7 @@
> #define USB_DEVICE_ID_CHIC_GAMEPAD 0x0014
>
> #define USB_VENDOR_ID_CHICONY 0x04f2
> +#define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE 0x1053
Just a small nitpick here. Please try to keep the list ordered by PID.
Maybe Jiri can amend that directly in his tree too.
Reviewed-by: Benjamin Tissoires
Cheers,
Benjamin
> #define USB_DEVICE_ID_CHICONY_TACTICAL_PAD 0x0418
> #define USB_DEVICE_ID_CHICONY_MULTI_TOUCH 0xb19d
> #define USB_DEVICE_ID_CHICONY_WIRELESS 0x0618
> diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
> index a775143..b0f7e9f4 100644
> --- a/drivers/hid/usbhid/hid-quirks.c
> +++ b/drivers/hid/usbhid/hid-quirks.c
> @@ -69,6 +69,7 @@ static const struct hid_blacklist {
> { USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_PRO_PEDALS, HID_QUIRK_NOGET },
> { USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_3AXIS_5BUTTON_STICK,
> HID_QUIRK_NOGET },
> { USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_AXIS_295, HID_QUIRK_NOGET },
> + { USB_VENDOR_ID_CHICONY,
> USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE, HID_QUIRK_ALWAYS_POLL },
> { USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
> { USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN,
> HID_QUIRK_ALWAYS_POLL },
> { USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_009B,
> HID_QUIRK_ALWAYS_POLL },
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
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
Bogus traffic since 3.19.3 -> 4.0.2 with Ericsson F5521gw WWAN
Hi, (this is the first time I'm reporting a but against the kernel - so please bear with me, and if I'm doing anything wrong or anything is missing, please let me know!) I have a Thinkpad x220t with an Ericsson F5521gw WWAN interface, running Archlinux. Since updating my kernel from 3.19.3 to 4.0.2 I see the following behaviour, which I can also reproduce with 4.1.0 mainline: The network interface (wwan0) has traffic spikes of some gigabytes per second in ifconfig or conky - right now, 10 minutes after booting, I see this: RX packets 4083 bytes 2277043 (2.1 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3680 bytes 12025908915562 (10.9 TiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lsusb | grep Ericsson: Bus 002 Device 003: ID 0bdb:1911 Ericsson Business Mobile Networks BV dmesg | grep cdc: [9.618674] cdc_wdm 2-1.4:1.5: cdc-wdm0: USB WDM device [9.618723] cdc_wdm 2-1.4:1.8: cdc-wdm1: USB WDM device [9.618741] usbcore: registered new interface driver cdc_wdm [9.619206] cdc_acm 2-1.4:1.1: ttyACM0: USB ACM device [9.621604] cdc_acm 2-1.4:1.3: ttyACM1: USB ACM device [9.622121] cdc_acm 2-1.4:1.9: ttyACM2: USB ACM device [9.622705] usbcore: registered new interface driver cdc_acm [9.622707] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters [9.648492] cdc_ncm 2-1.4:1.6: MAC-Address: 02:80:37:ec:02:00 [9.648754] cdc_ncm 2-1.4:1.6 wwan0: register 'cdc_ncm' at usb-:00:1d.0-1.4, Mobile Broadband Network Device, 02:80:37:ec:02:00 [9.648777] usbcore: registered new interface driver cdc_ncm [9.656875] usbcore: registered new interface driver cdc_mbim [ 27.532739] cdc_ncm 2-1.4:1.6 wwan0: kevent 12 may have been dropped [ 27.533187] cdc_ncm 2-1.4:1.6 wwan0: kevent 12 may have been dropped [ 27.533639] cdc_ncm 2-1.4:1.6 wwan0: kevent 12 may have been dropped [ 27.538294] cdc_ncm 2-1.4:1.6 wwan0: network connection: disconnected [ 27.554230] cdc_ncm 2-1.4:1.6 wwan0: 21 mbit/s downlink 5 mbit/s uplink [ 27.562250] cdc_ncm 2-1.4:1.6 wwan0: network connection: connected ver_linux output: Linux ginny 4.1.0-1-mainline #1 SMP PREEMPT Thu May 21 20:32:21 CEST 2015 x86_64 GNU/Linux Gnu C 4.9.2 Gnu make 4.1 binutils 2.25.0 util-linux 2.26.1 mount debug module-init-tools 20 e2fsprogs 1.42.12 jfsutils 1.1.15 reiserfsprogs 3.6.24 xfsprogs 3.2.2 pcmciautils018 PPP2.4.7 Linux C LibraryDynamic linker (ldd) 2.21 Linux C++ Library 6.0.20 Procps 3.3.10 Net-tools 2.10-alpha Kbd2.0.2 Sh-utils 8.23 wireless-tools 30 Modules Loaded ctr ccm snd_hda_codec_hdmi snd_hda_codec_conexant iTCO_wdt iTCO_vendor_support snd_hda_codec_generic arc4 iwldvm coretemp intel_rapl mac80211 iosf_mbi x86_pkg_temp_thermal intel_powerclamp kvm_intel joydev mousedev kvm uvcvideo evdev i915 psmouse videobuf2_vmalloc mac_hid videobuf2_memops pcspkr iwlwifi cdc_mbim serio_raw videobuf2_core snd_hda_intel wacom i2c_i801 cdc_ncm v4l2_common snd_hda_controller usbnet drm_kms_helper cdc_acm videodev cdc_wdm snd_hda_codec mii drm media snd_hda_core intel_gtt i2c_algo_bit cfg80211 lpc_ich thinkpad_acpi thermal wmi e1000e snd_hwdep tpm_tis nvram snd_pcm battery tpm rfkill i2c_core hwmon ac snd_timer mei_me snd mei video shpchp ptp pps_core soundcore button processor sch_fq_codel tun nfs lockd grace sunrpc fscache ext4 crc16 mbcache jbd2 algif_skcipher af_alg dm_crypt dm_mod sd_mod usbhid hid atkbd libps2 crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd ahci libahci libata sdhci_pci sdhci ehci_pci led_class scsi_mod ehci_hcd mmc_core usbcore usb_common i8042 serio When downgrading to 3.19.3 the issue is gone again. Thanks for your time, and please let me know if there's anything I can do to help. Florian -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ pgpBIoya1OukY.pgp Description: PGP signature
Re: Running ADB on a "stock" distribution (g_ffs)
On Thu, 2015-05-21 at 19:08 +0200, Marcel Holtmann wrote: > Hi Bastien, > > > > > > Could you specify exactly the model? > > > > > > > > Onda v975w > > > > > > > > > If android is running fine on it you may check android > > > > > kernel > > > > > config > > > > > for > > > > > this device and check which udc is enabled. > > > > > > > > No kernel sources from this Chinese vendor. But it looks like > > > > the > > > > USB_DWC3 config is the one to enable. > > > > > > > > > > I see that this tablet is running windows by default so just > > > flash > > > it > > > with stock image and check what device manager says about udc;) > > > > The Baytrail UDC driver is supposed to be a DWC3 PCI device, but it > > doesn't show up in lspci at all. Given that I managed to make an > > NFC > > chip show up that I didn't know was in the machine, I guess it's > > possibly hidden in the firmware somewhere. > > not all devices enumerate via PCI. Some of them only enumerate via > ACPI. Right, but the UDC support for Bay Trail is only currently supported on Linux through PCI, no? If it's supported any other way, would you know the ACPI ID for it? I couldn't find anything browsing through the device's DSDT. Given that the v975i variant of the device runs on Android (and this version can run on Android, I think), the device is bound to be exported in some way. -- 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: [RESEND][PATCH] Bluetooth: Make request workqueue freezable
On 05/21/15 19:32, Takashi Iwai wrote: At Thu, 21 May 2015 19:27:41 +0200, Arend van Spriel wrote: On 05/21/15 17:35, Takashi Iwai wrote: At Thu, 21 May 2015 11:26:17 -0400 (EDT), Alan Stern wrote: On Thu, 21 May 2015, Takashi Iwai wrote: At Thu, 21 May 2015 10:18:08 -0400 (EDT), Alan Stern wrote: On Thu, 21 May 2015, Takashi Iwai wrote: Then avoiding the failed firmware is no solution, indeed. If it's a new probe, it should be never executed during resume. Can you expand this comment? What's wrong with probing during resume? Well, if the probe requires the access to a user-space file, it can't be done during resume. That's the very problem we're seeing now. The firmware loader can't help much alone if it's a new device object. So you are saying each device driver should come up with some retry mechanism. Would make more sense to come up with something like that behind the scenes in the firmware loader so all device drivers can rely on one and the same solution. Regards, Arend But the same thing happens during early boot, if the driver is built into the kernel. When the probe occurs, userspace isn't up and running yet, so the firmware loader can't do anything. Why should probe during resume be any worse than probe during early boot? The early boot has initrd, so the files can be there. But the resume has no way to fetch the file except for cached data. but initrd is optional so without initrd it is pretty much the same. User can build the firmware into the kernel. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: High CPU usage when video streaming on EHCI, 3.17.8 kernel with DMA enabled
On Mon, May 18, 2015 at 7:59 AM, Tony Lindgren wrote: > [PATCH] dmaengine: omap-dma: Add support for memcpy Hi Tom, To follow up on your corresponding mail to the gumstix list [1], I tried on the 3.17.8 kernel on an Overo COM (DM37390) with the suggested dmaengine patch applied. Using "hdparm -t --DIRECT /dev/sda" with a USB hard drive attached via the USB EHCI port, I see a read speed of ~24MB/s (vs ~33MB/s on my laptop). I see the same behaviour on a recent kernel (from tony/omap-for-v4.2/cleanup, otherwise works nicely on an Overo FWIW) with and without the dmaengine patch. What would be the expected USB read speed for an OMAP3 platform? --Ash [1] http://gumstix.8.x6.nabble.com/Low-USB-speed-on-Overo-td4969907.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable
On 05/21/2015 08:26 AM, Alan Stern wrote:
On Thu, 21 May 2015, Marcel Holtmann wrote:
Hi Alan,
Then avoiding the failed firmware is no solution, indeed.
If it's a new probe, it should be never executed during resume.
Can you expand this comment? What's wrong with probing during resume?
The USB stack does carry out probes during resume under certain
circumstances. A driver lacking a reset_resume callback is one of
those circumstances.
in case the platform kills the power to the USB lines, we can never
do anything about this. I do not want to hack around this in the
driver.
What are the cases where we should implement reset_resume and would
it really help here. Since the btusb.ko driver implements
suspend/resume support, would reset_resume ever be called?
One of those cases is exactly what you have been talking about: when
the platform kills power to the USB lines during suspend. The driver's
reset_resume routine will be called during resume, as opposed to the
probe routine being called. Therefore the driver will be able to tell
that this is not a new device instance.
The other cases are less likely to occur: a device is unable to resume
normally and requires a reset before it will start working again, or
something else goes wrong along those lines.
However I get the feeling someone needs to go back and see if the
device is the same one and just gets probed again or if it is a new
one from the USB host stack perspective.
That can be done easily enough by enabling usbcore debugging before
carrying out the system suspend:
echo 'module usbcore =p' >/debug/dynamic_debug/control
The debugging information in the kernel log will tell just what
happened.
Playing around in my test setup as a baseline
[ 41.991035] usb usb1-port11: not reset yet, waiting 50ms
[ 42.092902] usb 1-11: reset full-speed USB device number 4 using xhci_hcd
[ 42.143575] usb usb1-port11: not reset yet, waiting 50ms
[ 42.257822] btusb 1-11:1.0: no reset_resume for driver btusb?
[ 42.257823] btusb 1-11:1.1: no reset_resume for driver btusb?
[ 42.257825] btusb 1-11:1.0: forced unbind
[ 42.258305] kworker/dying (826) used greatest stack depth: 10680 bytes left
[ 42.331342] usb 1-9.2: reset full-speed USB device number 7 using xhci_hcd
[ 42.416631] usb 1-9.2: ep0 maxpacket = 8
[ 42.681288] usb 1-9.1: reset low-speed USB device number 5 using xhci_hcd
[ 42.968138] usb 1-9.1: ep 0x81 - rounding interval to 64 microframes, ep
desc says 80 microframes
[ 42.968157] usb 1-9.1: ep 0x82 - rounding interval to 64 microframes, ep
desc says 80 microframes
[ 43.036290] usb 1-9.4: reset high-speed USB device number 8 using xhci_hcd
[ 43.123126] hub 1-9.4:1.0: hub_reset_resume
[ 43.123581] hub 1-9.4:1.0: enabling power on all ports
[ 43.224853] PM: resume of devices complete after 2456.587 msecs
[ 43.225038] btusb 1-11:1.0: usb_probe_interface
[ 43.225040] btusb 1-11:1.0: usb_probe_interface - got id
[ 43.225802] [ cut here ]
[ 43.225807] WARNING: CPU: 7 PID: 2844 at drivers/base/firmware_class.c:1118
_request_firmware+0x5ee/0x890()
so it is trying to call the reset resume. If I try a 'dummy reset resume'
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index a7bdac0..cda8137 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -3401,6 +3401,7 @@ static struct usb_driver btusb_driver = {
#ifdef CONFIG_PM
.suspend= btusb_suspend,
.resume = btusb_resume,
+ .reset_resume = btusb_resume,
#endif
.id_table = btusb_table,
.supports_autosuspend = 1,
I no longer see the warning which means that probe is no longer being called.
Marcel, does implementing a proper reset_resume callback seem like the right
approach or do you need more information?
Thanks,
Laura
--
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 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall
Many drivers and modules depend on ULPI bus registeration to
register ULPI interfaces and drivers. It's more appropriate
to register ULPI bus in subsys_initcall instead of module_init.
Kernel panic has been reported with some kind of kernel config.
[0.746856] kernel BUG at drivers/base/driver.c:153!
[0.752418] invalid opcode: [#1] PREEMPT SMP
[0.757804] Modules linked in:
[0.893985] Call Trace:
[0.896729] [] ? ulpi_register_driver+0x21/0x30
[0.903654] [] tusb1210_driver_init+0x10/0x12
[0.910386] [] do_one_initcall+0xd8/0x200
[0.916729] [] kernel_init_freeable+0x196/0x21e
[0.923655] [] ? rest_init+0x90/0x90
[0.929509] [] kernel_init+0xe/0xf0
[0.935266] [] ret_from_fork+0x42/0x70
[0.941315] [] ? rest_init+0x90/0x90
This patch fixes this kind of kernel panic by putting ulpi_init in
subsys_initcall().
Reported-by: Zhuo Qiuxu
Signed-off-by: Lu Baolu
---
drivers/usb/common/ulpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 0e6f968..01c0c04 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -242,7 +242,7 @@ static int __init ulpi_init(void)
{
return bus_register(&ulpi_bus);
}
-module_init(ulpi_init);
+subsys_initcall(ulpi_init);
static void __exit ulpi_exit(void)
{
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] extcon: fix phy-tahvo driver for extcon API change
Dear Felipe,
If you review this patch, I'll apply it on extcon tree.
Best Regards,
Chanwoo Choi
On 05/21/2015 06:39 PM, Arnd Bergmann wrote:
> Today, the API for the extcon drivers was changed, along
> with all drivers in drivers/extcon. However, one extcon driver
> instead lives in drivers/usb/phy/ and did not get change.
>
> Gcc warns about the now incorrect API usage:
>
> drivers/usb/phy/phy-tahvo.c: In function 'tahvo_usb_probe':
> drivers/usb/phy/phy-tahvo.c:368:29: warning: assignment from incompatible
> pointer type [-Wincompatible-pointer-types]
> tu->extcon.supported_cable = tahvo_cable;
>
> This changes the API in the same way as the other drivers.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 17cd440c9acc ("extcon: Update the prototype of
> extcon_register_notifier() with enum extcon")
> ---
> As the API change is only present in the extcon tree, this patch should get
> merged there as well, not in the usb-phy tree.
>
> If possible, please fold into the original commit.
>
> diff --git a/drivers/usb/phy/phy-tahvo.c b/drivers/usb/phy/phy-tahvo.c
> index 845f658276b1..1d1bb9ad8ccf 100644
> --- a/drivers/usb/phy/phy-tahvo.c
> +++ b/drivers/usb/phy/phy-tahvo.c
> @@ -60,10 +60,11 @@ struct tahvo_usb {
> struct extcon_dev extcon;
> };
>
> -static const char *tahvo_cable[] = {
> - "USB-HOST",
> - "USB",
> - NULL,
> +static const enum extcon tahvo_cable[] = {
> + EXTCON_USB,
> + EXTCON_USB_HOST,
> +
> + EXTCON_NONE,
> };
>
> static ssize_t vbus_state_show(struct device *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: [PATCH v2 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall
Hi, On Fri, May 22, 2015 at 10:07:05AM +0800, Lu Baolu wrote: > Many drivers and modules depend on ULPI bus registeration to > register ULPI interfaces and drivers. It's more appropriate > to register ULPI bus in subsys_initcall instead of module_init. > > Kernel panic has been reported with some kind of kernel config. Even though I agree subsys_initcall is better to register ulpi bus, it's still no excuse to have kernel panic. What about ULPI bus being compiled as module? IMHO this is avoiding the proper kernel panic fix which should be failing gracefully (or defer probe) from tusb1210 driver. Br, David -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall
On Thu, May 21, 2015 at 08:09:54PM -0700, David Cohen wrote: > Hi, > > On Fri, May 22, 2015 at 10:07:05AM +0800, Lu Baolu wrote: > > Many drivers and modules depend on ULPI bus registeration to > > register ULPI interfaces and drivers. It's more appropriate > > to register ULPI bus in subsys_initcall instead of module_init. > > > > Kernel panic has been reported with some kind of kernel config. > > Even though I agree subsys_initcall is better to register ulpi bus, it's > still no excuse to have kernel panic. What about ULPI bus being compiled > as module? > IMHO this is avoiding the proper kernel panic fix which should be > failing gracefully (or defer probe) from tusb1210 driver. Maybe I need to express myself better :) IMHO we should not consider work done with this patch only. It's still incomplete. Br, David -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable
Hi Laura,
> Then avoiding the failed firmware is no solution, indeed.
> If it's a new probe, it should be never executed during resume.
Can you expand this comment? What's wrong with probing during resume?
The USB stack does carry out probes during resume under certain
circumstances. A driver lacking a reset_resume callback is one of
those circumstances.
>>>
>>> in case the platform kills the power to the USB lines, we can never
>>> do anything about this. I do not want to hack around this in the
>>> driver.
>>>
>>> What are the cases where we should implement reset_resume and would
>>> it really help here. Since the btusb.ko driver implements
>>> suspend/resume support, would reset_resume ever be called?
>>
>> One of those cases is exactly what you have been talking about: when
>> the platform kills power to the USB lines during suspend. The driver's
>> reset_resume routine will be called during resume, as opposed to the
>> probe routine being called. Therefore the driver will be able to tell
>> that this is not a new device instance.
>>
>> The other cases are less likely to occur: a device is unable to resume
>> normally and requires a reset before it will start working again, or
>> something else goes wrong along those lines.
>>
>>> However I get the feeling someone needs to go back and see if the
>>> device is the same one and just gets probed again or if it is a new
>>> one from the USB host stack perspective.
>>
>> That can be done easily enough by enabling usbcore debugging before
>> carrying out the system suspend:
>>
>> echo 'module usbcore =p' >/debug/dynamic_debug/control
>>
>> The debugging information in the kernel log will tell just what
>> happened.
>>
>>
>
> Playing around in my test setup as a baseline
>
> [ 41.991035] usb usb1-port11: not reset yet, waiting 50ms
> [ 42.092902] usb 1-11: reset full-speed USB device number 4 using xhci_hcd
> [ 42.143575] usb usb1-port11: not reset yet, waiting 50ms
> [ 42.257822] btusb 1-11:1.0: no reset_resume for driver btusb?
> [ 42.257823] btusb 1-11:1.1: no reset_resume for driver btusb?
> [ 42.257825] btusb 1-11:1.0: forced unbind
> [ 42.258305] kworker/dying (826) used greatest stack depth: 10680 bytes left
> [ 42.331342] usb 1-9.2: reset full-speed USB device number 7 using xhci_hcd
> [ 42.416631] usb 1-9.2: ep0 maxpacket = 8
> [ 42.681288] usb 1-9.1: reset low-speed USB device number 5 using xhci_hcd
> [ 42.968138] usb 1-9.1: ep 0x81 - rounding interval to 64 microframes, ep
> desc says 80 microframes
> [ 42.968157] usb 1-9.1: ep 0x82 - rounding interval to 64 microframes, ep
> desc says 80 microframes
> [ 43.036290] usb 1-9.4: reset high-speed USB device number 8 using xhci_hcd
> [ 43.123126] hub 1-9.4:1.0: hub_reset_resume
> [ 43.123581] hub 1-9.4:1.0: enabling power on all ports
> [ 43.224853] PM: resume of devices complete after 2456.587 msecs
> [ 43.225038] btusb 1-11:1.0: usb_probe_interface
> [ 43.225040] btusb 1-11:1.0: usb_probe_interface - got id
> [ 43.225802] [ cut here ]
> [ 43.225807] WARNING: CPU: 7 PID: 2844 at
> drivers/base/firmware_class.c:1118 _request_firmware+0x5ee/0x890()
>
>
> so it is trying to call the reset resume. If I try a 'dummy reset resume'
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index a7bdac0..cda8137 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -3401,6 +3401,7 @@ static struct usb_driver btusb_driver = {
> #ifdef CONFIG_PM
>.suspend= btusb_suspend,
>.resume = btusb_resume,
> + .reset_resume = btusb_resume,
> #endif
>.id_table = btusb_table,
>.supports_autosuspend = 1,
>
>
> I no longer see the warning which means that probe is no longer being called.
>
> Marcel, does implementing a proper reset_resume callback seem like the right
> approach or do you need more information?
I wonder what is the right work that needs to be done in the reset_resume
callback. I am curious if devices are forgetting their firmware or not. There
is a patch to make the Realtek devices forcefully reset_resume since they
forget their firmware. So there is at least one kind of devices where the
firmware does not survive normal suspend/resume behaviour.
If the devices forget the firmware, then this means that we actually need to
tell the Bluetooth core that this device has been reset and it has to run
through hdev->setup() again. If it does that, then we have the same problem
that the firmware will not be found since userspace is not yet ready. However
we could note the fact that we tried to lookup the firmware and just know that
it was not found. So that might help already.
Devices that always require the firmware, we can assume that the firmware will
have been cached since we successfully loaded it in the first place. Which will
most likely make the Realtek devices f
Re: [PATCH v2 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall
On 05/22/2015 11:11 AM, David Cohen wrote: On Thu, May 21, 2015 at 08:09:54PM -0700, David Cohen wrote: Hi, On Fri, May 22, 2015 at 10:07:05AM +0800, Lu Baolu wrote: Many drivers and modules depend on ULPI bus registeration to register ULPI interfaces and drivers. It's more appropriate to register ULPI bus in subsys_initcall instead of module_init. Kernel panic has been reported with some kind of kernel config. Even though I agree subsys_initcall is better to register ulpi bus, it's still no excuse to have kernel panic. What about ULPI bus being compiled as module? No kernel panic if ULPI is built as a module. IMHO this is avoiding the proper kernel panic fix which should be failing gracefully (or defer probe) from tusb1210 driver. Maybe I need to express myself better :) IMHO we should not consider work done with this patch only. It's still incomplete. I am with you on that we should know the real problem. I could go ahead with further debugging. Do you have any suggestions about which direction should I go? Br, David Thank you, -Baolu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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
