On Wed, 21 Aug 2019, Matthias Maennich wrote:
> USB_STORAGE was defined as "usb-storage: " and used in a single location
> as argument to printk. In order to be able to use the name
> 'USB_STORAGE', drop the definition and use the string directly for the
> printk call.
>
> Signed-off-by: Matthias
t; > 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 Gleixner, Philip
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
> >
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 G
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
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 fixed
> > > with:
>
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
>
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
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, XDBC_MAX_PAC
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 free_and_quit
On Wed, 23 Jul 2014, Li RongQing wrote:
> This commit introduced this bug
>
> commit a9232076374334ca2bc2a448dfde96d38a54349a
> Author: Jeff Westfahl
> Date: Thu May 29 09:49:41 2014 +0300
>
> usb: gadget: u_ether: synchronize with transmit when stopping queue
>
> When disconnecting,
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 {IN-HAR
ces the
DMA interrupt on CPU1 to call hrtimer_start().
Use hrtimer_is_queued() instead of hrtimer_active() and evrything is
good.
Reported-by: Torben Hohn
Signed-off-by: Thomas Gleixner
Cc: sta...@vger.kernel.org
---
drivers/usb/musb/musb_cppi41.c |2 +-
1 file changed, 1 insertion(+), 1 delet
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 wh
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 belo
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.
&g
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
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 th
On Wed, 12 Jun 2013, Ming Lei wrote:
> On Wed, Jun 12, 2013 at 3:10 AM, Alan Stern 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 introduced by tasklet_
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
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()
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 sched
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 o
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
> > Date: Tue, 13 Nov 2012 10:52:52 -0800
> > Subject: Revert "USB/host: Cleanup unneccessary i
24 matches
Mail list logo
