[PATCH 1/8] pinctrl: meson: gxbb: add i2s output pins

Signed-off-by: Jerome Brunet --- drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 31 ++ 1 file changed, 31 insertions(+) diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c index

Re: [PATCH v3 04/11] Documentation: DT: bindings: mfd: add A33 GPADC binding

On Tue, 21 Mar 2017, Quentin Schulz wrote: > This patch adds documentation for the A33 GPADC binding. > > Signed-off-by: Quentin Schulz > --- > > v3: > - fixed missing allwinner in front of compatible, > - updated compatible to allwinner,sun8i-a33-ths to

[PATCH 1/8] pinctrl: meson: gxbb: add i2s output pins

Signed-off-by: Jerome Brunet --- drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 31 ++ 1 file changed, 31 insertions(+) diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c index 7671424d46cb..8d5dd4772042 100644 ---

Re: [PATCH v3 04/11] Documentation: DT: bindings: mfd: add A33 GPADC binding

On Tue, 21 Mar 2017, Quentin Schulz wrote: > This patch adds documentation for the A33 GPADC binding. > > Signed-off-by: Quentin Schulz > --- > > v3: > - fixed missing allwinner in front of compatible, > - updated compatible to allwinner,sun8i-a33-ths to better reflect the > datasheet's

Re: [PATCH 2/5] mfd: intel_soc_pmic: Select designware i2c-bus driver

On Wed, 22 Mar 2017, Andy Shevchenko wrote: > On Wed, 2017-03-22 at 12:29 +0100, Hans de Goede wrote: > > The Crystal Cove PMIC provides an ACPI OPRegion handler, which must be > > available before other drivers using it are loaded, which is why > > INTEL_SOC_PMIC is a bool. > > > > Just having

Re: [PATCH 2/5] mfd: intel_soc_pmic: Select designware i2c-bus driver

On Wed, 22 Mar 2017, Andy Shevchenko wrote: > On Wed, 2017-03-22 at 12:29 +0100, Hans de Goede wrote: > > The Crystal Cove PMIC provides an ACPI OPRegion handler, which must be > > available before other drivers using it are loaded, which is why > > INTEL_SOC_PMIC is a bool. > > > > Just having

Re: [Xen-devel] [PATCH 0/2 v2] xen/acpi: upload PM state from init-domain to Xen

On 03/21/2017 06:43 PM, Ankur Arora wrote: > This patch series re-enables the upload of PM data from initial-domain > to Xen. This was broken in commit cd979883b9ede90643e019f33cb317933eb867b4. > > The upload now happens post-resume in workqueue context. From the > POV of Xen, the PM upload might

Re: [Xen-devel] [PATCH 0/2 v2] xen/acpi: upload PM state from init-domain to Xen

On 03/21/2017 06:43 PM, Ankur Arora wrote: > This patch series re-enables the upload of PM data from initial-domain > to Xen. This was broken in commit cd979883b9ede90643e019f33cb317933eb867b4. > > The upload now happens post-resume in workqueue context. From the > POV of Xen, the PM upload might

Re: [PATCH v2 1/3] mfd: Add Cherry Trail Whiskey Cove PMIC driver

On Mon, 20 Mar 2017, Hans de Goede wrote: > Add mfd driver for Intel CHT Whiskey Cove PMIC, based on various non > upstreamed CHT Whiskey Cove PMIC patches. > > This is a somewhat minimal version which adds irqchip support and cells > for: ACPI PMIC opregion support, the i2c-controller driving

Re: [PATCH v2 1/3] mfd: Add Cherry Trail Whiskey Cove PMIC driver

On Mon, 20 Mar 2017, Hans de Goede wrote: > Add mfd driver for Intel CHT Whiskey Cove PMIC, based on various non > upstreamed CHT Whiskey Cove PMIC patches. > > This is a somewhat minimal version which adds irqchip support and cells > for: ACPI PMIC opregion support, the i2c-controller driving

Re: kvm: BUG in pte_list_remove

On Mon, Nov 14, 2016 at 10:43 AM, Dmitry Vyukov wrote: > On Mon, Nov 14, 2016 at 10:34 AM, Paolo Bonzini wrote: >> >> >> On 14/11/2016 10:03, Dmitry Vyukov wrote: >>> Paolo, >>> can you please also commit this test to tools/testing? We are >>> frustrated

Re: kvm: BUG in pte_list_remove

On Mon, Nov 14, 2016 at 10:43 AM, Dmitry Vyukov wrote: > On Mon, Nov 14, 2016 at 10:34 AM, Paolo Bonzini wrote: >> >> >> On 14/11/2016 10:03, Dmitry Vyukov wrote: >>> Paolo, >>> can you please also commit this test to tools/testing? We are >>> frustrated by the situation that we reported

Re: [PATCH] tpm2: fix off-by-one comparison and out-of-bounds read error

On Thu, Mar 23, 2017 at 05:53:58PM +0200, Jarkko Sakkinen wrote: > On Wed, Mar 22, 2017 at 04:12:49PM +0300, Dan Carpenter wrote: > > On Wed, Mar 22, 2017 at 11:45:37AM +, Colin Ian King wrote: > > > On 22/03/17 11:42, Jarkko Sakkinen wrote: > > > > On Mon, Mar 20, 2017 at 02:23:36PM +,

Re: [PATCH] tpm2: fix off-by-one comparison and out-of-bounds read error

On Thu, Mar 23, 2017 at 05:53:58PM +0200, Jarkko Sakkinen wrote: > On Wed, Mar 22, 2017 at 04:12:49PM +0300, Dan Carpenter wrote: > > On Wed, Mar 22, 2017 at 11:45:37AM +, Colin Ian King wrote: > > > On 22/03/17 11:42, Jarkko Sakkinen wrote: > > > > On Mon, Mar 20, 2017 at 02:23:36PM +,

Re: [REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") causes crashes in guest

On Thu, Mar 23, 2017 at 03:19:07PM +, Richard W.M. Jones wrote: > On Thu, Mar 23, 2017 at 01:13:50PM +0800, Jason Wang wrote: > > >From 312859b596e83a2164a8430343d31fce2a5ad808 Mon Sep 17 00:00:00 2001 > > From: Jason Wang > > Date: Thu, 23 Mar 2017 13:07:16 +0800 > >

Re: [REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") causes crashes in guest

On Thu, Mar 23, 2017 at 03:19:07PM +, Richard W.M. Jones wrote: > On Thu, Mar 23, 2017 at 01:13:50PM +0800, Jason Wang wrote: > > >From 312859b596e83a2164a8430343d31fce2a5ad808 Mon Sep 17 00:00:00 2001 > > From: Jason Wang > > Date: Thu, 23 Mar 2017 13:07:16 +0800 > > Subject: [PATCH]

Re: [PATCH v2 2/4] mvebu: xp: Add pwm properties to .dtsi files

Hi Ralph, On sam., mars 18 2017, Ralph Sennhauser wrote: It seems that I don't receive the 1st patch of the series. Also could you refresh my mind to expose why these patchse were not apply the first time and why we should apply them now? Thanks, Gregory >

Re: [PATCH v2 2/4] mvebu: xp: Add pwm properties to .dtsi files

Hi Ralph, On sam., mars 18 2017, Ralph Sennhauser wrote: It seems that I don't receive the 1st patch of the series. Also could you refresh my mind to expose why these patchse were not apply the first time and why we should apply them now? Thanks, Gregory > From: Andrew Lunn > > Add

Re: [PATCH v1] KVM: kvm_io_bus_unregister_dev() should never fail

On Thu, 23 Mar 2017 17:20:48 +0100 David Hildenbrand wrote: > > > As this may set kvm->buses[bus_idx] to NULL, don't you also need to > > guard for bus == NULL in kvm_io_bus_destroy()? (I looked at the code on > > kvm/queue.) > > very right, so something like this? > > diff

Re: [PATCH v1] KVM: kvm_io_bus_unregister_dev() should never fail

On Thu, 23 Mar 2017 17:20:48 +0100 David Hildenbrand wrote: > > > As this may set kvm->buses[bus_idx] to NULL, don't you also need to > > guard for bus == NULL in kvm_io_bus_destroy()? (I looked at the code on > > kvm/queue.) > > very right, so something like this? > > diff --git

Re: kvm: WARNING in mmu_spte_clear_track_bits

On Tue, Mar 14, 2017 at 4:17 PM, Radim Krčmář wrote: > 2017-03-12 12:20+0100, Dmitry Vyukov: >> On Tue, Jan 17, 2017 at 5:00 PM, Dmitry Vyukov wrote: >>> On Tue, Jan 17, 2017 at 4:20 PM, Paolo Bonzini wrote: On

Re: kvm: WARNING in mmu_spte_clear_track_bits

On Tue, Mar 14, 2017 at 4:17 PM, Radim Krčmář wrote: > 2017-03-12 12:20+0100, Dmitry Vyukov: >> On Tue, Jan 17, 2017 at 5:00 PM, Dmitry Vyukov wrote: >>> On Tue, Jan 17, 2017 at 4:20 PM, Paolo Bonzini wrote: On 13/01/2017 12:15, Dmitry Vyukov wrote: > > I've commented out

Re: [PATCH] hibernation: on 32-bit x86, disabled in favor of KASLR

Hi, On Thu, Mar 23, 2017 at 9:23 PM, Evgenii Shatokhin wrote: > On 23.03.2017 03:27, Kees Cook wrote: >> >> This is a modified revert of commit 65fe935dd238 ("x86/KASLR, x86/power: >> Remove x86 hibernation restrictions"), since it appears that 32-bit >> hibernation

Re: [PATCH] hibernation: on 32-bit x86, disabled in favor of KASLR

Hi, On Thu, Mar 23, 2017 at 9:23 PM, Evgenii Shatokhin wrote: > On 23.03.2017 03:27, Kees Cook wrote: >> >> This is a modified revert of commit 65fe935dd238 ("x86/KASLR, x86/power: >> Remove x86 hibernation restrictions"), since it appears that 32-bit >> hibernation still can't support KASLR.

[PATCH v6 1/4] irqchip: mips-gic: Add context saving for MIPS_REMOTEPROC

The MIPS remote processor driver allows non-Linux firmware to take control of and execute on one of the systems VPEs. If that VPE is brought back under Linux, it is necessary to ensure that all GIC interrupts are routed and masked as Linux expects them, as the firmware can have done anything it

[PATCH v6 1/4] irqchip: mips-gic: Add context saving for MIPS_REMOTEPROC

The MIPS remote processor driver allows non-Linux firmware to take control of and execute on one of the systems VPEs. If that VPE is brought back under Linux, it is necessary to ensure that all GIC interrupts are routed and masked as Linux expects them, as the firmware can have done anything it

[PATCH v6 4/4] MIPS: Deprecate VPE Loader

The MIPS remote processor driver (CONFIG_MIPS_REMOTEPROC) provides a more standard mechanism for using one or more VPs as coprocessors running separate firmware. Here we deprecate this mechanism before it is removed. Signed-off-by: Matt Redfearn --- Changes in v6:

[PATCH v6 4/4] MIPS: Deprecate VPE Loader

The MIPS remote processor driver (CONFIG_MIPS_REMOTEPROC) provides a more standard mechanism for using one or more VPs as coprocessors running separate firmware. Here we deprecate this mechanism before it is removed. Signed-off-by: Matt Redfearn --- Changes in v6: None Changes in v5: None

[PATCH v6 2/4] MIPS: CPS: Add VP(E) stealing

From: Lisa Parratt VP(E) stealing provides a mechanism for removing an offline Virtual Processor from the Linux kernel such that it is available to run bare metal code. Once the CPU has been offlined from Linux, the CPU can be given a task to run via

[PATCH v6 2/4] MIPS: CPS: Add VP(E) stealing

From: Lisa Parratt VP(E) stealing provides a mechanism for removing an offline Virtual Processor from the Linux kernel such that it is available to run bare metal code. Once the CPU has been offlined from Linux, the CPU can be given a task to run via mips_cps_steal_cpu_and_execute(). The CPU is

[PATCH v6 0/4] MIPS: Remote processor driver

The MIPS remote processor driver allows non-Linux firmware to take control of and execute on one of the systems VPEs, turning the system into a hybrid of SMP Linux and AMP. This is useful to allow running bare metal code, or an RTOS, on one or more CPUs while allowing Linux to continue running

[PATCH v6 3/4] remoteproc/MIPS: Add a remoteproc driver for MIPS

This driver allows a MIPS processor offlined from Linux to be used as a remote processor. The processor can then handle real-time tasks or perform coprocessing while remaining processors are available to Linux, effectively making the system hybrid of SMP Linux and AMP. A sysfs interface is

[PATCH v6 0/4] MIPS: Remote processor driver

The MIPS remote processor driver allows non-Linux firmware to take control of and execute on one of the systems VPEs, turning the system into a hybrid of SMP Linux and AMP. This is useful to allow running bare metal code, or an RTOS, on one or more CPUs while allowing Linux to continue running

[PATCH v6 3/4] remoteproc/MIPS: Add a remoteproc driver for MIPS

This driver allows a MIPS processor offlined from Linux to be used as a remote processor. The processor can then handle real-time tasks or perform coprocessing while remaining processors are available to Linux, effectively making the system hybrid of SMP Linux and AMP. A sysfs interface is

Re: [PATCH] tpm2: fix off-by-one comparison and out-of-bounds read error

On Thu, Mar 23, 2017 at 05:53:58PM +0200, Jarkko Sakkinen wrote: > On Wed, Mar 22, 2017 at 04:12:49PM +0300, Dan Carpenter wrote: > > On Wed, Mar 22, 2017 at 11:45:37AM +, Colin Ian King wrote: > > > On 22/03/17 11:42, Jarkko Sakkinen wrote: > > > > On Mon, Mar 20, 2017 at 02:23:36PM +,

Re: [PATCH] tpm2: fix off-by-one comparison and out-of-bounds read error

On Thu, Mar 23, 2017 at 05:53:58PM +0200, Jarkko Sakkinen wrote: > On Wed, Mar 22, 2017 at 04:12:49PM +0300, Dan Carpenter wrote: > > On Wed, Mar 22, 2017 at 11:45:37AM +, Colin Ian King wrote: > > > On 22/03/17 11:42, Jarkko Sakkinen wrote: > > > > On Mon, Mar 20, 2017 at 02:23:36PM +,

Re: [PATCH 1/2] mfd: hi655x: Reference required regulator driver

On Mon, 20 Mar 2017, Jeremy Linton wrote: > The hisi pmic requires an independent regulator driver to be > loaded so that devices dependent on the pmic/regulator are > started properly. Currently there is only a single compatible > regulator driver in the tree, so reference it with a module soft

Re: [PATCH 1/2] mfd: hi655x: Reference required regulator driver

On Mon, 20 Mar 2017, Jeremy Linton wrote: > The hisi pmic requires an independent regulator driver to be > loaded so that devices dependent on the pmic/regulator are > started properly. Currently there is only a single compatible > regulator driver in the tree, so reference it with a module soft

Re: linux-next: manual merge of the gpio tree with the input tree

On Thu, Mar 23, 2017 at 2:27 AM, Linus Walleij wrote: > On Mon, Mar 20, 2017 at 5:03 AM, Stephen Rothwell > wrote: >> Hi Linus, >> >> Today's linux-next merge of the gpio tree got a conflict in: >> >> drivers/input/misc/soc_button_array.c >> >>

Re: linux-next: manual merge of the gpio tree with the input tree

On Thu, Mar 23, 2017 at 2:27 AM, Linus Walleij wrote: > On Mon, Mar 20, 2017 at 5:03 AM, Stephen Rothwell > wrote: >> Hi Linus, >> >> Today's linux-next merge of the gpio tree got a conflict in: >> >> drivers/input/misc/soc_button_array.c >> >> between commit: >> >> a01cd17000a4 ("Input:

Re: [PATCH v2] ARM: dts: mvebu: linksys: enable buffer manager support

Hi Ralph, On jeu., mars 16 2017, Ralph Sennhauser wrote: > Add appropriate properties to devices in the Linksys WRT AC Series for the > mvneta driver to use hardware buffer management. > > Also update "soc" ranges property and set the status of bm and bm-bppi > to

Re: [PATCH v2] ARM: dts: mvebu: linksys: enable buffer manager support

Hi Ralph, On jeu., mars 16 2017, Ralph Sennhauser wrote: > Add appropriate properties to devices in the Linksys WRT AC Series for the > mvneta driver to use hardware buffer management. > > Also update "soc" ranges property and set the status of bm and bm-bppi > to "okay" (SRAM). > >

[RFT PATCH 2/6] ARM64: dts: meson-gxl: Add gpio-ranges properties

Signed-off-by: Neil Armstrong --- arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi index fe11b5f..64f4b6e 100644 ---

[RFT PATCH 2/6] ARM64: dts: meson-gxl: Add gpio-ranges properties

Signed-off-by: Neil Armstrong --- arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi index fe11b5f..64f4b6e 100644 ---

[RFT PATCH 3/6] ARM: dts: meson8: Add gpio-ranges properties

Signed-off-by: Neil Armstrong --- arch/arm/boot/dts/meson8.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi index 45619f6..ebc763e 100644 --- a/arch/arm/boot/dts/meson8.dtsi +++

[RFT PATCH 3/6] ARM: dts: meson8: Add gpio-ranges properties

Signed-off-by: Neil Armstrong --- arch/arm/boot/dts/meson8.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi index 45619f6..ebc763e 100644 --- a/arch/arm/boot/dts/meson8.dtsi +++ b/arch/arm/boot/dts/meson8.dtsi @@ -106,6

[RFT PATCH 0/6] pinctrl: meson: Fix gpio-ranged for GPIO Hog

Whem trying to add a gpio hog to enable the USB Hub on the Odroid-C2, I encountered a strange bug where when calling gpiochip_add_data() the gpiolib code was trying to add the Hog but failed because the gpio ranges were missing. In the meson-pinctrl driver, the gpio ranges are added manually

[RFT PATCH 0/6] pinctrl: meson: Fix gpio-ranged for GPIO Hog

Whem trying to add a gpio hog to enable the USB Hub on the Odroid-C2, I encountered a strange bug where when calling gpiochip_add_data() the gpiolib code was trying to add the Hog but failed because the gpio ranges were missing. In the meson-pinctrl driver, the gpio ranges are added manually

[RFT PATCH 4/6] ARM: dts: meson8b: Add gpio-ranges properties

Signed-off-by: Neil Armstrong --- arch/arm/boot/dts/meson8b.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi index 41fd536..828aa49 100644 --- a/arch/arm/boot/dts/meson8b.dtsi +++

[RFT PATCH 5/6] pinctrl: meson: use gpio-ranges from DT

When trying to add a gpio-hog, we enter a weird loop where the gpio-ranges is needed when gpiochip_add_data() is called but in the current implementation the ranges are added from the driver afterwards. A simple solution is to rely on the DR gpio-ranges attribute and remove the call to

[RFT PATCH 4/6] ARM: dts: meson8b: Add gpio-ranges properties

Signed-off-by: Neil Armstrong --- arch/arm/boot/dts/meson8b.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi index 41fd536..828aa49 100644 --- a/arch/arm/boot/dts/meson8b.dtsi +++ b/arch/arm/boot/dts/meson8b.dtsi @@ -198,6

[RFT PATCH 5/6] pinctrl: meson: use gpio-ranges from DT

When trying to add a gpio-hog, we enter a weird loop where the gpio-ranges is needed when gpiochip_add_data() is called but in the current implementation the ranges are added from the driver afterwards. A simple solution is to rely on the DR gpio-ranges attribute and remove the call to

[RFT PATCH 6/6] ARM64: dts: meson-gxbb: Add USB Hub GPIO hog

The ODroid-C2 on-board USB Hub needs to to have it's reset signal set to high level in order to be enumerated by the USB Host Controller. But this management must be part of the currently in-development Generic Power Sequence patch that will allow a USB Controller driver to start and stop a power

[RFT PATCH 6/6] ARM64: dts: meson-gxbb: Add USB Hub GPIO hog

The ODroid-C2 on-board USB Hub needs to to have it's reset signal set to high level in order to be enumerated by the USB Host Controller. But this management must be part of the currently in-development Generic Power Sequence patch that will allow a USB Controller driver to start and stop a power

[RFT PATCH 1/6] ARM64: dts: meson-gxbb: Add gpio-ranges properties

Signed-off-by: Neil Armstrong --- arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi index 04b3324..84c590b 100644 ---

[RFT PATCH 1/6] ARM64: dts: meson-gxbb: Add gpio-ranges properties

Signed-off-by: Neil Armstrong --- arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi index 04b3324..84c590b 100644 ---

Re: [PATCH v2 05/23] MAINTAINERS: Add file patterns for dove device tree bindings

Hi Geert, On dim., mars 12 2017, Geert Uytterhoeven wrote: > Submitters of device tree binding documentation may forget to CC > the subsystem maintainer if this is missing. > > Signed-off-by: Geert Uytterhoeven > Cc: Jason Cooper

Re: [PATCH v2 05/23] MAINTAINERS: Add file patterns for dove device tree bindings

Hi Geert, On dim., mars 12 2017, Geert Uytterhoeven wrote: > Submitters of device tree binding documentation may forget to CC > the subsystem maintainer if this is missing. > > Signed-off-by: Geert Uytterhoeven > Cc: Jason Cooper > Cc: Andrew Lunn > Cc: Sebastian Hesselbarth > Cc: Gregory

Re: [PATCH] printk: use console_trylock() in console_cpu_notify()

On Wed 2017-01-25 16:02:36, Petr Mladek wrote: > On Sat 2017-01-21 19:47:29, Sergey Senozhatsky wrote: > > There is no need to always call blocking console_lock() in > > console_cpu_notify(), it's quite possible that console_sem can > > be locked by other CPU on the system, either already printing

Re: [PATCH] printk: use console_trylock() in console_cpu_notify()

On Wed 2017-01-25 16:02:36, Petr Mladek wrote: > On Sat 2017-01-21 19:47:29, Sergey Senozhatsky wrote: > > There is no need to always call blocking console_lock() in > > console_cpu_notify(), it's quite possible that console_sem can > > be locked by other CPU on the system, either already printing

Re: [PATCH v3 02/12] irqchip: mtk-sysirq: extend intpol base to arbitrary number

On 19/03/17 15:26, Mars Cheng wrote: > Originally driver only supports one base. However, MT6797 has > more than one bases to configure interrupt polarity. To support > possible design change, here comes a solution to use arbitrary > number of bases. > > Signed-off-by: Mars Cheng

Re: [PATCH v3 02/12] irqchip: mtk-sysirq: extend intpol base to arbitrary number

On 19/03/17 15:26, Mars Cheng wrote: > Originally driver only supports one base. However, MT6797 has > more than one bases to configure interrupt polarity. To support > possible design change, here comes a solution to use arbitrary > number of bases. > > Signed-off-by: Mars Cheng Acked-by: Marc

Re: [PATCH v1] KVM: kvm_io_bus_unregister_dev() should never fail

> As this may set kvm->buses[bus_idx] to NULL, don't you also need to > guard for bus == NULL in kvm_io_bus_destroy()? (I looked at the code on > kvm/queue.) very right, so something like this? diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index e1be4b4..ef1aa7f 100644 ---

Re: [PATCH v1] KVM: kvm_io_bus_unregister_dev() should never fail

> As this may set kvm->buses[bus_idx] to NULL, don't you also need to > guard for bus == NULL in kvm_io_bus_destroy()? (I looked at the code on > kvm/queue.) very right, so something like this? diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index e1be4b4..ef1aa7f 100644 ---

Re: next build: 208 builds: 9 failed, 199 passed, 857 errors, 444 warnings (next-20170323)

On Thu, Mar 23, 2017 at 6:46 AM, kernelci.org bot wrote: > acs5k_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches > > Warnings: > :1328:2: warning: #warning syscall arch_prctl not implemented [-Wcpp] > :1328:2: warning: #warning syscall arch_prctl not

Re: next build: 208 builds: 9 failed, 199 passed, 857 errors, 444 warnings (next-20170323)

On Thu, Mar 23, 2017 at 6:46 AM, kernelci.org bot wrote: > acs5k_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches > > Warnings: > :1328:2: warning: #warning syscall arch_prctl not implemented [-Wcpp] > :1328:2: warning: #warning syscall arch_prctl not implemented [-Wcpp] patch

Re: [PATCH v2 4/7] arm: dts: r7s72100: Add pin controller node

Hi Geert, On Wed, Mar 22, 2017 at 02:12:04PM +0100, Geert Uytterhoeven wrote: > Hi Jacopo, > > On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi > wrote: > > Add pin controller node with 12 gpio controller sub-nodes to > > r7s72100 dtsi. > > > > Signed-off-by: Jacopo

Re: [PATCH v2 4/7] arm: dts: r7s72100: Add pin controller node

Hi Geert, On Wed, Mar 22, 2017 at 02:12:04PM +0100, Geert Uytterhoeven wrote: > Hi Jacopo, > > On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi > wrote: > > Add pin controller node with 12 gpio controller sub-nodes to > > r7s72100 dtsi. > > > > Signed-off-by: Jacopo Mondi > > Reviewed-by: Geert

Re: [PATCH v3 03/12] irqchip: mtk-sysirq: prevent unnecessary visibility when set_type

On 19/03/17 15:26, Mars Cheng wrote: > This prevent unnecessary visibility when configuring trigger type > > Signed-off-by: Mars Cheng Acked-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny...

Re: [PATCH v3 03/12] irqchip: mtk-sysirq: prevent unnecessary visibility when set_type

On 19/03/17 15:26, Mars Cheng wrote: > This prevent unnecessary visibility when configuring trigger type > > Signed-off-by: Mars Cheng Acked-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny...

Re: [PATCH] arm64: kconfig: allow support for memory failure handling

On 23/03/17 14:33, James Morse wrote: Hi Punit, On 01/02/17 21:38, Tyler Baicar wrote: From: "Jonathan (Zhixiong) Zhang" If ACPI_APEI and MEMORY_FAILURE is configured, select ACPI_APEI_MEMORY_FAILURE. This enables memory failure recovery when such memory failure is

Re: [PATCH] arm64: kconfig: allow support for memory failure handling

On 23/03/17 14:33, James Morse wrote: Hi Punit, On 01/02/17 21:38, Tyler Baicar wrote: From: "Jonathan (Zhixiong) Zhang" If ACPI_APEI and MEMORY_FAILURE is configured, select ACPI_APEI_MEMORY_FAILURE. This enables memory failure recovery when such memory failure is reported through ACPI

Re: [PATCH v4 1/4] pinctrl: rockchip: remove unnecessary locking

Hello John- One quick question below. Apologies if this has been covered, but just want to be sure. On Thu, Mar 23, 2017 at 10:59:28AM +, John Keeping wrote: > regmap_update_bits does its own locking and everything else accessed > here is a local variable so there is no need to lock around

Re: [PATCH v4 1/4] pinctrl: rockchip: remove unnecessary locking

Hello John- One quick question below. Apologies if this has been covered, but just want to be sure. On Thu, Mar 23, 2017 at 10:59:28AM +, John Keeping wrote: > regmap_update_bits does its own locking and everything else accessed > here is a local variable so there is no need to lock around

[PATCH] drivers/misc: aspeed-lpc-ctrl: fix printk format warning again

The format string is still broken after the first attempt to fix it: drivers/misc/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_probe': drivers/misc/aspeed-lpc-ctrl.c:232:17: error: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t {aka long long

[PATCH] drivers/misc: aspeed-lpc-ctrl: fix printk format warning again

The format string is still broken after the first attempt to fix it: drivers/misc/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_probe': drivers/misc/aspeed-lpc-ctrl.c:232:17: error: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t {aka long long

[PATCH] bna: avoid writing uninitialized data into hw registers

The latest gcc-7 snapshot warns about bfa_ioc_send_enable/bfa_ioc_send_disable writing undefined values into the hardware registers: drivers/net/ethernet/brocade/bna/bfa_ioc.c: In function 'bfa_iocpf_sm_disabling_entry': arch/arm/include/asm/io.h:109:22: error: '*((void *)_req+4)' is used

Hello,

Dear Friend, Can you be able to assist in handling this transaction? More details will be sent to you as soon as i receive your response. An approval will be granted to you as soon as you apply for the release of the fund to you. I need your urgent assistance in transferring the sum of US$5

[PATCH] bna: avoid writing uninitialized data into hw registers

The latest gcc-7 snapshot warns about bfa_ioc_send_enable/bfa_ioc_send_disable writing undefined values into the hardware registers: drivers/net/ethernet/brocade/bna/bfa_ioc.c: In function 'bfa_iocpf_sm_disabling_entry': arch/arm/include/asm/io.h:109:22: error: '*((void *)_req+4)' is used

Hello,

Dear Friend, Can you be able to assist in handling this transaction? More details will be sent to you as soon as i receive your response. An approval will be granted to you as soon as you apply for the release of the fund to you. I need your urgent assistance in transferring the sum of US$5

net/sched: GPF in qdisc_hash_add

Hello, I've hit the following GPF while running syzkaller on commit 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected kmalloc failure, most likely it's the root cause. FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 2 PID:

net/sched: GPF in qdisc_hash_add

Hello, I've hit the following GPF while running syzkaller on commit 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected kmalloc failure, most likely it's the root cause. FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 2 PID:

Re: [RFC] Add option to mount only a pids subset

Again, I can't really review this, I know nothing about vfs, but since nobody else replied... On 03/20, Alexey Gladkov wrote: > > @@ -97,7 +169,23 @@ static struct dentry *proc_mount(struct file_system_type > *fs_type, > ns = task_active_pid_ns(current); > } > > - return

Re: [RFC] Add option to mount only a pids subset

Again, I can't really review this, I know nothing about vfs, but since nobody else replied... On 03/20, Alexey Gladkov wrote: > > @@ -97,7 +169,23 @@ static struct dentry *proc_mount(struct file_system_type > *fs_type, > ns = task_active_pid_ns(current); > } > > - return

Re: [PATCH v1] KVM: kvm_io_bus_unregister_dev() should never fail

On Thu, 23 Mar 2017 15:34:41 +0100 David Hildenbrand wrote: > No caller currently checks the return value of > kvm_io_bus_unregister_dev(). This is evil, as all callers silently go on > freeing their device. A stale reference will remain in the io_bus, > getting at least used

Re: [PATCH v1] KVM: kvm_io_bus_unregister_dev() should never fail

On Thu, 23 Mar 2017 15:34:41 +0100 David Hildenbrand wrote: > No caller currently checks the return value of > kvm_io_bus_unregister_dev(). This is evil, as all callers silently go on > freeing their device. A stale reference will remain in the io_bus, > getting at least used again, when the

Re: [RFC] Add option to mount only a pids subset

Hi Alexey, On Mon, Mar 20, 2017 at 1:58 PM, Alexey Gladkov wrote: > > > Al Viro, this patch looks better ? > > == Overview == > > Some of the container virtualization systems are mounted /proc inside > the container. This is done in most cases to operate with

Re: [RFC] Add option to mount only a pids subset

Hi Alexey, On Mon, Mar 20, 2017 at 1:58 PM, Alexey Gladkov wrote: > > > Al Viro, this patch looks better ? > > == Overview == > > Some of the container virtualization systems are mounted /proc inside > the container. This is done in most cases to operate with information > about the processes.

Re: [PATCH v2] HV: properly delay KVP packets when negotiation is in progress

Long Li writes: > The host may send multiple negotiation packets (due to timeout) before > the KVP user-mode daemon is connected. We need to defer processing > those packets until the daemon is negotiated and connected. It's okay > for guest to respond to all negotiation

Re: [PATCH v2] HV: properly delay KVP packets when negotiation is in progress

Long Li writes: > The host may send multiple negotiation packets (due to timeout) before > the KVP user-mode daemon is connected. We need to defer processing > those packets until the daemon is negotiated and connected. It's okay > for guest to respond to all negotiation packets. > > In

[PATCH V2] ACPI / IPMI: allow ACPI_IPMI with IPMI_SSIF

ACPI_IPMI driver currently depends on IPMI System Interface (IPMI_SI) driver to be enabled. IPMI_SI driver only handles KCS, SMIC and BT BMC interfaces. IPMI_SSIF is an alternative BMC communication method. It allows BMC to be accessed over an I2C bus instead of a standard interface. Enabling

[PATCH V2] ACPI / IPMI: allow ACPI_IPMI with IPMI_SSIF

ACPI_IPMI driver currently depends on IPMI System Interface (IPMI_SI) driver to be enabled. IPMI_SI driver only handles KCS, SMIC and BT BMC interfaces. IPMI_SSIF is an alternative BMC communication method. It allows BMC to be accessed over an I2C bus instead of a standard interface. Enabling

Re: loop: WARNING in sysfs_remove_group

On Thu, Mar 23, 2017 at 03:09:44PM +0100, Dmitry Vyukov wrote: > Hello, > > I've got the following WARNING while running syzkaller on > 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected > kmalloc failure, most likely it's the root cause. > > FAULT_INJECTION: forcing a

Re: loop: WARNING in sysfs_remove_group

On Thu, Mar 23, 2017 at 03:09:44PM +0100, Dmitry Vyukov wrote: > Hello, > > I've got the following WARNING while running syzkaller on > 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected > kmalloc failure, most likely it's the root cause. > > FAULT_INJECTION: forcing a

Re: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc

Hi Geert, thanks for review On Wed, Mar 22, 2017 at 11:33:50AM +0100, Geert Uytterhoeven wrote: > Hi Jacopo, > > On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi > wrote: > > Add device tree bindings documentation for Renesas RZ/A1 gpio and pin > > for the Renesas

Re: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc

Hi Geert, thanks for review On Wed, Mar 22, 2017 at 11:33:50AM +0100, Geert Uytterhoeven wrote: > Hi Jacopo, > > On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi > wrote: > > Add device tree bindings documentation for Renesas RZ/A1 gpio and pin > > for the Renesas ... > > > controller. > > >

Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller

Hello, On Thu, Mar 23, 2017 at 10:32:54AM +, Patrick Bellasi wrote: > > But then we would lose out on being able to attach capacity > > constraints to specific tasks or groups of tasks? > > Yes, right. If CGroups are not available than you cannot specify > per-task constraints. This is just

Re: [RFC v3 1/5] sched/core: add capacity constraints to CPU controller

Hello, On Thu, Mar 23, 2017 at 10:32:54AM +, Patrick Bellasi wrote: > > But then we would lose out on being able to attach capacity > > constraints to specific tasks or groups of tasks? > > Yes, right. If CGroups are not available than you cannot specify > per-task constraints. This is just

Re: netlink: NULL timer crash

On Thu, 2017-03-23 at 07:53 -0700, Eric Dumazet wrote: > Nice ! > > Looks like neigh->ops->solicit is NULL Apparently we allow admins to do really stupid things with neighbours on tunnels. Following patch should avoid the crash. Anyone has better ideas ? net/ipv4/arp.c |5 +

Re: netlink: NULL timer crash

On Thu, 2017-03-23 at 07:53 -0700, Eric Dumazet wrote: > Nice ! > > Looks like neigh->ops->solicit is NULL Apparently we allow admins to do really stupid things with neighbours on tunnels. Following patch should avoid the crash. Anyone has better ideas ? net/ipv4/arp.c |5 +

<    5   6   7   8   9   10   11   12   13   14   >