Re: [PATCH 12/12] mmc: bcm2835: constify mmc_host_ops structures

Am 29.07.2017 um 07:59 schrieb Julia Lawall: > The mmc_host_ops structure is only stored in the ops field of an > mmc_host structure, which is declared as const. Thus the mmc_host_ops > structure itself can be const. > > Done with the help of Coccinelle. > > // > @r disable optional_qualifier@ >

Re: [PATCH 12/12] mmc: bcm2835: constify mmc_host_ops structures

Am 29.07.2017 um 07:59 schrieb Julia Lawall: > The mmc_host_ops structure is only stored in the ops field of an > mmc_host structure, which is declared as const. Thus the mmc_host_ops > structure itself can be const. > > Done with the help of Coccinelle. > > // > @r disable optional_qualifier@ >

Re: [PATCH v5 3/7] phy: qcom-qmp: Fix phy pipe clock name

Hi, On 07/31/2017 11:09 AM, Varadarajan Narayanan wrote: Presently, the phy pipe clock's name is assumed to be either usb3_phy_pipe_clk_src or pcie_XX_pipe_clk_src (where XX is the phy lane's number). However, this will not work if an SoC has more than one instance of the phy. Hence, instead

Re: [PATCH v5 3/7] phy: qcom-qmp: Fix phy pipe clock name

Hi, On 07/31/2017 11:09 AM, Varadarajan Narayanan wrote: Presently, the phy pipe clock's name is assumed to be either usb3_phy_pipe_clk_src or pcie_XX_pipe_clk_src (where XX is the phy lane's number). However, this will not work if an SoC has more than one instance of the phy. Hence, instead

[PATCH v2 1/2] i2c: uniphier: add suspend / resume support

When resuming, set up registers that have been lost in the sleep state. Also, add clock handling in the resume / suspend hooks. Signed-off-by: Masahiro Yamada --- Changes in v2: - Fix define but not used warning drivers/i2c/busses/i2c-uniphier.c | 40

[PATCH v2 1/2] i2c: uniphier: add suspend / resume support

When resuming, set up registers that have been lost in the sleep state. Also, add clock handling in the resume / suspend hooks. Signed-off-by: Masahiro Yamada --- Changes in v2: - Fix define but not used warning drivers/i2c/busses/i2c-uniphier.c | 40 ++-

[PATCH v2 2/2] i2c: uniphier-f: add suspend / resume support

When resuming, set up registers that have been lost in the sleep state. Also, add clock handling in the resume / suspend hooks. Signed-off-by: Masahiro Yamada --- Changes in v2: - Fix define but not used warning drivers/i2c/busses/i2c-uniphier-f.c | 46

[PATCH v2 2/2] i2c: uniphier-f: add suspend / resume support

When resuming, set up registers that have been lost in the sleep state. Also, add clock handling in the resume / suspend hooks. Signed-off-by: Masahiro Yamada --- Changes in v2: - Fix define but not used warning drivers/i2c/busses/i2c-uniphier-f.c | 46 +

[PATCH v2] bus: uniphier-system-bus: set up registers when resuming

When resuming, set up registers that have been lost in the sleep state. Signed-off-by: Masahiro Yamada --- Changes in v2: - Fix define but not used warning drivers/bus/uniphier-system-bus.c | 14 ++ 1 file changed, 14 insertions(+) diff --git

Re: [PATCH v5 2/7] dt-bindings: phy: qmp: Add support for QMP phy in IPQ8074

On 07/31/2017 11:09 AM, Varadarajan Narayanan wrote: IPQ8074 uses QMP phy controller that provides support to PCIe and USB. Adding dt binding information for the same. Signed-off-by: Varadarajan Narayanan --- Reviewed-by: Vivek Gautam

[PATCH v2] bus: uniphier-system-bus: set up registers when resuming

When resuming, set up registers that have been lost in the sleep state. Signed-off-by: Masahiro Yamada --- Changes in v2: - Fix define but not used warning drivers/bus/uniphier-system-bus.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/bus/uniphier-system-bus.c

Re: [PATCH v5 2/7] dt-bindings: phy: qmp: Add support for QMP phy in IPQ8074

On 07/31/2017 11:09 AM, Varadarajan Narayanan wrote: IPQ8074 uses QMP phy controller that provides support to PCIe and USB. Adding dt binding information for the same. Signed-off-by: Varadarajan Narayanan --- Reviewed-by: Vivek Gautam

[PATCH v2 4/4] ACPI / EC: Enable noirq stage GPE polling

This patch enables noirq stage GPE polling for the EC driver. EC is a very special driver, required to work throughout the entire suspend/resume process. Thus this patch enables IRQ polling for EC during noirq stages to avoid all kinds of possible issues. If this commit is bisected to be a

[PATCH v2 4/4] ACPI / EC: Enable noirq stage GPE polling

This patch enables noirq stage GPE polling for the EC driver. EC is a very special driver, required to work throughout the entire suspend/resume process. Thus this patch enables IRQ polling for EC during noirq stages to avoid all kinds of possible issues. If this commit is bisected to be a

[PATCH v2 3/4] ACPI / EC: Add support to handle EC events earlier

Now as GPE poller is implemented, EC driver is able to detect EC events during suspend/resume noirq stages, we can try to move EC event handling earlier without being worried about post-resume event stuck. Signed-off-by: Lv Zheng --- drivers/acpi/ec.c | 4 +++- 1 file

[PATCH v2 3/4] ACPI / EC: Add support to handle EC events earlier

Now as GPE poller is implemented, EC driver is able to detect EC events during suspend/resume noirq stages, we can try to move EC event handling earlier without being worried about post-resume event stuck. Signed-off-by: Lv Zheng --- drivers/acpi/ec.c | 4 +++- 1 file changed, 3 insertions(+),

[PATCH v2 2/4] ACPI / EC: Add IRQ polling support for noirq stages

1. Problems: EC IRQs contain transaction IRQs (OBF/IBF) and event IRQ (SCI_EVT). Transactions are initiated by hosts. The earliest OSPMs execution of EC transactions is from acpi_ec_transaction(), where the common EC IRQ handling procedure - advance_transaction() - is initiated from the task

[PATCH v2 2/4] ACPI / EC: Add IRQ polling support for noirq stages

1. Problems: EC IRQs contain transaction IRQs (OBF/IBF) and event IRQ (SCI_EVT). Transactions are initiated by hosts. The earliest OSPMs execution of EC transactions is from acpi_ec_transaction(), where the common EC IRQ handling procedure - advance_transaction() - is initiated from the task

[PATCH v2 1/4] ACPI / EC: Cleanup EC GPE mask flag

EC_FLAGS_COMMAND_STORM is actually used to mask GPE during IRQ processing. This patch cleans it up using more readable flag/function names. Signed-off-by: Lv Zheng --- drivers/acpi/ec.c | 23 +++ 1 file changed, 11 insertions(+), 12 deletions(-) diff

[PATCH v2 1/4] ACPI / EC: Cleanup EC GPE mask flag

EC_FLAGS_COMMAND_STORM is actually used to mask GPE during IRQ processing. This patch cleans it up using more readable flag/function names. Signed-off-by: Lv Zheng --- drivers/acpi/ec.c | 23 +++ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git

[PATCH v2 0/4] ACPI / EC: Solve EC event handling issues

There is a known issue in EC event handling. This patchset tries to handle noirq stage EC event polling to fix this known issue. In the very early version, the EC event polling mechanism is implemented by a kernel thread to poll EC events. Now the mechanism is implemented by a timer ticked in

[PATCH v2 0/4] ACPI / EC: Solve EC event handling issues

There is a known issue in EC event handling. This patchset tries to handle noirq stage EC event polling to fix this known issue. In the very early version, the EC event polling mechanism is implemented by a kernel thread to poll EC events. Now the mechanism is implemented by a timer ticked in

Re: mailing list for the dma mapping code

Hi All, On 2017-07-17 08:45, Christoph Hellwig wrote: Hi all, currently the dma-mapping code doesn't have a dedicated mailing list, and thus posts get lots on linux-kernel. I wonder if we should add a new separate list for it, or if it makes sense to reuse the existing iommu list given that

Re: mailing list for the dma mapping code

Hi All, On 2017-07-17 08:45, Christoph Hellwig wrote: Hi all, currently the dma-mapping code doesn't have a dedicated mailing list, and thus posts get lots on linux-kernel. I wonder if we should add a new separate list for it, or if it makes sense to reuse the existing iommu list given that

[PATCH v5 7/7] PCI: dwc: qcom: Add support for IPQ8074 PCIe controller

Add support for the IPQ8074 PCIe controller. IPQ8074 supports Gen 1/2, one lane, two PCIe root complex with support for MSI and legacy interrupts, and it conforms to PCI Express Base 2.1 specification. The core init is the similar to the existing SoC, however the clocks and reset lines differ.

[PATCH v5 7/7] PCI: dwc: qcom: Add support for IPQ8074 PCIe controller

Add support for the IPQ8074 PCIe controller. IPQ8074 supports Gen 1/2, one lane, two PCIe root complex with support for MSI and legacy interrupts, and it conforms to PCI Express Base 2.1 specification. The core init is the similar to the existing SoC, however the clocks and reset lines differ.

[PATCH v5 4/7] phy: qcom-qmp: Add support for IPQ8074

Add definitions required to enable QMP phy support for IPQ8074. Signed-off-by: smuthayy Signed-off-by: Varadarajan Narayanan --- drivers/phy/qualcomm/phy-qcom-qmp.c | 124 1 file changed, 124 insertions(+)

[PATCH v5 2/7] dt-bindings: phy: qmp: Add support for QMP phy in IPQ8074

IPQ8074 uses QMP phy controller that provides support to PCIe and USB. Adding dt binding information for the same. Signed-off-by: Varadarajan Narayanan --- Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 8 1 file changed, 8 insertions(+) diff --git

[PATCH v5 2/7] dt-bindings: phy: qmp: Add support for QMP phy in IPQ8074

IPQ8074 uses QMP phy controller that provides support to PCIe and USB. Adding dt binding information for the same. Signed-off-by: Varadarajan Narayanan --- Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 8 1 file changed, 8 insertions(+) diff --git

[PATCH v5 4/7] phy: qcom-qmp: Add support for IPQ8074

Add definitions required to enable QMP phy support for IPQ8074. Signed-off-by: smuthayy Signed-off-by: Varadarajan Narayanan --- drivers/phy/qualcomm/phy-qcom-qmp.c | 124 1 file changed, 124 insertions(+) diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c

[PATCH v5 6/7] dt-bindings: pci: qcom: Add support for IPQ8074

Add support for the IPQ8074 PCIe controller. IPQ8074 supports Gen 1/2, one lane, two PCIe root complex with support for MSI and legacy interrupts, and it conforms to PCI Express Base 2.1 specification. Signed-off-by: Varadarajan Narayanan ---

[PATCH v5 0/7] Add support for IPQ8074 PCIe phy and controller

v5: dt-bindings: phy: qmp: Add support for QMP phy in IPQ8074 Renamed phy_phy clock as common clock phy: qcom-qmp: Fix phy pipe clock name Moved the DT get into the registering function phy: qcom-qmp: Add support for IPQ8074 Place the IPQ8074 related structs similar

[PATCH v5 6/7] dt-bindings: pci: qcom: Add support for IPQ8074

Add support for the IPQ8074 PCIe controller. IPQ8074 supports Gen 1/2, one lane, two PCIe root complex with support for MSI and legacy interrupts, and it conforms to PCI Express Base 2.1 specification. Signed-off-by: Varadarajan Narayanan --- .../devicetree/bindings/pci/qcom,pcie.txt

[PATCH v5 0/7] Add support for IPQ8074 PCIe phy and controller

v5: dt-bindings: phy: qmp: Add support for QMP phy in IPQ8074 Renamed phy_phy clock as common clock phy: qcom-qmp: Fix phy pipe clock name Moved the DT get into the registering function phy: qcom-qmp: Add support for IPQ8074 Place the IPQ8074 related structs similar

[PATCH v5 5/7] PCI: dwc: qcom: Use block IP version for operations

Presently, when support for a new SoC is added, the driver ops structures and functions are versioned with plain 1, 2, 3 etc. Instead use the block IP version number. Signed-off-by: Varadarajan Narayanan --- drivers/pci/dwc/pcie-qcom.c | 133

[PATCH v5 3/7] phy: qcom-qmp: Fix phy pipe clock name

Presently, the phy pipe clock's name is assumed to be either usb3_phy_pipe_clk_src or pcie_XX_pipe_clk_src (where XX is the phy lane's number). However, this will not work if an SoC has more than one instance of the phy. Hence, instead of assuming the name of the clock, fetch it from the DT.

[PATCH v5 1/7] dt-bindings: phy: qmp: Add output-clock-names

The phy outputs a clock that will act as the parent for the phy's pipe clock. Add the name of this clock to the lane's DT node. Acked-by: Rob Herring Signed-off-by: Varadarajan Narayanan --- Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 3 +++

[PATCH v5 3/7] phy: qcom-qmp: Fix phy pipe clock name

Presently, the phy pipe clock's name is assumed to be either usb3_phy_pipe_clk_src or pcie_XX_pipe_clk_src (where XX is the phy lane's number). However, this will not work if an SoC has more than one instance of the phy. Hence, instead of assuming the name of the clock, fetch it from the DT.

[PATCH v5 1/7] dt-bindings: phy: qmp: Add output-clock-names

The phy outputs a clock that will act as the parent for the phy's pipe clock. Add the name of this clock to the lane's DT node. Acked-by: Rob Herring Signed-off-by: Varadarajan Narayanan --- Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 3 +++ 1 file changed, 3 insertions(+) diff

[PATCH v5 5/7] PCI: dwc: qcom: Use block IP version for operations

Presently, when support for a new SoC is added, the driver ops structures and functions are versioned with plain 1, 2, 3 etc. Instead use the block IP version number. Signed-off-by: Varadarajan Narayanan --- drivers/pci/dwc/pcie-qcom.c | 133 +++- 1 file

Re: [PATCH 2/4] clk: sunxi-ng: multiplier: Fix fractional mode

On Mon, Jul 31, 2017 at 12:41 AM, Jernej Skrabec wrote: > Driver for multiplier clock is missing a call to > ccu_frac_helper_enable() when fractional mode is selected. > > Add a call to ccu_frac_helper_enable(). > > Fixes: d77e8135b340 ("clk: sunxi-ng: multiplier: Add

Re: [PATCH 2/4] clk: sunxi-ng: multiplier: Fix fractional mode

On Mon, Jul 31, 2017 at 12:41 AM, Jernej Skrabec wrote: > Driver for multiplier clock is missing a call to > ccu_frac_helper_enable() when fractional mode is selected. > > Add a call to ccu_frac_helper_enable(). > > Fixes: d77e8135b340 ("clk: sunxi-ng: multiplier: Add fractional support") >

Re: [PATCH] phy: qcom-qmp: Fix failure path in phy_init functions

Hi Kishon, On Tue, Jun 20, 2017 at 11:27 AM, Vivek Gautam wrote: > Fixing the clk enable failure path in qcom_qmp_phy_init() > and cleanup the reset control deassertion failure path in > qcom_qmp_phy_com_init(). > > Fixes: e78f3d15e115 ("phy: qcom-qmp: new qmp phy

Re: [PATCH] phy: qcom-qmp: Fix failure path in phy_init functions

Hi Kishon, On Tue, Jun 20, 2017 at 11:27 AM, Vivek Gautam wrote: > Fixing the clk enable failure path in qcom_qmp_phy_init() > and cleanup the reset control deassertion failure path in > qcom_qmp_phy_com_init(). > > Fixes: e78f3d15e115 ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets") > >

Re: [PATCH 3/3] ANDROID: binder: fix proc->tsk check.

On 28 July 2017 at 17:26, Martijn Coenen wrote: > Commit c4ea41ba195d ("binder: use group leader instead of open thread")' > was incomplete and didn't update a check in binder_mmap(), causing all > mmap() calls into the binder driver to fail. > Fixes Android WiFi/BT regression

Re: [PATCH 3/3] ANDROID: binder: fix proc->tsk check.

On 28 July 2017 at 17:26, Martijn Coenen wrote: > Commit c4ea41ba195d ("binder: use group leader instead of open thread")' > was incomplete and didn't update a check in binder_mmap(), causing all > mmap() calls into the binder driver to fail. > Fixes Android WiFi/BT regression reported on

Re: [PATCH 0/4] clk: sunxi-ng: Fix issues with fractional mode

Hi Jernej, On Mon, Jul 31, 2017 at 12:41 AM, Jernej Skrabec wrote: > During development of H3 HDMI driver, I found some issues with > setting video clock rate. It turned out that clock driver decided > to use fractional mode and selected right frequency, but it didn't >

Re: [PATCH 0/4] clk: sunxi-ng: Fix issues with fractional mode

Hi Jernej, On Mon, Jul 31, 2017 at 12:41 AM, Jernej Skrabec wrote: > During development of H3 HDMI driver, I found some issues with > setting video clock rate. It turned out that clock driver decided > to use fractional mode and selected right frequency, but it didn't > enable it. Additionally,

Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

Hi Yong, On Mon, Jul 31, 2017 at 09:48:06AM +0800, Yong wrote: > On Sun, 30 Jul 2017 09:08:01 +0300 > Baruch Siach wrote: > > On Fri, Jul 28, 2017 at 06:02:33PM +0200, Maxime Ripard wrote: > > > On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote: > > > > +

Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

Hi Yong, On Mon, Jul 31, 2017 at 09:48:06AM +0800, Yong wrote: > On Sun, 30 Jul 2017 09:08:01 +0300 > Baruch Siach wrote: > > On Fri, Jul 28, 2017 at 06:02:33PM +0200, Maxime Ripard wrote: > > > On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote: > > > > + regmap_write(sdev->regmap,

[PATCH] bus: uniphier-system-bus: set up registers when resuming

When resuming, set up registers that have been lost in the sleep state. Signed-off-by: Masahiro Yamada --- drivers/bus/uniphier-system-bus.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/bus/uniphier-system-bus.c

[PATCH] bus: uniphier-system-bus: set up registers when resuming

When resuming, set up registers that have been lost in the sleep state. Signed-off-by: Masahiro Yamada --- drivers/bus/uniphier-system-bus.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/bus/uniphier-system-bus.c b/drivers/bus/uniphier-system-bus.c index

Re: [PATCH 4/4] clk: sunxi-ng: Wait for lock when using fractional mode

On Mon, Jul 31, 2017 at 12:41 AM, Jernej Skrabec wrote: > Currently ccu_frac_helper_set_rate() doesn't wait for a lock bit to be > set before returning. Because of that, unstable clock may be used. > > Add a wait for lock in the helper function. > > Signed-off-by: Jernej

linux-next: build warnings after merge of the staging tree

Hi Greg, After merging the staging tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/staging/media/atomisp/i2c/imx/imx.c:1087:12: warning: 'imx_vcm_power_up' defined but not used [-Wunused-function] static int imx_vcm_power_up(struct v4l2_subdev *sd)

Re: [PATCH V9 1/3] powernv: powercap: Add support for powercap framework

On Mon, 2017-07-31 at 07:54 +0530, Shilpasri G Bhat wrote: > Adds a generic powercap framework to change the system powercap > inband through OPAL-OCC command/response interface. > > Signed-off-by: Shilpasri G Bhat > --- > Changes from V8: > - Use __pa() while

Re: [PATCH 4/4] clk: sunxi-ng: Wait for lock when using fractional mode

On Mon, Jul 31, 2017 at 12:41 AM, Jernej Skrabec wrote: > Currently ccu_frac_helper_set_rate() doesn't wait for a lock bit to be > set before returning. Because of that, unstable clock may be used. > > Add a wait for lock in the helper function. > > Signed-off-by: Jernej Skrabec Can you provide

linux-next: build warnings after merge of the staging tree

Hi Greg, After merging the staging tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/staging/media/atomisp/i2c/imx/imx.c:1087:12: warning: 'imx_vcm_power_up' defined but not used [-Wunused-function] static int imx_vcm_power_up(struct v4l2_subdev *sd)

Re: [PATCH V9 1/3] powernv: powercap: Add support for powercap framework

On Mon, 2017-07-31 at 07:54 +0530, Shilpasri G Bhat wrote: > Adds a generic powercap framework to change the system powercap > inband through OPAL-OCC command/response interface. > > Signed-off-by: Shilpasri G Bhat > --- > Changes from V8: > - Use __pa() while passing pointer in opal call > -

Re: [PATCH 1/4] clk: sunxi-ng: Fix fractional mode for N-M clocks

On Mon, Jul 31, 2017 at 12:41 AM, Jernej Skrabec wrote: > N-M factor clock driver is missing a call to ccu_frac_helper_enable() > when fractional mode is used. Additionally, most SoCs require that M > factor must be set to 0 when fractional mode is used. > > Without this

Re: [PATCH 1/4] clk: sunxi-ng: Fix fractional mode for N-M clocks

On Mon, Jul 31, 2017 at 12:41 AM, Jernej Skrabec wrote: > N-M factor clock driver is missing a call to ccu_frac_helper_enable() > when fractional mode is used. Additionally, most SoCs require that M > factor must be set to 0 when fractional mode is used. > > Without this patch, clock keeps the

[PATCH 1/2] i2c: uniphier: add PM suspend / resume support

When resuming, set up registers that have been lost in the sleep state. Also, add clock handling in the resume / suspend hooks. Signed-off-by: Masahiro Yamada --- drivers/i2c/busses/i2c-uniphier.c | 40 ++- 1 file changed, 35

[PATCH 1/2] i2c: uniphier: add PM suspend / resume support

When resuming, set up registers that have been lost in the sleep state. Also, add clock handling in the resume / suspend hooks. Signed-off-by: Masahiro Yamada --- drivers/i2c/busses/i2c-uniphier.c | 40 ++- 1 file changed, 35 insertions(+), 5 deletions(-)

[PATCH 2/2] i2c: uniphier-f: add PM suspend / resume support

When resuming, set up registers that have been lost in the sleep state. Also, add clock handling in the resume / suspend hooks. Signed-off-by: Masahiro Yamada --- drivers/i2c/busses/i2c-uniphier-f.c | 46 + 1 file changed, 37

[PATCH 2/2] i2c: uniphier-f: add PM suspend / resume support

When resuming, set up registers that have been lost in the sleep state. Also, add clock handling in the resume / suspend hooks. Signed-off-by: Masahiro Yamada --- drivers/i2c/busses/i2c-uniphier-f.c | 46 + 1 file changed, 37 insertions(+), 9 deletions(-)

EXT4-fs (sdc1): Delayed block allocation failed ...

Hello. I am getting a single error message, similar to what happens in https://patchwork.kernel.org/patch/9460075/ EXT4-fs (sdc1): Delayed block allocation failed for inode 27155438 at logical offset 6561 with max blocks 6 with error 121 EXT4-fs (sdc1): This should not happen!! Data will be

EXT4-fs (sdc1): Delayed block allocation failed ...

Hello. I am getting a single error message, similar to what happens in https://patchwork.kernel.org/patch/9460075/ EXT4-fs (sdc1): Delayed block allocation failed for inode 27155438 at logical offset 6561 with max blocks 6 with error 121 EXT4-fs (sdc1): This should not happen!! Data will be

Re: [PATCH v3] vfio: platform: reset: Add Broadcom FlexRM reset module

Hi Eric, Thanks for the review comments... On Sat, Jul 29, 2017 at 6:31 PM, Auger Eric wrote: > Hi Anup, > On 20/07/2017 13:17, Anup Patel wrote: >> This patch adds Broadcom FlexRM low-level reset for >> VFIO platform. >> >> It will do the following: >> 1.

Re: [PATCH v3] vfio: platform: reset: Add Broadcom FlexRM reset module

Hi Eric, Thanks for the review comments... On Sat, Jul 29, 2017 at 6:31 PM, Auger Eric wrote: > Hi Anup, > On 20/07/2017 13:17, Anup Patel wrote: >> This patch adds Broadcom FlexRM low-level reset for >> VFIO platform. >> >> It will do the following: >> 1. Disable/Deactivate each FlexRM ring >>

Re: FSGSBASE ABI considerations

On Sun, Jul 30, 2017 at 8:05 PM, Andy Lutomirski wrote: > > This means that, when gdb saves away a regset and reloads it using > PTRACE_SETREGS or similar, the effect is to load gs_base and then load > gs. If gs != 0, this will blow away gs_base. Without FSGSBASE, this >

Re: FSGSBASE ABI considerations

On Sun, Jul 30, 2017 at 8:05 PM, Andy Lutomirski wrote: > > This means that, when gdb saves away a regset and reloads it using > PTRACE_SETREGS or similar, the effect is to load gs_base and then load > gs. If gs != 0, this will blow away gs_base. Without FSGSBASE, this > doesn't matter so much.

[PATCH v2] soc: ti: knav: Add a NULL pointer check for kdev in knav_pool_create

knav_pool_create is an exported function. In the event of a call before knav_queue_probe, we encounter a NULL pointer dereference in the following line. Hence return -EPROBE_DEFER to the caller till the kdev pointer is non-NULL. Signed-off-by: Keerthy --- Changes in v2: *

[PATCH v2] soc: ti: knav: Add a NULL pointer check for kdev in knav_pool_create

knav_pool_create is an exported function. In the event of a call before knav_queue_probe, we encounter a NULL pointer dereference in the following line. Hence return -EPROBE_DEFER to the caller till the kdev pointer is non-NULL. Signed-off-by: Keerthy --- Changes in v2: * Fixed returning an

Re: [greybus-dev] [PATCH 10/11] greybus: usb: constify hc_driver structures

On 28-07-17, 22:41, Julia Lawall wrote: > The hc_driver structure is only passed as the first argument to > usb_create_hcd, which is declared as const. Thus the hc_driver structure > itself can be const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall

Re: [greybus-dev] [PATCH 10/11] greybus: usb: constify hc_driver structures

On 28-07-17, 22:41, Julia Lawall wrote: > The hc_driver structure is only passed as the first argument to > usb_create_hcd, which is declared as const. Thus the hc_driver structure > itself can be const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall > > --- >

[PATCH] mm: don't zero ballooned pages

Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and shouldn't be given to the host ksmd to scan. Therefore, it is not necessary to zero ballooned pages, which is very time consuming when the page amount is large. The ongoing fast balloon tests show that the time to balloon 7G

[PATCH] mm: don't zero ballooned pages

Ballooned pages will be marked as MADV_DONTNEED by the hypervisor and shouldn't be given to the host ksmd to scan. Therefore, it is not necessary to zero ballooned pages, which is very time consuming when the page amount is large. The ongoing fast balloon tests show that the time to balloon 7G

Re: [PATCH] mfd: lp87565: Convert to use devm_mfd_add_devices

On Sunday 30 July 2017 04:28 PM, Axel Lin wrote: > This fixes missing mfd_remove_devices() call when unload the module. Reviewed-by: Keerthy > > Signed-off-by: Axel Lin > --- > drivers/mfd/lp87565.c | 7 +++ > 1 file changed, 3 insertions(+), 4

Re: [PATCH] mfd: lp87565: Convert to use devm_mfd_add_devices

On Sunday 30 July 2017 04:28 PM, Axel Lin wrote: > This fixes missing mfd_remove_devices() call when unload the module. Reviewed-by: Keerthy > > Signed-off-by: Axel Lin > --- > drivers/mfd/lp87565.c | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git

Re: [PATCH V8 1/6] PM / Domains: Add support to select performance-state of domains

On 29-07-17, 10:24, Ulf Hansson wrote: > Let's invent a new genpd flag, GENPD_FLAG_PERF_STATE! > > The creator of the genpd then needs to set this before calling > pm_genpd_init(). Similar as we are dealing with GENPD_FLAG_PM_CLK. > > The requirement for GENPD_FLAG_PERF_STATES, is to have the >

Re: [PATCH V8 1/6] PM / Domains: Add support to select performance-state of domains

On 29-07-17, 10:24, Ulf Hansson wrote: > Let's invent a new genpd flag, GENPD_FLAG_PERF_STATE! > > The creator of the genpd then needs to set this before calling > pm_genpd_init(). Similar as we are dealing with GENPD_FLAG_PM_CLK. > > The requirement for GENPD_FLAG_PERF_STATES, is to have the >

Re: [PATCH v3] cpuset: fix a deadlock due to incomplete patching of cpusets_enabled()

On Sun, Jul 30, 2017 at 9:01 PM, Dima Zavin wrote: > In codepaths that use the begin/retry interface for reading > mems_allowed_seq with irqs disabled, there exists a race condition that > stalls the patch process after only modifying a subset of the > static_branch call

Re: [PATCH v3] cpuset: fix a deadlock due to incomplete patching of cpusets_enabled()

On Sun, Jul 30, 2017 at 9:01 PM, Dima Zavin wrote: > In codepaths that use the begin/retry interface for reading > mems_allowed_seq with irqs disabled, there exists a race condition that > stalls the patch process after only modifying a subset of the > static_branch call sites. > > This problem

[PATCH v3] cpuset: fix a deadlock due to incomplete patching of cpusets_enabled()

In codepaths that use the begin/retry interface for reading mems_allowed_seq with irqs disabled, there exists a race condition that stalls the patch process after only modifying a subset of the static_branch call sites. This problem manifested itself as a dead lock in the slub allocator, inside

[PATCH v3] cpuset: fix a deadlock due to incomplete patching of cpusets_enabled()

In codepaths that use the begin/retry interface for reading mems_allowed_seq with irqs disabled, there exists a race condition that stalls the patch process after only modifying a subset of the static_branch call sites. This problem manifested itself as a dead lock in the slub allocator, inside

Re: [PATCH V5 2/2] cpufreq: Process remote callbacks from any CPU if the platform permits

On 28-07-17, 20:43, Joel Fernandes wrote: > On Thu, Jul 27, 2017 at 11:46 PM, Viresh Kumar > wrote: > > On many platforms, CPUs can do DVFS across cpufreq policies. i.e CPU > > from policy-A can change frequency of CPUs belonging to policy-B. > > > > This is quite common

Re: [PATCH V5 2/2] cpufreq: Process remote callbacks from any CPU if the platform permits

On 28-07-17, 20:43, Joel Fernandes wrote: > On Thu, Jul 27, 2017 at 11:46 PM, Viresh Kumar > wrote: > > On many platforms, CPUs can do DVFS across cpufreq policies. i.e CPU > > from policy-A can change frequency of CPUs belonging to policy-B. > > > > This is quite common in case of ARM platforms

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 28-07-17, 14:05, Saravana Kannan wrote: > 1. I'm not saying that. I'm saying assuming CPUs can change the freq only on > behalf of all the CPUs in the same policy is wrong. Again, the scheduler or > governor shouldn't even be making any of that assumption. That's a CPUfreq > driver problem. >

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 28-07-17, 14:05, Saravana Kannan wrote: > 1. I'm not saying that. I'm saying assuming CPUs can change the freq only on > behalf of all the CPUs in the same policy is wrong. Again, the scheduler or > governor shouldn't even be making any of that assumption. That's a CPUfreq > driver problem. >

Re: [PATCH 0/6] Add DSP DT nodes on Keystone platforms

On 7/28/17 4:19 PM, Suman Anna wrote: Hi Santosh, The following series adds the DT nodes for the DSP devices present on the Keystone2 66AK2H/K, 66AK2L and 66AK2E SoCs. They are disabled in the base dts files, and enabled in the corresponding board files alongside an added common reserved CMA

Re: [PATCH 0/6] Add DSP DT nodes on Keystone platforms

On 7/28/17 4:19 PM, Suman Anna wrote: Hi Santosh, The following series adds the DT nodes for the DSP devices present on the Keystone2 66AK2H/K, 66AK2L and 66AK2E SoCs. They are disabled in the base dts files, and enabled in the corresponding board files alongside an added common reserved CMA

linux-next: manual merge of the rcu tree with the tip tree

Hi Paul, Today's linux-next merge of the rcu tree got a conflict in: arch/x86/mm/tlb.c between commit: 94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking") from the tip tree and commit: d7713e8f8b23 ("membarrier: Expedited private command") from the rcu tree. I

linux-next: manual merge of the rcu tree with the tip tree

Hi Paul, Today's linux-next merge of the rcu tree got a conflict in: arch/x86/mm/tlb.c between commit: 94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking") from the tip tree and commit: d7713e8f8b23 ("membarrier: Expedited private command") from the rcu tree. I

[PATCH v7 1/3] mmc: dw_mmc-k3: add sd support for hi3660

Add sd card support for hi3660 soc Signed-off-by: Li Wei Signed-off-by: Chen Jun Major changes in v3: - solve review comments from Heiner Kallweit. *use the GENMASK and FIELD_PREP macros replace the bit shift operation. *use usleep_range()

[PATCH v7 1/3] mmc: dw_mmc-k3: add sd support for hi3660

Add sd card support for hi3660 soc Signed-off-by: Li Wei Signed-off-by: Chen Jun Major changes in v3: - solve review comments from Heiner Kallweit. *use the GENMASK and FIELD_PREP macros replace the bit shift operation. *use usleep_range() replace udelay() and mdelay(). Major changes

[PATCH v7 2/3] mmc: dw_mmc: move controller reset before driver init op

This commit modifies dw_mci_probe(), it moves reset assertion before drv_data->init(host) Some driver needs to access controller registers in its .init() ops. So, in order to make such access safe, we should do controller reset before .init() being called. Signed-off-by: Wei Li

[PATCH v7 2/3] mmc: dw_mmc: move controller reset before driver init op

This commit modifies dw_mci_probe(), it moves reset assertion before drv_data->init(host) Some driver needs to access controller registers in its .init() ops. So, in order to make such access safe, we should do controller reset before .init() being called. Signed-off-by: Wei Li Signed-off-by:

Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

Hi, On Fri, 28 Jul 2017 18:02:33 +0200 Maxime Ripard wrote: > Hi, > > Thanks for the second iteration! > > On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote: > > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface > > and CSI1 is

Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

Hi, On Fri, 28 Jul 2017 18:02:33 +0200 Maxime Ripard wrote: > Hi, > > Thanks for the second iteration! > > On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote: > > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface > > and CSI1 is used for parallel interface. This

[PATCH v3 3/5] ARM: dts: rockchip: add RGA device node for RK3288

This patch add the RGA dt config of rk3288 SoC. Signed-off-by: Jacob Chen Signed-off-by: Yakir Yang --- arch/arm/boot/dts/rk3288.dtsi | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/boot/dts/rk3288.dtsi

[PATCH v3 3/5] ARM: dts: rockchip: add RGA device node for RK3288

This patch add the RGA dt config of rk3288 SoC. Signed-off-by: Jacob Chen Signed-off-by: Yakir Yang --- arch/arm/boot/dts/rk3288.dtsi | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi index 1efc2f2..cea41b7 100644 ---

  1   2   3   4   5   6   7   >