Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io

On Mon, May 2, 2016 at 6:51 PM, Dave Chinner wrote: > On Mon, May 02, 2016 at 04:25:51PM -0700, Dan Williams wrote: [..] > Yes, I know, and it doesn't answer any of the questions I just > asked. What you just told me is that there is something that is kept > three levels of

Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io

On Mon, May 2, 2016 at 6:51 PM, Dave Chinner wrote: > On Mon, May 02, 2016 at 04:25:51PM -0700, Dan Williams wrote: [..] > Yes, I know, and it doesn't answer any of the questions I just > asked. What you just told me is that there is something that is kept > three levels of abstraction away from

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

Herbert Xu wrote: > On Sat, Apr 30, 2016 at 08:32:48AM +, Jamie Heilman wrote: > > I usually build my kernels to require module signatures and use > > automatic signing. As of v4.6-rc1 I'm getting this on boot: > > > > Problem loading in-kernel X.509 certificate (-2) > > > > I bisected that

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

Herbert Xu wrote: > On Sat, Apr 30, 2016 at 08:32:48AM +, Jamie Heilman wrote: > > I usually build my kernels to require module signatures and use > > automatic signing. As of v4.6-rc1 I'm getting this on boot: > > > > Problem loading in-kernel X.509 certificate (-2) > > > > I bisected that

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

David Howells wrote: > > Problem loading in-kernel X.509 certificate (-2) > > ENOENT? Hmmm... The only place that is generated is in the crypto layer. > That suggests missing crypto of some sort. > > The attached patch enables some debugging in some relevant files if you can > try applying it

Re: [PATCH] procfs: fixes pthread cross-thread naming if !PR_DUMPABLE

On 26/04/16 21:14, Kees Cook wrote: On Tue, Apr 26, 2016 at 10:20 AM, Janis Danisevskis wrote: The PR_DUMPABLE flag causes the pid related paths of the proc file system to be owned by ROOT. The implementation of pthread_set/getname_np however needs access to

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

David Howells wrote: > > Problem loading in-kernel X.509 certificate (-2) > > ENOENT? Hmmm... The only place that is generated is in the crypto layer. > That suggests missing crypto of some sort. > > The attached patch enables some debugging in some relevant files if you can > try applying it

Re: [PATCH] procfs: fixes pthread cross-thread naming if !PR_DUMPABLE

On 26/04/16 21:14, Kees Cook wrote: On Tue, Apr 26, 2016 at 10:20 AM, Janis Danisevskis wrote: The PR_DUMPABLE flag causes the pid related paths of the proc file system to be owned by ROOT. The implementation of pthread_set/getname_np however needs access to /proc//task//comm. If PR_DUMPABLE

Re: [PATCH net-next 5/5] net: remove dev->trans_start

Hi, [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Florian-Westphal/net-remove-trans_start-from-struct-net_device/20160503-234813 config: s390-default_defconfig (attached as .config) compiler: s390x-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205

Re: [PATCH net-next 5/5] net: remove dev->trans_start

Hi, [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Florian-Westphal/net-remove-trans_start-from-struct-net_device/20160503-234813 config: s390-default_defconfig (attached as .config) compiler: s390x-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205

Re: [RFC v2 3/7] firmware: port built-in section to linker table

On Tue, May 3, 2016 at 10:10 AM, Luis R. Rodriguez wrote: > On Tue, May 3, 2016 at 10:07 AM, Luis R. Rodriguez wrote: >> Thanks! Can you confirm if any Android or Brillo builds are already using it? > > Also more importantly, any chance you can provide any

Re: [RFC v2 3/7] firmware: port built-in section to linker table

On Tue, May 3, 2016 at 10:10 AM, Luis R. Rodriguez wrote: > On Tue, May 3, 2016 at 10:07 AM, Luis R. Rodriguez wrote: >> Thanks! Can you confirm if any Android or Brillo builds are already using it? > > Also more importantly, any chance you can provide any technical > reasons why initramfs

spolupráce

odpovezte mi na tento e-mail nize na dulezitou transakci. email: fnin...@gmx.com

spolupráce

odpovezte mi na tento e-mail nize na dulezitou transakci. email: fnin...@gmx.com

Re: [PATCH RFC] Watchdog: sbsa_gwdt: Enhance timeout range

On Tue, May 03, 2016 at 09:21:41PM +0530, Pratyush Anand wrote: > On 03/05/2016:10:07:48 AM, Timur Tabi wrote: > > Pratyush Anand wrote: > > >In fact after supporting max_hw_heartbeat_ms, there should be no change for > > >action=0 functionally. However, we would still need some changes for > >

[PATCH] sp5100_tco: properly check for new register layouts

Commits 190aa4304de6 (Add AMD Mullins platform support) and cca118fa2a0a94 (Add AMD Carrizo platform support) enabled the driver on a lot more devices, but the following commit missed a single location in the code when checking if the SB800 register offsets should be used. This leads to the wrong

Re: [PATCH RFC] Watchdog: sbsa_gwdt: Enhance timeout range

On Tue, May 03, 2016 at 09:21:41PM +0530, Pratyush Anand wrote: > On 03/05/2016:10:07:48 AM, Timur Tabi wrote: > > Pratyush Anand wrote: > > >In fact after supporting max_hw_heartbeat_ms, there should be no change for > > >action=0 functionally. However, we would still need some changes for > >

[PATCH] sp5100_tco: properly check for new register layouts

Commits 190aa4304de6 (Add AMD Mullins platform support) and cca118fa2a0a94 (Add AMD Carrizo platform support) enabled the driver on a lot more devices, but the following commit missed a single location in the code when checking if the SB800 register offsets should be used. This leads to the wrong

Re: [PATCH V3 1/4] acpi,pci,irq: reduce resource requirements

On 5/3/2016 12:17 PM, Nalla, Ravikanth wrote: >> >https://patchwork.ozlabs.org/patch/611493/mbox/ >> >https://patchwork.ozlabs.org/patch/611496/mbox/ >> >https://patchwork.ozlabs.org/patch/611495/mbox/ >> >https://patchwork.ozlabs.org/patch/611494/mbox/ > The above mbox patches worked with "git

Re: [PATCH V3 1/4] acpi,pci,irq: reduce resource requirements

On 5/3/2016 12:17 PM, Nalla, Ravikanth wrote: >> >https://patchwork.ozlabs.org/patch/611493/mbox/ >> >https://patchwork.ozlabs.org/patch/611496/mbox/ >> >https://patchwork.ozlabs.org/patch/611495/mbox/ >> >https://patchwork.ozlabs.org/patch/611494/mbox/ > The above mbox patches worked with "git

RE: [PATCH [RFC]] PCI: hv: add explicit fencing to config space access

> -Original Message- > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Tuesday, May 3, 2016 5:22 AM > To: linux-...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; Bjorn > Helgaas ; Haiyang Zhang > ;

RE: [PATCH [RFC]] PCI: hv: add explicit fencing to config space access

> -Original Message- > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Tuesday, May 3, 2016 5:22 AM > To: linux-...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; Bjorn > Helgaas ; Haiyang Zhang > ; KY Srinivasan ; Jake > Oshins > Subject:

[PATCH 1/2] ARM: sun4i: dt: Add pll3 and pll7 clocks

Enable pll3 and pll7 clocks that are needed to drive display clocks. Signed-off-by: Priit Laes --- arch/arm/boot/dts/sun4i-a10.dtsi | 44 1 file changed, 44 insertions(+) diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi

[PATCH 1/2] ARM: sun4i: dt: Add pll3 and pll7 clocks

Enable pll3 and pll7 clocks that are needed to drive display clocks. Signed-off-by: Priit Laes --- arch/arm/boot/dts/sun4i-a10.dtsi | 44 1 file changed, 44 insertions(+) diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi

[PATCH 2/2] ARM: sun7i: dt: Add pll3 and pll7 clocks

Enable pll3 and pll7 clocks that are needed by display clocks. --- arch/arm/boot/dts/sun7i-a20.dtsi | 41 1 file changed, 41 insertions(+) diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi index bf5d056..2688512 100644 ---

[PATCH 2/2] ARM: sun7i: dt: Add pll3 and pll7 clocks

Enable pll3 and pll7 clocks that are needed by display clocks. --- arch/arm/boot/dts/sun7i-a20.dtsi | 41 1 file changed, 41 insertions(+) diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi index bf5d056..2688512 100644 ---

[PATCH 0/2] ARM: dts: sunxi: Add pll3 and pll7 clock to sun[47]i.dtsi

Enable the pll3 and pll7 clocks in the DT that are used to drive the display-related clocks. Priit Laes (2): ARM: sun4i: dt: Add pll3 and pll7 clocks ARM: sun7i: dt: Add pll3 and pll7 clocks arch/arm/boot/dts/sun4i-a10.dtsi | 44

[PATCH 0/2] ARM: dts: sunxi: Add pll3 and pll7 clock to sun[47]i.dtsi

Enable the pll3 and pll7 clocks in the DT that are used to drive the display-related clocks. Priit Laes (2): ARM: sun4i: dt: Add pll3 and pll7 clocks ARM: sun7i: dt: Add pll3 and pll7 clocks arch/arm/boot/dts/sun4i-a10.dtsi | 44

Input: add Atmel Atmegaxx captouch driver

Add I2C driver for AtmegaXX capacitive touch device. Signed-off-by: Hung-yu Wu Signed-off-by: Grant Grundler --- .../bindings/input/atmel,atmegaxx_captouch.txt | 34 +++ drivers/input/misc/Kconfig | 11 +

Input: add Atmel Atmegaxx captouch driver

Add I2C driver for AtmegaXX capacitive touch device. Signed-off-by: Hung-yu Wu Signed-off-by: Grant Grundler --- .../bindings/input/atmel,atmegaxx_captouch.txt | 34 +++ drivers/input/misc/Kconfig | 11 + drivers/input/misc/Makefile| 1 +

Re: [PATCH] drm/vc4: Return -EBUSY if there's already a pending flip event.

Robert Foss writes: > On 05/02/2016 08:57 PM, Eric Anholt wrote: >> robert.f...@collabora.com writes: >> >>> From: Robert Foss >>> >>> As per the docs, atomic_commit should return -EBUSY "if an asycnhronous >>> update is requested and there

Re: [PATCH] drm/vc4: Return -EBUSY if there's already a pending flip event.

Robert Foss writes: > On 05/02/2016 08:57 PM, Eric Anholt wrote: >> robert.f...@collabora.com writes: >> >>> From: Robert Foss >>> >>> As per the docs, atomic_commit should return -EBUSY "if an asycnhronous >>> update is requested and there is an earlier update pending". >> >> Note: docs cited

Re: [RFC v2 3/7] firmware: port built-in section to linker table

On Tue, May 3, 2016 at 10:10 AM, Luis R. Rodriguez wrote: > or it was decided Sorry I meant to say: 'or _why_ it was decided to not use initramfs on these systems?' Luis

Re: [RFC v2 3/7] firmware: port built-in section to linker table

On Tue, May 3, 2016 at 10:10 AM, Luis R. Rodriguez wrote: > or it was decided Sorry I meant to say: 'or _why_ it was decided to not use initramfs on these systems?' Luis

Re: [RFC v2 3/7] firmware: port built-in section to linker table

On Tue, May 3, 2016 at 10:07 AM, Luis R. Rodriguez wrote: > Thanks! Can you confirm if any Android or Brillo builds are already using it? Also more importantly, any chance you can provide any technical reasons why initramfs cannot be used, or it was decided to not use it on

Re: [RFC v2 3/7] firmware: port built-in section to linker table

On Tue, May 3, 2016 at 10:07 AM, Luis R. Rodriguez wrote: > Thanks! Can you confirm if any Android or Brillo builds are already using it? Also more importantly, any chance you can provide any technical reasons why initramfs cannot be used, or it was decided to not use it on these systems? It

Re: [RFC v2 3/7] firmware: port built-in section to linker table

On Mon, May 2, 2016 at 11:41 AM, Greg KH wrote: > On Mon, May 02, 2016 at 11:34:33AM -0700, Kees Cook wrote: >> On Mon, Feb 29, 2016 at 10:56 AM, Luis R. Rodriguez wrote: >> > On Mon, Feb 29, 2016 at 10:12:50AM +, David Woodhouse wrote: >> >> On

Re: [RFC v2 3/7] firmware: port built-in section to linker table

On Mon, May 2, 2016 at 11:41 AM, Greg KH wrote: > On Mon, May 02, 2016 at 11:34:33AM -0700, Kees Cook wrote: >> On Mon, Feb 29, 2016 at 10:56 AM, Luis R. Rodriguez wrote: >> > On Mon, Feb 29, 2016 at 10:12:50AM +, David Woodhouse wrote: >> >> On Fri, 2016-02-19 at 05:45 -0800, Luis R.

Re: [RFC v2 3/7] firmware: port built-in section to linker table

On Mon, May 2, 2016 at 11:34 AM, Kees Cook wrote: > On Mon, Feb 29, 2016 at 10:56 AM, Luis R. Rodriguez wrote: >> On Mon, Feb 29, 2016 at 10:12:50AM +, David Woodhouse wrote: >>> On Fri, 2016-02-19 at 05:45 -0800, Luis R. Rodriguez wrote: >>> > This

Re: [RFC v2 3/7] firmware: port built-in section to linker table

On Mon, May 2, 2016 at 11:34 AM, Kees Cook wrote: > On Mon, Feb 29, 2016 at 10:56 AM, Luis R. Rodriguez wrote: >> On Mon, Feb 29, 2016 at 10:12:50AM +, David Woodhouse wrote: >>> On Fri, 2016-02-19 at 05:45 -0800, Luis R. Rodriguez wrote: >>> > This ports built-in firmware to use linker

Re: [PATCH v2 1/6] Documentation: mmc: add mmc-hs400-enhanced-strobe

On Fri, Apr 29, 2016 at 10:46:00AM +0800, Shawn Lin wrote: > mmc-hs400-enhanced-strobe is used to claim that the > host can support hs400 mode with enhanced strobe > introduced by emmc 5.1 spec. > > Signed-off-by: Shawn Lin > --- > > Changes in v2: None > >

Re: [PATCH v2 1/6] Documentation: mmc: add mmc-hs400-enhanced-strobe

On Fri, Apr 29, 2016 at 10:46:00AM +0800, Shawn Lin wrote: > mmc-hs400-enhanced-strobe is used to claim that the > host can support hs400 mode with enhanced strobe > introduced by emmc 5.1 spec. > > Signed-off-by: Shawn Lin > --- > > Changes in v2: None > >

Re: [PATCH 2/4] net: ethernet: ucc: move to new ethtool api {get|set}_link_ksettings

From: Philippe Reynes Date: Sun, 1 May 2016 17:08:09 +0200 > The ethtool api {get|set}_settings is deprecated. > We move the ucc driver to new api {get|set}_link_ksettings. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH] VSOCK: constify vsock_transport structure

From: Julia Lawall Date: Sun, 1 May 2016 14:49:15 +0200 > The vsock_transport structure is never modified, so declare it as const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall Applied.

Re: [PATCH 1/4] net: ethernet: gianfar: move to new ethtool api {get|set}_link_ksettings

From: Philippe Reynes Date: Sun, 1 May 2016 17:08:08 +0200 > The ethtool api {get|set}_settings is deprecated. > We move the gianfar driver to new api {get|set}_link_ksettings. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH 2/4] net: ethernet: ucc: move to new ethtool api {get|set}_link_ksettings

From: Philippe Reynes Date: Sun, 1 May 2016 17:08:09 +0200 > The ethtool api {get|set}_settings is deprecated. > We move the ucc driver to new api {get|set}_link_ksettings. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH] VSOCK: constify vsock_transport structure

From: Julia Lawall Date: Sun, 1 May 2016 14:49:15 +0200 > The vsock_transport structure is never modified, so declare it as const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall Applied.

Re: [PATCH 1/4] net: ethernet: gianfar: move to new ethtool api {get|set}_link_ksettings

From: Philippe Reynes Date: Sun, 1 May 2016 17:08:08 +0200 > The ethtool api {get|set}_settings is deprecated. > We move the gianfar driver to new api {get|set}_link_ksettings. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Fri, Apr 29, 2016 at 01:12:54AM +0300, Sergei Shtylyov wrote: > The PHY devices sometimes do have their reset signal (maybe even power > supply?) tied to some GPIO and sometimes it also does happen that a boot > loader does not leave it deasserted. So far this issue has been attacked > from (as

Re: [PATCH 3/4] net: ethernet: fs-enet: move to new ethtool api {get|set}_link_ksettings

From: Philippe Reynes Date: Sun, 1 May 2016 17:08:10 +0200 > The ethtool api {get|set}_settings is deprecated. > We move the fs-enet driver to new api {get|set}_link_ksettings. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Fri, Apr 29, 2016 at 01:12:54AM +0300, Sergei Shtylyov wrote: > The PHY devices sometimes do have their reset signal (maybe even power > supply?) tied to some GPIO and sometimes it also does happen that a boot > loader does not leave it deasserted. So far this issue has been attacked > from (as

Re: [PATCH 3/4] net: ethernet: fs-enet: move to new ethtool api {get|set}_link_ksettings

From: Philippe Reynes Date: Sun, 1 May 2016 17:08:10 +0200 > The ethtool api {get|set}_settings is deprecated. > We move the fs-enet driver to new api {get|set}_link_ksettings. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH 4/4] net: ethernet: fec_mpc52xx: move to new ethtool api {get|set}_link_ksettings

From: Philippe Reynes Date: Sun, 1 May 2016 17:08:11 +0200 > The ethtool api {get|set}_settings is deprecated. > We move the fec_mpc52xx driver to new api {get|set}_link_ksettings. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH 4/4] net: ethernet: fec_mpc52xx: move to new ethtool api {get|set}_link_ksettings

From: Philippe Reynes Date: Sun, 1 May 2016 17:08:11 +0200 > The ethtool api {get|set}_settings is deprecated. > We move the fec_mpc52xx driver to new api {get|set}_link_ksettings. > > Signed-off-by: Philippe Reynes Applied.

kcompactd hang during memory offlining

Assume memory47 is the last online block left in node1. This will hang: # echo offline > /sys/devices/system/node/node1/memory47/state After a couple of minutes, the following pops up in dmesg: INFO: task bash:957 blocked for more than 120 seconds. Not tainted 4.6.0-rc6+ #6 "echo 0 >

Re: [PATCH] drivers: net: xgene: constify xgene_cle_ops structure

From: Julia Lawall Date: Sun, 1 May 2016 14:36:28 +0200 > The xgene_cle_ops structure is never modified, so declare it as const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall Applied.

kcompactd hang during memory offlining

Assume memory47 is the last online block left in node1. This will hang: # echo offline > /sys/devices/system/node/node1/memory47/state After a couple of minutes, the following pops up in dmesg: INFO: task bash:957 blocked for more than 120 seconds. Not tainted 4.6.0-rc6+ #6 "echo 0 >

Re: [PATCH] drivers: net: xgene: constify xgene_cle_ops structure

From: Julia Lawall Date: Sun, 1 May 2016 14:36:28 +0200 > The xgene_cle_ops structure is never modified, so declare it as const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall Applied.

Re: [PATCH 7/8] wbt: add general throttling mechanism

On 05/03/2016 09:48 AM, Jan Kara wrote: On Tue 03-05-16 17:40:32, Jan Kara wrote: On Tue 03-05-16 11:34:10, Jan Kara wrote: Yeah, once I'll hunt down that regression with old disk, I can have a look into how writeback throttling plays together with blkio-controller. So I've tried the

Re: [PATCH 7/8] wbt: add general throttling mechanism

On 05/03/2016 09:48 AM, Jan Kara wrote: On Tue 03-05-16 17:40:32, Jan Kara wrote: On Tue 03-05-16 11:34:10, Jan Kara wrote: Yeah, once I'll hunt down that regression with old disk, I can have a look into how writeback throttling plays together with blkio-controller. So I've tried the

Re: [PATCH v3 3/3] leds: gpio: Support the "panic-indicator" firmware property

On Thu, Apr 28, 2016 at 07:03:40PM -0300, Ezequiel Garcia wrote: > Calling a GPIO LEDs is quite likely to work even if the kernel > has paniced, so they are ideal to blink in this situation. > This commit adds support for the new "panic-indicator" > firmware property, allowing to mark a given LED

Re: [PATCH 4/7] sched/fair: Clean up the logic in fix_small_imbalance()

On 03/05/16 11:12, Peter Zijlstra wrote: > On Fri, Apr 29, 2016 at 08:32:41PM +0100, Dietmar Eggemann wrote: >> Avoid the need to add scaled_busy_load_per_task on both sides of the if >> condition to determine whether imbalance has to be set to >> busiest->load_per_task or not. >> >> The imbn

Re: [PATCH v3 3/3] leds: gpio: Support the "panic-indicator" firmware property

On Thu, Apr 28, 2016 at 07:03:40PM -0300, Ezequiel Garcia wrote: > Calling a GPIO LEDs is quite likely to work even if the kernel > has paniced, so they are ideal to blink in this situation. > This commit adds support for the new "panic-indicator" > firmware property, allowing to mark a given LED

Re: [PATCH 4/7] sched/fair: Clean up the logic in fix_small_imbalance()

On 03/05/16 11:12, Peter Zijlstra wrote: > On Fri, Apr 29, 2016 at 08:32:41PM +0100, Dietmar Eggemann wrote: >> Avoid the need to add scaled_busy_load_per_task on both sides of the if >> condition to determine whether imbalance has to be set to >> busiest->load_per_task or not. >> >> The imbn

Re: [PATCH v7 2/2] memory: atmel-ebi: add DT bindings documentation

Hi Rob, On Tue, 3 May 2016 11:40:19 -0500 Rob Herring wrote: > On Thu, Apr 28, 2016 at 02:03:27PM +0200, Boris Brezillon wrote: > > The EBI (External Bus Interface) is used to access external peripherals > > (NOR, SRAM, NAND, and other specific devices like ethernet

Re: [PATCH v7 2/2] memory: atmel-ebi: add DT bindings documentation

Hi Rob, On Tue, 3 May 2016 11:40:19 -0500 Rob Herring wrote: > On Thu, Apr 28, 2016 at 02:03:27PM +0200, Boris Brezillon wrote: > > The EBI (External Bus Interface) is used to access external peripherals > > (NOR, SRAM, NAND, and other specific devices like ethernet controllers). > > Each

Re: [PATCH] PCI: dra7xx: program outbound atu with correct address

On Mon, May 02, 2016 at 04:09:33PM -0500, Bjorn Helgaas wrote: > On Mon, May 02, 2016 at 04:54:40PM +0200, Niklas Cassel wrote: > > From: Niklas Cassel > > > > commit 1488aefa37a4 ("PCI: designware: Move Root Complex > > setup code to dw_pcie_setup_rc()") broke dra7xx > >

Re: [PATCH] PCI: dra7xx: program outbound atu with correct address

On Mon, May 02, 2016 at 04:09:33PM -0500, Bjorn Helgaas wrote: > On Mon, May 02, 2016 at 04:54:40PM +0200, Niklas Cassel wrote: > > From: Niklas Cassel > > > > commit 1488aefa37a4 ("PCI: designware: Move Root Complex > > setup code to dw_pcie_setup_rc()") broke dra7xx > > by moving code from

Re: [PATCH V2] iommu/arm-smmu: clear cache lock bit of ACR

On 03/05/16 14:50, Peng Fan wrote: According MMU-500r2 TRM, section 3.7.1 Auxiliary Control registers, You can modify ACTLR only when the ACR.CACHE_LOCK bit is 0. So before clearing ARM_MMU500_ACTLR_CPRE of each context bank, need clear CACHE_LOCK bit of ACR register first. Since CACHE_LOCK

Re: [PATCH V2] iommu/arm-smmu: clear cache lock bit of ACR

On 03/05/16 14:50, Peng Fan wrote: According MMU-500r2 TRM, section 3.7.1 Auxiliary Control registers, You can modify ACTLR only when the ACR.CACHE_LOCK bit is 0. So before clearing ARM_MMU500_ACTLR_CPRE of each context bank, need clear CACHE_LOCK bit of ACR register first. Since CACHE_LOCK

Re: [tip:core/signals] signals/sigaltstack: Prepare to add new SS_xxx flags

On Tue, May 3, 2016 at 9:13 AM, Andy Lutomirski wrote: > On Tue, May 3, 2016 at 12:50 AM, tip-bot for Stas Sergeev > wrote: >> Commit-ID: 407bc16ad1769f5cb8ad9555611cb198187ef4cd >> Gitweb: >>

Re: [tip:core/signals] signals/sigaltstack: Prepare to add new SS_xxx flags

On Tue, May 3, 2016 at 9:13 AM, Andy Lutomirski wrote: > On Tue, May 3, 2016 at 12:50 AM, tip-bot for Stas Sergeev > wrote: >> Commit-ID: 407bc16ad1769f5cb8ad9555611cb198187ef4cd >> Gitweb: >> http://git.kernel.org/tip/407bc16ad1769f5cb8ad9555611cb198187ef4cd >> Author: Stas Sergeev

Re: [tip:core/signals] selftests/sigaltstack: Add new testcase for sigaltstack(SS_ONSTACK|SS_AUTODISARM)

On Tue, May 3, 2016 at 12:50 AM, tip-bot for Stas Sergeev wrote: > Commit-ID: 19fd2868e3671b446b13d135a44363182bbd319a > Gitweb: http://git.kernel.org/tip/19fd2868e3671b446b13d135a44363182bbd319a > Author: Stas Sergeev > AuthorDate: Thu, 14 Apr 2016

Re: [tip:core/signals] selftests/sigaltstack: Add new testcase for sigaltstack(SS_ONSTACK|SS_AUTODISARM)

On Tue, May 3, 2016 at 12:50 AM, tip-bot for Stas Sergeev wrote: > Commit-ID: 19fd2868e3671b446b13d135a44363182bbd319a > Gitweb: http://git.kernel.org/tip/19fd2868e3671b446b13d135a44363182bbd319a > Author: Stas Sergeev > AuthorDate: Thu, 14 Apr 2016 23:20:05 +0300 > Committer: Ingo

Re: [PATCH v2 2/3] ARM: DRA7x: dts: Update the OSC_32K_CLK frequency

* J.D. Schroeder [160503 06:32]: > On 05/03/2016 03:16 AM, Tero Kristo wrote: > > On 02/05/16 20:12, J.D. Schroeder wrote: > >> From: "J.D. Schroeder" > >> > >> This commit updates the OSC_32K_CLK (secure_32k_clk_src_ck) frequency > >> from the

Re: [PATCH v2 2/3] ARM: DRA7x: dts: Update the OSC_32K_CLK frequency

* J.D. Schroeder [160503 06:32]: > On 05/03/2016 03:16 AM, Tero Kristo wrote: > > On 02/05/16 20:12, J.D. Schroeder wrote: > >> From: "J.D. Schroeder" > >> > >> This commit updates the OSC_32K_CLK (secure_32k_clk_src_ck) frequency > >> from the precise 32kHz frequency (i.e., 32.768 kHz) to a

Re: [PATCH v7 2/2] memory: atmel-ebi: add DT bindings documentation

On Thu, Apr 28, 2016 at 02:03:27PM +0200, Boris Brezillon wrote: > The EBI (External Bus Interface) is used to access external peripherals > (NOR, SRAM, NAND, and other specific devices like ethernet controllers). > Each device is assigned a CS line and an address range and can have its > own

Re: [PATCH v7 2/2] memory: atmel-ebi: add DT bindings documentation

On Thu, Apr 28, 2016 at 02:03:27PM +0200, Boris Brezillon wrote: > The EBI (External Bus Interface) is used to access external peripherals > (NOR, SRAM, NAND, and other specific devices like ethernet controllers). > Each device is assigned a CS line and an address range and can have its > own

[PATCH v2 2/2] nbd: Fix checkpatch errors.

Signed-off-by: Pranay Kr. Srivastava --- drivers/block/nbd.c | 33 ++--- 1 file changed, 18 insertions(+), 15 deletions(-) diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c index c79bcd7..9ab3a27 100644 --- a/drivers/block/nbd.c +++

[PATCH v2 0/2] nbd: fix might_sleep warning and checkpatch fixes.

This patch series fixes 01) might_sleep warning generated on a xmit_timeout as the socket is shutdown while holding the spin_lock. Instead now the socket is shutdown in the sender kernel thread. 02) checkpatch errors. Pranay Kr. Srivastava (2): nbd: Fix might_sleep warning on xmit

[PATCH v2 2/2] nbd: Fix checkpatch errors.

Signed-off-by: Pranay Kr. Srivastava --- drivers/block/nbd.c | 33 ++--- 1 file changed, 18 insertions(+), 15 deletions(-) diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c index c79bcd7..9ab3a27 100644 --- a/drivers/block/nbd.c +++ b/drivers/block/nbd.c @@ -3,7

[PATCH v2 0/2] nbd: fix might_sleep warning and checkpatch fixes.

This patch series fixes 01) might_sleep warning generated on a xmit_timeout as the socket is shutdown while holding the spin_lock. Instead now the socket is shutdown in the sender kernel thread. 02) checkpatch errors. Pranay Kr. Srivastava (2): nbd: Fix might_sleep warning on xmit

[PATCH v2 1/2] nbd: Fix might_sleep warning on xmit timeout

This patch fixes the warning generated when a timeout occurs on the request and socket is closed from a non-sleep context by 1. Moving the socket closing on a timeout to nbd_thread_send 2. Make sock lock to be a mutex instead of a spin lock, since nbd_xmit_timeout doesn't need to hold it

[PATCH v2 1/2] nbd: Fix might_sleep warning on xmit timeout

This patch fixes the warning generated when a timeout occurs on the request and socket is closed from a non-sleep context by 1. Moving the socket closing on a timeout to nbd_thread_send 2. Make sock lock to be a mutex instead of a spin lock, since nbd_xmit_timeout doesn't need to hold it

Applied "ASoC: hdac_hdmi: Potential NULL deref in hdac_hdmi_get_spk_alloc()" to the asoc tree

The patch ASoC: hdac_hdmi: Potential NULL deref in hdac_hdmi_get_spk_alloc() has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Applied "ASoC: hdac_hdmi: Potential NULL deref in hdac_hdmi_get_spk_alloc()" to the asoc tree

The patch ASoC: hdac_hdmi: Potential NULL deref in hdac_hdmi_get_spk_alloc() has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Re: [RFC PATCH 2/7] ALSA: ac97: add an ac97 bus

On Sat, Apr 30, 2016 at 11:15:34PM +0200, Robert Jarzmik wrote: > AC97 is a bus for sound usage. It enables for a AC97 AC-Link to link one > controller to 0 to 4 AC97 codecs. > The goal of this new implementation is to implement a device/driver > model for AC97, with an automatic scan of the bus

Re: [RFC PATCH 2/7] ALSA: ac97: add an ac97 bus

On Sat, Apr 30, 2016 at 11:15:34PM +0200, Robert Jarzmik wrote: > AC97 is a bus for sound usage. It enables for a AC97 AC-Link to link one > controller to 0 to 4 AC97 codecs. > The goal of this new implementation is to implement a device/driver > model for AC97, with an automatic scan of the bus

Re: [PATCH] lightnvm: pass dma address to hardware rather than pointer

> > On 03 May 2016, at 17:22, Arnd Bergmann wrote: > > A recent change to lightnvm added code to pass a kernel pointer > to the hardware, which gcc complained about: > > drivers/nvme/host/lightnvm.c: In function 'nvme_nvm_rqtocmd': > drivers/nvme/host/lightnvm.c:472:32: error:

Re: [PATCH] lightnvm: pass dma address to hardware rather than pointer

> > On 03 May 2016, at 17:22, Arnd Bergmann wrote: > > A recent change to lightnvm added code to pass a kernel pointer > to the hardware, which gcc complained about: > > drivers/nvme/host/lightnvm.c: In function 'nvme_nvm_rqtocmd': > drivers/nvme/host/lightnvm.c:472:32: error: cast from

Re: [tip:core/signals] signals/sigaltstack: Implement SS_AUTODISARM flag

On Tue, May 3, 2016 at 12:50 AM, tip-bot for Stas Sergeev wrote: > Commit-ID: 2a74213838104a41588d86fd5e8d344972891ace > Gitweb: http://git.kernel.org/tip/2a74213838104a41588d86fd5e8d344972891ace > Author: Stas Sergeev > AuthorDate: Thu, 14 Apr 2016

Re: [tip:core/signals] signals/sigaltstack: Implement SS_AUTODISARM flag

On Tue, May 3, 2016 at 12:50 AM, tip-bot for Stas Sergeev wrote: > Commit-ID: 2a74213838104a41588d86fd5e8d344972891ace > Gitweb: http://git.kernel.org/tip/2a74213838104a41588d86fd5e8d344972891ace > Author: Stas Sergeev > AuthorDate: Thu, 14 Apr 2016 23:20:04 +0300 > Committer: Ingo

Re: [RFC][PATCH 0/6] /dev/random - a new approach

On Tue, May 3, 2016 at 4:48 PM, wrote: > On Tue, May 03, 2016 at 03:57:15PM +0200, Nikos Mavrogiannopoulos wrote: >> I believe their main concern is that they want to protect applications >> which do not check error codes of system calls, when running on a >> kernel which does not

Re: [RFC][PATCH 0/6] /dev/random - a new approach

On Tue, May 3, 2016 at 4:48 PM, wrote: > On Tue, May 03, 2016 at 03:57:15PM +0200, Nikos Mavrogiannopoulos wrote: >> I believe their main concern is that they want to protect applications >> which do not check error codes of system calls, when running on a >> kernel which does not provide

RE: [PATCH V3 1/4] acpi,pci,irq: reduce resource requirements

-Original Message- From: Sinan Kaya [mailto:ok...@codeaurora.org] Sent: Monday, May 02, 2016 11:29 PM To: Nalla, Ravikanth ; Bjorn Helgaas Cc: linux-a...@vger.kernel.org; ti...@codeaurora.org; c...@codeaurora.org; linux-...@vger.kernel.org;

RE: [PATCH V3 1/4] acpi,pci,irq: reduce resource requirements

-Original Message- From: Sinan Kaya [mailto:ok...@codeaurora.org] Sent: Monday, May 02, 2016 11:29 PM To: Nalla, Ravikanth ; Bjorn Helgaas Cc: linux-a...@vger.kernel.org; ti...@codeaurora.org; c...@codeaurora.org; linux-...@vger.kernel.org; l...@kernel.org; K, Harish (MCOU/UPEL) ;

Re: [tip:core/signals] signals/sigaltstack: Prepare to add new SS_xxx flags

On Tue, May 3, 2016 at 12:50 AM, tip-bot for Stas Sergeev wrote: > Commit-ID: 407bc16ad1769f5cb8ad9555611cb198187ef4cd > Gitweb: http://git.kernel.org/tip/407bc16ad1769f5cb8ad9555611cb198187ef4cd > Author: Stas Sergeev > AuthorDate: Thu, 14 Apr 2016

Re: [PATCH net v3 4/5] dt: cpsw: phy-handle, phy_id, and fixed-link are mutually exclusive

On Wed, Apr 27, 2016 at 09:42:47PM -0400, David Rivshin (Allworx) wrote: > From: David Rivshin > > The phy-handle, phy_id, and fixed-link properties are mutually exclusive, > and only one need be specified. Make this clear in the binding doc. > > Also mark the phy_id

Re: [tip:core/signals] signals/sigaltstack: Prepare to add new SS_xxx flags

On Tue, May 3, 2016 at 12:50 AM, tip-bot for Stas Sergeev wrote: > Commit-ID: 407bc16ad1769f5cb8ad9555611cb198187ef4cd > Gitweb: http://git.kernel.org/tip/407bc16ad1769f5cb8ad9555611cb198187ef4cd > Author: Stas Sergeev > AuthorDate: Thu, 14 Apr 2016 23:20:03 +0300 > Committer: Ingo

Re: [PATCH net v3 4/5] dt: cpsw: phy-handle, phy_id, and fixed-link are mutually exclusive

On Wed, Apr 27, 2016 at 09:42:47PM -0400, David Rivshin (Allworx) wrote: > From: David Rivshin > > The phy-handle, phy_id, and fixed-link properties are mutually exclusive, > and only one need be specified. Make this clear in the binding doc. > > Also mark the phy_id property as deprecated, as

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