1 deletion(-)
> create mode 100644 arch/arm/boot/dts/mbx001.dts
With the rename mbx001.dts -> mbx0001.dts, this works fine for me on
the hardware platform, so:
Tested-by: Thomas Petazzoni
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
developme
: Rafael J. Wysocki
Cc: Andreas Herrmann
Cc: sta...@vger.kernel.org
Signed-off-by: Thomas Gleixner
---
drivers/cpufreq/powernow-k8.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
Index: linux-2.6/drivers/cp
of the cpu on which this is called. So we fail
to look at the partials of the dead cpu.
Correct this by extending the arguments of unfreeze_partials with the
target cpu number and use per_cpu_ptr instead of this_cpu_ptr.
Signed-off-by: Thomas Gleixner
---
mm/slub.c |8
1 file
On Sat, 27 Oct 2012, Tejun Heo wrote:
> Hello, Thomas.
>
> On Sat, Oct 27, 2012 at 07:29:25PM +0200, Thomas Gleixner wrote:
> > This is fully preemptible non cpu bound context though the comment in the
> > code says:
> >
> > * Must run on @pol->c
Dear RT Folks,
I'm pleased to announce the 3.6.3-rt8 release.
Changes since 3.6.3-rt7:
* Fix the SLUB fallout on NUMA machines
I missed to fixup the smp function calls which can result in a
deadlock on RT.
* Fix a mainline issue with cpufreq/powernow-k8 (Same patch is
queu
On Sun, 28 Oct 2012, Roland Stigge wrote:
>
> consider arch/arm/mach-lpc32xx/irq.c: irq_set_chained_handler() is
> called at a point where it accesses
> irq_to_desc(IRQ_LPC32XX_SUB2IRQ)->irq_data.hwirq but which is not yet
> initialized.
None of the functions which are called inside of
irq_set_ch
On Sun, 28 Oct 2012, Roland Stigge wrote:
> On 28/10/12 18:34, Thomas Gleixner wrote:
> > On Sun, 28 Oct 2012, Roland Stigge wrote:
> >> consider arch/arm/mach-lpc32xx/irq.c: irq_set_chained_handler() is
> >> called at a point where it accesses
> >> irq_to_desc(
Dear RT Folks,
I'm pleased to announce the 3.6.3-rt9 release.
Changes since 3.6.3-rt8:
* hrtimer fix for interrupt stall case (Watanabe)
* Disable RCU_FAST_NO_HZ. Uses a timer_list timer in the guts of
the irq disable idle code. Needs some thought
* Netfilter RT workaround
*
Dear RT Folks,
I'm pleased to announce the 3.6.4-rt10 release. This is just an update
to 3.6.4 with no RT related changes
The RT patch against 3.6.4 can be found here:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patch-3.6.4-rt10.patch.xz
The split quilt queue is available at:
On Mon, 29 Oct 2012, Tvrtko Ursulin wrote:
> On 29/10/12 20:14, Tvrtko Ursulin wrote:
> > Unless RT patchset is the culprit. Hm.. that would be unexpected, but I
> > guess it is worth a shot. I'll let you know what happens without -rt.
>
> Ha, this is exciting, vanilla 3.6.4 works, with -rt10 patc
parameter is added to combiner_init function that allows non-dt platform code
to specify the number of combiners available.
Signed-off-by: Thomas Abraham
---
arch/arm/mach-exynos/common.c | 210 +--
drivers/irqchip/Makefile|1 +
drivers/irqchip
On Mon, 29 Oct 2012, Thomas Gleixner wrote:
> Dear RT Folks,
>
> I'm pleased to announce the 3.6.4-rt10 release. This is just an update
> to 3.6.4 with no RT related changes
FYI, please disable SLUB and switch back to SLAB. Seems I took a bit
too naive approach of making i
On Tue, 30 Oct 2012, Christoph Lameter wrote:
> On Sat, 27 Oct 2012, Thomas Gleixner wrote:
>
> > Correct this by extending the arguments of unfreeze_partials with the
> > target cpu number and use per_cpu_ptr instead of this_cpu_ptr.
>
> Passing the kmem_cache_cpu po
On Tue, 30 Oct 2012, Milan Broz wrote:
> Fix crypto api for 3.6.4-rt10 (broken only in realtime patchset)
>
> In peterz-srcu-crypto-chain.patch the blocking notifier is changed
> to srcu notifier and added initialization to module init fucntion.
>
> Later, in crypto-make-core-static-and-init-scr
On Tue, 30 Oct 2012, Peter LaDow wrote:
> Anyway, based on earlier discussion, is there any reason not to use a
> lock (presuming any solution properly takes into account possible
> recursion)? I understand that the mainline is protected, but perhaps
> in the RT version we can use seqlock (and pre
Dear RT Folks,
I'm pleased to announce the 3.6.4-rt11 release.
Changes since 3.6.3-rt10:
* Crypto wreckage fix (Milan Broz)
Another proof why copy and paste should be forbidden, but if that
would happen most of us would be serving time.
* Another attempt to tame SLUB
My p
dn);
> }
With the integration of Ezequiel patches that add DT support to the
mvebu-mbus driver, this chunk of the code is no longer needed, as of
linux-next.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training a
ame
BG2 PJ4BArmada1500 Tauros3
MV88DE3100
BG2-CT Cortex-A9 N/A PL310 N/A
BG3 Cortex-A15 N/A CA15 integrated N/A
"""
As was told that the Armada X or MV88DEx names
Dear Sebastian Hesselbarth,
On Tue, 27 Aug 2013 18:45:45 +0200, Sebastian Hesselbarth wrote:
> > After talking a bit with engineers within Marvell that work on this
> > SoC, I'm inclined to think that using mach-mvebu for this family of SoC
> > is not a good idea.
>
suggested to guard that with __HAVE_ARCH_RELAXED_IO, which
indicates that _relaxed variants are available.
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe
mplementations/features of Dove, Kirkwood, and Armada 370?
I agree that mvebu-audio is not a really good compatible string. It
should use the first SoC that introduced the IP block, so that if
future SOCs have variations, we can introduce separate compatible
strings.
So for now, the compatible
t's the instance
0 or instance 1 ? If it's needed for some specific reason, then there
should probably be something like marvell,i2s-channel-id = <0> and
marvell,i2s-channel-id = <1>.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded
ence between the two units is the availability of
SPDIF support, then we shouldn't encode the channel number, but instead
the availability of SPDIF, i.e:
audio0 {
reg = <... ...>;
compatible = "marvell,kirkwood-audio";
marvell,has-spdif;
dmacap,xor;
};
xor11 {
interrupts = <52>;
dmacap,memcpy;
dmacap,xor;
ng "we have SPDIF" etc. That information
> should come solely from whether the SPDIF output has been "wired up".
>
> Let me put that another way: we _can_ provide those properties to
> indicate what facilities the hardware has, we just wouldn't use them
>
ill be complete.
What is the status of this generic simple audio card effort? I've seen
the patch you had posted at https://lkml.org/lkml/2013/7/20/128 and the
following discussion. Has anyone picked up the work of Kuninori
Morimoto?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, dr
er just to control this register, that is accessed infrequently
(i.e only when the kernel boots essentially), would require a lot of
code for no real benefit.
Does that clarify the intended usage?
Thanks for your feedback,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time an
Resolve all of the 'WARNING: space prohibited before semicolon'
checkpatch warnings for rtl8712.
Signed-off-by: Thomas Cort
---
drivers/staging/rtl8712/os_intfs.c| 2 +-
drivers/staging/rtl8712/rtl8712_cmd.c | 4 ++--
drivers/staging/rtl8712/rtl8712_efuse.c
s PCI_MSI is selected, the presence of
X86_IO_APIC is guaranteed. Moreover, the AMD_IOMMU already depended on
X86_64, which already guaranteed that X86_IO_APIC was enabled, so this
dependency was anyway redundant.
Signed-off-by: Thomas Petazzoni
Reported-by: Konrad Rzeszutek Wilk
Cc: bhelg...@goog
On Sun, 7 Jul 2013, Jason Cooper wrote:
> On Sun, Jul 07, 2013 at 05:30:31PM +0200, Thomas Gleixner wrote:
> I don't mind delaying half of a series so the drivers/ portion can land
> in mainline, and the rest can land in the next cycle. But when things
> don't go according
Linus,
please pull the latest core-printk-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
core-printk-for-linus
A single lock ordering fix in the printk code.
Thanks,
tglx
-->
Bu, Yitian (1):
printk: Fix rq->lock vs logbuf_l
Jul 08 23:37:33 localhost.localdomain kernel: BUG: unable to handle kernel
paging request at 000113b10038
Jul 08 23:37:33 localhost.localdomain kernel: IP: []
i915_gem_unmap_dma_buf+0x2f/0x60 [i915]
Jul 08 23:37:33 localhost.localdomain kernel: PGD 1135e0067 PUD 0
Jul 08 23:37:33 localhost.l
-mmp/time.c| 15 ++-
> 3 files changed, 5 insertions(+), 18 deletions(-)
Maybe it would be good to take this opportunity to move
arch/arm/mach-mmp/time.c into drivers/clocksource/.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulti
eviewed-by: quickly...
#define SUPPORT_OLD_POWER_EVENTS
could also vanish, maybe with the next round.
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/ma
Linus,
please pull the latest core-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
core-urgent-for-linus
* Header cleanup as requested by Linus
Thanks,
tglx
-->
Maarten Lankhorst (1):
mutex: Move ww_mutex definitions
Linus,
please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
* Fix for do_div() abuse on x86
* Locking fix in perf core
* A pile of (build) fixes and cleanups in perf tools
Thanks,
tglx
Linus,
please pull the latest timers-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-for-linus
* Watchdog fixes for full dynticks
* Improved debug output for full dynticks
* Remove an obsolete full dynticks check
* Two ARM SoC clock
Linus,
please pull the latest irq-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
irq-urgent-for-linus
* Core fix for missing round up in the generic irq chip
implementation
* New irq chip for MOXA SoCs
* A few fixes and cleanups in the
Linus,
please pull the latest sched-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-for-linus
* Fix a potential deadlock versus hrtimers.
Thanks,
tglx
-->
Peter Zijlstra (1):
sched: Fix HRTICK
kernel/
Linus,
please pull the latest x86-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-for-linus
* Guarantee IDT page alignment
* Revert an UEFI patch which caused a regression
* Add a missing check for EFI runtime services
* Fix fo
On Mon, 16 Sep 2013, Fan Du wrote:
> On 2013年09月13日 22:32, Thomas Gleixner wrote:
> > On Fri, 13 Sep 2013, Fan Du wrote:
> > > (2) What I have been bugging you around here for this long time is really
> > > the
> > > second
> > > problem, I'
timer_common_init(np);
+}
+CLOCKSOURCE_OF_DECLARE(armada_xp, "marvell,armada-xp-timer",
+ armada_xp_timer_init);
+
+static void __init armada_370_timer_init(struct device_node *np)
+{
+ struct clk *clk = of_clk_get(np, 0);
+
+ BUG_ON(IS_ERR(clk));
+ timer_clk =
On Mon, 16 Sep 2013, Thomas Gleixner wrote:
> Linus,
>
> please pull the latest timers/core git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
>
> * armada SoC clocksource overhaul with a trivial merge conflict
> * Minor imp
Hi everyone,
I need to ask something that's been bugging me for years. Suppose you have a
graphics adapter with both DisplayPort and HDMI ports, and both of them are
connected to different screens.
Then how do I decide where to route my audio signals?
Linux ALSA drivers only expose one generic c
The variable priv->kms is not initialized yet.
Found by "scripts/coccinelle/tests/odd_ptr_err.cocci".
PTR_ERR should access the value just tested by IS_ERR.
Signed-off-by: Thomas Meyer
---
diff -u -p a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
--- a/driver
Hi,
lockdep complains about this:
[ 92.041513] iwlwifi :02:00.0: L1 Enabled; Disabling L0S
[ 92.090910] iwlwifi :02:00.0: Radio type=0x1-0x2-0x0
[ 92.094779] =
[ 92.094780] [ INFO: inconsistent lock state ]
[ 92.094782] 3.10.10-rt7 #5 Not tainted
On Tue, 17 Sep 2013, Russell King - ARM Linux wrote:
> On Tue, Sep 17, 2013 at 11:56:00AM +0200, Ludovic Desroches wrote:
> > Any reason to not do this:
> >
> > --- a/drivers/clocksource/tcb_clksrc.c
> > +++ b/drivers/clocksource/tcb_clksrc.c
> > @@ -144,6 +144,9 @@ static void tc_mode(enum clock
The low level preemption code fiddles with the PREEMPT_ACTIVE bit for
no reason and calls schedule() with interrupts disabled, which is
wrong to begin with. Remove the PREEMPT_ACTIVE fiddling and call the
proper schedule_preempt_irq() function.
Signed-off-by: Thomas Gleixner
Cc: "David S. M
There is no reason for per arch hardirq bits. Make them all generic
Signed-off-by: Thomas Gleixner
---
arch/blackfin/include/asm/hardirq.h |3 ---
arch/cris/include/asm/hardirq.h | 12
arch/h8300/include/asm/hardirq.h| 12
arch/m32r/include/asm
There is no point in having PREEMPT_ACTIVE and HARDIRQ_BITS defined by
an architecture.
The PREEMPT_ACTIVE bit manipulation in the low level entry code is
historical and has been replaced by preempt_schedule_irq().
The HARDIRQ_BITS constant could be 1 in theory because we run all
interrupt handle
On Tue, 17 Sep 2013, Xie XiuQi wrote:
> The functions clocksource_updatefreq_hz() and clocksource_updatefreq_khz()
> do not exist, The proper ones are __clocksource_updatefreq_hz() and
> __clocksource_updatefreq_khz().
I'd rather rename the functions and the few call sites because the
underscores
Use the proper core function instead of fiddling with PREEMPT_ACTIVE
and enable/disable interrupts in the low level code.
Signed-off-by: Thomas Gleixner
Cc: Tony Luck
Cc: Fenghua Yu
Cc: linux-i...@vger.kernel.org
---
arch/ia64/kernel/entry.S | 15 +--
1 file changed, 1
Use the proper function instead of fiddling with PREEMPT_ACTIVE and
interrupt enable/disable in the low level code.
Signed-off-by: Thomas Gleixner
Cc: Yoshinori Sato
Cc: Geert Uytterhoeven
---
arch/h8300/kernel/entry.S |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
Index
No point in having this bit defined by architecture.
Signed-off-by: Thomas Gleixner
---
arch/alpha/include/asm/thread_info.h |2 --
arch/arc/include/asm/thread_info.h|2 --
arch/arm/include/asm/thread_info.h|6 --
arch/arm64/include/asm/thread_info.h
Use the proper core function instead of fiddling with preempt_active
and interrupt enable in the low level code.
Signed-off-by: Thomas Gleixner
Cc: Hirokazu Takata
Cc: linux-m32r...@ml.linux-m32r.org
---
arch/m32r/kernel/entry.S |8 +---
1 file changed, 1 insertion(+), 7 deletions
On Tue, 17 Sep 2013, Geert Uytterhoeven wrote:
> On Tue, Sep 17, 2013 at 8:53 PM, Thomas Gleixner wrote:
> > --- linux-2.6.orig/arch/m68k/include/asm/hardirq.h
> > +++ linux-2.6/arch/m68k/include/asm/hardirq.h
> > @@ -5,17 +5,6 @@
> > #include
> > #include
resulting nsec * evt->mult in the
programming path will therefor always be in the 64bit boundary.
Signed-off-by: Thomas Gleixner
---
diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 38959c8..4fc4826 100644
--- a/kernel/time/clockevents.c
+++ b/kernel
On Wed, 18 Sep 2013, Marc Kleine-Budde wrote:
> On 09/17/2013 11:15 PM, Thomas Gleixner wrote:
> > Marc Kleine-Budde pointed out, that commit 77cc982 "clocksource: use
> > clockevents_config_and_register() where possible" caused a regression
> > for some of the c
On Tue, 17 Sep 2013, David Miller wrote:
> From: Thomas Gleixner
> Date: Tue, 17 Sep 2013 18:53:08 -
>
> > bne,pn %xcc, kern_fpucheck
> > -sethi %hi(PREEMPT_ACTIVE), %l6
> > - stw
On Wed, 18 Sep 2013, Uwe Kleine-König wrote:
> > Now we can easily verify whether the whole equation fits into the
> > 64bit boundary. Shifting the "clc" result back by evt->shift MUST
> > result in "latch". If that's not the case, we have a clear indicator
> But this is only the case if evt->mult
On Tue, 17 Sep 2013, Thomas Gleixner wrote:
> On Tue, 17 Sep 2013, Geert Uytterhoeven wrote:
>
> > On Tue, Sep 17, 2013 at 8:53 PM, Thomas Gleixner wrote:
> > > --- linux-2.6.orig/arch/m68k/include/asm/hardirq.h
> > > +++ linux-2.6/arch/m68k/include/asm
,7 @@ config MACH_ARMADA_370_XP
> select HAVE_SMP
> select CACHE_L2X0
> select CPU_PJ4B
> + select CLKSRC_OF
I disagree. This should go to drivers/clocksource/Kconfig, because it's
the clocksource driver that uses CLOCKSOURCE_OF_DECLARE. See what is
already
On Wed, 18 Sep 2013, Uwe Kleine-König wrote:
> On Wed, Sep 18, 2013 at 11:38:07AM +0200, Thomas Gleixner wrote:
> > On Wed, 18 Sep 2013, Uwe Kleine-König wrote:
> > > Another doubt I have is: You changed clockevent_delta2ns to round up now
> > > unconditionally. F
On Wed, 18 Sep 2013, Sricharan R wrote:
> On Wednesday 18 September 2013 07:22 PM, Sricharan R wrote:
> > Hi Thomas,
> >
> > On Tuesday 17 September 2013 05:56 PM, Linus Walleij wrote:
> >> On Fri, Sep 13, 2013 at 4:24 PM, Thomas Gleixner
> >> wrote:
>
On Wed, 18 Sep 2013, Santosh Shilimkar wrote:
> On Friday 13 September 2013 10:55 AM, Santosh Shilimkar wrote:
> > On Friday 13 September 2013 10:24 AM, Thomas Gleixner wrote:
>
> [...]
>
> >> Before you dig into MSI, lets talk about irq domains first.
> >&
On Wed, 18 Sep 2013, Andrew Morton wrote:
> On Tue, 10 Sep 2013 21:13:34 + Christoph Lameter wrote:
> > + cpumask_copy(monitored_cpus, cpu_online_mask);
> > + cpumask_clear_cpu(tick_do_timer_cpu, monitored_cpus);
>
> What on earth are we using tick_do_timer_cpu for anyway?
> tick_do_time
On Thu, 19 Sep 2013, Uwe Kleine-König wrote:
> On Thu, Sep 19, 2013 at 12:01:25AM +0200, Thomas Gleixner wrote:
> > Versus the 64bit overflow check, we need to be even more careful. We
> > need to check for overflowing (1 << 63) - 1 (i.e. the max positive
> > value
On Thu, 19 Sep 2013, Uwe Kleine-König wrote:
> On Thu, Sep 19, 2013 at 12:15:10PM +0200, Thomas Gleixner wrote:
> > On Thu, 19 Sep 2013, Uwe Kleine-König wrote:
> > > On Thu, Sep 19, 2013 at 12:01:25AM +0200, Thomas Gleixner wrote:
> > > > Versus the 64bit overflow
nt could easily lead to an unnoticed shift
overflow. With the above rounding fix applied the calculation before
the divison is:
u64 clc = (latch << evt->shift) + evt->mult - 1;
So we need to make sure, that neither the shift nor the rounding add
is overflowing the u64 boundary.
Signed-o
Geert,
On Wed, 18 Sep 2013, Thomas Gleixner wrote:
> The low level entry code is fiddling with preempt_count by adding
> HARDIRQ_OFFSET to it to keep track of nested interrupts. If the count
> goes to 0, it invokes do_softirq(). And you have another safety guard:
>
> ret_from
sizeof when applied to a pointer typed expression gives the size of the
pointer.
Found by coccinelle spatch "misc/noderef.cocci"
Signed-off-by: Thomas Meyer
---
diff -u -p a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/
sizeof when applied to a pointer typed expression gives the size of the
pointer.
Found by coccinelle spatch "misc/noderef.cocci"
Signed-off-by: Thomas Meyer
---
diff -u -p a/arch/xtensa/platforms/iss/network.c
b/arch/xtensa/platforms/iss/network.c
--- a/arch/xtensa/platforms/iss
Use kzalloc rather than kmalloc followed by memset with 0.
Found by coccinelle spatch "api/alloc/kzalloc-simple.cocci"
Run against version v3.11-7547-g44598f9
Let me know when you as a maintainer are not interested in these kind of
patches.
I can exclude you by path; all cocci findings in e.g. "
sizeof when applied to a pointer typed expression gives the size of the
pointer.
Found by coccinelle spatch "misc/noderef.cocci"
Signed-off-by: Thomas Meyer
---
diff -u -p a/drivers/staging/rtl8188eu/core/rtw_mp.c
b/drivers/staging/rtl8188eu/core/rtw_mp.c
--- a/drivers/staging/rtl8
Use kzalloc rather than kmalloc followed by memset with 0.
Found by coccinelle spatch "api/alloc/kzalloc-simple.cocci"
Signed-off-by: Thomas Meyer
---
diff -u -p a/drivers/block/nvme-scsi.c b/drivers/block/nvme-scsi.c
--- a/drivers/block/nvme-scsi.c
+++ b/drivers/block/nvme-scsi.c
sizeof when applied to a pointer typed expression gives the size of the
pointer.
Found by coccinelle spatch "misc/noderef.cocci"
Signed-off-by: Thomas Meyer
---
diff -u -p a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
--- a/drive
sizeof when applied to a pointer typed expression gives the size of the
pointer.
Found by coccinelle spatch "misc/noderef.cocci"
Signed-off-by: Thomas Meyer
---
diff -u -p a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
--- a/drive
sizeof when applied to a pointer typed expression gives the size of the
pointer.
Found by coccinelle spatch "misc/noderef.cocci"
Signed-off-by: Thomas Meyer
---
diff -u -p a/drivers/scsi/csiostor/csio_mb.c b/drivers/scsi/csiostor/csio_mb.c
--- a/drivers/scsi/csiostor/csio_mb.c
+++
sizeof when applied to a pointer typed expression gives the size of the
pointer.
Found by coccinelle spatch "misc/noderef.cocci"
Signed-off-by: Thomas Meyer
---
diff -u -p a/drivers/staging/lustre/lustre/obdecho/echo_client.c
b/drivers/staging/lustre/lustre/obdecho/echo_client.c
---
sizeof when applied to a pointer typed expression gives the size of the
pointer.
Found by coccinelle spatch "misc/noderef.cocci"
Signed-off-by: Thomas Meyer
---
diff -u -p a/drivers/staging/octeon-usb/cvmx-usb.c
b/drivers/staging/octeon-usb/cvmx-usb.c
--- a/drivers/staging/octeo
Use kzalloc rather than kmalloc followed by memset with 0.
Found by coccinelle spatch "api/alloc/kzalloc-simple.cocci"
Signed-off-by: Thomas Meyer
---
diff -u -p a/drivers/scsi/aic7xxx/aic79xx_osm.c
b/drivers/scsi/aic7xxx/aic79xx_osm.c
--- a/drivers/scsi/aic7xxx/aic79xx_osm.c
+++
On Thu, 19 Sep 2013, Geert Uytterhoeven wrote:
> On Thu, Sep 19, 2013 at 7:02 PM, Andreas Schwab wrote:
> > Thomas Gleixner writes:
> >> + /*
> >> + * Only the last interrupt leaving the kernel goes through the
> >> +
sizeof when applied to a pointer typed expression gives the size of the
pointer.
Found by coccinelle spatch "misc/noderef.cocci"
Signed-off-by: Thomas Meyer
---
diff -u -p a/arch/mips/bcm47xx/sprom.c b/arch/mips/bcm47xx/sprom.c
--- a/arch/mips/bcm47xx/sprom.c
+++ b/arch/mips/bcm47
sizeof when applied to a pointer typed expression gives the size of the
pointer.
Found by coccinelle spatch "misc/noderef.cocci"
Run against version v3.11-7547-g44598f9
Let me know when you as a maintainer are not interested in these kind of
patches.
I can exclude you by path; all cocci findings
On Thu, 19 Sep 2013, Uwe Kleine-König wrote:
> > + u64 rnd = (u64) evt->mult - 1;
> >
> > if (unlikely(!evt->mult)) {
> > evt->mult = 1;
> > WARN_ON(1);
> > }
> I suggest to move the assignment to rnd below this if block as it
> changes mult.
True.
>
On Thu, 19 Sep 2013, Christoph Lameter wrote:
> On Thu, 19 Sep 2013, Thomas Gleixner wrote:
>
> > The vmstat accounting is not the only thing which we want to delegate
> > to dedicated core(s) for the full NOHZ mode.
> >
> > So instead of playing broken games wi
On Thu, 19 Sep 2013, Linus Torvalds wrote:
> On Thu, Sep 19, 2013 at 2:51 PM, Frederic Weisbecker
> wrote:
> >
> > It fixes stacks overruns reported by Benjamin Herrenschmidt:
> > http://lkml.kernel.org/r/1378330796.4321.50.camel%40pasglop
>
> So I don't really dislike this patch-series, but is
On Fri, 20 Sep 2013, Frederic Weisbecker wrote:
> Now just for clarity, what do we then do with inline sofirq
> executions: on local_bh_enable() for example, or explicit calls to
> do_softirq() other than irq exit? Should we keep the current switch
> to a different softirq stack? If we have a gen
UPPORTS_MSI kconfig
> option).
> After reverting this commit, sparc32:defconfig builds fine.
>
> sparc64 defconfig is unaffected.
Thanks for the report, I'll have a look very soon.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Li
ng
>all them one time.
This problem would persist, because the by far biggest table typically
is the DSDT with several ten thousand lines of code, while the other
tables typically only have some hundred.
Thomas
--
To unsubscribe from this list: send the line "unsubscribe l
bled. The
arch/sparc/kernel/pci_msi.c file is now only built when
SPARC64_PCI_MSI is true.
Signed-off-by: Thomas Petazzoni
Reported-by: Guenter Roeck
---
arch/sparc/Kconfig | 7 ++-
arch/sparc/kernel/Makefile | 3 ++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/
On Tue, 20 Aug 2013, Fan Du wrote:
> Thanks for your patience. Please let me take a few seconds try to
> explain this.
Sorry for the late reply.
> Current xfrm layers has *one* hrtimer to guard Ipsec keys timeout,
> The timeout could be measured in either of below two ways:
>
> (1) The timer i
On Thu, 29 Aug 2013, Libin wrote:
> If thread is preempted before calling set_current_state(TASK_INTERRUPTIBLE),
> and the other thread set the condition followed with wake_up_process. After
> that when this thread is re-scheduled, calling set_current_state to set itself
> as state TASK_INTERRUPTI
On Thu, 29 Aug 2013, Libin wrote:
> If this thread is preempted at(or before) location a, and the other thread
> set the condition(kthread_stop). After that when this thread is re-scheduled,
> calling set_current_state to set itself as state TASK_INTERRUPTIBLE, if it is
> preempted again after that
On Thu, 29 Aug 2013, Libin wrote:
> If thread is preempted before calling set_current_state(TASK_INTERRUPTIBLE),
> and the other thread set the condition followed with wake_up_process. After
> that when this thread is re-scheduled, calling set_current_state to set itself
> as state TASK_INTERRUPTI
On Tue, 20 Aug 2013, Chen Gang wrote:
> rt_mutex_finish_proxy_lock() can return failure code (e.g. -EINTR,
> -ETIMEDOUT).
>
> Original implementation has already noticed about it, but not check it
> before next work.
>
> Also let coments within 80 columns to pass "./scripts/checkpatch.pl".
>
>
On Thu, 12 Sep 2013, Herbert Xu wrote:
> On Thu, Sep 12, 2013 at 03:21:24PM +0200, Thomas Gleixner wrote:
> >
> > > (3): http://www.spinics.net/lists/netdev/msg245169.html
> >
> > Thanks for the explanation so far.
> >
> > What's still unclea
what they were doing (using them as completions, I want to
> > say?)
>
> We explicitly converted them away so that we could kill it. This was
> a joint project with Thomas.
>
> > Bcache isn't using the rw sem as a completion though, it really is a
> > read/write
ects - in i915 we have just one lock
and so suffer quite a bit more from contention. So no idea how much
removing the yield would hurt.
-Daniel
/Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
er since I'll be on my way to plumbers..
I think a possible fix would be if fault() were allowed to return an
error and drop the mmap_sem() before returning.
Otherwise we need to track down all copy_to_user / copy_from_user which
happen with bo::reserve held.
/Thomas
--
To unsubscr
401 - 500 of 21533 matches
Mail list logo
