This patch is trying to fix this bug on SLES11 SP2:
https://bugzilla.novell.com/show_bug.cgi?id=817035
On a large HP system with 64T memory and 60 logical cpus, when usb
driver inits the iLo Virtual USB Controller, there comes a warning
"Controller not stopped yet!". It is because driver does
I send out this patch for the second time.
Changed try to int. And modified the comment.
On 04/25/2013 03:11 PM, Li, Zhen-Hua wrote:
This patch is trying to fix this bug on SLES11 SP2:
https://bugzilla.novell.com/show_bug.cgi?id=817035
On a large HP system with 64T memory and 60 logical cp
Hi,
On Wed, Apr 24, 2013 at 10:40:51PM +0300, panu.finn...@iki.fi wrote:
> We are having problems when trying to connect LAN9512 to AM3517 MUSB.
> The Ethernet connection runs fine for a while, but randomly stops every
> now and then (ifdown eth0; ifup eth0 solves the problem). When LAN9512
> is c
On Wed, Apr 24, 2013 at 10:05:46AM -0700, Michal Nazarewicz wrote:
> On Wed, Apr 24 2013, Geert Uytterhoeven wrote:
> > If gcc (e.g. 4.1.2) decides not to inline cdc_config_register() and
> > rndis_config_register(), this will cause section mismatch warnings:
> >
> > WARNING: drivers/usb/gadget/g_m
Hey Paul,
> > In the current code / my patches I also have SOF, NPTxFEmp and RxFLvl
> > marked (and handled) as a host interrupt, but I suspect that these three
> > are used for device mode as well? However, since we don't have
> > device handlers for them already, shouldn't they be cleared by
> >
From: Wei Yongjun
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Introduced by commit cf9a08ae5aece88987bbeee8eb0dd0ebb5015815
(usb: gadget: convert source sink and loopback to new function interface)
Signed-off-by: Wei Yongjun
Hi Paul,
> > Before, the DISCONNINT interrupt was enabled in
> > dwc2_enable_host_interrupts, but handled in dwc2_handle_common_intr,
> > while the RXFLVL interrupt was enabled in dwc2_enable_commont_interrupts
> > and handled in dwc_handle_hcd_intr.
>
> And, the RXFLVL interrupt is a host+device
On Wednesday 24 April 2013 07:31:25 Dan Williams wrote:
> So how do we go forward from here... I'm happy to update the patchset
> with anything needed to get davem to apply it. Have we decided to keep
> the memflags for now, and thus should I just resubmit with a summary of
> the discussion unde
Now that Fabio has written a few patches to this driver I'd like his help
in reviewing this series, can you make sure he gets a copy? Also
please include Praveena and Mian, thanks.
On Tue, Apr 23, 2013 at 5:03 PM, Lee Jones wrote:
> For all ux500 based platforms the maximum number of end-points
On Tue, Apr 23, 2013 at 5:03 PM, Lee Jones wrote:
> The MUSB HDRC configuration never changes between each of the ux500
> supported platforms, so there's little point passing it though platform
> data. If we set it in the driver instead, we can make good use of it
> when booting with either ATAGs
On Tue, Apr 23, 2013 at 5:03 PM, Lee Jones wrote:
> The dma_mask will always be the same as the coherent_dma_mask, so let's
> cut down on the platform_data burden and set it as such in the driver.
> This also saves us from supporting it separately when we come to enable
> this driver for Device T
Hi,
>> This is the stack dump when the completion routine is called without
>> an interrupt occurring first, is it useful?
>>
>> Backtrace:
>> [] (dump_backtrace+0x0/0x110) from []
>> (dump_stack+0x18/0x1c)
>> r6:bf030da8 r5:c12aec00 r4:c12b4c00 r3:00f8
>> [] (dump_stack+0x0/0x1c) from []
>>
On Wed, Apr 24, 2013 at 5:04 PM, Lee Jones wrote:
> In its current state, the ux500-musb driver uses platform data pointers
> blindly with no prior checking. If no platform data pointer is passed
> this will Oops the kernel. In this patch we ensure platform data and
> board data are present prior
On Wed, Apr 24, 2013 at 5:05 PM, Lee Jones wrote:
> If we can ever get to a state where we can solely search for DMA channels
> by name, this will almost completely alleviate the requirement to pass
> copious amounts of information though platform data. Here we take the
> first step towards this.
On Wed, Apr 24, 2013 at 9:43 AM, Lee Jones wrote:
> usb: musb: ux500: add device tree probing support
>
> This patch will allow ux500-musb to be probed and configured solely from
> configuration found in Device Tree.
>
> Cc: Felipe Balbi
> Cc: linux-usb@vger.kernel.org
> Signed-off-by: Lee Jones
Hi Paul,
> If RXFLVL is a host+device mode interrupt, doesn't it make sense to
> enable it in both enable_host_interrupts and (the future)
> enable_device_interrupts instead of in enable_common_interrupts?
Hmm, I just realized the underlying thing here is that I'm
distinguishing "common" interrupt
On Thu, 25 Apr 2013, victor yeo wrote:
> Hi,
>
> >> This is the stack dump when the completion routine is called without
> >> an interrupt occurring first, is it useful?
> >>
> >> Backtrace:
> >> [] (dump_backtrace+0x0/0x110) from []
> >> (dump_stack+0x18/0x1c)
> >> r6:bf030da8 r5:c12aec00 r4:c
On Thu, 25 Apr 2013, ZhenHua wrote:
> I send out this patch for the second time.
> Changed try to int. And modified the comment.
You did not answer my question: How long does it take for the iLo
controller to go into suspend?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscr
On Wed, 24 Apr 2013, Julius Werner wrote:
> The current EHCI code sleeps a flat 110ms in the resume path if there
> was a USB 1.1 device connected to its companion controller during
> suspend, waiting for the device to reappear and reset so that it can be
> handed back to the companion. This is ne
On Thu, 25 Apr 2013, ZhenHua wrote:
> >>> +#define UHCI_SUSPENDRH_RETRY_MAX 10
> >>> +#define UHCI_SUSPENDRH_RETRY_DELAY100
> > Why is the delay set to 100 us? Isn't that excessively large? How
> > long does it take for this controller to go into suspend?
> This controller will take abo
On Thu, 25 Apr 2013, Alan Stern wrote:
> On Thu, 25 Apr 2013, ZhenHua wrote:
>
> > I send out this patch for the second time.
> > Changed try to int. And modified the comment.
>
> You did not answer my question: How long does it take for the iLo
> controller to go into suspend?
Oops, sorry, I
On Thu, Apr 25, 2013 at 7:38 AM, Alan Stern wrote:
> On Wed, 24 Apr 2013, Julius Werner wrote:
>
>> The current EHCI code sleeps a flat 110ms in the resume path if there
>> was a USB 1.1 device connected to its companion controller during
>> suspend, waiting for the device to reappear and reset so
On Thu, 25 Apr 2013, Julius Werner wrote:
> >> +extern int usb_for_each_dev(void *data, int (*fn)(struct usb_device *,
> >> void *));
> >
> > Line is too long.
>
> The limit is 80 (inclusive), right? Without the diff's leading '+' I
> count exactly that...
Oh, okay, sorry. I was fooled by the
Hi,
>> Yes, the kagen2_ep_queue() calls req->req.complete directly. I thought
>> this is necessary to pass the packets to gadget driver for processing?
>
> It is necessary to call req.complete when the request has _completed_!
> That's why the callback is named "complete"!
>
>> req->req.complete i
On Thu, 25 Apr 2013, Yuan-Hsin Chen wrote:
> Hi,
>
> Are there any comments?
This is okay. There's just one thing...
> On Tue, Apr 16, 2013 at 8:43 PM, Yuan-Hsin Chen wrote:
>
> > FUSBH200-HCD is an USB2.0 hcd for Faraday FUSBH200.
> > FUSBH200 is an ehci-like controller with some difference
On Wed, 24 Apr 2013, Sedat Dilek wrote:
> With CONFIG_USB_DEBUG=y I do not see a PM/async line.
>
> Might you have a look at the logs?
They look quite normal. Except for one thing: The built-in hubs appear
to have gotten reset during the suspend/resume, for no apparent reason.
That's probabl
On Thu, 25 Apr 2013, Sedat Dilek wrote:
> [ Run logging on USB-bus #1 ]
>
> # cat /sys/kernel/debug/usb/usbmon/1u > /tmp/usbmon-1u.txt <--- USB-bus #01
>
> [ Do suspend plus resume ]
>
> ...
>
> [ Check /tmp/usbmon-1u.txt file ]
>
> ...
>
> File attached!
That also looks normal. Did you ha
On Thu, Apr 25, 2013 at 5:44 PM, Alan Stern wrote:
> On Wed, 24 Apr 2013, Sedat Dilek wrote:
>
>> With CONFIG_USB_DEBUG=y I do not see a PM/async line.
>>
>> Might you have a look at the logs?
>
> They look quite normal. Except for one thing: The built-in hubs appear
> to have gotten reset during
On Thu, Apr 25, 2013 at 5:49 PM, Alan Stern wrote:
> On Thu, 25 Apr 2013, Sedat Dilek wrote:
>
>> [ Run logging on USB-bus #1 ]
>>
>> # cat /sys/kernel/debug/usb/usbmon/1u > /tmp/usbmon-1u.txt <--- USB-bus #01
>>
>> [ Do suspend plus resume ]
>>
>> ...
>>
>> [ Check /tmp/usbmon-1u.txt file ]
>>
>>
On Thu, 25 Apr 2013, victor yeo wrote:
> For bulk out endpoint, I code the kagen2_ep_queue() to read the
> packets from the USB hardware, then call bulk_out_complete() via
> req->req.complete. Is this the correct way?
While kagen2_ep_queue() is running, there shouldn't be any packets in
the USB h
On Thu, 25 Apr 2013, Sedat Dilek wrote:
> You want me to send a patch against usb-next to clarify a bit on the
> kernel-config options to be enabled as prereqs in case of
> usbmon-tracing. If you think it's worth or not let me know.
It's up to you. Documentation patches are always welcome.
Alan
The current EHCI code sleeps a flat 110ms in the resume path if there
was a USB 1.1 device connected to its companion controller during
suspend, waiting for the device to reappear and reset so that it can be
handed back to the companion. This is necessary if the device uses
persist, so that the com
On Thu, Apr 25 2013, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Introduced by commit cf9a08ae5aece88987bbeee8eb0dd0ebb5015815
> (usb: gadget: convert source sink and loopback to
On Thu, 25 Apr 2013, Sedat Dilek wrote:
> > That also looks normal. Did you have CONFIG_USB_DEBUG enabled during
> > this test? If you did, you could try turning it back off to see if the
> > original problem returns while still doing a usbmon trace.
> >
>
> As my system works as "expected" aft
The Kconfig entry for USB_OMAP unconditionally selects USB_ISP1301,
which is now only visible when USB_PHY is also enabled.
This adds an appropriate dependency and enables USB_PHY in the omap1
defconfig, avoiding these build warnings:
warning: (USB_OHCI_HCD && USB_OMAP) selects ISP1301_OMAP which
Like the EHCI driver, OHCI supports a large number of different platform
glue drivers by directly including them, which causes problems with
conflicting macro definitions in some cases. As more ARM architecture
specific back-ends are required to coexist in a single build, we should
split those out
Hi subsystem maintainers,
Here is another set of patches that resulted from build testing on
linux-next. Please apply directly into your trees if you agree,
or let me know if I made a mistake.
I can take whatever remains through the arm-soc tree if you prefer
that or I don't hear back.
A
The Kconfig entry for USB_EHCI_MSM unconditionally selects USB_MSM_OTG,
which is now only visible when USB_PHY is also enabled.
This adds an appropriate dependency and enables USB_PHY in the msm
defconfig, avoiding the Kbuild warning:
warning: (USB_EHCI_MSM) selects USB_MSM_OTG which has unmet di
The Kconfig entry for USB_LPC32XX unconditionally selects USB_ISP1301,
which is now only visible when USB_PHY is also enabled.
This adds an appropriate dependency and enables USB_PHY in the msm
defconfig, avoiding these build errors:
warning: (USB_LPC32XX) selects USB_ISP1301 which has unmet dire
On Thu, Apr 25, 2013 at 07:29:01PM +0200, Arnd Bergmann wrote:
> The Kconfig entry for USB_EHCI_MSM unconditionally selects USB_MSM_OTG,
> which is now only visible when USB_PHY is also enabled.
>
> This adds an appropriate dependency and enables USB_PHY in the msm
> defconfig, avoiding the Kbuild
On 25/04/13 19:29, Arnd Bergmann wrote:
> The Kconfig entry for USB_LPC32XX unconditionally selects USB_ISP1301,
> which is now only visible when USB_PHY is also enabled.
>
> This adds an appropriate dependency and enables USB_PHY in the msm
> defconfig, avoiding these build errors:
>
> warning:
> From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> Sent: Thursday, April 25, 2013 2:22 AM
>
> Hey Paul,
Hi Matthijs,
What say we just defer this change for now? Once we go to add the
device-mode handling, we will probably find out that further changes
will be required anyway.
For example, h
Hey Paul,
> What say we just defer this change for now? Once we go to add the
> device-mode handling, we will probably find out that further changes
> will be required anyway.
Possibly, yeah.
In any case, I'm about to send a new patch series which has the easy
fixes up front and then tries to mak
On Thursday 25 April 2013, Greg Kroah-Hartman wrote:
> > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> > index c558472..de94f26 100644
> > --- a/drivers/usb/host/Kconfig
> > +++ b/drivers/usb/host/Kconfig
> > @@ -188,6 +188,7 @@ config USB_EHCI_HCD_AT91
> > config USB_EHCI_MSM
Hi folks,
these are a few of the patches I sent earlier that are either already
acked by Paul, or should be simple enough.
I already have a new version of the other patches prepared as well (with
a bit less invasive changes), but I haven't thoroughly reviewed those
yet (and I'm out of time until
This flag is a deprecated NOOP, interrupt handlers are always run
with interupts disabled.
See commit 6932bf37 (genirq: Remove IRQF_DISABLED from core code), and
include/linux/interrupt.h:
* IRQF_DISABLED - keep irqs disabled when calling the action handler.
* DE
The handling for the IC2INT and RESTOREDONE interrupts just cleared the
interrupt flag, but did not do anything else. Since these interrupts are
not enabled anywhere, they should never trigger and there should never
be a need to clear their flags, so we can safely remove this code.
Signed-off-by:
This makes the function name more clear and consistent with
dwc2_handle_common_intr().
Signed-off-by: Matthijs Kooijman
---
v2: New patch
---
drivers/staging/dwc2/hcd.c | 2 +-
drivers/staging/dwc2/hcd.h | 4 ++--
drivers/staging/dwc2/hcd_intr.c | 2 +-
3 files changed, 4 insertions(+
The top-level hcd interrupt handlers already used irq_return_t, but the
functions to which it delegates the actual work and the common irq
handler returned plain ints. In addition, they used the IRQ_RETVAL in
the wrong way (but because of the values of the various constants, this
didn't result in w
> From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> Sent: Thursday, April 25, 2013 2:39 PM
>
> This makes the function name more clear and consistent with
> dwc2_handle_common_intr().
>
> Signed-off-by: Matthijs Kooijman
>
> ---
> v2: New patch
> ---
> drivers/staging/dwc2/hcd.c | 2 +-
> From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> Sent: Thursday, April 25, 2013 2:39 PM
>
> The handling for the IC2INT and RESTOREDONE interrupts just cleared the
> interrupt flag, but did not do anything else. Since these interrupts are
> not enabled anywhere, they should never trigger and
On Mon, 22 Apr 2013 12:35:26 -0700 (PDT) David Rientjes
wrote:
> On Fri, 19 Apr 2013, Joe Perches wrote:
>
> > @@ -966,11 +934,13 @@ static int realtek_cr_autosuspend_setup(struct
> > us_data *us)
> > static void realtek_cr_destructor(void *extra)
> > {
> > struct rts51x_chip *chip = (st
On 04/25/2013 10:54 PM, Alan Stern wrote:
On Thu, 25 Apr 2013, ZhenHua wrote:
+#define UHCI_SUSPENDRH_RETRY_MAX 10
+#define UHCI_SUSPENDRH_RETRY_DELAY100
Why is the delay set to 100 us? Isn't that excessively large? How
long does it take for this controller to go into suspend?
Thi
On 04/23/2013 05:14 PM, Sarah Sharp wrote:
On Tue, Apr 23, 2013 at 04:18:00PM -0400, Tony Camuso wrote:
It hangs in both suspend and resume with vanilla 3.9-rc7 and rc8.
Neither the new patch nor the old patch helps.
It might be unrelated to USB then. Let's see what the bisect shows.
It do
Hi,
> While kagen2_ep_queue() is running, there shouldn't be any packets in
> the USB hardware. The hardware should refuse to accept any packets,
> sending NAKs back to the host, until a request has been submitted and
> queued.
>
> When the request is queued, that's when you should tell the hardw
From: Wei Yongjun
Add the missing platform_device_put() before return from
omap2430_probe() in the error handling case.
Introduced by commit ca784be36cc725bca9b526eba342de7550329731
(usb: start using the control module driver)
Signed-off-by: Wei Yongjun
---
drivers/usb/musb/omap2430.c | 3 ++-
56 matches
Mail list logo
