Re: [PATCH] USB: add SPDX identifiers to all files in drivers/usb/

reg Kroah-Hartman > >> <gre...@linuxfoundation.org> wrote: > >> > It's good to have SPDX identifiers in all files to make it easier to > >> > audit the kernel tree for correct licenses. This patch adds these > >> > identifiers to all files in drivers/usb/ based o

Re: [PATCH] USB: add SPDX identifiers to all files in drivers/usb/

On Thu, 19 Oct 2017, Greg Kroah-Hartman wrote: > On Thu, Oct 19, 2017 at 10:50:44AM +0200, Thomas Gleixner wrote: > > The last discussion about this was to add the identifier as the first line > > of the file or as the second in case of files with a shebang in the first > >

Re: [PATCH] USB: add SPDX identifiers to all files in drivers/usb/

On Thu, 19 Oct 2017, Greg Kroah-Hartman wrote: > It's good to have SPDX identifiers in all files to make it easier to > audit the kernel tree for correct licenses. This patch adds these > identifiers to all files in drivers/usb/ based on a script and data from > Thomas Gleixn

Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

On Fri, 17 Feb 2017, Frederic Weisbecker wrote: > On Thu, Feb 16, 2017 at 08:34:45PM +0100, Thomas Gleixner wrote: > > On Thu, 16 Feb 2017, Frederic Weisbecker wrote: > > > On Thu, Feb 16, 2017 at 10:20:14AM -0800, Linus Torvalds wrote: > > > > On Thu, Feb 16, 2017 at

Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

On Thu, 16 Feb 2017, Frederic Weisbecker wrote: > On Thu, Feb 16, 2017 at 10:20:14AM -0800, Linus Torvalds wrote: > > On Thu, Feb 16, 2017 at 10:13 AM, Frederic Weisbecker > > wrote: > > > > > > I haven't followed the discussion but this patch has a known issue which > > > is

Re: [PATCH v4 1/4] usb: dbc: early driver for xhci debug capability

On Sat, 12 Nov 2016, Lu Baolu wrote: > On 11/11/2016 08:28 PM, Peter Zijlstra wrote: > > Again, a UART rules. Make a virtual UART in hardware, that'd be totally > > awesome. This thing, I'm not convinced its worth having. > > This is the initial work. It helps at least in cases where people need

Re: [PATCH v4 1/4] usb: dbc: early driver for xhci debug capability

On Thu, 10 Nov 2016, Lu Baolu wrote: > On 11/09/2016 05:37 PM, Thomas Gleixner wrote: > > On Tue, 1 Nov 2016, Lu Baolu wrote: > >> +static void early_xdbc_write(struct console *con, const char *str, u32 n) > >> +{ > >> + int chunk, ret; > >> + static

Re: [PATCH v4 1/4] usb: dbc: early driver for xhci debug capability

On Tue, 1 Nov 2016, Lu Baolu wrote: > +static void early_xdbc_write(struct console *con, const char *str, u32 n) > +{ > + int chunk, ret; > + static char buf[XDBC_MAX_PACKET]; > + int use_cr = 0; > + > + if (!xdbc.xdbc_reg) > + return; > + memset(buf, 0,

Re: [PATCH v4 1/4] usb: dbc: early driver for xhci debug capability

On Tue, 1 Nov 2016, Lu Baolu wrote: > +static int __init xdbc_init(void) > +{ ... > + base = ioremap_nocache(xdbc.xhci_start, xdbc.xhci_length); > + if (!base) { > + xdbc_trace("failed to remap the io address\n"); > + ret = -ENOMEM; > + goto

Re: [BUG] Lockdep splat in usb network gadget

On Wed, 23 Jul 2014, Li RongQing wrote: This commit introduced this bug commit a9232076374334ca2bc2a448dfde96d38a54349a Author: Jeff Westfahl jeff.westf...@ni.com Date: Thu May 29 09:49:41 2014 +0300 usb: gadget: u_ether: synchronize with transmit when stopping queue When

[BUG] Lockdep splat in usb network gadget

On a Intel E660/EG20T system I can observe the following lockdep splats: [ 10.154920] = [ 10.156026] [ INFO: inconsistent lock state ] [ 10.156026] 3.16.0-rc5+ #13 Not tainted [ 10.156026] - [ 10.156026] inconsistent

usb: musb: Ensure that cppi41 timer gets armed on premature DMA TX irq

hrtimer_start(). Use hrtimer_is_queued() instead of hrtimer_active() and evrything is good. Reported-by: Torben Hohn torb...@linutronix.de Signed-off-by: Thomas Gleixner t...@linutronix.de Cc: sta...@vger.kernel.org --- drivers/usb/musb/musb_cppi41.c |2 +- 1 file changed, 1 insertion(+), 1 deletion

Re: [PATCH] usb: mark *hci_pci irqs with IRQF_NO_THREAD

On Mon, 17 Feb 2014, Stanislaw Gruszka wrote: There is threadirqs kenel boot option which allow to force interrupt routines to be performed as thread. USB irq routines use spin_lock(*hci-lock) variant without disabling interrupts, what is perfectly fine, but that can cause deadlock when

Re: USB storage vanilla kernel 3.13 hang on DELL PRECISION M6400

On Fri, 14 Feb 2014, Stefani Seibold wrote: Am Freitag, den 14.02.2014, 10:32 -0500 schrieb Alan Stern: On Fri, 14 Feb 2014, Stefani Seibold wrote: Hi Alan; Am Donnerstag, den 13.02.2014, 15:55 -0500 schrieb Alan Stern: Stefani, please try the patch below, with threadirq

Re: USB storage vanilla kernel 3.13 hang on DELL PRECISION M6400

On Wed, 12 Feb 2014, Alan Stern wrote: I have no idea what might have changed between 3.12 and 3.13 to cause this problem. Maybe Thomas can figure it out. And yes, the issues goes away when no thread irqs are used (with and without the patch). Thomas, there must be some reason why the

Re: USB storage vanilla kernel 3.13 hang on DELL PRECISION M6400

On Thu, 13 Feb 2014, Alan Stern wrote: On Thu, 13 Feb 2014, Thomas Gleixner wrote: I can think of two other solutions. The first is to move the non-hardirq-safe hrtimers into threaded softirq context, as mentioned above. Right, but that's major surgery. The second is for ehci_hrtimer_func

Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context

On Fri, 14 Jun 2013, Alan Stern wrote: On Fri, 14 Jun 2013, Ming Lei wrote: With the two trace points of irq_handler_entry and irq_handler_exit, the interrupt latency(or the time taken by hard irq handler) isn't hard to measure. One simple script can figure out the average/maximum

Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context

On Wed, 12 Jun 2013, Ming Lei wrote: On Wed, Jun 12, 2013 at 3:10 AM, Alan Stern st...@rowland.harvard.edu wrote: Also the tasklet running in CPU0 can handle the work which should have been done by the same tasket scheduled in CPU1, so we can avoid busy-waitting in CPU1 which may be

Re: patch Revert USB/host: Cleanup unneccessary irq disable code added to usb tree

On Wed, 14 Nov 2012, Alan Stern wrote: On Tue, 13 Nov 2012 gre...@linuxfoundation.org wrote: From e592c5d0b7db94b485b4a2342db041a1882b7f75 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman gre...@linuxfoundation.org Date: Tue, 13 Nov 2012 10:52:52 -0800 Subject: Revert USB/host:

Re: patch Revert USB/host: Cleanup unneccessary irq disable code added to usb tree

On Thu, 15 Nov 2012, Alan Stern wrote: On Thu, 15 Nov 2012, Thomas Gleixner wrote: The main thing is that you need a real primary handler, which runs in hard interrupt context, because the USB interrupts are often shared and you don't want and cannot block out the other devices while you

Re: patch Revert USB/host: Cleanup unneccessary irq disable code added to usb tree

On Thu, 15 Nov 2012, Alan Stern wrote: On Thu, 15 Nov 2012, Thomas Gleixner wrote: I guess this amounts to the same thing as asking what happens if a device interrupt occurs while the threaded handler is running. Would the kernel then schedule the threaded handler to run a second

Re: patch Revert USB/host: Cleanup unneccessary irq disable code added to usb tree

On Thu, 15 Nov 2012, Thomas Gleixner wrote: On Thu, 15 Nov 2012, Alan Stern wrote: To prevent the timer handler from interfering with the threaded handler, should the threaded handler use spin_{un}lock_bh()? _irqsave() unfortunately as the hrtimer callbacks run in hard

Re: patch Revert USB/host: Cleanup unneccessary irq disable code added to usb tree

On Thu, 15 Nov 2012, Alan Stern wrote: On Thu, 15 Nov 2012, Thomas Gleixner wrote: Hmmm. Doesn't that mean there would be no benefit from using threaded interrupt handlers? Not versus the timers. Threaded interrupt handlers are handy, if you want to be able to schedule