Re: [PATCH v2 Resend 9/9] usb: add usb_device_allow_power_off() function.
On Saturday 05 January 2013 13:58:27 Alan Stern wrote:
> > static int inline usb_device_prevent_power_off(struct usb_device *udev)
> > {
> > struct device *dev = usb_get_port_dev(udev);
> >
> > if(!dev)
> > return -ENODEV;
> >
> > return pm_runtime_get_sync(dev);
> > }
> >
> > usb_get_port_dev() locates in the driver/usb/core/port.c and
> > usb_device_allow/prevent_power_off() locate in the include/linux/usb.h.
>
> I was thinking more of something like this. In port.c:
>
> int usb_device_allow_prevent_power_off(struct usb_device *udev, bool allow)
> {
> ...
> }
Please change the name. It looks like a contradiction in itself and would
thereby almost beg for misuse.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usbnet: allow status interrupt URB to always be active
On Saturday 05 January 2013 11:59:16 Bjørn Mork wrote: Hi, > You can still use a trick similar to what qmi_wwan and cdc_mbim does to > take over the status endpoint from usbnet: By not implementing .status, > and possibly setting dev->status to NULL in .bind, you are free to > handle the status endpoint entirely inside the minidriver. Not sure if > that is smart though. You would have to reimplement init_status and > intr_complete from usbnet, and kill or resubmit the interrupt urb on > suspend/resume/disconnect yourself. Please no. We don't look for ways to circumvent frameworks. We alter frameworks to act as we need them to act. > The new usbnet flag is probably a better solution. Indeed. > FWIW, I agree with Oliver that always submitting the interrupt URB is > both risky and will cause too much unnecessary USB activity for most > usbnet devices. Good. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is it possible to load usb gadget mass storage driver as module(.ko)
On 12/31/2012 07:36 AM, Greg KH wrote:
i am using cypress mass storage driver (in path
/drivers/staging/westbridge/ben../gadget/cywbgadget.c )
That driver is very strange, and I don't even know if it works or not.
You should contact the authors of it for any help you need with it, as
no one else that I know of can even build that code, let alone run it.
I converted the driver in d8bfbf6e ("staging/westbridge: convert
cyasgadget to new udc core") and did a compile test.
It's also marked to be removed from the kernel source tree in a release
or so, so if you are using it, please work with the developers to get it
cleaned up and moved to the proper location in the kernel source tree
(out of drivers/staging/) so that the whole community can help out with
it.
My patch has been applied and the removal of westbridge has been
applied later in 78f23926dff9 ("Staging: delete westbridge code"). Both
patches appeared for the first time in v3.1-rc1. So I guess the best
thing to do (if someone plans to work on this) would be to get git and
revert the removal commit.
thanks,
greg k-h
Sebastian
--
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
usb: multi phy support
Hi Felipe, AM335x SoC's used in boards like beagle bone has two instances of USB modules (2.0) at the hardware level, each having a dedicated phy. Currently in mainline, only one instance of USB is supported (including a fix in your latest pull request). To support multi instance, the biggest obstacle is lack of multi phy support for usb phy's of same type. Earlier Kishon was working on usb phy device tree support, later it was seen that generic phy layer was preferred. And Kishon posted a couple of versions on generic phy framework, latest being on 26th September 2012, but I could not see follow up's on that series. It seems Kishon is not now working on generic phy support. Let me know your opinion/suggestions on supporting usb phy's of same type. We are trying to get multi USB instance support in mainline for AM335x. Regards Afzal
Re: usb: multi phy support
Hi, On Mon, Jan 07, 2013 at 12:57:15PM +0100, Mohammed, Afzal wrote: > AM335x SoC's used in boards like beagle bone has two instances of USB > modules (2.0) at the hardware level, each having a dedicated phy. > Currently in mainline, only one instance of USB is supported > (including a fix in your latest pull request). To support multi > instance, the biggest obstacle is lack of multi phy support for > usb phy's of same type. > > Earlier Kishon was working on usb phy device tree support, later it was > seen that generic phy layer was preferred. And Kishon posted a couple of > versions on generic phy framework, latest being on 26th September 2012, > but I could not see follow up's on that series. > > It seems Kishon is not now working on generic phy support. Let me know > your opinion/suggestions on supporting usb phy's of same type. We are > trying to get multi USB instance support in mainline for AM335x. Kishon is still working on generic PHY layer indeed. Right Kishon ? I believe he should be sending some newer version soonish... -- balbi signature.asc Description: Digital signature
Re: usb: multi phy support
Hi, On Monday 07 January 2013 05:30 PM, Felipe Balbi wrote: Hi, On Mon, Jan 07, 2013 at 12:57:15PM +0100, Mohammed, Afzal wrote: AM335x SoC's used in boards like beagle bone has two instances of USB modules (2.0) at the hardware level, each having a dedicated phy. Currently in mainline, only one instance of USB is supported (including a fix in your latest pull request). To support multi instance, the biggest obstacle is lack of multi phy support for usb phy's of same type. Earlier Kishon was working on usb phy device tree support, later it was seen that generic phy layer was preferred. And Kishon posted a couple of versions on generic phy framework, latest being on 26th September 2012, but I could not see follow up's on that series. It seems Kishon is not now working on generic phy support. Let me know your opinion/suggestions on supporting usb phy's of same type. We are trying to get multi USB instance support in mainline for AM335x. Kishon is still working on generic PHY layer indeed. Right Kishon ? Yes. I'll try and send it ASAP. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usbnet: allow status interrupt URB to always be active
On Sat, 2013-01-05 at 11:59 +0100, Bjørn Mork wrote: > Dan Williams writes: > > On Fri, 2013-01-04 at 23:16 +0100, Oliver Neukum wrote: > >> On Friday 04 January 2013 10:48:16 Dan Williams wrote: > >> > Some drivers (ex sierra_net) need the status interrupt URB > >> > active even when the device is closed, because they receive > >> > custom indications from firmware. Allow sub-drivers to set > >> > a flag that submits the status interrupt URB on probe and > >> > keeps the URB alive over device open/close. The URB is still > >> > killed/re-submitted for suspend/resume, as before. > >> > > >> > Signed-off-by: Dan Williams > >> > --- > >> > Oliver: alternatively, is there a problem with *always* > >> > submitting the interrupt URB, and then simply not calling > >> > the subdriver's .status function when the netdev is > >> > closed? That would be a much simpler patch. > >> > >> That is quite radical. We have no idea what a device > >> does when we do not react to a status update. I would > >> much prefer to not take the risk. > >> Besides, we don't use bandwidth if we don't have to. > > > > Ok, so scratch the alternative. Thus, does the posted patch look like > > the right course of action? > > > > If I wasn't clear enough before, sierra_net needs to listen to the > > status interrupt URB to receive the custom Restart indication as part of > > the driver's device setup. Thus for sierra_net at least, tying the > > status interrupt URB submission to device open/close isn't right. > > > > I'd previously done a patch to handle this all in sierra_net, but the > > problem there is suspend/resume: without directly accessing the usbnet > > structure's ->suspend_count member (icky!) sierra_net can't correctly > > kill/submit the URB itself. So I went with a flag to usbnet that Sierra > > can set. > > Just a few random thoughts... > > The sierra_net driver would have been an excellent candidate for the > cdc-wdm subdriver model if that had existed when sierra_net was written. > I assume the current driver only implements a minimal subset of the > DirectIP HIP protocol embedded in CDC, and exporting this to userspace > instead would have made it possible to extend that support without > changing the driver, in addtion to making the driver much more robust > against firmware differences. It would have eliminated the problem you > are facing and removed the minidriver workqueue complexity. > > But I guess it's too late to change this now. In theory we could > implement the cdc-wdm hooks that were initially proposed for cdc_mbim > and rewrite sierra_net to use it while being backwards compatible. > Don't think anyone wants to do either, so forget about it... > > You can still use a trick similar to what qmi_wwan and cdc_mbim does to > take over the status endpoint from usbnet: By not implementing .status, > and possibly setting dev->status to NULL in .bind, you are free to > handle the status endpoint entirely inside the minidriver. Not sure if > that is smart though. You would have to reimplement init_status and > intr_complete from usbnet, and kill or resubmit the interrupt urb on > suspend/resume/disconnect yourself. That was exactly the approach of my first patch. But that was icky because we need to also track suspend/resume state by looking at internal members of usbnet's structure. Yes, it's specific to Sierra, but it's pretty much a layer violation. So I went with the flag approach. Dan > The new usbnet flag is probably a better solution. > > FWIW, I agree with Oliver that always submitting the interrupt URB is > both risky and will cause too much unnecessary USB activity for most > usbnet devices. > > > Bjørn > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Linux USB file storage gadget with new UDC
On Mon, 7 Jan 2013, victor yeo wrote: > Yes, usbmon requires usb host side support (i enable them both to use > usbmon). So i disable the usbmon and usb host side support in > menuconfig. Then i rebuild linux again. Subsequently, the /sys/bus > does not contain usb folder. > > # ls /sys/bus/ > clocksource cpu mmc platform sdio spi For testing purposes, you probably should use a Linux host. Then you could use usbmon on the host to see what's happening, and there would be more debugging options available. > > Did you enable the two debugging options in file_storage.c? And did > > you remember to enable CONFIG_USB_GADGET_DEBUG in the kernel > > configuration? What shows up in the dmesg log? > > Yes, i enable the CONFIG_USB_GADGET_DEBUG and the VERBOSE_DEBUG and > DUMP_MSGS in file_storage.c. In dmesg log, there are lot of entries > recorded during usb gadget enumeration with host PC. After gadget > receives "get MAX LUN", the enumeration process gets repeated. Is this > the problem?? Please see the dmesg log below. This log looks oddly incomplete. A lot of debugging messages are missing. > g_file_storage gadget: ep0-setup, length 8: > : 80 06 00 01 00 00 40 00 > g_file_storage gadget: get device descriptor For example, right here we should see the device descriptor data that was sent back to the host. > g_file_storage gadget: ep0-setup, length 8: > : 80 06 00 01 00 00 12 00 > g_file_storage gadget: get device descriptor > g_file_storage gadget: ep0-setup, length 8: > : 80 06 00 02 00 00 ff 00 > g_file_storage gadget: get configuration descriptor > g_file_storage gadget: ep0-setup, length 8: > : 80 06 00 03 00 00 ff 00 > g_file_storage gadget: get string descriptor > g_file_storage gadget: ep0-setup, length 8: > : 80 06 02 03 09 04 ff 00 > g_file_storage gadget: get string descriptor > g_file_storage gadget: ep0-setup, length 8: > : 80 06 00 06 00 00 0a 00 > g_file_storage gadget: get device qualifier > g_file_storage gadget: ep0-setup, length 8: > : 80 06 00 01 00 00 12 00 > g_file_storage gadget: get device descriptor > g_file_storage gadget: ep0-setup, length 8: > : 80 06 00 02 00 00 09 00 > g_file_storage gadget: get configuration descriptor > g_file_storage gadget: ep0-setup, length 8: > : 80 06 00 02 00 00 20 00 > g_file_storage gadget: get configuration descriptor > > g_file_storage gadget: ep0-setup, length 8: > : 00 09 01 00 00 00 00 00 > g_file_storage gadget: set configuration > g_file_storage gadget: set interface 0 > g_file_storage gadget: high-speed config #1 > > g_file_storage gadget: ep0-setup, length 8: > : a1 fe 00 00 00 00 01 00 > g_file_storage gadget: get max LUN > > g_file_storage gadget: ep0-setup, length 8: > : 80 06 01 03 09 04 ff 00 > g_file_storage gadget: get string descriptor > > g_file_storage gadget: ep0-setup, length 8: > : 80 06 04 03 09 04 ff 00 > g_file_storage gadget: get string descriptor > > g_file_storage gadget: ep0-setup, length 8: > : 80 06 05 03 09 04 ff 00 > g_file_storage gadget: get string descriptor > > g_file_storage gadget: ep0-setup, length 8: > : 80 06 00 01 00 00 40 00 > g_file_storage gadget: get device descriptor > . Where does the enumeration repeat? I don't see any repeats here, aside from the fact that Windows asks for the same device and config descriptors a few times. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usbnet: allow status interrupt URB to always be active
On Sat, 2013-01-05 at 12:01 +0100, Oliver Neukum wrote: > On Friday 04 January 2013 19:26:33 Dan Williams wrote: > > On Fri, 2013-01-04 at 23:16 +0100, Oliver Neukum wrote: > > > On Friday 04 January 2013 10:48:16 Dan Williams wrote: > > > > Some drivers (ex sierra_net) need the status interrupt URB > > > > active even when the device is closed, because they receive > > > > custom indications from firmware. Allow sub-drivers to set > > > > a flag that submits the status interrupt URB on probe and > > > > keeps the URB alive over device open/close. The URB is still > > > > killed/re-submitted for suspend/resume, as before. > > > > > > > > Signed-off-by: Dan Williams > > > > --- > > > > Oliver: alternatively, is there a problem with *always* > > > > submitting the interrupt URB, and then simply not calling > > > > the subdriver's .status function when the netdev is > > > > closed? That would be a much simpler patch. > > > > > > That is quite radical. We have no idea what a device > > > does when we do not react to a status update. I would > > > much prefer to not take the risk. > > > Besides, we don't use bandwidth if we don't have to. > > > > Ok, so scratch the alternative. Thus, does the posted patch look like > > the right course of action? > > In principle yes. > > > If I wasn't clear enough before, sierra_net needs to listen to the > > status interrupt URB to receive the custom Restart indication as part of > > the driver's device setup. Thus for sierra_net at least, tying the > > status interrupt URB submission to device open/close isn't right. > > So, there seems to be an inevitable race before probe() is called. Yeah, you're right, we need Sierra to send the SYNC message *after* bind is called.Is there an existing "after bind" hook or do we need to create one? > Have you looked at FLAG_AVOID_UNLINK_URBS ? Not yet, but I will. Thanks, Dan > > I'd previously done a patch to handle this all in sierra_net, but the > > problem there is suspend/resume: without directly accessing the usbnet > > structure's ->suspend_count member (icky!) sierra_net can't correctly > > kill/submit the URB itself. So I went with a flag to usbnet that Sierra > > can set. > > That is absolutely the right way to do it. > > Regards > Oliver > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" 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: usb serial driver: private data already deallocated when release function is called
On Mon, 7 Jan 2013, Tilman wrote: > Hello > > I am porting a usb test driver from kernel version 3.0.8 to > kernel version 3.7.1. > > The release function was working on V3.0.0. On V3.7.1, the > private data stored in serial->port.device->p->driver_data > seems already to be deallocated (or never correctly be > allocated): usb_get_serial_port_data returns a null pointer. There were changes to almost all of the serial drivers in that time period. The problem was that they were using their release method to do work that needed to be done in the port_remove method. > Is there any function as part of the usb kernel framework > that releases the private data before calling the release > function ? Nope, your driver has to do that in its port_remove method. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] USB: OHCI: Fix definition overriding while registering Exynos OHCI driver
On Mon, 7 Jan 2013, Sachin Kamat wrote: > Exynos OHCI driver does not get registered if generic OHCI driver > is also selected as the macro PLATFORM_DRIVER gets re-defined to > 'ohci_platform_driver' instead of 'exynos_ohci_driver'. Hence define > it separately. > > Also, silences the following compilation warnings: > drivers/usb/host/ohci-hcd.c:1191:0: warning: > "PLATFORM_DRIVER" redefined [enabled by default] > drivers/usb/host/ohci-hcd.c:1110:0: note: > this is the location of the previous definition > drivers/usb/host/ohci-exynos.c:276:31: warning: > ‘exynos_ohci_driver’ defined but not used [-Wunused-variable] Why are you selecting both the Exynos and generic OHCI drivers at the same time? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] USB: OHCI: Fix definition overriding while registering Exynos OHCI driver
On Mon, 7 Jan 2013, Sachin Kamat wrote: > On Monday, 7 January 2013, Alan Stern wrote: > > On Mon, 7 Jan 2013, Sachin Kamat wrote: > > > >> Exynos OHCI driver does not get registered if generic OHCI driver > >> is also selected as the macro PLATFORM_DRIVER gets re-defined to > >> 'ohci_platform_driver' instead of 'exynos_ohci_driver'. Hence define > >> it separately. > >> > >> Also, silences the following compilation warnings: > >> drivers/usb/host/ohci-hcd.c:1191:0: warning: > >> "PLATFORM_DRIVER" redefined [enabled by default] > >> drivers/usb/host/ohci-hcd.c:1110:0: note: > >> this is the location of the previous definition > >> drivers/usb/host/ohci-exynos.c:276:31: warning: > >> �exynos_ohci_driver� defined but not used [-Wunused-variable] > > > > Why are you selecting both the Exynos and generic OHCI drivers at the > > same time? > > > I was experimenting selecting generic since that option is still available > after selecting Exynos. In case of other drivers like Omap, it worked > whereas in case of exynos it got overridden. Hence the patch to make it > behave like other drivers. I don't know what the OMAP driver does this differently. The only real reason would be if a board had two distinct kinds of OHCI controllers. If the Exynos board doesn't, the simplest approach is to change the Kconfig file so as to make USB_OHCI_EXYNOS mutually exclusive with USB_OHCI_HCD_PLATFORM. However, I would much prefer to see a more general solution, like the one that was recently merged for EHCI. Convert ohci-hcd into a platform-independent library module, and make ohci-exynos, ohci-omap, and so on into separate driver modules that use the library's facilities. I believe Manjunath Goudar may already be working on this, under Deepak Saxena. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 22/25] usb/at91_udc: don't use [delayed_]work_pending()
On 12/22/2012 02:57 AM, Tejun Heo : > There's no need to test whether a (delayed) work item in pending > before queueing, flushing or cancelling it. Most uses are unnecessary > and quite a few of them are buggy. > > Remove unnecessary pending tests from at91_udc. Only compile tested. > > Signed-off-by: Tejun Heo > Cc: Andrew Victor > Cc: Nicolas Ferre Acked-by: Nicolas Ferre > Cc: Jean-Christophe Plagniol-Villard > Cc: Felipe Balbi > Cc: linux-usb@vger.kernel.org > --- > Please let me know how this patch should be routed. I can take it > through the workqueue tree if necessary. > > Thanks. > > drivers/usb/gadget/at91_udc.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c > index f4a21f6..e81d8a2 100644 > --- a/drivers/usb/gadget/at91_udc.c > +++ b/drivers/usb/gadget/at91_udc.c > @@ -1621,8 +1621,7 @@ static void at91_vbus_timer(unsigned long data) >* bus such as i2c or spi which may sleep, so schedule some work >* to read the vbus gpio >*/ > - if (!work_pending(&udc->vbus_timer_work)) > - schedule_work(&udc->vbus_timer_work); > + schedule_work(&udc->vbus_timer_work); > } > > static int at91_start(struct usb_gadget *gadget, > -- Nicolas Ferre -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] USB: gadget: at91_adc: fix pullup pin validity check
On 12/23/2012 07:08 PM, Jean-Christophe PLAGNIOL-VILLARD :
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
Acked-by: Nicolas Ferre
> Cc: linux-usb@vger.kernel.org
> ---
> drivers/usb/gadget/at91_udc.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c
> index 89d90b5..888cb2a 100644
> --- a/drivers/usb/gadget/at91_udc.c
> +++ b/drivers/usb/gadget/at91_udc.c
> @@ -1739,7 +1739,7 @@ static int __devinit at91udc_probe(struct
> platform_device *pdev)
>
> /* rm9200 needs manual D+ pullup; off by default */
> if (cpu_is_at91rm9200()) {
> - if (gpio_is_valid(udc->board.pullup_pin)) {
> + if (!gpio_is_valid(udc->board.pullup_pin)) {
> DBG("no D+ pullup?\n");
> retval = -ENODEV;
> goto fail0;
>
--
Nicolas Ferre
--
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: musb: ux500: use clk_prepare_enable and clk_disable_unprepare
This patch converts the module to use clk_prepare_enable and
clk_disable_unprepare variants as required by common clock framework.
Without this the system crash during probe function.
Signed-off-by: Fabio Baltieri
---
drivers/usb/musb/ux500.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c
index a27ca1a..0804661 100644
--- a/drivers/usb/musb/ux500.c
+++ b/drivers/usb/musb/ux500.c
@@ -108,7 +108,7 @@ static int ux500_probe(struct platform_device *pdev)
goto err3;
}
- ret = clk_enable(clk);
+ ret = clk_prepare_enable(clk);
if (ret) {
dev_err(&pdev->dev, "failed to enable clock\n");
goto err4;
@@ -148,7 +148,7 @@ static int ux500_probe(struct platform_device *pdev)
return 0;
err5:
- clk_disable(clk);
+ clk_disable_unprepare(clk);
err4:
clk_put(clk);
@@ -168,7 +168,7 @@ static int ux500_remove(struct platform_device *pdev)
struct ux500_glue *glue = platform_get_drvdata(pdev);
platform_device_unregister(glue->musb);
- clk_disable(glue->clk);
+ clk_disable_unprepare(glue->clk);
clk_put(glue->clk);
kfree(glue);
@@ -182,7 +182,7 @@ static int ux500_suspend(struct device *dev)
struct musb *musb = glue_to_musb(glue);
usb_phy_set_suspend(musb->xceiv, 1);
- clk_disable(glue->clk);
+ clk_disable_unprepare(glue->clk);
return 0;
}
@@ -193,7 +193,7 @@ static int ux500_resume(struct device *dev)
struct musb *musb = glue_to_musb(glue);
int ret;
- ret = clk_enable(glue->clk);
+ ret = clk_prepare_enable(glue->clk);
if (ret) {
dev_err(dev, "failed to enable clock\n");
return ret;
--
1.7.12.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 v4 0/6] support other fsl SoCs with usbmisc + small fixes
Hi Alexander, On Wed, Nov 28, 2012 at 12:52 AM, Peter Chen wrote: > I have tested it at i.mx6q sabrelite board, it works good. > > I have pushed your commit to my git, please cc me > your coming chipidea patches, thanks. > > Alex, please add: > > Reviewed-by: Peter Chen > Tested-by: Peter Chen Could this series be applied, please? -- 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: [GIT PULL] USB fixes for v3.8-rc2
On Thu, Dec 13, 2012 at 04:58:36PM +0200, Felipe Balbi wrote: > Hi Greg, > > Here's my first set of fixes for this -rc cycle. Let me > know if you want any changes to this pull request. > > I'm basing it off of Linus' current master as there are no > tags yet. If you want to wait until -rc1 is tagged, I can easily > rebase. > > cheers > > The following changes since commit 6be35c700f742e911ecedd07fcc43d4439922334: > > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next > (2012-12-12 18:07:07 -0800) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > tags/fixes-for-v3.8-rc2 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Pull Request] usb-linus: USB core fixes for warm reset
On Thu, Jan 03, 2013 at 02:28:08PM -0800, Sarah Sharp wrote: > The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565: > > Linux 3.8-rc1 (2012-12-21 17:19:00 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git > for-usb-linus-2013-01-03 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Pull Request] usb-next: Further warm reset improvements
On Thu, Jan 03, 2013 at 02:28:30PM -0800, Sarah Sharp wrote: > The following changes since commit c52804a472649b2e5005342308739434cbd51119: > > xhci: Avoid "dead ports", add roothub port polling. (2013-01-03 14:10:29 > -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git > for-usb-next-2013-01-03 I've merged usb-linus into usb-next and pulled this into usb-next as well. Let me know if I messed anything up. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Pull Request] usb-next: Further warm reset improvements
On Mon, Jan 07, 2013 at 10:16:00AM -0800, Greg Kroah-Hartman wrote: > On Thu, Jan 03, 2013 at 02:28:30PM -0800, Sarah Sharp wrote: > > The following changes since commit c52804a472649b2e5005342308739434cbd51119: > > > > xhci: Avoid "dead ports", add roothub port polling. (2013-01-03 14:10:29 > > -0800) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git > > for-usb-next-2013-01-03 > > I've merged usb-linus into usb-next and pulled this into usb-next as > well. Let me know if I messed anything up. Looks fine, thanks! Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 7/9] usb: add usb port auto power off mechanism
On Sun, 6 Jan 2013, Lan Tianyu wrote:
> This patch is to add usb port auto power off mechanism.
> When usb device is suspending, usb core will suspend usb port and
> usb port runtime pm callback will clear PORT_POWER feature to
> power off port if all conditions were met. These conditions are
> remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist
> enable. When it resumes, power on port again. Add did_runtime_put
> in the struct usb_port in order to call pm_runtime_get/put(portdev)
> paired during suspending and resuming.
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1509,7 +1525,6 @@ static void hub_disconnect(struct usb_interface *intf)
> kfree(hub->status);
> kfree(hub->buffer);
>
> - pm_suspend_ignore_children(&intf->dev, false);
> kref_put(&hub->kref, hub_release);
> }
This looks like a mistake. Either that line shouldn't have been added
in the first place or else it shouldn't be removed here.
> @@ -1940,7 +1955,8 @@ void usb_disconnect(struct usb_device **pdev)
> sysfs_remove_link(&udev->dev.kobj, "port");
> sysfs_remove_link(&port_dev->dev.kobj, "device");
>
> - pm_runtime_put(&port_dev->dev);
> + if (!port_dev->did_runtime_put)
> + pm_runtime_put(&port_dev->dev);
> }
You need to set port_dev->did_runtime_put to false here, so that it
will have the correct value the next time a device is plugged into the
port.
> --- a/drivers/usb/core/hub.h
> +++ b/drivers/usb/core/hub.h
> @@ -80,6 +80,8 @@ struct usb_hub {
> * @port_owner: port's owner
> * @connect_type: port's connect type
> * @portnum: port index num based one
> + * @power_is_on: port's power state
> + * @did_runtime_put: port has done pm_runtime_put().
> */
> struct usb_port {
> struct usb_device *child;
> @@ -87,6 +89,8 @@ struct usb_port {
> struct dev_state *port_owner;
> enum usb_port_connect_type connect_type;
> u8 portnum;
> + bool power_is_on;
> + bool did_runtime_put;
> };
Should these be power_is_on:1 and did_runtime_put:1?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 8/9] usb: expose usb port's pm qos flags to user space
On Sun, 6 Jan 2013, Lan Tianyu wrote:
> This patch is to expose usb port's pm qos flags(pm_qos_no_power_off,
> pm_qos_remote_wakeup) to user space. User can set pm_qos_no_power_off
> flag to prohibit the port from being power off.
> @@ -165,8 +166,12 @@ int usb_hub_create_port_device(struct usb_hub *hub, int
> port1)
> if (retval)
> goto error_register;
>
> - pm_runtime_set_active(&port_dev->dev);
> - pm_runtime_enable(&port_dev->dev);
> + if (!dev_pm_qos_expose_flags(&port_dev->dev,
> + PM_QOS_FLAG_NO_POWER_OFF)) {
> + pm_runtime_set_active(&port_dev->dev);
> + pm_runtime_enable(&port_dev->dev);
> + }
I don't understand this. Why does this code need to be conditional?
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
[RFC PATCH 5/6] Kconfig and Makefile for the DWC2 driver
Signed-off-by: Paul Zimmerman --- drivers/usb/dwc2/Kconfig | 25 + drivers/usb/dwc2/Makefile | 13 + 2 files changed, 38 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/dwc2/Kconfig create mode 100644 drivers/usb/dwc2/Makefile diff --git a/drivers/usb/dwc2/Kconfig b/drivers/usb/dwc2/Kconfig new file mode 100644 index 000..08f33bc --- /dev/null +++ b/drivers/usb/dwc2/Kconfig @@ -0,0 +1,25 @@ +config USB_DWC2 + tristate "DesignWare USB2 DRD Core Support" + depends on (USB && USB_GADGET) + select USB_OTG_UTILS + help + Say Y or M here if your system has a Dual Role HighSpeed + USB controller based on the DesignWare HSOTG IP Core. + + If you choose to build this driver as a dynamically linked + module, the module will be called dwc2_pci.ko. + +if USB_DWC2 + +config USB_DWC2_DEBUG + bool "Enable Debugging Messages" + help + Say Y here to enable debugging messages in DWC2 Driver. + +config USB_DWC2_VERBOSE + bool "Enable Verbose Debugging Messages" + depends on USB_DWC2_DEBUG + help + Say Y here to enable verbose debugging messages in DWC2 Driver. + +endif diff --git a/drivers/usb/dwc2/Makefile b/drivers/usb/dwc2/Makefile new file mode 100644 index 000..fad5f1b --- /dev/null +++ b/drivers/usb/dwc2/Makefile @@ -0,0 +1,13 @@ +ccflags-$(CONFIG_USB_DWC2_DEBUG) += -DDEBUG +ccflags-$(CONFIG_USB_DWC2_VERBOSE) += -DVERBOSE +ccflags-y += -DDWC_HOST_ONLY + +ccflags-y += -Idrivers/usb/gadget + +obj-$(CONFIG_USB_DWC2) += dwc2_pci.o + +dwc2_pci-y += core.o core_intr.o +dwc2_pci-y += hcd.o hcd_intr.o +dwc2_pci-y += hcd_queue.o hcd_ddma.o + +dwc2_pci-y += pci.o -- 1.7.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
[RFC PATCH 0/6] DWC2 DesignWare HS OTG driver
Resending due to screwup in To: address line Hi Felipe, Ben, This is a host-mode driver for the Synopsys DesignWare HS OTG controller. This is the same controller whose peripheral mode is implemented by the existing s3c-hsotg driver. The idea is to add a dwc2/ directory alongside the existing dwc3/ directory, initially to contain just this host-mode driver. Once that has been accepted we would then like to move the s3c-hsotg driver into this directory and integrate it to make a dual-role driver. Finally we would implement support for the OTG features of the controller. This driver is still a work in progress, to wit: - Only Control and Bulk transfer types have been tested so far, using the mass-storage gadget. - Only a PCI bus interface has been implemented so far. However all the PCI specific code is isolated to a single file, so it should be fairly easy to add a platform device interface. - The driver has a couple dozen module parameters to control various optional features of the controller. I realize module parameters are frowned upon these days, so I would appreciate any advice on the best way to implement these in an acceptable manner. - There is no power-management support yet. - There is some code present to implement DRD and OTG support, but it is incomplete due to the missing peripheral-mode code. - There is quite a bit of debug code included. I would like to keep that until the integration with s3c-hsotg is complete, then most of it can be stripped out. The patches are checkpatch clean, except for boatloads of camel-case warnings due to the reuse of s3c-hsotg.h for the register definitions. Comments? Questions? -- Paul Zimmerman (6): Core files for the DWC2 driver HCD files for the DWC2 driver HCD descriptor DMA support for the DWC2 driver PCI bus interface for the DWC2 driver Kconfig and Makefile for the DWC2 driver Hook the DWC2 driver into the build system drivers/usb/Kconfig |2 + drivers/usb/Makefile |2 + drivers/usb/dwc2/Kconfig | 25 + drivers/usb/dwc2/Makefile| 13 + drivers/usb/dwc2/core.c | 2533 +++ drivers/usb/dwc2/core.h | 745 +++ drivers/usb/dwc2/core_intr.c | 726 ++ drivers/usb/dwc2/hcd.c | 3014 ++ drivers/usb/dwc2/hcd.h | 1134 drivers/usb/dwc2/hcd_ddma.c | 1168 drivers/usb/dwc2/hcd_intr.c | 2029 drivers/usb/dwc2/hcd_queue.c | 749 +++ drivers/usb/dwc2/hw.h| 512 +++ drivers/usb/dwc2/pci.c | 591 + 14 files changed, 13243 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/dwc2/Kconfig create mode 100644 drivers/usb/dwc2/Makefile create mode 100644 drivers/usb/dwc2/core.c create mode 100644 drivers/usb/dwc2/core.h create mode 100644 drivers/usb/dwc2/core_intr.c create mode 100644 drivers/usb/dwc2/hcd.c create mode 100644 drivers/usb/dwc2/hcd.h create mode 100644 drivers/usb/dwc2/hcd_ddma.c create mode 100644 drivers/usb/dwc2/hcd_intr.c create mode 100644 drivers/usb/dwc2/hcd_queue.c create mode 100644 drivers/usb/dwc2/hw.h create mode 100644 drivers/usb/dwc2/pci.c -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/6] DWC2 DesignWare HS OTG driver
Hi Felipe, Ben, This is a host-mode driver for the Synopsys DesignWare HS OTG controller. This is the same controller whose peripheral mode is implemented by the existing s3c-hsotg driver. The idea is to add a dwc2/ directory alongside the existing dwc3/ directory, initially to contain just this host-mode driver. Once that has been accepted we would then like to move the s3c-hsotg driver into this directory and integrate it to make a dual-role driver. Finally we would implement support for the OTG features of the controller. This driver is still a work in progress, to wit: - Only Control and Bulk transfer types have been tested so far, using the mass-storage gadget. - Only a PCI bus interface has been implemented so far. However all the PCI specific code is isolated to a single file, so it should be fairly easy to add a platform device interface. - The driver has a couple dozen module parameters to control various optional features of the controller. I realize module parameters are frowned upon these days, so I would appreciate any advice on the best way to implement these in an acceptable manner. - There is no power-management support yet. - There is some code present to implement DRD and OTG support, but it is incomplete due to the missing peripheral-mode code. - There is quite a bit of debug code included. I would like to keep that until the integration with s3c-hsotg is complete, then most of it can be stripped out. The patches are checkpatch clean, except for boatloads of camel-case warnings due to the reuse of s3c-hsotg.h for the register definitions. Comments? Questions? -- Paul Zimmerman (6): Core files for the DWC2 driver HCD files for the DWC2 driver HCD descriptor DMA support for the DWC2 driver PCI bus interface for the DWC2 driver Kconfig and Makefile for the DWC2 driver Hook the DWC2 driver into the build system drivers/usb/Kconfig |2 + drivers/usb/Makefile |2 + drivers/usb/dwc2/Kconfig | 25 + drivers/usb/dwc2/Makefile| 13 + drivers/usb/dwc2/core.c | 2533 +++ drivers/usb/dwc2/core.h | 745 +++ drivers/usb/dwc2/core_intr.c | 726 ++ drivers/usb/dwc2/hcd.c | 3014 ++ drivers/usb/dwc2/hcd.h | 1134 drivers/usb/dwc2/hcd_ddma.c | 1168 drivers/usb/dwc2/hcd_intr.c | 2029 drivers/usb/dwc2/hcd_queue.c | 749 +++ drivers/usb/dwc2/hw.h| 512 +++ drivers/usb/dwc2/pci.c | 591 + 14 files changed, 13243 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/dwc2/Kconfig create mode 100644 drivers/usb/dwc2/Makefile create mode 100644 drivers/usb/dwc2/core.c create mode 100644 drivers/usb/dwc2/core.h create mode 100644 drivers/usb/dwc2/core_intr.c create mode 100644 drivers/usb/dwc2/hcd.c create mode 100644 drivers/usb/dwc2/hcd.h create mode 100644 drivers/usb/dwc2/hcd_ddma.c create mode 100644 drivers/usb/dwc2/hcd_intr.c create mode 100644 drivers/usb/dwc2/hcd_queue.c create mode 100644 drivers/usb/dwc2/hw.h create mode 100644 drivers/usb/dwc2/pci.c -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 4/6] PCI bus interface for the DWC2 driver
Signed-off-by: Paul Zimmerman
---
drivers/usb/dwc2/pci.c | 591
1 files changed, 591 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/dwc2/pci.c
diff --git a/drivers/usb/dwc2/pci.c b/drivers/usb/dwc2/pci.c
new file mode 100644
index 000..2aef356
--- /dev/null
+++ b/drivers/usb/dwc2/pci.c
@@ -0,0 +1,591 @@
+/*
+ * pci.c - DesignWare HS OTG Controller PCI driver
+ *
+ * Copyright (C) 2004-2012 Synopsys, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following disclaimer,
+ *without modification.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The names of the above-listed copyright holders may not be used
+ *to endorse or promote products derived from this software without
+ *specific prior written permission.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation; either version 2 of the License, or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
+ * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
+ * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/*
+ * Provides the initialization and cleanup entry points for the DWC_otg PCI
+ * driver
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "core.h"
+#include "hcd.h"
+
+static const char driver_name[] = "dwc_otg";
+
+/*-*/
+/* Encapsulate the module parameter settings */
+
+struct dwc2_driver_module_params {
+ int otg_cap;
+ int dma_enable;
+ int dma_desc_enable;
+ int dma_burst_size;
+ int speed;
+ int host_support_fs_ls_low_power;
+ int host_ls_low_power_phy_clk;
+ int enable_dynamic_fifo;
+ int host_rx_fifo_size;
+ int host_nperio_tx_fifo_size;
+ int host_perio_tx_fifo_size;
+ int max_transfer_size;
+ int max_packet_count;
+ int host_channels;
+ int phy_type;
+ int phy_utmi_width;
+ int phy_ulpi_ddr;
+ int phy_ulpi_ext_vbus;
+ int i2c_enable;
+ int ulpi_fs_ls;
+ int ts_dline;
+ int en_multiple_tx_fifo;
+ int lpm_enable;
+ int ic_usb_cap;
+ int reload_ctl;
+ int ahb_single;
+ int otg_ver;
+};
+
+static struct dwc2_driver_module_params dwc2_module_params = {
+ .otg_cap= 0,/* HNP/SRP capable */
+ .dma_enable = 1,
+ .dma_desc_enable= 1,
+ .dma_burst_size = 32,
+ .speed = 0,/* High Speed */
+ .host_support_fs_ls_low_power = 0,
+ .host_ls_low_power_phy_clk = 0,/* 48 MHz */
+ .enable_dynamic_fifo= 1,
+ .host_rx_fifo_size = 1024, /* 1K DWORDs */
+ .host_nperio_tx_fifo_size = 256, /* 256 DWORDs */
+ .host_perio_tx_fifo_size= 1024, /* 1K DWORDs */
+ .max_transfer_size = 65535,
+ .max_packet_count = 511,
+ .host_channels = 11,
+ .phy_type = 1,/* UTMI */
+ .phy_utmi_width = 16, /* 16 bits */
+ .phy_ulpi_ddr = 0,/* Single */
+ .phy_ulpi_ext_vbus = 0,
+ .i2c_enable = 0,
+ .ulpi_fs_ls = 0,
+ .ts_dline = 0,
+ .en_multiple_tx_fifo= 1,
+ .lpm_enable = 0,
+ .ic_usb_cap = 0,
+ .reload_ctl = 0,
+ .ahb_single = 0,
+ .otg_ve
[RFC PATCH 3/6] HCD descriptor DMA support for the DWC2 driver
Signed-off-by: Paul Zimmerman
---
drivers/usb/dwc2/hcd_ddma.c | 1168 +++
1 files changed, 1168 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/dwc2/hcd_ddma.c
diff --git a/drivers/usb/dwc2/hcd_ddma.c b/drivers/usb/dwc2/hcd_ddma.c
new file mode 100644
index 000..8e63dc3
--- /dev/null
+++ b/drivers/usb/dwc2/hcd_ddma.c
@@ -0,0 +1,1168 @@
+/*
+ * hcd_ddma.c - DesignWare HS OTG Controller descriptor DMA routines
+ *
+ * Copyright (C) 2004-2012 Synopsys, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following disclaimer,
+ *without modification.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The names of the above-listed copyright holders may not be used
+ *to endorse or promote products derived from this software without
+ *specific prior written permission.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation; either version 2 of the License, or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
+ * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
+ * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/*
+ * This file contains the Descriptor DMA implementation for Host mode
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "core.h"
+#include "hcd.h"
+
+static u16 frame_list_idx(u16 frame)
+{
+ return frame & (MAX_FRLIST_EN_NUM - 1);
+}
+
+static u16 desclist_idx_inc(u16 idx, u16 inc, u8 speed)
+{
+ return (idx + inc) &
+ ((speed == DWC2_EP_SPEED_HIGH ? MAX_DMA_DESC_NUM_HS_ISOC :
+ MAX_DMA_DESC_NUM_GENERIC) - 1);
+}
+
+static u16 desclist_idx_dec(u16 idx, u16 inc, u8 speed)
+{
+ return (idx - inc) &
+ ((speed == DWC2_EP_SPEED_HIGH ? MAX_DMA_DESC_NUM_HS_ISOC :
+ MAX_DMA_DESC_NUM_GENERIC) - 1);
+}
+
+static u16 max_desc_num(struct dwc2_qh *qh)
+{
+ return (qh->ep_type == USB_ENDPOINT_XFER_ISOC &&
+ qh->dev_speed == DWC2_EP_SPEED_HIGH)
+ ? MAX_DMA_DESC_NUM_HS_ISOC : MAX_DMA_DESC_NUM_GENERIC;
+}
+
+static u16 frame_incr_val(struct dwc2_qh *qh)
+{
+ return qh->dev_speed == DWC2_EP_SPEED_HIGH
+ ? (qh->interval + 8 - 1) / 8 : qh->interval;
+}
+
+static int desc_list_alloc(struct dwc2_hcd *hcd, struct dwc2_qh *qh,
+ gfp_t flags)
+{
+ qh->desc_list = dma_alloc_coherent(hcd->dev,
+ sizeof(struct dwc2_host_dma_desc) *
+ max_desc_num(qh), &qh->desc_list_dma, flags);
+
+ if (!qh->desc_list) {
+ dev_err(hcd->dev, "%s: DMA descriptor list allocation failed\n",
+ __func__);
+ return -ENOMEM;
+ }
+
+ memset(qh->desc_list, 0,
+ sizeof(struct dwc2_host_dma_desc) * max_desc_num(qh));
+
+ qh->n_bytes = kzalloc(sizeof(u32) * max_desc_num(qh), flags);
+ if (!qh->n_bytes) {
+ dev_err(hcd->dev,
+ "%s: Failed to allocate array for descriptors' size
actual values\n",
+ __func__);
+ dma_free_coherent(hcd->dev, sizeof(struct dwc2_host_dma_desc) *
+ max_desc_num(qh), qh->desc_list,
+ qh->desc_list_dma);
+ qh->desc_list = NULL;
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static void desc_list_free(struct dwc2_hcd *hcd, struct dwc2_qh *qh)
+{
+ if (qh->desc_list) {
+ dma_free_coherent(hcd->dev, sizeof(struct dwc2_host_dma_desc) *
+ max_desc_num(qh), qh->desc_list,
+
[RFC PATCH 4/6] PCI bus interface for the DWC2 driver
Signed-off-by: Paul Zimmerman
---
drivers/usb/dwc2/pci.c | 591
1 files changed, 591 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/dwc2/pci.c
diff --git a/drivers/usb/dwc2/pci.c b/drivers/usb/dwc2/pci.c
new file mode 100644
index 000..2aef356
--- /dev/null
+++ b/drivers/usb/dwc2/pci.c
@@ -0,0 +1,591 @@
+/*
+ * pci.c - DesignWare HS OTG Controller PCI driver
+ *
+ * Copyright (C) 2004-2012 Synopsys, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following disclaimer,
+ *without modification.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The names of the above-listed copyright holders may not be used
+ *to endorse or promote products derived from this software without
+ *specific prior written permission.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation; either version 2 of the License, or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
+ * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
+ * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/*
+ * Provides the initialization and cleanup entry points for the DWC_otg PCI
+ * driver
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "core.h"
+#include "hcd.h"
+
+static const char driver_name[] = "dwc_otg";
+
+/*-*/
+/* Encapsulate the module parameter settings */
+
+struct dwc2_driver_module_params {
+ int otg_cap;
+ int dma_enable;
+ int dma_desc_enable;
+ int dma_burst_size;
+ int speed;
+ int host_support_fs_ls_low_power;
+ int host_ls_low_power_phy_clk;
+ int enable_dynamic_fifo;
+ int host_rx_fifo_size;
+ int host_nperio_tx_fifo_size;
+ int host_perio_tx_fifo_size;
+ int max_transfer_size;
+ int max_packet_count;
+ int host_channels;
+ int phy_type;
+ int phy_utmi_width;
+ int phy_ulpi_ddr;
+ int phy_ulpi_ext_vbus;
+ int i2c_enable;
+ int ulpi_fs_ls;
+ int ts_dline;
+ int en_multiple_tx_fifo;
+ int lpm_enable;
+ int ic_usb_cap;
+ int reload_ctl;
+ int ahb_single;
+ int otg_ver;
+};
+
+static struct dwc2_driver_module_params dwc2_module_params = {
+ .otg_cap= 0,/* HNP/SRP capable */
+ .dma_enable = 1,
+ .dma_desc_enable= 1,
+ .dma_burst_size = 32,
+ .speed = 0,/* High Speed */
+ .host_support_fs_ls_low_power = 0,
+ .host_ls_low_power_phy_clk = 0,/* 48 MHz */
+ .enable_dynamic_fifo= 1,
+ .host_rx_fifo_size = 1024, /* 1K DWORDs */
+ .host_nperio_tx_fifo_size = 256, /* 256 DWORDs */
+ .host_perio_tx_fifo_size= 1024, /* 1K DWORDs */
+ .max_transfer_size = 65535,
+ .max_packet_count = 511,
+ .host_channels = 11,
+ .phy_type = 1,/* UTMI */
+ .phy_utmi_width = 16, /* 16 bits */
+ .phy_ulpi_ddr = 0,/* Single */
+ .phy_ulpi_ext_vbus = 0,
+ .i2c_enable = 0,
+ .ulpi_fs_ls = 0,
+ .ts_dline = 0,
+ .en_multiple_tx_fifo= 1,
+ .lpm_enable = 0,
+ .ic_usb_cap = 0,
+ .reload_ctl = 0,
+ .ahb_single = 0,
+ .otg_ve
[RFC PATCH 5/6] Kconfig and Makefile for the DWC2 driver
Signed-off-by: Paul Zimmerman --- drivers/usb/dwc2/Kconfig | 25 + drivers/usb/dwc2/Makefile | 13 + 2 files changed, 38 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/dwc2/Kconfig create mode 100644 drivers/usb/dwc2/Makefile diff --git a/drivers/usb/dwc2/Kconfig b/drivers/usb/dwc2/Kconfig new file mode 100644 index 000..08f33bc --- /dev/null +++ b/drivers/usb/dwc2/Kconfig @@ -0,0 +1,25 @@ +config USB_DWC2 + tristate "DesignWare USB2 DRD Core Support" + depends on (USB && USB_GADGET) + select USB_OTG_UTILS + help + Say Y or M here if your system has a Dual Role HighSpeed + USB controller based on the DesignWare HSOTG IP Core. + + If you choose to build this driver as a dynamically linked + module, the module will be called dwc2_pci.ko. + +if USB_DWC2 + +config USB_DWC2_DEBUG + bool "Enable Debugging Messages" + help + Say Y here to enable debugging messages in DWC2 Driver. + +config USB_DWC2_VERBOSE + bool "Enable Verbose Debugging Messages" + depends on USB_DWC2_DEBUG + help + Say Y here to enable verbose debugging messages in DWC2 Driver. + +endif diff --git a/drivers/usb/dwc2/Makefile b/drivers/usb/dwc2/Makefile new file mode 100644 index 000..fad5f1b --- /dev/null +++ b/drivers/usb/dwc2/Makefile @@ -0,0 +1,13 @@ +ccflags-$(CONFIG_USB_DWC2_DEBUG) += -DDEBUG +ccflags-$(CONFIG_USB_DWC2_VERBOSE) += -DVERBOSE +ccflags-y += -DDWC_HOST_ONLY + +ccflags-y += -Idrivers/usb/gadget + +obj-$(CONFIG_USB_DWC2) += dwc2_pci.o + +dwc2_pci-y += core.o core_intr.o +dwc2_pci-y += hcd.o hcd_intr.o +dwc2_pci-y += hcd_queue.o hcd_ddma.o + +dwc2_pci-y += pci.o -- 1.7.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
[RFC PATCH 6/6] Hook the DWC2 driver into the build system
Signed-off-by: Paul Zimmerman --- drivers/usb/Kconfig |2 ++ drivers/usb/Makefile |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 4c90b51..4f1c6fe 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -125,6 +125,8 @@ source "drivers/usb/core/Kconfig" source "drivers/usb/dwc3/Kconfig" +source "drivers/usb/dwc2/Kconfig" + source "drivers/usb/mon/Kconfig" source "drivers/usb/wusbcore/Kconfig" diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index f5ed3d7..efa98f7 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -10,6 +10,8 @@ obj-$(CONFIG_USB_OTG_UTILS) += otg/ obj-$(CONFIG_USB_DWC3) += dwc3/ +obj-$(CONFIG_USB_DWC2) += dwc2/ + obj-$(CONFIG_USB_MON) += mon/ obj-$(CONFIG_PCI) += host/ -- 1.7.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
[RFC PATCH 6/6] Hook the DWC2 driver into the build system
Signed-off-by: Paul Zimmerman --- drivers/usb/Kconfig |2 ++ drivers/usb/Makefile |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 4c90b51..4f1c6fe 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -125,6 +125,8 @@ source "drivers/usb/core/Kconfig" source "drivers/usb/dwc3/Kconfig" +source "drivers/usb/dwc2/Kconfig" + source "drivers/usb/mon/Kconfig" source "drivers/usb/wusbcore/Kconfig" diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index f5ed3d7..efa98f7 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -10,6 +10,8 @@ obj-$(CONFIG_USB_OTG_UTILS) += otg/ obj-$(CONFIG_USB_DWC3) += dwc3/ +obj-$(CONFIG_USB_DWC2) += dwc2/ + obj-$(CONFIG_USB_MON) += mon/ obj-$(CONFIG_PCI) += host/ -- 1.7.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
[RFC PATCH 3/6] HCD descriptor DMA support for the DWC2 driver
Signed-off-by: Paul Zimmerman
---
drivers/usb/dwc2/hcd_ddma.c | 1168 +++
1 files changed, 1168 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/dwc2/hcd_ddma.c
diff --git a/drivers/usb/dwc2/hcd_ddma.c b/drivers/usb/dwc2/hcd_ddma.c
new file mode 100644
index 000..8e63dc3
--- /dev/null
+++ b/drivers/usb/dwc2/hcd_ddma.c
@@ -0,0 +1,1168 @@
+/*
+ * hcd_ddma.c - DesignWare HS OTG Controller descriptor DMA routines
+ *
+ * Copyright (C) 2004-2012 Synopsys, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following disclaimer,
+ *without modification.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The names of the above-listed copyright holders may not be used
+ *to endorse or promote products derived from this software without
+ *specific prior written permission.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation; either version 2 of the License, or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
+ * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
+ * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/*
+ * This file contains the Descriptor DMA implementation for Host mode
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "core.h"
+#include "hcd.h"
+
+static u16 frame_list_idx(u16 frame)
+{
+ return frame & (MAX_FRLIST_EN_NUM - 1);
+}
+
+static u16 desclist_idx_inc(u16 idx, u16 inc, u8 speed)
+{
+ return (idx + inc) &
+ ((speed == DWC2_EP_SPEED_HIGH ? MAX_DMA_DESC_NUM_HS_ISOC :
+ MAX_DMA_DESC_NUM_GENERIC) - 1);
+}
+
+static u16 desclist_idx_dec(u16 idx, u16 inc, u8 speed)
+{
+ return (idx - inc) &
+ ((speed == DWC2_EP_SPEED_HIGH ? MAX_DMA_DESC_NUM_HS_ISOC :
+ MAX_DMA_DESC_NUM_GENERIC) - 1);
+}
+
+static u16 max_desc_num(struct dwc2_qh *qh)
+{
+ return (qh->ep_type == USB_ENDPOINT_XFER_ISOC &&
+ qh->dev_speed == DWC2_EP_SPEED_HIGH)
+ ? MAX_DMA_DESC_NUM_HS_ISOC : MAX_DMA_DESC_NUM_GENERIC;
+}
+
+static u16 frame_incr_val(struct dwc2_qh *qh)
+{
+ return qh->dev_speed == DWC2_EP_SPEED_HIGH
+ ? (qh->interval + 8 - 1) / 8 : qh->interval;
+}
+
+static int desc_list_alloc(struct dwc2_hcd *hcd, struct dwc2_qh *qh,
+ gfp_t flags)
+{
+ qh->desc_list = dma_alloc_coherent(hcd->dev,
+ sizeof(struct dwc2_host_dma_desc) *
+ max_desc_num(qh), &qh->desc_list_dma, flags);
+
+ if (!qh->desc_list) {
+ dev_err(hcd->dev, "%s: DMA descriptor list allocation failed\n",
+ __func__);
+ return -ENOMEM;
+ }
+
+ memset(qh->desc_list, 0,
+ sizeof(struct dwc2_host_dma_desc) * max_desc_num(qh));
+
+ qh->n_bytes = kzalloc(sizeof(u32) * max_desc_num(qh), flags);
+ if (!qh->n_bytes) {
+ dev_err(hcd->dev,
+ "%s: Failed to allocate array for descriptors' size
actual values\n",
+ __func__);
+ dma_free_coherent(hcd->dev, sizeof(struct dwc2_host_dma_desc) *
+ max_desc_num(qh), qh->desc_list,
+ qh->desc_list_dma);
+ qh->desc_list = NULL;
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static void desc_list_free(struct dwc2_hcd *hcd, struct dwc2_qh *qh)
+{
+ if (qh->desc_list) {
+ dma_free_coherent(hcd->dev, sizeof(struct dwc2_host_dma_desc) *
+ max_desc_num(qh), qh->desc_list,
+
Re: [PATCH 11/16] usb/gadget: fix error path in uvc_function_bind()
Hi Felipe, On Wednesday 31 October 2012 15:06:54 Felipe Balbi wrote: > On Mon, Oct 22, 2012 at 10:15:05PM +0200, Sebastian Andrzej Siewior wrote: > > The "video->minor = -1" assigment is done in V4L2 by > > video_register_device() so it is removed here. > > Now. uvc_function_bind() calls in error case uvc_function_unbind() for > > cleanup. The problem is that uvc_function_unbind() frees the uvc struct > > and uvc_bind_config() does as well in error case of usb_add_function(). > > Removing kfree() in usb_add_function() would make the patch smaller but > > it would look odd because the new allocated memory is not cleaned up. > > However it is not guaranteed that if we call usb_add_function() we also > > get to the bind function. > > Therefore the patch extracts the conditional cleanup from > > uvc_function_unbind() applies to uvc_function_bind(). > > uvc_function_unbind() now contains only the complete cleanup which is > > required once everything has been registrated. > > > > Cc: Laurent Pinchart > > Cc: Bhupesh Sharma > > Cc: stable > > Signed-off-by: Sebastian Andrzej Siewior > > this has been soaking for long enough and no replies from either Laurent > or Bhupesh. I'm already applying this series, if there is something > wrong it will have to be a patch on top of my gadget branch. Sorry for the too long silence. I would have isolated the common code in a separate function, but that's too late now. It doesn't matter too much though. Bhupesh, do you plan to test my UVC gadget patches with USB 3, or should we drop the USB 3 patches completely ? -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part.
USB autosuspend vs. URB submission
Hi, We've had a few reports in Fedora of users hitting the WARN_ONCE in drivers/usb/core/urb.c that prints a warning about a usb_submit_urb being called on an active URB. One of them[1] is from the ums_realtek driver and the other[2] is from the uvcvideo driver. However, I noticed that in both instances it seems the devices were coming back from what I think is autosuspend. I didn't immediately find any similar reports, and to my rather inexperienced eyes the drivers didn't seem to be doing anything clearly wrong. I'm wondering if anyone has some possible ideas for debugging and whether or not this might be a general issue? The backtraces can be found in the bugs. I've ommitted them here for brevity, but if someone hates bugzilla that much I'd be happy to send them along. josh [1] https://bugzilla.redhat.com/show_bug.cgi?id=889286 [2] https://bugzilla.redhat.com/show_bug.cgi?id=879462 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb serial driver: private data already deallocated when release function is called
I added an addition port_probe, and port_remove function that do nothing but a "return 0". The bahavior is unchanged. The private data is already deallocated once the release function is called Now, i have 2 follow up questions: 1) When I load and unload the kernel model, I get an error message Device 'usbrsatest' does not have a release() function, it is broken and must be fixed. I have a release function. What does this message tries to tell me ? I do have a release function. 2) In the meanwhile, the dynamic debug feature was introduced. I left dev_dbg- messages in my module functions, and set the CONFIG_DYNCAMIC_DEBUG flag. And I issued a command to enable all debug statements ( echo "file usbrsatest.c +p" > /sys/kernel/debug/dynamic_debug/control). I would now expect to see my dev_dbg statments in the syslog. I do not find any message in the system log or using dmesg. Am i looking into the wrong files ? Thanks Tilman -- 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] sisusbvga: use proper device for dev_err() during probe
If kzalloc returns NULL, do not dereference the said NULL pointer as the
first argument to dev_err(); use &dev->dev instead. Similarly, before
sisusb->sisusb_dev has been initialized to dev, use dev_err(&dev->dev)
instead.
Signed-off-by: Nickolai Zeldovich
---
drivers/usb/misc/sisusbvga/sisusb.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/misc/sisusbvga/sisusb.c
b/drivers/usb/misc/sisusbvga/sisusb.c
index dd573ab..bf5f12c 100644
--- a/drivers/usb/misc/sisusbvga/sisusb.c
+++ b/drivers/usb/misc/sisusbvga/sisusb.c
@@ -3084,7 +3084,7 @@ static int sisusb_probe(struct usb_interface *intf,
/* Allocate memory for our private */
if (!(sisusb = kzalloc(sizeof(*sisusb), GFP_KERNEL))) {
- dev_err(&sisusb->sisusb_dev->dev, "Failed to allocate memory
for private data\n");
+ dev_err(&dev->dev, "Failed to allocate memory for private
data\n");
return -ENOMEM;
}
kref_init(&sisusb->kref);
@@ -3093,7 +3093,7 @@ static int sisusb_probe(struct usb_interface *intf,
/* Register device */
if ((retval = usb_register_dev(intf, &usb_sisusb_class))) {
- dev_err(&sisusb->sisusb_dev->dev, "Failed to get a minor for
device %d\n",
+ dev_err(&dev->dev, "Failed to get a minor for device %d\n",
dev->devnum);
retval = -ENODEV;
goto error_1;
--
1.7.10.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 v3 8/9] usb: expose usb port's pm qos flags to user space
On 2013年01月08日 02:44, Alan Stern wrote:
> On Sun, 6 Jan 2013, Lan Tianyu wrote:
>
>> This patch is to expose usb port's pm qos flags(pm_qos_no_power_off,
>> pm_qos_remote_wakeup) to user space. User can set pm_qos_no_power_off
>> flag to prohibit the port from being power off.
>
>> @@ -165,8 +166,12 @@ int usb_hub_create_port_device(struct usb_hub *hub, int
>> port1)
>> if (retval)
>> goto error_register;
>>
>> -pm_runtime_set_active(&port_dev->dev);
>> -pm_runtime_enable(&port_dev->dev);
>> +if (!dev_pm_qos_expose_flags(&port_dev->dev,
>> +PM_QOS_FLAG_NO_POWER_OFF)) {
>> +pm_runtime_set_active(&port_dev->dev);
>> +pm_runtime_enable(&port_dev->dev);
>> +}
>
> I don't understand this. Why does this code need to be conditional?
>
If expose pm qos flag failed, user space couldn't prevent device from
being powered off. This will be dangerous. So for safety, disable port's
runtime pm if it failed.
> Alan Stern
>
--
Best regards
Tianyu Lan
--
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] drivers: xhci: fix incorrect bit test
Fix incorrect bit test that originally showed up in
4ee823b83bc9851743fab756c76b27d6a1e2472b: use '&' instead of '&&'.
Signed-off-by: Nickolai Zeldovich
---
drivers/usb/host/xhci-ring.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index cbb44b7..06921b6 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1698,7 +1698,7 @@ static void handle_port_status(struct xhci_hcd *xhci,
faked_port_index + 1);
if (slot_id && xhci->devs[slot_id])
xhci_ring_device(xhci, slot_id);
- if (bus_state->port_remote_wakeup && (1 << faked_port_index)) {
+ if (bus_state->port_remote_wakeup & (1 << faked_port_index)) {
bus_state->port_remote_wakeup &=
~(1 << faked_port_index);
xhci_test_and_clear_bit(xhci, port_array,
--
1.7.10.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 11/16] usb/gadget: fix error path in uvc_function_bind()
Hi Laurent, > -Original Message- > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > Sent: Tuesday, January 08, 2013 2:13 AM > To: ba...@ti.com > Cc: Sebastian Andrzej Siewior; linux-usb@vger.kernel.org; Bhupesh SHARMA > Subject: Re: [PATCH 11/16] usb/gadget: fix error path in uvc_function_bind() > > Hi Felipe, > > On Wednesday 31 October 2012 15:06:54 Felipe Balbi wrote: > > On Mon, Oct 22, 2012 at 10:15:05PM +0200, Sebastian Andrzej Siewior > wrote: > > > The "video->minor = -1" assigment is done in V4L2 by > > > video_register_device() so it is removed here. > > > Now. uvc_function_bind() calls in error case uvc_function_unbind() > > > for cleanup. The problem is that uvc_function_unbind() frees the uvc > > > struct and uvc_bind_config() does as well in error case of > usb_add_function(). > > > Removing kfree() in usb_add_function() would make the patch smaller > > > but it would look odd because the new allocated memory is not cleaned > up. > > > However it is not guaranteed that if we call usb_add_function() we > > > also get to the bind function. > > > Therefore the patch extracts the conditional cleanup from > > > uvc_function_unbind() applies to uvc_function_bind(). > > > uvc_function_unbind() now contains only the complete cleanup which > > > is required once everything has been registrated. > > > > > > Cc: Laurent Pinchart > > > Cc: Bhupesh Sharma > > > Cc: stable > > > Signed-off-by: Sebastian Andrzej Siewior > > > > this has been soaking for long enough and no replies from either > > Laurent or Bhupesh. I'm already applying this series, if there is > > something wrong it will have to be a patch on top of my gadget branch. > > Sorry for the too long silence. I would have isolated the common code in a > separate function, but that's too late now. It doesn't matter too much > though. > > Bhupesh, do you plan to test my UVC gadget patches with USB 3, or should > we drop the USB 3 patches completely ? > Your USB3 patches break the UVC gadget enumeration with a USB3 host. I would like to send a patchset based on your patchset itself that should solve the issue, I am in the process of preparing and testing it. I know I am extremely late in working on this UVC patchsets, but I have too much on my plate for the moment. I will try to send the patches by this weekend. Sorry for the delay.. Regards, Bhupesh -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] staging: usbip: replace the interrupt safe spinlocks with common ones.
Signed-off-by: Harvey Yang
---
drivers/staging/usbip/vhci_hcd.c | 76 --
drivers/staging/usbip/vhci_rx.c | 10 ++---
drivers/staging/usbip/vhci_tx.c | 14 +++
3 files changed, 42 insertions(+), 58 deletions(-)
diff --git a/drivers/staging/usbip/vhci_hcd.c b/drivers/staging/usbip/vhci_hcd.c
index c3aa219..216648d 100644
--- a/drivers/staging/usbip/vhci_hcd.c
+++ b/drivers/staging/usbip/vhci_hcd.c
@@ -121,11 +121,9 @@ static void dump_port_status_diff(u32 prev_status, u32
new_status)
void rh_port_connect(int rhport, enum usb_device_speed speed)
{
- unsigned long flags;
-
usbip_dbg_vhci_rh("rh_port_connect %d\n", rhport);
- spin_lock_irqsave(&the_controller->lock, flags);
+ spin_lock(&the_controller->lock);
the_controller->port_status[rhport] |= USB_PORT_STAT_CONNECTION
| (1 << USB_PORT_FEAT_C_CONNECTION);
@@ -141,24 +139,22 @@ void rh_port_connect(int rhport, enum usb_device_speed
speed)
break;
}
- spin_unlock_irqrestore(&the_controller->lock, flags);
+ spin_unlock(&the_controller->lock);
usb_hcd_poll_rh_status(vhci_to_hcd(the_controller));
}
static void rh_port_disconnect(int rhport)
{
- unsigned long flags;
-
usbip_dbg_vhci_rh("rh_port_disconnect %d\n", rhport);
- spin_lock_irqsave(&the_controller->lock, flags);
+ spin_lock(&the_controller->lock);
the_controller->port_status[rhport] &= ~USB_PORT_STAT_CONNECTION;
the_controller->port_status[rhport] |=
(1 << USB_PORT_FEAT_C_CONNECTION);
- spin_unlock_irqrestore(&the_controller->lock, flags);
+ spin_unlock(&the_controller->lock);
usb_hcd_poll_rh_status(vhci_to_hcd(the_controller));
}
@@ -183,7 +179,6 @@ static void rh_port_disconnect(int rhport)
static int vhci_hub_status(struct usb_hcd *hcd, char *buf)
{
struct vhci_hcd *vhci;
- unsigned long flags;
int retval;
int rhport;
int changed = 0;
@@ -193,7 +188,7 @@ static int vhci_hub_status(struct usb_hcd *hcd, char *buf)
vhci = hcd_to_vhci(hcd);
- spin_lock_irqsave(&vhci->lock, flags);
+ spin_lock(&vhci->lock);
if (!HCD_HW_ACCESSIBLE(hcd)) {
usbip_dbg_vhci_rh("hw accessible flag not on?\n");
goto done;
@@ -216,7 +211,7 @@ static int vhci_hub_status(struct usb_hcd *hcd, char *buf)
usb_hcd_resume_root_hub(hcd);
done:
- spin_unlock_irqrestore(&vhci->lock, flags);
+ spin_unlock(&vhci->lock);
return changed ? retval : 0;
}
@@ -237,7 +232,6 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
{
struct vhci_hcd *dum;
int retval = 0;
- unsigned long flags;
int rhport;
u32 prev_port_status[VHCI_NPORTS];
@@ -257,7 +251,7 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
dum = hcd_to_vhci(hcd);
- spin_lock_irqsave(&dum->lock, flags);
+ spin_lock(&dum->lock);
/* store old status and compare now and old later */
if (usbip_dbg_flag_vhci_rh) {
@@ -410,7 +404,7 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
}
usbip_dbg_vhci_rh(" bye\n");
- spin_unlock_irqrestore(&dum->lock, flags);
+ spin_unlock(&dum->lock);
return retval;
}
@@ -433,7 +427,6 @@ static void vhci_tx_urb(struct urb *urb)
{
struct vhci_device *vdev = get_vdev(urb->dev);
struct vhci_priv *priv;
- unsigned long flag;
if (!vdev) {
pr_err("could not get virtual device");
@@ -442,11 +435,11 @@ static void vhci_tx_urb(struct urb *urb)
priv = kzalloc(sizeof(struct vhci_priv), GFP_ATOMIC);
- spin_lock_irqsave(&vdev->priv_lock, flag);
+ spin_lock(&vdev->priv_lock);
if (!priv) {
dev_err(&urb->dev->dev, "malloc vhci_priv\n");
- spin_unlock_irqrestore(&vdev->priv_lock, flag);
+ spin_unlock(&vdev->priv_lock);
usbip_event_add(&vdev->ud, VDEV_EVENT_ERROR_MALLOC);
return;
}
@@ -463,7 +456,7 @@ static void vhci_tx_urb(struct urb *urb)
list_add_tail(&priv->list, &vdev->priv_tx);
wake_up(&vdev->waitq_tx);
- spin_unlock_irqrestore(&vdev->priv_lock, flag);
+ spin_unlock(&vdev->priv_lock);
}
static int vhci_urb_enqueue(struct usb_hcd *hcd, struct urb *urb,
@@ -471,7 +464,6 @@ static int vhci_urb_enqueue(struct usb_hcd *hcd, struct urb
*urb,
{
struct device *dev = &urb->dev->dev;
int ret = 0;
- unsigned long flags;
struct vhci_device *vdev;
usbip_dbg_vhci_hc("enter, usb_hcd %p urb %p mem_flags %d\n",
@@ -480,11 +472,11 @@ static int vhci_urb_enqueue(struct usb_hcd *h
[PATCH 1/2] staging: usbip: use interrupt safe spinlock to avoid potential deadlock.
Signed-off-by: Harvey Yang
---
drivers/staging/usbip/stub_dev.c| 34 +-
drivers/staging/usbip/stub_rx.c |4 ++--
drivers/staging/usbip/usbip_event.c |6 --
3 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/usbip/stub_dev.c b/drivers/staging/usbip/stub_dev.c
index ee36415..d36c69e 100644
--- a/drivers/staging/usbip/stub_dev.c
+++ b/drivers/staging/usbip/stub_dev.c
@@ -67,9 +67,9 @@ static ssize_t show_status(struct device *dev, struct
device_attribute *attr,
return -ENODEV;
}
- spin_lock(&sdev->ud.lock);
+ spin_lock_irq(&sdev->ud.lock);
status = sdev->ud.status;
- spin_unlock(&sdev->ud.lock);
+ spin_unlock_irq(&sdev->ud.lock);
return snprintf(buf, PAGE_SIZE, "%d\n", status);
}
@@ -97,39 +97,39 @@ static ssize_t store_sockfd(struct device *dev, struct
device_attribute *attr,
if (sockfd != -1) {
dev_info(dev, "stub up\n");
- spin_lock(&sdev->ud.lock);
+ spin_lock_irq(&sdev->ud.lock);
if (sdev->ud.status != SDEV_ST_AVAILABLE) {
dev_err(dev, "not ready\n");
- spin_unlock(&sdev->ud.lock);
+ spin_unlock_irq(&sdev->ud.lock);
return -EINVAL;
}
socket = sockfd_to_socket(sockfd);
if (!socket) {
- spin_unlock(&sdev->ud.lock);
+ spin_unlock_irq(&sdev->ud.lock);
return -EINVAL;
}
sdev->ud.tcp_socket = socket;
- spin_unlock(&sdev->ud.lock);
+ spin_unlock_irq(&sdev->ud.lock);
sdev->ud.tcp_rx = kthread_get_run(stub_rx_loop, &sdev->ud,
"stub_rx");
sdev->ud.tcp_tx = kthread_get_run(stub_tx_loop, &sdev->ud,
"stub_tx");
- spin_lock(&sdev->ud.lock);
+ spin_lock_irq(&sdev->ud.lock);
sdev->ud.status = SDEV_ST_USED;
- spin_unlock(&sdev->ud.lock);
+ spin_unlock_irq(&sdev->ud.lock);
} else {
dev_info(dev, "stub down\n");
- spin_lock(&sdev->ud.lock);
+ spin_lock_irq(&sdev->ud.lock);
if (sdev->ud.status != SDEV_ST_USED) {
- spin_unlock(&sdev->ud.lock);
+ spin_unlock_irq(&sdev->ud.lock);
return -EINVAL;
}
- spin_unlock(&sdev->ud.lock);
+ spin_unlock_irq(&sdev->ud.lock);
usbip_event_add(&sdev->ud, SDEV_EVENT_DOWN);
}
@@ -241,9 +241,9 @@ static void stub_device_reset(struct usbip_device *ud)
ret = usb_lock_device_for_reset(udev, sdev->interface);
if (ret < 0) {
dev_err(&udev->dev, "lock for reset\n");
- spin_lock(&ud->lock);
+ spin_lock_irq(&ud->lock);
ud->status = SDEV_ST_ERROR;
- spin_unlock(&ud->lock);
+ spin_unlock_irq(&ud->lock);
return;
}
@@ -251,7 +251,7 @@ static void stub_device_reset(struct usbip_device *ud)
ret = usb_reset_device(udev);
usb_unlock_device(udev);
- spin_lock(&ud->lock);
+ spin_lock_irq(&ud->lock);
if (ret) {
dev_err(&udev->dev, "device reset\n");
ud->status = SDEV_ST_ERROR;
@@ -259,14 +259,14 @@ static void stub_device_reset(struct usbip_device *ud)
dev_info(&udev->dev, "device reset\n");
ud->status = SDEV_ST_AVAILABLE;
}
- spin_unlock(&ud->lock);
+ spin_unlock_irq(&ud->lock);
}
static void stub_device_unusable(struct usbip_device *ud)
{
- spin_lock(&ud->lock);
+ spin_lock_irq(&ud->lock);
ud->status = SDEV_ST_ERROR;
- spin_unlock(&ud->lock);
+ spin_unlock_irq(&ud->lock);
}
/**
diff --git a/drivers/staging/usbip/stub_rx.c b/drivers/staging/usbip/stub_rx.c
index 0572a15..e7458e1 100644
--- a/drivers/staging/usbip/stub_rx.c
+++ b/drivers/staging/usbip/stub_rx.c
@@ -307,12 +307,12 @@ static int valid_request(struct stub_device *sdev, struct
usbip_header *pdu)
int valid = 0;
if (pdu->base.devid == sdev->devid) {
- spin_lock(&ud->lock);
+ spin_lock_irq(&ud->lock);
if (ud->status == SDEV_ST_USED) {
/* A request is valid. */
valid = 1;
}
- spin_unlock(&ud->lock);
+ spin_unlock_irq(&ud->lock);
}
return valid;
diff --git a/drivers/staging/usbip/usbip_event.c
b/drivers/staging/usbip/usbip_event.c
index d332a34..82123be 100644
--- a/drivers/staging/usbip/usbip_event.c
+++ b/drivers/staging/usbip/usbip_event.c
@@ -105,10 +105,12 @@ EXPORT_SYMBOL_GPL(usbip_stop
[PATCH 0/2] staging: usbip: refine the lock
This patchset refines some spinlocks which maybe not used properly. [PATCH 1/2]: The function 'usbip_event_add()' may be called in interrupt context on the stub side: 'stub_complete'->'stub_enqueue_ret_unlink'->'usbip_event_add'. In this function it tries to get the lock 'ud->lock', so we should disable irq when we get this lock in process context. [PATCH 2/2]: On the client side, we have a virtual hcd driver, there actually no hardware interrupts, so we do not need worry about race conditions caused by irq. To achieve a good performance there is no need to use the interrupt safe spinlock. Just replace them with a non interrupt safe version. Harvey Yang (2): staging: usbip: use interrupt safe spinlock to avoid potential deadlock. staging: usbip: replace the interrupt safe spinlocks with common ones. drivers/staging/usbip/stub_dev.c| 34 drivers/staging/usbip/stub_rx.c |4 +- drivers/staging/usbip/usbip_event.c |6 ++- drivers/staging/usbip/vhci_hcd.c| 76 +++ drivers/staging/usbip/vhci_rx.c | 10 ++--- drivers/staging/usbip/vhci_tx.c | 14 +++ 6 files changed, 65 insertions(+), 79 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] staging: usbip: use interrupt safe spinlock to avoid potential deadlock.
On Tue, Jan 08, 2013 at 01:49:01PM +0800, Harvey Yang wrote: > > Signed-off-by: Harvey Yang You need to describe _why_ you did this, not just what you did. Why is this needed? What are you fixing by doing this? Is this something that older kernels need? Is it something that others are seeing? Same goes for patch 2/2 here, you have to provide a good changelog entry in order for this to be accepted. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] staging: usbip: refine the lock
On Tue, Jan 08, 2013 at 01:49:00PM +0800, Harvey Yang wrote: > This patchset refines some spinlocks which maybe not used properly. > > [PATCH 1/2]: The function 'usbip_event_add()' may be called in interrupt > context on the stub side: > 'stub_complete'->'stub_enqueue_ret_unlink'->'usbip_event_add'. > In this function it tries to get the lock 'ud->lock', so we should disable > irq when we get this lock in process context. > > [PATCH 2/2]: On the client side, we have a virtual hcd driver, there actually > no hardware interrupts, so we do not need worry about race conditions caused > by irq. To achieve a good performance there is no need to use the interrupt > safe spinlock. Just replace them with a non interrupt safe version. This information needs to be in the patches itself, otherwise it will never be seen. Also, why do you think this is going to make anything faster? Have you measured it? What are the results? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 Resend 9/9] usb: add usb_device_allow_power_off() function.
On 2013年01月07日 15:43, Oliver Neukum wrote:
> On Saturday 05 January 2013 13:58:27 Alan Stern wrote:
>>> static int inline usb_device_prevent_power_off(struct usb_device *udev)
>>> {
>>> struct device *dev = usb_get_port_dev(udev);
>>>
>>> if(!dev)
>>> return -ENODEV;
>>>
>>> return pm_runtime_get_sync(dev);
>>> }
>>>
>>> usb_get_port_dev() locates in the driver/usb/core/port.c and
>>> usb_device_allow/prevent_power_off() locate in the include/linux/usb.h.
>>
>> I was thinking more of something like this. In port.c:
>>
>> int usb_device_allow_prevent_power_off(struct usb_device *udev, bool allow)
>> {
>> ...
>> }
>
> Please change the name. It looks like a contradiction in itself and would
> thereby almost beg for misuse.
>
Hi Oliver:
how about "usb_device_control_power_off(struct usb_device *udev, bool
enabled)"? I am not good at giving a name. So I'd like to see your
opinion.:)
> Regards
> Oliver
>
--
Best regards
Tianyu Lan
--
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: Linux USB redirection
Hi Anil, 2013/1/4 Anil Nair : > Hello Abhijit, > >> I have used the USBIP source for 2.6.30 kernel and tested it. The >> modules are loaded correctly and I was able to export the device as >> virtual USB device to another machine and perform operations on the device. >> You may want to look at the README for compile and usage information. > > Thanks for the reply but one year earlier the drivers were in the > staging list so the module wouldn't load. I did not try after that. > But i will look do as you suggested. :). Are you sure Linux kernel > version 3.0+ supports usbip? Or do i have to switch back to older > kernel versions? Yes, the usbip is working fine with 3.0+ kernel. The userspace tools is located at $kernel-SOURCE/driver/staging/usbip/userspace. Reference: http://kernel.org/doc/readme/drivers-staging-usbip-userspace-README Regards, David Chang > > -- > Regards, > Anil Nair > -- > 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: [PATCH 11/16] usb/gadget: fix error path in uvc_function_bind()
Hi Bhupesh, On Tuesday 08 January 2013 12:00:43 Bhupesh SHARMA wrote: > On Tuesday, January 08, 2013 2:13 AM Laurent Pinchart wrote: > > On Wednesday 31 October 2012 15:06:54 Felipe Balbi wrote: > > > On Mon, Oct 22, 2012 at 10:15:05PM +0200, Sebastian Andrzej Siewior > > wrote: > > > > The "video->minor = -1" assigment is done in V4L2 by > > > > video_register_device() so it is removed here. > > > > Now. uvc_function_bind() calls in error case uvc_function_unbind() > > > > for cleanup. The problem is that uvc_function_unbind() frees the uvc > > > > struct and uvc_bind_config() does as well in error case of > > > > usb_add_function(). > > > > > > > > Removing kfree() in usb_add_function() would make the patch smaller > > > > but it would look odd because the new allocated memory is not cleaned > > > > up. > > > > > > > > However it is not guaranteed that if we call usb_add_function() we > > > > also get to the bind function. > > > > Therefore the patch extracts the conditional cleanup from > > > > uvc_function_unbind() applies to uvc_function_bind(). > > > > uvc_function_unbind() now contains only the complete cleanup which > > > > is required once everything has been registrated. > > > > > > > > Cc: Laurent Pinchart > > > > Cc: Bhupesh Sharma > > > > Cc: stable > > > > Signed-off-by: Sebastian Andrzej Siewior > > > > > > this has been soaking for long enough and no replies from either > > > Laurent or Bhupesh. I'm already applying this series, if there is > > > something wrong it will have to be a patch on top of my gadget branch. > > > > Sorry for the too long silence. I would have isolated the common code in a > > separate function, but that's too late now. It doesn't matter too much > > though. > > > > Bhupesh, do you plan to test my UVC gadget patches with USB 3, or should > > we drop the USB 3 patches completely ? > > Your USB3 patches break the UVC gadget enumeration with a USB3 host. > I would like to send a patchset based on your patchset itself that should > solve the issue, I am in the process of preparing and testing it. > > I know I am extremely late in working on this UVC patchsets, but I have too > much on my plate for the moment. I will try to send the patches by this > weekend. > > Sorry for the delay.. No worries, I perfectly understand that. All I wanted to know was whether you were still interested in USB3 support for the UVC gadget driver. I'm glad that you are :-) I will be on holidays next week (likely without an internet connection), so there's no issue if you delay the patches by one week. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 Resend 9/9] usb: add usb_device_allow_power_off() function.
On Tuesday 08 January 2013 14:38:27 Lan Tianyu wrote: > On 2013年01月07日 15:43, Oliver Neukum wrote: > > Please change the name. It looks like a contradiction in itself and would > > thereby almost beg for misuse. > > > Hi Oliver: > how about "usb_device_control_power_off(struct usb_device *udev, bool > enabled)"? I am not good at giving a name. So I'd like to see your > opinion.:) That sounds good to me. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
