[RFC PATCH] blk: reset 'bi_next' when bio is done inside request

blk_attempt_plug_merge() try to merge bio into request and chain them by 'bi_next', while after the bio is done inside request, we forgot to reset the 'bi_next'. This lead into BUG while removing all the underlying devices from md-raid1, the bio once go through: md_do_sync()

[RFC PATCH] blk: reset 'bi_next' when bio is done inside request

blk_attempt_plug_merge() try to merge bio into request and chain them by 'bi_next', while after the bio is done inside request, we forgot to reset the 'bi_next'. This lead into BUG while removing all the underlying devices from md-raid1, the bio once go through: md_do_sync()

Re: [PATCH v2] i2c/muxes/i2c-mux-ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch

On 2017-03-31 17:29, Peter Rosin wrote: > Hi! > > Sorry for my incremental reviewing... > Another incremental... > On 2017-03-29 12:15, michael.henner...@analog.com wrote: >> + >> +/* Now create an adapter for each channel */ >> +for (num = 0; num < data->chip->nchans; num++) { >> +

Re: [PATCH v2] i2c/muxes/i2c-mux-ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch

On 2017-03-31 17:29, Peter Rosin wrote: > Hi! > > Sorry for my incremental reviewing... > Another incremental... > On 2017-03-29 12:15, michael.henner...@analog.com wrote: >> + >> +/* Now create an adapter for each channel */ >> +for (num = 0; num < data->chip->nchans; num++) { >> +

Re: [PATCH] pinctrl: core: Fix pinctrl_register_and_init() with pinctrl_enable()

Hi Tony, On Thu, Mar 30, 2017 at 1:16 PM, Tony Lindgren wrote: > Recent pinctrl changes to allow dynamic allocation of pins exposed one > more issue with the pinctrl pins claimed early by the controller itself. > This caused a regression for IMX6 pinctrl hogs. > > Before

Re: [PATCH] pinctrl: core: Fix pinctrl_register_and_init() with pinctrl_enable()

Hi Tony, On Thu, Mar 30, 2017 at 1:16 PM, Tony Lindgren wrote: > Recent pinctrl changes to allow dynamic allocation of pins exposed one > more issue with the pinctrl pins claimed early by the controller itself. > This caused a regression for IMX6 pinctrl hogs. > > Before enabling the pin

Re: [PATCH 1/3] rsi: Rename the file rsi_91x_pkt.c to rsi_91x_hal.c

+ linux-wireless Prameela Rani Garnepudi writes: > The file rsi_91x_hal.c will contain new firmware loading method for > RSI 9113 chipset. So this file will have device specific operations. > As the file 'rsi_91x_pkt.c' contains code for preparing device > (frimware

Re: [PATCH 1/3] rsi: Rename the file rsi_91x_pkt.c to rsi_91x_hal.c

+ linux-wireless Prameela Rani Garnepudi writes: > The file rsi_91x_hal.c will contain new firmware loading method for > RSI 9113 chipset. So this file will have device specific operations. > As the file 'rsi_91x_pkt.c' contains code for preparing device > (frimware understandable) specific

Re: [PATCH 0/6] mm: make movable onlining suck less

On Thu 30-03-17 13:54:48, Michal Hocko wrote: [...] > Any thoughts, complains, suggestions? Anyting? I would really appreciate a feedback from IBM and Futjitsu guys who have shaped this code last few years. Also Igor and Vitaly seem to be using memory hotplug in virtualized environments. I do not

Re: [PATCH 0/6] mm: make movable onlining suck less

On Thu 30-03-17 13:54:48, Michal Hocko wrote: [...] > Any thoughts, complains, suggestions? Anyting? I would really appreciate a feedback from IBM and Futjitsu guys who have shaped this code last few years. Also Igor and Vitaly seem to be using memory hotplug in virtualized environments. I do not

Re: [PATCH] mm/zswap: fix potential deadlock in zswap_frontswap_store()

On 04/03/2017 11:47 AM, Michal Hocko wrote: > On Fri 31-03-17 10:00:30, Shakeel Butt wrote: >> On Fri, Mar 31, 2017 at 8:30 AM, Andrey Ryabinin >> wrote: >>> zswap_frontswap_store() is called during memory reclaim from >>> __frontswap_store() from swap_writepage() from

Re: [PATCH] mm/zswap: fix potential deadlock in zswap_frontswap_store()

On 04/03/2017 11:47 AM, Michal Hocko wrote: > On Fri 31-03-17 10:00:30, Shakeel Butt wrote: >> On Fri, Mar 31, 2017 at 8:30 AM, Andrey Ryabinin >> wrote: >>> zswap_frontswap_store() is called during memory reclaim from >>> __frontswap_store() from swap_writepage() from shrink_page_list(). >>>

Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread

On (03/06/17 21:45), Sergey Senozhatsky wrote: [..] > printk kthread changes the behavior of printk in one _corner case_. > The corner case is quite interesting and actually consists of two corner > cases. Suppose on SMP system there is only one CPU that printk()-s a lot, > the rest of CPUs

Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread

On (03/06/17 21:45), Sergey Senozhatsky wrote: [..] > printk kthread changes the behavior of printk in one _corner case_. > The corner case is quite interesting and actually consists of two corner > cases. Suppose on SMP system there is only one CPU that printk()-s a lot, > the rest of CPUs

Re: [LSF/MM TOPIC][LSF/MM,ATTEND] shared TLB, hugetlb reservations

On Wed 08-03-17 17:30:55, Mike Kravetz wrote: > On 01/10/2017 03:02 PM, Mike Kravetz wrote: > > Another more concrete topic is hugetlb reservations. Michal Hocko > > proposed the topic "mm patches review bandwidth", and brought up the > > related subject of areas in need of attention from an

Re: [LSF/MM TOPIC][LSF/MM,ATTEND] shared TLB, hugetlb reservations

On Wed 08-03-17 17:30:55, Mike Kravetz wrote: > On 01/10/2017 03:02 PM, Mike Kravetz wrote: > > Another more concrete topic is hugetlb reservations. Michal Hocko > > proposed the topic "mm patches review bandwidth", and brought up the > > related subject of areas in need of attention from an

Re: [PATCH] ARM: sun7i: Cubietruck: enable ACIN und USB power supply subnode

Hi, On Mon, Apr 03, 2017 at 11:12:45AM +0200, Alexander Syring wrote: > The Cubietruck has an AXP209 PMIC and can be power-supplied by ACIN via > the CHG-IN pin or by USB. > > This enables the ACIN and the USB power supply subnode in the DT. > > Signed-off-by: Alexander Syring

Re: [PATCH] ARM: sun7i: Cubietruck: enable ACIN und USB power supply subnode

Hi, On Mon, Apr 03, 2017 at 11:12:45AM +0200, Alexander Syring wrote: > The Cubietruck has an AXP209 PMIC and can be power-supplied by ACIN via > the CHG-IN pin or by USB. > > This enables the ACIN and the USB power supply subnode in the DT. > > Signed-off-by: Alexander Syring > --- > > Send

Re: [PATCH] KVM: VMX: require virtual NMI support

On 27.03.2017 14:38, Paolo Bonzini wrote: > Virtual NMIs are only missing in Prescott and Yonah chips. Both are obsolete > for virtualization usage---Yonah is 32-bit only even---so drop vNMI emulation. > > Signed-off-by: Paolo Bonzini > --- > arch/x86/kvm/vmx.c | 143 >

Re: [PATCH] KVM: VMX: require virtual NMI support

On 27.03.2017 14:38, Paolo Bonzini wrote: > Virtual NMIs are only missing in Prescott and Yonah chips. Both are obsolete > for virtualization usage---Yonah is 32-bit only even---so drop vNMI emulation. > > Signed-off-by: Paolo Bonzini > --- > arch/x86/kvm/vmx.c | 143 >

Re: Updating sunxi tree in linux-next

Hi Stephen, On Mon, Apr 03, 2017 at 09:56:12AM +1000, Stephen Rothwell wrote: > Hi Maxime, > > On Fri, 31 Mar 2017 09:57:29 +0200 Maxime Ripard > wrote: > > > > We've switched from my personal git tree for the Allwinner sunxi > > development to a shared tree:

Re: Updating sunxi tree in linux-next

Hi Stephen, On Mon, Apr 03, 2017 at 09:56:12AM +1000, Stephen Rothwell wrote: > Hi Maxime, > > On Fri, 31 Mar 2017 09:57:29 +0200 Maxime Ripard > wrote: > > > > We've switched from my personal git tree for the Allwinner sunxi > > development to a shared tree: > >

Re: [PATCH 16/16] drivers, net, intersil: convert request_context.refcount from atomic_t to refcount_t

Elena Reshetova writes: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. > >

Re: [PATCH 16/16] drivers, net, intersil: convert request_context.refcount from atomic_t to refcount_t

Elena Reshetova writes: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. > > Signed-off-by: Elena Reshetova >

Re: [PATCH v3 20/20] ARM: sunxi: Enable dwmac-sun8i driver on multi_v7_defconfig

On Mon, Apr 03, 2017 at 11:14:44AM +0200, Corentin Labbe wrote: > Enable the dwmac-sun8i driver in the multi_v7 default configuration Your prefix should be arm: multi_v7: Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc

Re: [PATCH v3 20/20] ARM: sunxi: Enable dwmac-sun8i driver on multi_v7_defconfig

On Mon, Apr 03, 2017 at 11:14:44AM +0200, Corentin Labbe wrote: > Enable the dwmac-sun8i driver in the multi_v7 default configuration Your prefix should be arm: multi_v7: Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc

Re: [PATCH 15/16] drivers, net, intersil: convert hostap_cmd_queue.usecnt from atomic_t to refcount_t

Elena Reshetova writes: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. > >

Re: [PATCH 15/16] drivers, net, intersil: convert hostap_cmd_queue.usecnt from atomic_t to refcount_t

Elena Reshetova writes: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. > > Signed-off-by: Elena Reshetova >

Re: [PATCH v3 16/20] ARM: dts: sun50i-a64: enable dwmac-sun8i on pine64

On Mon, Apr 03, 2017 at 11:14:40AM +0200, Corentin Labbe wrote: > The dwmac-sun8i hardware is present on the pine64 > It uses an external PHY via RMII. > > Signed-off-by: Corentin Labbe Looks fine, but please use "arm64: allwinner: pine64: " as your title prefix. It

Re: [PATCH v3 16/20] ARM: dts: sun50i-a64: enable dwmac-sun8i on pine64

On Mon, Apr 03, 2017 at 11:14:40AM +0200, Corentin Labbe wrote: > The dwmac-sun8i hardware is present on the pine64 > It uses an external PHY via RMII. > > Signed-off-by: Corentin Labbe Looks fine, but please use "arm64: allwinner: pine64: " as your title prefix. It applies to all your other

Re: Bad page state splats on arm64, v4.11-rc{3,4}

On Mon, Apr 03, 2017 at 11:56:29AM +0100, Mark Rutland wrote: > On Fri, Mar 31, 2017 at 06:58:45PM +0100, Mark Rutland wrote: > > Hi, > > > > I'm seeing intermittent bad page state splats on arm64 with 4.11-rc3 and > > v4.11-rc4. I have not tested earlier kernels, or other architectures. > > > >

Re: Bad page state splats on arm64, v4.11-rc{3,4}

On Mon, Apr 03, 2017 at 11:56:29AM +0100, Mark Rutland wrote: > On Fri, Mar 31, 2017 at 06:58:45PM +0100, Mark Rutland wrote: > > Hi, > > > > I'm seeing intermittent bad page state splats on arm64 with 4.11-rc3 and > > v4.11-rc4. I have not tested earlier kernels, or other architectures. > > > >

Re: [PATCH v3 12/20] ARM: dts: sun8i: Enable dwmac-sun8i on the Orange Pi plus

On Mon, Apr 03, 2017 at 11:14:36AM +0200, Corentin Labbe wrote: > The dwmac-sun8i hardware is present on the Orange PI plus. > It uses an external PHY rtl8211e via RGMII. > > This patch create the needed regulator, emac and phy nodes. > > Signed-off-by: Corentin Labbe

Re: [PATCH v3 12/20] ARM: dts: sun8i: Enable dwmac-sun8i on the Orange Pi plus

On Mon, Apr 03, 2017 at 11:14:36AM +0200, Corentin Labbe wrote: > The dwmac-sun8i hardware is present on the Orange PI plus. > It uses an external PHY rtl8211e via RGMII. > > This patch create the needed regulator, emac and phy nodes. > > Signed-off-by: Corentin Labbe > --- >

[PATCH v2] scsi: storvsc: Add support for FC rport.

Included in the current storvsc driver for Hyper-V is the ability to access luns on an FC fabric via a virtualized fiber channel adapter exposed by the Hyper-V host. The driver also attaches to the FC transport to allow host and port names to be published under /sys/class/fc_host/hostX. Current

[PATCH v2] scsi: storvsc: Add support for FC rport.

Included in the current storvsc driver for Hyper-V is the ability to access luns on an FC fabric via a virtualized fiber channel adapter exposed by the Hyper-V host. The driver also attaches to the FC transport to allow host and port names to be published under /sys/class/fc_host/hostX. Current

Re: [PATCH 1/2] kvm: make KVM_CAP_COALESCED_MMIO architecture agnostic

On 31.03.2017 15:41, Radim Krčmář wrote: > 2017-03-31 13:53+0200, Paolo Bonzini: >> Remove code from architecture files that can be moved to virt/kvm, since >> there >> is already common code for coalesced MMIO. >> >> Signed-off-by: Paolo Bonzini >> --- >> diff --git

Re: [PATCH 1/2] kvm: make KVM_CAP_COALESCED_MMIO architecture agnostic

On 31.03.2017 15:41, Radim Krčmář wrote: > 2017-03-31 13:53+0200, Paolo Bonzini: >> Remove code from architecture files that can be moved to virt/kvm, since >> there >> is already common code for coalesced MMIO. >> >> Signed-off-by: Paolo Bonzini >> --- >> diff --git a/virt/kvm/kvm_main.c

Re: [PATCH 0/9] Unify i2c_mux_add_adapter error reporting

On 2017-04-03 12:27, Wolfram Sang wrote: > On Mon, Apr 03, 2017 at 10:38:29AM +0200, Peter Rosin wrote: >> Hi! >> >> Many users of the i2c_mux_add_adapter interface log a message >> on failure, but the function already logs such a message. One >> or two of those users actually add more information

Re: [PATCH 0/9] Unify i2c_mux_add_adapter error reporting

On 2017-04-03 12:27, Wolfram Sang wrote: > On Mon, Apr 03, 2017 at 10:38:29AM +0200, Peter Rosin wrote: >> Hi! >> >> Many users of the i2c_mux_add_adapter interface log a message >> on failure, but the function already logs such a message. One >> or two of those users actually add more information

Re: [PATCH 1/4] regmap: irq: Fix lost interrupts by introducing handle_reread

On Wed, 22 Mar 2017, Tony Lindgren wrote: > At least Motorola CPCAP PMIC needs it's device interrupts re-read > until there are no more interrupts. Otherwise the PMIC interrupt to > the SoC will eventually stop toggling. This seems to be a bug in the > CPCAP PMIC where it can stop driving the

Re: [PATCH 1/4] regmap: irq: Fix lost interrupts by introducing handle_reread

On Wed, 22 Mar 2017, Tony Lindgren wrote: > At least Motorola CPCAP PMIC needs it's device interrupts re-read > until there are no more interrupts. Otherwise the PMIC interrupt to > the SoC will eventually stop toggling. This seems to be a bug in the > CPCAP PMIC where it can stop driving the

[PATCH 3/3] extcon: intel-cht-wc: Ignore failure to detect charger-type on host mode exit

When we leave host-mode because the id-pin is no longer connected to ground, the 5v boost converter is normally still on, so we will see Vbus, but it is not from a charger (normally) so the charger-type detection will fail. This commit silences the cht_wc_extcon_get_charger() false-positive

[PATCH 3/3] extcon: intel-cht-wc: Ignore failure to detect charger-type on host mode exit

When we leave host-mode because the id-pin is no longer connected to ground, the 5v boost converter is normally still on, so we will see Vbus, but it is not from a charger (normally) so the charger-type detection will fail. This commit silences the cht_wc_extcon_get_charger() false-positive

[PATCH 1/3] extcon: intel-cht-wc: Make error messages consistent

Before this commit the error messages were a mix of "Failed to ..." and "Error ...ing ...". This commit makes all the error messages consistently use "Error ...ing". Signed-off-by: Hans de Goede --- drivers/extcon/extcon-intel-cht-wc.c | 8 1 file changed, 4

[PATCH 1/3] extcon: intel-cht-wc: Make error messages consistent

Before this commit the error messages were a mix of "Failed to ..." and "Error ...ing ...". This commit makes all the error messages consistently use "Error ...ing". Signed-off-by: Hans de Goede --- drivers/extcon/extcon-intel-cht-wc.c | 8 1 file changed, 4 insertions(+), 4

[PATCH 2/3] extcon: intel-cht-wc: Disable external 5v boost converter on probe

Disable the 5v boost converter on probe in case it was left on by the BIOS, this fixes 2 problems: 1) This gets seen by the external battery charger as a valid Vbus supply and it then tries to feed Vsys from this creating a feedback loop which causes aprox. 300 mA extra battery drain

[PATCH 2/3] extcon: intel-cht-wc: Disable external 5v boost converter on probe

Disable the 5v boost converter on probe in case it was left on by the BIOS, this fixes 2 problems: 1) This gets seen by the external battery charger as a valid Vbus supply and it then tries to feed Vsys from this creating a feedback loop which causes aprox. 300 mA extra battery drain

pull-request: wireless-drivers-next 2017-04-03

Hi Dave, here few really small fixes. I'm hoping this to be the last pull request for 4.11. Please let me if there are any problems. Kalle The following changes since commit 6be3b6cce1e225f189b68b4e84fc711d19b4277b: ath10k: fix incorrect wlan_mac_base in qca6174_regs (2017-03-20 17:11:31

pull-request: wireless-drivers-next 2017-04-03

Hi Dave, here few really small fixes. I'm hoping this to be the last pull request for 4.11. Please let me if there are any problems. Kalle The following changes since commit 6be3b6cce1e225f189b68b4e84fc711d19b4277b: ath10k: fix incorrect wlan_mac_base in qca6174_regs (2017-03-20 17:11:31

Re: [RFC][PATCHv2 1/8] printk: move printk_pending out of per-cpu

On (03/31/17 15:33), Peter Zijlstra wrote: > On Fri, Mar 31, 2017 at 03:09:50PM +0200, Petr Mladek wrote: > > On Wed 2017-03-29 18:25:04, Sergey Senozhatsky wrote: > > > > if (waitqueue_active(_wait)) { > > > - this_cpu_or(printk_pending, PRINTK_PENDING_WAKEUP); > > > +

Re: [RFC][PATCHv2 1/8] printk: move printk_pending out of per-cpu

On (03/31/17 15:33), Peter Zijlstra wrote: > On Fri, Mar 31, 2017 at 03:09:50PM +0200, Petr Mladek wrote: > > On Wed 2017-03-29 18:25:04, Sergey Senozhatsky wrote: > > > > if (waitqueue_active(_wait)) { > > > - this_cpu_or(printk_pending, PRINTK_PENDING_WAKEUP); > > > +

[PATCH 1/1] arm64: tegra: fix PPI interrupt flag

The interrupt flag for PPI should not be set to any value, since the register is read-only. Fix the flags for the PPI interrupts to IRQ_TYPE_NONE, so that there is no write to the read-only register. Signed-off-by: Aniruddha Banerjee ---

Re: [PATCH v3 04/20] ARM: sun8i: dt: Add DT bindings documentation for Allwinner syscon

On Mon, Apr 03, 2017 at 11:14:28AM +0200, Corentin Labbe wrote: > Signed-off-by: Corentin Labbe > --- > .../devicetree/bindings/misc/allwinner,syscon.txt | 19 > +++ > 1 file changed, 19 insertions(+) > create mode 100644 >

[PATCH 1/1] arm64: tegra: fix PPI interrupt flag

The interrupt flag for PPI should not be set to any value, since the register is read-only. Fix the flags for the PPI interrupts to IRQ_TYPE_NONE, so that there is no write to the read-only register. Signed-off-by: Aniruddha Banerjee --- arch/arm64/boot/dts/nvidia/tegra132.dtsi | 8

Re: [PATCH v3 04/20] ARM: sun8i: dt: Add DT bindings documentation for Allwinner syscon

On Mon, Apr 03, 2017 at 11:14:28AM +0200, Corentin Labbe wrote: > Signed-off-by: Corentin Labbe > --- > .../devicetree/bindings/misc/allwinner,syscon.txt | 19 > +++ > 1 file changed, 19 insertions(+) > create mode 100644 >

Re: [PATCH v3 03/20] dt-bindings: net: Add DT bindings documentation for Allwinner dwmac-sun8i

On Mon, Apr 03, 2017 at 11:14:27AM +0200, Corentin Labbe wrote: > This patch adds documentation for Device-Tree bindings for the > Allwinner dwmac-sun8i driver. > > Signed-off-by: Corentin Labbe > Acked-by: Rob Herring > --- >

Re: [PATCH v3 03/20] dt-bindings: net: Add DT bindings documentation for Allwinner dwmac-sun8i

On Mon, Apr 03, 2017 at 11:14:27AM +0200, Corentin Labbe wrote: > This patch adds documentation for Device-Tree bindings for the > Allwinner dwmac-sun8i driver. > > Signed-off-by: Corentin Labbe > Acked-by: Rob Herring > --- > .../devicetree/bindings/net/dwmac-sun8i.txt| 77 >

Re: [PATCH] iommu/rockchip: Make use of 'struct iommu_device'

On Mon, Apr 03, 2017 at 01:11:01PM +0200, Heiko Stübner wrote: > ok, so you can at least add my > Tested-by: Heiko Stuebner > > on the patch Added and applied, thanks.

Re: [PATCH] iommu/rockchip: Make use of 'struct iommu_device'

On Mon, Apr 03, 2017 at 01:11:01PM +0200, Heiko Stübner wrote: > ok, so you can at least add my > Tested-by: Heiko Stuebner > > on the patch Added and applied, thanks.

Re: [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental

Hi Richard, On Thu, Mar 30, 2017 at 11:29:15PM +0200, Richard Weinberger wrote: > Jesper, > > Am 30.03.2017 um 19:39 schrieb Jesper Nilsson: > >> So we should document this with a big fat warning and set fastmap to > >> default=n ? > > > > Does this sound reasonable? > > > > Note that this

Re: [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental

Hi Richard, On Thu, Mar 30, 2017 at 11:29:15PM +0200, Richard Weinberger wrote: > Jesper, > > Am 30.03.2017 um 19:39 schrieb Jesper Nilsson: > >> So we should document this with a big fat warning and set fastmap to > >> default=n ? > > > > Does this sound reasonable? > > > > Note that this

Re: [PATCH 2/6] KVM: VMX: remove bogus check for invalid EPT violation

On 30.03.2017 11:55, Paolo Bonzini wrote: > handle_ept_violation is checking for "guest-linear-address invalid" + > "not a paging-structure walk". However, _all_ EPT violations without > a valid guest linear address are paging structure walks, because those > EPT violations happen when loading

Re: [RFC 00/10] V4L2 explicit synchronization support

Hi Gustavo, Em Mon, 13 Mar 2017 16:20:25 -0300 Gustavo Padovan escreveu: > From: Gustavo Padovan > > Hi, > > This RFC adds support for Explicit Synchronization of shared buffers in V4L2. > It uses the Sync File Framework[1] as vector to

Re: [PATCH 2/6] KVM: VMX: remove bogus check for invalid EPT violation

On 30.03.2017 11:55, Paolo Bonzini wrote: > handle_ept_violation is checking for "guest-linear-address invalid" + > "not a paging-structure walk". However, _all_ EPT violations without > a valid guest linear address are paging structure walks, because those > EPT violations happen when loading

Re: [RFC 00/10] V4L2 explicit synchronization support

Hi Gustavo, Em Mon, 13 Mar 2017 16:20:25 -0300 Gustavo Padovan escreveu: > From: Gustavo Padovan > > Hi, > > This RFC adds support for Explicit Synchronization of shared buffers in V4L2. > It uses the Sync File Framework[1] as vector to communicate the fences > between kernel and userspace.

Re: [PATCH v3 5/7] mfd: Add Device Tree bindings document for TI tps6105x chip

On Sat, 01 Apr 2017, Javier Martinez Canillas wrote: > There are Device Tree source files defining a device node for the > tps61050/61052 I2C chip but there isn't a binding document for it. > > Signed-off-by: Javier Martinez Canillas > --- > > Changes in v3: None >

Re: [PATCH v3 5/7] mfd: Add Device Tree bindings document for TI tps6105x chip

On Sat, 01 Apr 2017, Javier Martinez Canillas wrote: > There are Device Tree source files defining a device node for the > tps61050/61052 I2C chip but there isn't a binding document for it. > > Signed-off-by: Javier Martinez Canillas > --- > > Changes in v3: None > Changes in v2: None > >

Re: [PATCH 2/2] extcon: Add new extcon_register_notifier_all() to monitor all external connectors

Hi, On 03-04-17 09:24, Chanwoo Choi wrote: Hi, On 2017년 03월 30일 23:58, Hans de Goede wrote: Hi, On 30-03-17 11:20, Chanwoo Choi wrote: On 2017년 03월 30일 18:04, Hans de Goede wrote: Also this should be moved outside of the area of the function holding the edev->lock spinlock, since we

Re: [PATCH v3 2/7] mfd: retu: Add OF device ID table

On Sat, 01 Apr 2017, Javier Martinez Canillas wrote: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees. This is working on the assumption that a > I2C device registered via OF will always match a legacy I2C device ID and > that the

Re: [PATCH 2/2] extcon: Add new extcon_register_notifier_all() to monitor all external connectors

Hi, On 03-04-17 09:24, Chanwoo Choi wrote: Hi, On 2017년 03월 30일 23:58, Hans de Goede wrote: Hi, On 30-03-17 11:20, Chanwoo Choi wrote: On 2017년 03월 30일 18:04, Hans de Goede wrote: Also this should be moved outside of the area of the function holding the edev->lock spinlock, since we

Re: [PATCH v3 2/7] mfd: retu: Add OF device ID table

On Sat, 01 Apr 2017, Javier Martinez Canillas wrote: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees. This is working on the assumption that a > I2C device registered via OF will always match a legacy I2C device ID and > that the

Re: [PATCH v3 1/7] mfd: Add Device Tree bindings document for retu/tahvo ASIC chips

On Sat, 01 Apr 2017, Javier Martinez Canillas wrote: > There are Device Tree source files defining a device node for the > retu/tahvo I2C chip, but there isn't a DT binding document for it. > > Signed-off-by: Javier Martinez Canillas > --- > > Changes in v3: None >

Re: [PATCH v3 1/7] mfd: Add Device Tree bindings document for retu/tahvo ASIC chips

On Sat, 01 Apr 2017, Javier Martinez Canillas wrote: > There are Device Tree source files defining a device node for the > retu/tahvo I2C chip, but there isn't a DT binding document for it. > > Signed-off-by: Javier Martinez Canillas > --- > > Changes in v3: None > Changes in v2: None > >

Re: [PATCH 9/9] [media] cx231xx: stop double error reporting

On 2017-04-03 12:26, Wolfram Sang wrote: > On Mon, Apr 03, 2017 at 10:38:38AM +0200, Peter Rosin wrote: >> i2c_mux_add_adapter already logs a message on failure. >> >> Signed-off-by: Peter Rosin >> --- >> drivers/media/usb/cx231xx/cx231xx-i2c.c | 15 --- >> 1 file

Re: [PATCH 9/9] [media] cx231xx: stop double error reporting

On 2017-04-03 12:26, Wolfram Sang wrote: > On Mon, Apr 03, 2017 at 10:38:38AM +0200, Peter Rosin wrote: >> i2c_mux_add_adapter already logs a message on failure. >> >> Signed-off-by: Peter Rosin >> --- >> drivers/media/usb/cx231xx/cx231xx-i2c.c | 15 --- >> 1 file changed, 4

Re: [kbuild-all] [PATCH v3 1/3] mfd: intel_soc_pmic: Fix a mess with compilation units

On Mon, Apr 3, 2017 at 2:06 PM, Fengguang Wu wrote: > On Mon, Apr 03, 2017 at 12:26:54PM +0300, Andy Shevchenko wrote: >> On Mon, Apr 3, 2017 at 12:20 PM, Lee Jones wrote: >>> On Sun, 02 Apr 2017, Andy Shevchenko wrote: On Sun, Apr 2, 2017 at 11:03 PM,

Re: [kbuild-all] [PATCH v3 1/3] mfd: intel_soc_pmic: Fix a mess with compilation units

On Mon, Apr 3, 2017 at 2:06 PM, Fengguang Wu wrote: > On Mon, Apr 03, 2017 at 12:26:54PM +0300, Andy Shevchenko wrote: >> On Mon, Apr 3, 2017 at 12:20 PM, Lee Jones wrote: >>> On Sun, 02 Apr 2017, Andy Shevchenko wrote: On Sun, Apr 2, 2017 at 11:03 PM, kbuild test robot wrote: >

Re: [PATCH] iommu/rockchip: Make use of 'struct iommu_device'

Am Montag, 3. April 2017, 13:07:58 CEST schrieb Joerg Roedel: > Hey Heiko, > > On Mon, Apr 03, 2017 at 11:56:59AM +0200, Heiko Stübner wrote: > > In general works, and I still keep a working iommu-based display :-) > > I can also see my two vop iommus under /sys/class/iommu now. > > Great,

Re: [PATCH] iommu/rockchip: Make use of 'struct iommu_device'

Am Montag, 3. April 2017, 13:07:58 CEST schrieb Joerg Roedel: > Hey Heiko, > > On Mon, Apr 03, 2017 at 11:56:59AM +0200, Heiko Stübner wrote: > > In general works, and I still keep a working iommu-based display :-) > > I can also see my two vop iommus under /sys/class/iommu now. > > Great,

[PATCH 1/1] nios2: implement flush_dcache_mmap_lock/unlock

Use spin_lock/unlock_irq instead of doing nothing. This fixes corruptions of the vma_interval_tree causing the kernel to be stuck in an infinite loop in vma_interval_tree_foreach. Signed-off-by: Julien Beraud --- arch/nios2/include/asm/cacheflush.h | 6

[PATCH 1/1] nios2: implement flush_dcache_mmap_lock/unlock

Use spin_lock/unlock_irq instead of doing nothing. This fixes corruptions of the vma_interval_tree causing the kernel to be stuck in an infinite loop in vma_interval_tree_foreach. Signed-off-by: Julien Beraud --- arch/nios2/include/asm/cacheflush.h | 6 -- 1 file changed, 4 insertions(+), 2

Re: [PATCH] iommu/rockchip: Make use of 'struct iommu_device'

Hey Heiko, On Mon, Apr 03, 2017 at 11:56:59AM +0200, Heiko Stübner wrote: > In general works, and I still keep a working iommu-based display :-) > I can also see my two vop iommus under /sys/class/iommu now. Great, thanks for testing that patch! > Links in the devices subdirectory do not work

Re: [PATCH] iommu/rockchip: Make use of 'struct iommu_device'

Hey Heiko, On Mon, Apr 03, 2017 at 11:56:59AM +0200, Heiko Stübner wrote: > In general works, and I still keep a working iommu-based display :-) > I can also see my two vop iommus under /sys/class/iommu now. Great, thanks for testing that patch! > Links in the devices subdirectory do not work

Re: [kbuild-all] [PATCH v3 1/3] mfd: intel_soc_pmic: Fix a mess with compilation units

On Mon, Apr 03, 2017 at 12:26:54PM +0300, Andy Shevchenko wrote: On Mon, Apr 3, 2017 at 12:20 PM, Lee Jones wrote: On Sun, 02 Apr 2017, Andy Shevchenko wrote: On Sun, Apr 2, 2017 at 11:03 PM, kbuild test robot wrote: > Hi Andy, > > [auto build test

Re: [PATCH RESEND v5 7/7] mfd: dt-bindings: Add RK805 device tree bindings document

On Mon, 27 Mar 2017, Elaine Zhang wrote: > Add device tree bindings documentation for Rockchip's RK805 PMIC. > > Signed-off-by: Elaine Zhang > --- > Documentation/devicetree/bindings/mfd/rk808.txt | 22 +- > 1 file changed, 21 insertions(+), 1

Re: [kbuild-all] [PATCH v3 1/3] mfd: intel_soc_pmic: Fix a mess with compilation units

On Mon, Apr 03, 2017 at 12:26:54PM +0300, Andy Shevchenko wrote: On Mon, Apr 3, 2017 at 12:20 PM, Lee Jones wrote: On Sun, 02 Apr 2017, Andy Shevchenko wrote: On Sun, Apr 2, 2017 at 11:03 PM, kbuild test robot wrote: > Hi Andy, > > [auto build test ERROR on ljones-mfd/for-mfd-next] > [also

Re: [PATCH RESEND v5 7/7] mfd: dt-bindings: Add RK805 device tree bindings document

On Mon, 27 Mar 2017, Elaine Zhang wrote: > Add device tree bindings documentation for Rockchip's RK805 PMIC. > > Signed-off-by: Elaine Zhang > --- > Documentation/devicetree/bindings/mfd/rk808.txt | 22 +- > 1 file changed, 21 insertions(+), 1 deletion(-) For my own

[GIT PULL] s390 patches for 4.11-rc6

Hi Linus, please pull from the 'for-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive the following updates: Four bug fixes, two of them for stable: - Avoid initrd corruptions in the kernel decompressor - Prevent inconsistent dumps

[GIT PULL] s390 patches for 4.11-rc6

Hi Linus, please pull from the 'for-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive the following updates: Four bug fixes, two of them for stable: - Avoid initrd corruptions in the kernel decompressor - Prevent inconsistent dumps

Re: [PATCH v5 4/7] mfd: rk808: Add RK805 support

On Mon, 27 Mar 2017, Elaine Zhang wrote: > The RK805 chip is a Power Management IC (PMIC) for multimedia and handheld > devices. It contains the following components: > > - Regulators > - RTC > - Clocking > > Both RK808 and RK805 chips are using a similar register map, > so we can

Re: [PATCH v5 4/7] mfd: rk808: Add RK805 support

On Mon, 27 Mar 2017, Elaine Zhang wrote: > The RK805 chip is a Power Management IC (PMIC) for multimedia and handheld > devices. It contains the following components: > > - Regulators > - RTC > - Clocking > > Both RK808 and RK805 chips are using a similar register map, > so we can

Re: [PATCH v5 2/7] mfd: rk808: add rk805 regs addr and ID

On Mon, 27 Mar 2017, Elaine Zhang wrote: > Signed-off-by: Elaine Zhang > --- > include/linux/mfd/rk808.h | 120 > ++ > 1 file changed, 120 insertions(+) For my own reference: Acked-for-MFD-by: Lee Jones

Re: [PATCH v5 2/7] mfd: rk808: add rk805 regs addr and ID

On Mon, 27 Mar 2017, Elaine Zhang wrote: > Signed-off-by: Elaine Zhang > --- > include/linux/mfd/rk808.h | 120 > ++ > 1 file changed, 120 insertions(+) For my own reference: Acked-for-MFD-by: Lee Jones > diff --git a/include/linux/mfd/rk808.h

Re: [PATCH v5 1/7] mfd: rk808: fix up the chip id get failed

On Mon, 27 Mar 2017, Elaine Zhang wrote: > the rk8xx chip id is: > ((MSB << 8) | LSB) & 0xfff0 > > Signed-off-by: Elaine Zhang > --- It's usually helpful to keep a changelog here: v3 => v4: - Stuff that happened v2 => v3: - Stuff that happened v1 => v2: - Stuff

Re: [PATCH v5 1/7] mfd: rk808: fix up the chip id get failed

On Mon, 27 Mar 2017, Elaine Zhang wrote: > the rk8xx chip id is: > ((MSB << 8) | LSB) & 0xfff0 > > Signed-off-by: Elaine Zhang > --- It's usually helpful to keep a changelog here: v3 => v4: - Stuff that happened v2 => v3: - Stuff that happened v1 => v2: - Stuff that happened >

Re: [PATCH] driver: rtc: tps65910: Add parameter check

Hi, On 15/03/2017 at 11:52:32 +0100, Daniel Schultz wrote: > If the tps65910 driver has no interrupt, the probe of tps65910-rtc will > fail. > > This patch adds a check in the probe of the rtc if an interrupt exist. > The check is similar to the check in the function which creates the >

Re: [PATCH] driver: rtc: tps65910: Add parameter check

Hi, On 15/03/2017 at 11:52:32 +0100, Daniel Schultz wrote: > If the tps65910 driver has no interrupt, the probe of tps65910-rtc will > fail. > > This patch adds a check in the probe of the rtc if an interrupt exist. > The check is similar to the check in the function which creates the >

Re: Bad page state splats on arm64, v4.11-rc{3,4}

On Fri, Mar 31, 2017 at 06:58:45PM +0100, Mark Rutland wrote: > Hi, > > I'm seeing intermittent bad page state splats on arm64 with 4.11-rc3 and > v4.11-rc4. I have not tested earlier kernels, or other architectures. > > So far, it looks like the flags are always bad in the same > way: > >

Re: Bad page state splats on arm64, v4.11-rc{3,4}

On Fri, Mar 31, 2017 at 06:58:45PM +0100, Mark Rutland wrote: > Hi, > > I'm seeing intermittent bad page state splats on arm64 with 4.11-rc3 and > v4.11-rc4. I have not tested earlier kernels, or other architectures. > > So far, it looks like the flags are always bad in the same > way: > >

<    8   9   10   11   12   13   14   15   16   17   >