Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 01:34 PM, Mark Lord wrote: >From tracing through the powerpc arch code, this is the buffer that > is being directly DMA'd into. And the USB layer does an invalidate_dcache > on that entire buffer before initiating the DMA (confirmed via printk). Slight correction: the

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 01:34 PM, Mark Lord wrote: >From tracing through the powerpc arch code, this is the buffer that > is being directly DMA'd into. And the USB layer does an invalidate_dcache > on that entire buffer before initiating the DMA (confirmed via printk). Slight correction: the

Re: [PATCH 9/9] arm64: Documentation - Expose CPU feature registers

Hi Suzuki, On Thu, Nov 24, 2016 at 01:40:09PM +, Suzuki K. Poulose wrote: > --- /dev/null > +++ b/Documentation/arm64/cpu-feature-registers.txt > @@ -0,0 +1,198 @@ > + ARM64 CPU Feature Registers > + === > + > +Author: Suzuki K Poulose

Re: [PATCH 9/9] arm64: Documentation - Expose CPU feature registers

Hi Suzuki, On Thu, Nov 24, 2016 at 01:40:09PM +, Suzuki K. Poulose wrote: > --- /dev/null > +++ b/Documentation/arm64/cpu-feature-registers.txt > @@ -0,0 +1,198 @@ > + ARM64 CPU Feature Registers > + === > + > +Author: Suzuki K Poulose > + > +

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On Thu, Nov 24, 2016 at 11:43:53AM -0500, Mark Lord wrote: > On 16-11-24 11:21 AM, David Miller wrote: > > From: Hayes Wang > > Date: Thu, 24 Nov 2016 13:26:55 + > > > > > I don't think the garbage results from our driver or device. > > This is my impression with what

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On Thu, Nov 24, 2016 at 11:43:53AM -0500, Mark Lord wrote: > On 16-11-24 11:21 AM, David Miller wrote: > > From: Hayes Wang > > Date: Thu, 24 Nov 2016 13:26:55 + > > > > > I don't think the garbage results from our driver or device. > > This is my impression with what has been presented so

Re: [PATCH] Add IDT 89HPESx EEPROM/CSR driver

On Sun, Oct 30, 2016 at 09:53:58AM -0400, Greg KH wrote: > On Mon, Oct 03, 2016 at 02:13:45AM +0300, Serge Semin wrote: > > Hello linux folks, > > > > This driver primarily is developed to give an access to EEPROM of IDT > > PCIe-switches. Such switches provide

Re: [PATCH] Add IDT 89HPESx EEPROM/CSR driver

On Sun, Oct 30, 2016 at 09:53:58AM -0400, Greg KH wrote: > On Mon, Oct 03, 2016 at 02:13:45AM +0300, Serge Semin wrote: > > Hello linux folks, > > > > This driver primarily is developed to give an access to EEPROM of IDT > > PCIe-switches. Such switches provide a simple SMBus interface to

Re: wl1251 & mac address & calibration data

On Thursday 24 November 2016 19:11:39 Sebastian Reichel wrote: > Hi, > > On Thu, Nov 24, 2016 at 05:49:33PM +0100, Pali Rohár wrote: > > On Thursday 24 November 2016 17:08:30 Sebastian Reichel wrote: > > > On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote: > > > > On Thursday 24 November

Re: wl1251 & mac address & calibration data

On Thursday 24 November 2016 19:11:39 Sebastian Reichel wrote: > Hi, > > On Thu, Nov 24, 2016 at 05:49:33PM +0100, Pali Rohár wrote: > > On Thursday 24 November 2016 17:08:30 Sebastian Reichel wrote: > > > On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote: > > > > On Thursday 24 November

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 12:11 PM, David Miller wrote: > From: Mark Lord > Date: Thu, 24 Nov 2016 11:43:53 -0500 > >> So even if this were a platform memory coherency issue, one should >> still never see ASCII data at the beginning of an rx buffer. > > I'm not so convinced, since this is

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 12:11 PM, David Miller wrote: > From: Mark Lord > Date: Thu, 24 Nov 2016 11:43:53 -0500 > >> So even if this were a platform memory coherency issue, one should >> still never see ASCII data at the beginning of an rx buffer. > > I'm not so convinced, since this is the kind of random

Re: [PATCH 01/14] perf/x86: Introduce PERF_RECORD_OVERHEAD

On Thu, Nov 24, 2016 at 02:50:43PM +0100, Peter Zijlstra wrote: > On Thu, Nov 24, 2016 at 01:45:28PM +, Liang, Kan wrote: > > > I think we should make this optional/configurable like the rest of the aux > > > events, like below.. > > > > > > > The overhead logging only happens when event is

Re: [PATCH 01/14] perf/x86: Introduce PERF_RECORD_OVERHEAD

On Thu, Nov 24, 2016 at 02:50:43PM +0100, Peter Zijlstra wrote: > On Thu, Nov 24, 2016 at 01:45:28PM +, Liang, Kan wrote: > > > I think we should make this optional/configurable like the rest of the aux > > > events, like below.. > > > > > > > The overhead logging only happens when event is

[PATCH net v2 3/5] net: fsl/fman: fix phydev reference leak

Make sure to drop the reference taken by of_phy_find_device() during initialisation when later freeing the struct fman_mac. Fixes: 57ba4c9b56d8 ("fsl/fman: Add FMan MAC support") Signed-off-by: Johan Hovold --- drivers/net/ethernet/freescale/fman/fman_memac.c | 3 +++ 1 file

[PATCH net v2 3/5] net: fsl/fman: fix phydev reference leak

Make sure to drop the reference taken by of_phy_find_device() during initialisation when later freeing the struct fman_mac. Fixes: 57ba4c9b56d8 ("fsl/fman: Add FMan MAC support") Signed-off-by: Johan Hovold --- drivers/net/ethernet/freescale/fman/fman_memac.c | 3 +++ 1 file changed, 3

[PATCH net v2 1/5] net: dsa: fix fixed-link-phy device leaks

Make sure to drop the reference taken by of_phy_find_device() when registering and deregistering the fixed-link PHY-device. Fixes: 39b0c705195e ("net: dsa: Allow configuration of CPU & DSA port speeds/duplex") Signed-off-by: Johan Hovold --- net/dsa/dsa.c | 5 - 1 file

[PATCH net v2 5/5] net: qcom/emac: fix of_node and phydev leaks

Make sure to drop the reference taken by of_phy_find_device() during probe on probe errors and on driver unbind. Also drop the of_node reference taken by of_parse_phandle() in the same path. Fixes: b9b17debc69d ("net: emac: emac gigabit ethernet controller driver") Signed-off-by: Johan Hovold

[PATCH net v2 1/5] net: dsa: fix fixed-link-phy device leaks

Make sure to drop the reference taken by of_phy_find_device() when registering and deregistering the fixed-link PHY-device. Fixes: 39b0c705195e ("net: dsa: Allow configuration of CPU & DSA port speeds/duplex") Signed-off-by: Johan Hovold --- net/dsa/dsa.c | 5 - 1 file changed, 4

[PATCH net v2 5/5] net: qcom/emac: fix of_node and phydev leaks

Make sure to drop the reference taken by of_phy_find_device() during probe on probe errors and on driver unbind. Also drop the of_node reference taken by of_parse_phandle() in the same path. Fixes: b9b17debc69d ("net: emac: emac gigabit ethernet controller driver") Signed-off-by: Johan Hovold

[PATCH net v2 0/5] net: fix phydev reference leaks

This series fixes a number of phydev reference leaks (and one of_node leak) due to failure to put the reference taken by of_phy_find_device(). Note that I did not try to fix drivers/net/phy/xilinx_gmii2rgmii.c which still leaks a reference. Against net but should apply just as fine to net-next.

[PATCH net v2 2/5] net: bcmgenet: fix phydev reference leak

Make sure to drop the reference taken by of_phy_find_device() when initialising MOCA PHYs. Fixes: 6ac9de5f6563 ("net: bcmgenet: Register link_update callback for all MoCA PHYs") Signed-off-by: Johan Hovold --- drivers/net/ethernet/broadcom/genet/bcmmii.c | 4 +++- 1 file

[PATCH net v2 0/5] net: fix phydev reference leaks

This series fixes a number of phydev reference leaks (and one of_node leak) due to failure to put the reference taken by of_phy_find_device(). Note that I did not try to fix drivers/net/phy/xilinx_gmii2rgmii.c which still leaks a reference. Against net but should apply just as fine to net-next.

[PATCH net v2 2/5] net: bcmgenet: fix phydev reference leak

Make sure to drop the reference taken by of_phy_find_device() when initialising MOCA PHYs. Fixes: 6ac9de5f6563 ("net: bcmgenet: Register link_update callback for all MoCA PHYs") Signed-off-by: Johan Hovold --- drivers/net/ethernet/broadcom/genet/bcmmii.c | 4 +++- 1 file changed, 3

[PATCH net v2 4/5] net: fsl/fman: fix fixed-link-phydev reference leak

Make sure to drop the reference taken by of_phy_find_device() when looking up a fixed-link phydev during probe. Fixes: 57ba4c9b56d8 ("fsl/fman: Add FMan MAC support") Signed-off-by: Johan Hovold --- drivers/net/ethernet/freescale/fman/mac.c | 2 ++ 1 file changed, 2

[PATCH net v2 4/5] net: fsl/fman: fix fixed-link-phydev reference leak

Make sure to drop the reference taken by of_phy_find_device() when looking up a fixed-link phydev during probe. Fixes: 57ba4c9b56d8 ("fsl/fman: Add FMan MAC support") Signed-off-by: Johan Hovold --- drivers/net/ethernet/freescale/fman/mac.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

Re: [PATCH] pinctrl: imx: fix imx_pinctrl_desc initialization

Hi all, Just resending this email since there was a typo in Shawn's e-mail address. Regards, Gary On Thu, Nov 24, 2016 at 07:11:51PM +0100, Gary Bisson wrote: > Was introduced by: > 6e408ed pinctrl: imx: fix initialization of imx_pinctrl_desc > > Signed-off-by: Gary Bisson

Re: [PATCH] pinctrl: imx: fix imx_pinctrl_desc initialization

Hi all, Just resending this email since there was a typo in Shawn's e-mail address. Regards, Gary On Thu, Nov 24, 2016 at 07:11:51PM +0100, Gary Bisson wrote: > Was introduced by: > 6e408ed pinctrl: imx: fix initialization of imx_pinctrl_desc > > Signed-off-by: Gary Bisson > --- >

Re: wl1251 & mac address & calibration data

Hi, On Thu, Nov 24, 2016 at 05:49:33PM +0100, Pali Rohár wrote: > On Thursday 24 November 2016 17:08:30 Sebastian Reichel wrote: > > On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote: > > > On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote: > > > > On Thu, Nov 24, 2016 at

[PATCH] pinctrl: imx: fix imx_pinctrl_desc initialization

Was introduced by: 6e408ed pinctrl: imx: fix initialization of imx_pinctrl_desc Signed-off-by: Gary Bisson --- drivers/pinctrl/freescale/pinctrl-imx.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

Re: wl1251 & mac address & calibration data

Hi, On Thu, Nov 24, 2016 at 05:49:33PM +0100, Pali Rohár wrote: > On Thursday 24 November 2016 17:08:30 Sebastian Reichel wrote: > > On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote: > > > On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote: > > > > On Thu, Nov 24, 2016 at

[PATCH] pinctrl: imx: fix imx_pinctrl_desc initialization

Was introduced by: 6e408ed pinctrl: imx: fix initialization of imx_pinctrl_desc Signed-off-by: Gary Bisson --- drivers/pinctrl/freescale/pinctrl-imx.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c

Re: [PATCH] net: stmmac: enable tx queue 0 for gmac4 IPs synthesized with multiple TX queues

Hi Niklas, On 11/24/2016 03:36 PM, Niklas Cassel wrote: From: Niklas Cassel The dwmac4 IP can synthesized with 1-8 number of tx queues. On an IP synthesized with DWC_EQOS_NUM_TXQ > 1, all txqueues are disabled by default. For these IPs, the bitfield TXQEN is R/W.

Re: [PATCH] net: stmmac: enable tx queue 0 for gmac4 IPs synthesized with multiple TX queues

Hi Niklas, On 11/24/2016 03:36 PM, Niklas Cassel wrote: From: Niklas Cassel The dwmac4 IP can synthesized with 1-8 number of tx queues. On an IP synthesized with DWC_EQOS_NUM_TXQ > 1, all txqueues are disabled by default. For these IPs, the bitfield TXQEN is R/W. Always enable tx queue 0.

Re: Enabling peer to peer device transactions for PCIe devices

On 24/11/16 09:42 AM, Jason Gunthorpe wrote: > There are three cases to worry about: > - Coherent long lived page table mirroring (RDMA ODP MR) > - Non-coherent long lived page table mirroring (RDMA MR) > - Short lived DMA mapping (everything else) > > Like you say below we have to handle

Re: Enabling peer to peer device transactions for PCIe devices

On 24/11/16 09:42 AM, Jason Gunthorpe wrote: > There are three cases to worry about: > - Coherent long lived page table mirroring (RDMA ODP MR) > - Non-coherent long lived page table mirroring (RDMA MR) > - Short lived DMA mapping (everything else) > > Like you say below we have to handle

Re: [PATCH v8 3/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature

> Am 24.11.2016 um 18:38 schrieb Jonathan Cameron : > > > > On 22 November 2016 14:02:30 GMT+00:00, "H. Nikolaus Schaller" > wrote: >> The tsc2007 chip not only has a resistive touch screen controller but >> also an external AUX adc imput

Re: [PATCH v8 3/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature

> Am 24.11.2016 um 18:38 schrieb Jonathan Cameron : > > > > On 22 November 2016 14:02:30 GMT+00:00, "H. Nikolaus Schaller" > wrote: >> The tsc2007 chip not only has a resistive touch screen controller but >> also an external AUX adc imput which can be used for an ambient >> light sensor,

[GIT PULL] one more EFI patch for v4.10

The following changes since commit 9110bc036062fcd31994a35540d63f8deed22efa: thunderbolt: Use Device ROM retrieved from EFI (2016-11-12 21:14:43 +) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-next for you to fetch changes

Re: [PATCH 6/7] ovl: intercept mmap

On Thu, Nov 24, 2016 at 3:25 PM, Amir Goldstein wrote: > On Thu, Nov 24, 2016 at 12:55 PM, Miklos Szeredi wrote: >> ... in order to handle the corner case when the file is copied up after >> being opened read-only and mapped shared. >> >> Can be verified

[GIT PULL] one more EFI patch for v4.10

The following changes since commit 9110bc036062fcd31994a35540d63f8deed22efa: thunderbolt: Use Device ROM retrieved from EFI (2016-11-12 21:14:43 +) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-next for you to fetch changes

Re: [PATCH 6/7] ovl: intercept mmap

On Thu, Nov 24, 2016 at 3:25 PM, Amir Goldstein wrote: > On Thu, Nov 24, 2016 at 12:55 PM, Miklos Szeredi wrote: >> ... in order to handle the corner case when the file is copied up after >> being opened read-only and mapped shared. >> >> Can be verified with the following script: >> >> - 8< -

[PATCH] efi/libstub: Make efi_random_alloc() allocate below 4 GB on 32-bit

The UEFI stub executes in the context of the firmware, which identity maps the available system RAM, which implies that only memory below 4 GB can be used for allocations on 32-bit architectures, even on [L]PAE capable hardware. So ignore any reported memory above 4 GB in efi_random_alloc(). This

[PATCH] efi/libstub: Make efi_random_alloc() allocate below 4 GB on 32-bit

The UEFI stub executes in the context of the firmware, which identity maps the available system RAM, which implies that only memory below 4 GB can be used for allocations on 32-bit architectures, even on [L]PAE capable hardware. So ignore any reported memory above 4 GB in efi_random_alloc(). This

Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI

On Thu, 24 Nov 2016, Peter Zijlstra wrote: > On Wed, Nov 23, 2016 at 08:20:05PM +0100, Peter Zijlstra wrote: > > > + if (oldowner == _task && uval != 0) { > > > + raw_spin_lock(_state->owner->pi_lock); > > > + list_del_init(_state->list); > > > +

Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI

On Thu, 24 Nov 2016, Peter Zijlstra wrote: > On Wed, Nov 23, 2016 at 08:20:05PM +0100, Peter Zijlstra wrote: > > > + if (oldowner == _task && uval != 0) { > > > + raw_spin_lock(_state->owner->pi_lock); > > > + list_del_init(_state->list); > > > +

Re: [PATCH 4/4] net: stmmac: stmmac_platform: use correct setup function for gmac4

Hi Niklas, On 11/23/2016 03:25 PM, Niklas Cassel wrote: From: Niklas Cassel devicetree binding for stmmac states: - compatible: Should be "snps,dwmac-", "snps,dwmac" For backwards compatibility: "st,spear600-gmac" is also supported. Previously, when specifying

Re: [PATCH 4/4] net: stmmac: stmmac_platform: use correct setup function for gmac4

Hi Niklas, On 11/23/2016 03:25 PM, Niklas Cassel wrote: From: Niklas Cassel devicetree binding for stmmac states: - compatible: Should be "snps,dwmac-", "snps,dwmac" For backwards compatibility: "st,spear600-gmac" is also supported. Previously, when specifying "snps,dwmac-4.10a",

Re: Enabling peer to peer device transactions for PCIe devices

Hey, On 24/11/16 02:45 AM, Christian König wrote: > E.g. it can happen that PCI device A exports it's BAR using ZONE_DEVICE. > Not PCI device B (a SATA device) can directly read/write to it because > it is on the same bus segment, but PCI device C (a network card for > example) can't because it

Re: Enabling peer to peer device transactions for PCIe devices

Hey, On 24/11/16 02:45 AM, Christian König wrote: > E.g. it can happen that PCI device A exports it's BAR using ZONE_DEVICE. > Not PCI device B (a SATA device) can directly read/write to it because > it is on the same bus segment, but PCI device C (a network card for > example) can't because it

Re: [patch] iio: tsl2583: make array large enough

On Thu, Nov 24, 2016 at 05:54:17PM +0100, walter harms wrote: > > > Am 24.11.2016 16:48, schrieb Brian Masney: > > On Thu, Nov 24, 2016 at 04:38:07PM +0300, Dan Carpenter wrote: > >> This array is supposed to have 10 elements. Smatch complains that with > >> the current code we can have n ==

Re: [patch] iio: tsl2583: make array large enough

On Thu, Nov 24, 2016 at 05:54:17PM +0100, walter harms wrote: > > > Am 24.11.2016 16:48, schrieb Brian Masney: > > On Thu, Nov 24, 2016 at 04:38:07PM +0300, Dan Carpenter wrote: > >> This array is supposed to have 10 elements. Smatch complains that with > >> the current code we can have n ==

Re: [PATCH 02/29] fscrypt: Allow fscrypt_decrypt_page() to function with non-writeback pages

Eric, > On 15.11.2016, at 19:19, Eric Biggers wrote: > > On Sun, Nov 13, 2016 at 10:20:45PM +0100, Richard Weinberger wrote: >> /** >> * f2crypt_decrypt_page() - Decrypts a page in-place >> - * @page: The page to decrypt. Must be locked. >> + * @inode: The encrypted inode

Re: [PATCH 02/29] fscrypt: Allow fscrypt_decrypt_page() to function with non-writeback pages

Eric, > On 15.11.2016, at 19:19, Eric Biggers wrote: > > On Sun, Nov 13, 2016 at 10:20:45PM +0100, Richard Weinberger wrote: >> /** >> * f2crypt_decrypt_page() - Decrypts a page in-place >> - * @page: The page to decrypt. Must be locked. >> + * @inode: The encrypted inode to decrypt. >> + *

Re: [PATCH 1/4] bindings: net: stmmac: correct note about TSO

Hi Niklas, On 11/23/2016 03:24 PM, Niklas Cassel wrote: From: Niklas Cassel snps,tso was previously placed under AXI BUS Mode parameters, suggesting that the property should be in the stmmac-axi-config node. TSO (TCP Segmentation Offloading) has nothing to do with AXI

Re: [PATCH 1/4] bindings: net: stmmac: correct note about TSO

Hi Niklas, On 11/23/2016 03:24 PM, Niklas Cassel wrote: From: Niklas Cassel snps,tso was previously placed under AXI BUS Mode parameters, suggesting that the property should be in the stmmac-axi-config node. TSO (TCP Segmentation Offloading) has nothing to do with AXI BUS Mode parameters,

Re: [PATCH v8 3/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature

On 22 November 2016 14:02:30 GMT+00:00, "H. Nikolaus Schaller" wrote: >The tsc2007 chip not only has a resistive touch screen controller but >also an external AUX adc imput which can be used for an ambient >light sensor, battery voltage monitoring or any general purpose. >

Re: [PATCH v8 3/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature

On 22 November 2016 14:02:30 GMT+00:00, "H. Nikolaus Schaller" wrote: >The tsc2007 chip not only has a resistive touch screen controller but >also an external AUX adc imput which can be used for an ambient >light sensor, battery voltage monitoring or any general purpose. > >Additionally it can

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

Dominik Brodowski wrote: > > > - Abort in drivers/pcmcia/cistpl.c::pccard_store_cis() or remove > > > write access to the "cis" file in > > > drivers/pcmcia/cistpl.c::pccard_cis_attr > > > > What is that doing? Allowing the device to be reconfigured? > >

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

Dominik Brodowski wrote: > > > - Abort in drivers/pcmcia/cistpl.c::pccard_store_cis() or remove > > > write access to the "cis" file in > > > drivers/pcmcia/cistpl.c::pccard_cis_attr > > > > What is that doing? Allowing the device to be reconfigured? > > Exactly. It is a different

perf: fuzzer BUG: KASAN: stack-out-of-bounds in __unwind_start

This is on a skylake machine, linus git as of yesterday after the various kasan-related fixes went in. Not sure if there were any that hadn't hit upstream yet. Anyway I can't tell from this one what the actual trigger is. After this mess the fuzzer process was locked, udev started

perf: fuzzer BUG: KASAN: stack-out-of-bounds in __unwind_start

This is on a skylake machine, linus git as of yesterday after the various kasan-related fixes went in. Not sure if there were any that hadn't hit upstream yet. Anyway I can't tell from this one what the actual trigger is. After this mess the fuzzer process was locked, udev started

[PATCH] MIPS: Add support for ARCH_MMAP_RND_{COMPAT_}BITS

arch_mmap_rnd() uses hard-coded limits of 16MB for the randomisation of mmap within 32bit processes and 256MB in 64bit processes. Since v4.4 other arches support tuning this value in /proc/sys/vm/mmap_rnd_bits. Add support for this to MIPS. Set the minimum(default) number of bits randomisation

[PATCH] MIPS: Add support for ARCH_MMAP_RND_{COMPAT_}BITS

arch_mmap_rnd() uses hard-coded limits of 16MB for the randomisation of mmap within 32bit processes and 256MB in 64bit processes. Since v4.4 other arches support tuning this value in /proc/sys/vm/mmap_rnd_bits. Add support for this to MIPS. Set the minimum(default) number of bits randomisation

Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing

On Wed, Nov 23, 2016 at 11:44:19AM -0700, Ross Zwisler wrote: > Tracepoints are the standard way to capture debugging and tracing > information in many parts of the kernel, including the XFS and ext4 > filesystems. Create a tracepoint header for FS DAX and add the first DAX > tracepoints to the

Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing

On Wed, Nov 23, 2016 at 11:44:19AM -0700, Ross Zwisler wrote: > Tracepoints are the standard way to capture debugging and tracing > information in many parts of the kernel, including the XFS and ext4 > filesystems. Create a tracepoint header for FS DAX and add the first DAX > tracepoints to the

Re: [RFC PATCH net v2 0/3] Fix OdroidC2 Gigabit Tx link issue

On Thu, Nov 24, 2016 at 5:01 PM, Jerome Brunet wrote: > On Thu, 2016-11-24 at 15:40 +0100, Martin Blumenstingl wrote: >> Hi Jerome, >> >> On Mon, Nov 21, 2016 at 4:35 PM, Jerome Brunet >> wrote: >> > >> > This patchset fixes an issue with the OdroidC2

Re: [RFC PATCH net v2 0/3] Fix OdroidC2 Gigabit Tx link issue

On Thu, Nov 24, 2016 at 5:01 PM, Jerome Brunet wrote: > On Thu, 2016-11-24 at 15:40 +0100, Martin Blumenstingl wrote: >> Hi Jerome, >> >> On Mon, Nov 21, 2016 at 4:35 PM, Jerome Brunet >> wrote: >> > >> > This patchset fixes an issue with the OdroidC2 board (DWMAC + >> > RTL8211F). >> >

Re: [PATCH 2/6] KVM: x86: decouple irqchip_in_kernel() and pic_irqchip()

2016-11-24 11:55-0500, Paolo Bonzini: >> irqchip_in_kernel() tried to save a bit by reusing pic_irqchip(), but it >> just complicated the code. >> Add kvm->arch.irqchip_kvm that matches kvm->arch.irqchip_split. >> (Turning them into an exclusive type would be nicer.) > > Then do it. ;) It is

Re: [PATCH 2/6] KVM: x86: decouple irqchip_in_kernel() and pic_irqchip()

2016-11-24 11:55-0500, Paolo Bonzini: >> irqchip_in_kernel() tried to save a bit by reusing pic_irqchip(), but it >> just complicated the code. >> Add kvm->arch.irqchip_kvm that matches kvm->arch.irqchip_split. >> (Turning them into an exclusive type would be nicer.) > > Then do it. ;) It is

Re: [PATCH v2] i2c: i2c-mux-gpio: update mux with gpiod_set_array_value_cansleep

On 2016-11-24 16:14, Wolfram Sang wrote: > Hi Peter, > >> +int values[mux->data.n_gpios]; > > Hmm, my code checkers complain about this line: > > CHECK drivers/i2c/muxes/i2c-mux-gpio.c > SPARSE > drivers/i2c/muxes/i2c-mux-gpio.c:29:29: warning: Variable length array is > used. >

Re: [PATCH v2] i2c: i2c-mux-gpio: update mux with gpiod_set_array_value_cansleep

On 2016-11-24 16:14, Wolfram Sang wrote: > Hi Peter, > >> +int values[mux->data.n_gpios]; > > Hmm, my code checkers complain about this line: > > CHECK drivers/i2c/muxes/i2c-mux-gpio.c > SPARSE > drivers/i2c/muxes/i2c-mux-gpio.c:29:29: warning: Variable length array is > used. >

Re: What exactly do 32-bit x86 exceptions push on the stack in the CS slot?

On Mon, Nov 21, 2016 at 1:21 PM, Linus Torvalds wrote: > On Mon, Nov 21, 2016 at 10:26 AM, H. Peter Anvin wrote: >> On 11/21/16 10:00, Linus Torvalds wrote: >>> >>> I'd much rather we go back to just making the "cs" entry explicitly >>> 16-bit, and

Re: What exactly do 32-bit x86 exceptions push on the stack in the CS slot?

On Mon, Nov 21, 2016 at 1:21 PM, Linus Torvalds wrote: > On Mon, Nov 21, 2016 at 10:26 AM, H. Peter Anvin wrote: >> On 11/21/16 10:00, Linus Torvalds wrote: >>> >>> I'd much rather we go back to just making the "cs" entry explicitly >>> 16-bit, and have a separate padding entry, the way we used

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

From: Mark Lord Date: Thu, 24 Nov 2016 12:00:15 -0500 > It seems I am being overly helpful here. Either you want to cry or you want to keep helping us track down this problem. It is your choice, and your choice alone. Please do not pretend otherwise, everyone else in this

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

From: Mark Lord Date: Thu, 24 Nov 2016 12:00:15 -0500 > It seems I am being overly helpful here. Either you want to cry or you want to keep helping us track down this problem. It is your choice, and your choice alone. Please do not pretend otherwise, everyone else in this thread is operating

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

From: Mark Lord Date: Thu, 24 Nov 2016 11:43:53 -0500 > So even if this were a platform memory coherency issue, one should > still never see ASCII data at the beginning of an rx buffer. I'm not so convinced, since this is the kind of random corruption one would expect to see

FPU warning on x86_32 on Skylake

I gett this when booting a 32-bit 4.9-rc6-ish on Skylake: [0.564506] [ cut here ] [0.564994] WARNING: CPU: 0 PID: 1 at ./arch/x86/include/asm/fpu/internal.h:368 fpu__restore+0x203/0x210 [0.565737] Modules linked in: [0.566040] CPU: 0 PID: 1 Comm: sh Not

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

From: Mark Lord Date: Thu, 24 Nov 2016 11:43:53 -0500 > So even if this were a platform memory coherency issue, one should > still never see ASCII data at the beginning of an rx buffer. I'm not so convinced, since this is the kind of random corruption one would expect to see when dealing with

FPU warning on x86_32 on Skylake

I gett this when booting a 32-bit 4.9-rc6-ish on Skylake: [0.564506] [ cut here ] [0.564994] WARNING: CPU: 0 PID: 1 at ./arch/x86/include/asm/fpu/internal.h:368 fpu__restore+0x203/0x210 [0.565737] Modules linked in: [0.566040] CPU: 0 PID: 1 Comm: sh Not

Re: [dm-devel] [RFC PATCH 2/2] mm, mempool: do not throttle PF_LESS_THROTTLE tasks

On Thu, 24 Nov 2016, Michal Hocko wrote: > On Wed 23-11-16 16:11:59, Mikulas Patocka wrote: > [...] > > Hi Michal > > > > So, here Google developers hit a stacktrace where a block device driver is > > being throttled in the memory management: > > > >

Re: [dm-devel] [RFC PATCH 2/2] mm, mempool: do not throttle PF_LESS_THROTTLE tasks

On Thu, 24 Nov 2016, Michal Hocko wrote: > On Wed 23-11-16 16:11:59, Mikulas Patocka wrote: > [...] > > Hi Michal > > > > So, here Google developers hit a stacktrace where a block device driver is > > being throttled in the memory management: > > > >

Re: [PATCH] z3fold: use %z modifier for format string

On Thu, 2016-11-24 at 17:31 +0100, Arnd Bergmann wrote: > Printing a size_t requires the %zd format rather than %d: > > mm/z3fold.c: In function ‘init_z3fold’: > include/linux/kern_levels.h:4:18: error: format ‘%d’ expects argument of type > ‘int’, but argument 2 has type ‘long unsigned int’

Re: [PATCH] z3fold: use %z modifier for format string

On Thu, 2016-11-24 at 17:31 +0100, Arnd Bergmann wrote: > Printing a size_t requires the %zd format rather than %d: > > mm/z3fold.c: In function ‘init_z3fold’: > include/linux/kern_levels.h:4:18: error: format ‘%d’ expects argument of type > ‘int’, but argument 2 has type ‘long unsigned int’

Re: Enabling peer to peer device transactions for PCIe devices

On 2016-11-24 11:26 AM, Jason Gunthorpe wrote: On Thu, Nov 24, 2016 at 10:45:18AM +0100, Christian König wrote: Am 24.11.2016 um 00:25 schrieb Jason Gunthorpe: There is certainly nothing about the hardware that cares about ZONE_DEVICE vs System memory. Well that is clearly not so simple.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 11:43 AM, Mark Lord wrote: .. But how does this ASCII data end up at offset zero of the rx buffer?? Not possible -- this isn't even stale data, because only an rx_desc could be at that offset in that buffer. Answering my own question here, I suspect it ends up there as a result of

Re: Enabling peer to peer device transactions for PCIe devices

On 2016-11-24 11:26 AM, Jason Gunthorpe wrote: On Thu, Nov 24, 2016 at 10:45:18AM +0100, Christian König wrote: Am 24.11.2016 um 00:25 schrieb Jason Gunthorpe: There is certainly nothing about the hardware that cares about ZONE_DEVICE vs System memory. Well that is clearly not so simple.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 11:43 AM, Mark Lord wrote: .. But how does this ASCII data end up at offset zero of the rx buffer?? Not possible -- this isn't even stale data, because only an rx_desc could be at that offset in that buffer. Answering my own question here, I suspect it ends up there as a result of

Re: [PATCH 0/6] KVM: x86: minor irqchip improvements (API change)

- Original Message - > From: "Radim Krčmář" > To: linux-kernel@vger.kernel.org, k...@vger.kernel.org > Cc: "Paolo Bonzini" > Sent: Thursday, November 24, 2016 5:31:28 PM > Subject: [PATCH 0/6] KVM: x86: minor irqchip improvements (API change) >

Re: [PATCH 0/6] KVM: x86: minor irqchip improvements (API change)

- Original Message - > From: "Radim Krčmář" > To: linux-kernel@vger.kernel.org, k...@vger.kernel.org > Cc: "Paolo Bonzini" > Sent: Thursday, November 24, 2016 5:31:28 PM > Subject: [PATCH 0/6] KVM: x86: minor irqchip improvements (API change) > > There are two API changes: > 1) [1/6]

Re: [RFC][PATCHv4 3/6] printk: introduce per-cpu safe_print seq buffer

On Fri 2016-10-28 00:49:30, Sergey Senozhatsky wrote: > This patch extends the idea of NMI per-cpu buffers to regions > that may cause recursive printk() calls and possible deadlocks. > Namely, printk() can't handle printk calls from schedule code > or printk() calls from lock debugging code

Re: [RFC][PATCHv4 3/6] printk: introduce per-cpu safe_print seq buffer

On Fri 2016-10-28 00:49:30, Sergey Senozhatsky wrote: > This patch extends the idea of NMI per-cpu buffers to regions > that may cause recursive printk() calls and possible deadlocks. > Namely, printk() can't handle printk calls from schedule code > or printk() calls from lock debugging code

[PATCH v8] mtd: spi-nor: Add support for S3AN spi-nor devices

Xilinx Spartan-3AN FPGAs contain an In-System Flash where they keep their configuration data and (optionally) some user data. The protocol of this flash follows most of the spi-nor standard. With the following differences: - Page size might not be a power of two. - The address calculation

Re: [PATCH 2/6] KVM: x86: decouple irqchip_in_kernel() and pic_irqchip()

> irqchip_in_kernel() tried to save a bit by reusing pic_irqchip(), but it > just complicated the code. > Add kvm->arch.irqchip_kvm that matches kvm->arch.irqchip_split. > (Turning them into an exclusive type would be nicer.) Then do it. ;) Paolo > Signed-off-by: Radim Krčmář

[PATCH v8] mtd: spi-nor: Add support for S3AN spi-nor devices

Xilinx Spartan-3AN FPGAs contain an In-System Flash where they keep their configuration data and (optionally) some user data. The protocol of this flash follows most of the spi-nor standard. With the following differences: - Page size might not be a power of two. - The address calculation

Re: [PATCH 2/6] KVM: x86: decouple irqchip_in_kernel() and pic_irqchip()

> irqchip_in_kernel() tried to save a bit by reusing pic_irqchip(), but it > just complicated the code. > Add kvm->arch.irqchip_kvm that matches kvm->arch.irqchip_split. > (Turning them into an exclusive type would be nicer.) Then do it. ;) Paolo > Signed-off-by: Radim Krčmář > --- >

[PATCH v4 3/7] iio: inkern: api for manipulating ext_info of iio channels

Extend the inkern api with functions for reading and writing ext_info of iio channels. Signed-off-by: Peter Rosin --- drivers/iio/inkern.c | 60 include/linux/iio/consumer.h | 37 +++ 2 files changed,

[PATCH v4 6/7] dt-bindings: i2c: i2c-mux-simple: document i2c-mux-simple bindings

Signed-off-by: Peter Rosin --- .../devicetree/bindings/i2c/i2c-mux-simple.txt | 76 ++ 1 file changed, 76 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt diff --git

[PATCH v4 3/7] iio: inkern: api for manipulating ext_info of iio channels

Extend the inkern api with functions for reading and writing ext_info of iio channels. Signed-off-by: Peter Rosin --- drivers/iio/inkern.c | 60 include/linux/iio/consumer.h | 37 +++ 2 files changed, 97 insertions(+)

[PATCH v4 6/7] dt-bindings: i2c: i2c-mux-simple: document i2c-mux-simple bindings

Signed-off-by: Peter Rosin --- .../devicetree/bindings/i2c/i2c-mux-simple.txt | 76 ++ 1 file changed, 76 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt

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