t;
> Reported-by: Bernhard Landauer
> Reported-by: Ralf Ramsauer
> Signed-off-by: Sebastian Andrzej Siewior
ping
> ---
> drivers/hv/hyperv_vmbus.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
&g
On 2018-09-10 21:08:38 [+], KY Srinivasan wrote:
> It is in my queue; will submit it soon.
thank you for letting me know.
> K. Y
Sebastian
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/
On 2018-09-15 23:26:53 [+], Michael Kelley (EOSG) wrote:
> From Sebastian Andrzej Siewior Sent: Thursday, August 30, 2018 12:55 AM
> >
> > On !RT the header file get_irq_regs() gets pulled in via other header
> > files. On
> > RT it does not and the build fai
For spinlocks the type spinlock_t should be used instead of "struct
spinlock".
Use spinlock_t for spinlock's definition.
Cc: Greg Kroah-Hartman
Cc: Christian Gromm
Cc: de...@driverdev.osuosl.org
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/staging/most/net/net.c |
On 2019-07-06 12:02:53 [+0200], Greg Kroah-Hartman wrote:
> On Thu, Jul 04, 2019 at 05:38:00PM +0200, Sebastian Andrzej Siewior wrote:
> > For spinlocks the type spinlock_t should be used instead of "struct
> > spinlock".
>
> Why?
>
> > Use spinlock_t
-off-by: Sebastian Andrzej Siewior
---
drivers/staging/greybus/audio_manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/audio_manager.c
b/drivers/staging/greybus/audio_manager.c
index aa6508b44fab..045696ce85c7 100644
--- a/drivers/staging
‘get_irq_regs’
[-Werror=implicit-function-declaration]
Add the header file for get_irq_regs() in a common header so it used by
vmbus_drv.c by hv.c for their get_irq_regs() usage.
Reported-by: Bernhard Landauer
Reported-by: Ralf Ramsauer
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/hv
-by: Sebastian Andrzej Siewior
---
v1…v2: rebase to linux-next
Side note: Is there a reason the handle the down state very late at
CPU_DEAD time and use the counterpart of the online callback (the old
CPU_DOWN_PREPARE state).
.../staging/lustre/lnet/libcfs/linux/linux-cpu.c | 88
-by: Sebastian Andrzej Siewior
---
v2…v3: add the missing blank before the Cc: lines.
v1…v2: rebase to linux-next
Side note: Is there a reason the handle the down state very late at
CPU_DEAD time and use the counterpart of the online callback (the old
CPU_DOWN_PREPARE state).
.../staging/lustre
From: Anna-Maria Gleixner
Install the callbacks via the state machine.
Cc: Oleg Drokin
Cc: Andreas Dilger
Cc: James Simmons
Cc: Greg Kroah-Hartman
Cc: lustre-de...@lists.lustre.org
Cc: de...@driverdev.osuosl.org
Signed-off-by: Anna-Maria Gleixner
Signed-off-by: Sebastian Andrzej Siewior
The `ret´ variable is only initialized in the error case. For some reason
it was always != 0 while I played with generic_buffer so here is a patch.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/staging/iio/Documentation/iio_utils.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On 2020-07-16 09:57:18 [+0200], Peter Zijlstra wrote:
>
> there appear to be hardly any users left.. Can't we stage an extinction
> event here instead?
Most of the time the tasklet is scheduled from an interrupt handler. So
we could get rid of these tasklets by using threaded IRQs.
Sebastian
___
On 08/17/2013 01:18 AM, Aaro Koskinen wrote:
> Looking more into this (and after a failed testing attempt), I don't think
> we can simply delete octeon-usb if we want to keep supporting Octeon:
> there's also Octeon-specific registers of which the driver needs to
> take care of before/while using D
On 08/17/2013 10:44 PM, Paul Zimmerman wrote:
> Hi Greg, all,
>
> After taking a look at the Octeon driver, it looks like that controller
> uses a customized version of the DWC2 core - it has a different DMA
> engine than the one provided by the standard hardware. So in fact these
> two drivers ar
14 matches
Mail list logo