[PATCH] usb: ehci-orion: fix probe for !GENERIC_PHY
Commit d445913ce0ab7f ("usb: ehci-orion: add optional PHY support")
added support for optional phys, but devm_phy_optional_get returns
-ENOSYS if GENERIC_PHY is not enabled.
This causes probe failures, even when there are no phys specified:
[1.443365] orion-ehci f1058000.usb: init f1058000.usb fail, -38
[1.449403] orion-ehci: probe of f1058000.usb failed with error -38
Similar to dwc3, treat -ENOSYS as no phy.
Fixes: d445913ce0ab7f ("usb: ehci-orion: add optional PHY support")
Signed-off-by: Jonas Gorski
---
drivers/usb/host/ehci-orion.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
index bfcbb9a..ee8d5fa 100644
--- a/drivers/usb/host/ehci-orion.c
+++ b/drivers/usb/host/ehci-orion.c
@@ -224,7 +224,8 @@ static int ehci_orion_drv_probe(struct platform_device
*pdev)
priv->phy = devm_phy_optional_get(&pdev->dev, "usb");
if (IS_ERR(priv->phy)) {
err = PTR_ERR(priv->phy);
- goto err_phy_get;
+ if (err != -ENOSYS)
+ goto err_phy_get;
} else {
err = phy_init(priv->phy);
if (err)
--
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] usb: ehci-orion: fix probe for !GENERIC_PHY
On Sun, 23 Aug 2015, Jonas Gorski wrote:
> Commit d445913ce0ab7f ("usb: ehci-orion: add optional PHY support")
> added support for optional phys, but devm_phy_optional_get returns
> -ENOSYS if GENERIC_PHY is not enabled.
>
> This causes probe failures, even when there are no phys specified:
>
> [1.443365] orion-ehci f1058000.usb: init f1058000.usb fail, -38
> [1.449403] orion-ehci: probe of f1058000.usb failed with error -38
>
> Similar to dwc3, treat -ENOSYS as no phy.
>
> Fixes: d445913ce0ab7f ("usb: ehci-orion: add optional PHY support")
>
> Signed-off-by: Jonas Gorski
> ---
> drivers/usb/host/ehci-orion.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
> index bfcbb9a..ee8d5fa 100644
> --- a/drivers/usb/host/ehci-orion.c
> +++ b/drivers/usb/host/ehci-orion.c
> @@ -224,7 +224,8 @@ static int ehci_orion_drv_probe(struct platform_device
> *pdev)
> priv->phy = devm_phy_optional_get(&pdev->dev, "usb");
> if (IS_ERR(priv->phy)) {
> err = PTR_ERR(priv->phy);
> - goto err_phy_get;
> + if (err != -ENOSYS)
> + goto err_phy_get;
> } else {
> err = phy_init(priv->phy);
> if (err)
Acked-by: Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: core: buffer: Added parenthesis to sizeof
This patch fixes a coding style issue by adding parenthesis
to the sizeof operator, which is the preferred way of using it.
Signed-off-by: Muhammad Falak R Wani
---
drivers/usb/core/buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index 506b969..58004eb 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -70,7 +70,7 @@ int hcd_buffer_create(struct usb_hcd *hcd)
size = pool_max[i];
if (!size)
continue;
- snprintf(name, sizeof name, "buffer-%d", size);
+ snprintf(name, sizeof(name), "buffer-%d", size);
hcd->pool[i] = dma_pool_create(name, hcd->self.controller,
size, size, 0);
if (!hcd->pool[i]) {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: core: driver: Use kmalloc_array
This patch introduces the use of function kmalloc_array(), instead
of using kmalloc(), for allocating memory for an array and removes
the corresponding call to kmalloc().
Signed-off-by: Muhammad Falak R Wani
---
drivers/usb/core/driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index 818369a..d19106b 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -416,7 +416,7 @@ static int usb_unbind_interface(struct device *dev)
if (ep->streams == 0)
continue;
if (j == 0) {
- eps = kmalloc(USB_MAXENDPOINTS * sizeof(void *),
+ eps = kmalloc_array(USB_MAXENDPOINTS, sizeof(void *),
GFP_KERNEL);
if (!eps) {
dev_warn(dev, "oom, leaking streams\n");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: core: driver: Use kmalloc_array
On Mon, 2015-08-24 at 00:18 +0530, Muhammad Falak R Wani wrote:
> This patch introduces the use of function kmalloc_array(), instead
> of using kmalloc(), for allocating memory for an array and removes
> the corresponding call to kmalloc().
[]
> diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
[]
> @@ -416,7 +416,7 @@ static int usb_unbind_interface(struct device *dev)
> if (ep->streams == 0)
> continue;
> if (j == 0) {
> - eps = kmalloc(USB_MAXENDPOINTS * sizeof(void *),
> + eps = kmalloc_array(USB_MAXENDPOINTS, sizeof(void *),
> GFP_KERNEL);
> if (!eps) {
> dev_warn(dev, "oom, leaking streams\n");
Allocations like this really don't need to use
kmalloc_array as it's unlikely that USB_MAXENDPOINTS
is very large.
If you are going to do this, it'd be nicer to keep
the parenthesis alignment and likely also better to
remove the dev_warn for a memory leak.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hello Alan, bisecting turned out to be much simpler than I was afraid of. Here's the result: 638139eb95d2d241781330a321e88c8dafe46078 is the first bad commit commit 638139eb95d2d241781330a321e88c8dafe46078 Author: Petr Mladek Date: Fri Sep 19 17:32:24 2014 +0200 usb: hub: allow to process more usb hub events in parallel It seems that only choose_devnum() was not ready to process more hub events at the same time. All should be fine if we take bus->usb_address0_mutex there. It will make sure that more devnums will not be chosen for the given bus and the related devices at the same time. Signed-off-by: Petr Mladek Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman :04 04 6c3b464b8db2bec572cf7904c0aac317b41c1eec da3ee40957d0637f17895ae05aad4a6646377b2a M drivers thanks and cheers, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] FTDI CBUS GPIO support
On Sun, 21 Jun 2015 21:44:30 +0200
, Stefan Agner
wrote:
> On 2015-06-21 01:49, Peter Stuge wrote:
> > Stefan Agner wrote:
> >> libftdi requires to detach the kernel driver to get access to the device
> >
> > Control transfers ought to be possible without a detach.
>
> Good to know, thanks for this input. The detach is probably a default
> behavior of libftdi... Will have a look at that.
libftdi is built on libusb. libusb detaches the device from ftdi_sio and
binds it to a special driver for userspace access. There may indeed be
another way to do it, but libusb doesn't know how to do it AFAIKS.
We can't avoid the detach on current libftdi, but I do have a patch to
libftdi that will at least reconnect the ftdi_sio driver after userspace
has finished. I'll be posting it to the libftdi list in the next week,
but I've attached it below for anyone who wants to play.
> Having kernel level gpiolib would still have advantages: It would make
> the matching of the GPIO's and tty device easier, since with this patch
> the gpiolib device is a sub-node of the usb-serial device in sysfs and
> the user would have to use kernel interfaces only (no libftdi)...
NAK on the sysfs interface. Don't add a new ABI. gpiolib is the right
way to expose these pins.
g.
---
Subject: [PATCH] Automatically reattach kernel driver on close
The built-in libusb auto detach feature supports automatically
reattaching the kernel driver when the device is closed. Switch libftdi
to use the libusb auto-detach code so that we can get the Linux ftdi_sio
driver reattached automatically when finished with the device.
---
src/ftdi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/ftdi.c b/src/ftdi.c
index 68489ea096be..0d043690aeca 100644
--- a/src/ftdi.c
+++ b/src/ftdi.c
@@ -548,7 +548,7 @@ int ftdi_usb_open_dev(struct ftdi_context *ftdi,
libusb_device *dev)
// Likely scenario is a static ftdi_sio kernel module.
if (ftdi->module_detach_mode == AUTO_DETACH_SIO_MODULE)
{
-if (libusb_detach_kernel_driver(ftdi->usb_dev, ftdi->interface) !=0)
+if (libusb_set_auto_detach_kernel_driver(ftdi->usb_dev, 1))
detach_errno = errno;
}
--
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 3/8][v3]usb:fsl:otg: Add support to add/remove usb host driver
> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Thursday, August 20, 2015 7:40 PM
> To: Mehresh Ramneek-B31383
> Cc: linux-ker...@vger.kernel.org; ba...@ti.com;
> gre...@linuxfoundation.org; linux-usb@vger.kernel.org; Li Yang-Leo-R58472
>
> Subject: RE: [PATCH 3/8][v3]usb:fsl:otg: Add support to add/remove usb
> host driver
>
> On Thu, 20 Aug 2015, Ramneek Mehresh wrote:
>
> > > > --- a/drivers/usb/host/ehci-fsl.h
> > > > +++ b/drivers/usb/host/ehci-fsl.h
> > > > @@ -63,4 +63,22 @@
> > > > #define UTMI_PHY_EN (1<<9)
> > > > #define ULPI_PHY_CLK_SEL(1<<10)
> > > > #define PHY_CLK_VALID (1<<17)
> > > > +
> > > > +struct ehci_fsl {
> > > > +#ifdef CONFIG_PM
> > > > + /* Saved USB PHY settings, need to restore after deep sleep. */
> > > > + u32 usb_ctrl;
> > > > +#endif
> > >
> > > Do you need this #ifdef?
> > >
> > Yes, this is required for deep-sleep support...we need to save/restore
> controller
> > registers during deep-sleep when usb controller power is shut-off. Don't
> need this
> > during normal usb operation...saving/restoring usb controller registers in
> non deep-sleep
> > scenario will add unnecessary delays
>
> What I meant was, can you keep the "u32 usb_ctrl;" line but get rid of
> the "#ifdef CONFIG_PM" and "#endif" lines?
>
> Alan Stern
I do understand that. However, USB suspend/resume functionality work in context
of
PM. Only in this context, we need to save/restore usb controller register
for deep-sleep functionality. If you see usage of this in ehci-fsl.c file, it's
used in
ehci_fsl_drv_suspend() under CONFIG_PM to save USB CNTL register.
If I remove CONFIG_PM from struct ehci_fsl{}, I'll need to change the entire
driver
also to make suspend and resume functionalities compile by default.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some restrictions when using usbtest and g_zero
On Fri, Aug 21, 2015 at 10:16:30AM -0400, Alan Stern wrote:
> On Fri, 21 Aug 2015, Peter Chen wrote:
>
> > Thanks, Alan and Felipe.
> >
> > My problem should be the chipidea udc driver does not support functional
> > stall well, it fixes the handling between functional and protocol stall.
> >
> > My understanding for these two stalls:
> >
> > - Functional stall, the host stalls the endpoints through SET_FEATURE
> > by ep0, the ep0 does not recommend to support functional stall from
> > the spec. The device should always set stall for this endpoint, and
> > return success for it.
>
> That's almost right. I just checked the USB spec to make sure (section
> 8.4.5). A functional stall occurs whenever the endpoint's HALT feature
> is set. This could be caused the host sending a Set-Halt request, _or_
> it could be caused by the device's firmware (for example, by a call to
> usb_ep_set_halt()). Either way, the endpoint continues to stall until
> the host sends a Clear-Halt request.
>
> (And yes, the spec recommends that devices should not set the HALT
> feature for ep0. If they do, it is undefined whether the device will
> respond to a Clear-Halt request!)
>
> > - Protocol stall, if the endpoint doesn't support one request, it can
> > stall itself. If there is an IN request on this endpoint, it should
> > not do stall, and return error.
>
> Protocol stalls occur only on control endpoints; they indicate the
> device does not understand or cannot carry out a control request. They
> are automatically cleared the next time a Setup packet arrives.
>
> So if you're talking about a bulk/interrupt endpoint, the only kind of
> stall you have to worry about is a functional stall. The host can
> cause a functional stall at any time by sending Set-Halt. The gadget
> driver can also cause a functional stall, but it makes no sense to do
> so while it is in the middle of transferring data to/from the host.
> For this reason, usb_ep_set_halt() always returns an error if the
> endpoint queue or the FIFO is non-empty.
>
Thanks, that's much clear.
At udc driver:
__set_halt(struct usb_ep *ep, int value, bool may_fail)
{
if (may_fail && ep queue is not empty) {
return false
} else {
do stall;
return true;
}
}
gadget_ops:
.set_halt = ep_set_halt,
ep_set_halt(struct usb_ep *ep, int value)
{
__set_halt(ep, value, true);
}
And call __set_halt(ep, value, false) at below conditions:
- SET(CLEAR)_FEATURE for Set(Clear)-Halt
- If ep0 request has failed
Do we need to update kernel doc for usb_ep_set_halt that
say it should only for bulk and interrupt endpoints?
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
