[patch] USB: legousbtower.c: remove a bogus NULL check
"udev" can't be NULL here. The debugging printk() makes static checkers complain when we dereference it later in the function inside the call to usb_rcvctrlpipe(). Signed-off-by: Dan Carpenter diff --git a/drivers/usb/misc/legousbtower.c b/drivers/usb/misc/legousbtower.c index a2702cb..8089479 100644 --- a/drivers/usb/misc/legousbtower.c +++ b/drivers/usb/misc/legousbtower.c @@ -868,9 +868,6 @@ static int tower_probe (struct usb_interface *interface, const struct usb_device dbg(2, "%s: enter", __func__); - if (udev == NULL) - dev_info(&interface->dev, "udev is NULL.\n"); - /* allocate memory for our device state and initialize it */ dev = kmalloc (sizeof(struct lego_usb_tower), GFP_KERNEL); -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] usb: chipidea: fix and improve dependencies if usb host or gadget support is built as module
Since commit "5e0aa49 usb: chipidea: use generic map/unmap routines", the udc part of the chipidea driver needs the generic usb gadget helper functions. If the chipidea driver with udc support is built into the kernel and usb gadget is built a module, the linking of the kernel fails with: drivers/built-in.o: In function `_hardware_dequeue': drivers/usb/chipidea/udc.c:527: undefined reference to `usb_gadget_unmap_request' drivers/usb/chipidea/udc.c:1269: undefined reference to `usb_gadget_unmap_request' drivers/usb/chipidea/udc.c:1821: undefined reference to `usb_del_gadget_udc' drivers/usb/chipidea/udc.c:443: undefined reference to `usb_gadget_map_request' drivers/usb/chipidea/udc.c:1774: undefined reference to `usb_add_gadget_udc' This patch changes the dependencies, so that udc support can only be activated if the linux gadget support (USB_GADGET) is builtin or both chipidea driver and USB_GADGET are modular. Same dependencies for the chipidea host support and the linux host side USB support (USB). While there, fix the indention of chipidea the help text. Cc: Alexander Shishkin Reviewed-by: Felipe Balbi Signed-off-by: Marc Kleine-Budde --- Hello Greg, rebased to your usb-next tree. Marc Changes since v1 - Do not depend on USB host support anymore (tnx Felipe for the input) - Fix help text indention Changes since v2 - rebased to Greg's usb-next drivers/usb/chipidea/Kconfig |9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig index 8337fb5..47e499c 100644 --- a/drivers/usb/chipidea/Kconfig +++ b/drivers/usb/chipidea/Kconfig @@ -1,9 +1,9 @@ config USB_CHIPIDEA tristate "ChipIdea Highspeed Dual Role Controller" - depends on USB + depends on USB || USB_GADGET help - Say Y here if your system has a dual role high speed USB - controller based on ChipIdea silicon IP. Currently, only the + Say Y here if your system has a dual role high speed USB + controller based on ChipIdea silicon IP. Currently, only the peripheral mode is supported. When compiled dynamically, the module will be called ci-hdrc.ko. @@ -12,7 +12,7 @@ if USB_CHIPIDEA config USB_CHIPIDEA_UDC bool "ChipIdea device controller" - depends on USB_GADGET + depends on USB_GADGET=y || USB_GADGET=USB_CHIPIDEA select USB_GADGET_DUALSPEED help Say Y here to enable device controller functionality of the @@ -20,6 +20,7 @@ config USB_CHIPIDEA_UDC config USB_CHIPIDEA_HOST bool "ChipIdea host controller" + depends on USB=y || USB=USB_CHIPIDEA select USB_EHCI_ROOT_HUB_TT help Say Y here to enable host controller functionality of the -- 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 v2] usb: chipidea: fix and improve dependencies if usb host or gadget support is built as module
On 07/20/2012 12:57 AM, Greg KH wrote: [..] >> The problem is, one half of the functions comes from the USB host >> subsystem, the other half from the USB gadget subsystem.So the driver >> can only be built into the kernel (with host+udc support) if both USB >> host and USB gadget are built in. > > > > Ok what a mess. > > But, to top it all off, this patch doesn't apply to my tree. Care to > refresh it against usb-next so that I can apply it? Done regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Fri, Jul 20, 2012 at 4:25 AM, Greg KH wrote: > On Thu, Jul 19, 2012 at 03:54:05PM -0700, Greg KH wrote: >> On Thu, Jul 19, 2012 at 01:20:14PM +0300, Felipe Balbi wrote: >> > Hi, >> > >> > On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote: >> > > This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled >> > > "Fix OMAP EHCI suspend/resume failure (i693)" is causing >> > > the usb hub and device detection fails in beagle XM >> > > causeing NFS not functional. This affects the core retention too. >> > > The same commit logic needs to be revisted adhering to hwmod and >> > > device tree framework. >> > > for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac >> > > titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted. >> > > >> > > This patch is validated on BeagleXM with NFS support over >> > > usb ethernet and USB mass storage and other device detection. >> > > >> > > Signed-off-by: Keshava Munegowda >> > >> > Acked-by: Felipe Balbi >> > >> > turns out this is causing other issues and another version of the patch >> > will be provided. >> > >> > Greg, Alan, this is basically a git revert of the commit id listed >> > above. >> >> Ok, I'll queue it up for 3.6-rc1 and add a -stable mark to it to get >> into 3.5.1, ok? > > Hm, that doesn't work as it doesn't apply to my tree :( > > Can someone please update this against usb-next and send it to me? > Felipe? Hi Greg yes, I will do this I will send the v2 of this patch ASAP regards keshava -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb/at91udc: don't overwrite driver data
On Thu, Jul 19, 2012 at 7:10 PM, Sebastian Andrzej Siewior
wrote:
> The driver was converted to the new start/stop interface in f3d8bf34c2
> ("usb: gadget: at91_udc: convert to new style start/stop interface").
> I overlooked that the driver is overwritting the private data which is
> used by the composite framework. The udc driver doesn't read it, it is
> only writen here
>
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> drivers/usb/gadget/at91_udc.c |2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c
> index 1a4430f..5fd61e2 100644
> --- a/drivers/usb/gadget/at91_udc.c
> +++ b/drivers/usb/gadget/at91_udc.c
> @@ -1634,7 +1634,6 @@ static int at91_start(struct usb_gadget *gadget,
> udc = container_of(gadget, struct at91_udc, gadget);
> udc->driver = driver;
> udc->gadget.dev.driver = &driver->driver;
> - dev_set_drvdata(&udc->gadget.dev, &driver->driver);
> udc->enabled = 1;
> udc->selfpowered = 1;
>
> @@ -1655,7 +1654,6 @@ static int at91_stop(struct usb_gadget *gadget,
> spin_unlock_irqrestore(&udc->lock, flags);
>
> udc->gadget.dev.driver = NULL;
> - dev_set_drvdata(&udc->gadget.dev, NULL);
> udc->driver = NULL;
>
> DBG("unbound from %s\n", driver->driver.name);
> --
> 1.7.10.4
>
Now the driver works fine.
Tested-by: Fabio Porcedda
Regards
--
Fabio Porcedda
--
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/at91udc: Don't check for ep->ep.desc
On Thu, Jul 19, 2012 at 7:10 PM, Sebastian Andrzej Siewior
wrote:
> We used earlier to check for ep->ep.desc to figure out if this ep is
> already enabled and if so, abort.
> Ido Shayevitz removed the usb_endpoint_descriptor from private udc
> structure 5a6506f00 ("usb: gadget: Update at91_udc to use
> usb_endpoint_descriptor inside the struct usb_ep") but did not fix up
> the ep_enable condition because _now_ the member is always true and we
> can't check if this ep is enabled twice.
>
> Cc: Ido Shayevitz
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> drivers/usb/gadget/at91_udc.c |4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c
> index 5fd61e2..22865dd 100644
> --- a/drivers/usb/gadget/at91_udc.c
> +++ b/drivers/usb/gadget/at91_udc.c
> @@ -475,8 +475,7 @@ static int at91_ep_enable(struct usb_ep *_ep,
> unsigned long flags;
>
> if (!_ep || !ep
> - || !desc || ep->ep.desc
> - || _ep->name == ep0name
> + || !desc || _ep->name == ep0name
> || desc->bDescriptorType != USB_DT_ENDPOINT
> || (maxpacket = usb_endpoint_maxp(desc)) == 0
> || maxpacket > ep->maxpacket) {
> @@ -530,7 +529,6 @@ ok:
> tmp |= AT91_UDP_EPEDS;
> __raw_writel(tmp, ep->creg);
>
> - ep->ep.desc = desc;
> ep->ep.maxpacket = maxpacket;
>
> /*
> --
> 1.7.10.4
>
Now the driver works fine.
Tested-by: Fabio Porcedda
Regards
--
Fabio Porcedda
--
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] hidraw : fix list->buffer memleak
On Thu, 28 Jun 2012, Matthieu CASTET wrote:
> If we don't read fast enough hidraw device, hidraw_report_event
> will cycle and we will leak list->buffer.
> Also list->buffer are not free on release.
> After this patch, kmemleak report nothing.
>
> Signed-off-by: Matthieu CASTET
> ---
> drivers/hid/hidraw.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c
> index 36fa77b..3b6f7bf 100644
> --- a/drivers/hid/hidraw.c
> +++ b/drivers/hid/hidraw.c
> @@ -96,6 +96,7 @@ static ssize_t hidraw_read(struct file *file, char __user
> *buffer, size_t count,
> }
>
> kfree(list->buffer[list->tail].value);
> + list->buffer[list->tail].value = NULL;
> list->tail = (list->tail + 1) & (HIDRAW_BUFFER_SIZE - 1);
> }
> out:
> @@ -300,6 +301,7 @@ static int hidraw_release(struct inode * inode, struct
> file * file)
> struct hidraw *dev;
> struct hidraw_list *list = file->private_data;
> int ret;
> + int i;
>
> mutex_lock(&minors_lock);
> if (!hidraw_table[minor]) {
> @@ -317,6 +319,9 @@ static int hidraw_release(struct inode * inode, struct
> file * file)
> kfree(list->hidraw);
> }
> }
> +
> + for (i = 0; i < HIDRAW_BUFFER_SIZE; ++i)
> + kfree(list->buffer[i].value);
> kfree(list);
> ret = 0;
> unlock:
> @@ -446,12 +451,17 @@ int hidraw_report_event(struct hid_device *hid, u8
> *data, int len)
> int ret = 0;
>
> list_for_each_entry(list, &dev->list, node) {
> + int new_head = (list->head + 1) & (HIDRAW_BUFFER_SIZE - 1);
> +
> + if (new_head == list->tail)
> + continue;
> +
> if (!(list->buffer[list->head].value = kmemdup(data, len,
> GFP_ATOMIC))) {
> ret = -ENOMEM;
> break;
> }
> list->buffer[list->head].len = len;
> - list->head = (list->head + 1) & (HIDRAW_BUFFER_SIZE - 1);
> + list->head = new_head;
> kill_fasync(&list->fasync, SIGIO, POLL_IN);
> }
>
Applied, thank you Matthieu.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hid-core : optimize in case of hidraw
On Thu, 28 Jun 2012, Matthieu CASTET wrote:
> When using hidraw, hid buffer can be big and take lot's of
> time to process (interrupt) kernel context.
> Don't try to parse report if we are only interrested in hidraw.
>
> Also don't prepare data for debug stuff if no debugfs file
> are opened.
>
> Signed-off-by: Matthieu CASTET
Nice catch. Applied, thanks.
> ---
> drivers/hid/hid-core.c| 10 --
> drivers/hid/hid-picolcd.c |2 +-
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 8e3a6b2..9f8f7c6 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1194,8 +1194,10 @@ int hid_report_raw_event(struct hid_device *hid, int
> type, u8 *data, int size,
> goto out;
> }
>
> - for (a = 0; a < report->maxfield; a++)
> - hid_input_field(hid, report->field[a], cdata, interrupt);
> + if (hid->claimed != HID_CLAIMED_HIDRAW) {
> + for (a = 0; a < report->maxfield; a++)
> + hid_input_field(hid, report->field[a], cdata,
> interrupt);
> + }
>
> if (hid->claimed & HID_CLAIMED_INPUT)
> hidinput_report_event(hid, report);
> @@ -1243,6 +1245,10 @@ int hid_input_report(struct hid_device *hid, int type,
> u8 *data, int size, int i
> goto unlock;
> }
>
> + /* Avoid unnecessary overhead if debugfs is disabled */
> + if (list_empty(&hid->debug_list))
> + goto nomem;
> +
> buf = kmalloc(sizeof(char) * HID_DEBUG_BUFSIZE, GFP_ATOMIC);
>
> if (!buf)
> diff --git a/drivers/hid/hid-picolcd.c b/drivers/hid/hid-picolcd.c
> index 45c3433..3e0a1e5 100644
> --- a/drivers/hid/hid-picolcd.c
> +++ b/drivers/hid/hid-picolcd.c
> @@ -1846,7 +1846,7 @@ static void picolcd_debug_out_report(struct
> picolcd_data *data,
> #define BUFF_SZ 256
>
> /* Avoid unnecessary overhead if debugfs is disabled */
> - if (!hdev->debug_events)
> + if (list_empty(&hdev->debug_list))
> return;
>
> buff = kmalloc(BUFF_SZ, GFP_ATOMIC);
> --
> 1.7.10.4
>
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH for v3.5 0/2] usb: gadget: at91_udc: fix oops regression
On Fri, Jul 20, 2012 at 12:50 AM, Greg Kroah-Hartman wrote: > On Thu, Jul 19, 2012 at 07:16:54PM +0200, Sebastian Andrzej Siewior wrote: >> On Thu, Jul 19, 2012 at 03:50:54PM +0200, Fabio Porcedda wrote: >> > > I would prefer to fix the bug causing the oops instead of reverting >> > > patches. >> > >> > Me too, it's just that i don't have much time to work on that, and so >> > I'm not confident to be able to fix the kernel panic oops in time for >> > the v3.5 release. >> Yes. If nobody looks into this then the v3.5 kernel will be released and >> other >> kernels will follow. >> Would you now please test it and say that it works with those two patches I >> just posted? The patches fix both issues, now the driver works again! Thanks. >> >> Greg: Any chance to get this two bugfixes into the current release? > > It's too late for 3.5, sorry, but patches can always be backported to > stable releases if they are causing problems. > > thanks, > > greg k-h Regards -- Fabio Porcedda -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] usb/at91udc: don't overwrite driver data
> -Original Message-
> From: Sebastian Andrzej Siewior [mailto:bige...@linutronix.de]
> Sent: quinta-feira, 19 de Julho de 2012 18:11
> To: Felipe Balbi
> Cc: Greg Kroah-Hartman; linux-usb@vger.kernel.org; Mario Jorge
Isidoro; Fabio
> Porcedda; sebast...@breakpoint.cc; Sebastian Andrzej Siewior
> Subject: [PATCH 1/2] usb/at91udc: don't overwrite driver data
>
> The driver was converted to the new start/stop interface in f3d8bf34c2
> ("usb: gadget: at91_udc: convert to new style start/stop interface").
> I overlooked that the driver is overwritting the private data which is
> used by the composite framework. The udc driver doesn't read it, it is
> only writen here
>
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> drivers/usb/gadget/at91_udc.c |2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/at91_udc.c
b/drivers/usb/gadget/at91_udc.c
> index 1a4430f..5fd61e2 100644
> --- a/drivers/usb/gadget/at91_udc.c
> +++ b/drivers/usb/gadget/at91_udc.c
> @@ -1634,7 +1634,6 @@ static int at91_start(struct usb_gadget *gadget,
> udc = container_of(gadget, struct at91_udc, gadget);
> udc->driver = driver;
> udc->gadget.dev.driver = &driver->driver;
> - dev_set_drvdata(&udc->gadget.dev, &driver->driver);
> udc->enabled = 1;
> udc->selfpowered = 1;
>
> @@ -1655,7 +1654,6 @@ static int at91_stop(struct usb_gadget *gadget,
> spin_unlock_irqrestore(&udc->lock, flags);
>
> udc->gadget.dev.driver = NULL;
> - dev_set_drvdata(&udc->gadget.dev, NULL);
> udc->driver = NULL;
>
> DBG("unbound from %s\n", driver->driver.name);
> --
> 1.7.10.4
Hi,
I've tested it, and it works fine here.
Tested-by: Mario Isidoro
Best regards,
Mario Isidoro
--
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/at91udc: Don't check for ep->ep.desc
> -Original Message-
> From: Sebastian Andrzej Siewior [mailto:bige...@linutronix.de]
> Sent: quinta-feira, 19 de Julho de 2012 18:11
> To: Felipe Balbi
> Cc: Greg Kroah-Hartman; linux-usb@vger.kernel.org; Mario Jorge
Isidoro; Fabio
> Porcedda; sebast...@breakpoint.cc; Sebastian Andrzej Siewior; Ido
Shayevitz
> Subject: [PATCH 2/2] usb/at91udc: Don't check for ep->ep.desc
>
> We used earlier to check for ep->ep.desc to figure out if this ep is
> already enabled and if so, abort.
> Ido Shayevitz removed the usb_endpoint_descriptor from private udc
> structure 5a6506f00 ("usb: gadget: Update at91_udc to use
> usb_endpoint_descriptor inside the struct usb_ep") but did not
fix up
> the ep_enable condition because _now_ the member is always true and we
> can't check if this ep is enabled twice.
>
> Cc: Ido Shayevitz
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> drivers/usb/gadget/at91_udc.c |4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/usb/gadget/at91_udc.c
b/drivers/usb/gadget/at91_udc.c
> index 5fd61e2..22865dd 100644
> --- a/drivers/usb/gadget/at91_udc.c
> +++ b/drivers/usb/gadget/at91_udc.c
> @@ -475,8 +475,7 @@ static int at91_ep_enable(struct usb_ep *_ep,
> unsigned long flags;
>
> if (!_ep || !ep
> - || !desc || ep->ep.desc
> - || _ep->name == ep0name
> + || !desc || _ep->name == ep0name
> || desc->bDescriptorType != USB_DT_ENDPOINT
> || (maxpacket = usb_endpoint_maxp(desc)) == 0
> || maxpacket > ep->maxpacket) {
> @@ -530,7 +529,6 @@ ok:
> tmp |= AT91_UDP_EPEDS;
> __raw_writel(tmp, ep->creg);
>
> - ep->ep.desc = desc;
> ep->ep.maxpacket = maxpacket;
>
> /*
> --
> 1.7.10.4
Hi,
I've tested it, and it works fine here.
Tested-by: Mario Isidoro
Best regards,
Mario Isidoro
--
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 RESEND] OMAP: USB : Fix the EHCI enumeration and core retention issue
This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
"Fix OMAP EHCI suspend/resume failure (i693)" is causing
the usb hub and device detection fails in beagle XM
causeing NFS not functional. This affects the core retention too.
The same commit logic needs to be revisted adhering to hwmod and
device tree framework.
for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted.
This patch is validated on BeagleXM with NFS support over
usb ethernet and USB mass storage and other device detection.
Signed-off-by: Keshava Munegowda
---
drivers/usb/host/ehci-omap.c | 167 +-
1 file changed, 1 insertion(+), 166 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index ec21f4a..3ee5ed3 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -56,15 +56,6 @@
#defineEHCI_INSNREG05_ULPI_EXTREGADD_SHIFT 8
#defineEHCI_INSNREG05_ULPI_WRDATA_SHIFT0
-/* Errata i693 */
-static struct clk *utmi_p1_fck;
-static struct clk *utmi_p2_fck;
-static struct clk *xclk60mhsp1_ck;
-static struct clk *xclk60mhsp2_ck;
-static struct clk *usbhost_p1_fck;
-static struct clk *usbhost_p2_fck;
-static struct clk *init_60m_fclk;
-
/*-*/
static const struct hc_driver ehci_omap_hc_driver;
@@ -80,40 +71,6 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
return __raw_readl(base + reg);
}
-/* Erratum i693 workaround sequence */
-static void omap_ehci_erratum_i693(struct ehci_hcd *ehci)
-{
- int ret = 0;
-
- /* Switch to the internal 60 MHz clock */
- ret = clk_set_parent(utmi_p1_fck, init_60m_fclk);
- if (ret != 0)
- ehci_err(ehci, "init_60m_fclk set parent"
- "failed error:%d\n", ret);
-
- ret = clk_set_parent(utmi_p2_fck, init_60m_fclk);
- if (ret != 0)
- ehci_err(ehci, "init_60m_fclk set parent"
- "failed error:%d\n", ret);
-
- clk_enable(usbhost_p1_fck);
- clk_enable(usbhost_p2_fck);
-
- /* Wait 1ms and switch back to the external clock */
- mdelay(1);
- ret = clk_set_parent(utmi_p1_fck, xclk60mhsp1_ck);
- if (ret != 0)
- ehci_err(ehci, "xclk60mhsp1_ck set parent"
- "failed error:%d\n", ret);
-
- ret = clk_set_parent(utmi_p2_fck, xclk60mhsp2_ck);
- if (ret != 0)
- ehci_err(ehci, "xclk60mhsp2_ck set parent"
- "failed error:%d\n", ret);
-
- clk_disable(usbhost_p1_fck);
- clk_disable(usbhost_p2_fck);
-}
static void omap_ehci_soft_phy_reset(struct usb_hcd *hcd, u8 port)
{
@@ -195,50 +152,6 @@ static int omap_ehci_init(struct usb_hcd *hcd)
return rc;
}
-static int omap_ehci_hub_control(
- struct usb_hcd *hcd,
- u16 typeReq,
- u16 wValue,
- u16 wIndex,
- char*buf,
- u16 wLength
-)
-{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
- u32 __iomem *status_reg = &ehci->regs->port_status[
- (wIndex & 0xff) - 1];
- u32 temp;
- unsigned long flags;
- int retval = 0;
-
- spin_lock_irqsave(&ehci->lock, flags);
-
- if (typeReq == SetPortFeature && wValue == USB_PORT_FEAT_SUSPEND) {
- temp = ehci_readl(ehci, status_reg);
- if ((temp & PORT_PE) == 0 || (temp & PORT_RESET) != 0) {
- retval = -EPIPE;
- goto done;
- }
-
- temp &= ~PORT_WKCONN_E;
- temp |= PORT_WKDISC_E | PORT_WKOC_E;
- ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
-
- omap_ehci_erratum_i693(ehci);
-
- set_bit((wIndex & 0xff) - 1, &ehci->suspended_ports);
- goto done;
- }
-
- spin_unlock_irqrestore(&ehci->lock, flags);
-
- /* Handle the hub control events here */
- return ehci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
-done:
- spin_unlock_irqrestore(&ehci->lock, flags);
- return retval;
-}
-
static void disable_put_regulator(
struct ehci_hcd_omap_platform_data *pdata)
{
@@ -351,79 +264,9 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
goto err_pm_runtime;
}
- /* get clocks */
- utmi_p1_fck = clk_get(dev, "utmi_p1_gfclk");
- if (IS_ERR(utmi_p1_fck)) {
- ret = PTR_ERR(utmi_p1_fck);
- dev_err(dev, "utmi_p1_gfclk failed error:%d\n", ret);
- goto err_add_hcd;
- }
-
- xclk60mhsp1_ck = clk_get(dev, "xclk60mhsp1_ck");
- if (IS_ERR(xclk60mhsp1_ck)) {
-
[PATCH RESEND] OMAP: USB : Fix the EHCI enumeration and core retention issue
This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled
"Fix OMAP EHCI suspend/resume failure (i693)" is causing
the usb hub and device detection fails in beagle XM
causeing NFS not functional. This affects the core retention too.
The same commit logic needs to be revisted adhering to hwmod and
device tree framework.
for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac
titled "Fix OMAP EHCI suspend/resume failure (i693)" reverted.
This patch is validated on BeagleXM with NFS support over
usb ethernet and USB mass storage and other device detection.
Signed-off-by: Keshava Munegowda
Acked-by: Felipe Balbi
---
drivers/usb/host/ehci-omap.c | 167 +-
1 file changed, 1 insertion(+), 166 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index ec21f4a..3ee5ed3 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -56,15 +56,6 @@
#defineEHCI_INSNREG05_ULPI_EXTREGADD_SHIFT 8
#defineEHCI_INSNREG05_ULPI_WRDATA_SHIFT0
-/* Errata i693 */
-static struct clk *utmi_p1_fck;
-static struct clk *utmi_p2_fck;
-static struct clk *xclk60mhsp1_ck;
-static struct clk *xclk60mhsp2_ck;
-static struct clk *usbhost_p1_fck;
-static struct clk *usbhost_p2_fck;
-static struct clk *init_60m_fclk;
-
/*-*/
static const struct hc_driver ehci_omap_hc_driver;
@@ -80,40 +71,6 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
return __raw_readl(base + reg);
}
-/* Erratum i693 workaround sequence */
-static void omap_ehci_erratum_i693(struct ehci_hcd *ehci)
-{
- int ret = 0;
-
- /* Switch to the internal 60 MHz clock */
- ret = clk_set_parent(utmi_p1_fck, init_60m_fclk);
- if (ret != 0)
- ehci_err(ehci, "init_60m_fclk set parent"
- "failed error:%d\n", ret);
-
- ret = clk_set_parent(utmi_p2_fck, init_60m_fclk);
- if (ret != 0)
- ehci_err(ehci, "init_60m_fclk set parent"
- "failed error:%d\n", ret);
-
- clk_enable(usbhost_p1_fck);
- clk_enable(usbhost_p2_fck);
-
- /* Wait 1ms and switch back to the external clock */
- mdelay(1);
- ret = clk_set_parent(utmi_p1_fck, xclk60mhsp1_ck);
- if (ret != 0)
- ehci_err(ehci, "xclk60mhsp1_ck set parent"
- "failed error:%d\n", ret);
-
- ret = clk_set_parent(utmi_p2_fck, xclk60mhsp2_ck);
- if (ret != 0)
- ehci_err(ehci, "xclk60mhsp2_ck set parent"
- "failed error:%d\n", ret);
-
- clk_disable(usbhost_p1_fck);
- clk_disable(usbhost_p2_fck);
-}
static void omap_ehci_soft_phy_reset(struct usb_hcd *hcd, u8 port)
{
@@ -195,50 +152,6 @@ static int omap_ehci_init(struct usb_hcd *hcd)
return rc;
}
-static int omap_ehci_hub_control(
- struct usb_hcd *hcd,
- u16 typeReq,
- u16 wValue,
- u16 wIndex,
- char*buf,
- u16 wLength
-)
-{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
- u32 __iomem *status_reg = &ehci->regs->port_status[
- (wIndex & 0xff) - 1];
- u32 temp;
- unsigned long flags;
- int retval = 0;
-
- spin_lock_irqsave(&ehci->lock, flags);
-
- if (typeReq == SetPortFeature && wValue == USB_PORT_FEAT_SUSPEND) {
- temp = ehci_readl(ehci, status_reg);
- if ((temp & PORT_PE) == 0 || (temp & PORT_RESET) != 0) {
- retval = -EPIPE;
- goto done;
- }
-
- temp &= ~PORT_WKCONN_E;
- temp |= PORT_WKDISC_E | PORT_WKOC_E;
- ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
-
- omap_ehci_erratum_i693(ehci);
-
- set_bit((wIndex & 0xff) - 1, &ehci->suspended_ports);
- goto done;
- }
-
- spin_unlock_irqrestore(&ehci->lock, flags);
-
- /* Handle the hub control events here */
- return ehci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
-done:
- spin_unlock_irqrestore(&ehci->lock, flags);
- return retval;
-}
-
static void disable_put_regulator(
struct ehci_hcd_omap_platform_data *pdata)
{
@@ -351,79 +264,9 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
goto err_pm_runtime;
}
- /* get clocks */
- utmi_p1_fck = clk_get(dev, "utmi_p1_gfclk");
- if (IS_ERR(utmi_p1_fck)) {
- ret = PTR_ERR(utmi_p1_fck);
- dev_err(dev, "utmi_p1_gfclk failed error:%d\n", ret);
- goto err_add_hcd;
- }
-
- xclk60mhsp1_ck = clk_get(dev, "xclk60mhsp1_ck");
- if (IS_ERR(xclk60m
Re: linux-next: Tree for July 17 (debugobjects: bt | btusb | usb related?)
On Wed, Jul 18, 2012 at 08:06:17PM +0200, Sedat Dilek wrote: > On Tue, Jul 17, 2012 at 7:41 AM, Stephen Rothwell > wrote: > > Hi all, > > > > Changes since 20120716: > > > > Not sure what the root cause of this issue is. > > I see the following call-trace in linux-next (next-20120717). > > [ 23.431889] [ cut here ] > [ 23.431896] WARNING: at lib/debugobjects.c:261 > debug_print_object+0x8e/0xb0() > [ 23.431897] Hardware name: > [ 23.431901] ODEBUG: free active (active state 0) object type: > timer_list hint: delayed_work_timer_fn+0x0/0x40 There are few delayed works on hci_dev structure, it's hard to say which one is not stopped before kfree. > # CONFIG_DEBUG_OBJECTS_WORK is not set If you enable that option, it should show which delayed work is causing trouble. Stanislaw -- 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/6] USBHID: fix several suspend-related bugs
On Thu, 19 Jul 2012, Alan Stern wrote: > Jiri: > > This patch series fixes several major and minor bugs in the usbhid > driver related to suspend and resume, and especially autosuspend. Alan, thanks a lot for all the fixes! Amazing how many defects have gone unnoticed for quite a long time. I have now queued all this for 3.6. > I don't think any of the problems are terribly severe, although some of > them prevent autosuspend from working properly, so I haven't marked the > patches for -stable. If you want to submit some of them (especially the > first two) for the stable trees, that's okay with me. I'll probably just go with plain 3.6 if you don't mind. Some of the problems have been there for quite a long time already, and I don't remember seeing any report as a fallout of those. Thanks again, -- Jiri Kosina SUSE Labs -- 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 v3] USB: dwc3-exynos: Add support for device tree
Hi,
On Mon, Jul 16, 2012 at 11:27:38AM +0530, Vivek Gautam wrote:
> This patch adds support to parse probe data for
> dwc3 driver for exynos using device tree
>
> Signed-off-by: Praveen Paneri
> Signed-off-by: Vivek Gautam
> ---
> drivers/usb/dwc3/dwc3-exynos.c | 22 ++
> 1 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
> index b8f0038..a293c69 100644
> --- a/drivers/usb/dwc3/dwc3-exynos.c
> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
>
> #include "core.h"
>
> @@ -29,6 +30,8 @@ struct dwc3_exynos {
> struct clk *clk;
> };
>
> +static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
> +
> static int __devinit dwc3_exynos_probe(struct platform_device *pdev)
> {
> struct dwc3_exynos_data *pdata = pdev->dev.platform_data;
> @@ -45,6 +48,16 @@ static int __devinit dwc3_exynos_probe(struct
> platform_device *pdev)
> goto err0;
> }
>
> + /*
> + * Right now device-tree probed devices don't get dma_mask set.
> + * Since shared usb code relies on it, set it here for now.
> + * Once we move to full device tree support this will vanish off.
> + */
> + if (!pdev->dev.dma_mask)
> + pdev->dev.dma_mask = &dwc3_exynos_dma_mask;
> + if (!pdev->dev.coherent_dma_mask)
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> +
> platform_set_drvdata(pdev, exynos);
>
> devid = dwc3_get_device_id();
> @@ -134,11 +147,20 @@ static int __devexit dwc3_exynos_remove(struct
> platform_device *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id exynos_xhci_match[] = {
> + { .compatible = "samsung,exynos-xhci" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, exynos_xhci_match);
this is not an xhci device. It contains one inside of it, but it's not
an xhci device.
--
balbi
signature.asc
Description: Digital signature
Re: linux-next: Tree for July 17 (debugobjects: bt | btusb | usb related?)
On Fri, Jul 20, 2012 at 11:47 AM, Stanislaw Gruszka wrote: > On Wed, Jul 18, 2012 at 08:06:17PM +0200, Sedat Dilek wrote: >> On Tue, Jul 17, 2012 at 7:41 AM, Stephen Rothwell >> wrote: >> > Hi all, >> > >> > Changes since 20120716: >> > >> >> Not sure what the root cause of this issue is. >> >> I see the following call-trace in linux-next (next-20120717). >> >> [ 23.431889] [ cut here ] >> [ 23.431896] WARNING: at lib/debugobjects.c:261 >> debug_print_object+0x8e/0xb0() >> [ 23.431897] Hardware name: >> [ 23.431901] ODEBUG: free active (active state 0) object type: >> timer_list hint: delayed_work_timer_fn+0x0/0x40 > There are few delayed works on hci_dev structure, it's hard to say which > one is not stopped before kfree. > >> # CONFIG_DEBUG_OBJECTS_WORK is not set > If you enable that option, it should show which delayed work is causing > trouble. > OK, thanks for the explanations & hints! I will activate that kconfig-option. FYI: With yesterday's linux-next (next-20120719) I didn't trap into this regression (same kernel-config + several bootups). - Sedat - > Stanislaw -- 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 v3] USB: dwc3-exynos: Add vbus setup function to the exynos dwc3 glue layer
Hi,
On Mon, Jul 16, 2012 at 11:27:39AM +0530, Vivek Gautam wrote:
> This patch retrieves and configures the vbus control gpio via
> the device tree. The suspend/resume callbacks will be later
> modified for vbus control.
>
> Signed-off-by: Abhilash Kesavan
> Signed-off-by: Vivek Gautam
> ---
> drivers/usb/dwc3/dwc3-exynos.c | 25 +
> 1 files changed, 25 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
> index a293c69..9b0238f 100644
> --- a/drivers/usb/dwc3/dwc3-exynos.c
> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include "core.h"
>
> @@ -30,6 +31,28 @@ struct dwc3_exynos {
> struct clk *clk;
> };
>
> +static int dwc3_setup_vbus_gpio(struct platform_device *pdev)
> +{
> + int err;
> + int gpio;
> +
> + if (!pdev->dev.of_node)
> + return 0;
> +
> + gpio = of_get_named_gpio(pdev->dev.of_node,
> + "samsung,vbus-gpio", 0);
> + if (!gpio_is_valid(gpio))
> + return 0;
> +
> + err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, "dwc3_vbus_gpio");
> + if (err) {
> + dev_err(&pdev->dev, "can't request dwc3 vbus gpio %d", gpio);
> + return err;
> + }
> +
> + return err;
> +}
> +
> static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
>
> static int __devinit dwc3_exynos_probe(struct platform_device *pdev)
> @@ -58,6 +81,8 @@ static int __devinit dwc3_exynos_probe(struct
> platform_device *pdev)
> if (!pdev->dev.coherent_dma_mask)
> pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>
> + dwc3_setup_vbus_gpio(pdev);
I think this should be handled by the gpio-vbus transceiver. No ?
--
balbi
signature.asc
Description: Digital signature
Re: Regarding usb 2.0 synopsys otg controller status
Hi, On Wed, Jul 11, 2012 at 03:55:43PM +0530, rajeev k wrote: > Resending the mail as it fails to deliver to the mailing list. > > Hello Balbi, > > I am using synopsys usb 2.0 otg driver written by Tirumala Marri < > tma...@apm.com>. > > The driver is too bulky, and it can be modified for the ease. The driver > has capability to work both in dma as well as slave mode. > > > > Why I am writing this mail because I am not seeing any development activity > for this. Is this driver no more in existence. > > If I want to float some patches on this controller in order to stabilize > the same, will it get reviewed and be considered for mainline inclusion.. There were over 17 rounds of review to that driver so I killed it in favor of generalizing the samsung s3c_hsotg driver. Samsung exynos platform uses the dwc usb2 2.0 otg controller, so the same driver can be used. The samsung folks have been working a lot towards that goal, but they need help. Wanna take the challenge ? It should end up with a similar design as drivers/usb/dwc3/, meaning the core driver is instantiated and re-used multiple times if necessary. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: chipidea: ci13xxx-imx: remove global struct
> Actually i am touching two thing at a time in this patch, removing the > static struct and setting the flags by oftree. I will resend this patch, > together with other work, and will just leave the flags as currently > set. Yup. Might be worth splitting up this patch into two, as well. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
unneeded SubClass and Protocol entries in unusual_devs.h
Hello, I'm testing an embedded system, which is running a somewhat dated (May 2009) 2.6.28.10 kernel. When I plug this cheap 2-GB USB drive, I get the following message: hub_port_init 1 Plug in USB Port3 udev->speed: 3 usb 3-1: configuration #1 chosen from 1 choice usb-storage: This device (058f,6387,0104 S 06 P 50) has unneeded SubClass and Protocol entries in unusual_devs.h (kernel 2.6.28.10) Please send a copy of this message to and scsi0 : SCSI emulation for USB Mass Storage devices scsi 0:0:0:0: Direct-Access Generic Flash Disk 8.07 PQ: 0 ANSI: 2 usb 3-1: New USB device found, idVendor=058f, idProduct=6387 usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-1: Product: Mass Storage usb 3-1: Manufacturer: Generic usb 3-1: SerialNumber: 6FA643E9 sd 0:0:0:0: [sda] 4075520 512-byte hardware sectors: (2.08 GB/1.94 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Assuming drive cache: write through sd 0:0:0:0: [sda] 4075520 512-byte hardware sectors: (2.08 GB/1.94 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Assuming drive cache: write through sda:<7>hub 3-0:1.0: port 1 enable change, status 0403 sd 0:0:0:0: [sda] Attached SCSI removable disk sdp->removable:1 And, when I try to list the drive's contents, I can't: (while WinXP "sees" the contents) # ls -l /dev/sda /dev/sda/ /dev/sda1 /dev/sda1/ ls: /dev/sda/: Not a directory ls: /dev/sda1: No such file or directory ls: /dev/sda1/: No such file or directory brw-rw1 root 0 8, 0 Jan 1 00:06 /dev/sda Given the age of my kernel, there is a good chance this problem has been already been fixed in recent kernels. Is it the case? For reference, here's my boot message: LX_MEM = 0x0, 0x230 LX_MEM2 = 0x6600, 0x700 CPHYSADDR(PFN_ALIGN(&_end))= 0x46F000 EMAC_LEN= 0x10 DRAM_LEN= 0x1000 console [early0] enabled CPU revision is: 00019750 (MIPS 74Kc) FPU revision is: 01739700 Begin Kaiserin_setup Determined physical RAM map: memory: 0230 @ (usable) memory: 0700 @ 6600 (usable) Initrd not found or empty - disabling initrd Zone PFN ranges: DMA 0x -> 0x8000 Normal 0x8000 -> 0x0002 HighMem 0x0002 -> 0x0006d000 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x -> 0x2300 0: 0x00066000 -> 0x0006d000 Normal zone: 768 pages exceeds realsize 0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 34912 Kernel command line: console=ttyS0,115200 ubi.mtd=0,2048 root=ubi:RFS rootfstype=ubifs rw LX_MEM=0x230 EMAC_MEM=0x10 DRAM_LEN=0x1000 LX_MEM2=0x6600,0x700 BB_ADDR=0x700 MS_GOP0_MIU=0 mtdparts=edb64M-nand:128m(UBI),-(NA) ENV=SERIAL alloc ebase: 81da6000 Primary instruction cache 32kB, VIPT, 4-way, linesize 32 bytes. Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes Writing ErrCtl register= Readback ErrCtl register= PID hash table entries: 256 (order: 8, 1024 bytes) CPU freq count = 39600 console handover: boot [early0] -> real [ttyS0] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 131772k/35840k available (3070k kernel code, 18596k reserved, 849k data, 164k init, 114688k highmem) SLUB: Genslabs=6, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Calibrating delay loop... 395.26 BogoMIPS (lpj=197632) Mount-cache hash table entries: 512 net_namespace: 288 bytes NET: Registered protocol family 16 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered NET: Registered protocol family 1 highmem bounce pool size: 64 pages squashfs: version 3.4 (2008/08/26) Phillip Lougher squashfs: LZMA suppport for slax.org by jro JFFS2 version 2.2. (NAND)2001-2006 Red Hat, Inc. fuse init (API version 7.10) msgmni has been set to 33 alg: No test for stdrng (krng) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) Serial: 8250/16550 driver4 ports, IRQ sharing disabled serial8250: ttyS0 at I/O 0xbf201300 (irq = 8) is a 16550 brd: module loaded loop: module loaded Driver 'sd' needs updating - please use bus_type methods usbmon: debugfs is not available Mstar-ehci-2 H.W init Titania3_series_start_ehc start Mstar-ehci-2 Mstar-ehci-2.1: Mstar EHCI Mstar-ehci-2 Mstar-ehci-2.1: new USB bus registered, assigned bus number 1 Mstar-ehci-2 Mstar-ehci-2.1: irq 74, io mem 0xbf201a00 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0:
Re: [PATCH] isp1362-hcd.c: usb message always saved in case of underrun
Il 20/07/2012 00:58, Greg KH ha scritto:
On Wed, Jul 18, 2012 at 10:53:09AM +0200, Claudio Scordino wrote:
Il 06/07/2012 19:41, Greg KH ha scritto:
On Wed, Jun 27, 2012 at 06:01:39PM +0200, Claudio Scordino wrote:
Hi Olav,
please find below a patch for the isp1362-hcd.c driver to always
save the message in case of underrun. More information is provided
inside the patch comment. Let us know if you need any further
information.
Best regards,
Claudio
Subject: isp1362-hcd.c: usb message always saved in case of underrun
From: Bruno Morelli
The usb message must be saved also in case the USB endpoint is not a
control endpoint (i.e., "endpoint 0"), otherwise in some circumstances
we don't have a payload in case of error.
The patch has been created by tracing with usbmon the different error
messages generated by this driver with respect to the ehci-hcd driver.
Signed-off-by: Bruno Morelli
Signed-off-by: Claudio Scordino
Tested-by: Bruno Morelli
---
drivers/usb/host/isp1362-hcd.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/isp1362-hcd.c b/drivers/usb/host/isp1362-hcd.c
index 2ed112d..61bf1b2 100644
--- a/drivers/usb/host/isp1362-hcd.c
+++ b/drivers/usb/host/isp1362-hcd.c
@@ -543,13 +543,14 @@ static void postproc_ep(struct isp1362_hcd *isp1362_hcd,
struct isp1362_ep *ep)
usb_pipein(urb->pipe) ? "IN" : "OUT", ep->nextpid,
short_ok ? "" : "not_",
PTD_GET_COUNT(ptd), ep->maxpacket, len);
+ /* save the data underrun error code for later and
+* proceed with the status stage
+*/
+ urb->actual_length += PTD_GET_COUNT(ptd);
+ BUG_ON(urb->actual_length>
+ urb->transfer_buffer_length);
Please NEVER crash the machine in a driver like this, it's bad and can
cause problems. Yes, I know you are just moving it from the lines
below:
if (usb_pipecontrol(urb->pipe)) {
ep->nextpid = USB_PID_ACK;
- /* save the data underrun error code for later
and
-* proceed with the status stage
-*/
- urb->actual_length += PTD_GET_COUNT(ptd);
- BUG_ON(urb->actual_length>
urb->transfer_buffer_length);
But really, it should not be in the driver at all. Please remove it, at
the most, do a WARN_ON() so that someone can see the problem and at
least report it.
Actually, what is this checking? How can someone recover from it? Who
is this check for? The developer of this driver? Another driver?
Hardware developer? End user? Who would be able to fix the problem if
this happens?
As it is, I can't take it, sorry.
Hi Greg.
I understand. As you have already said, this driver is full of BUG_ON
statements.
So, we can shift just the assignment as in the patch below, to have a
correct behavior, leaving the BUG_ON where it already is. Then, we may
propose a different patch to change BUG_ONs to WARN_ONs.
Your updated patch is much better, thanks.
But it doesn't apply to my tree right now. Can you please refresh it
against the usb-next tree and resend it?
Actually, I did.
So, this means that I'm using the wrong tree...
I'm using the "usb-next" branch available on your tree at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
Is this the wrong one ?
Many thanks,
Claudio
--
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: unneeded SubClass and Protocol entries in unusual_devs.h
Mason wrote: > I'm testing an embedded system, which is running a somewhat dated > (May 2009) 2.6.28.10 kernel. > > When I plug this cheap 2-GB USB drive, I get the following message: > > usb-storage: This device (058f,6387,0104 S 06 P 50) has unneeded SubClass and > Protocol entries in unusual_devs.h (kernel 2.6.28.10) >Please send a copy of this message to and > > > And, when I try to list the drive's contents, I can't. Sorry, my brain glitched for a moment, looking at the device nodes, instead of the appropriate mount point. # ls -l /mnt/sda/ -rwxrwxrwx1 root 0 572928 Mar 27 2012 hfs.exe sda instead of sda1 means there is no MBR, thus no partition table, right? AFAIU, the whole drive is being used for a single partition. How does the kernel know the partition type then? Is it just guessing? -- Regards. -- 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] firmware load: defer request_firmware during early boot and resume
The RFC patch is just for discussing if the idea of deferring
request_firmware is doable for addressing the issue of
request_firmware in resume path, which is caused by driver
unbind/rebind during resume.
At least usb bus is involved in such things, one driver may be
unbound and rebound in resume path at several situations, and
request_firmware is often called inside probe().
Also the idea should be helpful for other hotplug buses too,
at least there was the similar problem report on pcmcia bus.
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 6cd2c6c..fb02eff 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -123,7 +123,7 @@ static bool driver_deferred_probe_enable = false;
* list and schedules the deferred probe workqueue to process them. It
* should be called anytime a driver is successfully bound to a device.
*/
-static void driver_deferred_probe_trigger(void)
+void driver_deferred_probe_trigger(void)
{
if (!driver_deferred_probe_enable)
return;
@@ -144,6 +144,7 @@ static void driver_deferred_probe_trigger(void)
*/
queue_work(deferred_wq, &deferred_probe_work);
}
+EXPORT_SYMBOL_GPL(driver_deferred_probe_trigger);
/**
* deferred_probe_initcall() - Enable probing of deferred devices
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 5401814..4fe742f 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -593,6 +593,9 @@ request_firmware(const struct firmware
**firmware_p, const char *name,
if (IS_ERR_OR_NULL(fw_priv))
return PTR_RET(fw_priv);
+ if (system_state != SYSTEM_RUNNING)
+ return -EPROBE_DEFER;
+
ret = usermodehelper_read_trylock();
if (WARN_ON(ret)) {
dev_err(device, "firmware: %s will not be loaded\n", name);
diff --git a/include/linux/device.h b/include/linux/device.h
index d0e4d99..a63d3171 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -244,7 +244,7 @@ extern struct device_driver *driver_find(const char *name,
struct bus_type *bus);
extern int driver_probe_done(void);
extern void wait_for_device_probe(void);
-
+extern void driver_deferred_probe_trigger(void);
/* sysfs interface for exporting driver attributes */
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index e07f5e0..c8d74c6 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -378,6 +378,7 @@ extern enum system_states {
SYSTEM_POWER_OFF,
SYSTEM_RESTART,
SYSTEM_SUSPEND_DISK,
+ SYSTEM_SUSPEND,
} system_state;
#define TAINT_PROPRIETARY_MODULE 0
diff --git a/init/main.c b/init/main.c
index e60679d..237eae1 100644
--- a/init/main.c
+++ b/init/main.c
@@ -809,6 +809,8 @@ static noinline int init_post(void)
current->signal->flags |= SIGNAL_UNKILLABLE;
flush_delayed_fput();
+ driver_deferred_probe_trigger();
+
if (ramdisk_execute_command) {
run_init_process(ramdisk_execute_command);
printk(KERN_WARNING "Failed to execute %s\n",
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 1da39ea..dbf6ffb 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -224,6 +224,9 @@ int suspend_devices_and_enter(suspend_state_t state)
goto Recover_platform;
}
suspend_test_finish("suspend devices");
+
+ system_state = SYSTEM_SUSPEND;
+
if (suspend_test(TEST_DEVICES))
goto Recover_platform;
@@ -301,6 +304,10 @@ static int enter_state(suspend_state_t state)
Finish:
pr_debug("PM: Finishing wakeup.\n");
suspend_finish();
+
+ system_state = SYSTEM_RUNNING;
+ driver_deferred_probe_trigger();
+
Unlock:
mutex_unlock(&pm_mutex);
return error;
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] firmware load: defer request_firmware during early boot and resume
On Fri, Jul 20, 2012 at 08:33:32PM +0800, Ming Lei wrote:
> The RFC patch is just for discussing if the idea of deferring
> request_firmware is doable for addressing the issue of
> request_firmware in resume path, which is caused by driver
> unbind/rebind during resume.
>
> At least usb bus is involved in such things, one driver may be
> unbound and rebound in resume path at several situations, and
> request_firmware is often called inside probe().
>
> Also the idea should be helpful for other hotplug buses too,
> at least there was the similar problem report on pcmcia bus.
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 6cd2c6c..fb02eff 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -123,7 +123,7 @@ static bool driver_deferred_probe_enable = false;
> * list and schedules the deferred probe workqueue to process them. It
> * should be called anytime a driver is successfully bound to a device.
> */
> -static void driver_deferred_probe_trigger(void)
> +void driver_deferred_probe_trigger(void)
> {
> if (!driver_deferred_probe_enable)
> return;
> @@ -144,6 +144,7 @@ static void driver_deferred_probe_trigger(void)
>*/
> queue_work(deferred_wq, &deferred_probe_work);
> }
> +EXPORT_SYMBOL_GPL(driver_deferred_probe_trigger);
>
> /**
> * deferred_probe_initcall() - Enable probing of deferred devices
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 5401814..4fe742f 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -593,6 +593,9 @@ request_firmware(const struct firmware
> **firmware_p, const char *name,
> if (IS_ERR_OR_NULL(fw_priv))
> return PTR_RET(fw_priv);
>
> + if (system_state != SYSTEM_RUNNING)
> + return -EPROBE_DEFER;
> +
> ret = usermodehelper_read_trylock();
> if (WARN_ON(ret)) {
> dev_err(device, "firmware: %s will not be loaded\n", name);
> diff --git a/include/linux/device.h b/include/linux/device.h
> index d0e4d99..a63d3171 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -244,7 +244,7 @@ extern struct device_driver *driver_find(const char *name,
>struct bus_type *bus);
> extern int driver_probe_done(void);
> extern void wait_for_device_probe(void);
> -
> +extern void driver_deferred_probe_trigger(void);
>
> /* sysfs interface for exporting driver attributes */
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index e07f5e0..c8d74c6 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -378,6 +378,7 @@ extern enum system_states {
> SYSTEM_POWER_OFF,
> SYSTEM_RESTART,
> SYSTEM_SUSPEND_DISK,
> + SYSTEM_SUSPEND,
> } system_state;
>
> #define TAINT_PROPRIETARY_MODULE 0
> diff --git a/init/main.c b/init/main.c
> index e60679d..237eae1 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -809,6 +809,8 @@ static noinline int init_post(void)
> current->signal->flags |= SIGNAL_UNKILLABLE;
> flush_delayed_fput();
>
> + driver_deferred_probe_trigger();
> +
> if (ramdisk_execute_command) {
> run_init_process(ramdisk_execute_command);
> printk(KERN_WARNING "Failed to execute %s\n",
> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> index 1da39ea..dbf6ffb 100644
> --- a/kernel/power/suspend.c
> +++ b/kernel/power/suspend.c
> @@ -224,6 +224,9 @@ int suspend_devices_and_enter(suspend_state_t state)
> goto Recover_platform;
> }
> suspend_test_finish("suspend devices");
> +
> + system_state = SYSTEM_SUSPEND;
This new SYSTEM_SUSPEND state is declared above and only assigned here
to system_state without being tested anywhere. AFAICT, the only test
you're doing is system_state != SYSTEM_RUNNING and that works without
defining a new SYSTEM_SUSPEND state.
So are you sure you really need it?
--
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] firmware load: defer request_firmware during early boot and resume
On Fri, Jul 20, 2012 at 8:52 PM, Borislav Petkov wrote: > This new SYSTEM_SUSPEND state is declared above and only assigned here > to system_state without being tested anywhere. AFAICT, the only test > you're doing is system_state != SYSTEM_RUNNING and that works without > defining a new SYSTEM_SUSPEND state. > > So are you sure you really need it? If the approach is workable, I will rename SYSTEM_SUSPEND_DISK as SYSTEM_SUSPEND since SYSTEM_SUSPEND_DISK is not used now. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] firmware load: defer request_firmware during early boot and resume
On Fri, Jul 20, 2012 at 08:57:05PM +0800, Ming Lei wrote: > On Fri, Jul 20, 2012 at 8:52 PM, Borislav Petkov wrote: > > > This new SYSTEM_SUSPEND state is declared above and only assigned here > > to system_state without being tested anywhere. AFAICT, the only test > > you're doing is system_state != SYSTEM_RUNNING and that works without > > defining a new SYSTEM_SUSPEND state. > > > > So are you sure you really need it? > > If the approach is workable, I will rename SYSTEM_SUSPEND_DISK as > SYSTEM_SUSPEND since SYSTEM_SUSPEND_DISK is not used now. This still doesn't change the fact that SYSTEM_SUSPEND or SYSTEM_SUSPEND_DISK is unused. IOW, both states are unused. So why introduce a new state instead of simply test != SYSTEM_RUNNING? -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] firmware load: defer request_firmware during early boot and resume
On Fri, Jul 20, 2012 at 9:03 PM, Borislav Petkov wrote: > This still doesn't change the fact that SYSTEM_SUSPEND or > SYSTEM_SUSPEND_DISK is unused. IOW, both states are unused. So why > introduce a new state instead of simply test != SYSTEM_RUNNING? Because system_state is still SYSTEM_RUNNING during S2R or hibernation. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] firmware load: defer request_firmware during early boot and resume
On Fri, Jul 20, 2012 at 09:09:10PM +0800, Ming Lei wrote: > On Fri, Jul 20, 2012 at 9:03 PM, Borislav Petkov wrote: > > This still doesn't change the fact that SYSTEM_SUSPEND or > > SYSTEM_SUSPEND_DISK is unused. IOW, both states are unused. So why > > introduce a new state instead of simply test != SYSTEM_RUNNING? > > Because system_state is still SYSTEM_RUNNING during S2R or hibernation. Ah, and you change that in suspend_devices_and_enter(). Ok, thanks. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] firmware load: defer request_firmware during early boot and resume
On Friday 20 July 2012 20:33:32 Ming Lei wrote: > The RFC patch is just for discussing if the idea of deferring > request_firmware is doable for addressing the issue of > request_firmware in resume path, which is caused by driver > unbind/rebind during resume. > > At least usb bus is involved in such things, one driver may be > unbound and rebound in resume path at several situations, and > request_firmware is often called inside probe(). > > Also the idea should be helpful for other hotplug buses too, > at least there was the similar problem report on pcmcia bus. The approach seems to me to be less comprehensive than it ought to be. If you defer, why not the whole probe()? Deferring only the upoad of the firmware complicates error handling. 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] isp1362-hcd.c: usb message always saved in case of underrun
On Fri, Jul 20, 2012 at 12:26:10PM +0200, Claudio Scordino wrote:
> Il 20/07/2012 00:58, Greg KH ha scritto:
> >On Wed, Jul 18, 2012 at 10:53:09AM +0200, Claudio Scordino wrote:
> >>Il 06/07/2012 19:41, Greg KH ha scritto:
> >>>On Wed, Jun 27, 2012 at 06:01:39PM +0200, Claudio Scordino wrote:
> Hi Olav,
>
> please find below a patch for the isp1362-hcd.c driver to always
> save the message in case of underrun. More information is provided
> inside the patch comment. Let us know if you need any further
> information.
>
> Best regards,
>
> Claudio
>
>
> Subject: isp1362-hcd.c: usb message always saved in case of underrun
> From: Bruno Morelli
>
> The usb message must be saved also in case the USB endpoint is not a
> control endpoint (i.e., "endpoint 0"), otherwise in some circumstances
> we don't have a payload in case of error.
>
> The patch has been created by tracing with usbmon the different error
> messages generated by this driver with respect to the ehci-hcd driver.
>
> Signed-off-by: Bruno Morelli
> Signed-off-by: Claudio Scordino
> Tested-by: Bruno Morelli
> ---
> drivers/usb/host/isp1362-hcd.c | 11 ++-
> 1 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/host/isp1362-hcd.c
> b/drivers/usb/host/isp1362-hcd.c
> index 2ed112d..61bf1b2 100644
> --- a/drivers/usb/host/isp1362-hcd.c
> +++ b/drivers/usb/host/isp1362-hcd.c
> @@ -543,13 +543,14 @@ static void postproc_ep(struct isp1362_hcd
> *isp1362_hcd, struct isp1362_ep *ep)
> usb_pipein(urb->pipe) ? "IN" : "OUT",
> ep->nextpid,
> short_ok ? "" : "not_",
> PTD_GET_COUNT(ptd), ep->maxpacket, len);
> + /* save the data underrun error code for later and
> + * proceed with the status stage
> + */
> + urb->actual_length += PTD_GET_COUNT(ptd);
> + BUG_ON(urb->actual_length>
> + urb->transfer_buffer_length);
> >>>
> >>>Please NEVER crash the machine in a driver like this, it's bad and can
> >>>cause problems. Yes, I know you are just moving it from the lines
> >>>below:
> >>>
> if (usb_pipecontrol(urb->pipe)) {
> ep->nextpid = USB_PID_ACK;
> - /* save the data underrun error code for later
> and
> - * proceed with the status stage
> - */
> - urb->actual_length += PTD_GET_COUNT(ptd);
> - BUG_ON(urb->actual_length>
> urb->transfer_buffer_length);
> >>>
> >>>But really, it should not be in the driver at all. Please remove it, at
> >>>the most, do a WARN_ON() so that someone can see the problem and at
> >>>least report it.
> >>>
> >>>Actually, what is this checking? How can someone recover from it? Who
> >>>is this check for? The developer of this driver? Another driver?
> >>>Hardware developer? End user? Who would be able to fix the problem if
> >>>this happens?
> >>>
> >>>As it is, I can't take it, sorry.
> >>
> >>
> >>Hi Greg.
> >>
> >>I understand. As you have already said, this driver is full of BUG_ON
> >>statements.
> >>
> >>So, we can shift just the assignment as in the patch below, to have a
> >>correct behavior, leaving the BUG_ON where it already is. Then, we may
> >>propose a different patch to change BUG_ONs to WARN_ONs.
> >
> >Your updated patch is much better, thanks.
> >
> >But it doesn't apply to my tree right now. Can you please refresh it
> >against the usb-next tree and resend it?
>
> Actually, I did.
>
> So, this means that I'm using the wrong tree...
>
> I'm using the "usb-next" branch available on your tree at
>
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
>
> Is this the wrong one ?
That is the correct one. It didn't work for me, so try refreshing your
patch and resending it.
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: [RFC] firmware load: defer request_firmware during early boot and resume
On Fri, Jul 20, 2012 at 9:54 PM, Oliver Neukum wrote: > > The approach seems to me to be less comprehensive than > it ought to be. If you defer, why not the whole probe()? Because for other failures, we don't know when the conditions for them can be satisfied. For example, we don't know when the memory allocation can be met for one previous allocation failure. IMO, at least the approach provides one simple way to solve the firmware loading problem during. early boot or resume > Deferring only the upoad of the firmware complicates > error handling. Looks there is no special requirement for the error handling of request_firmware, just like other failures' handling, undo things which has been done, isn't there? Thanks, -- Ming Lei -- 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: Kernel tracing options with USB subsystem
Hi Greg, When it comes to embedded device cases, I feel that the options are just left with debug messages. It becomes really difficult to debug some SMP specific issues, thread deadlocks etc. I felt that, using trace events, we could effectively log some of those specific data without the penalty of compromising latency which happens with printks. usbmon is perfect, but USB-centric. The background behind my queries was that, is there someway we could trace out whats happening in the USB which also contains the kernel information, like the cpu%d it is running, the task context etc. I am fairly new to linux, so please correct me if I got my understanding wrong :) Many Thanks, ~Bala On 07/20/2012 12:18 AM, Greg KH wrote: On Thu, Jul 19, 2012 at 10:00:12PM +0530, Balakumar wrote: Hello Alan, John, I had this question from the embedded perspective. printk on occasions seems to have some overhead which actually dilutes the issue occurrence frequency. So, just wanted to know if this was not included by choice. What does printk have to do with usbmon? And note, the USB tracing code was added before there was an in-kernel tracing infrastructure, so that is why it does not take advantage of it. Does usbmon somehow not work for you? 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: [RFC PATCH] USB: enable "power/wakeup" to control remote wakeup in the runtime suspend
On Thu, Jul 19, 2012 at 11:42:57AM +0200, Oliver Neukum wrote: > On Thursday 19 July 2012 15:42:37 Lan Tianyu wrote: > > On 2012年07月19日 14:37, Oliver Neukum wrote: > > > > But this leaves me with a question. Has anybody ever measured the > > > additional > > > power savings compared to a suspended state for devices? Or are you doing > > > this only as a prelude to become able to send host controllers to D3cold? > > hi Oliver: > > I have done a test on a usb3.0 ORICO SSD which may cost 3w normally. > > Traditional suspend can save 1w. Power off can save additional 2w. I also > > test > > Well, then the device violates the standard for power consumption. Not necessarily. Tianyu, are you measuring the whole system power consumption or just the power drawn by the device? How are you measuring power consumption? Also, are you sure the mass storage device was actually suspended? Unfortunately, userspace polls unmounted drives every two seconds or so to see if there's a medium change. So even though you may have enabled auto-suspend, userspace will still be waking the device out of suspend every two seconds. That might explain your high suspend power consumption. You would need to unload the mass storage driver to truly measure uninterrupted suspend power consumption. You can also set the power/autosuspend_delay_ms to something very low, like 10, in order to get the mass storage device into suspend faster than every two seconds. 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: [RFC PATCH] USB: enable "power/wakeup" to control remote wakeup in the runtime suspend
On Thu, Jul 19, 2012 at 09:27:55PM +0200, Oliver Neukum wrote: > On Thursday 19 July 2012 10:42:23 Alan Stern wrote: > > > > > > 1) remote wakeup is requested > > > 2) user space has blocked it via the new sysfs attribute > > > 3) USB_QUIRK_RESET_MORPHS is set > > > > The same is true for external ports if they are marked as > > non-removable. For example, consider a compound keyboard/mouse device > > with a built-in hub. The connections from the keyboard and the mouse > > to the hub are internal and not removable. > > True. So the decisive factor is not just being internal. Sure, we can tell whether an external device is removable by looking at the hub "DeviceRemovable" bit for each port. However, the port power off mechanism will only work for roothub ports on the Intel system. I suppose external USB 2.0 or USB 3.0 hubs might actually be able to power off ports as well. 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: Kernel tracing options with USB subsystem
A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Fri, Jul 20, 2012 at 10:14:57PM +0530, Balakumar wrote: > Hi Greg, > > When it comes to embedded device cases, I feel that the options are > just left with debug messages. It becomes really difficult to debug > some SMP specific issues, thread deadlocks etc. I felt that, using > trace events, we could effectively log some of those specific data > without the penalty of compromising latency which happens with > printks. Again, where in the usb core are we using printks for tracing? We don't do that except for the "usb snoop" mode for usbfs, and that's there primarily to help reverse engineer other operating systems, and it works pretty well for that task. > usbmon is perfect, but USB-centric. The background behind my queries > was that, is there someway we could trace out whats happening in the > USB which also contains the kernel information, like the cpu%d it is > running, the task context etc. > > I am fairly new to linux, so please correct me if I got my > understanding wrong :) usbmon is usb-centric, as that is what it was written for. What exactly are you wanting to see here that could help you out more than what usbmon provides? usbmon is there to monitor the flow of data across the usb wire, not to do any performance testing or really care about anything outside of the USB core at all. If you need/want more, we will be glad to work to provide it, but we need specific use-cases and examples to work off of. So, to start with, what specific problems are you having with USB on your platform that you need better tracing information for to help resolve the issues? 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: [RFC PATCH for v3.5 0/2] usb: gadget: at91_udc: fix oops regression
On Thu, Jul 19, 2012 at 03:50:19PM -0700, Greg Kroah-Hartman wrote: > > Greg: Any chance to get this two bugfixes into the current release? > > It's too late for 3.5, sorry, but patches can always be backported to > stable releases if they are causing problems. As you wish. I repost them in a few against your usb-next tree because #1 does not apply. > 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
[PATCH 1/2] usb/at91udc: don't overwrite driver data
The driver was converted to the new start/stop interface in f3d8bf34c2
("usb: gadget: at91_udc: convert to new style start/stop interface").
I overlooked that the driver is overwritting the private data which is
used by the composite framework. The udc driver doesn't read it, it is
only written here.
Tested-by: Fabio Porcedda
Tested-by: Mario Isidoro
Cc: # v3.5
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/gadget/at91_udc.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c
index c9e66df..14df835 100644
--- a/drivers/usb/gadget/at91_udc.c
+++ b/drivers/usb/gadget/at91_udc.c
@@ -1635,7 +1635,6 @@ static int at91_start(struct usb_gadget *gadget,
udc->driver = driver;
udc->gadget.dev.driver = &driver->driver;
udc->gadget.dev.of_node = udc->pdev->dev.of_node;
- dev_set_drvdata(&udc->gadget.dev, &driver->driver);
udc->enabled = 1;
udc->selfpowered = 1;
@@ -1656,7 +1655,6 @@ static int at91_stop(struct usb_gadget *gadget,
spin_unlock_irqrestore(&udc->lock, flags);
udc->gadget.dev.driver = NULL;
- dev_set_drvdata(&udc->gadget.dev, NULL);
udc->driver = NULL;
DBG("unbound from %s\n", driver->driver.name);
--
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
[PATCH 2/2] usb/at91udc: Don't check for ep->ep.desc
Earlier we used to check for ep->ep.desc to figure out if this ep has
already been enabled and if so, abort.
Ido Shayevitz removed the usb_endpoint_descriptor from private udc
structure 5a6506f00 ("usb: gadget: Update at91_udc to use
usb_endpoint_descriptor inside the struct usb_ep") but did not fix up
the ep_enable condition because _now_ the member is always true and we
can't check if this ep is enabled twice.
Cc: Ido Shayevitz
Tested-by: Fabio Porcedda
Tested-by: Mario Isidoro
Cc: # v3.5
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/gadget/at91_udc.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c
index 14df835..1e35963 100644
--- a/drivers/usb/gadget/at91_udc.c
+++ b/drivers/usb/gadget/at91_udc.c
@@ -475,8 +475,7 @@ static int at91_ep_enable(struct usb_ep *_ep,
unsigned long flags;
if (!_ep || !ep
- || !desc || ep->ep.desc
- || _ep->name == ep0name
+ || !desc || _ep->name == ep0name
|| desc->bDescriptorType != USB_DT_ENDPOINT
|| (maxpacket = usb_endpoint_maxp(desc)) == 0
|| maxpacket > ep->maxpacket) {
@@ -530,7 +529,6 @@ ok:
tmp |= AT91_UDP_EPEDS;
__raw_writel(tmp, ep->creg);
- ep->ep.desc = desc;
ep->ep.maxpacket = maxpacket;
/*
--
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
[PATCHv3 2/2] ARM: vt8500: Add support for UHCI companion controller
Add support for a generic non-pci UHCI companion controller.
Existing board files for arch-vt8500 updated to include UHCI
support.
Signed-off-by: Tony Prisk
---
V3:
Added the missing commits for the board files.
arch/arm/mach-vt8500/bv07.c |1 +
arch/arm/mach-vt8500/devices-vt8500.c |5 +
arch/arm/mach-vt8500/devices-wm8505.c |4 +
arch/arm/mach-vt8500/devices.c| 11 +++
arch/arm/mach-vt8500/devices.h|1 +
arch/arm/mach-vt8500/wm8505_7in.c |1 +
drivers/usb/host/Kconfig | 12 ++-
drivers/usb/host/uhci-hcd.c |5 +
drivers/usb/host/uhci-platform.c | 157 +
9 files changed, 195 insertions(+), 2 deletions(-)
create mode 100644 drivers/usb/host/uhci-platform.c
diff --git a/arch/arm/mach-vt8500/bv07.c b/arch/arm/mach-vt8500/bv07.c
index a464c75..19d20d9 100644
--- a/arch/arm/mach-vt8500/bv07.c
+++ b/arch/arm/mach-vt8500/bv07.c
@@ -32,6 +32,7 @@ static struct platform_device *devices[] __initdata = {
&vt8500_device_uart0,
&vt8500_device_lcdc,
&vt8500_device_ehci,
+ &vt8500_device_uhci,
&vt8500_device_ge_rops,
&vt8500_device_pwm,
&vt8500_device_pwmbl,
diff --git a/arch/arm/mach-vt8500/devices-vt8500.c
b/arch/arm/mach-vt8500/devices-vt8500.c
index 19519ae..def7fe3 100644
--- a/arch/arm/mach-vt8500/devices-vt8500.c
+++ b/arch/arm/mach-vt8500/devices-vt8500.c
@@ -48,6 +48,11 @@ void __init vt8500_set_resources(void)
tmp[1] = wmt_irq_res(IRQ_EHCI);
wmt_res_add(&vt8500_device_ehci, tmp, 2);
+ /* vt8500 uses a single IRQ for both EHCI and UHCI controllers */
+ tmp[0] = wmt_mmio_res(VT8500_UHCI_BASE, SZ_512);
+ tmp[1] = wmt_irq_res(IRQ_EHCI);
+ wmt_res_add(&vt8500_device_uhci, tmp, 2);
+
tmp[0] = wmt_mmio_res(VT8500_GEGEA_BASE, SZ_256);
wmt_res_add(&vt8500_device_ge_rops, tmp, 1);
diff --git a/arch/arm/mach-vt8500/devices-wm8505.c
b/arch/arm/mach-vt8500/devices-wm8505.c
index db4594e..c810454 100644
--- a/arch/arm/mach-vt8500/devices-wm8505.c
+++ b/arch/arm/mach-vt8500/devices-wm8505.c
@@ -55,6 +55,10 @@ void __init wm8505_set_resources(void)
tmp[1] = wmt_irq_res(IRQ_EHCI);
wmt_res_add(&vt8500_device_ehci, tmp, 2);
+ tmp[0] = wmt_mmio_res(WM8505_UHCI_BASE, SZ_512);
+ tmp[1] = wmt_irq_res(IRQ_UHCI);
+ wmt_res_add(&vt8500_device_uhci, tmp, 2);
+
tmp[0] = wmt_mmio_res(WM8505_GEGEA_BASE, SZ_256);
wmt_res_add(&vt8500_device_ge_rops, tmp, 1);
diff --git a/arch/arm/mach-vt8500/devices.c b/arch/arm/mach-vt8500/devices.c
index 1fcdc36..46ff82d 100644
--- a/arch/arm/mach-vt8500/devices.c
+++ b/arch/arm/mach-vt8500/devices.c
@@ -204,6 +204,17 @@ struct platform_device vt8500_device_ehci = {
},
};
+static u64 uhci_dma_mask = DMA_BIT_MASK(32);
+
+struct platform_device vt8500_device_uhci = {
+ .name = "platform-uhci",
+ .id = 0,
+ .dev= {
+ .dma_mask = &uhci_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
struct platform_device vt8500_device_ge_rops = {
.name = "wmt_ge_rops",
.id = -1,
diff --git a/arch/arm/mach-vt8500/devices.h b/arch/arm/mach-vt8500/devices.h
index 188d4e1..0e6d9f9 100644
--- a/arch/arm/mach-vt8500/devices.h
+++ b/arch/arm/mach-vt8500/devices.h
@@ -81,6 +81,7 @@ extern struct platform_device vt8500_device_uart5;
extern struct platform_device vt8500_device_lcdc;
extern struct platform_device vt8500_device_wm8505_fb;
extern struct platform_device vt8500_device_ehci;
+extern struct platform_device vt8500_device_uhci;
extern struct platform_device vt8500_device_ge_rops;
extern struct platform_device vt8500_device_pwm;
extern struct platform_device vt8500_device_pwmbl;
diff --git a/arch/arm/mach-vt8500/wm8505_7in.c
b/arch/arm/mach-vt8500/wm8505_7in.c
index cf910a9..302ae2f 100644
--- a/arch/arm/mach-vt8500/wm8505_7in.c
+++ b/arch/arm/mach-vt8500/wm8505_7in.c
@@ -31,6 +31,7 @@ static void __iomem *pmc_hiber;
static struct platform_device *devices[] __initdata = {
&vt8500_device_uart0,
&vt8500_device_ehci,
+ &vt8500_device_uhci,
&vt8500_device_wm8505_fb,
&vt8500_device_ge_rops,
&vt8500_device_pwm,
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 83e58df..3d153d0 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -450,7 +450,7 @@ config USB_OHCI_LITTLE_ENDIAN
config USB_UHCI_HCD
tristate "UHCI HCD (most Intel and VIA) support"
- depends on USB && (PCI || SPARC_LEON)
+ depends on USB && (PCI || SPARC_LEON || ARCH_VT8500)
---help---
The Universal Host Controller Interface is a standard by Intel for
accessing the USB hardware in the PC (which is also called the USB
@@ -468,7 +468,15 @@ config USB_UHCI_HCD
config USB_UHCI_SUPPORT_NON_PCI_
[PATCH 1/2] ARM: vt8500: Update vt8500-ehci driver to support device tree.
Signed-off-by: Tony Prisk
---
.../devicetree/bindings/usb/vt8500-ehci.txt| 10 ++
drivers/usb/host/ehci-vt8500.c |9 +
2 files changed, 19 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/vt8500-ehci.txt
diff --git a/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
b/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
new file mode 100644
index 000..74f75c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
@@ -0,0 +1,10 @@
+VIA VT8500 and Wondermedia WM8xxx SoC USB controllers.
+
+Required properties:
+ - compatible: Should be "via,vt8500-ehci" or "wm,prizm-ehci".
+
+usb: ehci@D8007100 {
+ compatible = "wm,prizm-ehci", "usb-ehci";
+ reg = <0xD8007100 0x200>;
+ interrupts = <1>;
+};
diff --git a/drivers/usb/host/ehci-vt8500.c b/drivers/usb/host/ehci-vt8500.c
index c1eda73..4ba8f0c 100644
--- a/drivers/usb/host/ehci-vt8500.c
+++ b/drivers/usb/host/ehci-vt8500.c
@@ -16,6 +16,7 @@
*
*/
+#include
#include
static int ehci_update_device(struct usb_hcd *hcd, struct usb_device *udev)
@@ -162,6 +163,12 @@ static int vt8500_ehci_drv_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id vt8500_ehci_ids[] = {
+ { .compatible = "via,vt8500-ehci", },
+ { .compatible = "wm,prizm-ehci", },
+ {}
+};
+
static struct platform_driver vt8500_ehci_driver = {
.probe = vt8500_ehci_drv_probe,
.remove = vt8500_ehci_drv_remove,
@@ -169,7 +176,9 @@ static struct platform_driver vt8500_ehci_driver = {
.driver = {
.name = "vt8500-ehci",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(vt8500_ehci_ids),
}
};
MODULE_ALIAS("platform:vt8500-ehci");
+MODULE_DEVICE_TABLE(of, vt8500_ehci_ids);
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] firmware load: defer request_firmware during early boot and resume
CC guys who discussed the problem in the below link in Jan. :
http://marc.info/?t=13252895602&r=10&w=2
On Fri, Jul 20, 2012 at 8:33 PM, Ming Lei wrote:
> The RFC patch is just for discussing if the idea of deferring
> request_firmware is doable for addressing the issue of
> request_firmware in resume path, which is caused by driver
> unbind/rebind during resume.
>
> At least usb bus is involved in such things, one driver may be
> unbound and rebound in resume path at several situations, and
> request_firmware is often called inside probe().
>
> Also the idea should be helpful for other hotplug buses too,
> at least there was the similar problem report on pcmcia bus.
Looks it works well in my two test cases: one is to call request_firmware
in early boot(initcall), another one is to call request_firmware in probe()
of resume path(caused by unbind & rebind). And without the patch, both
two request_firmware return failure and can't complete the loading.
V1:
only defer handling the requests called from probe()
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 6cd2c6c..fb02eff 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -123,7 +123,7 @@ static bool driver_deferred_probe_enable = false;
* list and schedules the deferred probe workqueue to process them. It
* should be called anytime a driver is successfully bound to a device.
*/
-static void driver_deferred_probe_trigger(void)
+void driver_deferred_probe_trigger(void)
{
if (!driver_deferred_probe_enable)
return;
@@ -144,6 +144,7 @@ static void driver_deferred_probe_trigger(void)
*/
queue_work(deferred_wq, &deferred_probe_work);
}
+EXPORT_SYMBOL_GPL(driver_deferred_probe_trigger);
/**
* deferred_probe_initcall() - Enable probing of deferred devices
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 5401814..1b13536 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include "base.h"
#define to_dev(obj) container_of(obj, struct device, kobj)
@@ -593,6 +594,11 @@ request_firmware(const struct firmware
**firmware_p, const char *name,
if (IS_ERR_OR_NULL(fw_priv))
return PTR_RET(fw_priv);
+ /* only defer handling the requests called from probe() */
+ if (!klist_node_attached(&device->p->knode_driver) &&
+ system_state != SYSTEM_RUNNING)
+ return -EPROBE_DEFER;
+
ret = usermodehelper_read_trylock();
if (WARN_ON(ret)) {
dev_err(device, "firmware: %s will not be loaded\n", name);
diff --git a/include/linux/device.h b/include/linux/device.h
index d0e4d99..a63d3171 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -244,7 +244,7 @@ extern struct device_driver *driver_find(const char *name,
struct bus_type *bus);
extern int driver_probe_done(void);
extern void wait_for_device_probe(void);
-
+extern void driver_deferred_probe_trigger(void);
/* sysfs interface for exporting driver attributes */
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index e07f5e0..c8d74c6 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -378,6 +378,7 @@ extern enum system_states {
SYSTEM_POWER_OFF,
SYSTEM_RESTART,
SYSTEM_SUSPEND_DISK,
+ SYSTEM_SUSPEND,
} system_state;
#define TAINT_PROPRIETARY_MODULE 0
diff --git a/init/main.c b/init/main.c
index e60679d..02fc1c2 100644
--- a/init/main.c
+++ b/init/main.c
@@ -809,6 +809,9 @@ static noinline int init_post(void)
current->signal->flags |= SIGNAL_UNKILLABLE;
flush_delayed_fput();
+ /* defer handling request_firmware in probe of initcall path */
+ driver_deferred_probe_trigger();
+
if (ramdisk_execute_command) {
run_init_process(ramdisk_execute_command);
printk(KERN_WARNING "Failed to execute %s\n",
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 1da39ea..61c723f 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -224,6 +224,9 @@ int suspend_devices_and_enter(suspend_state_t state)
goto Recover_platform;
}
suspend_test_finish("suspend devices");
+
+ system_state = SYSTEM_SUSPEND;
+
if (suspend_test(TEST_DEVICES))
goto Recover_platform;
@@ -301,6 +304,12 @@ static int enter_state(suspend_state_t state)
Finish:
pr_debug("PM: Finishing wakeup.\n");
suspend_finish();
+
+ system_state = SYSTEM_RUNNING;
+
+ /* defer handling request_firmware in probe of resume path */
+ driver_deferred_probe_trigger();
+
Unlock:
mutex_unlock(&pm_mutex);
return error;
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More
