[PATCH 07/14] mwifiex: fixup init_channel_scan_gap error case

In reading through _mwifiex_fw_dpc(), I noticed that after we've registered our wiphy, we still have error paths that don't free it back up. Let's do that. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/main.c | 3 ++- 1 file changed, 2

[PATCH 05/14] mwifiex: re-register wiphy across reset

In general, it's helpful to use the same code for device removal as for device reset, as this tends to have fewer bugs. Let's move the wiphy unregistration code into the common reset and removal code. In particular, it's very hard to properly handle the reset sequence when something fails.

[PATCH 05/14] mwifiex: re-register wiphy across reset

In general, it's helpful to use the same code for device removal as for device reset, as this tends to have fewer bugs. Let's move the wiphy unregistration code into the common reset and removal code. In particular, it's very hard to properly handle the reset sequence when something fails.

[PATCH 07/14] mwifiex: fixup init_channel_scan_gap error case

In reading through _mwifiex_fw_dpc(), I noticed that after we've registered our wiphy, we still have error paths that don't free it back up. Let's do that. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

[PATCH 11/14] mwifiex: utilize netif_tx_{wake,stop}_all_queues()

We're open-coding these. Just use the helpers. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/init.c | 20 ++-- 1 file changed, 2 insertions(+), 18 deletions(-) diff --git a/drivers/net/wireless/marvell/mwifiex/init.c

[PATCH 03/14] mwifiex: reset interrupt status across device reset

When resetting the device, we might have queued up interrupts that didn't get a chance to finish processing. We really don't need to handle them at this point; we just want to make sure they don't cause us to try to process old commands from before the device was reset. Signed-off-by: Brian

[PATCH 11/14] mwifiex: utilize netif_tx_{wake,stop}_all_queues()

We're open-coding these. Just use the helpers. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/init.c | 20 ++-- 1 file changed, 2 insertions(+), 18 deletions(-) diff --git a/drivers/net/wireless/marvell/mwifiex/init.c

[PATCH 03/14] mwifiex: reset interrupt status across device reset

When resetting the device, we might have queued up interrupts that didn't get a chance to finish processing. We really don't need to handle them at this point; we just want to make sure they don't cause us to try to process old commands from before the device was reset. Signed-off-by: Brian

[PATCH 01/14] mwifiex: pcie: properly synchronize, disable interrupts in driver callbacks

It seems that the implicit assumption of the mwifiex {enable,disable}_int() callbacks is that after ->disable_int(), all interrupt handling should be complete (synchronized) and not fire again until after ->enable_int(). Also, interrupts should not be serviced until after the first ->enable_int().

[PATCH 01/14] mwifiex: pcie: properly synchronize, disable interrupts in driver callbacks

It seems that the implicit assumption of the mwifiex {enable,disable}_int() callbacks is that after ->disable_int(), all interrupt handling should be complete (synchronized) and not fire again until after ->enable_int(). Also, interrupts should not be serviced until after the first ->enable_int().

[PATCH 10/14] mwifiex: pcie: stop masking interrupts in FW downloader

The upper layers already have disabled our interrupts (haven't called ->enable_int() yet for probe(), and we call ->disable_int() before trying to reset), so this is redundant. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/pcie.c | 6 -- 1

[PATCH 10/14] mwifiex: pcie: stop masking interrupts in FW downloader

The upper layers already have disabled our interrupts (haven't called ->enable_int() yet for probe(), and we call ->disable_int() before trying to reset), so this is redundant. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/pcie.c | 6 -- 1 file changed, 6 deletions(-)

[PATCH 06/14] mwifiex: don't short-circuit netdev notifiers on interface deletion

When we leave the delete interface function, there are still netdev hooks that might try to process the device. We're short-circuiting some of that by changing the interface type and clearing ieee80211_ptr. This means we skip NETDEV_UNREGISTER_FINAL in cfg80211. Fortunately, that is currently a

[PATCH 06/14] mwifiex: don't short-circuit netdev notifiers on interface deletion

When we leave the delete interface function, there are still netdev hooks that might try to process the device. We're short-circuiting some of that by changing the interface type and clearing ieee80211_ptr. This means we skip NETDEV_UNREGISTER_FINAL in cfg80211. Fortunately, that is currently a

[PATCH 12/14] mwifiex: don't open-code ARRAY_SIZE()

Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/cfp.c | 4 +--- drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 8 ++-- drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 5 ++--- 3 files changed, 5 insertions(+), 12 deletions(-)

[PATCH 13/14] mwifiex: drop 'add_tail' param from mwifiex_insert_cmd_to_pending_q()

It's always called with 'true' -- we only determine it 'false' locally within this function. So drop the parameter. Also, this should be 'bool' (since we use true/false), not 'u32'. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/cmdevt.c | 5

[PATCH 12/14] mwifiex: don't open-code ARRAY_SIZE()

Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/cfp.c | 4 +--- drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 8 ++-- drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 5 ++--- 3 files changed, 5 insertions(+), 12 deletions(-) diff --git

[PATCH 13/14] mwifiex: drop 'add_tail' param from mwifiex_insert_cmd_to_pending_q()

It's always called with 'true' -- we only determine it 'false' locally within this function. So drop the parameter. Also, this should be 'bool' (since we use true/false), not 'u32'. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/cmdevt.c | 5 +++--

[PATCH 14/14] mwifiex: pcie: fix whitespace

This keeps annoying me. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/pcie.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c index

[PATCH 08/14] mwifiex: ensure "disable auto DS" struct is initialized

The .idle_time field *should* be unused, but technically, we're allowing unitialized stack garbage to pass all the way through to the firmware host command. Let's zero it out instead. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 6

[PATCH 14/14] mwifiex: pcie: fix whitespace

This keeps annoying me. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/pcie.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c index c86119b05f52..4f1d946ea460

[PATCH 08/14] mwifiex: ensure "disable auto DS" struct is initialized

The .idle_time field *should* be unused, but technically, we're allowing unitialized stack garbage to pass all the way through to the firmware host command. Let's zero it out instead. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 6 +++--- 1 file changed, 3

[PATCH 09/14] mwifiex: pcie: remove redundant synchronize_irq()

free_irq() already calls synchronize_irq() in a non-racy manner. Calling synchronize_irq() here is redundant. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/pcie.c | 3 --- 1 file changed, 3 deletions(-) diff --git

[PATCH 09/14] mwifiex: pcie: remove redundant synchronize_irq()

free_irq() already calls synchronize_irq() in a non-racy manner. Calling synchronize_irq() here is redundant. Signed-off-by: Brian Norris --- drivers/net/wireless/marvell/mwifiex/pcie.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c

[PATCH 02/14] mwifiex: reunite copy-and-pasted remove/reset code

When PCIe FLR code was added, it explicitly copy-and-pasted much of mwifiex_remove_card() into mwifiex_shutdown_sw(). This is unnecessary, as almost all of the code should be reused. Let's reunite what we can for now. The only functional changes for now: * call netif_device_detach() in the

[PATCH 02/14] mwifiex: reunite copy-and-pasted remove/reset code

When PCIe FLR code was added, it explicitly copy-and-pasted much of mwifiex_remove_card() into mwifiex_shutdown_sw(). This is unnecessary, as almost all of the code should be reused. Let's reunite what we can for now. The only functional changes for now: * call netif_device_detach() in the

Re: [PATCH V2] workqueue: Implement delayed_work_busy()

Hi Alex, [auto build test WARNING on next-20170522] [also build test WARNING on v4.12-rc2] [cannot apply to v4.9-rc8 v4.9-rc7 v4.9-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH 04/14] mwifiex: pcie: don't allow cmd buffer reuse after reset

In rogue cases (due to other bugs) it's possible we try to process an old command response *after* resetting the device. This could trigger a double-free (or the SKB can get reallocated elsewhere...causing other memory corruptions) in mwifiex_pcie_process_cmd_complete(). For safety (and symmetry)

Re: [PATCH V2] workqueue: Implement delayed_work_busy()

Hi Alex, [auto build test WARNING on next-20170522] [also build test WARNING on v4.12-rc2] [cannot apply to v4.9-rc8 v4.9-rc7 v4.9-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH 04/14] mwifiex: pcie: don't allow cmd buffer reuse after reset

In rogue cases (due to other bugs) it's possible we try to process an old command response *after* resetting the device. This could trigger a double-free (or the SKB can get reallocated elsewhere...causing other memory corruptions) in mwifiex_pcie_process_cmd_complete(). For safety (and symmetry)

Re: [tpmdd-devel] [PATCH v6 3/3] tpm: vtpm_proxy: Prevent userspace from sending driver command

On Wed, May 24, 2017 at 03:22:11PM -0700, Jarkko Sakkinen wrote: > On Wed, May 24, 2017 at 05:39:41PM -0400, Stefan Berger wrote: > > To prevent userspace from sending the TPM driver command to set > > the locality, we need to check every command that is sent from > > user space. To distinguish

Re: [tpmdd-devel] [PATCH v6 3/3] tpm: vtpm_proxy: Prevent userspace from sending driver command

On Wed, May 24, 2017 at 03:22:11PM -0700, Jarkko Sakkinen wrote: > On Wed, May 24, 2017 at 05:39:41PM -0400, Stefan Berger wrote: > > To prevent userspace from sending the TPM driver command to set > > the locality, we need to check every command that is sent from > > user space. To distinguish

Re: [PATCH v6 2/3] tpm: vtpm_proxy: Implement request_locality function.

On Wed, May 24, 2017 at 07:03:27PM -0400, Stefan Berger wrote: > On 05/24/2017 06:21 PM, Jarkko Sakkinen wrote: > > On Wed, May 24, 2017 at 05:39:40PM -0400, Stefan Berger wrote: > > > Implement the request_locality function. To set the locality on the > > > backend we define vendor-specific TPM

Re: [PATCH v6 2/3] tpm: vtpm_proxy: Implement request_locality function.

On Wed, May 24, 2017 at 07:03:27PM -0400, Stefan Berger wrote: > On 05/24/2017 06:21 PM, Jarkko Sakkinen wrote: > > On Wed, May 24, 2017 at 05:39:40PM -0400, Stefan Berger wrote: > > > Implement the request_locality function. To set the locality on the > > > backend we define vendor-specific TPM

Re: [PATCH 7/8] firmware: vpd: remove platform driver

I'm not a kernel expert so maybe I don't understand this right, but... I think this might have been done this way to ensure that the driver can get initialized correctly regardless of probe ordering. coreboot_table_find() may fail with -EPROBE_DEFER if the coreboot_table driver and its dependent

Re: [PATCH 7/8] firmware: vpd: remove platform driver

I'm not a kernel expert so maybe I don't understand this right, but... I think this might have been done this way to ensure that the driver can get initialized correctly regardless of probe ordering. coreboot_table_find() may fail with -EPROBE_DEFER if the coreboot_table driver and its dependent

[PATCH v4 5/7] arch/sparc: Enable queued rwlocks for SPARC

Enable queued rwlocks for SPARC. Here are the discussions on this feature when this was introduced. https://lwn.net/Articles/572765/ https://lwn.net/Articles/582200/ Cleaned-up the arch_read_xxx and arch_write_xxx definitions in spinlock_64.h. These routines are replaced by the functions in

[PATCH v4 5/7] arch/sparc: Enable queued rwlocks for SPARC

Enable queued rwlocks for SPARC. Here are the discussions on this feature when this was introduced. https://lwn.net/Articles/572765/ https://lwn.net/Articles/582200/ Cleaned-up the arch_read_xxx and arch_write_xxx definitions in spinlock_64.h. These routines are replaced by the functions in

[PATCH v4 7/7] arch/sparc: Enable queued spinlock support for SPARC

This patch makes the necessary changes in SPARC architecture to enable queued spinlock support. Here are some of the earlier discussions about this feature. https://lwn.net/Articles/561775/ https://lwn.net/Articles/590243/ Cleaned-up the spinlock_64.h. The definitions of arch_spin_xxx are

[PATCH v4 7/7] arch/sparc: Enable queued spinlock support for SPARC

This patch makes the necessary changes in SPARC architecture to enable queued spinlock support. Here are some of the earlier discussions about this feature. https://lwn.net/Articles/561775/ https://lwn.net/Articles/590243/ Cleaned-up the spinlock_64.h. The definitions of arch_spin_xxx are

[PATCH v4 0/7] Enable queued rwlock and queued spinlock for SPARC

This series of patches enables queued rwlock and queued spinlock support for SPARC. These features were introduced some time ago in upstream. Here are some of the earlier discussions. https://lwn.net/Articles/572765/ https://lwn.net/Articles/582200/ https://lwn.net/Articles/561775/

[PATCH v4 0/7] Enable queued rwlock and queued spinlock for SPARC

This series of patches enables queued rwlock and queued spinlock support for SPARC. These features were introduced some time ago in upstream. Here are some of the earlier discussions. https://lwn.net/Articles/572765/ https://lwn.net/Articles/582200/ https://lwn.net/Articles/561775/

[PATCH v4 3/7] arch/sparc: Define config parameter CPU_BIG_ENDIAN

Found this problem while enabling queued rwlock on SPARC. The parameter CONFIG_CPU_BIG_ENDIAN is used to clear the specific byte in qrwlock structure. Without this parameter, we clear the wrong byte. Here is the code. static inline u8 *__qrwlock_write_byte(struct qrwlock *lock) { return

[PATCH v4 3/7] arch/sparc: Define config parameter CPU_BIG_ENDIAN

Found this problem while enabling queued rwlock on SPARC. The parameter CONFIG_CPU_BIG_ENDIAN is used to clear the specific byte in qrwlock structure. Without this parameter, we clear the wrong byte. Here is the code. static inline u8 *__qrwlock_write_byte(struct qrwlock *lock) { return

[PATCH v4 2/7] kernel/locking: Fix compile error with qrwlock.c

Saw these compile errors on SPARC when queued rwlock feature is enabled. CC kernel/locking/qrwlock.o kernel/locking/qrwlock.c: In function ‘queued_read_lock_slowpath’: kernel/locking/qrwlock.c:89: error: implicit declaration of function ‘arch_spin_lock’ kernel/locking/qrwlock.c:102: error:

[PATCH v4 2/7] kernel/locking: Fix compile error with qrwlock.c

Saw these compile errors on SPARC when queued rwlock feature is enabled. CC kernel/locking/qrwlock.o kernel/locking/qrwlock.c: In function ‘queued_read_lock_slowpath’: kernel/locking/qrwlock.c:89: error: implicit declaration of function ‘arch_spin_lock’ kernel/locking/qrwlock.c:102: error:

[PATCH v4 6/7] arch/sparc: Introduce xchg16 for SPARC

SPARC supports 32 bit and 64 bit xchg right now. Add the support for 16 bit (2 byte) xchg. This is required to support queued spinlock feature which uses 2 byte xchg. This is achieved using 4 byte cas instructions with byte manipulations. Also re-arranged the code to call __cmpxchg_u32 inside

[PATCH v4 6/7] arch/sparc: Introduce xchg16 for SPARC

SPARC supports 32 bit and 64 bit xchg right now. Add the support for 16 bit (2 byte) xchg. This is required to support queued spinlock feature which uses 2 byte xchg. This is achieved using 4 byte cas instructions with byte manipulations. Also re-arranged the code to call __cmpxchg_u32 inside

[PATCH v4 1/7] arch/sparc: Remove the check #ifndef __LINUX_SPINLOCK_TYPES_H

Saw these compile errors on SPARC when queued rwlock feature is enabled. CC kernel/locking/qrwlock.o In file included from ./include/asm-generic/qrwlock_types.h:5, from ./arch/sparc/include/asm/qrwlock.h:4, from kernel/locking/qrwlock.c:24:

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

On 05/24/2017 06:19 AM, Michael Ellerman wrote: > Michael Bringmann writes: > >> On 05/23/2017 04:49 PM, Reza Arbab wrote: >>> On Tue, May 23, 2017 at 03:05:08PM -0500, Michael Bringmann wrote: On 05/23/2017 10:52 AM, Reza Arbab wrote: > On Tue, May 23, 2017

[PATCH v4 1/7] arch/sparc: Remove the check #ifndef __LINUX_SPINLOCK_TYPES_H

Saw these compile errors on SPARC when queued rwlock feature is enabled. CC kernel/locking/qrwlock.o In file included from ./include/asm-generic/qrwlock_types.h:5, from ./arch/sparc/include/asm/qrwlock.h:4, from kernel/locking/qrwlock.c:24:

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

On 05/24/2017 06:19 AM, Michael Ellerman wrote: > Michael Bringmann writes: > >> On 05/23/2017 04:49 PM, Reza Arbab wrote: >>> On Tue, May 23, 2017 at 03:05:08PM -0500, Michael Bringmann wrote: On 05/23/2017 10:52 AM, Reza Arbab wrote: > On Tue, May 23, 2017 at 10:15:44AM -0500,

[PATCH v4 4/7] arch/sparc: Introduce cmpxchg_u8 SPARC

SPARC supports 32 bit and 64 bit cmpxchg right now. Add support for 8 bit (1 byte) cmpxchg. This is required to support queued rwlocks feature which uses 1 byte cmpxchg. The function __cmpxchg_u8 here uses the 4 byte cas instruction with a byte manipulation to achieve 1 byte cmpxchg.

[PATCH v4 4/7] arch/sparc: Introduce cmpxchg_u8 SPARC

SPARC supports 32 bit and 64 bit cmpxchg right now. Add support for 8 bit (1 byte) cmpxchg. This is required to support queued rwlocks feature which uses 1 byte cmpxchg. The function __cmpxchg_u8 here uses the 4 byte cas instruction with a byte manipulation to achieve 1 byte cmpxchg.

Re: [PATCH v2] bug: fix problem including from linux/kernel.h

Hi Ian, [auto build test ERROR on linus/master] [also build test ERROR on v4.12-rc2 next-20170524] [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/Ian-Abbott/bug-fix-problem-including-linux-bug

Re: [PATCH v2] bug: fix problem including from linux/kernel.h

Hi Ian, [auto build test ERROR on linus/master] [also build test ERROR on v4.12-rc2 next-20170524] [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/Ian-Abbott/bug-fix-problem-including-linux-bug

Re: [PATCH] test_bpf: Add a couple of tests for BPF_JSGE.

On 05/25/2017 01:35 AM, David Daney wrote: Some JITs can optimize comparisons with zero. Add a couple of BPF_JSGE tests against immediate zero. Signed-off-by: David Daney Thanks for the tests! Acked-by: Daniel Borkmann

Re: [PATCH] test_bpf: Add a couple of tests for BPF_JSGE.

On 05/25/2017 01:35 AM, David Daney wrote: Some JITs can optimize comparisons with zero. Add a couple of BPF_JSGE tests against immediate zero. Signed-off-by: David Daney Thanks for the tests! Acked-by: Daniel Borkmann

[GIT PULL] SCSI fixes for 4.12-rc2

This is quite a big update because it includes a rework of the lpfc driver to separate the NVMe part from the FC part. The reason for doing this is because two separate trees (the nvme and scsi trees respectively) want to update the individual components and this separation will prevent a really

[GIT PULL] SCSI fixes for 4.12-rc2

This is quite a big update because it includes a rework of the lpfc driver to separate the NVMe part from the FC part. The reason for doing this is because two separate trees (the nvme and scsi trees respectively) want to update the individual components and this separation will prevent a really

[PATCH v4 3/5] mtd: handle partitioning on devices with 0 erasesize

erasesize is meaningful for flash devices but for SRAM there is no concept of an erase block so erasesize is set to 0. When partitioning these devices instead of ensuring partitions fall on erasesize boundaries we ensure they fall on writesize boundaries. Helped-by: Boris Brezillon

[PATCH v4 3/5] mtd: handle partitioning on devices with 0 erasesize

erasesize is meaningful for flash devices but for SRAM there is no concept of an erase block so erasesize is set to 0. When partitioning these devices instead of ensuring partitions fall on erasesize boundaries we ensure they fall on writesize boundaries. Helped-by: Boris Brezillon

[PATCH v4 5/5] mtd: mchp23k256: Add support for mchp23lcv1024

The mchp23lcv1024 is similar to the mchp23k256, the differences (from a software point of view) are the capacity of the chip and the size of the addresses used. There is no way to detect the specific chip so we must be told via a Device Tree or default to mchp23k256 when device tree is not used.

[PATCH v4 4/5] mtd: mchp23k256: add partitioning support

Setting the of_node for the mtd device allows the generic mtd code to setup the partitions. Additionally we must specify a non-zero erasesize for the partitions to be writeable. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by:

[PATCH v4 5/5] mtd: mchp23k256: Add support for mchp23lcv1024

The mchp23lcv1024 is similar to the mchp23k256, the differences (from a software point of view) are the capacity of the chip and the size of the addresses used. There is no way to detect the specific chip so we must be told via a Device Tree or default to mchp23k256 when device tree is not used.

[PATCH v4 4/5] mtd: mchp23k256: add partitioning support

Setting the of_node for the mtd device allows the generic mtd code to setup the partitions. Additionally we must specify a non-zero erasesize for the partitions to be writeable. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn --- Changes in v2 - collect revew/test

[PATCH v4 2/5] mtd: mchp23k256: switch to mtd_device_register()

Use mtd_device_register() instead of mtd_device_parse_register() to eliminate two unused parameters. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn --- Changes in v2 - collect review/test from

[PATCH v4 2/5] mtd: mchp23k256: switch to mtd_device_register()

Use mtd_device_register() instead of mtd_device_parse_register() to eliminate two unused parameters. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn --- Changes in v2 - collect review/test from Andrew Changes in v3: - None Changes in v4: - None

[PATCH v4 0/5] mtd: mchp23k256: device tree and mchp23lcv1024

This series adds device tree support to the mchp23k256 driver and support for the mchp23lcv1024 chip. I suspect there are more compatible variants that we could now enumerate if desired. Chris Packham (5): mtd: mchp23k256: Add OF device ID table mtd: mchp23k256: switch to

[PATCH v4 1/5] mtd: mchp23k256: Add OF device ID table

This allows registering of this device via a Device Tree. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn --- Changes in v2: - collect review/test from Andrew Changes in v3: - None Changes in v4: -

[PATCH v4 0/5] mtd: mchp23k256: device tree and mchp23lcv1024

This series adds device tree support to the mchp23k256 driver and support for the mchp23lcv1024 chip. I suspect there are more compatible variants that we could now enumerate if desired. Chris Packham (5): mtd: mchp23k256: Add OF device ID table mtd: mchp23k256: switch to

[PATCH v4 1/5] mtd: mchp23k256: Add OF device ID table

This allows registering of this device via a Device Tree. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn --- Changes in v2: - collect review/test from Andrew Changes in v3: - None Changes in v4: - None .../devicetree/bindings/mtd/microchip,mchp23k256.txt | 18

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

I will get a log based on the latest 4.12 kernel to show what happens one way or the other, with this patch removed. On 05/24/2017 09:36 AM, Reza Arbab wrote: > On Tue, May 23, 2017 at 05:44:23PM -0500, Michael Bringmann wrote: >> On 05/23/2017 04:49 PM, Reza Arbab wrote: >>> On Tue, May 23, 2017

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

I will get a log based on the latest 4.12 kernel to show what happens one way or the other, with this patch removed. On 05/24/2017 09:36 AM, Reza Arbab wrote: > On Tue, May 23, 2017 at 05:44:23PM -0500, Michael Bringmann wrote: >> On 05/23/2017 04:49 PM, Reza Arbab wrote: >>> On Tue, May 23, 2017

Re: [PATCH v2 for-4.12-fixes 1/2] sched/fair: Use task_groups instead of leaf_cfs_rq_list to walk all cfs_rqs

On 05/09/2017 09:17 AM, Tejun Heo wrote: Currently, rq->leaf_cfs_rq_list is a traversal ordered list of all live cfs_rqs which have ever been active on the CPU; unfortunately, this makes update_blocked_averages() O(total number of CPU cgroups) which isn't scalable at all. The next patch will

Re: [PATCH v2 for-4.12-fixes 1/2] sched/fair: Use task_groups instead of leaf_cfs_rq_list to walk all cfs_rqs

On 05/09/2017 09:17 AM, Tejun Heo wrote: Currently, rq->leaf_cfs_rq_list is a traversal ordered list of all live cfs_rqs which have ever been active on the CPU; unfortunately, this makes update_blocked_averages() O(total number of CPU cgroups) which isn't scalable at all. The next patch will

Re: [PATCH] workqueue: Ensure that cpumask set for pools created after boot

On 05/23/2017 03:10 PM, Tejun Heo wrote: > Hello, > > On Tue, May 23, 2017 at 03:09:07PM -0500, Michael Bringmann wrote: >> To confirm, you want the WARN_ON(cpumask_any(pool->attrs->cpumask) >= >> NR_CPUS) >> at the point where I place my current patch? > > Yeah, cpumask_weight() probably is a

Re: [PATCH] workqueue: Ensure that cpumask set for pools created after boot

On 05/23/2017 03:10 PM, Tejun Heo wrote: > Hello, > > On Tue, May 23, 2017 at 03:09:07PM -0500, Michael Bringmann wrote: >> To confirm, you want the WARN_ON(cpumask_any(pool->attrs->cpumask) >= >> NR_CPUS) >> at the point where I place my current patch? > > Yeah, cpumask_weight() probably is a

[PATCH] test_bpf: Add a couple of tests for BPF_JSGE.

Some JITs can optimize comparisons with zero. Add a couple of BPF_JSGE tests against immediate zero. Signed-off-by: David Daney --- lib/test_bpf.c | 38 ++ 1 file changed, 38 insertions(+) diff --git a/lib/test_bpf.c b/lib/test_bpf.c

[PATCH] test_bpf: Add a couple of tests for BPF_JSGE.

Some JITs can optimize comparisons with zero. Add a couple of BPF_JSGE tests against immediate zero. Signed-off-by: David Daney --- lib/test_bpf.c | 38 ++ 1 file changed, 38 insertions(+) diff --git a/lib/test_bpf.c b/lib/test_bpf.c index 889bc31..be88cba

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

Hi Mark Cc: DRM maintainer > > ALSA SoC needs to know connected DAI ID for probing. > > It is not a big problem if device/driver was only for sound, > > but getting DAI ID will be difficult if device includes both > > Video/Sound, like HDMI. > > As far as I understand what's going on with the

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

Hi Mark Cc: DRM maintainer > > ALSA SoC needs to know connected DAI ID for probing. > > It is not a big problem if device/driver was only for sound, > > but getting DAI ID will be difficult if device includes both > > Video/Sound, like HDMI. > > As far as I understand what's going on with the

linux-next: manual merge of the net-next tree with the net tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/phy/marvell.c between commit: f2899788353c ("net: phy: marvell: Limit errata to 88m1101") from the net tree and commit: 0c3439bc7773 ("net: phy: Marvell: checkpatch - Comments") from the net-next

linux-next: manual merge of the net-next tree with the net tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/phy/marvell.c between commit: f2899788353c ("net: phy: marvell: Limit errata to 88m1101") from the net tree and commit: 0c3439bc7773 ("net: phy: Marvell: checkpatch - Comments") from the net-next

Re: [patch] compiler, clang: suppress warning for unused static inline functions

Hi, On Wed, May 24, 2017 at 2:32 PM, Andrew Morton wrote: > On Wed, 24 May 2017 14:22:29 -0700 Matthias Kaehlcke > wrote: > >> I'm not a kernel maintainer, so it's not my decision whether this >> warning should be silenced, my personal opinion is

Re: [patch] compiler, clang: suppress warning for unused static inline functions

Hi, On Wed, May 24, 2017 at 2:32 PM, Andrew Morton wrote: > On Wed, 24 May 2017 14:22:29 -0700 Matthias Kaehlcke > wrote: > >> I'm not a kernel maintainer, so it's not my decision whether this >> warning should be silenced, my personal opinion is that it's benfits >> outweigh the

Re: [PATCH] Staging: bcm2835-audio: bcm2835-ctl.c: Fixed a comment coding style issue.

On Wed, May 24, 2017 at 08:03:14PM +0530, srishti sharma wrote: This driver is not in Greg KH's staging tree. You may like to work off of that tree when doing staging patches. https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ To aid you future patches here are a couple of

Re: [PATCH] Staging: bcm2835-audio: bcm2835-ctl.c: Fixed a comment coding style issue.

On Wed, May 24, 2017 at 08:03:14PM +0530, srishti sharma wrote: This driver is not in Greg KH's staging tree. You may like to work off of that tree when doing staging patches. https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ To aid you future patches here are a couple of

Re: [PATCH v2] bug: fix problem including from linux/kernel.h

Hi Ian, [auto build test WARNING on linus/master] [also build test WARNING on v4.12-rc2 next-20170524] [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/Ian-Abbott/bug-fix-problem-including-linux

Re: [PATCH v2] bug: fix problem including from linux/kernel.h

Hi Ian, [auto build test WARNING on linus/master] [also build test WARNING on v4.12-rc2 next-20170524] [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/Ian-Abbott/bug-fix-problem-including-linux

[PATCH] staging: iio: light: Replace snprintf calls with scnprintf

This patch fixes the miscoded use of return value of snprintf by using the scnprintf function which returns the length of actual string created in the buffer. Signed-off-by: Harinath Nampally --- drivers/staging/iio/light/tsl2x7x.c | 20 ++-- 1 file

[PATCH] staging: iio: light: Replace snprintf calls with scnprintf

This patch fixes the miscoded use of return value of snprintf by using the scnprintf function which returns the length of actual string created in the buffer. Signed-off-by: Harinath Nampally --- drivers/staging/iio/light/tsl2x7x.c | 20 ++-- 1 file changed, 10 insertions(+), 10

Re: [PATCH] x86/ftrace: Make sure that ftrace trampolines are not RWX

eeds > to become rw before freeing again. > > I applied this patch, and it appears to fix the bug for me. > > Signed-off-by: Steven Rostedt (VMware) <rost...@goodmis.org> Awesome, this also cures my panic: mcgrof@piggy ~/linux-next (git::20170524-fixwarn)$ sudo tools/testing

Re: [PATCH] x86/ftrace: Make sure that ftrace trampolines are not RWX

re freeing again. > > I applied this patch, and it appears to fix the bug for me. > > Signed-off-by: Steven Rostedt (VMware) Awesome, this also cures my panic: mcgrof@piggy ~/linux-next (git::20170524-fixwarn)$ sudo tools/testing/selftests/ftrace/ftracetest ... # of passed: 45 # of failed: 0 # of unresolved: 0 # of untested: 0 # of unsupported: 0 # of xfailed: 0 # of undefined(test bug): 0 So the combination of both: Tested-by: Luis R. Rodriguez Luis

[PATCH] MAINTAINERS: give proc sysctl some maintainer love

We poke at proc sysctl enough that really we should declare it maintained. We'll just be Cc'd and sending updates / ACK'ing changes through akpm's tree. Acked-by: Kees Cook Signed-off-by: Luis R. Rodriguez --- MAINTAINERS | 11 +++ 1 file

[PATCH] MAINTAINERS: give proc sysctl some maintainer love

We poke at proc sysctl enough that really we should declare it maintained. We'll just be Cc'd and sending updates / ACK'ing changes through akpm's tree. Acked-by: Kees Cook Signed-off-by: Luis R. Rodriguez --- MAINTAINERS | 11 +++ 1 file changed, 11 insertions(+) diff --git

Re: [PATCH v2] bug: fix problem including from linux/kernel.h

On 2017-05-24 17:06, Ian Abbott wrote: If "include/linux/kernel.h" includes , a circular dependency is introduced when "include/asm-generic/bug.h" includes . This results in build breakage when something includes before for architectures that select `CONFIG_GENERIC_BUG` because `struct

Re: [PATCH v2] bug: fix problem including from linux/kernel.h

On 2017-05-24 17:06, Ian Abbott wrote: If "include/linux/kernel.h" includes , a circular dependency is introduced when "include/asm-generic/bug.h" includes . This results in build breakage when something includes before for architectures that select `CONFIG_GENERIC_BUG` because `struct

Re: [PATCH v6 2/3] tpm: vtpm_proxy: Implement request_locality function.

On 05/24/2017 06:21 PM, Jarkko Sakkinen wrote: On Wed, May 24, 2017 at 05:39:40PM -0400, Stefan Berger wrote: Implement the request_locality function. To set the locality on the backend we define vendor-specific TPM 1.2 and TPM 2 ordinals and send a command to the backend to set the locality

Re: [PATCH v6 2/3] tpm: vtpm_proxy: Implement request_locality function.

On 05/24/2017 06:21 PM, Jarkko Sakkinen wrote: On Wed, May 24, 2017 at 05:39:40PM -0400, Stefan Berger wrote: Implement the request_locality function. To set the locality on the backend we define vendor-specific TPM 1.2 and TPM 2 ordinals and send a command to the backend to set the locality

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