Re: [PATCH v6 0/5] clk: Add Aspeed clock driver

Hello clk maintainers, Has anyone had a chance to review these patches? On Tue, Nov 28, 2017 at 5:49 PM, Joel Stanley wrote: > This driver supports the ast2500, ast2400 (and derivative) BMC SoCs from > Aspeed. > > This is v6. See patches for detailed changelogs. > > v6: Added

Re: [PATCH v6 0/5] clk: Add Aspeed clock driver

Hello clk maintainers, Has anyone had a chance to review these patches? On Tue, Nov 28, 2017 at 5:49 PM, Joel Stanley wrote: > This driver supports the ast2500, ast2400 (and derivative) BMC SoCs from > Aspeed. > > This is v6. See patches for detailed changelogs. > > v6: Added reviewed-bys > v5:

Re: [PATCH] [linux][master][v1] misc: Add Xilinx ZYNQMP VCU logicoreIP init driver

On Wed, Dec 06, 2017 at 06:01:37AM +, Dhaval Rajeshbhai Shah wrote: > Hi Greg k-h, > > Thanks a lot for the review. > > Replies inline. As they should be, perhaps you need a better email client :) > > > +config XILINX_VCU > > + tristate "Xilinx VCU Init" > > + default n > >

Re: [PATCH] [linux][master][v1] misc: Add Xilinx ZYNQMP VCU logicoreIP init driver

On Wed, Dec 06, 2017 at 06:01:37AM +, Dhaval Rajeshbhai Shah wrote: > Hi Greg k-h, > > Thanks a lot for the review. > > Replies inline. As they should be, perhaps you need a better email client :) > > > +config XILINX_VCU > > + tristate "Xilinx VCU Init" > > + default n > >

Re: [PATCH V2] clk: fix a panic error caused by accessing NULL pointer

On 6 December 2017 at 07:28, Stephen Boyd wrote: > On 11/21, Chunyan Zhang wrote: >> From: Cai Li >> >> In some cases the clock parent would be set NULL when doing re-parent, >> it will cause a NULL pointer accessing if clk_set trace event is >>

Re: [PATCH V2] clk: fix a panic error caused by accessing NULL pointer

On 6 December 2017 at 07:28, Stephen Boyd wrote: > On 11/21, Chunyan Zhang wrote: >> From: Cai Li >> >> In some cases the clock parent would be set NULL when doing re-parent, >> it will cause a NULL pointer accessing if clk_set trace event is >> enabled. >> >> This patch sets the parent as

Re: Multiple oom_reaper BUGs: unmap_page_range racing with exit_mmap

On Wed, 6 Dec 2017, Tetsuo Handa wrote: > > > One way to solve the issue is to have two mm flags: one to indicate the > > > mm > > > is entering unmap_vmas(): set the flag, do down_write(>mmap_sem); > > > up_write(>mmap_sem), then unmap_vmas(). The oom reaper needs this > > > flag clear, not

Re: Multiple oom_reaper BUGs: unmap_page_range racing with exit_mmap

On Wed, 6 Dec 2017, Tetsuo Handa wrote: > > > One way to solve the issue is to have two mm flags: one to indicate the > > > mm > > > is entering unmap_vmas(): set the flag, do down_write(>mmap_sem); > > > up_write(>mmap_sem), then unmap_vmas(). The oom reaper needs this > > > flag clear, not

Re: [PATCH 4.4 02/96] s390/runtime instrumention: fix possible memory corruption

On Tue, Dec 05, 2017 at 07:15:34PM +0100, Heiko Carstens wrote: > On Tue, Dec 05, 2017 at 06:08:47PM +0100, Greg Kroah-Hartman wrote: > > On Tue, Dec 05, 2017 at 05:02:32PM +, Ben Hutchings wrote: > > > On Tue, 2017-11-28 at 11:22 +0100, Greg Kroah-Hartman wrote: > > > > 4.4-stable review

Re: [PATCH 4.4 02/96] s390/runtime instrumention: fix possible memory corruption

On Tue, Dec 05, 2017 at 07:15:34PM +0100, Heiko Carstens wrote: > On Tue, Dec 05, 2017 at 06:08:47PM +0100, Greg Kroah-Hartman wrote: > > On Tue, Dec 05, 2017 at 05:02:32PM +, Ben Hutchings wrote: > > > On Tue, 2017-11-28 at 11:22 +0100, Greg Kroah-Hartman wrote: > > > > 4.4-stable review

Re: [PATCH] clk: fix a panic error caused by accessing NULL pointer

On 6 December 2017 at 07:28, Stephen Boyd wrote: > On 11/21, Chunyan Zhang wrote: >> On 21 November 2017 at 16:57, Chunyan Zhang wrote: >> > On 21 November 2017 at 03:12, Stephen Boyd wrote: >> >> On 11/20, Chunyan Zhang wrote:

Re: [PATCH] clk: fix a panic error caused by accessing NULL pointer

On 6 December 2017 at 07:28, Stephen Boyd wrote: > On 11/21, Chunyan Zhang wrote: >> On 21 November 2017 at 16:57, Chunyan Zhang wrote: >> > On 21 November 2017 at 03:12, Stephen Boyd wrote: >> >> On 11/20, Chunyan Zhang wrote: >> >>> From: Cai Li >> >>> >> >>> In some cases the clock parent

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On 12/06/2017 08:33 AM, John Hubbard wrote: In that case, maybe: MAP_EXACT ? ...because that's the characteristic behavior. Is that true? mmap still silently rounding up the length to the page size, I assume, so even that name is misleading. Thanks, Florian

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On 12/06/2017 08:33 AM, John Hubbard wrote: In that case, maybe: MAP_EXACT ? ...because that's the characteristic behavior. Is that true? mmap still silently rounding up the length to the page size, I assume, so even that name is misleading. Thanks, Florian

Re: [PATCH] doc: convert printk-formats.txt to rst

On Wed, 2017-12-06 at 08:11 +0100, Markus Heiser wrote: > > Am 06.12.2017 um 02:45 schrieb Tobin C. Harding : > > Documentation/printk-formats.txt is a candidate for conversion to > > ReStructuredText format. Some effort has already been made to do this > > conversion even thought

Re: [PATCH] doc: convert printk-formats.txt to rst

On Wed, 2017-12-06 at 08:11 +0100, Markus Heiser wrote: > > Am 06.12.2017 um 02:45 schrieb Tobin C. Harding : > > Documentation/printk-formats.txt is a candidate for conversion to > > ReStructuredText format. Some effort has already been made to do this > > conversion even thought the suffix is

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On 12/05/2017 11:03 PM, Matthew Wilcox wrote: > On Tue, Dec 05, 2017 at 08:54:35PM -0800, Matthew Wilcox wrote: >> On Wed, Dec 06, 2017 at 03:51:44PM +1100, Michael Ellerman wrote: >>> Cyril Hrubis writes: >>> Hi! >> MAP_FIXED_UNIQUE >> MAP_FIXED_ONCE >>

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On 12/05/2017 11:03 PM, Matthew Wilcox wrote: > On Tue, Dec 05, 2017 at 08:54:35PM -0800, Matthew Wilcox wrote: >> On Wed, Dec 06, 2017 at 03:51:44PM +1100, Michael Ellerman wrote: >>> Cyril Hrubis writes: >>> Hi! >> MAP_FIXED_UNIQUE >> MAP_FIXED_ONCE >> MAP_FIXED_FRESH >

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On 2017-12-06 05:50, Michael Ellerman wrote: > Michal Hocko writes: > >> On Wed 29-11-17 14:25:36, Kees Cook wrote: >> It is safe in a sense it doesn't perform any address space dangerous >> operations. mmap is _inherently_ about the address space so the context >> should be

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On 2017-12-06 05:50, Michael Ellerman wrote: > Michal Hocko writes: > >> On Wed 29-11-17 14:25:36, Kees Cook wrote: >> It is safe in a sense it doesn't perform any address space dangerous >> operations. mmap is _inherently_ about the address space so the context >> should be kind of clear. > >

[PATCH v6 3/6] kernel/reboot.c: export pm_power_off_prepare

Export pm_power_off_prepare. It is needed to implement power off on Freescale/NXP iMX6 based boards with external power management integrated circuit (PMIC). Signed-off-by: Oleksij Rempel --- kernel/reboot.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v6 3/6] kernel/reboot.c: export pm_power_off_prepare

Export pm_power_off_prepare. It is needed to implement power off on Freescale/NXP iMX6 based boards with external power management integrated circuit (PMIC). Signed-off-by: Oleksij Rempel --- kernel/reboot.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/reboot.c b/kernel/reboot.c

[PATCH RESEND v6 0/6] provide power off support for iMX6 with external PMIC

2017.12.06: Adding Linus. Probably there is no maintainer for this patch set. No changes are made, tested on v4.15-rc1. 2017.10.27: Last version of this patch set was send at 20 Jun 2017, this is a rebase against kernel v4.14-rc6. Probably this set got lost. If I forgot to address some comments,

[PATCH v6 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set

One of the Freescale recommended sequences for power off with external PMIC is the following: ... 3. SoC is programming PMIC for power off when standby is asserted. 4. In CCM STOP mode, Standby is asserted, PMIC gates SoC supplies. See:

[PATCH v6 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set

One of the Freescale recommended sequences for power off with external PMIC is the following: ... 3. SoC is programming PMIC for power off when standby is asserted. 4. In CCM STOP mode, Standby is asserted, PMIC gates SoC supplies. See:

[PATCH RESEND v6 0/6] provide power off support for iMX6 with external PMIC

2017.12.06: Adding Linus. Probably there is no maintainer for this patch set. No changes are made, tested on v4.15-rc1. 2017.10.27: Last version of this patch set was send at 20 Jun 2017, this is a rebase against kernel v4.14-rc6. Probably this set got lost. If I forgot to address some comments,

[PATCH v6 5/6] regulator: pfuze100-regulator: provide pm_power_off_prepare handler

On some boards the SoC can use one pin "PMIC_STBY_REQ" to notify th PMIC about state changes. In this case internal state of PMIC must be preconfigured for upcomming state change. It works fine with the current regulator framework, except with the power-off case. This patch is providing an

[PATCH v6 4/6] regulator: pfuze100: add fsl,pmic-stby-poweroff property

Document the new optional "fsl,pmic-stby-poweroff" property. Signed-off-by: Oleksij Rempel Acked-by: Rob Herring --- Documentation/devicetree/bindings/regulator/pfuze100.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git

[PATCH v6 1/6] ARM: imx6q: provide documentation for new fsl,pmic-stby-poweroff property

Signed-off-by: Oleksij Rempel Acked-by: Rob Herring --- Documentation/devicetree/bindings/clock/imx6q-clock.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt

[PATCH v6 1/6] ARM: imx6q: provide documentation for new fsl,pmic-stby-poweroff property

Signed-off-by: Oleksij Rempel Acked-by: Rob Herring --- Documentation/devicetree/bindings/clock/imx6q-clock.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt index

[PATCH v6 5/6] regulator: pfuze100-regulator: provide pm_power_off_prepare handler

On some boards the SoC can use one pin "PMIC_STBY_REQ" to notify th PMIC about state changes. In this case internal state of PMIC must be preconfigured for upcomming state change. It works fine with the current regulator framework, except with the power-off case. This patch is providing an

[PATCH v6 4/6] regulator: pfuze100: add fsl,pmic-stby-poweroff property

Document the new optional "fsl,pmic-stby-poweroff" property. Signed-off-by: Oleksij Rempel Acked-by: Rob Herring --- Documentation/devicetree/bindings/regulator/pfuze100.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt

[PATCH v6 6/6] ARM: dts: imx6: RIoTboard provide standby on power off option

This board, as well as some other boards with i.MX6 and a PMIC, uses a "PMIC_STBY_REQ" line to notify the PMIC about a state change. The PMIC is programmed for a specific state change before triggering the line. In this case, PMIC_STBY_REQ can be used for stand by, sleep and power off modes.

[PATCH v6 6/6] ARM: dts: imx6: RIoTboard provide standby on power off option

This board, as well as some other boards with i.MX6 and a PMIC, uses a "PMIC_STBY_REQ" line to notify the PMIC about a state change. The PMIC is programmed for a specific state change before triggering the line. In this case, PMIC_STBY_REQ can be used for stand by, sleep and power off modes.

Re: [PATCH] doc: convert printk-formats.txt to rst

> Am 06.12.2017 um 02:45 schrieb Tobin C. Harding : > > Documentation/printk-formats.txt is a candidate for conversion to > ReStructuredText format. Some effort has already been made to do this > conversion even thought the suffix is currently .txt > > Changes required to

Re: [PATCH] doc: convert printk-formats.txt to rst

> Am 06.12.2017 um 02:45 schrieb Tobin C. Harding : > > Documentation/printk-formats.txt is a candidate for conversion to > ReStructuredText format. Some effort has already been made to do this > conversion even thought the suffix is currently .txt > > Changes required to complete conversion >

Re: [PATCH v4 1/3] drm/bridge/synopsys: dsi: stop clobbering drvdata

Hi Brian, On 2017年12月06日 02:56, Brian Norris wrote: Hi Nickey, On Tue, Dec 05, 2017 at 05:14:11PM +0800, Nickey Yang wrote: On 2017年12月01日 18:07, Philippe CORNU wrote: On 12/01/2017 10:11 AM, Nickey Yang wrote: On 2017年12月01日 16:32, Philippe CORNU wrote: I am sorry to say that but you can

Re: [PATCH v4 1/3] drm/bridge/synopsys: dsi: stop clobbering drvdata

Hi Brian, On 2017年12月06日 02:56, Brian Norris wrote: Hi Nickey, On Tue, Dec 05, 2017 at 05:14:11PM +0800, Nickey Yang wrote: On 2017年12月01日 18:07, Philippe CORNU wrote: On 12/01/2017 10:11 AM, Nickey Yang wrote: On 2017年12月01日 16:32, Philippe CORNU wrote: I am sorry to say that but you can

[PATCH] sched/wait: fix add_wait_queue() behavior change

From: Omar Sandoval Commit 50816c48997a ("sched/wait: Standardize internal naming of wait-queue entries") changed the behavior of add_wait_queue() from inserting the wait entry at the head of the wait queue to the tail of the wait queue. That commit was a cleanup and didn't

[PATCH] sched/wait: fix add_wait_queue() behavior change

From: Omar Sandoval Commit 50816c48997a ("sched/wait: Standardize internal naming of wait-queue entries") changed the behavior of add_wait_queue() from inserting the wait entry at the head of the wait queue to the tail of the wait queue. That commit was a cleanup and didn't mention any

Re: rsi_91x: Failed to read status register on failed authentication

On Tue, Dec 5, 2017 at 9:41 PM, Alexey Brodkin wrote: > Hi Amit, > > I'm seeing quite a strange behavior of RedPine module. > It connects perfectly fine to one of access points but fails > to connect to another. > > Moreover after that failure RSI driver starts to

Re: rsi_91x: Failed to read status register on failed authentication

On Tue, Dec 5, 2017 at 9:41 PM, Alexey Brodkin wrote: > Hi Amit, > > I'm seeing quite a strange behavior of RedPine module. > It connects perfectly fine to one of access points but fails > to connect to another. > > Moreover after that failure RSI driver starts to flood me with > messages saying:

RE: [Bug fix] octeon-i2c driver updates

Hi David, In fact, in current octeon_i2c_probe(), there has the bus reset unconditionally, It is reset by octeon_i2c_init_lowlevel() unconditionally. In my patch, I replace it by octeon_i2c_recovery(), which will be executed under three conditions. + /* +* Try to recover bus in

RE: [Bug fix] octeon-i2c driver updates

Hi David, In fact, in current octeon_i2c_probe(), there has the bus reset unconditionally, It is reset by octeon_i2c_init_lowlevel() unconditionally. In my patch, I replace it by octeon_i2c_recovery(), which will be executed under three conditions. + /* +* Try to recover bus in

[PATCH] Staging: rtl8192u: Fix no spaces around '+'

Added spaces around '+'. Warning found using checkpatch.pl --- drivers/staging/rtl8192u/ieee80211/dot11d.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8192u/ieee80211/dot11d.c b/drivers/staging/rtl8192u/ieee80211/dot11d.c index 64b13a5..ba284bf 100644

[PATCH] Staging: rtl8192u: Fix no spaces around '+'

Added spaces around '+'. Warning found using checkpatch.pl --- drivers/staging/rtl8192u/ieee80211/dot11d.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8192u/ieee80211/dot11d.c b/drivers/staging/rtl8192u/ieee80211/dot11d.c index 64b13a5..ba284bf 100644

[PATCH] MIPS: Octeon: Fix logging messages with spurious periods after newlines

Using a period after a newline causes bad output. Signed-off-by: Joe Perches --- arch/mips/cavium-octeon/octeon-irq.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/mips/cavium-octeon/octeon-irq.c b/arch/mips/cavium-octeon/octeon-irq.c

[PATCH] MIPS: Octeon: Fix logging messages with spurious periods after newlines

Using a period after a newline causes bad output. Signed-off-by: Joe Perches --- arch/mips/cavium-octeon/octeon-irq.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/mips/cavium-octeon/octeon-irq.c b/arch/mips/cavium-octeon/octeon-irq.c index

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On Tue, Dec 05, 2017 at 08:54:35PM -0800, Matthew Wilcox wrote: > On Wed, Dec 06, 2017 at 03:51:44PM +1100, Michael Ellerman wrote: > > Cyril Hrubis writes: > > > > > Hi! > > >> > MAP_FIXED_UNIQUE > > >> > MAP_FIXED_ONCE > > >> > MAP_FIXED_FRESH > > >> > > >> Well, I can open a

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On Tue, Dec 05, 2017 at 08:54:35PM -0800, Matthew Wilcox wrote: > On Wed, Dec 06, 2017 at 03:51:44PM +1100, Michael Ellerman wrote: > > Cyril Hrubis writes: > > > > > Hi! > > >> > MAP_FIXED_UNIQUE > > >> > MAP_FIXED_ONCE > > >> > MAP_FIXED_FRESH > > >> > > >> Well, I can open a poll for the

Re: [PATCH] ARM: dts: introduce the sama5d2 ptc ek board

On Tue, Dec 05, 2017 at 07:01:41PM +0200, Baruch Siach wrote: > Hi Ludovic, > > On Tue, Dec 05, 2017 at 03:23:12PM +0100, Ludovic Desroches wrote: > > Add the official SAMA5D2 Peripheral Touch Controller Evaluation > > Kit board. > > > > Signed-off-by: Ludovic Desroches

Re: [PATCH] ARM: dts: introduce the sama5d2 ptc ek board

On Tue, Dec 05, 2017 at 07:01:41PM +0200, Baruch Siach wrote: > Hi Ludovic, > > On Tue, Dec 05, 2017 at 03:23:12PM +0100, Ludovic Desroches wrote: > > Add the official SAMA5D2 Peripheral Touch Controller Evaluation > > Kit board. > > > > Signed-off-by: Ludovic Desroches > > --- > > [...] > >

[PATCH V2] ARM: dts: introduce the sama5d2 ptc ek board

Add the official SAMA5D2 Peripheral Touch Controller Evaluation Kit board. Signed-off-by: Ludovic Desroches --- Changes: - v2: - remove memory node - use SPDX-License-Identifier arch/arm/boot/dts/Makefile| 1 +

[PATCH V2] ARM: dts: introduce the sama5d2 ptc ek board

Add the official SAMA5D2 Peripheral Touch Controller Evaluation Kit board. Signed-off-by: Ludovic Desroches --- Changes: - v2: - remove memory node - use SPDX-License-Identifier arch/arm/boot/dts/Makefile| 1 + arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts | 402

Re: [PATCH] usb: dwc2: add optional usb ecc reset bit

On 11/01/2017 08:35 AM, Dinh Nguyen wrote: > The dwc2 USB controller in Stratix10 has an additional ECC reset bit that > needs to get de-asserted in order for the controller to work properly. > > Signed-off-by: Dinh Nguyen > --- > drivers/usb/dwc2/core.h | 1 + >

Re: [PATCH] usb: dwc2: add optional usb ecc reset bit

On 11/01/2017 08:35 AM, Dinh Nguyen wrote: > The dwc2 USB controller in Stratix10 has an additional ECC reset bit that > needs to get de-asserted in order for the controller to work properly. > > Signed-off-by: Dinh Nguyen > --- > drivers/usb/dwc2/core.h | 1 + > drivers/usb/dwc2/platform.c

A kernel warning will be triggered,during copy a big file into zstd compressed btrfs filesystem

Hi all, I have found a kernel warning of btrfs ,during run my shell script in qemu qemu virtual machine. Linux mainline version Linux 4.15-rc2 (ae64f9bd) The script try to copy a big file(15G) into btrfs filesystem,when I login virtual machine,then run the script,A kernel warning will be

A kernel warning will be triggered,during copy a big file into zstd compressed btrfs filesystem

Hi all, I have found a kernel warning of btrfs ,during run my shell script in qemu qemu virtual machine. Linux mainline version Linux 4.15-rc2 (ae64f9bd) The script try to copy a big file(15G) into btrfs filesystem,when I login virtual machine,then run the script,A kernel warning will be

Re: [PATCH 4.14 00/95] 4.14.4-stable review

On Wed, Dec 06, 2017 at 07:49:49AM +0100, Greg Kroah-Hartman wrote: > Don't fall down the trap of running code for the sake of running code > (i.e. like that web site that starts with a P) that doesn't actually > test anything that actually matters. I forgot to add: Especially when there are

Re: [PATCH 4.14 00/95] 4.14.4-stable review

On Wed, Dec 06, 2017 at 07:49:49AM +0100, Greg Kroah-Hartman wrote: > Don't fall down the trap of running code for the sake of running code > (i.e. like that web site that starts with a P) that doesn't actually > test anything that actually matters. I forgot to add: Especially when there are

Re: [PATCH 4.14 00/95] 4.14.4-stable review

On Tue, Dec 05, 2017 at 03:45:07PM -0600, Tom Gall wrote: > > > > On Dec 5, 2017, at 12:24 AM, Greg Kroah-Hartman > > wrote: > > > > On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote: > >> > >> > >>> On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman > >>>

Re: [PATCH 4.14 00/95] 4.14.4-stable review

On Tue, Dec 05, 2017 at 03:45:07PM -0600, Tom Gall wrote: > > > > On Dec 5, 2017, at 12:24 AM, Greg Kroah-Hartman > > wrote: > > > > On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote: > >> > >> > >>> On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman > >>> wrote: > >>> > >>> This is

Re: [PATCH] bfa: fix access to bfad_im_port_s

On Tue, 2017-11-28 at 16:26 +0100, Johannes Thumshirn wrote: > Commit 'cd21c605b2cf ("scsi: fc: provide fc_bsg_to_shost() helper")' > changed access to bfa's 'struct bfad_im_port_s' by using shost_priv() > instead of shost->hostdata[0]. > > This lead to crashes like in the following back-trace: >

Re: [PATCH] bfa: fix access to bfad_im_port_s

On Tue, 2017-11-28 at 16:26 +0100, Johannes Thumshirn wrote: > Commit 'cd21c605b2cf ("scsi: fc: provide fc_bsg_to_shost() helper")' > changed access to bfa's 'struct bfad_im_port_s' by using shost_priv() > instead of shost->hostdata[0]. > > This lead to crashes like in the following back-trace: >

[PATCH] usb: xhci: fix TDS for MTK xHCI1.1

For MTK's xHCI 1.0 or latter, TD size is the number of max packet sized packets remaining in the TD, not including this TRB (following spec). For MTK's xHCI 0.96 and older, TD size is the number of max packet sized packets remaining in the TD, including this TRB (not following spec).

[PATCH] usb: xhci: fix TDS for MTK xHCI1.1

For MTK's xHCI 1.0 or latter, TD size is the number of max packet sized packets remaining in the TD, not including this TRB (following spec). For MTK's xHCI 0.96 and older, TD size is the number of max packet sized packets remaining in the TD, including this TRB (not following spec).

[PATCH] xen-netback: Fix logging message with spurious period after newline

Using a period after a newline causes bad output. Signed-off-by: Joe Perches --- drivers/net/xen-netback/interface.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c index

[PATCH] xen-netback: Fix logging message with spurious period after newline

Using a period after a newline causes bad output. Signed-off-by: Joe Perches --- drivers/net/xen-netback/interface.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c index d6dff347f896..78ebe494fef0

Re: [PATCH] usb: core: Fix logging messages with spurious periods after newlines

On Wed, 2017-12-06 at 07:27 +0100, Greg Kroah-Hartman wrote: > On Tue, Dec 05, 2017 at 10:22:05PM -0800, Joe Perches wrote: > > Using a period after a newline causes bad output. > > Nice catch, how did you find that? $ git grep '\\n\."'

Re: [PATCH] usb: core: Fix logging messages with spurious periods after newlines

On Wed, 2017-12-06 at 07:27 +0100, Greg Kroah-Hartman wrote: > On Tue, Dec 05, 2017 at 10:22:05PM -0800, Joe Perches wrote: > > Using a period after a newline causes bad output. > > Nice catch, how did you find that? $ git grep '\\n\."'

Re: [PATCH] efi: move some sysfs files to be read-only by root

On Wed, Dec 06, 2017 at 07:50:41AM +1100, Tobin C. Harding wrote: > On Tue, Dec 05, 2017 at 11:13:43AM +0100, Greg Kroah-Hartman wrote: > > Thanks to the scripts/leaking_addresses.pl script, it was found that > > some EFI values should not be readable by non-root users. > > > > So make them

Re: [PATCH] efi: move some sysfs files to be read-only by root

On Wed, Dec 06, 2017 at 07:50:41AM +1100, Tobin C. Harding wrote: > On Tue, Dec 05, 2017 at 11:13:43AM +0100, Greg Kroah-Hartman wrote: > > Thanks to the scripts/leaking_addresses.pl script, it was found that > > some EFI values should not be readable by non-root users. > > > > So make them

Re: [PATCH] driver-core: platform: Avoid to return IRQ 0 in platform_get_irq()

Hi Dmitry, On Tuesday 05 December 2017 11:50 PM, Dmitry Torokhov wrote: On Tue, Dec 05, 2017 at 11:41:52PM +0530, Arvind Yadav wrote: Function platform_get_irq() can return 0. Which means NO_IRQ. So this change will not allow to return 0. This change is help to use platform_get_irq() without

Re: [PATCH] driver-core: platform: Avoid to return IRQ 0 in platform_get_irq()

Hi Dmitry, On Tuesday 05 December 2017 11:50 PM, Dmitry Torokhov wrote: On Tue, Dec 05, 2017 at 11:41:52PM +0530, Arvind Yadav wrote: Function platform_get_irq() can return 0. Which means NO_IRQ. So this change will not allow to return 0. This change is help to use platform_get_irq() without

Re: [PATCH v6 2/2] staging: ion: create one device entry per heap

On Tue, Dec 05, 2017 at 03:01:42PM -0800, Laura Abbott wrote: > On 12/02/2017 07:53 AM, Greg KH wrote: > > > This is one of the item in the TODO list before been able to unstage ION > > > which is my real need. > > Why does it matter where in the tree this code is? Don't go adding new > > things

Re: [PATCH v6 2/2] staging: ion: create one device entry per heap

On Tue, Dec 05, 2017 at 03:01:42PM -0800, Laura Abbott wrote: > On 12/02/2017 07:53 AM, Greg KH wrote: > > > This is one of the item in the TODO list before been able to unstage ION > > > which is my real need. > > Why does it matter where in the tree this code is? Don't go adding new > > things

Re: [PATCH] usb: core: Fix logging messages with spurious periods after newlines

On Tue, Dec 05, 2017 at 10:22:05PM -0800, Joe Perches wrote: > Using a period after a newline causes bad output. Nice catch, how did you find that? thanks, greg k-h

Re: [PATCH] usb: core: Fix logging messages with spurious periods after newlines

On Tue, Dec 05, 2017 at 10:22:05PM -0800, Joe Perches wrote: > Using a period after a newline causes bad output. Nice catch, how did you find that? thanks, greg k-h

Re: In kernel power management domain_pm created for async schedules

On Wed, Dec 06, 2017 at 05:38:31AM +, Vikas Bansal wrote: > If there is a driver in system which starts creating async schedules just > after resume (Same as our case, in which we faced issue). Then > async_synchronize_full API in PM cores starts waiting for completion of async > schedules

Re: In kernel power management domain_pm created for async schedules

On Wed, Dec 06, 2017 at 05:38:31AM +, Vikas Bansal wrote: > If there is a driver in system which starts creating async schedules just > after resume (Same as our case, in which we faced issue). Then > async_synchronize_full API in PM cores starts waiting for completion of async > schedules

[PATCH] usb: core: Fix logging messages with spurious periods after newlines

Using a period after a newline causes bad output. Miscellanea: o Coalesce formats too Signed-off-by: Joe Perches --- drivers/usb/core/driver.c | 8 drivers/usb/core/hub.c | 17 +++-- drivers/usb/core/message.c | 6 +++--- 3 files changed, 14

[PATCH] usb: core: Fix logging messages with spurious periods after newlines

Using a period after a newline causes bad output. Miscellanea: o Coalesce formats too Signed-off-by: Joe Perches --- drivers/usb/core/driver.c | 8 drivers/usb/core/hub.c | 17 +++-- drivers/usb/core/message.c | 6 +++--- 3 files changed, 14 insertions(+), 17

Re: [PATCH] usb: dwc2: Fix TxFIFOn sizes and total TxFIFO size issues

On 11/30/2017 12:16 AM, Minas Harutyunyan wrote: > In host mode reading from DPTXSIZn returning invalid value in > dwc2_check_param_tx_fifo_sizes function. > > In total TxFIFO size calculations unnecessarily reducing by ep_info. > hw->total_fifo_size can be fully allocated for FIFO's. > > Added

Re: [PATCH] usb: dwc2: Fix TxFIFOn sizes and total TxFIFO size issues

On 11/30/2017 12:16 AM, Minas Harutyunyan wrote: > In host mode reading from DPTXSIZn returning invalid value in > dwc2_check_param_tx_fifo_sizes function. > > In total TxFIFO size calculations unnecessarily reducing by ep_info. > hw->total_fifo_size can be fully allocated for FIFO's. > > Added

drivers/nvme/target/fcloop.c:1080:9: warning: 'tport' may be used uninitialized in this function

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 328b4ed93b69a6f2083d52f31a240a09e5de386a commit: fddc9923c6d41de9fe7b1f323a3cece53e046c88 nvme-fcloop: fix port deletes and callbacks date: 2 months ago config: i386-randconfig-h1-12061225 (attached as

drivers/nvme/target/fcloop.c:1080:9: warning: 'tport' may be used uninitialized in this function

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 328b4ed93b69a6f2083d52f31a240a09e5de386a commit: fddc9923c6d41de9fe7b1f323a3cece53e046c88 nvme-fcloop: fix port deletes and callbacks date: 2 months ago config: i386-randconfig-h1-12061225 (attached as

Re: [PATCH v3 1/2] usb: dwc2: host: Don't retry NAKed transactions right away

On 12/05/2017 08:18 AM, Stefan Wahren wrote: > Hi Felipe, > Hi John, > > > Am 30.10.2017 um 18:08 schrieb Douglas Anderson: >> On rk3288-veyron devices on Chrome OS it was found that plugging in an >> Arduino-based USB device could cause the system to lockup, especially >> if the CPU Frequency was

Re: [PATCH v3 1/2] usb: dwc2: host: Don't retry NAKed transactions right away

On 12/05/2017 08:18 AM, Stefan Wahren wrote: > Hi Felipe, > Hi John, > > > Am 30.10.2017 um 18:08 schrieb Douglas Anderson: >> On rk3288-veyron devices on Chrome OS it was found that plugging in an >> Arduino-based USB device could cause the system to lockup, especially >> if the CPU Frequency was

[PATCH v2] drm: rcar-du: calculate DPLLCR to be more small jitter

From: Kuninori Morimoto In general, PLL has VCO (= Voltage controlled oscillator), one of the very important electronic feature called as "jitter" is related to this VCO. In academic generalism, VCO should be maximum to be more small jitter. In high frequency

[PATCH v2] drm: rcar-du: calculate DPLLCR to be more small jitter

From: Kuninori Morimoto In general, PLL has VCO (= Voltage controlled oscillator), one of the very important electronic feature called as "jitter" is related to this VCO. In academic generalism, VCO should be maximum to be more small jitter. In high frequency clock, jitter will be large impact.

Re: [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver

Hello, > -Original Message- > From: Mark Brown [mailto:broo...@kernel.org] > Sent: Tuesday, December 5, 2017 9:15 PM > To: Suzuki, Katsuhiro/鈴木 勝博 > Cc: alsa-de...@alsa-project.org; Rob Herring ; > devicet...@vger.kernel.org; Yamada,

Re: [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver

Hello, > -Original Message- > From: Mark Brown [mailto:broo...@kernel.org] > Sent: Tuesday, December 5, 2017 9:15 PM > To: Suzuki, Katsuhiro/鈴木 勝博 > Cc: alsa-de...@alsa-project.org; Rob Herring ; > devicet...@vger.kernel.org; Yamada, Masahiro/山田 真弘 > ; Masami Hiramatsu > ; Jassi Brar ; >

Re: Sending 802.1Q packets using AF_PACKET socket on filtered bridge forwards with wrong MAC addresses

Hi, (CC: Vlad) On 2017/11/30 7:01, Brandon Carpenter wrote: > I narrowed the search to a memmove() called from > skb_reorder_vlan_header() in net/core/skbuff.c. > >> memmove(skb->data - ETH_HLEN, skb->data - skb->mac_len - VLAN_HLEN, >>2 * ETH_ALEN); > > Calling skb_reset_mac_len()

Re: Sending 802.1Q packets using AF_PACKET socket on filtered bridge forwards with wrong MAC addresses

Hi, (CC: Vlad) On 2017/11/30 7:01, Brandon Carpenter wrote: > I narrowed the search to a memmove() called from > skb_reorder_vlan_header() in net/core/skbuff.c. > >> memmove(skb->data - ETH_HLEN, skb->data - skb->mac_len - VLAN_HLEN, >>2 * ETH_ALEN); > > Calling skb_reset_mac_len()

Re: [PATCH] drm: rcar-du: calculate DPLLCR to be more small jitter

Hi I noticed 1 typo, 1 bug on this patch. I will post v2 patch > From: Kuninori Morimoto > > In general, PLL has VCO (= Voltage controlled oscillator), > one of the very important electronic feature called as "jitter" > is related to this VCO. > In academic

Re: [PATCH] drm: rcar-du: calculate DPLLCR to be more small jitter

Hi I noticed 1 typo, 1 bug on this patch. I will post v2 patch > From: Kuninori Morimoto > > In general, PLL has VCO (= Voltage controlled oscillator), > one of the very important electronic feature called as "jitter" > is related to this VCO. > In academic generalism, VCO should be maximum

RE: [PATCH] [linux][master][v1] misc: Add Xilinx ZYNQMP VCU logicoreIP init driver

Hi Greg k-h, Thanks a lot for the review. Replies inline. -Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Tuesday, December 05, 2017 5:30 AM To: Dhaval Rajeshbhai Shah Cc: a...@arndb.de; linux-kernel@vger.kernel.org;

RE: [PATCH] [linux][master][v1] misc: Add Xilinx ZYNQMP VCU logicoreIP init driver

Hi Greg k-h, Thanks a lot for the review. Replies inline. -Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Tuesday, December 05, 2017 5:30 AM To: Dhaval Rajeshbhai Shah Cc: a...@arndb.de; linux-kernel@vger.kernel.org; michal.si...@xilinx.com; Hyun Kwon ;

[PATCH PTI] Fixup "x86/entry/64: Use a per-CPU trampoline stack for IDT entries"

Add to commit message: Using a trampoline stack would obnoxious for Xen PV because Xen PV enters entry_SYSCALL_64_after_hwframe on the stack indicated by sp0. This could be fixed, but I think it's nice to ensure the entry code can still work without a trampoline stack. So this patch doesn't use

[PATCH PTI] Fixup "x86/entry/64: Use a per-CPU trampoline stack for IDT entries"

Add to commit message: Using a trampoline stack would obnoxious for Xen PV because Xen PV enters entry_SYSCALL_64_after_hwframe on the stack indicated by sp0. This could be fixed, but I think it's nice to ensure the entry code can still work without a trampoline stack. So this patch doesn't use

  1   2   3   4   5   6   7   8   9   10   >