Arnd Bergmann wrote:
sleep_on is known broken and going away. The atari_scsi driver is one of
two remaining users in the falcon_get_lock() function, which is a rather
crazy piece of code. This does not attempt to fix the driver's locking
scheme in general, but at least prevents falcon_get_lock
On Tue, Feb 25, 2014 at 11:40:17AM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven
>
> Add support for Dual/Quad SPI Transfers to the spidev API.
> As this uses SPI mode bits that don't fit in a single byte, two new
> ioctls (SPI_IOC_RD_MODE32 and SPI_IOC_WR_MODE32) are introduced.
On Tue, Feb 25, 2014 at 11:21:07AM +0100, Geert Uytterhoeven wrote:
> Hi Mark,
>
> This patch series refactors the sh-msiof SPI driver and adds support for
> the MSIOF variant in the Renesas R-Car H2 (r8a7790) and M2 (r8a7791) SoCs.
I applied all these, thanks. Laurent does make a valid
On Tue, Feb 25, 2014 at 11:40:19AM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven
>
> Use SPI_IOC_RD_MODE32 to print the full SPI mode, now in hex.
Applied, thanks.
signature.asc
Description: Digital signature
On Thu, Feb 27, 2014 at 08:45:01AM +0800, Xiubo Li wrote:
> o Add SND_SOC_DAIFMT_DSP_A support.
> o Add SND_SOC_DAIFMT_DSP_B support.
Applied, thanks.
signature.asc
Description: Digital signature
On Tue, Feb 25, 2014 at 11:40:18AM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven
Applied, thanks.
signature.asc
Description: Digital signature
On Tue, Feb 25, 2014 at 11:40:16AM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven
>
> In commit f477b7fb13df2b843997559ff34e87d054ba6538 ("spi: DUAL and QUAD
> support"), spi_device.mode was enlarged from 8 to 16 bits.
Applied, thanks.
> For SPI_IOC_WR_MODE this is probably not so
On Wed, Feb 26, 2014 at 10:22:05AM +0900, Jingoo Han wrote:
> Fix indent code style in order to fix the following checkpatch
> issues.
Applied, thanks.
signature.asc
Description: Digital signature
Since the NMI handlers(e.g. perf) can interrupt in the
single stepping (or preparing the single stepping, do_debug
etc.), we should consider a kprobe is hit in the NMI
handler. Even in that case, the kprobe is allowed to be
reentered as same as the kprobes hit in kprobe handlers
(KPROBE_HIT_ACTIVE
Current kprobes in-kernel page fault handler doesn't
expect that its single-stepping can be interrupted by
an NMI handler which may cause a page fault(e.g. perf
with callback tracing).
In that case, the page-fault handled by kprobes and it
misunderstands the page-fault has been caused by the
Prohibit probing on native_set_debugreg and native_load_idt.
Since the kprobes uses do_debug for single stepping,
functions called from do_debug before notify_die must not
be probed.
And also native_load_idt is called from paranoid_exit when
returning int3, this also must not be probed.
Introduce NOKPROBE_SYMBOL() macro which builds a kprobe
blacklist in build time. The usage of this macro is similar
to the EXPORT_SYMBOL, put the NOKPROBE_SYMBOL(function); just
after the function definition.
Since this macro will inhibit inlining of static/inline
functions, this patch also
Prohibit probing on debug_stack_reset and debug_stack_set_zero.
Since the both functions are called from TRACE_IRQS_ON/OFF_DEBUG
macros which run in int3 ist entry, probing it may cause a soft
lockup.
This happens when the kernel built with CONFIG_DYNAMIC_FTRACE=y
and CONFIG_TRACE_IRQFLAGS=y.
There is no need to prohibit probing on the functions
used in preparation phase. Those are safely probed because
those are not invoked from breakpoint/fault/debug handlers,
there is no chance to cause recursive exceptions.
Following functions are now removed from the kprobes blacklist.
can_boost
thunk/restore functions are also used for tracing irqoff etc.
and those are involved in kprobe's exception handling.
Prohibit probing on them to avoid kernel crash.
Signed-off-by: Masami Hiramatsu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
---
arch/x86/lib/thunk_32.S |3 ++-
There is no need to prohibit probing on the functions
used for preparation and uprobe only fetch functions.
Those are safely probed because those are not invoked
from kprobe's breakpoint/fault/debug handlers. So there
is no chance to cause recursive exceptions.
Following functions are now removed
Move exception_enter() call after kprobes handler
is done. Since the exception_enter() involves
many other functions (like printk), it can cause
recursive int3/break loop when kprobes probe such
functions.
Signed-off-by: Masami Hiramatsu
---
arch/x86/kernel/traps.c |5 ++---
1 file changed,
Use NOKPROBE_SYMBOL macro to protect functions from
kprobes instead of __kprobes annotation.
Signed-off-by: Masami Hiramatsu
Cc: Ananth N Mavinakayanahalli
Cc: "David S. Miller"
---
kernel/kprobes.c | 67 +-
1 file changed, 41
To avoid a kernel crash by probing on lockdep code, call
kprobe_int3_handler and kprobe_debug_handler directly
from do_int3 and do_debug. Since there is a locking code
in notify_die, lockdep code can be invoked. And because
the lockdep involves printk() related things, theoretically,
we need to
Allow kprobes on text_poke/hw_breakpoint because
those are not related to the critical int3-debug
recursive path of kprobes at this moment.
Signed-off-by: Masami Hiramatsu
---
arch/x86/kernel/alternative.c |3 +--
arch/x86/kernel/hw_breakpoint.c |5 ++---
2 files changed, 3
Use NOKPROBE_SYMBOL macro to protect functions from
kprobes instead of __kprobes annotation in notifier.
Signed-off-by: Masami Hiramatsu
---
kernel/notifier.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/kernel/notifier.c b/kernel/notifier.c
There is no need to prohibit probing on the functions
used for preparation, registeration, optimization,
controll etc. Those are safely probed because those are
not invoked from breakpoint/fault/debug handlers,
there is no chance to cause recursive exceptions.
Following functions are now removed
Show blacklist entries (function names with the address
range) via /sys/kernel/debug/kprobes/blacklist.
Signed-off-by: Masami Hiramatsu
Cc: Ananth N Mavinakayanahalli
Cc: "David S. Miller"
---
kernel/kprobes.c | 61 +++---
1 file changed, 53
Use NOKPROBE_SYMBOL macro to protect functions from
kprobes instead of __kprobes annotation in ftrace.
This applies nokprobe_inline annotation for some cases,
because NOKPROBE_SYMBOL() will inhibit inlining by
referring the symbol address.
Changes from previous:
- Use nokprobe_inline for
Use kprobe_blackpoint for blacklisting .entry.text and .kprobees.text
instead of arch_within_kprobe_blacklist. This also makes them visible
via (debugfs)/kprobes/blacklist.
Signed-off-by: Masami Hiramatsu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Ananth N Mavinakayanahalli
To blacklist the functions in a module (e.g. user-defined
kprobe handler and the functions invoked from it), expand
blacklist support for modules.
With this change, users can use NOKPROBE_SYMBOL() macro in
their own modules.
Signed-off-by: Masami Hiramatsu
Cc: Ananth N Mavinakayanahalli
Cc:
Use NOKPROBE_SYMBOL macro to protect functions from
kprobes instead of __kprobes annotation in sched/core.c.
Signed-off-by: Masami Hiramatsu
Cc: Ingo Molnar
Cc: Peter Zijlstra
---
kernel/sched/core.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
Since the kprobes itself owns a hash table to get a kprobe
data structure corresponding to the given ip address, there
is no need to test ftrace hash in ftrace side.
To achive better performance on ftrace-based kprobe,
FTRACE_OPS_FL_SELF_FILTER flag to ftrace_ops which means
that ftrace skips
Introduce kprobe cache to reduce cache misshits for
massive multiple kprobes.
For stress testing kprobes, we need to activate kprobes
as many as possible. This situation causes cache miss
hit storm on kprobe hash-list. kprobe hashlist is already
enlarged to 4k entries and this is still small for
Currently, since the kprobes expects to be used
with less than 100 probe points, its hash table
just has 64 entries. This is too little to handle
several thousands of probes.
Enlarge this to 4096 entires which just consumes
32KB (on 64bit arch) for better scalability.
Without this patch, enabling
Since the int3 itself disables the local_irq and kprobes
keeps it disabled while the single step has done, the
kernel preemption never happen while processing a kprobe.
This means that we don't need to disable/enable preemption.
Also, this changes kprobe_int3_handler to use goto-out style.
Use NOKPROBE_SYMBOL() to protect handlers from kprobes
in sample modules.
Signed-off-by: Masami Hiramatsu
Ananth N Mavinakayanahalli
---
samples/kprobes/jprobe_example.c|1 +
samples/kprobes/kprobe_example.c|3 +++
samples/kprobes/kretprobe_example.c |2 ++
3 files changed,
Use NOKPROBE_SYMBOL macro for protecting functions
from kprobes instead of __kprobes annotation under
arch/x86.
This applies nokprobe_inline annotation for some cases,
because NOKPROBE_SYMBOL() will inhibit inlining by
referring the symbol address.
This just folds a bunch of previous
Hi,
Here is the version 7 of NOKPROBE_SYMBOL series. :)
This includes several scalability improvements against massive
multiple probes (over 10k probes), which are useful for stress
testing of kprobes (putting kprobes on every function entry).
I also include bugfixes which I sent last week(*),
.entry.text is a code area which is used for interrupt/syscall
entries, and there are many sensitive codes.
Thus, it is better to prohibit probing on all of such codes
instead of a part of that.
Since some symbols are already registered on kprobe blacklist,
this also removes them from the
As time goes, the code changes a lot, and this leads to that
some old-days comments scatter around , which instead of faciliating
understanding, but make more confusion. So this patch cleans up them.
Also, this patch unifies some variables naming.
Signed-off-by: Jianyu Zhan
---
mm/slab.c | 66
Add i2c dts node properties for eDMA support, them depend on the eDMA driver.
Signed-off-by: Yuan Yao
---
arch/arm/boot/dts/vf610.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index 91a7757..9d14a19 100644
---
Added in v1:
- Enable dma if it's support dma and transfer size bigger than the threshold.
- Add device tree bindings for i2c eDMA support.
- Add eDMA support for i2c driver.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Add i2c dts node properties for eDMA support, them depend on the eDMA driver.
Signed-off-by: Yuan Yao
---
Documentation/devicetree/bindings/i2c/i2c-imx.txt | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.txt
Add dma support for i2c. This function depend on DMA driver.
You can turn on it by write both the dmas and dma-name properties in dts node.
And you should set ".has_dma_support" as true for dma support in imx_i2c_hwdata
struct.
Signed-off-by: Yuan Yao
---
drivers/i2c/busses/i2c-imx.c | 358
On Wed, Feb 26, 2014 at 06:13:06PM -0800, Josh Triplett wrote:
> The unconditionally built keyboard driver, drivers/s390/char/keyboard.c,
> requires CONFIG_TTY, so select it from CONFIG_S390 to prevent a build
> error.
>
> Signed-off-by: Josh Triplett
> ---
> arch/s390/Kconfig | 1 +
> 1 file
Am Donnerstag, 27. Februar 2014, 10:48:26 schrieb Pankaj Dubey:
> On 02/27/2014 09:16 AM, Mike Turquette wrote:
> > Quoting Pankaj Dubey (2014-02-25 21:24:07)
> >
> >> CC: Ben Dooks
> >> CC: Kukjin Kim
> >> CC: Russell King
> >> Signed-off-by: Pankaj Dubey
> >> ---
> >>
> >>
When the request length is aligned to maxpacketsize, sometimes
the return length ret > the user space requested len.
At that time, we will use min_t(size_t, ret, len) to limit the
size in case of user data buffer overflow.
But we need return the min_t(size_t, ret, len) to tell the user
space
On Sat, 2014-01-25 at 23:29 +0100, Richard Weinberger wrote:
> Commit beeb5a1e (thermal: rcar-thermal: Enable driver compilation with
> COMPILE_TEST)
> broke build on archs wihout io memory.
>
> On archs like S390 or um this driver cannot build nor work.
> Make it depend on HAS_IOMEM to bypass
Agree with Linus; this is starting to look pretty good.
I still have nits though :)
On Wed, Feb 26, 2014 at 4:07 PM, Davidlohr Bueso wrote:
> @@ -0,0 +1,45 @@
> +#ifndef __LINUX_VMACACHE_H
> +#define __LINUX_VMACACHE_H
> +
> +#include
> +
> +#ifdef CONFIG_MMU
> +#define VMACACHE_BITS 2
>
On Wed, 2014-02-05 at 17:43 -0800, Courtney Cavin wrote:
> This driver is a generic method for using IIO ADC channels as thermal
> sensors.
>
> Signed-off-by: Courtney Cavin
Eduardo,
what do you think of this patch?
thanks,
rui
> ---
> .../devicetree/bindings/thermal/iio-thermal.txt| 46
On Thursday 27 February 2014 12:11 PM, Loc Ho wrote:
Hi,
+
+static void sds_wr(void __iomem *csr_base, u32 indirect_cmd_reg,
+ u32 indirect_data_reg, u32 addr, u32 data)
+{
+ u32 val;
+ u32 cmd;
+
+ cmd = CFG_IND_WR_CMD_MASK | CFG_IND_CMD_DONE_MASK;
+
On Tue, 2014-01-14 at 14:45 -0400, Eduardo Valentin wrote:
> When registering a thermal zone, passing an invalid
> .governor_name via struct thermal_zone_params may
> create a thermal zone without a governor, when it
> is supposed to be the default governor.
>
> This patch fixes this issue by
On Thursday 27 February 2014 12:04 PM, Kishon Vijay Abraham I wrote:
On Thursday 27 February 2014 11:55 AM, Loc Ho wrote:
Hi,
+
+static void sds_wr(void __iomem *csr_base, u32 indirect_cmd_reg,
+ u32 indirect_data_reg, u32 addr, u32 data)
+{
+ u32 val;
+ u32 cmd;
Hi,
>> +
>> +static void sds_wr(void __iomem *csr_base, u32 indirect_cmd_reg,
>> + u32 indirect_data_reg, u32 addr, u32 data)
>> +{
>> + u32 val;
>> + u32 cmd;
>> +
>> + cmd = CFG_IND_WR_CMD_MASK | CFG_IND_CMD_DONE_MASK;
>> +
Arnd,
It's been a while since the first submission of these patches,
but a lot of them have made it into linux-next already, so here
is the stuff that is not merged yet, hopefully addressing all
the comments.
Geert and Michael: the I was expecting the ataflop and atari_scsi
patches to be
On Thursday 27 February 2014 11:55 AM, Loc Ho wrote:
Hi,
+
+static void sds_wr(void __iomem *csr_base, u32 indirect_cmd_reg,
+ u32 indirect_data_reg, u32 addr, u32 data)
+{
+ u32 val;
+ u32 cmd;
+
+ cmd = CFG_IND_WR_CMD_MASK | CFG_IND_CMD_DONE_MASK;
+
Hi,
+
+static void sds_wr(void __iomem *csr_base, u32 indirect_cmd_reg,
+ u32 indirect_data_reg, u32 addr, u32 data)
+{
+ u32 val;
+ u32 cmd;
+
+ cmd = CFG_IND_WR_CMD_MASK | CFG_IND_CMD_DONE_MASK;
+ cmd =
If poll or select is waiting on /proc/mdstat when md-mod is unloaded
an oops will ensure when the poll/select completes.
This is because the wait_queue_head which is registered with poll_wait()
is local to the module and no longer exists when the poll completes and
detaches that wait_queue_head
On 02/27/2014 02:04 AM, Mike Turquette wrote:
Quoting Lars-Peter Clausen (2014-02-17 01:31:53)
This patch adds support for the new v2 version of the axi-clkgen core.
Unfortunately the method of accessing the registers is quite different on v2,
while the content still stays largely the same. So
Hi all,
This tree fails (more than usual) the powerpc allyesconfig build.
Changes since 20140226:
The powerpc tree still had its build failure.
The libata tree lost its build failure.
The mfd-lj tree still had its build failure so I used the version from
next-20140210.
The drm-tegra tree
On Thursday 27 February 2014 02:15 AM, Loc Ho wrote:
Hi,
+config PHY_XGENE
+ tristate "APM X-Gene 15Gbps PHY support"
+ depends on ARM64 || COMPILE_TEST
+ select GENERIC_PHY
depends on HAS_IOMEM and CONFIG_OF..
I will make it depends as "HAS_IOMEM && OF && (ARM64 ||
These two patches initiate the switch of the pwm-backlight driver to
the gpiod GPIO interface, as it considerably simplifies the code.
For compatibility with current users of the driver, it is still possible
to pass the enable GPIO number as platform data. Two platforms are still
relying on this
The pwm-backlight driver is moving to use the gpiod interface,
which has its own mapping mechanism for platform data GPIOs.
These mappings carry GPIO properties like active low so they don't have
to be explicitly handled by GPIO consumers.
Because of this change, the enable_gpio_flags member of
Switch to the new gpiod interface, which allows to handle GPIO
properties such as active low transparently and removes a whole bunch of
code.
There are still a couple of users of this driver that rely on passing
the enable GPIO number through platform data, so a fallback mechanism
using a GPIO
Hi Greg,
On Wed, 26 Feb 2014 19:37:16 -0800 Greg KH wrote:
>
> On Wed, Feb 26, 2014 at 05:47:21PM +1100, Stephen Rothwell wrote:
> >
> > On Fri, 21 Feb 2014 16:47:11 +1100 Stephen Rothwell
> > wrote:
> > >
> > > After merging the char-misc tree, today's linux-next build (x86_64
> > >
On 27 February 2014 01:47, Saravana Kannan wrote:
> cpufreq_frequency_get_table() is called from all callers of
> __cpufreq_stats_create_table(). So, move it inside.
>
> Suggested-by: Viresh Kumar
> Signed-off-by: Saravana Kannan
> ---
> drivers/cpufreq/cpufreq_stats.c | 22
On 02/26/2014 09:19 PM, Andy Lutomirski wrote:
>>
>> The normal ABI almost certainly makes more sense; as such -mregparm=3 is
>> probably not what we want, and I suspect it makes more sense to just
>> drop that from the CFLAGS line?
>
> Hmm. What happens on a native 32-bit build? IIRC the whole
On Fri, 2014-02-21 at 17:22 +, Will Deacon wrote:
> The asm-generic rwsem implementation directly acceses sem->cnt when
> performing a __down_read_trylock operation. Whilst this is probably safe
> on all architectures, we should stick to the atomic_long_* API and use
> atomic_long_read
Hi Rashika,
On 26 February 2014 22:08, Rashika Kheria wrote:
> Mark function as static in cpufreq.c because it is not
> used outside this file.
>
> This eliminates the following warning in cpufreq.c:
> drivers/cpufreq/cpufreq.c:355:9: warning: no previous prototype for
> 'show_boost'
On Wed, Feb 26, 2014 at 10:06 PM, H. Peter Anvin wrote:
> On 02/26/2014 07:39 PM, Andi Kleen wrote:
>> On Wed, Feb 26, 2014 at 05:02:13PM -0800, Andy Lutomirski wrote:
>>> This makes no difference for 64-bit, bit it's critical for 32-bit code:
>>> these functions are called from outside the
On 02/26/2014 12:54 PM, Andy Lutomirski wrote:
> On Wed, Feb 26, 2014 at 12:45 PM, Greg KH wrote:
>> On Wed, Feb 26, 2014 at 08:34:58PM +0100, Stefani Seibold wrote:
>>> Hi,
>>>
>>> i still wait for ACK's for the 32 bit VDSO time function support. Whats
>>> the next step? Is there a way to apply
Reprogramming the DMA after tear down is initiated leads to warning.
This is mainly seen with ISOCH since we do a delayed completion for
ISOCH transfers. In ISOCH transfers dma_completion should not reprogram
if the channel tear down is initiated.
Signed-off-by: George Cherian
---
Start the channel tear down only if the channel is busy, else just
bail out. In some cases its seen that by the time the tear down is
initiated the cppi completes the DMA, especially in ISOCH transfers.
Signed-off-by: George Cherian
---
drivers/dma/cppi41.c | 7 +--
1 file changed, 5
Warinings are seen after ISOCH transfers, during channel tear down.
This is mainly beacause we handle ISOCH differently as compared to
other transfers.
Patch 1: make sure we do channel tear down only if channel is busy.
If not the tear down will never succeed.
Patch 2: ISOCH
On 02/26/2014 07:39 PM, Andi Kleen wrote:
> On Wed, Feb 26, 2014 at 05:02:13PM -0800, Andy Lutomirski wrote:
>> This makes no difference for 64-bit, bit it's critical for 32-bit code:
>> these functions are called from outside the kernel, so they need to comply
>> with the ABI.
>
> That's an odd
On 02/26/2014 07:39 PM, Andi Kleen wrote:
>
> Also you would rather need notrace more often.
>
Again, can be dealt with in CFLAGS, no?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
Hi Thierry,
Thanks very much, I will fix them all.
:)
--
Best Regards,
Xiubo
> Sorry for taking so long to get back to you. Things have been quite busy
> lately. A few more comments below, but we're getting there.
>
> On Wed, Feb 19, 2014 at 04:38:54PM +0800, Xiubo Li wrote:
> [...]
> > diff
Use devm_*() functions to make cleanup paths simpler.
Signed-off-by: Jingoo Han
---
drivers/char/hw_random/timeriomem-rng.c | 40 ---
1 file changed, 10 insertions(+), 30 deletions(-)
diff --git a/drivers/char/hw_random/timeriomem-rng.c
On 2014-02-26 20:42, Sam Bradshaw (sbradshaw) wrote:
On 2014-02-26 11:29, Christoph Hellwig wrote:
Hi all,
with blk-mq stabilizing in mainline and Jens using mtip32xx as tje
major
example drivers in the past is there any progress on getting the
conversion finished and merged?
I'll pick
Use devm_*() functions to make cleanup paths simpler.
Signed-off-by: Jingoo Han
---
drivers/char/hw_random/nomadik-rng.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/char/hw_random/nomadik-rng.c
b/drivers/char/hw_random/nomadik-rng.c
index
Use devm_clk_get() to make cleanup paths simpler.
Signed-off-by: Jingoo Han
---
drivers/char/hw_random/picoxcell-rng.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/char/hw_random/picoxcell-rng.c
b/drivers/char/hw_random/picoxcell-rng.c
index
Use devm_clk_get() to make cleanup paths simpler.
Signed-off-by: Jingoo Han
---
drivers/char/hw_random/omap3-rom-rng.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/omap3-rom-rng.c
b/drivers/char/hw_random/omap3-rom-rng.c
index c853e9e..6f2eaff
Quoting Nishanth Menon (2014-02-26 18:34:55)
> +/**
> + * pm_runtime_get_rate() - Returns the device operational frequency
> + * @dev: Device to handle
> + * @rate: Returns rate in Hz.
> + *
> + * Returns appropriate error value in case of error conditions, else
> + * returns 0 and rate
Use devm_clk_get() to make cleanup paths simpler.
Signed-off-by: Jingoo Han
---
drivers/char/hw_random/atmel-rng.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/char/hw_random/atmel-rng.c
b/drivers/char/hw_random/atmel-rng.c
index dfeddf2..851bc7e
Hi Thierry,
Today's linux-next merge of the pwm tree got a conflict in
arch/arm/Kconfig between commit f6723b569a67 ("usb: host: remove selects
of USB_ARCH_HAS_?HCI") from the usb tree and commit 557fe99d9d49 ("pwm:
Remove obsolete HAVE_PWM Kconfig symbol") from the pwm tree.
I fixed it up (see
On Thu, 2014-02-27 at 03:45 +, Ken Moffat wrote:
> On Thu, Feb 27, 2014 at 04:26:35AM +0100, Mike Galbraith wrote:
> >
> > I would start with strace to see if a task is looping in userspace, then
> > move on to perf top -g -p (or perf record/report) to peek at what
> > it's up to in the
Kieran Clancy wrote:
On Thu, Feb 27, 2014 at 12:29 PM, Li Guang wrote:
+#define ACPI_EC_CLEAR_MAX 20 /* Maximum number of events to
query
+* when trying to clear the EC */
20 is enough?
the query index is length of a byte.
> On 2014-02-26 11:29, Christoph Hellwig wrote:
> > Hi all,
> >
> > with blk-mq stabilizing in mainline and Jens using mtip32xx as tje
> major
> > example drivers in the past is there any progress on getting the
> > conversion finished and merged?
>
> I'll pick up the pieces as soon as I get
Hi,
Sasha, could you test if the bug you reported recently [1] reproduces
on the latest next tree with this patchset? (I'm not sure of this
because the problem looks differently in my own testing...)
[1] http://thread.gmane.org/gmane.linux.kernel.mm/113374/focus=113
---
Summary:
Naoya Horiguchi
When we try to walk over inside a vma, walk_page_range() tries to walk
until vma->vm_end even if a given end is before that point.
So this patch takes the smaller one as an end address.
Signed-off-by: Naoya Horiguchi
---
mm/pagewalk.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
vma_adjust() is called also for vma(VM_HUGETLB) and it could happen that
we happen to try to split hugetlbfs hugepage. So exclude the possibility.
Signed-off-by: Naoya Horiguchi
---
mm/mmap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git next-20140220.orig/mm/mmap.c
page->index stores pagecache index when the page is mapped into file mapping
region, and the index is in pagecache size unit, so it depends on the page
size. Some of users of reverse mapping obviously assumes that page->index
is in PAGE_CACHE_SHIFT unit, so they don't work for anonymous hugepage.
Hi Carl,
Thank you for the heads up. I believe Jason's patchset 4 of 4
(http://www.spinics.net/lists/linux-input/msg29435.html) fixed the
issue for your device and for other's. The patch was submitted last
month. If you can test the set on your device and give us a Tested-by
here, it will help
On 02/26/2014 08:26 PM, Ben Pfaff wrote:
>
>> Because sizeof(_Bool) is a little bit special compare to sizeof(long).
>> In the case of long, all sizeof(long) * 8 bits are use in the actual value.
>> But for the _Bool, only the 1 bit is used in the 8 bits size. In other words,
>> the _Bool has a
On Wed, Feb 26, 2014 at 10:15:08PM -0500, Dave Jones wrote:
> On Wed, Feb 26, 2014 at 05:34:24PM -0800, Greg KH wrote:
>
> > Yes, for some areas of the kernel it will take some work, but for
> > others, sparse works really well. As an example, building all of
> > drivers/usb/* with sparse
On Wed, Feb 26, 2014 at 08:19:23PM -0800, H. Peter Anvin wrote:
> On 02/26/2014 05:52 PM, Peter Hurley wrote:
> >
> > Well there was that "should we do a bug-fix-only 4.0 release?" message
> > from Linus back at the 3.12 release.
> >
>
> Sure... but will it actually happen?
I sure hope not,
On Wed, Feb 26, 2014 at 08:19:57PM -0800, H. Peter Anvin wrote:
> On 02/26/2014 08:00 PM, Ben Pfaff wrote:
> >
> > The commit *relaxed* sparse behavior: because previously sizeof(bool)
> > was an error. I'm not in favor of any diagnostic at all for
> > sizeof(bool), but my recollection is that a
On 02/26/2014 08:00 PM, Ben Pfaff wrote:
>
> The commit *relaxed* sparse behavior: because previously sizeof(bool)
> was an error. I'm not in favor of any diagnostic at all for
> sizeof(bool), but my recollection is that a sparse maintainer wanted it
> to yield one.
>
Still not clear as to
On 02/26/2014 05:52 PM, Peter Hurley wrote:
>
> Well there was that "should we do a bug-fix-only 4.0 release?" message
> from Linus back at the 3.12 release.
>
Sure... but will it actually happen?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Hi Hannes,
Although I sent you a message 6 days ago to ask your work which
is similar to my patch, I resend my patch because I'm considering
this problem should be fixed as soon as possible.
Thank you,
Yoshihiro YUNOMAE
(2014/02/27 13:17), Yoshihiro YUNOMAE wrote:
Output error messages using
On Wednesday 26 February 2014, Ken Moffat wrote:
>On Thu, Feb 27, 2014 at 04:26:35AM +0100, Mike Galbraith wrote:
>> I would start with strace to see if a task is looping in userspace,
>> then move on to perf top -g -p (or perf record/report) to peek
>> at what it's up to in the kernel. Once you
Output error messages using structured printk in single line.
In SCSI drivers, some error messages which should be output in single line are
divided in multiple lines. When user tools handle the error messages, those
divided messages will create some inconveniences.
The reason why this problem is
On Thu, Feb 27, 2014 at 09:37:45AM +0800, Xiubo Li wrote:
> I'm also thinking could we just discard snd_soc_codec_set_cache_io()
> calling from each individual driver to simply the code? And just bind
> it to devm_regmap_init_i2c() and devm_regmap_init_spi()...
> Is there any other limitations
On Wed, Feb 26, 2014 at 07:38:46PM -0800, Joe Perches wrote:
> (adding Ben Pfaff and Christopher Li)
>
> On Wed, 2014-02-26 at 19:29 -0800, H. Peter Anvin wrote:
> > On 02/26/2014 06:58 PM, Josh Triplett wrote:
> > > On Wed, Feb 26, 2014 at 06:53:14PM -0800, Joe Perches wrote:
> > >> Allow an
1 - 100 of 1722 matches
Mail list logo
