[PATCH v1 0/9] ufs: sysfs: read-only access to device descriptors, attributes and flags

This patch introduces sysfs entries that will provide read-only access to device management data that could be received with UFS query requests. User-space applications will be able to read UFS device descriptors, flags and attributes. This will allow to get full UFS device configuration and its

[PATCH v1 0/9] ufs: sysfs: read-only access to device descriptors, attributes and flags

This patch introduces sysfs entries that will provide read-only access to device management data that could be received with UFS query requests. User-space applications will be able to read UFS device descriptors, flags and attributes. This will allow to get full UFS device configuration and its

Re: [PATCH v5 2/2] fs: fat: add ioctl method in fat filesystem driver

ChenGuanqiao writes: > +/* the characters in this field shall be d-characters, and unused byte shall > be set to 0x20. */ > +static int fat_format_d_characters(char *label, unsigned long len) > +{ > + int i; > + > + for (i=0; i +

Re: [PATCH v5 2/2] fs: fat: add ioctl method in fat filesystem driver

ChenGuanqiao writes: > +/* the characters in this field shall be d-characters, and unused byte shall > be set to 0x20. */ > +static int fat_format_d_characters(char *label, unsigned long len) > +{ > + int i; > + > + for (i=0; i + switch (label[i]) { > + case '0'

Re: [PATCH v5 1/2] fs: fat: Add fat filesystem partition volume label in local structure

ChenGuanqiao writes: > +static int fat_get_volume_label_entry(struct inode *dir, loff_t *pos, > +struct buffer_head **bh, > +struct msdos_dir_entry **de) > +{ > + while (fat_get_entry(dir, pos, bh, de) >= 0)

Re: [PATCH v5 1/2] fs: fat: Add fat filesystem partition volume label in local structure

ChenGuanqiao writes: > +static int fat_get_volume_label_entry(struct inode *dir, loff_t *pos, > +struct buffer_head **bh, > +struct msdos_dir_entry **de) > +{ > + while (fat_get_entry(dir, pos, bh, de) >= 0) > + if

Re: [PATCH 2/2 v4] scsi: ufs: introduce sysfs entries exposing UFS health info

On Wed, Dec 27, 2017 at 09:00:10AM +, Avri Altman wrote: > > > > -Original Message- > > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > > ow...@vger.kernel.org] On Behalf Of Greg Kroah-Hartman > > Sent: Thursday, December 21, 2017 10:00 AM > > To: Jaegeuk Kim

Re: [PATCH 2/2 v4] scsi: ufs: introduce sysfs entries exposing UFS health info

On Wed, Dec 27, 2017 at 09:00:10AM +, Avri Altman wrote: > > > > -Original Message- > > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > > ow...@vger.kernel.org] On Behalf Of Greg Kroah-Hartman > > Sent: Thursday, December 21, 2017 10:00 AM > > To: Jaegeuk Kim > > Cc:

cancel_work_sync() can cause priority invertion

Hi For those who care about linux RT behavior: while analyzing traces, just found priority inversion caused by RT task calling cancel_work_sync(), while work item in question is executing in non-RT kworker that was preempted for significant time. WBR, Nikita Yushchenko

cancel_work_sync() can cause priority invertion

Hi For those who care about linux RT behavior: while analyzing traces, just found priority inversion caused by RT task calling cancel_work_sync(), while work item in question is executing in non-RT kworker that was preempted for significant time. WBR, Nikita Yushchenko

Re: [PATCH 2/2] usb: quirks: Add reset-resume quirk for Dell DW1820 QCA Rome Bluetooth

On Tue, Dec 26, 2017 at 10:01:46PM +0100, Marcel Holtmann wrote: > Hi Greg, > > > Commit ("fd865802c66bc451dc515ed89360f84376ce1a56 Bluetooth: btusb: fix > > QCA Rome suspend/resume") enables reset_resume in btusb_probe(). This > > makes the device resets during btusb_open(), firmware loading

Re: [PATCH 2/2] usb: quirks: Add reset-resume quirk for Dell DW1820 QCA Rome Bluetooth

On Tue, Dec 26, 2017 at 10:01:46PM +0100, Marcel Holtmann wrote: > Hi Greg, > > > Commit ("fd865802c66bc451dc515ed89360f84376ce1a56 Bluetooth: btusb: fix > > QCA Rome suspend/resume") enables reset_resume in btusb_probe(). This > > makes the device resets during btusb_open(), firmware loading

Re: BUG warnings in 4.14.9

On Wed, Dec 27, 2017 at 04:25:00AM +, alexander.le...@verizon.com wrote: > On Tue, Dec 26, 2017 at 10:54:37PM +0200, Ido Schimmel wrote: > >On Tue, Dec 26, 2017 at 07:59:55PM +0100, Willy Tarreau wrote: > >> Guys, > >> > >> Chris reported the bug below and confirmed that reverting commit > >>

Re: BUG warnings in 4.14.9

On Wed, Dec 27, 2017 at 04:25:00AM +, alexander.le...@verizon.com wrote: > On Tue, Dec 26, 2017 at 10:54:37PM +0200, Ido Schimmel wrote: > >On Tue, Dec 26, 2017 at 07:59:55PM +0100, Willy Tarreau wrote: > >> Guys, > >> > >> Chris reported the bug below and confirmed that reverting commit > >>

Re: [RFC PATCH] memory-hotplug: add sysfs immovable_mem attribute

On Wed, Dec 27, 2017 at 08:30:12PM +0800, Chao Fan wrote: > In sometimes users specify the memory region in immovable node in > some kernel commandline, such as "kernel_core" or the "immovable_mem=" > in the patchset that I have send. But users don't know the memory > region. So add this interface

Re: [RFC PATCH] memory-hotplug: add sysfs immovable_mem attribute

On Wed, Dec 27, 2017 at 08:30:12PM +0800, Chao Fan wrote: > In sometimes users specify the memory region in immovable node in > some kernel commandline, such as "kernel_core" or the "immovable_mem=" > in the patchset that I have send. But users don't know the memory > region. So add this interface

[PATCH 3/5] kasan: detect invalid frees for large mempool objects

Detect frees of pointers into middle of mempool objects. I did a one-off test, but it turned out to be very tricky, so I reverted it. First, mempool does not call kasan_poison_kfree() unless allocation function fails. I stubbed an allocation function to fail on second and subsequent allocations.

[PATCH 3/5] kasan: detect invalid frees for large mempool objects

Detect frees of pointers into middle of mempool objects. I did a one-off test, but it turned out to be very tricky, so I reverted it. First, mempool does not call kasan_poison_kfree() unless allocation function fails. I stubbed an allocation function to fail on second and subsequent allocations.

Re: [PATCH 2/2] dts: Probe efuse for CI20

On Wed, Dec 27, 2017 at 01:27:02PM +0100, Mathieu Malaterre wrote: > Signed-off-by: Mathieu Malaterre I know i can't take patches without any changelog text at all, and really, you shouldn't ever create such a thing :) thanks, greg k-h

Re: [PATCH 2/2] dts: Probe efuse for CI20

On Wed, Dec 27, 2017 at 01:27:02PM +0100, Mathieu Malaterre wrote: > Signed-off-by: Mathieu Malaterre I know i can't take patches without any changelog text at all, and really, you shouldn't ever create such a thing :) thanks, greg k-h

[PATCH 5/5] kasan: detect invalid frees

Detect frees of pointers into middle of heap objects. Signed-off-by: Dmitry Vyukov Cc: linux...@kvack.org Cc: linux-kernel@vger.kernel.org Cc: kasan-...@googlegroups.com --- lib/test_kasan.c | 50 ++ mm/kasan/kasan.c | 6

[PATCH 5/5] kasan: detect invalid frees

Detect frees of pointers into middle of heap objects. Signed-off-by: Dmitry Vyukov Cc: linux...@kvack.org Cc: linux-kernel@vger.kernel.org Cc: kasan-...@googlegroups.com --- lib/test_kasan.c | 50 ++ mm/kasan/kasan.c | 6 ++ 2 files changed,

[PATCH 4/5] kasan: unify code between kasan_slab_free() and kasan_poison_kfree()

Both of these functions deal with freeing of slab objects. However, kasan_poison_kfree() mishandles SLAB_TYPESAFE_BY_RCU (must also not poison such objects) and does not detect double-frees. Unify code between these functions. This solves both of the problems and allows to add more common code

[PATCH 1/5] kasan: detect invalid frees for large objects

Detect frees of pointers into middle of large heap objects. I dropped const from kasan_kfree_large() because it starts propagating through a bunch of functions in kasan_report.c, slab/slub nearest_obj(), all of their local variables, fixup_red_left(), etc. Signed-off-by: Dmitry Vyukov

Re: [PATCH 1/3] staging: irda: fix type from "unsigned" to "unsigned int"

On Tue, Dec 26, 2017 at 09:52:54PM -0800, JI-HUN KIM wrote: > Clean up checkpatch warning: > WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > > Signed-off-by: JI-HUN KIM > --- > drivers/staging/irda/drivers/esi-sir.c | 4 ++-- > 1 file changed, 2 insertions(+), 2

[PATCH 0/5] kasan: detect invalid frees

KASAN detects double-frees, but does not detect invalid-frees (when a pointer into a middle of heap object is passed to free). We recently had a very unpleasant case in crypto code which freed an inner object inside of a heap allocation. This left unnoticed during free, but totally corrupted heap

[PATCH 1/5] kasan: detect invalid frees for large objects

Detect frees of pointers into middle of large heap objects. I dropped const from kasan_kfree_large() because it starts propagating through a bunch of functions in kasan_report.c, slab/slub nearest_obj(), all of their local variables, fixup_red_left(), etc. Signed-off-by: Dmitry Vyukov Cc:

Re: [PATCH 1/3] staging: irda: fix type from "unsigned" to "unsigned int"

On Tue, Dec 26, 2017 at 09:52:54PM -0800, JI-HUN KIM wrote: > Clean up checkpatch warning: > WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > > Signed-off-by: JI-HUN KIM > --- > drivers/staging/irda/drivers/esi-sir.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Please

[PATCH 0/5] kasan: detect invalid frees

KASAN detects double-frees, but does not detect invalid-frees (when a pointer into a middle of heap object is passed to free). We recently had a very unpleasant case in crypto code which freed an inner object inside of a heap allocation. This left unnoticed during free, but totally corrupted heap

[PATCH 4/5] kasan: unify code between kasan_slab_free() and kasan_poison_kfree()

Both of these functions deal with freeing of slab objects. However, kasan_poison_kfree() mishandles SLAB_TYPESAFE_BY_RCU (must also not poison such objects) and does not detect double-frees. Unify code between these functions. This solves both of the problems and allows to add more common code

[PATCH 2/5] kasan: don't use __builtin_return_address(1)

__builtin_return_address(1) is unreliable without frame pointers. With defconfig on kmalloc_pagealloc_invalid_free test I am getting: BUG: KASAN: double-free or invalid-free in (null) Pass caller PC from callers explicitly. Signed-off-by: Dmitry Vyukov Cc:

[PATCH 2/5] kasan: don't use __builtin_return_address(1)

__builtin_return_address(1) is unreliable without frame pointers. With defconfig on kmalloc_pagealloc_invalid_free test I am getting: BUG: KASAN: double-free or invalid-free in (null) Pass caller PC from callers explicitly. Signed-off-by: Dmitry Vyukov Cc: linux...@kvack.org Cc:

Re: [PATCH v2] x86/kexec: Exclude GART aperture from vmcore

On 12/27/17 at 01:25pm, Borislav Petkov wrote: > On Wed, Dec 27, 2017 at 03:44:49PM +0800, Baoquan He wrote: > > > yes, instead of crashing the machine (because GART may be initialized in > > > the > > > 2nd kernel, overlapping the 1st kernel memory, which the 2nd kernel with > > > its > > >

Re: [PATCH v2] x86/kexec: Exclude GART aperture from vmcore

On 12/27/17 at 01:25pm, Borislav Petkov wrote: > On Wed, Dec 27, 2017 at 03:44:49PM +0800, Baoquan He wrote: > > > yes, instead of crashing the machine (because GART may be initialized in > > > the > > > 2nd kernel, overlapping the 1st kernel memory, which the 2nd kernel with > > > its > > >

Re: [SIL2review] [PATCH] fixdep: free memory on second error path of do_config_file

On Mon, 18 Dec 2017, Masahiro Yamada wrote: 2017-12-15 17:23 GMT+09:00 Nicholas Mc Guire : On Thu, Dec 14, 2017 at 08:54:10PM +0100, Lukas Bulwahn wrote: Commit dee81e988674 ("fixdep: faster CONFIG_ search") introduces the memory leak when `map = mmap(...)` was replaced

Re: [SIL2review] [PATCH] fixdep: free memory on second error path of do_config_file

On Mon, 18 Dec 2017, Masahiro Yamada wrote: 2017-12-15 17:23 GMT+09:00 Nicholas Mc Guire : On Thu, Dec 14, 2017 at 08:54:10PM +0100, Lukas Bulwahn wrote: Commit dee81e988674 ("fixdep: faster CONFIG_ search") introduces the memory leak when `map = mmap(...)` was replaced with `map =

[PATCH] sched: cgroup: export nr_running for each cpu cgroup

Export the nr_running for each cpu cgroup could help us monitor the container conveniently. The total threads of cpu cgroup could be got from the tasks file, and it could also be got from pids subsystem. But we still donot know how many processes are running in a container, only if we traversal

[PATCH] sched: cgroup: export nr_running for each cpu cgroup

Export the nr_running for each cpu cgroup could help us monitor the container conveniently. The total threads of cpu cgroup could be got from the tasks file, and it could also be got from pids subsystem. But we still donot know how many processes are running in a container, only if we traversal

Re: [PATCH] objtool: Fix clang enum conversion warning

On Tue, 26 Dec 2017, Nick Desaulniers wrote: I sent a similar one recently: https://patchwork.kernel.org/patch/10131815/ (maybe Josh is just forwarding me an earlier fix?) Reviewed-by: Nick Desaulniers I actually submitted this (other) patch to LKML on

Re: [PATCH] objtool: Fix clang enum conversion warning

On Tue, 26 Dec 2017, Nick Desaulniers wrote: I sent a similar one recently: https://patchwork.kernel.org/patch/10131815/ (maybe Josh is just forwarding me an earlier fix?) Reviewed-by: Nick Desaulniers I actually submitted this (other) patch to LKML on 2017-12-10:

Re: [Ocfs2-devel] [PATCH] ocfs2: try a blocking lock before return AOP_TRUNCATED_PAGE

Hi Gang, I like your fix. It looks good to me. On 2017/12/27 17:30, Gang He wrote: > If we can't get inode lock immediately in the function > ocfs2_inode_lock_with_page() when reading a page, we should not > return directly here, since this will lead to a softlockup problem. > The method is to

Re: [Ocfs2-devel] [PATCH] ocfs2: try a blocking lock before return AOP_TRUNCATED_PAGE

Hi Gang, I like your fix. It looks good to me. On 2017/12/27 17:30, Gang He wrote: > If we can't get inode lock immediately in the function > ocfs2_inode_lock_with_page() when reading a page, we should not > return directly here, since this will lead to a softlockup problem. > The method is to

Re: [RFC PATCH] memory-hotplug: add sysfs immovable_mem attribute

The result in my virtual machine looks like this: [root@localhost ~]# cat /sys/devices/system/memory/immovable_mem

Re: [RFC PATCH] memory-hotplug: add sysfs immovable_mem attribute

The result in my virtual machine looks like this: [root@localhost ~]# cat /sys/devices/system/memory/immovable_mem

[RFC PATCH] memory-hotplug: add sysfs immovable_mem attribute

In sometimes users specify the memory region in immovable node in some kernel commandline, such as "kernel_core" or the "immovable_mem=" in the patchset that I have send. But users don't know the memory region. So add this interface to print it. It will show like this: "nn@ss,nn@ss,...". "nn"

[RFC PATCH] memory-hotplug: add sysfs immovable_mem attribute

In sometimes users specify the memory region in immovable node in some kernel commandline, such as "kernel_core" or the "immovable_mem=" in the patchset that I have send. But users don't know the memory region. So add this interface to print it. It will show like this: "nn@ss,nn@ss,...". "nn"

[PATCH 2/2] dts: Probe efuse for CI20

Signed-off-by: Mathieu Malaterre --- arch/mips/configs/ci20_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig index b5f4ad8f2c45..62c63617e97a 100644 --- a/arch/mips/configs/ci20_defconfig +++

[PATCH 2/2] dts: Probe efuse for CI20

Signed-off-by: Mathieu Malaterre --- arch/mips/configs/ci20_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig index b5f4ad8f2c45..62c63617e97a 100644 --- a/arch/mips/configs/ci20_defconfig +++

[PATCH 1/2] nvmem: add driver for JZ4780 efuse

From: PrasannaKumar Muralidharan This patch brings support for the JZ4780 efuse. Currently it only expose a read only access to the entire 8K bits efuse memory. Tested-by: Mathieu Malaterre Signed-off-by: PrasannaKumar Muralidharan

[PATCH 1/2] nvmem: add driver for JZ4780 efuse

From: PrasannaKumar Muralidharan This patch brings support for the JZ4780 efuse. Currently it only expose a read only access to the entire 8K bits efuse memory. Tested-by: Mathieu Malaterre Signed-off-by: PrasannaKumar Muralidharan --- .../ABI/testing/sysfs-driver-jz4780-efuse | 16

[PATCH 0/2] Add efuse driver for Ingenic JZ4780 SoC

This patchset bring support for read-only access to the JZ4780 efuse as found on MIPS Creator CI20. To keep the driver as simple as possible, it was not possible to re-use most of the nvmem core functionalities. This driver is not compatible with the original efuse driver as found in the custom

[PATCH 0/2] Add efuse driver for Ingenic JZ4780 SoC

This patchset bring support for read-only access to the JZ4780 efuse as found on MIPS Creator CI20. To keep the driver as simple as possible, it was not possible to re-use most of the nvmem core functionalities. This driver is not compatible with the original efuse driver as found in the custom

Re: [PATCH v2] x86/kexec: Exclude GART aperture from vmcore

On Wed, Dec 27, 2017 at 03:44:49PM +0800, Baoquan He wrote: > > yes, instead of crashing the machine (because GART may be initialized in the > > 2nd kernel, overlapping the 1st kernel memory, which the 2nd kernel with its > > fake e820 map sees as unused). > > > > I'd say this is an improvement.

Re: [PATCH v2] x86/kexec: Exclude GART aperture from vmcore

On Wed, Dec 27, 2017 at 03:44:49PM +0800, Baoquan He wrote: > > yes, instead of crashing the machine (because GART may be initialized in the > > 2nd kernel, overlapping the 1st kernel memory, which the 2nd kernel with its > > fake e820 map sees as unused). > > > > I'd say this is an improvement.

Re: [PATCH] clk: mediatek: remove unnecessary include header from reset.c

Hi Sean, Stephen, On Wed, 27 Dec 2017 11:33:00 +0800, Sean Wang wrote: > On Tue, 2017-12-26 at 17:10 -0800, Stephen Boyd wrote: > > drivers/clk/mediatek/reset.c:64:6: warning: symbol > > 'mtk_register_reset_controller' was not declared. Should it be static? > > It cannot be static since the

Re: [PATCH] clk: mediatek: remove unnecessary include header from reset.c

Hi Sean, Stephen, On Wed, 27 Dec 2017 11:33:00 +0800, Sean Wang wrote: > On Tue, 2017-12-26 at 17:10 -0800, Stephen Boyd wrote: > > drivers/clk/mediatek/reset.c:64:6: warning: symbol > > 'mtk_register_reset_controller' was not declared. Should it be static? > > It cannot be static since the

[PATCH IMPROVEMENT/BUGFIX 0/1] block, bfq: address starvation caused by tag consumption

Hi Jens, all, here's the patch I anticipated in my last email. It addresses (serious) starvation problems caused by request-tag exhaustion, as explained in more detail in the commit message. I started from the solution in the function kyber_limit_depth, but then I had to define more articulate

[PATCH IMPROVEMENT/BUGFIX 0/1] block, bfq: address starvation caused by tag consumption

Hi Jens, all, here's the patch I anticipated in my last email. It addresses (serious) starvation problems caused by request-tag exhaustion, as explained in more detail in the commit message. I started from the solution in the function kyber_limit_depth, but then I had to define more articulate

[PATCH IMPROVEMENT/BUGFIX 1/1] block, bfq: limit tags for writes and async I/O

Asynchronous I/O can easily starve synchronous I/O (both sync reads and sync writes), by consuming all request tags. Similarly, storms of synchronous writes, such as those that sync(2) may trigger, can starve synchronous reads. In their turn, these two problems may also cause BFQ to loose control

[PATCH IMPROVEMENT/BUGFIX 1/1] block, bfq: limit tags for writes and async I/O

Asynchronous I/O can easily starve synchronous I/O (both sync reads and sync writes), by consuming all request tags. Similarly, storms of synchronous writes, such as those that sync(2) may trigger, can starve synchronous reads. In their turn, these two problems may also cause BFQ to loose control

[PATCH] clk: qcom: Add support for controlling Fabia PLL

Fabia PLL is a Digital Frequency Locked Loop (DFLL) clock generator which has a wide range of frequency output. It supports dynamic updating of the output frequency ("frequency slewing") without need to turn off the PLL before configuration. Add support for initial configuration and programming

[PATCH] clk: qcom: Add support for controlling Fabia PLL

Fabia PLL is a Digital Frequency Locked Loop (DFLL) clock generator which has a wide range of frequency output. It supports dynamic updating of the output frequency ("frequency slewing") without need to turn off the PLL before configuration. Add support for initial configuration and programming

RE: [PATCH 1/4] lockd: convert nlm_host.h_count from atomic_t to refcount_t

> On Fri, Dec 22, 2017 at 09:25:53AM -0500, J. Bruce Fields wrote: > > On Fri, Dec 22, 2017 at 09:29:15AM +, Reshetova, Elena wrote: > > > > > > On Wed, Nov 29, 2017 at 01:15:43PM +0200, Elena Reshetova wrote: > > > > atomic_t variables are currently used to implement reference > > > >

RE: [PATCH 1/4] lockd: convert nlm_host.h_count from atomic_t to refcount_t

> On Fri, Dec 22, 2017 at 09:25:53AM -0500, J. Bruce Fields wrote: > > On Fri, Dec 22, 2017 at 09:29:15AM +, Reshetova, Elena wrote: > > > > > > On Wed, Nov 29, 2017 at 01:15:43PM +0200, Elena Reshetova wrote: > > > > atomic_t variables are currently used to implement reference > > > >

Re: [RESEND PATCH] blackfin: defconfig: Cleanup from old Kconfig options

On Wed, Dec 27, 2017 at 12:29:33PM +0100, Linus Walleij wrote: > On Tue, Dec 26, 2017 at 2:30 PM, Krzysztof Kozlowski wrote: > > > Remove old, dead Kconfig options (in order appearing in this commit): > > > > Signed-off-by: Krzysztof Kozlowski > > Acked-by:

Re: [RESEND PATCH] blackfin: defconfig: Cleanup from old Kconfig options

On Wed, Dec 27, 2017 at 12:29:33PM +0100, Linus Walleij wrote: > On Tue, Dec 26, 2017 at 2:30 PM, Krzysztof Kozlowski wrote: > > > Remove old, dead Kconfig options (in order appearing in this commit): > > > > Signed-off-by: Krzysztof Kozlowski > > Acked-by: Linus Walleij > > This

Re: [RESEND PATCH] blackfin: defconfig: Cleanup from old Kconfig options

On Tue, Dec 26, 2017 at 2:30 PM, Krzysztof Kozlowski wrote: > Remove old, dead Kconfig options (in order appearing in this commit): > - EXPERIMENTAL is gone since v3.9; > - INET_LRO: commit 7bbf3cae65b6 ("ipv4: Remove inet_lro library"); > - USB_DEVICE_CLASS: commit

Re: [RESEND PATCH] blackfin: defconfig: Cleanup from old Kconfig options

On Tue, Dec 26, 2017 at 2:30 PM, Krzysztof Kozlowski wrote: > Remove old, dead Kconfig options (in order appearing in this commit): > - EXPERIMENTAL is gone since v3.9; > - INET_LRO: commit 7bbf3cae65b6 ("ipv4: Remove inet_lro library"); > - USB_DEVICE_CLASS: commit 007bab91324e ("USB: remove

[PATCH] ASoC: rt5514-spi: Check the validity of drvdata pointer on resume

The rt5514-spi driver seem to assume the validity of the drvdata pointer on resume, which it may not be populated, leading to a not-so-nice crash. This stems from the fact that rt5514_spi_pcm_probe() is never called on my system (a kevin Chromebook). No idea why, but if it can happen, it is worth

[PATCH] ASoC: rt5514-spi: Check the validity of drvdata pointer on resume

The rt5514-spi driver seem to assume the validity of the drvdata pointer on resume, which it may not be populated, leading to a not-so-nice crash. This stems from the fact that rt5514_spi_pcm_probe() is never called on my system (a kevin Chromebook). No idea why, but if it can happen, it is worth

Re: [PATCH v2] gpio: winbond: add driver

On Wed, Dec 27, 2017 at 1:24 AM, William Breathitt Gray wrote: > Here are the error messages printed on my system when I add a select > ISA_BUS_API line to the GPIO_WINBOND Kconfig option in the version 2 of > your patch: > > drivers/gpio/Kconfig:13:error: recursive

Re: [PATCH v2] gpio: winbond: add driver

On Wed, Dec 27, 2017 at 1:24 AM, William Breathitt Gray wrote: > Here are the error messages printed on my system when I add a select > ISA_BUS_API line to the GPIO_WINBOND Kconfig option in the version 2 of > your patch: > > drivers/gpio/Kconfig:13:error: recursive dependency detected! > For a

Re: [PATCH 2/2] ARM: dts: imx6: RDU2: correct RTC compatible

Hi Andrey, On Wed, Dec 27, 2017 at 1:56 AM, Andrey Smirnov wrote: > The RTC is manufactured by Maxim. This is a cosmetic fix, as Linux > doesn't match the vendor string for i2c devices. > > Cc: Sascha Hauer > Cc: Fabio Estevam

Re: [PATCH 2/2] ARM: dts: imx6: RDU2: correct RTC compatible

Hi Andrey, On Wed, Dec 27, 2017 at 1:56 AM, Andrey Smirnov wrote: > The RTC is manufactured by Maxim. This is a cosmetic fix, as Linux > doesn't match the vendor string for i2c devices. > > Cc: Sascha Hauer > Cc: Fabio Estevam > Cc: Rob Herring > Cc: Mark Rutland > Cc:

Re: [PATCH 1/2] ARM: dts: imx6: RDU2: disable internal watchdog

Hi Andrey, On Wed, Dec 27, 2017 at 1:56 AM, Andrey Smirnov wrote: > The system has an external watchdog in the environment processor > so the internal watchdog is of no use. > > Cc: Sascha Hauer > Cc: Fabio Estevam > Cc:

Re: [PATCH 1/2] ARM: dts: imx6: RDU2: disable internal watchdog

Hi Andrey, On Wed, Dec 27, 2017 at 1:56 AM, Andrey Smirnov wrote: > The system has an external watchdog in the environment processor > so the internal watchdog is of no use. > > Cc: Sascha Hauer > Cc: Fabio Estevam > Cc: Rob Herring > Cc: Mark Rutland > Cc:

[PATCH v2] MIPS: Use proper Return keyword

For reference: * https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#function-documentation Fix non-fatal warning: arch/mips/kernel/branch.c:418: warning: Excess function parameter 'returns' description in '__compute_return_epc_for_insn' Signed-off-by: Mathieu Malaterre

[PATCH v2] MIPS: Use proper Return keyword

For reference: * https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#function-documentation Fix non-fatal warning: arch/mips/kernel/branch.c:418: warning: Excess function parameter 'returns' description in '__compute_return_epc_for_insn' Signed-off-by: Mathieu Malaterre --- v2:

[PATCH] PCI: imx6: Add PHY reference clock source support

i.MX7D variant of the IP can use either Crystal Oscillator input or internal clock input as a Reference Clock input for PCIe PHY. Add support for an optional property 'pcie-phy-refclk-internal'. If present then an internal clock input is used as PCIe PHY reference clock source. By default an

[PATCH] PCI: imx6: Add PHY reference clock source support

i.MX7D variant of the IP can use either Crystal Oscillator input or internal clock input as a Reference Clock input for PCIe PHY. Add support for an optional property 'pcie-phy-refclk-internal'. If present then an internal clock input is used as PCIe PHY reference clock source. By default an

Re: [PATCH 10/11 v3] ARM: s3c24xx/s3c64xx: constify gpio_led

Hi, On Wednesday 27 December 2017 01:49 PM, Krzysztof Kozlowski wrote: On Tue, Dec 26, 2017 at 7:50 PM, Arvind Yadav wrote: gpio_led are not supposed to change at runtime. struct gpio_led_platform_data working with const gpio_led provided by . So mark the non-const

Re: [PATCH 10/11 v3] ARM: s3c24xx/s3c64xx: constify gpio_led

Hi, On Wednesday 27 December 2017 01:49 PM, Krzysztof Kozlowski wrote: On Tue, Dec 26, 2017 at 7:50 PM, Arvind Yadav wrote: gpio_led are not supposed to change at runtime. struct gpio_led_platform_data working with const gpio_led provided by . So mark the non-const structs as const.

Re: [PATCH] USB: serial: ftdi_sio: add id for Airbus DS P8GR

On Wed, Dec 20, 2017 at 08:47:44PM +0100, Max Schulze wrote: > Add AIRBUS_DS_P8GR device IDs to ftdi_sio driver. > > Signed-off-by: Max Schulze Thanks for the patch. Note that I moved the new defines to try to keep (some of) the ids sorted on VID, and dropped the comment

Re: [PATCH] USB: serial: ftdi_sio: add id for Airbus DS P8GR

On Wed, Dec 20, 2017 at 08:47:44PM +0100, Max Schulze wrote: > Add AIRBUS_DS_P8GR device IDs to ftdi_sio driver. > > Signed-off-by: Max Schulze Thanks for the patch. Note that I moved the new defines to try to keep (some of) the ids sorted on VID, and dropped the comment header in the id-table

Re: [PATCH v6 00/11] Intel SGX Driver

On Dec 12, 3:07pm, Pavel Machek wrote: } Subject: Re: [PATCH v6 00/11] Intel SGX Driver Good morning, I hope this note finds the holiday season going well for everyone. This note is a bit delayed due to the holidays, my apologies. Pretty wide swath on this e-mail but will include the copy list

Re: [PATCH v6 00/11] Intel SGX Driver

On Dec 12, 3:07pm, Pavel Machek wrote: } Subject: Re: [PATCH v6 00/11] Intel SGX Driver Good morning, I hope this note finds the holiday season going well for everyone. This note is a bit delayed due to the holidays, my apologies. Pretty wide swath on this e-mail but will include the copy list

Applied "regmap: Add one flag to indicate if a hwlock should be used" to the regmap tree

The patch regmap: Add one flag to indicate if a hwlock should be used has been applied to the regmap tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regmap: Add one flag to indicate if a hwlock should be used" to the regmap tree

The patch regmap: Add one flag to indicate if a hwlock should be used has been applied to the regmap tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regmap: debugfs: document why we don't create the debugfs entries" to the regmap tree

The patch regmap: debugfs: document why we don't create the debugfs entries has been applied to the regmap tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "regmap: debugfs: document why we don't create the debugfs entries" to the regmap tree

The patch regmap: debugfs: document why we don't create the debugfs entries has been applied to the regmap tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Re: [Ocfs2-devel] [PATCH] ocfs2: try a blocking lock before return AOP_TRUNCATED_PAGE

Hi Jun, >>> > Hi Gang, > > Do you mean that too many retrys in loop cast losts of CPU-time and > block page-fault interrupt? We should not add any delay in > ocfs2_fault(), right? And I still feel a little confused why your > method can solve this problem. You can see the related code in

Re: [Ocfs2-devel] [PATCH] ocfs2: try a blocking lock before return AOP_TRUNCATED_PAGE

Hi Jun, >>> > Hi Gang, > > Do you mean that too many retrys in loop cast losts of CPU-time and > block page-fault interrupt? We should not add any delay in > ocfs2_fault(), right? And I still feel a little confused why your > method can solve this problem. You can see the related code in

Re: [PATCH 0/3] mtd: spi-nor: fix DMA-unsafe buffer issue between MTD and SPI

On Tue, Dec 26, 2017 at 06:45:28PM +, Trent Piepho wrote: > Or, since this only fixes instances of DMA-unsafe buffers used in > access to SPI NOR flash chips, and since there are other SPI master > interface users, those chip specific fixes in some/all spi master > drivers are still needed to

Re: [PATCH 0/3] mtd: spi-nor: fix DMA-unsafe buffer issue between MTD and SPI

On Tue, Dec 26, 2017 at 06:45:28PM +, Trent Piepho wrote: > Or, since this only fixes instances of DMA-unsafe buffers used in > access to SPI NOR flash chips, and since there are other SPI master > interface users, those chip specific fixes in some/all spi master > drivers are still needed to

Re: [PATCH] spi: Add a sysfs interface to instantiate devices

On Sat, Dec 23, 2017 at 09:58:51AM +0100, Geert Uytterhoeven wrote: > >> > > + struct spi_board_info bi = { > >> > > + .modalias = "spidev", > I would make it a little bit more generic and extract the modalias from the > string written. Right, that'd be much better. signature.asc

Re: [PATCH] spi: Add a sysfs interface to instantiate devices

On Sat, Dec 23, 2017 at 09:58:51AM +0100, Geert Uytterhoeven wrote: > >> > > + struct spi_board_info bi = { > >> > > + .modalias = "spidev", > I would make it a little bit more generic and extract the modalias from the > string written. Right, that'd be much better. signature.asc

Re: [PATCH 4.14 108/159] kvm, mm: account kvm related kmem slabs to kmemcg

On 23/12/2017 10:24, Greg Kroah-Hartman wrote: > For many subsystems, the maintainers _never_ mark patches for stable. > Others, they catch maybe half of the things they should be applying. > > KVM is one such example of the "half" group, they mark patches as > resolving CVE issues at times, yet

Re: [PATCH V1 3/4] usb: serial: f81534: add output pin control

On Thu, Dec 21, 2017 at 05:49:45PM +0800, Ji-Ze Hong (Peter Hong) wrote: > Hi Johan, > > Johan Hovold 於 2017/12/19 上午 12:06 寫道: > > On Thu, Nov 16, 2017 at 03:46:08PM +0800, Ji-Ze Hong (Peter Hong) wrote: > >> +static int f81534_set_port_output_pin(struct usb_serial_port *port) > >> +{ > >> +

Re: [PATCH V1 3/4] usb: serial: f81534: add output pin control

On Thu, Dec 21, 2017 at 05:49:45PM +0800, Ji-Ze Hong (Peter Hong) wrote: > Hi Johan, > > Johan Hovold 於 2017/12/19 上午 12:06 寫道: > > On Thu, Nov 16, 2017 at 03:46:08PM +0800, Ji-Ze Hong (Peter Hong) wrote: > >> +static int f81534_set_port_output_pin(struct usb_serial_port *port) > >> +{ > >> +

Re: [PATCH 4.14 108/159] kvm, mm: account kvm related kmem slabs to kmemcg

On 23/12/2017 10:24, Greg Kroah-Hartman wrote: > For many subsystems, the maintainers _never_ mark patches for stable. > Others, they catch maybe half of the things they should be applying. > > KVM is one such example of the "half" group, they mark patches as > resolving CVE issues at times, yet

<    4   5   6   7   8   9   10   11   >