Re: [PATCH v2] driver-core: Return EBUSY error instead of BUG_ON()

On Fri, May 04, 2018 at 03:23:57PM +0200, Florian Schmaus wrote: > I triggerd the BUG_ON() in driver_register(), which was added in > f48f3febb2cbfd0f2ecee7690835ba745c1034a4, when booting a domU Xen > domain. Since there was no contextual information logged, I needed to > attach kgdb to determine

Re: [PATCH v2] driver-core: Return EBUSY error instead of BUG_ON()

On Fri, May 04, 2018 at 03:23:57PM +0200, Florian Schmaus wrote: > I triggerd the BUG_ON() in driver_register(), which was added in > f48f3febb2cbfd0f2ecee7690835ba745c1034a4, when booting a domU Xen > domain. Since there was no contextual information logged, I needed to > attach kgdb to determine

Re: [PATCHv2] serial: 8250: omap: Fix idling of clocks for unused uarts

* Tony Lindgren [180504 17:33]: > I noticed that unused UARTs won't necessarily idle properly always > unless at least one byte tx transfer is done first. > --- > arch/arm/mach-actions/platsmp.c | 6 +++--- > arch/arm/mach-exynos/platsmp.c | 12 ++-- >

Re: [PATCHv2] serial: 8250: omap: Fix idling of clocks for unused uarts

* Tony Lindgren [180504 17:33]: > I noticed that unused UARTs won't necessarily idle properly always > unless at least one byte tx transfer is done first. > --- > arch/arm/mach-actions/platsmp.c | 6 +++--- > arch/arm/mach-exynos/platsmp.c | 12 ++-- >

Re: [PATCH 4/4] ide: don't enable/disable interrupts in force threaded-IRQ mode

From: Sebastian Andrzej Siewior Date: Fri, 4 May 2018 16:24:46 +0200 > The interrupts are enabled/disabled so the interrupt handler can run > with enabled interrupts while serving the interrupt and not lose other > interrupts especially the timer tick. > If the system

Re: [PATCH 4/4] ide: don't enable/disable interrupts in force threaded-IRQ mode

From: Sebastian Andrzej Siewior Date: Fri, 4 May 2018 16:24:46 +0200 > The interrupts are enabled/disabled so the interrupt handler can run > with enabled interrupts while serving the interrupt and not lose other > interrupts especially the timer tick. > If the system runs with force-threaded

Re: [PATCH 3/4] ide: don't disable interrupts during kmap_atomic()

From: Sebastian Andrzej Siewior Date: Fri, 4 May 2018 16:24:45 +0200 > ide_pio_bytes() disables interrupts around kmap_atomic(). This is a > leftover from the old kmap_atomic() implementation which relied on fixed > mapping slots, so the caller had to make sure that the

Re: [PATCH 3/4] ide: don't disable interrupts during kmap_atomic()

From: Sebastian Andrzej Siewior Date: Fri, 4 May 2018 16:24:45 +0200 > ide_pio_bytes() disables interrupts around kmap_atomic(). This is a > leftover from the old kmap_atomic() implementation which relied on fixed > mapping slots, so the caller had to make sure that the same slot could not > be

serial: uart_port->type

Hi All, For the uart_port structure’s “type”, I see the permitted types are none, 8250, 16450, 16550, 16550A, 16650, 16650V2, 16654, 16750, 16850, 16950, and 16954 etc. For FPGA based UART hardware(it has 512 bytes FIFO and supports up to 4Mbps speed) what should be the ‘type’ value? --

Re: [PATCH 2/4] ide: Handle irq disabling consistently

From: Sebastian Andrzej Siewior Date: Fri, 4 May 2018 16:24:44 +0200 > ide_timer_expiry() disables interrupt at function entry when acquiring > hwif->lock. Before disabling the device interrupt it unlocks hwif->lock, > but interrupts stay disabled. After the call to

Re: [RFC] sched/core: Don't schedule threads on pre-empted vcpus

Hi Steve, On 05/04/2018 10:32 AM, Steven Sistare wrote: On 5/4/2018 1:22 PM, Rohit Jain wrote: Hi Peter, On 05/04/2018 02:47 AM, Peter Zijlstra wrote: On Wed, May 02, 2018 at 01:52:10PM -0700, Rohit Jain wrote: diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 5e10aae..75d1ecf

serial: uart_port->type

Hi All, For the uart_port structure’s “type”, I see the permitted types are none, 8250, 16450, 16550, 16550A, 16650, 16650V2, 16654, 16750, 16850, 16950, and 16954 etc. For FPGA based UART hardware(it has 512 bytes FIFO and supports up to 4Mbps speed) what should be the ‘type’ value? --

Re: [PATCH 2/4] ide: Handle irq disabling consistently

From: Sebastian Andrzej Siewior Date: Fri, 4 May 2018 16:24:44 +0200 > ide_timer_expiry() disables interrupt at function entry when acquiring > hwif->lock. Before disabling the device interrupt it unlocks hwif->lock, > but interrupts stay disabled. After the call to disable_irq() interrupts >

Re: [RFC] sched/core: Don't schedule threads on pre-empted vcpus

Hi Steve, On 05/04/2018 10:32 AM, Steven Sistare wrote: On 5/4/2018 1:22 PM, Rohit Jain wrote: Hi Peter, On 05/04/2018 02:47 AM, Peter Zijlstra wrote: On Wed, May 02, 2018 at 01:52:10PM -0700, Rohit Jain wrote: diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 5e10aae..75d1ecf

Re: rcu-bh design

On Fri, 4 May 2018 10:32:06 -0700 "Paul E. McKenney" wrote: > > > But preemptible RCU *does not* use context-switch as a quiescent state. > > > > It doesn't? > > It does, but only sort of. Ah, my confusion. I was thinking of rcu_read_lock_sched() as

Re: rcu-bh design

On Fri, 4 May 2018 10:32:06 -0700 "Paul E. McKenney" wrote: > > > But preemptible RCU *does not* use context-switch as a quiescent state. > > > > It doesn't? > > It does, but only sort of. Ah, my confusion. I was thinking of rcu_read_lock_sched() as "preemptible RCU", not the "we can

Re: [PATCH 1/4] alim15x3: move irq-restore before pci_dev_put()

From: Sebastian Andrzej Siewior Date: Fri, 4 May 2018 16:24:43 +0200 > init_chipset_ali15x3() initializes the chipset during init with disabled > interrupts. There is no need to keep the interrupts disabled during > pci_dev_put(). > Move the irq-restore before

Re: [PATCH 1/4] alim15x3: move irq-restore before pci_dev_put()

From: Sebastian Andrzej Siewior Date: Fri, 4 May 2018 16:24:43 +0200 > init_chipset_ali15x3() initializes the chipset during init with disabled > interrupts. There is no need to keep the interrupts disabled during > pci_dev_put(). > Move the irq-restore before pci_dev_put() is invoked. > >

Re: [PATCH v2] driver-core: Return EBUSY error instead of BUG_ON()

On Fri, May 04, 2018 at 03:23:57PM +0200, Florian Schmaus wrote: > I triggerd the BUG_ON() in driver_register(), which was added in > f48f3febb2cbfd0f2ecee7690835ba745c1034a4, when booting a domU Xen > domain. Since there was no contextual information logged, I needed to > attach kgdb to determine

Re: [PATCH v2] driver-core: Return EBUSY error instead of BUG_ON()

On Fri, May 04, 2018 at 03:23:57PM +0200, Florian Schmaus wrote: > I triggerd the BUG_ON() in driver_register(), which was added in > f48f3febb2cbfd0f2ecee7690835ba745c1034a4, when booting a domU Xen > domain. Since there was no contextual information logged, I needed to > attach kgdb to determine

Re: [PATCH v2 13/27] coresight: Add generic TMC sg table framework

On Tue, May 01, 2018 at 10:10:43AM +0100, Suzuki K Poulose wrote: > This patch introduces a generic sg table data structure and > associated operations. An SG table can be used to map a set > of Data pages where the trace data could be stored by the TMC > ETR. The information about the data pages

Re: [PATCH v2 13/27] coresight: Add generic TMC sg table framework

On Tue, May 01, 2018 at 10:10:43AM +0100, Suzuki K Poulose wrote: > This patch introduces a generic sg table data structure and > associated operations. An SG table can be used to map a set > of Data pages where the trace data could be stored by the TMC > ETR. The information about the data pages

Re: [PATCH v7 01/24] soc: qcom dt-bindings: Add APR bus bindings

On Tue 01 May 05:07 PDT 2018, Srinivas Kandagatla wrote: > This patch add dt bindings for Qualcomm APR (Asynchronous Packet Router) > bus driver. This bus is used for communicating with DSP which provides > audio and various other services to cpu. > > Signed-off-by: Srinivas Kandagatla

Re: [PATCH v7 01/24] soc: qcom dt-bindings: Add APR bus bindings

On Tue 01 May 05:07 PDT 2018, Srinivas Kandagatla wrote: > This patch add dt bindings for Qualcomm APR (Asynchronous Packet Router) > bus driver. This bus is used for communicating with DSP which provides > audio and various other services to cpu. > > Signed-off-by: Srinivas Kandagatla >

Re: [RFC] sched/core: Don't schedule threads on pre-empted vcpus

On 5/4/2018 1:22 PM, Rohit Jain wrote: > Hi Peter, > > On 05/04/2018 02:47 AM, Peter Zijlstra wrote: >> On Wed, May 02, 2018 at 01:52:10PM -0700, Rohit Jain wrote: >>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c >>> index 5e10aae..75d1ecf 100644 >>> --- a/kernel/sched/core.c >>> +++

Re: [RFC] sched/core: Don't schedule threads on pre-empted vcpus

On 5/4/2018 1:22 PM, Rohit Jain wrote: > Hi Peter, > > On 05/04/2018 02:47 AM, Peter Zijlstra wrote: >> On Wed, May 02, 2018 at 01:52:10PM -0700, Rohit Jain wrote: >>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c >>> index 5e10aae..75d1ecf 100644 >>> --- a/kernel/sched/core.c >>> +++

Re: [PATCH] Add a file named cgroup.procs_stat in cgroup

On Fri, May 04, 2018 at 10:28:20PM +0800, zhangq95 wrote: > When I run "cat /proc/stat" in a container, container will access > host's file directly which is a security risk. Why is this a "security risk"? What can be learned there that is somehow "bad"? thanks, greg k-h

Re: [PATCH] Add a file named cgroup.procs_stat in cgroup

On Fri, May 04, 2018 at 10:28:20PM +0800, zhangq95 wrote: > When I run "cat /proc/stat" in a container, container will access > host's file directly which is a security risk. Why is this a "security risk"? What can be learned there that is somehow "bad"? thanks, greg k-h

Charity Gift !!!

-- This is the second time i am sending you this mail. I, Mavis Wanczyk donates $ 5 Million Dollars from part of my Powerball Jackpot Lottery of $ 758 Million Dollars, respond with your details for claims. I await your earliest response and God Bless you Good luck. Mavis Wanczyk

Charity Gift !!!

-- This is the second time i am sending you this mail. I, Mavis Wanczyk donates $ 5 Million Dollars from part of my Powerball Jackpot Lottery of $ 758 Million Dollars, respond with your details for claims. I await your earliest response and God Bless you Good luck. Mavis Wanczyk

Re: [PATCH net] net: phy: sfp: fix the BR,min computation

From: Antoine Tenart Date: Fri, 4 May 2018 17:10:54 +0200 > In an SFP EEPROM values can be read to get information about a given SFP > module. One of those is the bitrate, which can be determined using a > nominal bitrate in addition with min and max values (in %).

Re: [PATCH net] net: phy: sfp: fix the BR,min computation

From: Antoine Tenart Date: Fri, 4 May 2018 17:10:54 +0200 > In an SFP EEPROM values can be read to get information about a given SFP > module. One of those is the bitrate, which can be determined using a > nominal bitrate in addition with min and max values (in %). The SFP code > currently

Re: [PATCH v2 2/4] net: hook socketpair() into LSM

From: David Herrmann Date: Fri, 4 May 2018 16:28:20 +0200 > Use the newly created LSM-hook for socketpair(). The default hook > return-value is 0, so behavior stays the same unless LSMs start using > this hook. > > Acked-by: Serge Hallyn >

[PATCHv2] serial: 8250: omap: Fix idling of clocks for unused uarts

I noticed that unused UARTs won't necessarily idle properly always unless at least one byte tx transfer is done first. After some debugging I narrowed down the problem to the scr register dma configuration bits that need to be set before softreset for the clocks to idle. Unless we do this, the

Re: [PATCH v2 2/4] net: hook socketpair() into LSM

From: David Herrmann Date: Fri, 4 May 2018 16:28:20 +0200 > Use the newly created LSM-hook for socketpair(). The default hook > return-value is 0, so behavior stays the same unless LSMs start using > this hook. > > Acked-by: Serge Hallyn > Signed-off-by: Tom Gundersen > Signed-off-by: David

[PATCHv2] serial: 8250: omap: Fix idling of clocks for unused uarts

I noticed that unused UARTs won't necessarily idle properly always unless at least one byte tx transfer is done first. After some debugging I narrowed down the problem to the scr register dma configuration bits that need to be set before softreset for the clocks to idle. Unless we do this, the

Re: rcu-bh design

On Fri, May 04, 2018 at 12:30:50PM -0400, Steven Rostedt wrote: > On Fri, 04 May 2018 16:20:11 + > Joel Fernandes wrote: > > > Hi Paul, everyone, > > > > I had some question(s) about rcu-bh design. > > I am trying to understand the reasoning or need of it. I see that

Re: rcu-bh design

On Fri, May 04, 2018 at 12:30:50PM -0400, Steven Rostedt wrote: > On Fri, 04 May 2018 16:20:11 + > Joel Fernandes wrote: > > > Hi Paul, everyone, > > > > I had some question(s) about rcu-bh design. > > I am trying to understand the reasoning or need of it. I see that rcu-bh > > will disable

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

Steven Rostedt wrote: On Sat, 5 May 2018 00:48:28 +0900 Masami Hiramatsu wrote: > > Also, when looking at the kprobe code, I was looking at this function: > > > /* Ftrace callback handler for kprobes -- called under preepmt disabed */ > > void

Re: [PATCH v7 00/16] tracing: probeevent: Improve fetcharg features

Steven Rostedt wrote: On Sat, 5 May 2018 00:48:28 +0900 Masami Hiramatsu wrote: > > Also, when looking at the kprobe code, I was looking at this function: > > > /* Ftrace callback handler for kprobes -- called under preepmt disabed */ > > void kprobe_ftrace_handler(unsigned long ip,

[PATCH 2/2] memcg: Close the race between migration and installing bprm->mm as mm

Oleg pointed out that there is a race at exec time between when bprm->mm is initialized and the exec'ing task being migrated to a different memory control group. Ractor the code in memcontrol so exec_mmap can use the same code as as fork to ensure that task->memcg == task->mm->memcg.

[PATCH 2/2] memcg: Close the race between migration and installing bprm->mm as mm

Oleg pointed out that there is a race at exec time between when bprm->mm is initialized and the exec'ing task being migrated to a different memory control group. Ractor the code in memcontrol so exec_mmap can use the same code as as fork to ensure that task->memcg == task->mm->memcg.

[PATCH 1/2] memcg: Update the mm->memcg maintenance to work when !CONFIG_MMU

Michal Hocko reported: > I am getting the following for nommu with MEMCG=y randconfig: > kernel/fork.o: In function `mm_init': > fork.c:(.text+0x948): undefined reference to `mm_update_memcg' > kernel/fork.o: In function `mmput': > fork.c:(.text+0x119c): undefined reference to

[PATCH 1/2] memcg: Update the mm->memcg maintenance to work when !CONFIG_MMU

Michal Hocko reported: > I am getting the following for nommu with MEMCG=y randconfig: > kernel/fork.o: In function `mm_init': > fork.c:(.text+0x948): undefined reference to `mm_update_memcg' > kernel/fork.o: In function `mmput': > fork.c:(.text+0x119c): undefined reference to `mm_update_memcg'

[PATCH 0/2] mm->owner to mm->memcg fixes

Andrew can you pick up these two fixes as well. These address the issues Michal Hocko and Oleg Nesterov noticed. Eric W. Biederman (2): memcg: Update the mm->memcg maintenance to work when !CONFIG_MMU memcg: Close the race between migration and installing bprm->mm as mm fs/exec.c

[PATCH 0/2] mm->owner to mm->memcg fixes

Andrew can you pick up these two fixes as well. These address the issues Michal Hocko and Oleg Nesterov noticed. Eric W. Biederman (2): memcg: Update the mm->memcg maintenance to work when !CONFIG_MMU memcg: Close the race between migration and installing bprm->mm as mm fs/exec.c

[PATCH 1/2] net: nixge: Fix error path for obtaining mac address

Fix issue where nixge_get_nvmem_address() returns a non-NULL return value on a failed nvmem_cell_get() that causes an invalid access when error value encoded in pointer is dereferenced. Furthermore ensure that buffer allocated by nvmem_cell_read() actually gets kfreed() if the function succeeds.

[PATCH 1/2] net: nixge: Fix error path for obtaining mac address

Fix issue where nixge_get_nvmem_address() returns a non-NULL return value on a failed nvmem_cell_get() that causes an invalid access when error value encoded in pointer is dereferenced. Furthermore ensure that buffer allocated by nvmem_cell_read() actually gets kfreed() if the function succeeds.

[PATCH 2/2] net: nixge: Address compiler warnings about signedness

Fixes the following warnings: warning: pointer targets in passing argument 1 of ‘is_valid_ether_addr’ differ in signedness [-Wpointer-sign] if (mac_addr && is_valid_ether_addr(mac_addr)) { ^~~~ expected ‘const u8 * {aka const unsigned char *}’ but

[PATCH 2/2] net: nixge: Address compiler warnings about signedness

Fixes the following warnings: warning: pointer targets in passing argument 1 of ‘is_valid_ether_addr’ differ in signedness [-Wpointer-sign] if (mac_addr && is_valid_ether_addr(mac_addr)) { ^~~~ expected ‘const u8 * {aka const unsigned char *}’ but

Re: [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors

Hi Florian, On Fri, May 04, 2018 at 10:04:48AM -0700, Florian Fainelli wrote: > On 05/04/2018 06:56 AM, Antoine Tenart wrote: > > SFP connectors can be solder on a board without having any of their pins > > (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed, > > and the

Re: [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors

Hi Florian, On Fri, May 04, 2018 at 10:04:48AM -0700, Florian Fainelli wrote: > On 05/04/2018 06:56 AM, Antoine Tenart wrote: > > SFP connectors can be solder on a board without having any of their pins > > (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed, > > and the

Re: [RFC] sched/core: Don't schedule threads on pre-empted vcpus

Hi Peter, On 05/04/2018 02:47 AM, Peter Zijlstra wrote: On Wed, May 02, 2018 at 01:52:10PM -0700, Rohit Jain wrote: diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 5e10aae..75d1ecf 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -4033,6 +4033,9 @@ int idle_cpu(int

Re: [RFC] sched/core: Don't schedule threads on pre-empted vcpus

Hi Peter, On 05/04/2018 02:47 AM, Peter Zijlstra wrote: On Wed, May 02, 2018 at 01:52:10PM -0700, Rohit Jain wrote: diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 5e10aae..75d1ecf 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -4033,6 +4033,9 @@ int idle_cpu(int

Re: KASAN: use-after-free Read in fuse_kill_sb_anon

Miklos, please respond to a patch at http://lkml.kernel.org/r/37d2030a-124c-9927-aa48-bb769da79...@i-love.sakura.ne.jp . #syz dup: KASAN: use-after-free Read in fuse_kill_sb_blk

Re: [PATCH net-next v2 01/13] net: phy: sfp: make the i2c-bus property really optional

Hi Florian, On Fri, May 04, 2018 at 10:03:16AM -0700, Florian Fainelli wrote: > On 05/04/2018 06:56 AM, Antoine Tenart wrote: > > > > static int sfp_read(struct sfp *sfp, bool a2, u8 addr, void *buf, size_t > > len) > > { > > + if (!sfp->read) > > + return -EOPNOTSUPP; > >

Re: KASAN: use-after-free Read in fuse_kill_sb_anon

Miklos, please respond to a patch at http://lkml.kernel.org/r/37d2030a-124c-9927-aa48-bb769da79...@i-love.sakura.ne.jp . #syz dup: KASAN: use-after-free Read in fuse_kill_sb_blk

Re: [PATCH net-next v2 01/13] net: phy: sfp: make the i2c-bus property really optional

Hi Florian, On Fri, May 04, 2018 at 10:03:16AM -0700, Florian Fainelli wrote: > On 05/04/2018 06:56 AM, Antoine Tenart wrote: > > > > static int sfp_read(struct sfp *sfp, bool a2, u8 addr, void *buf, size_t > > len) > > { > > + if (!sfp->read) > > + return -EOPNOTSUPP; > >

Re: [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors

On Fri, May 04, 2018 at 10:04:48AM -0700, Florian Fainelli wrote: > On 05/04/2018 06:56 AM, Antoine Tenart wrote: > > SFP connectors can be solder on a board without having any of their pins > > (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed, > > and the overall link

Re: [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors

On Fri, May 04, 2018 at 10:04:48AM -0700, Florian Fainelli wrote: > On 05/04/2018 06:56 AM, Antoine Tenart wrote: > > SFP connectors can be solder on a board without having any of their pins > > (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed, > > and the overall link

Re: [PATCH] kernel/signal: Remove no longer required irqsave/restore

Sebastian Andrzej Siewior writes: > On 2018-05-04 11:59:08 [-0500], Eric W. Biederman wrote: >> Sebastian Andrzej Siewior writes: >> > From: Anna-Maria Gleixner > … >> > This long-term fix has been made in commit

Re: [PATCH] kernel/signal: Remove no longer required irqsave/restore

Sebastian Andrzej Siewior writes: > On 2018-05-04 11:59:08 [-0500], Eric W. Biederman wrote: >> Sebastian Andrzej Siewior writes: >> > From: Anna-Maria Gleixner > … >> > This long-term fix has been made in commit 4abf91047cf ("rtmutex: Make > >> > wait_lock irq safe") for different reason. >>

[PATCH BUGFIX] block, bfq: postpone rq preparation to insert or merge

When invoked for an I/O request rq, the prepare_request hook of bfq increments reference counters in the destination bfq_queue for rq. In this respect, after this hook has been invoked, rq may still be transformed into a request with no icq attached, i.e., for bfq, a request not associated with

[PATCH BUGFIX] block, bfq: postpone rq preparation to insert or merge

When invoked for an I/O request rq, the prepare_request hook of bfq increments reference counters in the destination bfq_queue for rq. In this respect, after this hook has been invoked, rq may still be transformed into a request with no icq attached, i.e., for bfq, a request not associated with

Re: rcu-bh design

Hi Steven, Just for a warning/disclaimer, I am new to RCU-land and trying to make sense ;-) So forgive me if something sounds too outlandish. On Fri, May 4, 2018 at 9:30 AM Steven Rostedt wrote: > On Fri, 04 May 2018 16:20:11 + > Joel Fernandes

Re: rcu-bh design

Hi Steven, Just for a warning/disclaimer, I am new to RCU-land and trying to make sense ;-) So forgive me if something sounds too outlandish. On Fri, May 4, 2018 at 9:30 AM Steven Rostedt wrote: > On Fri, 04 May 2018 16:20:11 + > Joel Fernandes wrote: > > Hi Paul, everyone, > > > > I had

Re: [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available

On Fri, May 04, 2018 at 10:07:53AM -0700, Florian Fainelli wrote: > On 05/04/2018 06:56 AM, Antoine Tenart wrote: > > In case no Tx disable pin is available the SFP modules will always be > > emitting. This could be an issue when using modules using laser as their > > light source as we would have

Re: [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available

On Fri, May 04, 2018 at 10:07:53AM -0700, Florian Fainelli wrote: > On 05/04/2018 06:56 AM, Antoine Tenart wrote: > > In case no Tx disable pin is available the SFP modules will always be > > emitting. This could be an issue when using modules using laser as their > > light source as we would have

Re: [PATCH] net: sched: cls: fix a potential missing-check bug

From: Wenwen Wang Date: Fri, 4 May 2018 02:05:05 -0500 > Given that gen_tunnel() may return a value larger than 255 based on > data, the new value of f->res.classid should be re-checked. gen_tunnel() may not ever return a value larger than 255. data->tgenerator is a u8 and

Re: [PATCH] net: sched: cls: fix a potential missing-check bug

From: Wenwen Wang Date: Fri, 4 May 2018 02:05:05 -0500 > Given that gen_tunnel() may return a value larger than 255 based on > data, the new value of f->res.classid should be re-checked. gen_tunnel() may not ever return a value larger than 255. data->tgenerator is a u8 and therefore can never

Re: [PATCH v2 2/2] ACPI: APD: Add AMD misc clock handler support

On 5/4/2018 4:37 PM, Rafael J. Wysocki wrote: > On Fri, May 4, 2018 at 12:23 PM, Agrawal, Akshu wrote: >> >> >> On 5/4/2018 3:45 PM, Rafael J. Wysocki wrote: >>> On Fri, May 4, 2018 at 12:09 PM, Agrawal, Akshu >>> wrote: On 5/4/2018

Re: [PATCH v2 2/2] ACPI: APD: Add AMD misc clock handler support

On 5/4/2018 4:37 PM, Rafael J. Wysocki wrote: > On Fri, May 4, 2018 at 12:23 PM, Agrawal, Akshu wrote: >> >> >> On 5/4/2018 3:45 PM, Rafael J. Wysocki wrote: >>> On Fri, May 4, 2018 at 12:09 PM, Agrawal, Akshu >>> wrote: On 5/4/2018 3:36 PM, Rafael J. Wysocki wrote: > On

Re: [PATCH] mtd: spi-nor: add support for Microchip 25LC256

On 05/04/2018 05:54 PM, Radu Pirea wrote: > Added geometry description for Microchip 25LC256 memory. Are you sure this is a SPI NOR ? I don't see any RDID instruction in the datasheet, only some 6 instructions to read/write the array and lock it. Isn't the AT25 driver a better fit for this EEPROM

Re: [PATCH] mtd: spi-nor: add support for Microchip 25LC256

On 05/04/2018 05:54 PM, Radu Pirea wrote: > Added geometry description for Microchip 25LC256 memory. Are you sure this is a SPI NOR ? I don't see any RDID instruction in the datasheet, only some 6 instructions to read/write the array and lock it. Isn't the AT25 driver a better fit for this EEPROM

Re: [PATCH v4 2/2] ThunderX2: Add Cavium ThunderX2 SoC UNCORE PMU driver

Hi Kim, On 04/05/18 01:30, Kim Phillips wrote: On Tue, 1 May 2018 12:54:05 +0100 Will Deacon wrote: Hi Kim, Hi Will, thanks for responding. On Fri, Apr 27, 2018 at 11:56:25AM -0500, Kim Phillips wrote: On Fri, 27 Apr 2018 17:09:14 +0100 Will Deacon

Re: [PATCH v4 2/2] ThunderX2: Add Cavium ThunderX2 SoC UNCORE PMU driver

Hi Kim, On 04/05/18 01:30, Kim Phillips wrote: On Tue, 1 May 2018 12:54:05 +0100 Will Deacon wrote: Hi Kim, Hi Will, thanks for responding. On Fri, Apr 27, 2018 at 11:56:25AM -0500, Kim Phillips wrote: On Fri, 27 Apr 2018 17:09:14 +0100 Will Deacon wrote: On Fri, Apr 27, 2018 at

[PATCH v3 1/2] clk: x86: Add ST oscout platform clock

Stoney SoC provides oscout clock. This clock can support 25Mhz and 48Mhz of frequency. The clock is available for general system use. Signed-off-by: Akshu Agrawal --- v2: config change, added SPDX tag and used clk_hw_register_. v3: Fix kbuild warning for checking of NULL

[PATCH v2 2/2] ACPI: APD: Add AMD misc clock handler support

AMD SoC exposes clock for general purpose use. The clock registration is done in clk-st driver. The MMIO mapping are passed on to the clock driver for accessing the registers. The misc clock handler will create MMIO mappings to access the clock registers and enable the clock driver to expose the

[PATCH v3 1/2] clk: x86: Add ST oscout platform clock

Stoney SoC provides oscout clock. This clock can support 25Mhz and 48Mhz of frequency. The clock is available for general system use. Signed-off-by: Akshu Agrawal --- v2: config change, added SPDX tag and used clk_hw_register_. v3: Fix kbuild warning for checking of NULL pointer

[PATCH v2 2/2] ACPI: APD: Add AMD misc clock handler support

AMD SoC exposes clock for general purpose use. The clock registration is done in clk-st driver. The MMIO mapping are passed on to the clock driver for accessing the registers. The misc clock handler will create MMIO mappings to access the clock registers and enable the clock driver to expose the

[PATCH 0/2] Add support for general system clock on ST AMD platform

AMD ST/CZ platform provides a general system clock which can be used by any driver. Registration of this clock will done in clk-st driver. While the ACPI misc device will create the required MMIO mappings and pass the same to the clk-st driver. The clk-st driver will use the address to

[PATCH 0/2] Add support for general system clock on ST AMD platform

AMD ST/CZ platform provides a general system clock which can be used by any driver. Registration of this clock will done in clk-st driver. While the ACPI misc device will create the required MMIO mappings and pass the same to the clk-st driver. The clk-st driver will use the address to

Re: [PATCH 0/8] Assorted rhashtable fixes and cleanups

From: NeilBrown Date: Fri, 04 May 2018 13:54:14 +1000 > This series contains some bugfixes, mostly minor though one > is worthy of a stable backport I think - tagged with Fixes and Cc: stable. > > Then there are improvements to walking, which have been discussed > to some degree

Re: [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available

On 05/04/2018 06:56 AM, Antoine Tenart wrote: > In case no Tx disable pin is available the SFP modules will always be > emitting. This could be an issue when using modules using laser as their > light source as we would have no way to disable it when the fiber is > removed. This patch adds a

Re: [PATCH 0/8] Assorted rhashtable fixes and cleanups

From: NeilBrown Date: Fri, 04 May 2018 13:54:14 +1000 > This series contains some bugfixes, mostly minor though one > is worthy of a stable backport I think - tagged with Fixes and Cc: stable. > > Then there are improvements to walking, which have been discussed > to some degree already. >

Re: [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available

On 05/04/2018 06:56 AM, Antoine Tenart wrote: > In case no Tx disable pin is available the SFP modules will always be > emitting. This could be an issue when using modules using laser as their > light source as we would have no way to disable it when the fiber is > removed. This patch adds a

Re: [PATCH] kernel/signal: Remove no longer required irqsave/restore

On 2018-05-04 11:59:08 [-0500], Eric W. Biederman wrote: > Sebastian Andrzej Siewior writes: > > From: Anna-Maria Gleixner … > > This long-term fix has been made in commit 4abf91047cf ("rtmutex: Make > > > wait_lock irq safe") for different

Re: [PATCH] kernel/signal: Remove no longer required irqsave/restore

On 2018-05-04 11:59:08 [-0500], Eric W. Biederman wrote: > Sebastian Andrzej Siewior writes: > > From: Anna-Maria Gleixner … > > This long-term fix has been made in commit 4abf91047cf ("rtmutex: Make > > > wait_lock irq safe") for different reason. > > Which tree has this change been made in?

Re: [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors

On 05/04/2018 06:56 AM, Antoine Tenart wrote: > SFP connectors can be solder on a board without having any of their pins > (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed, > and the overall link status reporting is left to other layers. > > In order to achieve this, a new

Re: [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors

On 05/04/2018 06:56 AM, Antoine Tenart wrote: > SFP connectors can be solder on a board without having any of their pins > (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed, > and the overall link status reporting is left to other layers. > > In order to achieve this, a new

Re: [PATCH net-next v2 01/13] net: phy: sfp: make the i2c-bus property really optional

On 05/04/2018 06:56 AM, Antoine Tenart wrote: > The SFF,SFP documentation is clear about making all the DT properties, > with the exception of the compatible, optional. In practice this is not > the case and without an i2c-bus property provided the SFP code will > throw NULL pointer exceptions. >

Re: [PATCH net-next v2 01/13] net: phy: sfp: make the i2c-bus property really optional

On 05/04/2018 06:56 AM, Antoine Tenart wrote: > The SFF,SFP documentation is clear about making all the DT properties, > with the exception of the compatible, optional. In practice this is not > the case and without an i2c-bus property provided the SFP code will > throw NULL pointer exceptions. >

Re: perf: fuzzer causes stack going in wrong direction warnings

On Fri, 4 May 2018, Josh Poimboeuf wrote: > Also, any tips for reproducing this locally? I cloned the perf fuzzer > github. Is it as simple as just "make" and "./run_tests.sh"? run_tests only runs the perf_event regressiong tests. To run the fuzzer, enter the "fuzzer" directory and either run

Re: perf: fuzzer causes stack going in wrong direction warnings

On Fri, 4 May 2018, Josh Poimboeuf wrote: > Also, any tips for reproducing this locally? I cloned the perf fuzzer > github. Is it as simple as just "make" and "./run_tests.sh"? run_tests only runs the perf_event regressiong tests. To run the fuzzer, enter the "fuzzer" directory and either run

[PATCH] gpio: pca953x: Clear irq trigger type on irq shutdown

The driver stores the result of irq_set_type() in the internal variables irq_trig_raise and irq_trig_fall, which later are used to determine the GPIOs that must be re-configured as input. These variables retain their value between gpiolib's export / unexport, resulting in an incorrect state in

Re: [PATCH] kernel/signal: Remove no longer required irqsave/restore

Sebastian Andrzej Siewior writes: > From: Anna-Maria Gleixner > > Commit a841796f11c9 ("signal: align __lock_task_sighand() irq disabling and > RCU") introduced a rcu read side critical section with interrupts > disabled. The changelog suggested

[PATCH] gpio: pca953x: Clear irq trigger type on irq shutdown

The driver stores the result of irq_set_type() in the internal variables irq_trig_raise and irq_trig_fall, which later are used to determine the GPIOs that must be re-configured as input. These variables retain their value between gpiolib's export / unexport, resulting in an incorrect state in

Re: [PATCH] kernel/signal: Remove no longer required irqsave/restore

Sebastian Andrzej Siewior writes: > From: Anna-Maria Gleixner > > Commit a841796f11c9 ("signal: align __lock_task_sighand() irq disabling and > RCU") introduced a rcu read side critical section with interrupts > disabled. The changelog suggested that a better long-term fix would be "to > make

Re: [PATCH] ALSA: pcm: Hide local_irq_disable/enable() and local_irqsave/restore()

On Fri, 04 May 2018 17:28:10 +0200, Sebastian Andrzej Siewior wrote: > > From: Anna-Maria Gleixner > > The snd_pcm_stream_lock_irq*() functions decouple disabling interrupts > from the actual locking process. This does not work as expected if the > locking primitives

Re: [PATCH] ALSA: pcm: Hide local_irq_disable/enable() and local_irqsave/restore()

On Fri, 04 May 2018 17:28:10 +0200, Sebastian Andrzej Siewior wrote: > > From: Anna-Maria Gleixner > > The snd_pcm_stream_lock_irq*() functions decouple disabling interrupts > from the actual locking process. This does not work as expected if the > locking primitives are replaced like on

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