Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

On Fri, 2017-07-28 at 08:25 -0600, Jens Axboe wrote: > On 07/28/2017 12:19 AM, Michael Ellerman wrote: > > OK, so the resolution is "fix it in IPR" ? > > I'll leave that to the SCSI crew. But at least one bug is in IPR, if you > look at the call trace: > > - timer function triggers, runs

Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

On Fri, 2017-07-28 at 08:25 -0600, Jens Axboe wrote: > On 07/28/2017 12:19 AM, Michael Ellerman wrote: > > OK, so the resolution is "fix it in IPR" ? > > I'll leave that to the SCSI crew. But at least one bug is in IPR, if you > look at the call trace: > > - timer function triggers, runs

[PATCH net-next 4/4] net: dsa: lan9303: MDIO access phy registers directly

Indirect access (PMI) to phy register only work in I2C mode. In MDIO mode phy registers must be accessed directly. Introduced struct lan9303_phy_ops to handle the two modes. Signed-off-by: Egil Hjelmeland --- drivers/net/dsa/lan9303-core.c | 20 +---

[PATCH net-next 4/4] net: dsa: lan9303: MDIO access phy registers directly

Indirect access (PMI) to phy register only work in I2C mode. In MDIO mode phy registers must be accessed directly. Introduced struct lan9303_phy_ops to handle the two modes. Signed-off-by: Egil Hjelmeland --- drivers/net/dsa/lan9303-core.c | 20 +--- drivers/net/dsa/lan9303.h

[PATCH net-next 3/4] net: dsa: lan9303: Renamed indirect phy access functions

Preparing for the following fix of MDIO phy access: Renamed functions that access PHY 1 and 2 indirectly through PMI registers. lan9303_port_phy_reg_wait_for_completion() to lan9303_indirect_phy_wait_for_completion() lan9303_port_phy_reg_read() to lan9303_indirect_phy_read()

[PATCH net-next 3/4] net: dsa: lan9303: Renamed indirect phy access functions

Preparing for the following fix of MDIO phy access: Renamed functions that access PHY 1 and 2 indirectly through PMI registers. lan9303_port_phy_reg_wait_for_completion() to lan9303_indirect_phy_wait_for_completion() lan9303_port_phy_reg_read() to lan9303_indirect_phy_read()

Re: [PATCH] xen: avoid deadlock in xenbus

On 07/28/2017 10:53 AM, Juergen Gross wrote: > When starting the xenwatch thread a theoretical deadlock situation is > possible: > > xs_init() contains: > > task = kthread_run(xenwatch_thread, NULL, "xenwatch"); > if (IS_ERR(task)) > return PTR_ERR(task); > xenwatch_pid =

Re: [PATCH] xen: avoid deadlock in xenbus

On 07/28/2017 10:53 AM, Juergen Gross wrote: > When starting the xenwatch thread a theoretical deadlock situation is > possible: > > xs_init() contains: > > task = kthread_run(xenwatch_thread, NULL, "xenwatch"); > if (IS_ERR(task)) > return PTR_ERR(task); > xenwatch_pid =

[PATCH net-next 1/4] net: dsa: lan9303: Fix lan9303_detect_phy_setup() for MDIO

Handle that MDIO read with no response return 0x. Signed-off-by: Egil Hjelmeland --- drivers/net/dsa/lan9303-core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c index

[PATCH net-next 1/4] net: dsa: lan9303: Fix lan9303_detect_phy_setup() for MDIO

Handle that MDIO read with no response return 0x. Signed-off-by: Egil Hjelmeland --- drivers/net/dsa/lan9303-core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c index cd76e61f1fca..9d0ab77edb4a 100644

[PATCH net-next 0/4] net: dsa: lan9303: Fix MDIO issues.

This series fix the MDIO interface for the lan9303 DSA driver. Bugs found after testing on actual HW. This series is extracted from the first patch of my first large series. Significant changes from that version are: - use mdiobus_write_nested, mdiobus_read_nested. - EXPORT

[PATCH net-next 0/4] net: dsa: lan9303: Fix MDIO issues.

This series fix the MDIO interface for the lan9303 DSA driver. Bugs found after testing on actual HW. This series is extracted from the first patch of my first large series. Significant changes from that version are: - use mdiobus_write_nested, mdiobus_read_nested. - EXPORT

Re: [PATCH] Cipso: cipso_v4_optptr enter infinite loop

On Fri, Jul 28, 2017 at 7:30 AM, Yujuan Qi wrote: > From: "yujuan.qi" > > in for(),if((optlen > 0) && (optptr[1] == 0)), enter infinite loop. > > Test: receive a packet which the ip length > 20 and the first byte of ip > option is 0, produce this

Re: [PATCH] Cipso: cipso_v4_optptr enter infinite loop

On Fri, Jul 28, 2017 at 7:30 AM, Yujuan Qi wrote: > From: "yujuan.qi" > > in for(),if((optlen > 0) && (optptr[1] == 0)), enter infinite loop. > > Test: receive a packet which the ip length > 20 and the first byte of ip > option is 0, produce this issue > > Signed-off-by: yujuan.qi > --- >

Re: [PATCH 2/3] mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem

On Fri, Jul 28, 2017 at 09:46:34AM +0100, Mel Gorman wrote: > On Fri, Jul 28, 2017 at 03:41:51PM +0900, Minchan Kim wrote: > > Nadav reported parallel MADV_DONTNEED on same range has a stale TLB > > problem and Mel fixed it[1] and found same problem on MADV_FREE[2]. > > > > Quote from Mel Gorman

Re: [PATCH 2/3] mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem

On Fri, Jul 28, 2017 at 09:46:34AM +0100, Mel Gorman wrote: > On Fri, Jul 28, 2017 at 03:41:51PM +0900, Minchan Kim wrote: > > Nadav reported parallel MADV_DONTNEED on same range has a stale TLB > > problem and Mel fixed it[1] and found same problem on MADV_FREE[2]. > > > > Quote from Mel Gorman

Re: [PATCH net-next 3/3] tap: XDP support

On 07/28/2017 05:46 AM, Michael S. Tsirkin wrote: On Fri, Jul 28, 2017 at 11:28:54AM +0800, Jason Wang wrote: + old_prog = rtnl_dereference(tun->xdp_prog); + if (old_prog) + bpf_prog_put(old_prog); + rcu_assign_pointer(tun->xdp_prog, prog); Is this OK? Could

Re: [PATCH net-next 3/3] tap: XDP support

On 07/28/2017 05:46 AM, Michael S. Tsirkin wrote: On Fri, Jul 28, 2017 at 11:28:54AM +0800, Jason Wang wrote: + old_prog = rtnl_dereference(tun->xdp_prog); + if (old_prog) + bpf_prog_put(old_prog); + rcu_assign_pointer(tun->xdp_prog, prog); Is this OK? Could

Re: [PATCH v2 3/3] ASoC: codecs: msm8916-wcd-digital: select DMIC source in CIC filter path

On 28/07/17 14:32, Mark Brown wrote: On Wed, Jul 26, 2017 at 01:48:22AM +0200, srinivas.kandaga...@linaro.org wrote: From: Srinivas Kandagatla This patch fixes a missing selection of DMIC in CIC filter source path. Without this patch dmic is not functional.

Re: [PATCH v2 3/3] ASoC: codecs: msm8916-wcd-digital: select DMIC source in CIC filter path

On 28/07/17 14:32, Mark Brown wrote: On Wed, Jul 26, 2017 at 01:48:22AM +0200, srinivas.kandaga...@linaro.org wrote: From: Srinivas Kandagatla This patch fixes a missing selection of DMIC in CIC filter source path. Without this patch dmic is not functional. What happens when someone needs

Re: [PATCH] cgroup: add cgroup.stat interface with basic hierarchy stats

Hello, On Fri, Jul 28, 2017 at 02:01:55PM +0100, Roman Gushchin wrote: > > > + nr_dying_descendants > > > + Total number of dying descendant cgroups. > > > > Can you please go into more detail on what's going on with dying > > descendants here? > > Sure. > Don't we plan do describe

Re: [PATCH] cgroup: add cgroup.stat interface with basic hierarchy stats

Hello, On Fri, Jul 28, 2017 at 02:01:55PM +0100, Roman Gushchin wrote: > > > + nr_dying_descendants > > > + Total number of dying descendant cgroups. > > > > Can you please go into more detail on what's going on with dying > > descendants here? > > Sure. > Don't we plan do describe

Re: [RFC PATCH 0/8] EDAC, mce_amd: Add a tracepoint for the decoded error

Ok, here's a working version. It looks pretty straight-forward (to me, at least) and it does what it is supposed to when I inject an MCE: # tracer: nop # # _-=> irqs-off # / _=> need-resched #| / _---=>

Re: [RFC PATCH 0/8] EDAC, mce_amd: Add a tracepoint for the decoded error

Ok, here's a working version. It looks pretty straight-forward (to me, at least) and it does what it is supposed to when I inject an MCE: # tracer: nop # # _-=> irqs-off # / _=> need-resched #| / _---=>

Re: [PATCH v7] workqueue: Fix edge cases for calc of pool's cpumask

On Thu, Jul 27, 2017 at 04:27:14PM -0500, Michael Bringmann wrote: > > There is an underlying assumption/trade-off in many layers of the Linux > system that CPU <-> node mapping is static. This is despite the presence > of features like NUMA and 'hotplug' that support the dynamic addition/ >

Re: [PATCH v7] workqueue: Fix edge cases for calc of pool's cpumask

On Thu, Jul 27, 2017 at 04:27:14PM -0500, Michael Bringmann wrote: > > There is an underlying assumption/trade-off in many layers of the Linux > system that CPU <-> node mapping is static. This is despite the presence > of features like NUMA and 'hotplug' that support the dynamic addition/ >

Re: [v3,04/10] ipw2200: constify attribute_group structures

Kalle Valo writes: > Arvind Yadav wrote: > >> attribute_group are not supposed to change at runtime. All functions >> working with attribute_group provided by work >> with const attribute_group. So mark the non-const structs as const. >> >>

Re: [v3,04/10] ipw2200: constify attribute_group structures

Kalle Valo writes: > Arvind Yadav wrote: > >> attribute_group are not supposed to change at runtime. All functions >> working with attribute_group provided by work >> with const attribute_group. So mark the non-const structs as const. >> >> Signed-off-by: Arvind Yadav > > 4 patches applied

Re: wl3501_cs: fix spelling mistake: "Insupported" -> "Unsupported"

Colin Ian King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in printk message > > Signed-off-by: Colin Ian King Patch applied to wireless-drivers-next.git, thanks. fcc870d76a2c wl3501_cs: fix

Re: wl3501_cs: fix spelling mistake: "Insupported" -> "Unsupported"

Colin Ian King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in printk message > > Signed-off-by: Colin Ian King Patch applied to wireless-drivers-next.git, thanks. fcc870d76a2c wl3501_cs: fix spelling mistake: "Insupported" -> "Unsupported" --

Re: [v3,04/10] ipw2200: constify attribute_group structures

Arvind Yadav wrote: > attribute_group are not supposed to change at runtime. All functions > working with attribute_group provided by work > with const attribute_group. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav

Re: [v3,04/10] ipw2200: constify attribute_group structures

Arvind Yadav wrote: > attribute_group are not supposed to change at runtime. All functions > working with attribute_group provided by work > with const attribute_group. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav 4 patches applied to wireless-drivers-next.git,

Re: [11/11] brcmfmac: constify pci_device_id

Arvind Yadav wrote: > pci_device_id are not supposed to change at runtime. All functions > working with pci_device_id provided by work with > const pci_device_id. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav >

Re: [11/11] brcmfmac: constify pci_device_id

Arvind Yadav wrote: > pci_device_id are not supposed to change at runtime. All functions > working with pci_device_id provided by work with > const pci_device_id. So mark the non-const structs as const. > > Signed-off-by: Arvind Yadav > Acked-by: Arend van Spriel Patch applied to

Re: zd1211rw: fix spelling mistake 'hybernate' -> 'hibernate'

Colin Ian King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in PDEBUG debug message. > > Signed-off-by: Colin Ian King Patch applied to wireless-drivers-next.git, thanks. af643fe9bbe0

Re: zd1211rw: fix spelling mistake 'hybernate' -> 'hibernate'

Colin Ian King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in PDEBUG debug message. > > Signed-off-by: Colin Ian King Patch applied to wireless-drivers-next.git, thanks. af643fe9bbe0 zd1211rw: fix spelling mistake 'hybernate' -> 'hibernate' --

Re: [PATCH v2 2/2] crypto: engine - Permit to enqueue skcipher request

On Fri, Jul 28, 2017 at 09:52:57PM +0800, Herbert Xu wrote: > On Fri, Jul 14, 2017 at 01:15:36PM +0200, Corentin Labbe wrote: > > On Fri, Jun 23, 2017 at 02:48:37PM +0800, Herbert Xu wrote: > > > On Mon, Jun 19, 2017 at 09:55:24AM +0200, Corentin Labbe wrote: > > > > > > > > Since there are two

Re: [PATCH v2 2/2] crypto: engine - Permit to enqueue skcipher request

On Fri, Jul 28, 2017 at 09:52:57PM +0800, Herbert Xu wrote: > On Fri, Jul 14, 2017 at 01:15:36PM +0200, Corentin Labbe wrote: > > On Fri, Jun 23, 2017 at 02:48:37PM +0800, Herbert Xu wrote: > > > On Mon, Jun 19, 2017 at 09:55:24AM +0200, Corentin Labbe wrote: > > > > > > > > Since there are two

Re: [PATCH 2/2] printk: Add boottime and real timestamps

On 07/25/2017 09:00 AM, Peter Zijlstra wrote: > On Tue, Jul 25, 2017 at 08:17:27AM -0400, Prarit Bhargava wrote: >> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug >> index 5b1662ec546f..6cd38a25f8ea 100644 >> --- a/lib/Kconfig.debug >> +++ b/lib/Kconfig.debug >> @@ -1,8 +1,8 @@ >> menu

Re: [PATCH 2/2] printk: Add boottime and real timestamps

On 07/25/2017 09:00 AM, Peter Zijlstra wrote: > On Tue, Jul 25, 2017 at 08:17:27AM -0400, Prarit Bhargava wrote: >> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug >> index 5b1662ec546f..6cd38a25f8ea 100644 >> --- a/lib/Kconfig.debug >> +++ b/lib/Kconfig.debug >> @@ -1,8 +1,8 @@ >> menu

Re: [PATCH 1/3] perf tools: Add callchain to ctf conversion

Em Fri, Jul 28, 2017 at 11:25:50AM +0200, Jiri Olsa escreveu: > On Thu, Jul 27, 2017 at 02:12:03PM -0400, Geneviève Bastien wrote: > > The field perf_callchain, if available, is added to the sampling > > events during the CTF conversion. It is an array of u64 values. > > The perf_callchain_size

Re: [PATCH 1/3] perf tools: Add callchain to ctf conversion

Em Fri, Jul 28, 2017 at 11:25:50AM +0200, Jiri Olsa escreveu: > On Thu, Jul 27, 2017 at 02:12:03PM -0400, Geneviève Bastien wrote: > > The field perf_callchain, if available, is added to the sampling > > events during the CTF conversion. It is an array of u64 values. > > The perf_callchain_size

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

On 28/07/17 17:50, Thomas Gleixner wrote: On Fri, 28 Jul 2017, Tomi Sarvela wrote: On 28/07/17 17:13, Thomas Gleixner wrote: On Fri, 28 Jul 2017, Tomi Sarvela wrote: On 28/07/17 16:15, Thomas Gleixner wrote: Another question. Is the machine completely dead or not? Completely dead. Powerled

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

On 28/07/17 17:50, Thomas Gleixner wrote: On Fri, 28 Jul 2017, Tomi Sarvela wrote: On 28/07/17 17:13, Thomas Gleixner wrote: On Fri, 28 Jul 2017, Tomi Sarvela wrote: On 28/07/17 16:15, Thomas Gleixner wrote: Another question. Is the machine completely dead or not? Completely dead. Powerled

Re: mwifiex: fix spelling mistake: "Insuffient" -> "Insufficient"

Colin Ian King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in mwifiex_dbg debug message > > Signed-off-by: Colin Ian King Patch applied to wireless-drivers-next.git, thanks. 17830147c40a

Re: mwifiex: fix spelling mistake: "Insuffient" -> "Insufficient"

Colin Ian King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in mwifiex_dbg debug message > > Signed-off-by: Colin Ian King Patch applied to wireless-drivers-next.git, thanks. 17830147c40a mwifiex: fix spelling mistake: "Insuffient" -> "Insufficient" --

[PATCH] xen: avoid deadlock in xenbus

When starting the xenwatch thread a theoretical deadlock situation is possible: xs_init() contains: task = kthread_run(xenwatch_thread, NULL, "xenwatch"); if (IS_ERR(task)) return PTR_ERR(task); xenwatch_pid = task->pid; And xenwatch_thread() does: mutex_lock(_mutex);

[PATCH] xen: avoid deadlock in xenbus

When starting the xenwatch thread a theoretical deadlock situation is possible: xs_init() contains: task = kthread_run(xenwatch_thread, NULL, "xenwatch"); if (IS_ERR(task)) return PTR_ERR(task); xenwatch_pid = task->pid; And xenwatch_thread() does: mutex_lock(_mutex);

[PATCH] hysdn: fix to a race condition in put_log_buffer

The synchronization type that was used earlier to guard the loop that deletes unused log buffers may have lead to a situation that prevents any thread from going through the loop. The patch deletes previously used synchronization mechanism and moves the loop under the spin_lock so the similar

[PATCH] hysdn: fix to a race condition in put_log_buffer

The synchronization type that was used earlier to guard the loop that deletes unused log buffers may have lead to a situation that prevents any thread from going through the loop. The patch deletes previously used synchronization mechanism and moves the loop under the spin_lock so the similar

Re: mwifiex: usb: fix spelling mistake: "aggreataon"-> "aggregation"

Colin Ian King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in aggr_ctrl module parameter > message text. > > Signed-off-by: Colin Ian King Patch applied to wireless-drivers-next.git, thanks.

Re: mwifiex: usb: fix spelling mistake: "aggreataon"-> "aggregation"

Colin Ian King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in aggr_ctrl module parameter > message text. > > Signed-off-by: Colin Ian King Patch applied to wireless-drivers-next.git, thanks. c55971726c40 mwifiex: usb: fix spelling mistake: "aggreataon"-> "aggregation"

Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

> It is too late when we know the PHY ID. > We need to set a syscon for choosing external/internal PHY. > So we can rely only on DT. The point is, its not a property of the PHY. It is a syscon or a MAC property. Having it as a MAC property would be more generic. Andrew

Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

> It is too late when we know the PHY ID. > We need to set a syscon for choosing external/internal PHY. > So we can rely only on DT. The point is, its not a property of the PHY. It is a syscon or a MAC property. Having it as a MAC property would be more generic. Andrew

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

On Fri, 28 Jul 2017, Tomi Sarvela wrote: > On 28/07/17 17:13, Thomas Gleixner wrote: > > On Fri, 28 Jul 2017, Tomi Sarvela wrote: > > > On 28/07/17 16:15, Thomas Gleixner wrote: > > > > Another question. Is the machine completely dead or not? > > > > > > Completely dead. Powerled is on, so host

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

On Fri, 28 Jul 2017, Tomi Sarvela wrote: > On 28/07/17 17:13, Thomas Gleixner wrote: > > On Fri, 28 Jul 2017, Tomi Sarvela wrote: > > > On 28/07/17 16:15, Thomas Gleixner wrote: > > > > Another question. Is the machine completely dead or not? > > > > > > Completely dead. Powerled is on, so host

Re: [PATCH] staging: pi433: use div_u64 for 64-bit division

Hi Dan, Thanks for the hint. I don't get, what went wrong. If I take the mail from my outbox and view it, it looks nice. Seems, I really need to look for another mailtool. But for several reasons, that's not possible at the moment (slow move of 20 domains with someting arround 80 mail adresses

Re: [v2] mwifiex: uninit wakeup info in the error handling

Jeffy Chen wrote: > We inited wakeup info at the beginning of mwifiex_add_card, so we need > to uninit it in the error handling. > > It's much the same as what we did in: > 36908c4 mwifiex: uninit wakeup info when removing device > > Signed-off-by: Jeffy Chen

Re: [PATCH] staging: pi433: use div_u64 for 64-bit division

Hi Dan, Thanks for the hint. I don't get, what went wrong. If I take the mail from my outbox and view it, it looks nice. Seems, I really need to look for another mailtool. But for several reasons, that's not possible at the moment (slow move of 20 domains with someting arround 80 mail adresses

Re: [v2] mwifiex: uninit wakeup info in the error handling

Jeffy Chen wrote: > We inited wakeup info at the beginning of mwifiex_add_card, so we need > to uninit it in the error handling. > > It's much the same as what we did in: > 36908c4 mwifiex: uninit wakeup info when removing device > > Signed-off-by: Jeffy Chen > Reviewed-by: Brian Norris

Re: [v2,01/20] mwifiex: reunite copy-and-pasted remove/reset code

Brian Norris wrote: > 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

Re: [v2,01/20] mwifiex: reunite copy-and-pasted remove/reset code

Brian Norris wrote: > 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: > >

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

On 28/07/17 17:13, Thomas Gleixner wrote: On Fri, 28 Jul 2017, Tomi Sarvela wrote: On 28/07/17 16:15, Thomas Gleixner wrote: Another question. Is the machine completely dead or not? Completely dead. Powerled is on, so host isn't shut down. So that means it does not even power the machine

Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

On 28/07/17 17:13, Thomas Gleixner wrote: On Fri, 28 Jul 2017, Tomi Sarvela wrote: On 28/07/17 16:15, Thomas Gleixner wrote: Another question. Is the machine completely dead or not? Completely dead. Powerled is on, so host isn't shut down. So that means it does not even power the machine

[GIT PULL] xen: fixes for 4.13-rc3

Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.13b-rc3-tag xen: fixes for 4.13-rc3 It contains three minor cleanups for xen related drivers. Thanks. Juergen drivers/xen/events/events_base.c | 13 +++--

[GIT PULL] xen: fixes for 4.13-rc3

Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.13b-rc3-tag xen: fixes for 4.13-rc3 It contains three minor cleanups for xen related drivers. Thanks. Juergen drivers/xen/events/events_base.c | 13 +++--

Re: [PATCH 08/14] ipmi: use atomic_dec_not_zero()

On 07/28/2017 09:27 AM, Corey Minyard wrote: I missed this until now, and I see it hasn't been applied yet. It's queued for the next release. Well, never mind, I see the main update didn't go in. -corey Thanks, -corey On 01/30/2017 12:47 PM, Fabian Frederick wrote: instead of

Re: [PATCH 08/14] ipmi: use atomic_dec_not_zero()

On 07/28/2017 09:27 AM, Corey Minyard wrote: I missed this until now, and I see it hasn't been applied yet. It's queued for the next release. Well, never mind, I see the main update didn't go in. -corey Thanks, -corey On 01/30/2017 12:47 PM, Fabian Frederick wrote: instead of

Re: [PATCH v1 4/6] ASoC: codecs: msm8916-wcd-analog: set default micbias voltage to 1.8

On 28/07/17 15:01, Mark Brown wrote: On Fri, Jul 28, 2017 at 02:54:59PM +0100, Srinivas Kandagatla wrote: On 28/07/17 14:40, Mark Brown wrote: On Wed, Jul 26, 2017 at 02:35:10AM +0200, srinivas.kandaga...@linaro.org wrote: From: Srinivas Kandagatla This

Re: [PATCH v1 4/6] ASoC: codecs: msm8916-wcd-analog: set default micbias voltage to 1.8

On 28/07/17 15:01, Mark Brown wrote: On Fri, Jul 28, 2017 at 02:54:59PM +0100, Srinivas Kandagatla wrote: On 28/07/17 14:40, Mark Brown wrote: On Wed, Jul 26, 2017 at 02:35:10AM +0200, srinivas.kandaga...@linaro.org wrote: From: Srinivas Kandagatla This patch sets the default internal

Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

On Fri, Jul 28, 2017 at 04:36:00PM +0200, Andrew Lunn wrote: > > > I've probably asked this before: Does the internal PHY use a different > > > PHY ID in registers 2 and 3? > > > > > > > yes > > > > reg2: 0x0044 > > reg3: 0X1500 Copy/paste error, its 1400 > > So this is not about loading the

Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

On Fri, Jul 28, 2017 at 04:36:00PM +0200, Andrew Lunn wrote: > > > I've probably asked this before: Does the internal PHY use a different > > > PHY ID in registers 2 and 3? > > > > > > > yes > > > > reg2: 0x0044 > > reg3: 0X1500 Copy/paste error, its 1400 > > So this is not about loading the

[PATCH net] tcp: avoid bogus gcc-7 array-bounds warning

When using CONFIG_UBSAN_SANITIZE_ALL, the TCP code produces a false-positive warning: net/ipv4/tcp_output.c: In function 'tcp_connect': net/ipv4/tcp_output.c:2207:40: error: array subscript is below array bounds [-Werror=array-bounds] tp->chrono_stat[tp->chrono_type - 1] += now -

[PATCH net] tcp: avoid bogus gcc-7 array-bounds warning

When using CONFIG_UBSAN_SANITIZE_ALL, the TCP code produces a false-positive warning: net/ipv4/tcp_output.c: In function 'tcp_connect': net/ipv4/tcp_output.c:2207:40: error: array subscript is below array bounds [-Werror=array-bounds] tp->chrono_stat[tp->chrono_type - 1] += now -

Re: [PATCH 0/2] arm64: dts: cleanup Broadcom boards per SoC

Hi Florian, Could you please pick up PATCH 1/2 of this series below and drop PATCH 2/2 ? On 17-07-19 10:05 AM, Scott Branden wrote: Separate Broadcom boards per SoC to assist in cleaner management of boards. This has already been done for Stingray and is done here for RPI and NS2. If this is

Re: [PATCH 0/2] arm64: dts: cleanup Broadcom boards per SoC

Hi Florian, Could you please pick up PATCH 1/2 of this series below and drop PATCH 2/2 ? On 17-07-19 10:05 AM, Scott Branden wrote: Separate Broadcom boards per SoC to assist in cleaner management of boards. This has already been done for Stingray and is done here for RPI and NS2. If this is

Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

> > I've probably asked this before: Does the internal PHY use a different > > PHY ID in registers 2 and 3? > > > > yes > > reg2: 0x0044 > reg3: 0X1500 So this is not about loading the correct PHY driver. You can already do this based on the PHY IDs... This is about selecting which PHY to

Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

> > I've probably asked this before: Does the internal PHY use a different > > PHY ID in registers 2 and 3? > > > > yes > > reg2: 0x0044 > reg3: 0X1500 So this is not about loading the correct PHY driver. You can already do this based on the PHY IDs... This is about selecting which PHY to

Re: [PATCH] HID: wacom: add USB_HID dependency

On Fri, Jul 28, 2017 at 4:24 PM, Jason Gerecke wrote: > On Fri, Jul 28, 2017 at 7:18 AM, Arnd Bergmann wrote: >> On Fri, Jul 28, 2017 at 4:07 PM, Jason Gerecke wrote: >> #ifdef CONFIG_USB_HID >> extern bool

Re: [PATCH] HID: wacom: add USB_HID dependency

On Fri, Jul 28, 2017 at 4:24 PM, Jason Gerecke wrote: > On Fri, Jul 28, 2017 at 7:18 AM, Arnd Bergmann wrote: >> On Fri, Jul 28, 2017 at 4:07 PM, Jason Gerecke wrote: >> #ifdef CONFIG_USB_HID >> extern bool hid_is_using_usb_driver(struct hid_device *hdev) >> #else >> static inline bool

[PATCH v5 1/2] platform: Add driver for RAVE Supervisory Processor

Add a driver for RAVE Supervisory Processor, an MCU implementing varoius bits of housekeeping functionality (watchdoging, backlight control, LED control, etc) on RAVE family of products by Zodiac Inflight Innovations. This driver implementes core MFD/serdev device as well as communication

[PATCH v5 2/2] dt-bindings: mfd: Add bindings for ZII RAVE devices

Cc: cphe...@gmail.com Cc: Lucas Stach Cc: Nikita Yushchenko Cc: Rob Herring Cc: Mark Rutland Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Acked-by: Rob Herring

Re: [PATCH 08/14] ipmi: use atomic_dec_not_zero()

I missed this until now, and I see it hasn't been applied yet. It's queued for the next release. Thanks, -corey On 01/30/2017 12:47 PM, Fabian Frederick wrote: instead of atomic_add_unless(value, -1, 0) Signed-off-by: Fabian Frederick ---

[PATCH v5 1/2] platform: Add driver for RAVE Supervisory Processor

Add a driver for RAVE Supervisory Processor, an MCU implementing varoius bits of housekeeping functionality (watchdoging, backlight control, LED control, etc) on RAVE family of products by Zodiac Inflight Innovations. This driver implementes core MFD/serdev device as well as communication

[PATCH v5 2/2] dt-bindings: mfd: Add bindings for ZII RAVE devices

Cc: cphe...@gmail.com Cc: Lucas Stach Cc: Nikita Yushchenko Cc: Rob Herring Cc: Mark Rutland Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Acked-by: Rob Herring Acked-for-MFD-by: Lee Jones Signed-off-by: Andrey Smirnov --- .../devicetree/bindings/mfd/zii,rave-sp.txt

Re: [PATCH 08/14] ipmi: use atomic_dec_not_zero()

I missed this until now, and I see it hasn't been applied yet. It's queued for the next release. Thanks, -corey On 01/30/2017 12:47 PM, Fabian Frederick wrote: instead of atomic_add_unless(value, -1, 0) Signed-off-by: Fabian Frederick --- drivers/char/ipmi/ipmi_msghandler.c | 2 +- 1

[PATCH v5 0/2] ZII RAVE platform driver

Greg, I am not sure if you are the right person to send these to, if you are not, please let me know who would be the appropriate recepient and sorry for the noise. Thanks! The orginal conver letter text follows: Hi everyone, This patch series is v4 of the driver for supervisory processor

[PATCH v5 0/2] ZII RAVE platform driver

Greg, I am not sure if you are the right person to send these to, if you are not, please let me know who would be the appropriate recepient and sorry for the noise. Thanks! The orginal conver letter text follows: Hi everyone, This patch series is v4 of the driver for supervisory processor

Re: [PATCH] staging: pi433: use div_u64 for 64-bit division

On Fri, Jul 28, 2017 at 04:21:05PM +0200, Marcus Wolf wrote: > Hi Arnd, > > we already have a patch for this: > [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation > from 20.07.2017 https://patchwork.kernel.org/patch/9855261/ > > Maybe I did something wrong, but my

Re: [PATCH] staging: pi433: use div_u64 for 64-bit division

On Fri, Jul 28, 2017 at 04:21:05PM +0200, Marcus Wolf wrote: > Hi Arnd, > > we already have a patch for this: > [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation > from 20.07.2017 https://patchwork.kernel.org/patch/9855261/ > > Maybe I did something wrong, but my

Re: [PATCH] staging: pi433: use div_u64 for 64-bit division

On Fri, Jul 28, 2017 at 4:21 PM, Marcus Wolf wrote: > Hi Arnd, > > we already have a patch for this: > [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation > from 20.07.2017 > > Maybe I did something wrong, but my first solution was

Re: [PATCH] staging: pi433: use div_u64 for 64-bit division

On Fri, Jul 28, 2017 at 4:21 PM, Marcus Wolf wrote: > Hi Arnd, > > we already have a patch for this: > [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation > from 20.07.2017 > > Maybe I did something wrong, but my first solution was exactly like your > proposal. As far as

Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

On 07/28/2017 12:19 AM, Michael Ellerman wrote: > Jens Axboe writes: >> On 07/27/2017 08:47 AM, Bart Van Assche wrote: >>> On Thu, 2017-07-27 at 08:02 -0600, Jens Axboe wrote: The bug looks like SCSI running the queue inline from IRQ context, that's not a good idea. >

Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

On 07/28/2017 12:19 AM, Michael Ellerman wrote: > Jens Axboe writes: >> On 07/27/2017 08:47 AM, Bart Van Assche wrote: >>> On Thu, 2017-07-27 at 08:02 -0600, Jens Axboe wrote: The bug looks like SCSI running the queue inline from IRQ context, that's not a good idea. > ... >>> >>>

Re: [PATCH] HID: wacom: add USB_HID dependency

On Fri, Jul 28, 2017 at 7:18 AM, Arnd Bergmann wrote: > On Fri, Jul 28, 2017 at 4:07 PM, Jason Gerecke wrote: >> On July 28, 2017 6:18:00 AM PDT, Arnd Bergmann wrote: >>>The driver has gained a compile-time dependency that we should >>>express

Re: [PATCH] HID: wacom: add USB_HID dependency

On Fri, Jul 28, 2017 at 7:18 AM, Arnd Bergmann wrote: > On Fri, Jul 28, 2017 at 4:07 PM, Jason Gerecke wrote: >> On July 28, 2017 6:18:00 AM PDT, Arnd Bergmann wrote: >>>The driver has gained a compile-time dependency that we should >>>express in Kconfig to avoid this link error: >>> >> >>

Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

On Fri, Jul 28, 2017 at 03:55:44PM +0200, Andrew Lunn wrote: > On Fri, Jul 28, 2017 at 11:28:15AM +0200, Corentin Labbe wrote: > > Hello > > > > The current way to find if the phy is internal is to compare DT phy-mode > > and emac_variant/internal_phy. > > But it will negate a possible future SoC

Re: [PATCH 0/3] net-next: stmmac: support future possible different internal phy mode

On Fri, Jul 28, 2017 at 03:55:44PM +0200, Andrew Lunn wrote: > On Fri, Jul 28, 2017 at 11:28:15AM +0200, Corentin Labbe wrote: > > Hello > > > > The current way to find if the phy is internal is to compare DT phy-mode > > and emac_variant/internal_phy. > > But it will negate a possible future SoC

[PATCH] fs: convert a pile of fsync routines to errseq_t based reporting

From: Jeff Layton This patch converts most of the in-kernel filesystems that do writeback out of the pagecache to report errors using the errseq_t-based infrastructure that was recently added. This allows them to report errors once for each open file description. Most

[PATCH] fs: convert a pile of fsync routines to errseq_t based reporting

From: Jeff Layton This patch converts most of the in-kernel filesystems that do writeback out of the pagecache to report errors using the errseq_t-based infrastructure that was recently added. This allows them to report errors once for each open file description. Most filesystems have a fairly

<    3   4   5   6   7   8   9   10   11   12   >