Re: [PATCH v4 01/18] fpga: bridge: support getting bridge from device

On Wed, Sep 13, 2017 at 6:38 PM, wrote: Hi Matthew, > > Hi Alan, > > Two minor nits below. > > Matthew Gerlach > > On Wed, 13 Sep 2017, Alan Tull wrote: > >> Add two functions for getting the FPGA bridge from the device >> rather than device tree node. This is

Re: [PATCH v4 01/18] fpga: bridge: support getting bridge from device

On Wed, Sep 13, 2017 at 6:38 PM, wrote: Hi Matthew, > > Hi Alan, > > Two minor nits below. > > Matthew Gerlach > > On Wed, 13 Sep 2017, Alan Tull wrote: > >> Add two functions for getting the FPGA bridge from the device >> rather than device tree node. This is to enable writing code >> that

[PATCH] objtool: Do not retrieve data from empty sections

From: Petr Vandrovec Binutils 2.29-9 in Debian return an error when elf_getdata is invoked on empty section (.note.GNU-stack in all kernel files), causing immediate failure of kernel build with: elf_getdata: can't manipulate null section As nothing is done with sections

[PATCH] objtool: Do not retrieve data from empty sections

From: Petr Vandrovec Binutils 2.29-9 in Debian return an error when elf_getdata is invoked on empty section (.note.GNU-stack in all kernel files), causing immediate failure of kernel build with: elf_getdata: can't manipulate null section As nothing is done with sections that have zero size,

Re: [PATCH 1/1] irqchip/gicv3: iterate over possible CPUs by for_each_possible_cpu()

On Thu, Sep 14 2017 at 1:15:14 pm BST, zijun_hu wrote: > From: zijun_hu > > get_cpu_number() doesn't use existing helper to iterate over possible > CPUs, so error happens in case of discontinuous @cpu_possible_mask > such as 0b0001. Do you have an

Re: [PATCH 1/1] irqchip/gicv3: iterate over possible CPUs by for_each_possible_cpu()

On Thu, Sep 14 2017 at 1:15:14 pm BST, zijun_hu wrote: > From: zijun_hu > > get_cpu_number() doesn't use existing helper to iterate over possible > CPUs, so error happens in case of discontinuous @cpu_possible_mask > such as 0b0001. Do you have an example of such a situation? Your patch is

Re: [PATCH v5 05/10] dt-bindings: net: dwmac-sun8i: update documentation about integrated PHY

> > Is the MDIO controller "allwinner,sun8i-h3-emac" or "snps,dwmac-mdio"? > > If the latter, then I think the node is fine, but then the mux should be > > a child node of it. IOW, the child of an MDIO controller should either > > be a mux node or slave devices. Hi Rob Up until now, children

Re: [PATCH v5 05/10] dt-bindings: net: dwmac-sun8i: update documentation about integrated PHY

> > Is the MDIO controller "allwinner,sun8i-h3-emac" or "snps,dwmac-mdio"? > > If the latter, then I think the node is fine, but then the mux should be > > a child node of it. IOW, the child of an MDIO controller should either > > be a mux node or slave devices. Hi Rob Up until now, children

Re: [PATCH RFC 0/3] A few round_pipe_size() and pipe-max-size fixups

On 09/14/2017 12:57 PM, Randy Dunlap wrote: > On 09/14/17 06:26, Michael Kerrisk (man-pages) wrote: >> Hello Joe, >> >> On 5 September 2017 at 16:44, Joe Lawrence wrote: >>> While backporting Michael's "pipe: fix limit handling" [1] patchset to a >>> distro-kernel,

Re: [PATCH RFC 0/3] A few round_pipe_size() and pipe-max-size fixups

On 09/14/2017 12:57 PM, Randy Dunlap wrote: > On 09/14/17 06:26, Michael Kerrisk (man-pages) wrote: >> Hello Joe, >> >> On 5 September 2017 at 16:44, Joe Lawrence wrote: >>> While backporting Michael's "pipe: fix limit handling" [1] patchset to a >>> distro-kernel, Mikulas noticed that current

Re: [PATCH for 4.9 11/59] MIPS: fix mem=X@Y commandline processing

On Thu, Sep 14, 2017 at 9:11 PM, Levin, Alexander (Sasha Levin) wrote: > On Thu, Sep 14, 2017 at 08:59:05PM +0200, Mathieu Malaterre wrote: >>On Thu, Sep 14, 2017 at 5:51 PM, Levin, Alexander (Sasha Levin) >> wrote: >>> From: Marcin

Re: [PATCH for 4.9 11/59] MIPS: fix mem=X@Y commandline processing

On Thu, Sep 14, 2017 at 9:11 PM, Levin, Alexander (Sasha Levin) wrote: > On Thu, Sep 14, 2017 at 08:59:05PM +0200, Mathieu Malaterre wrote: >>On Thu, Sep 14, 2017 at 5:51 PM, Levin, Alexander (Sasha Levin) >> wrote: >>> From: Marcin Nowakowski >>> >>> [ Upstream commit

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

On 09/14, Al Viro wrote: > On Thu, Sep 14, 2017 at 02:30:17AM +0100, Al Viro wrote: > > On Wed, Sep 13, 2017 at 06:10:48PM -0700, Jaegeuk Kim wrote: > > > > > Android triggers umount(2) by init process, which is definitely not a > > > kernel > > > thread. But, we've seen some kernel panics which

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

On 09/14, Al Viro wrote: > On Thu, Sep 14, 2017 at 02:30:17AM +0100, Al Viro wrote: > > On Wed, Sep 13, 2017 at 06:10:48PM -0700, Jaegeuk Kim wrote: > > > > > Android triggers umount(2) by init process, which is definitely not a > > > kernel > > > thread. But, we've seen some kernel panics which

Re: [PATCH for 4.9 11/59] MIPS: fix mem=X@Y commandline processing

On Thu, Sep 14, 2017 at 08:59:05PM +0200, Mathieu Malaterre wrote: >On Thu, Sep 14, 2017 at 5:51 PM, Levin, Alexander (Sasha Levin) > wrote: >> From: Marcin Nowakowski >> >> [ Upstream commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411 ] >>

Re: [PATCH for 4.9 11/59] MIPS: fix mem=X@Y commandline processing

On Thu, Sep 14, 2017 at 08:59:05PM +0200, Mathieu Malaterre wrote: >On Thu, Sep 14, 2017 at 5:51 PM, Levin, Alexander (Sasha Levin) > wrote: >> From: Marcin Nowakowski >> >> [ Upstream commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411 ] >> >> When a memory offset is specified through the

Re: [patch v2] madvise.2: Add MADV_WIPEONFORK documentation

On Thu, Sep 14, 2017 at 12:05 PM, Rik van Riel wrote: > v2: implement the improvements suggested by Colm, and add > Colm's text to the fork.2 man page > (Colm, I have added a signed-off-by in your name - is that ok?) Yep, that's ok! Whole thing LGTM. -- Colm

Re: [patch v2] madvise.2: Add MADV_WIPEONFORK documentation

On Thu, Sep 14, 2017 at 12:05 PM, Rik van Riel wrote: > v2: implement the improvements suggested by Colm, and add > Colm's text to the fork.2 man page > (Colm, I have added a signed-off-by in your name - is that ok?) Yep, that's ok! Whole thing LGTM. -- Colm

Re: [v4 07/11] soc/fsl/qbman: Rework portal mapping calls for ARM/PPC

On 9/14/2017 10:00 AM, Catalin Marinas wrote: > On Thu, Aug 24, 2017 at 04:37:51PM -0400, Roy Pledge wrote: >> diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c >> index ff8998f..e31c843 100644 >> --- a/drivers/soc/fsl/qbman/bman.c >> +++ b/drivers/soc/fsl/qbman/bman.c >> @@

Re: [v4 07/11] soc/fsl/qbman: Rework portal mapping calls for ARM/PPC

On 9/14/2017 10:00 AM, Catalin Marinas wrote: > On Thu, Aug 24, 2017 at 04:37:51PM -0400, Roy Pledge wrote: >> diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c >> index ff8998f..e31c843 100644 >> --- a/drivers/soc/fsl/qbman/bman.c >> +++ b/drivers/soc/fsl/qbman/bman.c >> @@

[patch v2] madvise.2: Add MADV_WIPEONFORK documentation

v2: implement the improvements suggested by Colm, and add Colm's text to the fork.2 man page (Colm, I have added a signed-off-by in your name - is that ok?) Add MADV_WIPEONFORK and MADV_KEEPONFORK documentation to madvise.2. The new functionality was recently merged by Linus, and should

[patch v2] madvise.2: Add MADV_WIPEONFORK documentation

v2: implement the improvements suggested by Colm, and add Colm's text to the fork.2 man page (Colm, I have added a signed-off-by in your name - is that ok?) Add MADV_WIPEONFORK and MADV_KEEPONFORK documentation to madvise.2. The new functionality was recently merged by Linus, and should

Re: [PATCH v2 2/3] efi: call get_event_log before ExitBootServices

On Thu, Sep 14, 2017 at 11:48:54AM -0700, Matthew Garrett wrote: > On Thu, Sep 14, 2017 at 11:43 AM, Jarkko Sakkinen > wrote: > > On Mon, Sep 11, 2017 at 12:00:21PM +0200, Thiebaud Weksteen wrote: > >> With TPM 2.0 specification, the event logs may only be

Re: [PATCH v2 2/3] efi: call get_event_log before ExitBootServices

On Thu, Sep 14, 2017 at 11:48:54AM -0700, Matthew Garrett wrote: > On Thu, Sep 14, 2017 at 11:43 AM, Jarkko Sakkinen > wrote: > > On Mon, Sep 11, 2017 at 12:00:21PM +0200, Thiebaud Weksteen wrote: > >> With TPM 2.0 specification, the event logs may only be accessible by > >> calling an EFI Boot

[PATCH] mm/memcg: avoid page count check for zone device

From: Jérôme Glisse Fix for 4.14, zone device page always have an elevated refcount of one and thus page count sanity check in uncharge_page() is inappropriate for them. Signed-off-by: Jérôme Glisse Reported-by: Evgeny Baskakov Cc:

[PATCH] mm/memcg: avoid page count check for zone device

From: Jérôme Glisse Fix for 4.14, zone device page always have an elevated refcount of one and thus page count sanity check in uncharge_page() is inappropriate for them. Signed-off-by: Jérôme Glisse Reported-by: Evgeny Baskakov Cc: Andrew Morton Cc: Johannes Weiner Cc: Michal Hocko Cc:

Re: [PATCH for 4.9 11/59] MIPS: fix mem=X@Y commandline processing

On Thu, Sep 14, 2017 at 5:51 PM, Levin, Alexander (Sasha Levin) wrote: > From: Marcin Nowakowski > > [ Upstream commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411 ] > > When a memory offset is specified through the commandline, add the >

Re: [PATCH for 4.9 11/59] MIPS: fix mem=X@Y commandline processing

On Thu, Sep 14, 2017 at 5:51 PM, Levin, Alexander (Sasha Levin) wrote: > From: Marcin Nowakowski > > [ Upstream commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411 ] > > When a memory offset is specified through the commandline, add the > memory in range PHYS_OFFSET:Y as reserved memory area. >

[PATCH] ata: pata_artop: remove redundant initialization of pio

From: Colin Ian King pio is initialized and the data is never read, instead it is almost immediately being updated to a new value. Fix this by removing the initialization. Detected by scan-build: "warning: Value stored to 'pio' during its initialization is never read"

[PATCH] ata: pata_artop: remove redundant initialization of pio

From: Colin Ian King pio is initialized and the data is never read, instead it is almost immediately being updated to a new value. Fix this by removing the initialization. Detected by scan-build: "warning: Value stored to 'pio' during its initialization is never read" Fixes: 669a5db411d8

Re: [PATCH v5 05/10] dt-bindings: net: dwmac-sun8i: update documentation about integrated PHY

On Wed, Sep 13, 2017 at 01:20:04PM -0500, Rob Herring wrote: > On Fri, Sep 08, 2017 at 09:43:25AM +0200, Corentin Labbe wrote: > > On Fri, Sep 08, 2017 at 09:25:38AM +0200, Maxime Ripard wrote: > > > On Fri, Sep 08, 2017 at 09:11:51AM +0200, Corentin Labbe wrote: > > > > This patch add

Re: [PATCH v5 05/10] dt-bindings: net: dwmac-sun8i: update documentation about integrated PHY

On Wed, Sep 13, 2017 at 01:20:04PM -0500, Rob Herring wrote: > On Fri, Sep 08, 2017 at 09:43:25AM +0200, Corentin Labbe wrote: > > On Fri, Sep 08, 2017 at 09:25:38AM +0200, Maxime Ripard wrote: > > > On Fri, Sep 08, 2017 at 09:11:51AM +0200, Corentin Labbe wrote: > > > > This patch add

Re: [PATCH] Input: add support for HiDeep touchscreen

Hi Anthony, On Thu, Sep 14, 2017 at 01:36:44PM +0900, Anthony Kim wrote: > The HiDeep touchscreen device is a capacitive multi-touch controller > mainly for multi-touch supported devices use. It use I2C interface for > communication to IC and provide axis X, Y, Z locations for ten finger > touch

Re: [PATCH] Input: add support for HiDeep touchscreen

Hi Anthony, On Thu, Sep 14, 2017 at 01:36:44PM +0900, Anthony Kim wrote: > The HiDeep touchscreen device is a capacitive multi-touch controller > mainly for multi-touch supported devices use. It use I2C interface for > communication to IC and provide axis X, Y, Z locations for ten finger > touch

Re: [PATCH 1/3] ASoC: max98927: Added support for DSP_A and DSP_B format

On Mon, Sep 11, 2017 at 09:12:18AM -0700, Ryan Lee wrote: > Signed-off-by: Ryan Lee > --- Please make an effort to write changelogs that clearly describe the change you're making. This is doing way more than just implementing DSP mode, it's also adding a fairly

Re: [PATCH 1/3] ASoC: max98927: Added support for DSP_A and DSP_B format

On Mon, Sep 11, 2017 at 09:12:18AM -0700, Ryan Lee wrote: > Signed-off-by: Ryan Lee > --- Please make an effort to write changelogs that clearly describe the change you're making. This is doing way more than just implementing DSP mode, it's also adding a fairly complicated set_tdm_slot()

Re: [PATCH v2 2/3] efi: call get_event_log before ExitBootServices

On Thu, Sep 14, 2017 at 11:43 AM, Jarkko Sakkinen wrote: > On Mon, Sep 11, 2017 at 12:00:21PM +0200, Thiebaud Weksteen wrote: >> With TPM 2.0 specification, the event logs may only be accessible by >> calling an EFI Boot Service. Modify the EFI stub to copy the

Re: [PATCH v2 2/3] efi: call get_event_log before ExitBootServices

On Thu, Sep 14, 2017 at 11:43 AM, Jarkko Sakkinen wrote: > On Mon, Sep 11, 2017 at 12:00:21PM +0200, Thiebaud Weksteen wrote: >> With TPM 2.0 specification, the event logs may only be accessible by >> calling an EFI Boot Service. Modify the EFI stub to copy the log area to >> a new Linux-specific

Re: [PATCH v2 3/3] tpm: parse TPM event logs based on EFI table

On Mon, Sep 11, 2017 at 12:00:22PM +0200, Thiebaud Weksteen wrote: > If we are not able to retrieve the TPM event logs from the ACPI table, > check the EFI configuration table (Linux-specific GUID). > > The format version of the log may be returned by the function. If not > specified (by previous

Re: [PATCH v2 3/3] tpm: parse TPM event logs based on EFI table

On Mon, Sep 11, 2017 at 12:00:22PM +0200, Thiebaud Weksteen wrote: > If we are not able to retrieve the TPM event logs from the ACPI table, > check the EFI configuration table (Linux-specific GUID). > > The format version of the log may be returned by the function. If not > specified (by previous

[PATCH 1/6] ACPI/PPTT: Add Processor Properties Topology Table parsing

ACPI 6.2 adds a new table, which describes how processing units are related to each other in tree like fashion. Caches are also sprinkled throughout the tree and describe the properties of the caches in relation to other caches and processing units. Add the code to parse the cache hierarchy and

[PATCH 1/6] ACPI/PPTT: Add Processor Properties Topology Table parsing

ACPI 6.2 adds a new table, which describes how processing units are related to each other in tree like fashion. Caches are also sprinkled throughout the tree and describe the properties of the caches in relation to other caches and processing units. Add the code to parse the cache hierarchy and

[PATCH 1/6] ACPI/PPTT: Add Processor Properties Topology Table parsing

ACPI 6.2 adds a new table, which describes how processing units are related to each other in tree like fashion. Caches are also sprinkled throughout the tree and describe the properties of the caches in relation to other caches and processing units. Add the code to parse the cache hierarchy and

[PATCH 1/6] ACPI/PPTT: Add Processor Properties Topology Table parsing

ACPI 6.2 adds a new table, which describes how processing units are related to each other in tree like fashion. Caches are also sprinkled throughout the tree and describe the properties of the caches in relation to other caches and processing units. Add the code to parse the cache hierarchy and

[PATCH v2] dmaengine: imx-sdma: Correct src_addr_widths and directions

The driver already supports DMA_DEV_TO_DEV in sdma_config(), DMA_SLAVE_BUSWIDTH_2_BYTES and DMA_SLAVE_BUSWIDTH_1_BYTE in sdma_prep_slave_sg(). So this patch adds them to the lists. Signed-off-by: Nicolin Chen --- drivers/dma/imx-sdma.c | 14 +++--- 1 file

[PATCH v2] dmaengine: imx-sdma: Correct src_addr_widths and directions

The driver already supports DMA_DEV_TO_DEV in sdma_config(), DMA_SLAVE_BUSWIDTH_2_BYTES and DMA_SLAVE_BUSWIDTH_1_BYTE in sdma_prep_slave_sg(). So this patch adds them to the lists. Signed-off-by: Nicolin Chen --- drivers/dma/imx-sdma.c | 14 +++--- 1 file changed, 11 insertions(+), 3

Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent

On Thu, Sep 14, 2017 at 11:28:30AM -0700, Linus Torvalds wrote: > On Thu, Sep 14, 2017 at 10:33 AM, Josh Poimboeuf wrote: > >> > >> a) uglifying the 15 or so relevant inline asm locations with ifdefs; or > > > > Actually I guess we could put the "sp" in a macro... I'll try

Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent

On Thu, Sep 14, 2017 at 11:28:30AM -0700, Linus Torvalds wrote: > On Thu, Sep 14, 2017 at 10:33 AM, Josh Poimboeuf wrote: > >> > >> a) uglifying the 15 or so relevant inline asm locations with ifdefs; or > > > > Actually I guess we could put the "sp" in a macro... I'll try it. > > Exactly. Do

Re: [PATCH v2 2/3] efi: call get_event_log before ExitBootServices

On Mon, Sep 11, 2017 at 12:00:21PM +0200, Thiebaud Weksteen wrote: > With TPM 2.0 specification, the event logs may only be accessible by > calling an EFI Boot Service. Modify the EFI stub to copy the log area to > a new Linux-specific EFI configuration table so it remains accessible > once

Re: [PATCH v2 2/3] efi: call get_event_log before ExitBootServices

On Mon, Sep 11, 2017 at 12:00:21PM +0200, Thiebaud Weksteen wrote: > With TPM 2.0 specification, the event logs may only be accessible by > calling an EFI Boot Service. Modify the EFI stub to copy the log area to > a new Linux-specific EFI configuration table so it remains accessible > once

Re: [PATCH] dmaengine: imx-sdma: Correct addr widths

On Wed, Sep 13, 2017 at 10:39:20PM -0700, Nicolin Chen wrote: > The driver also supports 2_BYTES and 1_BYTE in sdma_prep_slave_sg(). > So this patch just adds them to the lists. > > Signed-off-by: Nicolin Chen Please ignore this one as I just found the "directions" is

Re: [PATCH] dmaengine: imx-sdma: Correct addr widths

On Wed, Sep 13, 2017 at 10:39:20PM -0700, Nicolin Chen wrote: > The driver also supports 2_BYTES and 1_BYTE in sdma_prep_slave_sg(). > So this patch just adds them to the lists. > > Signed-off-by: Nicolin Chen Please ignore this one as I just found the "directions" is also wrong. Sending a

Re: [alsa-devel] [PATCH] ALSA: oxygen: Xonar DG(X): make model_xonar_dg const

Bhumika Goyal wrote: > Make this const as it not modified anywhere. It is only used during a > copy operation. Also, add const to the declaration in header. > > Signed-off-by: Bhumika Goyal Acked-by: Clemens Ladisch > --- > sound/pci/oxygen/xonar_dg.h

Re: [alsa-devel] [PATCH] ALSA: oxygen: Xonar DG(X): make model_xonar_dg const

Bhumika Goyal wrote: > Make this const as it not modified anywhere. It is only used during a > copy operation. Also, add const to the declaration in header. > > Signed-off-by: Bhumika Goyal Acked-by: Clemens Ladisch > --- > sound/pci/oxygen/xonar_dg.h | 2 +- >

Re: [PATCH] net/mlx5: fpga: avoid uninitialized return codes

On Thu, Sep 14, 2017 at 5:54 AM, Leon Romanovsky wrote: > On Thu, Sep 14, 2017 at 01:06:18PM +0200, Arnd Bergmann wrote: >> calling mlx5_fpga_mem_{read,write}_i2c() with a zero length on >> older compiler version such as gcc-4.6 results in a warning that >> the return code is

Re: [PATCH] net/mlx5: fpga: avoid uninitialized return codes

On Thu, Sep 14, 2017 at 5:54 AM, Leon Romanovsky wrote: > On Thu, Sep 14, 2017 at 01:06:18PM +0200, Arnd Bergmann wrote: >> calling mlx5_fpga_mem_{read,write}_i2c() with a zero length on >> older compiler version such as gcc-4.6 results in a warning that >> the return code is not initialized: >>

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

On Thu, Sep 14, 2017 at 02:30:17AM +0100, Al Viro wrote: > On Wed, Sep 13, 2017 at 06:10:48PM -0700, Jaegeuk Kim wrote: > > > Android triggers umount(2) by init process, which is definitely not a kernel > > thread. But, we've seen some kernel panics which say umount(2) was > > succeeded, > > but

Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

On Thu, Sep 14, 2017 at 02:30:17AM +0100, Al Viro wrote: > On Wed, Sep 13, 2017 at 06:10:48PM -0700, Jaegeuk Kim wrote: > > > Android triggers umount(2) by init process, which is definitely not a kernel > > thread. But, we've seen some kernel panics which say umount(2) was > > succeeded, > > but

Re: [kernel-hardening] [PATCH v6 10/11] mm: add a user_virt_to_phys symbol

On Thu, Sep 07, 2017 at 11:36:08AM -0600, Tycho Andersen wrote: > We need someting like this for testing XPFO. Since it's architecture > specific, putting it in the test code is slightly awkward, so let's make it > an arch-specific symbol and export it for use in LKDTM. > > v6: * add a definition

Re: [kernel-hardening] [PATCH v6 10/11] mm: add a user_virt_to_phys symbol

On Thu, Sep 07, 2017 at 11:36:08AM -0600, Tycho Andersen wrote: > We need someting like this for testing XPFO. Since it's architecture > specific, putting it in the test code is slightly awkward, so let's make it > an arch-specific symbol and export it for use in LKDTM. > > v6: * add a definition

Re: [PATCH v2 06/14] irqchip: add initial support for ompic

On Thu, Sep 14 2017 at 3:54:02 pm BST, Stafford Horne wrote: > On Wed, Sep 13, 2017 at 06:21:39PM +0100, Marc Zyngier wrote: [...] >> > +{ >> > + unsigned int dst_cpu; >> > + unsigned int src_cpu = smp_processor_id(); >> > + >> > + for_each_cpu(dst_cpu, mask) { >> > +

Re: [PATCH v5 02/10] dt-bindings: net: Restore sun8i dwmac binding

On Wed, Sep 13, 2017 at 01:07:34PM -0500, Rob Herring wrote: > On Fri, Sep 08, 2017 at 09:11:48AM +0200, Corentin Labbe wrote: > > This patch restore dt-bindings documentation about dwmac-sun8i > > This reverts commit 8aa33ec2f481 ("dt-bindings: net: Revert sun8i dwmac > > binding") > > Why? >

Re: [PATCH v2 06/14] irqchip: add initial support for ompic

On Thu, Sep 14 2017 at 3:54:02 pm BST, Stafford Horne wrote: > On Wed, Sep 13, 2017 at 06:21:39PM +0100, Marc Zyngier wrote: [...] >> > +{ >> > + unsigned int dst_cpu; >> > + unsigned int src_cpu = smp_processor_id(); >> > + >> > + for_each_cpu(dst_cpu, mask) { >> > +

Re: [PATCH v5 02/10] dt-bindings: net: Restore sun8i dwmac binding

On Wed, Sep 13, 2017 at 01:07:34PM -0500, Rob Herring wrote: > On Fri, Sep 08, 2017 at 09:11:48AM +0200, Corentin Labbe wrote: > > This patch restore dt-bindings documentation about dwmac-sun8i > > This reverts commit 8aa33ec2f481 ("dt-bindings: net: Revert sun8i dwmac > > binding") > > Why? >

Re: [PATCH v8 11/28] x86/insn-eval: Add utility function to identify string instructions

On Fri, 2017-09-08 at 15:57 +0200, Borislav Petkov wrote: > On Fri, Aug 18, 2017 at 05:27:52PM -0700, Ricardo Neri wrote: > > > > String instructions are special because, in protected mode, the > > linear > > address is always obtained via the ES segment register in operands > > that > > use the

Re: [PATCH v8 11/28] x86/insn-eval: Add utility function to identify string instructions

On Fri, 2017-09-08 at 15:57 +0200, Borislav Petkov wrote: > On Fri, Aug 18, 2017 at 05:27:52PM -0700, Ricardo Neri wrote: > > > > String instructions are special because, in protected mode, the > > linear > > address is always obtained via the ES segment register in operands > > that > > use the

Re: [v4 05/11] soc/fsl/qbman: Drop L1_CACHE_BYTES compile time check

On 9/14/2017 9:49 AM, Catalin Marinas wrote: > On Thu, Aug 24, 2017 at 04:37:49PM -0400, Roy Pledge wrote: >> From: Claudiu Manoil >> >> Not relevant and arch dependent. Overkill for PPC. >> >> Signed-off-by: Claudiu Manoil >> Signed-off-by: Roy

Re: [v4 05/11] soc/fsl/qbman: Drop L1_CACHE_BYTES compile time check

On 9/14/2017 9:49 AM, Catalin Marinas wrote: > On Thu, Aug 24, 2017 at 04:37:49PM -0400, Roy Pledge wrote: >> From: Claudiu Manoil >> >> Not relevant and arch dependent. Overkill for PPC. >> >> Signed-off-by: Claudiu Manoil >> Signed-off-by: Roy Pledge >> --- >>

Re: [PATCH v8 10/28] x86/insn-eval: Add a utility function to get register offsets

On Fri, 2017-09-08 at 15:35 +0200, Borislav Petkov wrote: > On Fri, Aug 18, 2017 at 05:27:51PM -0700, Ricardo Neri wrote: > > > > The function get_reg_offset() returns the offset to the register > > the > > argument specifies as indicated in an enumeration of type offset. > > Callers > > of this

Re: [PATCH v8 10/28] x86/insn-eval: Add a utility function to get register offsets

On Fri, 2017-09-08 at 15:35 +0200, Borislav Petkov wrote: > On Fri, Aug 18, 2017 at 05:27:51PM -0700, Ricardo Neri wrote: > > > > The function get_reg_offset() returns the offset to the register > > the > > argument specifies as indicated in an enumeration of type offset. > > Callers > > of this

Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent

On Thu, Sep 14, 2017 at 10:33 AM, Josh Poimboeuf wrote: >> >> a) uglifying the 15 or so relevant inline asm locations with ifdefs; or > > Actually I guess we could put the "sp" in a macro... I'll try it. Exactly. Do something like #ifdef CONFIG_FRAME_POINTER #

Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent

On Thu, Sep 14, 2017 at 10:33 AM, Josh Poimboeuf wrote: >> >> a) uglifying the 15 or so relevant inline asm locations with ifdefs; or > > Actually I guess we could put the "sp" in a macro... I'll try it. Exactly. Do something like #ifdef CONFIG_FRAME_POINTER # define EXTRA_ASM_CLOBBERS

Re: [PATCH v6 07/11] arm64/mm, xpfo: temporarily map dcache regions

On Thu, Sep 07, 2017 at 11:36:05AM -0600, Tycho Andersen wrote: > From: Juerg Haefliger > > If the page is unmapped by XPFO, a data cache flush results in a fatal > page fault, so let's temporarily map the region, flush the cache, and then > unmap it. > > v6:

Re: [PATCH v6 07/11] arm64/mm, xpfo: temporarily map dcache regions

On Thu, Sep 07, 2017 at 11:36:05AM -0600, Tycho Andersen wrote: > From: Juerg Haefliger > > If the page is unmapped by XPFO, a data cache flush results in a fatal > page fault, so let's temporarily map the region, flush the cache, and then > unmap it. > > v6: actually flush in the face of xpfo,

[PATCH v2] android: binder: Drop lru lock in isolate callback

Drop the global lru lock in isolate callback before calling zap_page_range which calls cond_resched, and re-acquire the global lru lock before returning. Also change return code to LRU_REMOVED_RETRY. Use mmput_async when fail to acquire mmap sem in an atomic context. Fix "BUG: sleeping function

[PATCH v2] android: binder: Drop lru lock in isolate callback

Drop the global lru lock in isolate callback before calling zap_page_range which calls cond_resched, and re-acquire the global lru lock before returning. Also change return code to LRU_REMOVED_RETRY. Use mmput_async when fail to acquire mmap sem in an atomic context. Fix "BUG: sleeping function

Re: [kernel-hardening] [PATCH v6 05/11] arm64/mm: Add support for XPFO

Hi, On Thu, Sep 07, 2017 at 11:36:03AM -0600, Tycho Andersen wrote: > From: Juerg Haefliger > > Enable support for eXclusive Page Frame Ownership (XPFO) for arm64 and > provide a hook for updating a single kernel page table entry (which is > required by the

Re: [kernel-hardening] [PATCH v6 05/11] arm64/mm: Add support for XPFO

Hi, On Thu, Sep 07, 2017 at 11:36:03AM -0600, Tycho Andersen wrote: > From: Juerg Haefliger > > Enable support for eXclusive Page Frame Ownership (XPFO) for arm64 and > provide a hook for updating a single kernel page table entry (which is > required by the generic XPFO code). > > v6: use

Re: kernel BUG at fs/ext4/fsync.c:LINE!

On Fri, Sep 15, 2017 at 12:41 AM, Andreas Dilger wrote: > I don't think a reproducer is needed. It looks like the fsync callpath > is happening from an IRQ context due to IO completion, and then re-entering > the filesystem while a transaction is already started. It looks

Re: kernel BUG at fs/ext4/fsync.c:LINE!

On Fri, Sep 15, 2017 at 12:41 AM, Andreas Dilger wrote: > I don't think a reproducer is needed. It looks like the fsync callpath > is happening from an IRQ context due to IO completion, and then re-entering > the filesystem while a transaction is already started. It looks like the > original IO

Re: RFC: Audit Kernel Container IDs

On 2017-09-14 12:33, Eric W. Biederman wrote: > Richard Guy Briggs writes: > > > The trigger is a pseudo filesystem (proc, since PID tree already exists) > > write of a u64 representing the container ID to a file representing a > > process that will become the first process in a

Re: RFC: Audit Kernel Container IDs

On 2017-09-14 12:33, Eric W. Biederman wrote: > Richard Guy Briggs writes: > > > The trigger is a pseudo filesystem (proc, since PID tree already exists) > > write of a u64 representing the container ID to a file representing a > > process that will become the first process in a new container. >

Re: RTL8192EE PCIe Wireless Network Adapter crashed with linux-4.13

On 09/14/2017 08:30 AM, Zwindl wrote: Dear developers: I'm using Arch Linux with testing enabled, the current kernel version and details are `Linux zwindl 4.13.2-1-ARCH #1 SMP PREEMPT Thu Sep 14 02:57:34 UTC 2017 x86_64 GNU/Linux`. The wireless card can't work properly from the kernel 4.13.

Re: RTL8192EE PCIe Wireless Network Adapter crashed with linux-4.13

On 09/14/2017 08:30 AM, Zwindl wrote: Dear developers: I'm using Arch Linux with testing enabled, the current kernel version and details are `Linux zwindl 4.13.2-1-ARCH #1 SMP PREEMPT Thu Sep 14 02:57:34 UTC 2017 x86_64 GNU/Linux`. The wireless card can't work properly from the kernel 4.13.

[PATCH] crypto: algboss: remove redundant setting of len to zero

From: Colin Ian King The variable len is set to zero, never read and then later updated to p - name, so clearly the zero'ing of len is redundant and can be removed. Detected by clang scan-build: " warning: Value stored to 'len' is never read" Signed-off-by: Colin Ian

[PATCH] crypto: algboss: remove redundant setting of len to zero

From: Colin Ian King The variable len is set to zero, never read and then later updated to p - name, so clearly the zero'ing of len is redundant and can be removed. Detected by clang scan-build: " warning: Value stored to 'len' is never read" Signed-off-by: Colin Ian King ---

Re: usb/gadget: stalls in dummy_timer

On Thu, Sep 14, 2017 at 7:49 PM, Alan Stern wrote: > On Thu, 14 Sep 2017, Andrey Konovalov wrote: > >> Looked at this a little more. >> >> dummy_timer() stucks in an infinite loop. It calls >> usb_hcd_giveback_urb(), which in turn calls usbtouch_irq(), which >> calls

Re: usb/gadget: stalls in dummy_timer

On Thu, Sep 14, 2017 at 7:49 PM, Alan Stern wrote: > On Thu, 14 Sep 2017, Andrey Konovalov wrote: > >> Looked at this a little more. >> >> dummy_timer() stucks in an infinite loop. It calls >> usb_hcd_giveback_urb(), which in turn calls usbtouch_irq(), which >> calls usb_submit_urb(), which calls

Re: [PATCH 1/3] mm: slab: output reclaimable flag in /proc/slabinfo

On 9/14/17 10:27 AM, Christopher Lameter wrote: Well /proc/slabinfo is a legacy interface. The infomation if a slab is reclaimable is available via the slabinfo tool. We would break a format that is relied upon by numerous tools. Thanks for pointing this out. It would be unacceptable if it

Re: [PATCH 1/3] mm: slab: output reclaimable flag in /proc/slabinfo

On 9/14/17 10:27 AM, Christopher Lameter wrote: Well /proc/slabinfo is a legacy interface. The infomation if a slab is reclaimable is available via the slabinfo tool. We would break a format that is relied upon by numerous tools. Thanks for pointing this out. It would be unacceptable if it

Re: [PATCH] mm,compaction: serialize waitqueue_active() checks (for real)

On Wed, 13 Sep 2017, Davidlohr Bueso wrote: - /* -* Pairs with implicit barrier in wait_event_freezable() -* such that wakeups are not missed in the lockless -* waitqueue_active() call. -*/ smp_acquire__after_ctrl_dep(); sorry, forgot to delete

Re: [PATCH] mm,compaction: serialize waitqueue_active() checks (for real)

On Wed, 13 Sep 2017, Davidlohr Bueso wrote: - /* -* Pairs with implicit barrier in wait_event_freezable() -* such that wakeups are not missed in the lockless -* waitqueue_active() call. -*/ smp_acquire__after_ctrl_dep(); sorry, forgot to delete

Re: usb/gadget: stalls in dummy_timer

On Thu, 14 Sep 2017, Andrey Konovalov wrote: > Looked at this a little more. > > dummy_timer() stucks in an infinite loop. It calls > usb_hcd_giveback_urb(), which in turn calls usbtouch_irq(), which > calls usb_submit_urb(), which calls dummy_urb_enqueue() and puts urb > back into dummy urb

Re: usb/gadget: stalls in dummy_timer

On Thu, 14 Sep 2017, Andrey Konovalov wrote: > Looked at this a little more. > > dummy_timer() stucks in an infinite loop. It calls > usb_hcd_giveback_urb(), which in turn calls usbtouch_irq(), which > calls usb_submit_urb(), which calls dummy_urb_enqueue() and puts urb > back into dummy urb

Re: [PATCH 3/3] mm: oom: show unreclaimable slab info when kernel panic

On 9/14/17 10:32 AM, Christopher Lameter wrote: I am not sure that this is generally useful at OOM times unless this is not a rare occurrence. I would say it is not very rare. But, it is definitely troublesome to narrow down without certain information about slab usage when it happens.

Re: [PATCH 3/3] mm: oom: show unreclaimable slab info when kernel panic

On 9/14/17 10:32 AM, Christopher Lameter wrote: I am not sure that this is generally useful at OOM times unless this is not a rare occurrence. I would say it is not very rare. But, it is definitely troublesome to narrow down without certain information about slab usage when it happens.

Re: [PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

On Wed, Sep 13, 2017 at 06:51:25PM -0500, Rob Landley wrote: > From: Rob Landley > > Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move > /dev/console open after devtmpfs mount. > > Add workaround for Debian bug that was copied by Ubuntu. > > Signed-off-by: Rob Landley

Re: [PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

On Wed, Sep 13, 2017 at 06:51:25PM -0500, Rob Landley wrote: > From: Rob Landley > > Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move > /dev/console open after devtmpfs mount. > > Add workaround for Debian bug that was copied by Ubuntu. > > Signed-off-by: Rob Landley > --- > > v2

Re: [x86/topology] 05aa90edc7: kernel_BUG_at_arch/x86/kernel/cpu/common.c

> Everytime a socket is down'd and up'd the logical_packages value increases by > one, and eventually overflows. > > Andi -- I can add this to your patch if you're okay with it. Sure looks good (minus all the pr_debugs). Thanks for debugging. -Andi

Re: [x86/topology] 05aa90edc7: kernel_BUG_at_arch/x86/kernel/cpu/common.c

> Everytime a socket is down'd and up'd the logical_packages value increases by > one, and eventually overflows. > > Andi -- I can add this to your patch if you're okay with it. Sure looks good (minus all the pr_debugs). Thanks for debugging. -Andi

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