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
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 Gleixn
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
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,
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
23 matches
Mail list logo