Re: [PATCH 3/3] livepatch: force transition process to finish

On Thu, May 18, 2017 at 02:00:43PM +0200, Miroslav Benes wrote: > @@ -591,3 +591,19 @@ void klp_send_fake_signal(void) > } > read_unlock(_lock); > } > + > +/* > + * Drop TIF_PATCH_PENDING of all tasks on admin's request. This forces an > + * existing transition to finish. > + */ >

Re: [PATCH 3/3] livepatch: force transition process to finish

On Thu, May 18, 2017 at 02:00:43PM +0200, Miroslav Benes wrote: > @@ -591,3 +591,19 @@ void klp_send_fake_signal(void) > } > read_unlock(_lock); > } > + > +/* > + * Drop TIF_PATCH_PENDING of all tasks on admin's request. This forces an > + * existing transition to finish. > + */ >

[PATCH] KEYS: fix refcount_inc() on zero

If a key's refcount is dropped to zero between key_lookup() peeking at the refcount and subsequently attempting to increment it, refcount_inc() will see a zero refcount. Here, refcount_inc() will WARN_ONCE(), and will *not* increment the refcount, which will remain zero. Once key_lookup() drops

[PATCH] KEYS: fix refcount_inc() on zero

If a key's refcount is dropped to zero between key_lookup() peeking at the refcount and subsequently attempting to increment it, refcount_inc() will see a zero refcount. Here, refcount_inc() will WARN_ONCE(), and will *not* increment the refcount, which will remain zero. Once key_lookup() drops

Re: [PATCH 3/3] livepatch: force transition process to finish

On Thu, May 25, 2017 at 06:03:07PM +0200, Petr Mladek wrote: > On Thu 2017-05-25 14:59:55, Miroslav Benes wrote: > > > > > > > In fact, I would suggest to take klp_mutex in force_store() > > > > > and do all actions synchronously, including the check > > > > > of klp_transition_patch. > > > > >

Re: [PATCH 3/3] livepatch: force transition process to finish

On Thu, May 25, 2017 at 06:03:07PM +0200, Petr Mladek wrote: > On Thu 2017-05-25 14:59:55, Miroslav Benes wrote: > > > > > > > In fact, I would suggest to take klp_mutex in force_store() > > > > > and do all actions synchronously, including the check > > > > > of klp_transition_patch. > > > > >

[PATCH v3] x86: remove unused atomic_inc_short()

It is completely unused and implemented only on x86. Remove it. Signed-off-by: Dmitry Vyukov Suggested-by: Mark Rutland Cc: Andrey Ryabinin Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H.

[PATCH v3] x86: remove unused atomic_inc_short()

It is completely unused and implemented only on x86. Remove it. Signed-off-by: Dmitry Vyukov Suggested-by: Mark Rutland Cc: Andrey Ryabinin Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Peter Zijlstra Cc: Andrew Morton Cc: linux-kernel@vger.kernel.org Cc: x...@kernel.org

Re: [PATCH 5/5] drm: dw-hdmi-i2s: add .get_dai_id callback for ALSA SoC

On Wed, May 24, 2017 at 11:34:46PM +, Kuninori Morimoto wrote: > > As far as I understand what's going on with the graph code this seems to > > make sense to me. How do we want to go about handling the patch? > This is comment to me ? or DRM maintainer ? > If to me, any case (pickup by

Re: [PATCH 5/5] drm: dw-hdmi-i2s: add .get_dai_id callback for ALSA SoC

On Wed, May 24, 2017 at 11:34:46PM +, Kuninori Morimoto wrote: > > As far as I understand what's going on with the graph code this seems to > > make sense to me. How do we want to go about handling the patch? > This is comment to me ? or DRM maintainer ? > If to me, any case (pickup by

Re: [PATCH V2 1/2] powerpc/numa: Update CPU topology when VPHN enabled

Hi Michael, [auto build test ERROR on powerpc/next] [also build test ERROR on v4.12-rc2 next-20170526] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Michael-Bringmann/powerpc-numa-Update-CPU

Re: [PATCH V2 1/2] powerpc/numa: Update CPU topology when VPHN enabled

Hi Michael, [auto build test ERROR on powerpc/next] [also build test ERROR on v4.12-rc2 next-20170526] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Michael-Bringmann/powerpc-numa-Update-CPU

Re: [PATCH v2 2/3] mm: kmemleak: Factor object reference updating out of scan_block()

On Fri, May 26, 2017 at 05:23:30PM +0100, Catalin Marinas wrote: > On Fri, May 26, 2017 at 05:21:08PM +0100, Catalin Marinas wrote: > > On Fri, May 26, 2017 at 05:09:17PM +0100, Luis Henriques wrote: > > > On Thu, May 25, 2017 at 04:42:16PM +0100, Catalin Marinas wrote: > > > > The scan_block()

Re: [PATCH v2 2/3] mm: kmemleak: Factor object reference updating out of scan_block()

On Fri, May 26, 2017 at 05:23:30PM +0100, Catalin Marinas wrote: > On Fri, May 26, 2017 at 05:21:08PM +0100, Catalin Marinas wrote: > > On Fri, May 26, 2017 at 05:09:17PM +0100, Luis Henriques wrote: > > > On Thu, May 25, 2017 at 04:42:16PM +0100, Catalin Marinas wrote: > > > > The scan_block()

Re: [PATCH 1/4] Introduce regmap infrastructure over Maxim/Dalas OneWire (W1) bus

On Fri, May 26, 2017 at 04:45:12PM +0300, Evgeniy Polyakov wrote: Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. > I wonder what is 'cache' argument about? If I know

Re: [PATCH 1/4] Introduce regmap infrastructure over Maxim/Dalas OneWire (W1) bus

On Fri, May 26, 2017 at 04:45:12PM +0300, Evgeniy Polyakov wrote: Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. > I wonder what is 'cache' argument about? If I know

[PATCH] Revert "timers: Don't wake ktimersoftd on every tick"

This reverts commit 032f93cae150a. The problem is that the look ahead optimization from the tick timer interrupt context can race with the softirq thread expiring timer. As a consequence the temporary hlist heads which hold the to expire timers are overwritten and the timers which are already

[PATCH] Revert "timers: Don't wake ktimersoftd on every tick"

This reverts commit 032f93cae150a. The problem is that the look ahead optimization from the tick timer interrupt context can race with the softirq thread expiring timer. As a consequence the temporary hlist heads which hold the to expire timers are overwritten and the timers which are already

Re: [PATCH 5/5] MIPS: Add support for eBPF JIT.

Hi David, [auto build test ERROR on linus/master] [also build test ERROR on v4.12-rc2] [cannot apply to next-20170526] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/David-Daney/MIPS-Implement

Re: [PATCH 5/5] MIPS: Add support for eBPF JIT.

Hi David, [auto build test ERROR on linus/master] [also build test ERROR on v4.12-rc2] [cannot apply to next-20170526] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/David-Daney/MIPS-Implement

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

On Fri, May 26, 2017 at 01:43:12PM +0100, David Howells wrote: > Casey Schaufler wrote: > > > You called out five distinct features in 0/5, so how about > > a bit for each of those? > > Actually, there are more than five in that list - there are three in the first > item

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

On Fri, May 26, 2017 at 01:43:12PM +0100, David Howells wrote: > Casey Schaufler wrote: > > > You called out five distinct features in 0/5, so how about > > a bit for each of those? > > Actually, there are more than five in that list - there are three in the first > item - and I'm not sure the

Re: [PATCH v3] Input: mousedev - fix implicit conversion warning

On Fri, May 26, 2017 at 08:40:28AM -0700, Nick Desaulniers wrote: > Clang warns: > > drivers/input/mousedev.c:653:63: error: implicit conversion from 'int' > to 'signed char' changes value from 200 to -56 > [-Wconstant-conversion] > client->ps2[1] = 0x60; client->ps2[2] = 3; client->ps2[3] =

Re: [PATCH v3] Input: mousedev - fix implicit conversion warning

On Fri, May 26, 2017 at 08:40:28AM -0700, Nick Desaulniers wrote: > Clang warns: > > drivers/input/mousedev.c:653:63: error: implicit conversion from 'int' > to 'signed char' changes value from 200 to -56 > [-Wconstant-conversion] > client->ps2[1] = 0x60; client->ps2[2] = 3; client->ps2[3] =

Re: [PATCH 1/3] mm/slub: Only define kmalloc_large_node_hook() for NUMA systems

Hi, On Wed, May 24, 2017 at 3:09 PM, Matthias Kaehlcke wrote: > Hi David, > > El Wed, May 24, 2017 at 01:36:21PM -0700 David Rientjes ha dit: > >> On Tue, 23 May 2017, Matthias Kaehlcke wrote: >> >> > > diff --git a/include/linux/compiler-clang.h >> > >

Re: [PATCH 1/3] mm/slub: Only define kmalloc_large_node_hook() for NUMA systems

Hi, On Wed, May 24, 2017 at 3:09 PM, Matthias Kaehlcke wrote: > Hi David, > > El Wed, May 24, 2017 at 01:36:21PM -0700 David Rientjes ha dit: > >> On Tue, 23 May 2017, Matthias Kaehlcke wrote: >> >> > > diff --git a/include/linux/compiler-clang.h >> > > b/include/linux/compiler-clang.h >> > >

Re: [PATCH v2] arm: eBPF JIT compiler

Hi Andrew, Did you get the time to test the code with CONFIG_FRAME_POINTER? It would be great if you could check if it works on ARMv5 so that Russell can look at the patch. Thanks. Best, Shubham Bansal On Fri, May 26, 2017 at 5:06 AM, Shubham Bansal wrote: > Just to

Re: [PATCH v2] arm: eBPF JIT compiler

Hi Andrew, Did you get the time to test the code with CONFIG_FRAME_POINTER? It would be great if you could check if it works on ARMv5 so that Russell can look at the patch. Thanks. Best, Shubham Bansal On Fri, May 26, 2017 at 5:06 AM, Shubham Bansal wrote: > Just to add. It a very very small

[PATCH 2/3] remoteproc/keystone: add a remoteproc driver for Keystone 2 DSPs

The Texas Instrument's Keystone 2 family of SoCs has 1 or more TMS320C66x DSP Core Subsystems (C66x CorePacs). Each subsystem has a C66x Fixed/Floating-Point DSP Core, with 32KB of L1P and L1D SRAMs, that can be configured and partitioned as either RAM and/or Cache, and 1 MB of L2 SRAM. The

[PATCH 2/3] remoteproc/keystone: add a remoteproc driver for Keystone 2 DSPs

The Texas Instrument's Keystone 2 family of SoCs has 1 or more TMS320C66x DSP Core Subsystems (C66x CorePacs). Each subsystem has a C66x Fixed/Floating-Point DSP Core, with 32KB of L1P and L1D SRAMs, that can be configured and partitioned as either RAM and/or Cache, and 1 MB of L2 SRAM. The

[PATCH 0/3] Add Keystone2 Remoteproc driver

Hi, This series adds the DT binding and the driver for loading and booting the DSP devices present on various Keystone2 SoC families. The current series supports the 66AK2H/K, 66AK2L and 66AK2E SoC families. Support for the remaining 66AK2G SoC family will be added later as it is awaiting the

[PATCH 0/3] Add Keystone2 Remoteproc driver

Hi, This series adds the DT binding and the driver for loading and booting the DSP devices present on various Keystone2 SoC families. The current series supports the 66AK2H/K, 66AK2L and 66AK2E SoC families. Support for the remaining 66AK2G SoC family will be added later as it is awaiting the

[PATCH 1/3] Documentation: DT: add Keystone DSP remoteproc binding

Add the device tree bindings document for the Texas Instrument's Keystone 2 DSP remoteproc devices. Signed-off-by: Suman Anna Signed-off-by: Sam Nelson --- .../bindings/remoteproc/ti,keystone-rproc.txt | 132 + 1 file changed, 132

[PATCH 1/3] Documentation: DT: add Keystone DSP remoteproc binding

Add the device tree bindings document for the Texas Instrument's Keystone 2 DSP remoteproc devices. Signed-off-by: Suman Anna Signed-off-by: Sam Nelson --- .../bindings/remoteproc/ti,keystone-rproc.txt | 132 + 1 file changed, 132 insertions(+) create mode 100644

[PATCH 3/3] remoteproc/keystone: ensure the DSPs are in reset in probe

From: "Andrew F. Davis" The DSPs are expected to be in reset when the driver probes a device. If the DSPs are out of reset in probe, the system may crash when the firmware is being loaded. So, add a check to make sure the DSP resets are asserted, and if not, throw a eye-catchy

[PATCH 3/3] remoteproc/keystone: ensure the DSPs are in reset in probe

From: "Andrew F. Davis" The DSPs are expected to be in reset when the driver probes a device. If the DSPs are out of reset in probe, the system may crash when the firmware is being loaded. So, add a check to make sure the DSP resets are asserted, and if not, throw a eye-catchy warning and assert

Re: [PATCH] s390: provide default ioremap and iounmap declaration

On 26/05/17 06:38 AM, Heiko Carstens wrote: > On Thu, May 25, 2017 at 09:43:48AM -0600, Logan Gunthorpe wrote: > I'd rather move the #ifdef CONFIG_PCI than implementing this yet another > time (see patch below). But I'll leave that up to Sebastian. I'd be more than happy with this change. Let

Re: [PATCH] s390: provide default ioremap and iounmap declaration

On 26/05/17 06:38 AM, Heiko Carstens wrote: > On Thu, May 25, 2017 at 09:43:48AM -0600, Logan Gunthorpe wrote: > I'd rather move the #ifdef CONFIG_PCI than implementing this yet another > time (see patch below). But I'll leave that up to Sebastian. I'd be more than happy with this change. Let

Re: [linux-sunxi] [PATCH 2/3] arm64: allwinner: h5: Add initial Orangepi Prime support

在 2017-05-27 00:44，Jagan Teki 写道： On Fri, May 26, 2017 at 10:10 PM, wrote: 在 2017-05-26 03:26，Jagan Teki 写道： From: Jagan Teki Orangepi Prime is an open-source single-board computer using the Allwinner h5 SOC. Sorry but I have already added

Re: [linux-sunxi] [PATCH 2/3] arm64: allwinner: h5: Add initial Orangepi Prime support

在 2017-05-27 00:44，Jagan Teki 写道： On Fri, May 26, 2017 at 10:10 PM, wrote: 在 2017-05-26 03:26，Jagan Teki 写道： From: Jagan Teki Orangepi Prime is an open-source single-board computer using the Allwinner h5 SOC. Sorry but I have already added this board and it's scheduled at 4.13. Ohh,

Re: [v3 0/9] parallelized "struct page" zeroing

Hi Michal, I have considered your proposals: 1. Making memset(0) unconditional inside __init_single_page() is not going to work because it slows down SPARC, and ppc64. On SPARC even the BSTI optimization that I have proposed earlier won't work, because after consulting with other engineers I

Re: [v3 0/9] parallelized "struct page" zeroing

Hi Michal, I have considered your proposals: 1. Making memset(0) unconditional inside __init_single_page() is not going to work because it slows down SPARC, and ppc64. On SPARC even the BSTI optimization that I have proposed earlier won't work, because after consulting with other engineers I

Re: [linux-sunxi] [PATCH 2/3] arm64: allwinner: h5: Add initial Orangepi Prime support

On Fri, May 26, 2017 at 10:10 PM, wrote: > 在 2017-05-26 03:26，Jagan Teki 写道： >> >> From: Jagan Teki >> >> Orangepi Prime is an open-source single-board computer >> using the Allwinner h5 SOC. > > > Sorry but I have already added this board and it's >

Re: [linux-sunxi] [PATCH 2/3] arm64: allwinner: h5: Add initial Orangepi Prime support

On Fri, May 26, 2017 at 10:10 PM, wrote: > 在 2017-05-26 03:26，Jagan Teki 写道： >> >> From: Jagan Teki >> >> Orangepi Prime is an open-source single-board computer >> using the Allwinner h5 SOC. > > > Sorry but I have already added this board and it's > scheduled at 4.13. Ohh, unfortunately I

[GIT PULL] PCI fixes for v4.12

PCI fixes: - fix PCI_ENDPOINT build error (merged for v4.12) - fix Switchtec driver (merged for v4.12) - fix imx6 config read timeouts, fallout from changing to non-postable reads - add PM "needs_resume" flag for i915 suspend issue The following changes since commit

[GIT PULL] PCI fixes for v4.12

PCI fixes: - fix PCI_ENDPOINT build error (merged for v4.12) - fix Switchtec driver (merged for v4.12) - fix imx6 config read timeouts, fallout from changing to non-postable reads - add PM "needs_resume" flag for i915 suspend issue The following changes since commit

Re: [linux-sunxi] [PATCH 2/3] arm64: allwinner: h5: Add initial Orangepi Prime support

在 2017-05-26 03:26，Jagan Teki 写道： From: Jagan Teki Orangepi Prime is an open-source single-board computer using the Allwinner h5 SOC. Sorry but I have already added this board and it's scheduled at 4.13. H5 Orangepi Prime has - Quad-core Cortex-A53 - 2GB DDR3 -

Re: [linux-sunxi] [PATCH 2/3] arm64: allwinner: h5: Add initial Orangepi Prime support

在 2017-05-26 03:26，Jagan Teki 写道： From: Jagan Teki Orangepi Prime is an open-source single-board computer using the Allwinner h5 SOC. Sorry but I have already added this board and it's scheduled at 4.13. H5 Orangepi Prime has - Quad-core Cortex-A53 - 2GB DDR3 - Debug TTL UART - 1000M/100M

Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

On Fri, May 26, 2017 at 11:22:36AM -0500, Tom Lendacky wrote: > In addition to the same issue as efi.memmap.phys_map, efi_phys has > the __initdata attribute so it will be released/freed which will cause > problems in checks performed afterwards. Sounds to me like we should drop the __initdata

Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

On Fri, May 26, 2017 at 11:22:36AM -0500, Tom Lendacky wrote: > In addition to the same issue as efi.memmap.phys_map, efi_phys has > the __initdata attribute so it will be released/freed which will cause > problems in checks performed afterwards. Sounds to me like we should drop the __initdata

[RFC PATCH] ASoC: Intel: sst: Delete sst_save_shim64(); saved regs are never used

In commit 9a075265c6dc ("ASoC: Intel: sst: Remove unused function sst_restore_shim64()"), we deleted the sst_restore_shim64() since it was never used. ...but a quick look at the code shows that we should also be able to remove the sst_save_shim64() function and the structure members we were

[RFC PATCH] ASoC: Intel: sst: Delete sst_save_shim64(); saved regs are never used

In commit 9a075265c6dc ("ASoC: Intel: sst: Remove unused function sst_restore_shim64()"), we deleted the sst_restore_shim64() since it was never used. ...but a quick look at the code shows that we should also be able to remove the sst_save_shim64() function and the structure members we were

Re: [PATCH v2 1/1] w1: Add subsystem kernel public interface

On 05/26/2017 11:13 AM, Evgeniy Polyakov wrote: > > > 25.05.2017, 16:50, "Andrew F. Davis" : > >>> Why do you have to create a pseudo-platform device driver to connect w1 >>> and power/supply? >>> >>> I'm not against creating w1 drivers in different places than drivers/w1, >>>

Re: [PATCH v2 1/1] w1: Add subsystem kernel public interface

On 05/26/2017 11:13 AM, Evgeniy Polyakov wrote: > > > 25.05.2017, 16:50, "Andrew F. Davis" : > >>> Why do you have to create a pseudo-platform device driver to connect w1 >>> and power/supply? >>> >>> I'm not against creating w1 drivers in different places than drivers/w1, >>> but so far

Re: [PATCH v5 29/32] x86/mm: Add support to encrypt the kernel in-place

On Thu, May 25, 2017 at 05:24:27PM -0500, Tom Lendacky wrote: > I guess I could do that, but this will probably only end up clearing a > single PGD entry anyway since it's highly doubtful the address range > would cross a 512GB boundary. Or you can compute how many 512G-covering, i.e., PGD

Re: [PATCH v5 29/32] x86/mm: Add support to encrypt the kernel in-place

On Thu, May 25, 2017 at 05:24:27PM -0500, Tom Lendacky wrote: > I guess I could do that, but this will probably only end up clearing a > single PGD entry anyway since it's highly doubtful the address range > would cross a 512GB boundary. Or you can compute how many 512G-covering, i.e., PGD

Re: [PATCH v4 1/5] rpmsg: virtio_rpmsg: set rpmsg_buf_size customizable

On 03/28/2017 06:49 AM, Loic Pallardy wrote: > Rpmsg buffer size is currently fixed to 512 bytes. > This patch introduces a new capability in struct virtproc_info > to tune shared buffer size between host and coprocessor > according to the needs. > > Signed-off-by: Loic Pallardy

Re: [PATCH v4 1/5] rpmsg: virtio_rpmsg: set rpmsg_buf_size customizable

On 03/28/2017 06:49 AM, Loic Pallardy wrote: > Rpmsg buffer size is currently fixed to 512 bytes. > This patch introduces a new capability in struct virtproc_info > to tune shared buffer size between host and coprocessor > according to the needs. > > Signed-off-by: Loic Pallardy Acked-by: Suman

Re: [GIT PULL] MMC fixes for v.4.12 rc3 - take 2/2

Hi Ulf, On Fri, May 26, 2017 at 6:08 AM, Ulf Hansson wrote: > Hi Linus, > > Here are a couple of mmc and arm64-dts fixes intended for v4.12 rc3. > They are based on v4.12-rc2. > > Details are as usual found in the signed tag. Please pull this in! > > Kind regards > Ulf

Re: [GIT PULL] MMC fixes for v.4.12 rc3 - take 2/2

Hi Ulf, On Fri, May 26, 2017 at 6:08 AM, Ulf Hansson wrote: > Hi Linus, > > Here are a couple of mmc and arm64-dts fixes intended for v4.12 rc3. > They are based on v4.12-rc2. > > Details are as usual found in the signed tag. Please pull this in! > > Kind regards > Ulf Hansson > > > The

Re: [PATCH v2 2/3] mm: kmemleak: Factor object reference updating out of scan_block()

On Fri, May 26, 2017 at 05:21:08PM +0100, Catalin Marinas wrote: > On Fri, May 26, 2017 at 05:09:17PM +0100, Luis Henriques wrote: > > On Thu, May 25, 2017 at 04:42:16PM +0100, Catalin Marinas wrote: > > > The scan_block() function updates the number of references (pointers) to > > > objects,

Re: [PATCH v2 2/3] mm: kmemleak: Factor object reference updating out of scan_block()

On Fri, May 26, 2017 at 05:21:08PM +0100, Catalin Marinas wrote: > On Fri, May 26, 2017 at 05:09:17PM +0100, Luis Henriques wrote: > > On Thu, May 25, 2017 at 04:42:16PM +0100, Catalin Marinas wrote: > > > The scan_block() function updates the number of references (pointers) to > > > objects,

Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

On 5/18/2017 2:50 PM, Matt Fleming wrote: On Mon, 15 May, at 08:35:17PM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 04:19:21PM -0500, Tom Lendacky wrote: + paddr = boot_params.efi_info.efi_memmap_hi; + paddr <<= 32; + paddr |=

Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

On 5/18/2017 2:50 PM, Matt Fleming wrote: On Mon, 15 May, at 08:35:17PM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 04:19:21PM -0500, Tom Lendacky wrote: + paddr = boot_params.efi_info.efi_memmap_hi; + paddr <<= 32; + paddr |=

Re: [PATCH -next] mtd: nand: Add support for Toshiba BENAND (Built-in ECC NAND)

Hi KOBAYASHI, Le Fri, 26 May 2017 10:15:35 +0900, KOBAYASHI Yoshitake a écrit : > This patch enables support for Toshiba BENAND. It was originally posted on > https://lkml.org/lkml/2015/7/24/571 > > This patch is rewrote to adapt the recent mtd "separate

Re: [PATCH -next] mtd: nand: Add support for Toshiba BENAND (Built-in ECC NAND)

Hi KOBAYASHI, Le Fri, 26 May 2017 10:15:35 +0900, KOBAYASHI Yoshitake a écrit : > This patch enables support for Toshiba BENAND. It was originally posted on > https://lkml.org/lkml/2015/7/24/571 > > This patch is rewrote to adapt the recent mtd "separate vendor specific code > from core"

Re: [PATCH v2 2/3] mm: kmemleak: Factor object reference updating out of scan_block()

On Fri, May 26, 2017 at 05:09:17PM +0100, Luis Henriques wrote: > On Thu, May 25, 2017 at 04:42:16PM +0100, Catalin Marinas wrote: > > The scan_block() function updates the number of references (pointers) to > > objects, adding them to the gray_list when object->min_count is reached. > > The patch

Re: [PATCH v2 2/3] mm: kmemleak: Factor object reference updating out of scan_block()

On Fri, May 26, 2017 at 05:09:17PM +0100, Luis Henriques wrote: > On Thu, May 25, 2017 at 04:42:16PM +0100, Catalin Marinas wrote: > > The scan_block() function updates the number of references (pointers) to > > objects, adding them to the gray_list when object->min_count is reached. > > The patch

[PATCH v2 02/27] thunderbolt: No need to read UID of the root switch on resume

The root switch is part of the host controller and cannot be physically removed, so there is no point of reading UID again on resume in order to check if the root switch is still the same. Signed-off-by: Mika Westerberg --- drivers/thunderbolt/switch.c | 29

[PATCH v2 02/27] thunderbolt: No need to read UID of the root switch on resume

The root switch is part of the host controller and cannot be physically removed, so there is no point of reading UID again on resume in order to check if the root switch is still the same. Signed-off-by: Mika Westerberg --- drivers/thunderbolt/switch.c | 29 ++--- 1 file

[PATCH v2 06/27] thunderbolt: Rework capability handling

Organization of the capabilities in switches and ports is not so random after all. Rework the capability handling functionality so that it follows how capabilities are organized and provide two new functions (tb_switch_find_vsec_cap() and tb_port_find_cap()) which can be used to extract

[PATCH v2 06/27] thunderbolt: Rework capability handling

Organization of the capabilities in switches and ports is not so random after all. Rework the capability handling functionality so that it follows how capabilities are organized and provide two new functions (tb_switch_find_vsec_cap() and tb_port_find_cap()) which can be used to extract

Re: [PATCH 1/4] Introduce regmap infrastructure over Maxim/Dalas OneWire (W1) bus

Alex, it is up to you to decide whether you want to push your regmap version or not, I will not object against, but in my personal opinion your first version version was much cleaner. I don't know. First edition (without regmap) was very simple. I think anyone could understand how this

Re: [PATCH 1/4] Introduce regmap infrastructure over Maxim/Dalas OneWire (W1) bus

Alex, it is up to you to decide whether you want to push your regmap version or not, I will not object against, but in my personal opinion your first version version was much cleaner. I don't know. First edition (without regmap) was very simple. I think anyone could understand how this

[PATCH v2 04/27] thunderbolt: Do not warn about newer DROM versions

DROM version 2 is compatible with the previous generation so no need to warn about that. Signed-off-by: Mika Westerberg Reviewed-by: Yehezkel Bernat Reviewed-by: Michael Jamet Reviewed-by: Andy Shevchenko

[PATCH v2 04/27] thunderbolt: Do not warn about newer DROM versions

DROM version 2 is compatible with the previous generation so no need to warn about that. Signed-off-by: Mika Westerberg Reviewed-by: Yehezkel Bernat Reviewed-by: Michael Jamet Reviewed-by: Andy Shevchenko --- drivers/thunderbolt/eeprom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH v2 10/27] thunderbolt: Fail switch adding operation if reading DROM fails

All non-root switches are expected to have DROM so if the operation fails, it might be due the user unlugging the device. There is no point continuing adding the switch further in that case. Just bail out. For root switches (hosts) the DROM is either retrieved from a EFI variable, NVM or

[PATCH v2 10/27] thunderbolt: Fail switch adding operation if reading DROM fails

All non-root switches are expected to have DROM so if the operation fails, it might be due the user unlugging the device. There is no point continuing adding the switch further in that case. Just bail out. For root switches (hosts) the DROM is either retrieved from a EFI variable, NVM or

[PATCH v2 05/27] thunderbolt: Add MSI-X support

Intel Thunderbolt controllers support up to 16 MSI-X vectors. Using MSI-X is preferred over MSI or legacy interrupt and may bring additional performance because there is no need to check the status registers which interrupt was triggered. While there we convert comments in structs tb_ring and

[PATCH v2 05/27] thunderbolt: Add MSI-X support

Intel Thunderbolt controllers support up to 16 MSI-X vectors. Using MSI-X is preferred over MSI or legacy interrupt and may bring additional performance because there is no need to check the status registers which interrupt was triggered. While there we convert comments in structs tb_ring and

Re: [PATCH 2/2] kernel: mark all struct k_clock instances const

On Fri, 2017-05-26 at 12:32 +0200, Thomas Gleixner wrote: > On Fri, 26 May 2017, Joe Perches wrote: > > On Fri, 2017-05-26 at 12:03 +0300, Christoph Hellwig wrote: > > > And initialize the array statically at compile time. Originally > > > based on changes in the Grsecurity patch set, but redone

Re: [PATCH 2/2] kernel: mark all struct k_clock instances const

On Fri, 2017-05-26 at 12:32 +0200, Thomas Gleixner wrote: > On Fri, 26 May 2017, Joe Perches wrote: > > On Fri, 2017-05-26 at 12:03 +0300, Christoph Hellwig wrote: > > > And initialize the array statically at compile time. Originally > > > based on changes in the Grsecurity patch set, but redone

[PATCH v2 15/27] thunderbolt: Expose get_route() to other files

We are going to use it when we change the connection manager to handle events itself. Also rename it to follow naming convention used in functions exposed in ctl.h. Signed-off-by: Mika Westerberg Reviewed-by: Yehezkel Bernat

[PATCH v2 15/27] thunderbolt: Expose get_route() to other files

We are going to use it when we change the connection manager to handle events itself. Also rename it to follow naming convention used in functions exposed in ctl.h. Signed-off-by: Mika Westerberg Reviewed-by: Yehezkel Bernat Reviewed-by: Michael Jamet Reviewed-by: Andy Shevchenko ---

[PATCH v2 17/27] thunderbolt: Let the connection manager handle all notifications

Currently the control channel (ctl.c) handles the one supported notification (PLUG_EVENT) and sends back ACK accordingly. However, we are going to add support for the internal connection manager (ICM) that needs to handle a different notifications. So instead of dealing everything in the control

[PATCH v2 17/27] thunderbolt: Let the connection manager handle all notifications

Currently the control channel (ctl.c) handles the one supported notification (PLUG_EVENT) and sends back ACK accordingly. However, we are going to add support for the internal connection manager (ICM) that needs to handle a different notifications. So instead of dealing everything in the control

Re: [PATCH 5/8] i2c: break out ACPI support into seperate file

On Fri, May 26, 2017 at 10:20:56AM +0200, Wolfram Sang wrote: > Removes some ifdeffery. Also add the new file to the relevant > MAINTAINERS section. > > Signed-off-by: Wolfram Sang Reviewed-by: Mika Westerberg

Re: [PATCH 5/8] i2c: break out ACPI support into seperate file

On Fri, May 26, 2017 at 10:20:56AM +0200, Wolfram Sang wrote: > Removes some ifdeffery. Also add the new file to the relevant > MAINTAINERS section. > > Signed-off-by: Wolfram Sang Reviewed-by: Mika Westerberg

[PATCH v2 14/27] thunderbolt: Move control channel messages to tb_msgs.h

We will be forwarding notifications received from the control channel to the connection manager implementations. This way they can decide what to do if anything when a notification is received. To be able to use control channel messages from other files, move them to tb_msgs.h. No functional

[PATCH v2 14/27] thunderbolt: Move control channel messages to tb_msgs.h

We will be forwarding notifications received from the control channel to the connection manager implementations. This way they can decide what to do if anything when a notification is received. To be able to use control channel messages from other files, move them to tb_msgs.h. No functional

[PATCH v2 11/27] thunderbolt: Do not fail if DROM data CRC32 is invalid

There are devices out there where CRC32 of the DROM is not correct. One reason for this is that the ICM firmware does not validate it and it seems that neither does the Apple driver. To be able to support such devices we continue parsing the DROM contents regardless of whether CRC32 failed or not.

[PATCH v2 11/27] thunderbolt: Do not fail if DROM data CRC32 is invalid

There are devices out there where CRC32 of the DROM is not correct. One reason for this is that the ICM firmware does not validate it and it seems that neither does the Apple driver. To be able to support such devices we continue parsing the DROM contents regardless of whether CRC32 failed or not.

[PATCH v2 21/27] thunderbolt: Store Thunderbolt generation in the switch structure

In some cases it is useful to know what is the Thunderbolt generation the switch supports. This introduces a new field to struct switch that stores the generation of the switch based on the device ID. Unknown switches (there should be none) are assumed to be first generation to be on the safe

[PATCH v2 21/27] thunderbolt: Store Thunderbolt generation in the switch structure

In some cases it is useful to know what is the Thunderbolt generation the switch supports. This introduces a new field to struct switch that stores the generation of the switch based on the device ID. Unknown switches (there should be none) are assumed to be first generation to be on the safe

[PATCH v2 16/27] thunderbolt: Expose make_header() to other files

We will be using this function in files introduced in subsequent patches. While there the function is renamed to tb_cfg_make_header() following tb_cfg_get_route(). Signed-off-by: Mika Westerberg Reviewed-by: Yehezkel Bernat

[PATCH v2 16/27] thunderbolt: Expose make_header() to other files

We will be using this function in files introduced in subsequent patches. While there the function is renamed to tb_cfg_make_header() following tb_cfg_get_route(). Signed-off-by: Mika Westerberg Reviewed-by: Yehezkel Bernat Reviewed-by: Michael Jamet Reviewed-by: Andy Shevchenko ---

[PATCH v2 24/27] thunderbolt: Add support for Internal Connection Manager (ICM)

Starting from Intel Falcon Ridge the internal connection manager running on the Thunderbolt host controller has been supporting 4 security levels. One reason for this is to prevent DMA attacks and only allow connecting devices the user trusts. The internal connection manager (ICM) is the

[PATCH v2 24/27] thunderbolt: Add support for Internal Connection Manager (ICM)

Starting from Intel Falcon Ridge the internal connection manager running on the Thunderbolt host controller has been supporting 4 security levels. One reason for this is to prevent DMA attacks and only allow connecting devices the user trusts. The internal connection manager (ICM) is the

[PATCH v2 23/27] thunderbolt: Do not touch the hardware if the NHI is gone on resume

On PCs the NHI host controller is only present when there is a device connected. When the last device is disconnected the host controller will dissappear shortly (within 10s). Now if that happens when we are suspended we should not try to touch the hardware anymore, so add a flag for this and

[PATCH v2 22/27] thunderbolt: Add support for DMA configuration based mailbox

The DMA (NHI) port of a switch provides access to the NVM of the host controller (and devices starting from Intel Alpine Ridge). The NVM contains also more complete DROM for the root switch including vendor and device identification strings. This will look for the DMA port capability for each

<    1   2   3   4   5   6   7   8   9   10   >