[GIT PULL] extcon next for v4.12

[Chanwoo Choi]

Dear Greg,

This is extcon-next pull request for v4.12. I add detailed description of
this pull request on below. Please pull extcon with following updates.

Best Regards,
Chanwoo Choi

The following changes since commit c02ed2e75ef4c74e41e421acb4ef1494671585e8:

  Linux 4.11-rc4 (2017-03-26 14:15:16 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
tags/extcon-next-for-4.12

for you to fetch changes up to 70641a0a84e1ae3c6eee3d47ed5a482f85b11e3e:

  extcon: Use BIT() macro for the left-shift operation (2017-04-06 11:12:45 
+0900)


Update extcon for 4.12

Detailed description for this pull request:
1. Add new 'extcon-intel-cht-wc.c' driver
- Intel Cherrytrail Whiskey Cove PMIC extcon driver supports
the detection of the charger connectors and the control.

2. Add new extcon API to monitor the all external connectors.
- The extcon consumer might need to monitor the all supported external
connectors from the extcon device. Before, the extcon consumer
should have each notifier_block structure for each external connector.

In order to support the requirement, the extcon adds new
extcon_register_notifier_all() API. The extcon consumer is able
to monitor the state change of all supported external connectors
from the extcon device by using only one notifier_block.

- extcon_(register|unregister)_notifier_all(struct extcon_dev *edev
struct notifier_block *nb)
- devm_extcon_(register|unregister)_notifier_all(struct device *dev,
struct extcon_dev *edev
struct notifier_block *nb)

3. Remove porting compatibility of old switch class
- The extcon removes the porting compatibility of old switch class
because there are no any use-case and requirement of switch class.

4. Update the extcon drivers and Fix the minor issues
- Revert the ACPI gpio interface on the extcon-usb-gpioc.c.
- Fix the issues related to the suspend-to-ram for both extcon-usb-gpio.c
  and extcon-palmas.c.
- Add warning message for extcon-arizona.c when headphone detection is not
  finished.


Andy Shevchenko (1):
  Revert "extcon: usb-gpio: add support for ACPI gpio interface"

Chanwoo Choi (4):
  extcon: Add new extcon_register_notifier_all() to monitor all external 
connectors
  Merge branch 'ib-extcon-4.12' into HEAD
  extcon: Remove porting compatibility of swich class
  extcon: Use BIT() macro for the left-shift operation

Charles Keepax (1):
  extcon: arizona: Wait for any running HPDETs to complete on jack removal

Hans de Goede (3):
  extcon: intel-cht-wc: Add Intel Cherry Trail Whiskey Cove PMIC extcon 
driver
  extcon: intel-cht-wc: Disable external 5v boost converter on probe
  extcon: intel-cht-wc: Ignore failure to detect charger-type on host mode 
exit

Peter Chen (1):
  extcon: usb-gpio: Do not enable USB as wakeup source by default

Roger Quadros (2):
  extcon: usb-gpio: Don't miss event during suspend/resume
  extcon: palmas: Don't miss GPIO events during suspend/resume

 Documentation/extcon/porting-android-switch-class | 123 ---
 drivers/extcon/Kconfig|   7 +
 drivers/extcon/Makefile   |   1 +
 drivers/extcon/devres.c   |  61 
 drivers/extcon/extcon-arizona.c   |  46 +++
 drivers/extcon/extcon-intel-cht-wc.c  | 395 ++
 drivers/extcon/extcon-palmas.c|   6 +
 drivers/extcon/extcon-usb-gpio.c  |  10 +-
 drivers/extcon/extcon.c   |  88 +++--
 drivers/extcon/extcon.h   |   3 +
 include/linux/extcon.h|  21 +-
 11 files changed, 606 insertions(+), 155 deletions(-)
 delete mode 100644 Documentation/extcon/porting-android-switch-class
 create mode 100644 drivers/extcon/extcon-intel-cht-wc.c

[GIT PULL] extcon next for v4.12

[Chanwoo Choi]

Dear Greg,

This is extcon-next pull request for v4.12. I add detailed description of
this pull request on below. Please pull extcon with following updates.

Best Regards,
Chanwoo Choi

The following changes since commit c02ed2e75ef4c74e41e421acb4ef1494671585e8:

  Linux 4.11-rc4 (2017-03-26 14:15:16 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
tags/extcon-next-for-4.12

for you to fetch changes up to 70641a0a84e1ae3c6eee3d47ed5a482f85b11e3e:

  extcon: Use BIT() macro for the left-shift operation (2017-04-06 11:12:45 
+0900)


Update extcon for 4.12

Detailed description for this pull request:
1. Add new 'extcon-intel-cht-wc.c' driver
- Intel Cherrytrail Whiskey Cove PMIC extcon driver supports
the detection of the charger connectors and the control.

2. Add new extcon API to monitor the all external connectors.
- The extcon consumer might need to monitor the all supported external
connectors from the extcon device. Before, the extcon consumer
should have each notifier_block structure for each external connector.

In order to support the requirement, the extcon adds new
extcon_register_notifier_all() API. The extcon consumer is able
to monitor the state change of all supported external connectors
from the extcon device by using only one notifier_block.

- extcon_(register|unregister)_notifier_all(struct extcon_dev *edev
struct notifier_block *nb)
- devm_extcon_(register|unregister)_notifier_all(struct device *dev,
struct extcon_dev *edev
struct notifier_block *nb)

3. Remove porting compatibility of old switch class
- The extcon removes the porting compatibility of old switch class
because there are no any use-case and requirement of switch class.

4. Update the extcon drivers and Fix the minor issues
- Revert the ACPI gpio interface on the extcon-usb-gpioc.c.
- Fix the issues related to the suspend-to-ram for both extcon-usb-gpio.c
  and extcon-palmas.c.
- Add warning message for extcon-arizona.c when headphone detection is not
  finished.


Andy Shevchenko (1):
  Revert "extcon: usb-gpio: add support for ACPI gpio interface"

Chanwoo Choi (4):
  extcon: Add new extcon_register_notifier_all() to monitor all external 
connectors
  Merge branch 'ib-extcon-4.12' into HEAD
  extcon: Remove porting compatibility of swich class
  extcon: Use BIT() macro for the left-shift operation

Charles Keepax (1):
  extcon: arizona: Wait for any running HPDETs to complete on jack removal

Hans de Goede (3):
  extcon: intel-cht-wc: Add Intel Cherry Trail Whiskey Cove PMIC extcon 
driver
  extcon: intel-cht-wc: Disable external 5v boost converter on probe
  extcon: intel-cht-wc: Ignore failure to detect charger-type on host mode 
exit

Peter Chen (1):
  extcon: usb-gpio: Do not enable USB as wakeup source by default

Roger Quadros (2):
  extcon: usb-gpio: Don't miss event during suspend/resume
  extcon: palmas: Don't miss GPIO events during suspend/resume

 Documentation/extcon/porting-android-switch-class | 123 ---
 drivers/extcon/Kconfig|   7 +
 drivers/extcon/Makefile   |   1 +
 drivers/extcon/devres.c   |  61 
 drivers/extcon/extcon-arizona.c   |  46 +++
 drivers/extcon/extcon-intel-cht-wc.c  | 395 ++
 drivers/extcon/extcon-palmas.c|   6 +
 drivers/extcon/extcon-usb-gpio.c  |  10 +-
 drivers/extcon/extcon.c   |  88 +++--
 drivers/extcon/extcon.h   |   3 +
 include/linux/extcon.h|  21 +-
 11 files changed, 606 insertions(+), 155 deletions(-)
 delete mode 100644 Documentation/extcon/porting-android-switch-class
 create mode 100644 drivers/extcon/extcon-intel-cht-wc.c

Re: [PATCH] cpufreq: imx6q: Fix error handling code

[Viresh Kumar]

On 09-04-17, 09:33, Christophe JAILLET wrote:
> According to the previous error handling code, it is likely that
> 'goto out_free_opp' is expected here in order to avoid a memory leak in
> error handling path.
> 
> Signed-off-by: Christophe JAILLET 
> ---
>  drivers/cpufreq/imx6q-cpufreq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
> index 7719b02e04f5..b14117dcfff5 100644
> --- a/drivers/cpufreq/imx6q-cpufreq.c
> +++ b/drivers/cpufreq/imx6q-cpufreq.c
> @@ -255,7 +255,7 @@ static int imx6q_cpufreq_probe(struct platform_device 
> *pdev)
>   ret = dev_pm_opp_init_cpufreq_table(cpu_dev, _table);
>   if (ret) {
>   dev_err(cpu_dev, "failed to init cpufreq table: %d\n", ret);
> - goto put_reg;
> + goto out_free_opp;
>   }
>  
>   /* Make imx6_soc_volt array's size same as arm opp number */

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] cpufreq: imx6q: Fix error handling code

[Viresh Kumar]

On 09-04-17, 09:33, Christophe JAILLET wrote:
> According to the previous error handling code, it is likely that
> 'goto out_free_opp' is expected here in order to avoid a memory leak in
> error handling path.
> 
> Signed-off-by: Christophe JAILLET 
> ---
>  drivers/cpufreq/imx6q-cpufreq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
> index 7719b02e04f5..b14117dcfff5 100644
> --- a/drivers/cpufreq/imx6q-cpufreq.c
> +++ b/drivers/cpufreq/imx6q-cpufreq.c
> @@ -255,7 +255,7 @@ static int imx6q_cpufreq_probe(struct platform_device 
> *pdev)
>   ret = dev_pm_opp_init_cpufreq_table(cpu_dev, _table);
>   if (ret) {
>   dev_err(cpu_dev, "failed to init cpufreq table: %d\n", ret);
> - goto put_reg;
> + goto out_free_opp;
>   }
>  
>   /* Make imx6_soc_volt array's size same as arm opp number */

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2

[Kishon Vijay Abraham I]

Hi,

On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote:
> Hi Kishon,
> 
> On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I  wrote:
>> Hi Ravi,
>>
>> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
>>> Hi Kishon,
>>>
>>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I  
>>> wrote:
 Hi,

 On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
> This is driver for USB DRD Phy used in Broadcom's Northstar2
> SoC. The phy can be configured to be in Device mode or Host
> mode based on the type of cable connected to the port. The
> driver registers to  extcon framework to get appropriate
> connect events for Host/Device cables connect/disconnect
> states based on VBUS and ID interrupts.

 $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
 Northstar2.

>>>
>>> Will do.
>>>
 Sorry for not letting you know this earlier. But I feel the design of the
 driver should be changed. Extcon shouldn't be used here. The extcon
 notifications should be sent to the consumer driver and the consumer driver
 should be responsible for invoking the phy ops.

>>>
>>> The consumer drivers here would be a UDC driver (USB device
>>> controller), EHCI and OHCI host controller drivers.
>>> I was already suggested in UDC driver review to deal with extcon in Phy 
>>> driver.
>>>
>>> This phy connects to 2 host controllers, and one device controller.
>>> That's the design in Broadcom Northstar2
>>> platform. The values of the VBUS and ID pins of this port are
>>> determined based on the type of the cable (device cable
>>> or host cable). And. phy has to be configured accordingly.
>>>
 The phy ops being invoked during extcon events doesn't look right.
>>>
>>> Could you please elaborate on the concern, so that we can think of
>>> mitigating those issues in this driver?
>>> Since we are dealing with phy init/shutdown in this driver itself, are
>>> you okay with moving the extcon handling code
>>> out of phy ops ?
>>
>> yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
>> extcon events too. Can a phy which is initialized by a phy consumer (say your
>> UDC invokes phy_init) can be shutdown by an extcon event?
>>
>> Maybe a clear explanation of when phy_ops here will be invoked and when it 
>> will
>> set using extcon events might help.
>>
> 
> Say, we have a USB pendrive which is connected to the DRD port through
> a host cable.
> Now the PHY will be initialized to be in host mode.
> When the pendrive is unplugged, and we now connect the NS2 device to
> some linux PC,
> now the PHY has to be shutdown, and re-initialized to be in Device mode.
> 
> On unplug event, it is set neither to Host nor Device mode (basically
> shutdown). Next time which ever cable is connected, the PHY is
> initialized to the respective
> mode.
> 
> Please let me know if it's fine to do these initializations outside
> phy ops, because those will
> be irrelevant for phy consumers (the controllers) as it's anyways
> dealt in the phy driver through
> extcon.

How does the consumer get to know whether they have to operate in host mode or
device mode?

Thanks
Kishon

Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2

[Kishon Vijay Abraham I]

Hi,

On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote:
> Hi Kishon,
> 
> On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I  wrote:
>> Hi Ravi,
>>
>> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
>>> Hi Kishon,
>>>
>>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I  
>>> wrote:
 Hi,

 On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
> This is driver for USB DRD Phy used in Broadcom's Northstar2
> SoC. The phy can be configured to be in Device mode or Host
> mode based on the type of cable connected to the port. The
> driver registers to  extcon framework to get appropriate
> connect events for Host/Device cables connect/disconnect
> states based on VBUS and ID interrupts.

 $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
 Northstar2.

>>>
>>> Will do.
>>>
 Sorry for not letting you know this earlier. But I feel the design of the
 driver should be changed. Extcon shouldn't be used here. The extcon
 notifications should be sent to the consumer driver and the consumer driver
 should be responsible for invoking the phy ops.

>>>
>>> The consumer drivers here would be a UDC driver (USB device
>>> controller), EHCI and OHCI host controller drivers.
>>> I was already suggested in UDC driver review to deal with extcon in Phy 
>>> driver.
>>>
>>> This phy connects to 2 host controllers, and one device controller.
>>> That's the design in Broadcom Northstar2
>>> platform. The values of the VBUS and ID pins of this port are
>>> determined based on the type of the cable (device cable
>>> or host cable). And. phy has to be configured accordingly.
>>>
 The phy ops being invoked during extcon events doesn't look right.
>>>
>>> Could you please elaborate on the concern, so that we can think of
>>> mitigating those issues in this driver?
>>> Since we are dealing with phy init/shutdown in this driver itself, are
>>> you okay with moving the extcon handling code
>>> out of phy ops ?
>>
>> yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
>> extcon events too. Can a phy which is initialized by a phy consumer (say your
>> UDC invokes phy_init) can be shutdown by an extcon event?
>>
>> Maybe a clear explanation of when phy_ops here will be invoked and when it 
>> will
>> set using extcon events might help.
>>
> 
> Say, we have a USB pendrive which is connected to the DRD port through
> a host cable.
> Now the PHY will be initialized to be in host mode.
> When the pendrive is unplugged, and we now connect the NS2 device to
> some linux PC,
> now the PHY has to be shutdown, and re-initialized to be in Device mode.
> 
> On unplug event, it is set neither to Host nor Device mode (basically
> shutdown). Next time which ever cable is connected, the PHY is
> initialized to the respective
> mode.
> 
> Please let me know if it's fine to do these initializations outside
> phy ops, because those will
> be irrelevant for phy consumers (the controllers) as it's anyways
> dealt in the phy driver through
> extcon.

How does the consumer get to know whether they have to operate in host mode or
device mode?

Thanks
Kishon

Re: [PATCH] phy: qcom-qmp: Add dependency on COMMON_CLK

[Kishon Vijay Abraham I]

On Friday 07 April 2017 01:37 AM, Vivek Gautam wrote:
> The driver uses clock provider interface, and therefore
> it fails to build when enabled for COMPILE_TEST, since
> COMMON_CLK is not enabled at that time.
> So, make PHY_QCOM_QMP depend on COMMON_CLK as well.
> 
> Cc: Fengguang Wu 
> Cc: Kishon Vijay Abraham I 
> Signed-off-by: Vivek Gautam 
> ---
> 
> Hi Kishon,
> 
> This patch is fixing the build failures for architectures
> such as, tile, and ia64, that don't enable COMMON_CLK by default.
> You can either squash this into the qmp phy driver patch,
> or put it as a separate patch with 'Fix' tag.
> Let me know if you want me to add a 'fix' tag with a reference
> to the commit ID.

I squashed it with your earlier patch and pushed.

Thanks
Kishon

> 
> Regards
> Vivek
> 
>  drivers/phy/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index bb8140355608..8550d3dc0b71 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -441,7 +441,7 @@ config PHY_STIH407_USB
>  
>  config PHY_QCOM_QMP
>   tristate "Qualcomm QMP PHY Driver"
> - depends on OF && (ARCH_QCOM || COMPILE_TEST)
> + depends on OF && COMMON_CLK && (ARCH_QCOM || COMPILE_TEST)
>   select GENERIC_PHY
>   help
> Enable this to support the QMP PHY transceiver that is used
> 

Re: [PATCH] phy: qcom-qmp: Add dependency on COMMON_CLK

[Kishon Vijay Abraham I]

On Friday 07 April 2017 01:37 AM, Vivek Gautam wrote:
> The driver uses clock provider interface, and therefore
> it fails to build when enabled for COMPILE_TEST, since
> COMMON_CLK is not enabled at that time.
> So, make PHY_QCOM_QMP depend on COMMON_CLK as well.
> 
> Cc: Fengguang Wu 
> Cc: Kishon Vijay Abraham I 
> Signed-off-by: Vivek Gautam 
> ---
> 
> Hi Kishon,
> 
> This patch is fixing the build failures for architectures
> such as, tile, and ia64, that don't enable COMMON_CLK by default.
> You can either squash this into the qmp phy driver patch,
> or put it as a separate patch with 'Fix' tag.
> Let me know if you want me to add a 'fix' tag with a reference
> to the commit ID.

I squashed it with your earlier patch and pushed.

Thanks
Kishon

> 
> Regards
> Vivek
> 
>  drivers/phy/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index bb8140355608..8550d3dc0b71 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -441,7 +441,7 @@ config PHY_STIH407_USB
>  
>  config PHY_QCOM_QMP
>   tristate "Qualcomm QMP PHY Driver"
> - depends on OF && (ARCH_QCOM || COMPILE_TEST)
> + depends on OF && COMMON_CLK && (ARCH_QCOM || COMPILE_TEST)
>   select GENERIC_PHY
>   help
> Enable this to support the QMP PHY transceiver that is used
> 

Re: [PATCH 0/2] drm: dw-hdmi: various improvements

[Archit Taneja]

Hi,

On 04/07/2017 07:49 PM, Romain Perier wrote:

This set of patches split the stream handling functions in two parts. It
introduces new callbacks that are specific to each variant, one for I2S
and one for AHB.

Then, as requested by the datasheet for the I2S variant, it adds support
for gating the audio sampler clock when the audio stream is enabled and
disabled.

This patches series is the continuity of the following discussion:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/493550.html


Since these aren't fixes, could you make sure to redo the patches over:

git://anongit.freedesktop.org/drm-misc drm-misc-next

The dw-hdmi driver is now under drivers/gpu/drm/bridge/synopsis/

Thanks,
Archit



Romain Perier (2):
  drm: dw-hdmi: add specific I2S and AHB functions for stream handling
  drm: dw-hdmi: Gate audio clock from the I2S enablement callbacks

 drivers/gpu/drm/bridge/dw-hdmi.c | 45 +---
 1 file changed, 37 insertions(+), 8 deletions(-)



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 0/2] drm: dw-hdmi: various improvements

[Archit Taneja]

Hi,

On 04/07/2017 07:49 PM, Romain Perier wrote:

This set of patches split the stream handling functions in two parts. It
introduces new callbacks that are specific to each variant, one for I2S
and one for AHB.

Then, as requested by the datasheet for the I2S variant, it adds support
for gating the audio sampler clock when the audio stream is enabled and
disabled.

This patches series is the continuity of the following discussion:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/493550.html


Since these aren't fixes, could you make sure to redo the patches over:

git://anongit.freedesktop.org/drm-misc drm-misc-next

The dw-hdmi driver is now under drivers/gpu/drm/bridge/synopsis/

Thanks,
Archit



Romain Perier (2):
  drm: dw-hdmi: add specific I2S and AHB functions for stream handling
  drm: dw-hdmi: Gate audio clock from the I2S enablement callbacks

 drivers/gpu/drm/bridge/dw-hdmi.c | 45 +---
 1 file changed, 37 insertions(+), 8 deletions(-)



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] PM / OPP: Use - instead of @ for DT entries

[Viresh Kumar]

Compiling the DT file with W=1, DTC warns like follows:

Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
unit name, but no reg property

Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.

Reported-by: Masahiro Yamada 
Signed-off-by: Viresh Kumar 
---
 .../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++
 Documentation/devicetree/bindings/opp/opp.txt  | 38 ++---
 arch/arm/boot/dts/exynos3250.dtsi  | 46 +++
 arch/arm/boot/dts/exynos4210.dtsi  | 32 +--
 arch/arm/boot/dts/exynos4412-prime.dtsi|  4 +-
 arch/arm/boot/dts/exynos4412.dtsi  | 66 +++---
 arch/arm/boot/dts/exynos5420.dtsi  | 40 ++---
 arch/arm/boot/dts/exynos5800.dtsi  | 56 +-
 arch/arm/boot/dts/pxa25x.dtsi  |  8 +--
 arch/arm/boot/dts/pxa27x.dtsi  | 14 ++---
 arch/arm/boot/dts/sun8i-a33.dtsi   |  8 +--
 arch/arm/boot/dts/uniphier-pro5.dtsi   | 32 +--
 arch/arm/boot/dts/uniphier-pxs2.dtsi   | 16 +++---
 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 
 arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi   | 14 ++---
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi   | 32 +--
 arch/arm64/boot/dts/zte/zx296718.dtsi  | 10 ++--
 18 files changed, 280 insertions(+), 280 deletions(-)

diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index d085ef90d27c..f8e946471a58 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -202,23 +202,23 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
 
-   opp@5000 {
+   opp-5000 {
opp-hz = /bits/ 64 <5000>;
opp-microvolt = <80>;
};
-   opp@1 {
+   opp-1 {
opp-hz = /bits/ 64 <1>;
opp-microvolt = <80>;
};
-   opp@13400 {
+   opp-13400 {
opp-hz = /bits/ 64 <13400>;
opp-microvolt = <80>;
};
-   opp@2 {
+   opp-2 {
opp-hz = /bits/ 64 <2>;
opp-microvolt = <825000>;
};
-   opp@4 {
+   opp-4 {
opp-hz = /bits/ 64 <4>;
opp-microvolt = <875000>;
};
@@ -292,23 +292,23 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
 
-   opp@5000 {
+   opp-5000 {
opp-hz = /bits/ 64 <5000>;
opp-microvolt = <90>;
};
-   opp@8000 {
+   opp-8000 {
opp-hz = /bits/ 64 <8000>;
opp-microvolt = <90>;
};
-   opp@1 {
+   opp-1 {
opp-hz = /bits/ 64 <1>;
opp-microvolt = <100>;
};
-   opp@13400 {
+   opp-13400 {
opp-hz = /bits/ 64 <13400>;
opp-microvolt = <100>;
};
-   opp@2 {
+   opp-2 {
opp-hz = /bits/ 64 <2>;
opp-microvolt = <100>;
};
@@ -318,19 +318,19 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
 
-   opp@5000 {
+   opp-5000 {
opp-hz = /bits/ 64 <5000>;
};
-   opp@8000 {
+   opp-8000 {
opp-hz = /bits/ 64 <8000>;
};
-   opp@1 {
+   opp-1 {
opp-hz = /bits/ 64 <1>;
};
-   opp@2 {
+   opp-2 {
opp-hz = /bits/ 64 <2>;
};
-   opp@4 {
+   opp-4 {
opp-hz = /bits/ 64 <4>;
  

[PATCH] PM / OPP: Use - instead of @ for DT entries

[Viresh Kumar]

Compiling the DT file with W=1, DTC warns like follows:

Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
unit name, but no reg property

Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.

Reported-by: Masahiro Yamada 
Signed-off-by: Viresh Kumar 
---
 .../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++
 Documentation/devicetree/bindings/opp/opp.txt  | 38 ++---
 arch/arm/boot/dts/exynos3250.dtsi  | 46 +++
 arch/arm/boot/dts/exynos4210.dtsi  | 32 +--
 arch/arm/boot/dts/exynos4412-prime.dtsi|  4 +-
 arch/arm/boot/dts/exynos4412.dtsi  | 66 +++---
 arch/arm/boot/dts/exynos5420.dtsi  | 40 ++---
 arch/arm/boot/dts/exynos5800.dtsi  | 56 +-
 arch/arm/boot/dts/pxa25x.dtsi  |  8 +--
 arch/arm/boot/dts/pxa27x.dtsi  | 14 ++---
 arch/arm/boot/dts/sun8i-a33.dtsi   |  8 +--
 arch/arm/boot/dts/uniphier-pro5.dtsi   | 32 +--
 arch/arm/boot/dts/uniphier-pxs2.dtsi   | 16 +++---
 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 
 arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi   | 14 ++---
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi   | 32 +--
 arch/arm64/boot/dts/zte/zx296718.dtsi  | 10 ++--
 18 files changed, 280 insertions(+), 280 deletions(-)

diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index d085ef90d27c..f8e946471a58 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -202,23 +202,23 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
 
-   opp@5000 {
+   opp-5000 {
opp-hz = /bits/ 64 <5000>;
opp-microvolt = <80>;
};
-   opp@1 {
+   opp-1 {
opp-hz = /bits/ 64 <1>;
opp-microvolt = <80>;
};
-   opp@13400 {
+   opp-13400 {
opp-hz = /bits/ 64 <13400>;
opp-microvolt = <80>;
};
-   opp@2 {
+   opp-2 {
opp-hz = /bits/ 64 <2>;
opp-microvolt = <825000>;
};
-   opp@4 {
+   opp-4 {
opp-hz = /bits/ 64 <4>;
opp-microvolt = <875000>;
};
@@ -292,23 +292,23 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
 
-   opp@5000 {
+   opp-5000 {
opp-hz = /bits/ 64 <5000>;
opp-microvolt = <90>;
};
-   opp@8000 {
+   opp-8000 {
opp-hz = /bits/ 64 <8000>;
opp-microvolt = <90>;
};
-   opp@1 {
+   opp-1 {
opp-hz = /bits/ 64 <1>;
opp-microvolt = <100>;
};
-   opp@13400 {
+   opp-13400 {
opp-hz = /bits/ 64 <13400>;
opp-microvolt = <100>;
};
-   opp@2 {
+   opp-2 {
opp-hz = /bits/ 64 <2>;
opp-microvolt = <100>;
};
@@ -318,19 +318,19 @@ is able to support the bus frequency for all Exynos SoCs.
compatible = "operating-points-v2";
opp-shared;
 
-   opp@5000 {
+   opp-5000 {
opp-hz = /bits/ 64 <5000>;
};
-   opp@8000 {
+   opp-8000 {
opp-hz = /bits/ 64 <8000>;
};
-   opp@1 {
+   opp-1 {
opp-hz = /bits/ 64 <1>;
};
-   opp@2 {
+   opp-2 {
opp-hz = /bits/ 64 <2>;
};
-   opp@4 {
+   opp-4 {
opp-hz = /bits/ 64 <4>;
};
};
@@ -339,19 +339,19 @@ is able to 

Re: [PATCH 2/4] drm: Add drm_object lease infrastructure

[Michel Dänzer]

On 03/04/17 01:31 AM, Keith Packard wrote:
> Daniel Vetter  writes:
> 
>> I'm also not sure whether we really want sub-leases in v1, that's easy
>> to add later on, but for now just complicates stuff. Main compositor
>> should be a full master, VR can be the first lease level, we don't
>> need more I think for now?
> 
> We've discussed how leases might be used to implement multi-user
> support, so offering sub-leases means that environment could also
> support leasing resources out from the users session.
> 
> We also just don't know how useful it might be until we explore the
> space a bit more.

It should only be added upstream once it's clear that it's useful.


> Given that it takes years to get new features into distributions, I
> tend to error on the side of generality.

Why would it take years? Distros seem to generally use the latest
upstream kernel release available at release/freeze.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/4] drm: Add drm_object lease infrastructure

[Michel Dänzer]

On 03/04/17 01:31 AM, Keith Packard wrote:
> Daniel Vetter  writes:
> 
>> I'm also not sure whether we really want sub-leases in v1, that's easy
>> to add later on, but for now just complicates stuff. Main compositor
>> should be a full master, VR can be the first lease level, we don't
>> need more I think for now?
> 
> We've discussed how leases might be used to implement multi-user
> support, so offering sub-leases means that environment could also
> support leasing resources out from the users session.
> 
> We also just don't know how useful it might be until we explore the
> space a bit more.

It should only be added upstream once it's clear that it's useful.


> Given that it takes years to get new features into distributions, I
> tend to error on the side of generality.

Why would it take years? Distros seem to generally use the latest
upstream kernel release available at release/freeze.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



signature.asc
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi Greg,

After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/staging/rtl8723bs/core/rtw_ieee80211.c: In function 'rtw_macaddr_cfg':
drivers/staging/rtl8723bs/core/rtw_ieee80211.c:1193:22: error: implicit 
declaration of function 'of_get_property' 
[-Werror=implicit-function-declaration]
  (addr = of_get_property(np, "local-mac-address", )) &&
  ^
drivers/staging/rtl8723bs/core/rtw_ieee80211.c:1193:20: warning: assignment 
makes pointer from integer without a cast [-Wint-conversion]
  (addr = of_get_property(np, "local-mac-address", )) &&
^

Caused by commit

  554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")

I have used the staging tree from next-20170407 for today.

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Greg,

After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/staging/rtl8723bs/core/rtw_ieee80211.c: In function 'rtw_macaddr_cfg':
drivers/staging/rtl8723bs/core/rtw_ieee80211.c:1193:22: error: implicit 
declaration of function 'of_get_property' 
[-Werror=implicit-function-declaration]
  (addr = of_get_property(np, "local-mac-address", )) &&
  ^
drivers/staging/rtl8723bs/core/rtw_ieee80211.c:1193:20: warning: assignment 
makes pointer from integer without a cast [-Wint-conversion]
  (addr = of_get_property(np, "local-mac-address", )) &&
^

Caused by commit

  554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")

I have used the staging tree from next-20170407 for today.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] phy: qcom-qmp: select COMMON_CLK

[Kishon Vijay Abraham I]

Hi,

On Monday 10 April 2017 02:45 AM, Jérémy Lefaure wrote:
> It is impossible to build Qualcom QMP phy driver without COMMON_CLK
> enabled:
>   CC  drivers/phy/phy-qcom-qmp.o
> drivers/phy/phy-qcom-qmp.c: In function ‘phy_pipe_clk_register’:
> drivers/phy/phy-qcom-qmp.c:932:9: error: variable ‘init’ has initializer
> but incomplete type
>   struct clk_init_data init = { };
>  ^
> drivers/phy/phy-qcom-qmp.c:932:23: error: storage size of ‘init’ isn’t
> known
>   struct clk_init_data init = { };
>^~~~
> ...
> 
> Selecting COMMON_CLK when PHY_QCOM_QMP is enabled fix this issue.
> 
> Fixes: 93a8c0c7b1ad ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets")
> Signed-off-by: Jérémy Lefaure 

Vivek has already sent a patch for this. I have picked that.

Thanks
Kishon
> ---
>  drivers/phy/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index c120071fd2c8..e881eb2ef305 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -443,6 +443,7 @@ config PHY_QCOM_QMP
>   tristate "Qualcomm QMP PHY Driver"
>   depends on OF && (ARCH_QCOM || COMPILE_TEST)
>   select GENERIC_PHY
> + select COMMON_CLK
>   help
> Enable this to support the QMP PHY transceiver that is used
> with controllers such as PCIe, UFS, and USB on Qualcomm chips.
> 

Re: [PATCH] phy: qcom-qmp: select COMMON_CLK

[Kishon Vijay Abraham I]

Hi,

On Monday 10 April 2017 02:45 AM, Jérémy Lefaure wrote:
> It is impossible to build Qualcom QMP phy driver without COMMON_CLK
> enabled:
>   CC  drivers/phy/phy-qcom-qmp.o
> drivers/phy/phy-qcom-qmp.c: In function ‘phy_pipe_clk_register’:
> drivers/phy/phy-qcom-qmp.c:932:9: error: variable ‘init’ has initializer
> but incomplete type
>   struct clk_init_data init = { };
>  ^
> drivers/phy/phy-qcom-qmp.c:932:23: error: storage size of ‘init’ isn’t
> known
>   struct clk_init_data init = { };
>^~~~
> ...
> 
> Selecting COMMON_CLK when PHY_QCOM_QMP is enabled fix this issue.
> 
> Fixes: 93a8c0c7b1ad ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets")
> Signed-off-by: Jérémy Lefaure 

Vivek has already sent a patch for this. I have picked that.

Thanks
Kishon
> ---
>  drivers/phy/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index c120071fd2c8..e881eb2ef305 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -443,6 +443,7 @@ config PHY_QCOM_QMP
>   tristate "Qualcomm QMP PHY Driver"
>   depends on OF && (ARCH_QCOM || COMPILE_TEST)
>   select GENERIC_PHY
> + select COMMON_CLK
>   help
> Enable this to support the QMP PHY transceiver that is used
> with controllers such as PCIe, UFS, and USB on Qualcomm chips.
> 

Re: Recommended notation for OPP to avoid DTC warnings

[Viresh Kumar]

On 31-03-17, 11:59, Masahiro Yamada wrote:
> Hi.
> 
> 2017-02-27 19:55 GMT+09:00 Viresh Kumar :
> > On 27-02-17, 10:44, Mark Rutland wrote:
> >> On Sun, Feb 26, 2017 at 02:18:03PM +0900, Masahiro Yamada wrote:
> >> > Hi.
> >> >
> >> >
> >> > Decumentation/devicetree/bindings/opp/opp.txt
> >> > takes examples like this:
> >> >
> >> > opp@10 {
> >> > opp-hz = /bits/ 64 <10>;
> >> > opp-microvolt = <97 975000 985000>;
> >> > opp-microamp = <7>;
> >> > clock-latency-ns = <30>;
> >> > opp-suspend;
> >> > };
> >>
> >> > If we follow this notation and the device-tree is built with W=1,
> >> > DTC warns like follows:
> >> >
> >> > Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
> >> > unit name, but no reg property
> >> >
> >> > Is there a recommended notation to avoid it?
> >> >
> >> > Maybe, simply omit the "@" ?
> >>
> >> I think just s/@/-/ should be fine, e.g. call the above opp-10.
> >
> > That's fine with me. I can send a patch to fix all existing users if we all
> > agree for it.
> >
> > --
> > viresh
> 
> 
> Any progress on this?
> 
> Did we reach on agreement with s/@/-/  ?

We can follow this as no one else objected. I will send a patch for existing
entries and you can do it for the newer ones.

-- 
viresh

Re: Recommended notation for OPP to avoid DTC warnings

[Viresh Kumar]

On 31-03-17, 11:59, Masahiro Yamada wrote:
> Hi.
> 
> 2017-02-27 19:55 GMT+09:00 Viresh Kumar :
> > On 27-02-17, 10:44, Mark Rutland wrote:
> >> On Sun, Feb 26, 2017 at 02:18:03PM +0900, Masahiro Yamada wrote:
> >> > Hi.
> >> >
> >> >
> >> > Decumentation/devicetree/bindings/opp/opp.txt
> >> > takes examples like this:
> >> >
> >> > opp@10 {
> >> > opp-hz = /bits/ 64 <10>;
> >> > opp-microvolt = <97 975000 985000>;
> >> > opp-microamp = <7>;
> >> > clock-latency-ns = <30>;
> >> > opp-suspend;
> >> > };
> >>
> >> > If we follow this notation and the device-tree is built with W=1,
> >> > DTC warns like follows:
> >> >
> >> > Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
> >> > unit name, but no reg property
> >> >
> >> > Is there a recommended notation to avoid it?
> >> >
> >> > Maybe, simply omit the "@" ?
> >>
> >> I think just s/@/-/ should be fine, e.g. call the above opp-10.
> >
> > That's fine with me. I can send a patch to fix all existing users if we all
> > agree for it.
> >
> > --
> > viresh
> 
> 
> Any progress on this?
> 
> Did we reach on agreement with s/@/-/  ?

We can follow this as no one else objected. I will send a patch for existing
entries and you can do it for the newer ones.

-- 
viresh

Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage

[Sergey Senozhatsky]

On (04/09/17 12:12), Pavel Machek wrote:
[..]
> > a side note,
> > that's rather unclear to me how would "message delayed" really help.
> > if your system hard-lockup so badly and there are no printk messages
> > even from NMI watchdog, then we won't be able to print that message.
> 
> We are talking about
> 
>printk("unusual condition");
>do_something_clever(); /* Which unfortunately hard-crashes the machine */
> 
> that works with my proposal, but not with yours. Seen it happen many
> times before.

I see your point, sure.
I can't completely agree on "that works with my proposal, but not with yours."

on SMP system this would be true only if no other CPU holds the console_sem
at the time we call printk(). (skipping irrelevant cases when we have suspended
console or !online CPU and !CON_ANYTIME console). and there is nothing that
makes "no other CPU holds the console_sem" always true on SMP system at any
given point in time. so no, "A always works, B never works" is not accurate.

but, once again, I see your point.

-ss

Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage

[Sergey Senozhatsky]

On (04/09/17 12:12), Pavel Machek wrote:
[..]
> > a side note,
> > that's rather unclear to me how would "message delayed" really help.
> > if your system hard-lockup so badly and there are no printk messages
> > even from NMI watchdog, then we won't be able to print that message.
> 
> We are talking about
> 
>printk("unusual condition");
>do_something_clever(); /* Which unfortunately hard-crashes the machine */
> 
> that works with my proposal, but not with yours. Seen it happen many
> times before.

I see your point, sure.
I can't completely agree on "that works with my proposal, but not with yours."

on SMP system this would be true only if no other CPU holds the console_sem
at the time we call printk(). (skipping irrelevant cases when we have suspended
console or !online CPU and !CON_ANYTIME console). and there is nothing that
makes "no other CPU holds the console_sem" always true on SMP system at any
given point in time. so no, "A always works, B never works" is not accurate.

but, once again, I see your point.

-ss

Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage

[Sergey Senozhatsky]

Hello Eric,

On (04/09/17 13:21), Eric W. Biederman wrote:
[..]
> It sounds like you are blaming printk when the problem is a very slow
> logging device.

sure, slow logging device definitely adds up to the problem. if there
is no delay in call_console_driver() then printk()->console_unlock()
take no time. anything (uart, fbdev, etc.) that makes call_console_drivers()
slower makes printk() slower. the patch set is not about offloading during
panic(), when offloading make no sense, as you mentioned, or about
uncommon/extreme/impossible cases of 45sec delays in printk. no.

but about the fact that printk() called from inappropriate context
can introduce delays/timeouts/stalls and lockups. several CPUs may call
printk simultaneously, but we don't have any mechanism that would grant
console_sem ownership to a CPU in !atomic context. the winner (the CPU
that first acquires console_sem) prints it all, as long as there are
pending messages.

e.g.
 lkml.kernel.org/r/20160701165959.GR12473@ubuntu
e.g.
 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/printk/printk.c?id=8d91f8b15361dfb438ab6eb3b319e2ded43458ff

and so on.

I've even seen when printk->console_unlock() invoked from RCU read side
caused OOM condition (some RCU protected objects are small, but some are
big -- e.g. slab pages: kmem_rcu_free()). that's very rare, but I've seen
it.

so there are too many uncertainties and too many inappropriate contexts
for printk.

but yes, you are right, if there is nothing that makes call_console_driver()
slow, then there is no issue.

-ss

Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage

[Sergey Senozhatsky]

Hello Eric,

On (04/09/17 13:21), Eric W. Biederman wrote:
[..]
> It sounds like you are blaming printk when the problem is a very slow
> logging device.

sure, slow logging device definitely adds up to the problem. if there
is no delay in call_console_driver() then printk()->console_unlock()
take no time. anything (uart, fbdev, etc.) that makes call_console_drivers()
slower makes printk() slower. the patch set is not about offloading during
panic(), when offloading make no sense, as you mentioned, or about
uncommon/extreme/impossible cases of 45sec delays in printk. no.

but about the fact that printk() called from inappropriate context
can introduce delays/timeouts/stalls and lockups. several CPUs may call
printk simultaneously, but we don't have any mechanism that would grant
console_sem ownership to a CPU in !atomic context. the winner (the CPU
that first acquires console_sem) prints it all, as long as there are
pending messages.

e.g.
 lkml.kernel.org/r/20160701165959.GR12473@ubuntu
e.g.
 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/printk/printk.c?id=8d91f8b15361dfb438ab6eb3b319e2ded43458ff

and so on.

I've even seen when printk->console_unlock() invoked from RCU read side
caused OOM condition (some RCU protected objects are small, but some are
big -- e.g. slab pages: kmem_rcu_free()). that's very rare, but I've seen
it.

so there are too many uncertainties and too many inappropriate contexts
for printk.

but yes, you are right, if there is nothing that makes call_console_driver()
slow, then there is no issue.

-ss

Re: [greybus-dev] [PATCH] staging: greybus: compress return logic

[Viresh Kumar]

On 25-03-17, 10:50, Arushi Singhal wrote:
> Simplify function returns by merging assignment and return.
> 
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/greybus/loopback.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/greybus/loopback.c 
> b/drivers/staging/greybus/loopback.c
> index aaf29a5fac83..08e255884206 100644
> --- a/drivers/staging/greybus/loopback.c
> +++ b/drivers/staging/greybus/loopback.c
> @@ -365,11 +365,8 @@ static void gb_loopback_calculate_stats(struct 
> gb_loopback *gb, bool error);
>  
>  static u32 gb_loopback_nsec_to_usec_latency(u64 elapsed_nsecs)
>  {
> - u32 lat;
> -
>   do_div(elapsed_nsecs, NSEC_PER_USEC);
> - lat = elapsed_nsecs;
> - return lat;
> + return elapsed_nsecs;
>  }
>  
>  static u64 __gb_loopback_calc_latency(u64 t1, u64 t2)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [greybus-dev] [PATCH] staging: greybus: compress return logic

[Viresh Kumar]

On 25-03-17, 10:50, Arushi Singhal wrote:
> Simplify function returns by merging assignment and return.
> 
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/greybus/loopback.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/greybus/loopback.c 
> b/drivers/staging/greybus/loopback.c
> index aaf29a5fac83..08e255884206 100644
> --- a/drivers/staging/greybus/loopback.c
> +++ b/drivers/staging/greybus/loopback.c
> @@ -365,11 +365,8 @@ static void gb_loopback_calculate_stats(struct 
> gb_loopback *gb, bool error);
>  
>  static u32 gb_loopback_nsec_to_usec_latency(u64 elapsed_nsecs)
>  {
> - u32 lat;
> -
>   do_div(elapsed_nsecs, NSEC_PER_USEC);
> - lat = elapsed_nsecs;
> - return lat;
> + return elapsed_nsecs;
>  }
>  
>  static u64 __gb_loopback_calc_latency(u64 t1, u64 t2)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 3/4] drm: Check mode object lease status in all master ioctl paths

[Keith Packard]

Daniel Vetter  writes:

> I think it'd be good if we could consolidate all the lease checking into
> drm_mode_object_find (respectively __drm_mode_object_find). We'd need to
> wire up the fpriv to be able to do that, but we could upstream that patch
> right away before anything else. That should take care of most of the
> checks in this patch here.

Hrm. Without some major changes, the effect of this will be to have the
lessee see only the objects which it holds a lease on. I think that's OK
as the lessor will be doing object filtering for its clients, however
it's not what Dave and I discussed, so I just want to make him aware
that the kernel is going to be simpler than originally planned. We had
originally discussed having the lessee see the un-leased objects, but to
have them reported with different status.

-- 
-keith


signature.asc
Description: PGP signature

Re: [PATCH 3/4] drm: Check mode object lease status in all master ioctl paths

[Keith Packard]

Daniel Vetter  writes:

> I think it'd be good if we could consolidate all the lease checking into
> drm_mode_object_find (respectively __drm_mode_object_find). We'd need to
> wire up the fpriv to be able to do that, but we could upstream that patch
> right away before anything else. That should take care of most of the
> checks in this patch here.

Hrm. Without some major changes, the effect of this will be to have the
lessee see only the objects which it holds a lease on. I think that's OK
as the lessor will be doing object filtering for its clients, however
it's not what Dave and I discussed, so I just want to make him aware
that the kernel is going to be simpler than originally planned. We had
originally discussed having the lessee see the un-leased objects, but to
have them reported with different status.

-- 
-keith


signature.asc
Description: PGP signature

[PATCH] drivers/staging/iio: braces {} are not necessary for single statement blocks

[Pushkar Jambhlekar]

Handling checkpatch.pl warning for if block. For single if statement block, 
braces are not neccessary. Making code consistent with linux kernel coding 
guidelines.

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/staging/iio/accel/adis16203.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/accel/adis16203.c 
b/drivers/staging/iio/accel/adis16203.c
index faa2869..401386a 100644
--- a/drivers/staging/iio/accel/adis16203.c
+++ b/drivers/staging/iio/accel/adis16203.c
@@ -205,9 +205,9 @@ static int adis16203_read_raw(struct iio_dev *indio_dev,
bits = 14;
addr = adis16203_addresses[chan->scan_index];
ret = adis_read_reg_16(st, addr, );
-   if (ret) {
+   if (ret)
return ret;
-   }
+
val16 &= (1 << bits) - 1;
val16 = (s16)(val16 << (16 - bits)) >> (16 - bits);
*val = val16;
-- 
2.7.4

[PATCH] drivers/staging/iio: braces {} are not necessary for single statement blocks

[Pushkar Jambhlekar]

Handling checkpatch.pl warning for if block. For single if statement block, 
braces are not neccessary. Making code consistent with linux kernel coding 
guidelines.

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/staging/iio/accel/adis16203.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/accel/adis16203.c 
b/drivers/staging/iio/accel/adis16203.c
index faa2869..401386a 100644
--- a/drivers/staging/iio/accel/adis16203.c
+++ b/drivers/staging/iio/accel/adis16203.c
@@ -205,9 +205,9 @@ static int adis16203_read_raw(struct iio_dev *indio_dev,
bits = 14;
addr = adis16203_addresses[chan->scan_index];
ret = adis_read_reg_16(st, addr, );
-   if (ret) {
+   if (ret)
return ret;
-   }
+
val16 &= (1 << bits) - 1;
val16 = (s16)(val16 << (16 - bits)) >> (16 - bits);
*val = val16;
-- 
2.7.4

Re: [HMM 14/16] mm/hmm/devmem: device memory hotplug using ZONE_DEVICE

[Balbir Singh]

On Fri, 2017-04-07 at 12:26 -0400, Jerome Glisse wrote:
> On Thu, Apr 06, 2017 at 10:02:55PM -0400, Jerome Glisse wrote:
> > On Fri, Apr 07, 2017 at 11:37:34AM +1000, Balbir Singh wrote:
> > > On Wed, 2017-04-05 at 16:40 -0400, Jérôme Glisse wrote:
> > > > This introduce a simple struct and associated helpers for device driver
> > > > to use when hotpluging un-addressable device memory as ZONE_DEVICE. It
> > > > will find a unuse physical address range and trigger memory hotplug for
> > > > it which allocates and initialize struct page for the device memory.
> > > > 
> > > > Signed-off-by: Jérôme Glisse 
> > > > Signed-off-by: Evgeny Baskakov 
> > > > Signed-off-by: John Hubbard 
> > > > Signed-off-by: Mark Hairgrove 
> > > > Signed-off-by: Sherry Cheung 
> > > > Signed-off-by: Subhash Gutti 
> > > > ---
> > > >  include/linux/hmm.h | 114 +++
> > > >  mm/Kconfig  |   9 ++
> > > >  mm/hmm.c| 398 
> > > > 
> > > >  3 files changed, 521 insertions(+)
> > > > 
> > > > +/*
> > > > + * To add (hotplug) device memory, HMM assumes that there is no real 
> > > > resource
> > > > + * that reserves a range in the physical address space (this is 
> > > > intended to be
> > > > + * use by unaddressable device memory). It will reserve a physical 
> > > > range big
> > > > + * enough and allocate struct page for it.
> > > 
> > > I've found that the implementation of this is quite non-portable, in that
> > > starting from iomem_resource.end+1-size (which is effectively -size) on
> > > my platform (powerpc) does not give expected results. It could be that
> > > additional changes are needed to arch_add_memory() to support this
> > > use case.
> > 
> > The CDM version does not use that part, that being said isn't -size a valid
> > value we care only about unsigned here ? What is the end value on powerpc ?
> > In any case this sounds more like a unsigned/signed arithmetic issue, i will
> > look into it.
> > 

Thanks!

> > > 
> > > > +
> > > > +   size = ALIGN(size, SECTION_SIZE);
> > > > +   addr = (iomem_resource.end + 1ULL) - size;
> > > 
> > > 
> > > Why don't we allocate_resource() with the right constraints and get a new
> > > unused region?
> > 
> > The issue with allocate_resource() is that it does scan the resource tree
> > from lower address to higher ones. I was told that it was less likely to
> > have hotplug issue conflict if i pick highest physicall address for the
> > device memory hence why i do my own scan from the end toward the start.
> > 
> > Again all this function does not apply to PPC, it can be hidden behind
> > x86 config if you prefer it.
> 
> Ok so i have look into it and there is no arithmetic bug in my code the
> issue is simpler than that. It seems only x86 clamp iomem_resource.end to
> MAX_PHYSMEM_BITS so using allocate_resource() would just hide the issue.

> 
> It is fine not to clamp if you know that you won't get resource with
> funky physical address but in case of UNADDRESSABLE i do not get any
> physical address so i have to pick one and i want to pick one that is
> unlikely to cause trouble latter on with someone hotpluging memory.
> 
> If we care about the UNADDRESSABLE case on powerpc i see 2 way to fix
> this. Clamp iomem_resource.end to MAX_PHYSMEM_BITS or restrict my scan
> in hmm to MIN(iomem_resource.end, 1UL << MAX_PHYSMEM_BITS) the latter
> is probably safer and more bullet proof in respect to other arch getting
> interested in this.
>

We do care about UNADDRESSABLE for certain platforms on powerpc
 
I think MAX_PHYSMEM_BITS sounds good or we can make it an arch hook. I spoke
to Michael Ellerman and he recommended we do either. We can't clamp down
iomem_resource.end in the arch as we have other things beyond MAX_PHYSMEM_BITS,
but doing the walk in HMM from the end of MAX_PHYSMEM_BITS is a good idea to
begin with.

Balbir Singh.

Re: [RFC] x86/tboot: add an option to disable iommu force on

[Shaohua Li]

On Fri, Apr 07, 2017 at 09:49:52PM +, Sun, Ning wrote:
> Hi Shaohua,
> 
> One question, did you still see the network performance penalty when Linux 
> kernel cmdline intel_iommu was set to off ( intel_iommu=off) ?

the boot parameter has no effect, it runs very early and set dmar_disable=1.
The tboot code (tboot_force_iommu) runs later and force dmar_disabled = 0.

Thanks,
Shaohua
 
> Thanks,
> -ning
> 
> -Original Message-
> From: Joerg Roedel [mailto:jroe...@suse.de] 
> Sent: Friday, April 07, 2017 3:09 AM
> To: Shaohua Li 
> Cc: linux-kernel@vger.kernel.org; Wei, Gang ; 
> h...@linux.intel.com; mi...@kernel.org; kernel-t...@fb.com; Sun, Ning 
> ; sri...@fb.com; Eydelberg, Alex 
> 
> Subject: Re: [RFC] x86/tboot: add an option to disable iommu force on
> 
> On Mon, Apr 03, 2017 at 12:19:28PM -0700, Shaohua Li wrote:
> > On Wed, Mar 22, 2017 at 07:50:55AM -0400, Shaohua Li wrote:
> > > On Wed, Mar 22, 2017 at 11:49:00AM +0100, Joerg Roedel wrote:
> > > > Hi Shaohua,
> > > > 
> > > > On Tue, Mar 21, 2017 at 11:37:51AM -0700, Shaohua Li wrote:
> > > > > IOMMU harms performance signficantly when we run very fast 
> > > > > networking workloads. This is a limitation in hardware based on 
> > > > > our observation, so we'd like to disable the IOMMU force on, but 
> > > > > we do want to use TBOOT and we can sacrifice the DMA security 
> > > > > bought by IOMMU. I must admit I know nothing about TBOOT, but 
> > > > > TBOOT guys (cc-ed) think not eabling IOMMU is totally ok.
> > > > 
> > > > Can you elaborate a bit more on the setup where the IOMMU still 
> > > > harms network performance? With the recent scalability 
> > > > improvements I measured only a minimal impact on 10GBit networking.
> > > Hi,
> > > 
> > > It's 40GB networking doing XDP test. Software overhead is almost 
> > > unaware, but it's the IOTLB miss (based on our analysis) which kills 
> > > the performance. We observed the same performance issue even with 
> > > software passthrough (identity mapping), only the hardware 
> > > passthrough survives. The pps with iommu (with software passthrough) is 
> > > only about ~30% of that without it.
> > 
> > Any update on this?
> 
> An explicit Ack from the tboot guys would be good to have.
> 
> 
>   Joerg
> 

Re: [HMM 14/16] mm/hmm/devmem: device memory hotplug using ZONE_DEVICE

[Balbir Singh]

On Fri, 2017-04-07 at 12:26 -0400, Jerome Glisse wrote:
> On Thu, Apr 06, 2017 at 10:02:55PM -0400, Jerome Glisse wrote:
> > On Fri, Apr 07, 2017 at 11:37:34AM +1000, Balbir Singh wrote:
> > > On Wed, 2017-04-05 at 16:40 -0400, Jérôme Glisse wrote:
> > > > This introduce a simple struct and associated helpers for device driver
> > > > to use when hotpluging un-addressable device memory as ZONE_DEVICE. It
> > > > will find a unuse physical address range and trigger memory hotplug for
> > > > it which allocates and initialize struct page for the device memory.
> > > > 
> > > > Signed-off-by: Jérôme Glisse 
> > > > Signed-off-by: Evgeny Baskakov 
> > > > Signed-off-by: John Hubbard 
> > > > Signed-off-by: Mark Hairgrove 
> > > > Signed-off-by: Sherry Cheung 
> > > > Signed-off-by: Subhash Gutti 
> > > > ---
> > > >  include/linux/hmm.h | 114 +++
> > > >  mm/Kconfig  |   9 ++
> > > >  mm/hmm.c| 398 
> > > > 
> > > >  3 files changed, 521 insertions(+)
> > > > 
> > > > +/*
> > > > + * To add (hotplug) device memory, HMM assumes that there is no real 
> > > > resource
> > > > + * that reserves a range in the physical address space (this is 
> > > > intended to be
> > > > + * use by unaddressable device memory). It will reserve a physical 
> > > > range big
> > > > + * enough and allocate struct page for it.
> > > 
> > > I've found that the implementation of this is quite non-portable, in that
> > > starting from iomem_resource.end+1-size (which is effectively -size) on
> > > my platform (powerpc) does not give expected results. It could be that
> > > additional changes are needed to arch_add_memory() to support this
> > > use case.
> > 
> > The CDM version does not use that part, that being said isn't -size a valid
> > value we care only about unsigned here ? What is the end value on powerpc ?
> > In any case this sounds more like a unsigned/signed arithmetic issue, i will
> > look into it.
> > 

Thanks!

> > > 
> > > > +
> > > > +   size = ALIGN(size, SECTION_SIZE);
> > > > +   addr = (iomem_resource.end + 1ULL) - size;
> > > 
> > > 
> > > Why don't we allocate_resource() with the right constraints and get a new
> > > unused region?
> > 
> > The issue with allocate_resource() is that it does scan the resource tree
> > from lower address to higher ones. I was told that it was less likely to
> > have hotplug issue conflict if i pick highest physicall address for the
> > device memory hence why i do my own scan from the end toward the start.
> > 
> > Again all this function does not apply to PPC, it can be hidden behind
> > x86 config if you prefer it.
> 
> Ok so i have look into it and there is no arithmetic bug in my code the
> issue is simpler than that. It seems only x86 clamp iomem_resource.end to
> MAX_PHYSMEM_BITS so using allocate_resource() would just hide the issue.

> 
> It is fine not to clamp if you know that you won't get resource with
> funky physical address but in case of UNADDRESSABLE i do not get any
> physical address so i have to pick one and i want to pick one that is
> unlikely to cause trouble latter on with someone hotpluging memory.
> 
> If we care about the UNADDRESSABLE case on powerpc i see 2 way to fix
> this. Clamp iomem_resource.end to MAX_PHYSMEM_BITS or restrict my scan
> in hmm to MIN(iomem_resource.end, 1UL << MAX_PHYSMEM_BITS) the latter
> is probably safer and more bullet proof in respect to other arch getting
> interested in this.
>

We do care about UNADDRESSABLE for certain platforms on powerpc
 
I think MAX_PHYSMEM_BITS sounds good or we can make it an arch hook. I spoke
to Michael Ellerman and he recommended we do either. We can't clamp down
iomem_resource.end in the arch as we have other things beyond MAX_PHYSMEM_BITS,
but doing the walk in HMM from the end of MAX_PHYSMEM_BITS is a good idea to
begin with.

Balbir Singh.

Re: [RFC] x86/tboot: add an option to disable iommu force on

[Shaohua Li]

On Fri, Apr 07, 2017 at 09:49:52PM +, Sun, Ning wrote:
> Hi Shaohua,
> 
> One question, did you still see the network performance penalty when Linux 
> kernel cmdline intel_iommu was set to off ( intel_iommu=off) ?

the boot parameter has no effect, it runs very early and set dmar_disable=1.
The tboot code (tboot_force_iommu) runs later and force dmar_disabled = 0.

Thanks,
Shaohua
 
> Thanks,
> -ning
> 
> -Original Message-
> From: Joerg Roedel [mailto:jroe...@suse.de] 
> Sent: Friday, April 07, 2017 3:09 AM
> To: Shaohua Li 
> Cc: linux-kernel@vger.kernel.org; Wei, Gang ; 
> h...@linux.intel.com; mi...@kernel.org; kernel-t...@fb.com; Sun, Ning 
> ; sri...@fb.com; Eydelberg, Alex 
> 
> Subject: Re: [RFC] x86/tboot: add an option to disable iommu force on
> 
> On Mon, Apr 03, 2017 at 12:19:28PM -0700, Shaohua Li wrote:
> > On Wed, Mar 22, 2017 at 07:50:55AM -0400, Shaohua Li wrote:
> > > On Wed, Mar 22, 2017 at 11:49:00AM +0100, Joerg Roedel wrote:
> > > > Hi Shaohua,
> > > > 
> > > > On Tue, Mar 21, 2017 at 11:37:51AM -0700, Shaohua Li wrote:
> > > > > IOMMU harms performance signficantly when we run very fast 
> > > > > networking workloads. This is a limitation in hardware based on 
> > > > > our observation, so we'd like to disable the IOMMU force on, but 
> > > > > we do want to use TBOOT and we can sacrifice the DMA security 
> > > > > bought by IOMMU. I must admit I know nothing about TBOOT, but 
> > > > > TBOOT guys (cc-ed) think not eabling IOMMU is totally ok.
> > > > 
> > > > Can you elaborate a bit more on the setup where the IOMMU still 
> > > > harms network performance? With the recent scalability 
> > > > improvements I measured only a minimal impact on 10GBit networking.
> > > Hi,
> > > 
> > > It's 40GB networking doing XDP test. Software overhead is almost 
> > > unaware, but it's the IOTLB miss (based on our analysis) which kills 
> > > the performance. We observed the same performance issue even with 
> > > software passthrough (identity mapping), only the hardware 
> > > passthrough survives. The pps with iommu (with software passthrough) is 
> > > only about ~30% of that without it.
> > 
> > Any update on this?
> 
> An explicit Ack from the tboot guys would be good to have.
> 
> 
>   Joerg
> 

[PATCHv3] phy: cpcap-usb: Add CPCAP PMIC USB support

[Tony Lindgren]

Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a
multiplexing USB PHY.

This USB PHY can operate at least in four modes using pin multiplexing
and two control GPIOS:

- Pass through companion PHY for the SoC USB PHY
- ULPI PHY for the SoC
- Pass through USB for the modem
- UART debug console for the SoC

This patch adds support for droid 4 USB PHY and debug UART modes,
support for other modes can be added later on as needed.

Both peripheral and host mode are working for the USB. The
host mode depends on the cpcap-charger driver for VBUS.

VBUS and ID pin detection are done using cpcap-adc IIO ADC
driver.

Cc: devicet...@vger.kernel.org
Cc: Marcel Partap 
Cc: Michael Scott 
Acked-by: Rob Herring 
Tested-by: Sebastian Reichel 
Signed-off-by: Tony Lindgren 
---

Changes since v2:
- Added extcon support as requested by Kishon

- Added Rob's ack

- Folded in Kconfig randconfig build fix to add depends on IIO

Changes since v1:
- Use iio_read_channel_processed() instead of iio_read_channel_scaled()
  as changed in the v2 of the ADC driver

- Kept Tested-by from Sebastian Reichel  as the change
  from v1 is trivial

---
 .../devicetree/bindings/phy/phy-cpcap-usb.txt  |  40 ++
 drivers/phy/Kconfig|   8 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-cpcap-usb.c| 734 +
 4 files changed, 783 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
 create mode 100644 drivers/phy/phy-cpcap-usb.c

diff --git a/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
@@ -0,0 +1,40 @@
+Motorola CPCAP PMIC USB PHY binding
+
+Required properties:
+compatible: Shall be either "motorola,cpcap-usb-phy" or
+   "motorola,mapphone-cpcap-usb-phy"
+#phy-cells: Shall be 0
+interrupts: CPCAP PMIC interrupts used by the USB PHY
+interrupt-names: Interrupt names
+io-channels: IIO ADC channels used by the USB PHY
+io-channel-names: IIO ADC channel names
+vusb-supply: Regulator for the PHY
+
+Optional properties:
+pinctrl: Optional alternate pin modes for the PHY
+pinctrl-names: Names for optional pin modes
+mode-gpios: Optional GPIOs for configuring alternate modes
+
+Example:
+cpcap_usb2_phy: phy {
+   compatible = "motorola,mapphone-cpcap-usb-phy";
+   pinctrl-0 = <_gpio_mux_sel1 _gpio_mux_sel2>;
+   pinctrl-1 = <_ulpi_pins>;
+   pinctrl-2 = <_utmi_pins>;
+   pinctrl-3 = <_pins>;
+   pinctrl-names = "default", "ulpi", "utmi", "uart";
+   #phy-cells = <0>;
+   interrupts-extended = <
+15 0  14 0  28 0  19 0
+18 0  17 0  16 0  49 0
+48 1
+   >;
+   interrupt-names =
+   "id_ground", "id_float", "se0conn", "vbusvld",
+   "sessvld", "sessend", "se1", "dm", "dp";
+   mode-gpios = < 28 GPIO_ACTIVE_HIGH
+  0 GPIO_ACTIVE_HIGH>;
+   io-channels = <_adc 2>, <_adc 7>;
+   io-channel-names = "vbus", "id";
+   vusb-supply = <>;
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -47,6 +47,14 @@ config PHY_BERLIN_SATA
help
  Enable this to support the SATA PHY on Marvell Berlin SoCs.
 
+config PHY_CPCAP_USB
+   tristate "CPCAP USB PHY driver"
+   depends on USB_SUPPORT && IIO
+   select GENERIC_PHY
+   select USB_PHY
+   help
+ Enable this for CPCAP USB to work.
+
 config ARMADA375_USBCLUSTER_PHY
def_bool y
depends on MACH_ARMADA_375 || COMPILE_TEST
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PHY_BCM_NS_USB2)   += phy-bcm-ns-usb2.o
 obj-$(CONFIG_PHY_BCM_NS_USB3)  += phy-bcm-ns-usb3.o
 obj-$(CONFIG_PHY_BERLIN_USB)   += phy-berlin-usb.o
 obj-$(CONFIG_PHY_BERLIN_SATA)  += phy-berlin-sata.o
+obj-$(CONFIG_PHY_CPCAP_USB)+= phy-cpcap-usb.o
 obj-$(CONFIG_PHY_DA8XX_USB)+= phy-da8xx-usb.o
 obj-$(CONFIG_PHY_DM816X_USB)   += phy-dm816x-usb.o
 obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
diff --git a/drivers/phy/phy-cpcap-usb.c b/drivers/phy/phy-cpcap-usb.c
new file mode 100644
--- /dev/null
+++ b/drivers/phy/phy-cpcap-usb.c
@@ -0,0 +1,734 @@
+/*
+ * Motorola CPCAP PMIC USB PHY driver
+ * Copyright (C) 2017 Tony Lindgren 
+ *
+ * Some parts based on earlier Motorola Linux kernel tree code in
+ * board-mapphone-usb.c and cpcap-usb-det.c:
+ * Copyright (C) 2007 - 2011 Motorola, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under 

[PATCHv3] phy: cpcap-usb: Add CPCAP PMIC USB support

[Tony Lindgren]

Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a
multiplexing USB PHY.

This USB PHY can operate at least in four modes using pin multiplexing
and two control GPIOS:

- Pass through companion PHY for the SoC USB PHY
- ULPI PHY for the SoC
- Pass through USB for the modem
- UART debug console for the SoC

This patch adds support for droid 4 USB PHY and debug UART modes,
support for other modes can be added later on as needed.

Both peripheral and host mode are working for the USB. The
host mode depends on the cpcap-charger driver for VBUS.

VBUS and ID pin detection are done using cpcap-adc IIO ADC
driver.

Cc: devicet...@vger.kernel.org
Cc: Marcel Partap 
Cc: Michael Scott 
Acked-by: Rob Herring 
Tested-by: Sebastian Reichel 
Signed-off-by: Tony Lindgren 
---

Changes since v2:
- Added extcon support as requested by Kishon

- Added Rob's ack

- Folded in Kconfig randconfig build fix to add depends on IIO

Changes since v1:
- Use iio_read_channel_processed() instead of iio_read_channel_scaled()
  as changed in the v2 of the ADC driver

- Kept Tested-by from Sebastian Reichel  as the change
  from v1 is trivial

---
 .../devicetree/bindings/phy/phy-cpcap-usb.txt  |  40 ++
 drivers/phy/Kconfig|   8 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-cpcap-usb.c| 734 +
 4 files changed, 783 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
 create mode 100644 drivers/phy/phy-cpcap-usb.c

diff --git a/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
@@ -0,0 +1,40 @@
+Motorola CPCAP PMIC USB PHY binding
+
+Required properties:
+compatible: Shall be either "motorola,cpcap-usb-phy" or
+   "motorola,mapphone-cpcap-usb-phy"
+#phy-cells: Shall be 0
+interrupts: CPCAP PMIC interrupts used by the USB PHY
+interrupt-names: Interrupt names
+io-channels: IIO ADC channels used by the USB PHY
+io-channel-names: IIO ADC channel names
+vusb-supply: Regulator for the PHY
+
+Optional properties:
+pinctrl: Optional alternate pin modes for the PHY
+pinctrl-names: Names for optional pin modes
+mode-gpios: Optional GPIOs for configuring alternate modes
+
+Example:
+cpcap_usb2_phy: phy {
+   compatible = "motorola,mapphone-cpcap-usb-phy";
+   pinctrl-0 = <_gpio_mux_sel1 _gpio_mux_sel2>;
+   pinctrl-1 = <_ulpi_pins>;
+   pinctrl-2 = <_utmi_pins>;
+   pinctrl-3 = <_pins>;
+   pinctrl-names = "default", "ulpi", "utmi", "uart";
+   #phy-cells = <0>;
+   interrupts-extended = <
+15 0  14 0  28 0  19 0
+18 0  17 0  16 0  49 0
+48 1
+   >;
+   interrupt-names =
+   "id_ground", "id_float", "se0conn", "vbusvld",
+   "sessvld", "sessend", "se1", "dm", "dp";
+   mode-gpios = < 28 GPIO_ACTIVE_HIGH
+  0 GPIO_ACTIVE_HIGH>;
+   io-channels = <_adc 2>, <_adc 7>;
+   io-channel-names = "vbus", "id";
+   vusb-supply = <>;
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -47,6 +47,14 @@ config PHY_BERLIN_SATA
help
  Enable this to support the SATA PHY on Marvell Berlin SoCs.
 
+config PHY_CPCAP_USB
+   tristate "CPCAP USB PHY driver"
+   depends on USB_SUPPORT && IIO
+   select GENERIC_PHY
+   select USB_PHY
+   help
+ Enable this for CPCAP USB to work.
+
 config ARMADA375_USBCLUSTER_PHY
def_bool y
depends on MACH_ARMADA_375 || COMPILE_TEST
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PHY_BCM_NS_USB2)   += phy-bcm-ns-usb2.o
 obj-$(CONFIG_PHY_BCM_NS_USB3)  += phy-bcm-ns-usb3.o
 obj-$(CONFIG_PHY_BERLIN_USB)   += phy-berlin-usb.o
 obj-$(CONFIG_PHY_BERLIN_SATA)  += phy-berlin-sata.o
+obj-$(CONFIG_PHY_CPCAP_USB)+= phy-cpcap-usb.o
 obj-$(CONFIG_PHY_DA8XX_USB)+= phy-da8xx-usb.o
 obj-$(CONFIG_PHY_DM816X_USB)   += phy-dm816x-usb.o
 obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
diff --git a/drivers/phy/phy-cpcap-usb.c b/drivers/phy/phy-cpcap-usb.c
new file mode 100644
--- /dev/null
+++ b/drivers/phy/phy-cpcap-usb.c
@@ -0,0 +1,734 @@
+/*
+ * Motorola CPCAP PMIC USB PHY driver
+ * Copyright (C) 2017 Tony Lindgren 
+ *
+ * Some parts based on earlier Motorola Linux kernel tree code in
+ * board-mapphone-usb.c and cpcap-usb-det.c:
+ * Copyright (C) 2007 - 2011 Motorola, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is 

linux-next: manual merge of the kvms390 tree with the kvm, kvm-arm and kvm-ppc trees

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvms390 tree got a conflict in:

  include/uapi/linux/kvm.h

between commits:

  a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities")
  578fd61d2d21 ("KVM: MIPS: Add 64BIT capability")
  3fe17e682616 ("KVM: arm/arm64: Add ARM user space interrupt signaling ABI")
  2e60acebefd8 ("KVM: PPC: Reserve KVM_CAP_SPAPR_TCE_VFIO capability number")

from the kvm, kvm-arm and kvm-ppc trees and commits:

  4e0b1ab72b8a ("KVM: s390: gs support for kvm guests")
  47a4693e1d3e ("KVM: s390: introduce AIS capability")

from the kvms390 tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/uapi/linux/kvm.h
index 7bf2f99ebe5a,33dd2a4e36dc..
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -887,11 -883,8 +887,13 @@@ struct kvm_ppc_resize_hpt 
  #define KVM_CAP_PPC_MMU_RADIX 134
  #define KVM_CAP_PPC_MMU_HASH_V3 135
  #define KVM_CAP_IMMEDIATE_EXIT 136
 -#define KVM_CAP_S390_GS 137
 -#define KVM_CAP_S390_AIS 138
 +#define KVM_CAP_MIPS_VZ 137
 +#define KVM_CAP_MIPS_TE 138
 +#define KVM_CAP_MIPS_64BIT 139
 +#define KVM_CAP_ARM_USER_IRQ 140
 +#define KVM_CAP_SPAPR_TCE_VFIO 141
++#define KVM_CAP_S390_GS 142
++#define KVM_CAP_S390_AIS 143
  
  #ifdef KVM_CAP_IRQ_ROUTING
  

linux-next: manual merge of the kvms390 tree with the kvm, kvm-arm and kvm-ppc trees

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvms390 tree got a conflict in:

  include/uapi/linux/kvm.h

between commits:

  a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities")
  578fd61d2d21 ("KVM: MIPS: Add 64BIT capability")
  3fe17e682616 ("KVM: arm/arm64: Add ARM user space interrupt signaling ABI")
  2e60acebefd8 ("KVM: PPC: Reserve KVM_CAP_SPAPR_TCE_VFIO capability number")

from the kvm, kvm-arm and kvm-ppc trees and commits:

  4e0b1ab72b8a ("KVM: s390: gs support for kvm guests")
  47a4693e1d3e ("KVM: s390: introduce AIS capability")

from the kvms390 tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/uapi/linux/kvm.h
index 7bf2f99ebe5a,33dd2a4e36dc..
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -887,11 -883,8 +887,13 @@@ struct kvm_ppc_resize_hpt 
  #define KVM_CAP_PPC_MMU_RADIX 134
  #define KVM_CAP_PPC_MMU_HASH_V3 135
  #define KVM_CAP_IMMEDIATE_EXIT 136
 -#define KVM_CAP_S390_GS 137
 -#define KVM_CAP_S390_AIS 138
 +#define KVM_CAP_MIPS_VZ 137
 +#define KVM_CAP_MIPS_TE 138
 +#define KVM_CAP_MIPS_64BIT 139
 +#define KVM_CAP_ARM_USER_IRQ 140
 +#define KVM_CAP_SPAPR_TCE_VFIO 141
++#define KVM_CAP_S390_GS 142
++#define KVM_CAP_S390_AIS 143
  
  #ifdef KVM_CAP_IRQ_ROUTING
  

Re: [RFC PATCH 4/4] dt-bindings: Add support for devices with multiple PM domains

[Rajendra Nayak]

On 03/28/2017 07:44 PM, Jon Hunter wrote:
> Now that the generic PM domain framework supports consumers that can
> control multiple PM domains, update the device-tree binding for generic
> PM domains to state that one or more PM domain is permitted for a
> device.
> 
> Signed-off-by: Jon Hunter 
> ---
>  Documentation/devicetree/bindings/power/power_domain.txt | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt 
> b/Documentation/devicetree/bindings/power/power_domain.txt
> index 723e1ad937da..fb28d37f9e1f 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -20,8 +20,15 @@ Required properties:
> as specified by device tree binding documentation of particular provider.
>  
>  Optional properties:
> - - power-domains : A phandle and PM domain specifier as defined by bindings 
> of
> -   the power controller specified by phandle.
> + - power-domains : An array of one or more PM domain specifiers (defined by 
> the
> +bindings of the PM domain provider) for each PM domain that
> +is required by the device.
> + - power-domain-names: A list of strings of PM domain names. The list must 
> have
> +   a name for each PM domain specifier in the
> +'power-domains' property and these names must be unique
> +within the context of this property. The names must be
> +indexed so that the first name corresponds to the first
> +PM domain specifier and so on.

These bindings are for power-domain providers. We also need to update the 
bindings
for the consumers (look further down in the same file)

> Some power domains might be powered from another power domain (or have
> other hardware specific dependencies). For representing such dependency
> a standard PM domain consumer binding is used. When provided, all domains
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

Re: [RFC PATCH 4/4] dt-bindings: Add support for devices with multiple PM domains

[Rajendra Nayak]

On 03/28/2017 07:44 PM, Jon Hunter wrote:
> Now that the generic PM domain framework supports consumers that can
> control multiple PM domains, update the device-tree binding for generic
> PM domains to state that one or more PM domain is permitted for a
> device.
> 
> Signed-off-by: Jon Hunter 
> ---
>  Documentation/devicetree/bindings/power/power_domain.txt | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt 
> b/Documentation/devicetree/bindings/power/power_domain.txt
> index 723e1ad937da..fb28d37f9e1f 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -20,8 +20,15 @@ Required properties:
> as specified by device tree binding documentation of particular provider.
>  
>  Optional properties:
> - - power-domains : A phandle and PM domain specifier as defined by bindings 
> of
> -   the power controller specified by phandle.
> + - power-domains : An array of one or more PM domain specifiers (defined by 
> the
> +bindings of the PM domain provider) for each PM domain that
> +is required by the device.
> + - power-domain-names: A list of strings of PM domain names. The list must 
> have
> +   a name for each PM domain specifier in the
> +'power-domains' property and these names must be unique
> +within the context of this property. The names must be
> +indexed so that the first name corresponds to the first
> +PM domain specifier and so on.

These bindings are for power-domain providers. We also need to update the 
bindings
for the consumers (look further down in the same file)

> Some power domains might be powered from another power domain (or have
> other hardware specific dependencies). For representing such dependency
> a standard PM domain consumer binding is used. When provided, all domains
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

linux-next: manual merge of the kvm-ppc tree with the kvm and kvm-arm trees

[Stephen Rothwell]

Hi Paul,

Today's linux-next merge of the kvm-ppc tree got a conflict in:

  include/uapi/linux/kvm.h

between commits:

  a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities")
  578fd61d2d21 ("KVM: MIPS: Add 64BIT capability")
  3fe17e682616 ("KVM: arm/arm64: Add ARM user space interrupt signaling ABI")

from the kvm and kvm-arm trees and commit:

  2e60acebefd8 ("KVM: PPC: Reserve KVM_CAP_SPAPR_TCE_VFIO capability number")

from the kvm-ppc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/uapi/linux/kvm.h
index f46b8e317f84,0f8a5e6528aa..
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -887,10 -883,7 +887,11 @@@ struct kvm_ppc_resize_hpt 
  #define KVM_CAP_PPC_MMU_RADIX 134
  #define KVM_CAP_PPC_MMU_HASH_V3 135
  #define KVM_CAP_IMMEDIATE_EXIT 136
 -#define KVM_CAP_SPAPR_TCE_VFIO 137
 +#define KVM_CAP_MIPS_VZ 137
 +#define KVM_CAP_MIPS_TE 138
 +#define KVM_CAP_MIPS_64BIT 139
 +#define KVM_CAP_ARM_USER_IRQ 140
++#define KVM_CAP_SPAPR_TCE_VFIO 141
  
  #ifdef KVM_CAP_IRQ_ROUTING
  

linux-next: manual merge of the kvm-ppc tree with the kvm and kvm-arm trees

[Stephen Rothwell]

Hi Paul,

Today's linux-next merge of the kvm-ppc tree got a conflict in:

  include/uapi/linux/kvm.h

between commits:

  a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities")
  578fd61d2d21 ("KVM: MIPS: Add 64BIT capability")
  3fe17e682616 ("KVM: arm/arm64: Add ARM user space interrupt signaling ABI")

from the kvm and kvm-arm trees and commit:

  2e60acebefd8 ("KVM: PPC: Reserve KVM_CAP_SPAPR_TCE_VFIO capability number")

from the kvm-ppc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/uapi/linux/kvm.h
index f46b8e317f84,0f8a5e6528aa..
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -887,10 -883,7 +887,11 @@@ struct kvm_ppc_resize_hpt 
  #define KVM_CAP_PPC_MMU_RADIX 134
  #define KVM_CAP_PPC_MMU_HASH_V3 135
  #define KVM_CAP_IMMEDIATE_EXIT 136
 -#define KVM_CAP_SPAPR_TCE_VFIO 137
 +#define KVM_CAP_MIPS_VZ 137
 +#define KVM_CAP_MIPS_TE 138
 +#define KVM_CAP_MIPS_64BIT 139
 +#define KVM_CAP_ARM_USER_IRQ 140
++#define KVM_CAP_SPAPR_TCE_VFIO 141
  
  #ifdef KVM_CAP_IRQ_ROUTING
  

Re: [RFC PATCH 2/4] PM / Domains: Add support for explicit control of PM domains

[Rajendra Nayak]

Hey Jon,

On 03/28/2017 07:44 PM, Jon Hunter wrote:
> The current generic PM domain framework (GenDP) only allows a single
> PM domain to be associated with a given device. There are several
> use-cases for various system-on-chip devices where it is necessary for
> a PM domain consumer to control more than one PM domain where the PM
> domains:
> i).  Do not conform to a parent-child relationship so are not nested
> ii). May not be powered on and off at the same time so need independent
>  control.
> 
> To support the above, add new APIs for GenPD to allow consumers to get,
> power-on, power-off and put PM domains so that they can be explicitly
> controlled by the consumer.

thanks for working on this RFC.

[]..
  
> +/**
> + * pm_genpd_get - Get a generic I/O PM domain by name
> + * @name: Name of the PM domain.
> + *
> + * Look-ups a PM domain by name. If found, increment the device
> + * count for PM domain to ensure that the PM domain cannot be
> + * removed, increment the suspended count so that it can still
> + * be turned off (when not in-use) and return a pointer to its
> + * generic_pm_domain structure. If not found return ERR_PTR().
> + */
> +struct generic_pm_domain *pm_genpd_get(const char *name)
> +{
> + struct generic_pm_domain *gpd, *genpd = ERR_PTR(-EEXIST);
> +
> + if (!name)
> + return ERR_PTR(-EINVAL);
> +
> + mutex_lock(_list_lock);
> + list_for_each_entry(gpd, _list, gpd_list_node) {
> + if (!strcmp(gpd->name, name)) {
> + genpd_lock(gpd);
> + gpd->device_count++;

There apis' should also take a device pointer as a parameter,
so we can track all the devices belonging to a powerdomain.
That would also mean keeping the genpd->dev_list updated instead of
only incrementing the device_count here.

> + gpd->suspended_count++;
> + genpd_unlock(gpd);
> + genpd = gpd;
> + break;
> + }
> + }
> + mutex_unlock(_list_lock);
> +
> + return genpd;

Instead of returning a pointer to generic_pm_domain to all
consumers (who are then free to poke around it) we should hide
all internal structures handled by the framework and only expose
some kind of a handle to all the consumers.
That would also mean having a clear split of the headers to
distinguish between what's accessible to consumers vs providers.

regards
Rajendra

> +}
> +EXPORT_SYMBOL(pm_genpd_get);
> +
> +/**
> + * pm_genpd_put - Put a generic I/O PM domain
> + * @genpd: Pointer to a PM domain.
> + */
> +void pm_genpd_put(struct generic_pm_domain *genpd)
> +{
> + if (!genpd)
> + return;
> +
> + genpd_lock(genpd);
> +
> + if (WARN_ON(!genpd->device_count || !genpd->suspended_count))
> + goto out;
> +
> + genpd->suspended_count--;
> + genpd->device_count--;
> +
> +out:
> + genpd_unlock(genpd);
> +}
> +EXPORT_SYMBOL(pm_genpd_put);
> +
> +/**
> + * pm_genpd_poweron - Power on a generic I/O PM domain
> + * @genpd: Pointer to a PM domain.
> + *
> + * Powers on a PM domain, if not already on, and decrements the
> + * 'suspended_count' to prevent the PM domain from being powered off.
> + */
> +int pm_genpd_poweron(struct generic_pm_domain *genpd)
> +{
> + if (!genpd)
> + return -EINVAL;
> +
> + genpd_lock(genpd);
> +
> + if (WARN_ON(!genpd->suspended_count))
> + goto out;
> +
> + genpd->suspended_count--;
> + genpd_sync_power_on(genpd, true, 0);
> +
> +out:
> + genpd_unlock(genpd);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pm_genpd_poweron);
> +
> +/**
> + * pm_genpd_poweroff - Power off a generic I/O PM domain
> + * @genpd: Pointer to a PM domain.
> + *
> + * Increments the 'suspended_count' for a PM domain and if the
> + * 'suspended_count' equals the 'device_count' then will power
> + * off the PM domain.
> + */
> +int pm_genpd_poweroff(struct generic_pm_domain *genpd)
> +{
> + if (!genpd)
> + return -EINVAL;
> +
> + genpd_lock(genpd);
> +
> + if (WARN_ON(genpd->suspended_count >= genpd->device_count))
> + goto out;
> +
> + genpd->suspended_count++;
> + genpd_sync_power_off(genpd, false, 0);
> +
> +out:
> + genpd_unlock(genpd);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pm_genpd_poweroff);
> +
>  #ifdef CONFIG_PM_GENERIC_DOMAINS_OF
>  
>  typedef struct generic_pm_domain *(*genpd_xlate_t)(struct of_phandle_args 
> *args,
> @@ -2171,7 +2285,6 @@ int of_genpd_parse_idle_states(struct device_node *dn,
>   return 0;
>  }
>  EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
> -
>  #endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
>  
>  
> @@ -2223,7 +2336,7 @@ static int pm_genpd_summary_one(struct seq_file *s,
>   const char *kobj_path;
>   struct gpd_link *link;
>   char state[16];
> - int ret;
> + int ret, count;
>  
>   ret = genpd_lock_interruptible(genpd);
>   if (ret)
> @@ -2250,6 +2363,8 @@ 

Re: [RFC PATCH 2/4] PM / Domains: Add support for explicit control of PM domains

[Rajendra Nayak]

Hey Jon,

On 03/28/2017 07:44 PM, Jon Hunter wrote:
> The current generic PM domain framework (GenDP) only allows a single
> PM domain to be associated with a given device. There are several
> use-cases for various system-on-chip devices where it is necessary for
> a PM domain consumer to control more than one PM domain where the PM
> domains:
> i).  Do not conform to a parent-child relationship so are not nested
> ii). May not be powered on and off at the same time so need independent
>  control.
> 
> To support the above, add new APIs for GenPD to allow consumers to get,
> power-on, power-off and put PM domains so that they can be explicitly
> controlled by the consumer.

thanks for working on this RFC.

[]..
  
> +/**
> + * pm_genpd_get - Get a generic I/O PM domain by name
> + * @name: Name of the PM domain.
> + *
> + * Look-ups a PM domain by name. If found, increment the device
> + * count for PM domain to ensure that the PM domain cannot be
> + * removed, increment the suspended count so that it can still
> + * be turned off (when not in-use) and return a pointer to its
> + * generic_pm_domain structure. If not found return ERR_PTR().
> + */
> +struct generic_pm_domain *pm_genpd_get(const char *name)
> +{
> + struct generic_pm_domain *gpd, *genpd = ERR_PTR(-EEXIST);
> +
> + if (!name)
> + return ERR_PTR(-EINVAL);
> +
> + mutex_lock(_list_lock);
> + list_for_each_entry(gpd, _list, gpd_list_node) {
> + if (!strcmp(gpd->name, name)) {
> + genpd_lock(gpd);
> + gpd->device_count++;

There apis' should also take a device pointer as a parameter,
so we can track all the devices belonging to a powerdomain.
That would also mean keeping the genpd->dev_list updated instead of
only incrementing the device_count here.

> + gpd->suspended_count++;
> + genpd_unlock(gpd);
> + genpd = gpd;
> + break;
> + }
> + }
> + mutex_unlock(_list_lock);
> +
> + return genpd;

Instead of returning a pointer to generic_pm_domain to all
consumers (who are then free to poke around it) we should hide
all internal structures handled by the framework and only expose
some kind of a handle to all the consumers.
That would also mean having a clear split of the headers to
distinguish between what's accessible to consumers vs providers.

regards
Rajendra

> +}
> +EXPORT_SYMBOL(pm_genpd_get);
> +
> +/**
> + * pm_genpd_put - Put a generic I/O PM domain
> + * @genpd: Pointer to a PM domain.
> + */
> +void pm_genpd_put(struct generic_pm_domain *genpd)
> +{
> + if (!genpd)
> + return;
> +
> + genpd_lock(genpd);
> +
> + if (WARN_ON(!genpd->device_count || !genpd->suspended_count))
> + goto out;
> +
> + genpd->suspended_count--;
> + genpd->device_count--;
> +
> +out:
> + genpd_unlock(genpd);
> +}
> +EXPORT_SYMBOL(pm_genpd_put);
> +
> +/**
> + * pm_genpd_poweron - Power on a generic I/O PM domain
> + * @genpd: Pointer to a PM domain.
> + *
> + * Powers on a PM domain, if not already on, and decrements the
> + * 'suspended_count' to prevent the PM domain from being powered off.
> + */
> +int pm_genpd_poweron(struct generic_pm_domain *genpd)
> +{
> + if (!genpd)
> + return -EINVAL;
> +
> + genpd_lock(genpd);
> +
> + if (WARN_ON(!genpd->suspended_count))
> + goto out;
> +
> + genpd->suspended_count--;
> + genpd_sync_power_on(genpd, true, 0);
> +
> +out:
> + genpd_unlock(genpd);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pm_genpd_poweron);
> +
> +/**
> + * pm_genpd_poweroff - Power off a generic I/O PM domain
> + * @genpd: Pointer to a PM domain.
> + *
> + * Increments the 'suspended_count' for a PM domain and if the
> + * 'suspended_count' equals the 'device_count' then will power
> + * off the PM domain.
> + */
> +int pm_genpd_poweroff(struct generic_pm_domain *genpd)
> +{
> + if (!genpd)
> + return -EINVAL;
> +
> + genpd_lock(genpd);
> +
> + if (WARN_ON(genpd->suspended_count >= genpd->device_count))
> + goto out;
> +
> + genpd->suspended_count++;
> + genpd_sync_power_off(genpd, false, 0);
> +
> +out:
> + genpd_unlock(genpd);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pm_genpd_poweroff);
> +
>  #ifdef CONFIG_PM_GENERIC_DOMAINS_OF
>  
>  typedef struct generic_pm_domain *(*genpd_xlate_t)(struct of_phandle_args 
> *args,
> @@ -2171,7 +2285,6 @@ int of_genpd_parse_idle_states(struct device_node *dn,
>   return 0;
>  }
>  EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
> -
>  #endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
>  
>  
> @@ -2223,7 +2336,7 @@ static int pm_genpd_summary_one(struct seq_file *s,
>   const char *kobj_path;
>   struct gpd_link *link;
>   char state[16];
> - int ret;
> + int ret, count;
>  
>   ret = genpd_lock_interruptible(genpd);
>   if (ret)
> @@ -2250,6 +2363,8 @@ 

[PATCH v3 2/2] drivers/serial: Add driver for Aspeed virtual UART

[Joel Stanley]

From: Jeremy Kerr 

This change adds a driver for the 16550-based Aspeed virtual UART
device. We use a similar process to the of_serial driver for device
probe, but expose some VUART-specific functions through sysfs too.

The VUART is two UART 'front ends' connected by their FIFO (no actual
serial line in between). One is on the BMC side (management controller)
and one is on the host CPU side.

This driver is for the BMC side. The sysfs files allow the BMC
userspace, which owns the system configuration policy, to specify at
what IO port and interrupt number the host side will appear to the host
on the Host <-> BMC LPC bus. It could be different on a different system
(though most of them use 3f8/4).

OpenPOWER host firmware doesn't like it when the host-side of the
VUART's FIFO is not drained. This driver only disables host TX discard
mode when the port is in use. We set the VUART enabled bit when we bind
to the device, and clear it on unbind.

We don't want to do this on open/release, as the host may be using this
bit to configure serial output modes, which is independent of whether
the devices has been opened by BMC userspace.

Signed-off-by: Jeremy Kerr 
Signed-off-by: Joel Stanley 
Acked-by: Rob Herring 

---
v3:
 - remove whitespace in header
 - reformat comment
 - don't check for reg-io-width property; we don't need any special
   accessors for reading/writing bytes
 - move file to 8250_aspeed_vuart.c

v2:
 - Use attribute groups and DEVICE_ATTR_RW
 - Use platform_get_resource/devm_ioremap_resource
 - of_find_property -> of_property_read_bool
 - Drop unncessary 0xff mask
 - Fix comment style
 - Use BIT and GENMASK where pssible
 - Move to 8250 directory
 - Rename ast -> aspeed to match other Aspeed drivers
 - Add documentation of sysfs file
 - Add detail to the commit message

 Documentation/ABI/stable/sysfs-driver-aspeed-vuart |  15 +
 Documentation/devicetree/bindings/serial/8250.txt  |   2 +
 drivers/tty/serial/8250/8250_aspeed_vuart.c| 323 +
 drivers/tty/serial/8250/Kconfig|  10 +
 drivers/tty/serial/8250/Makefile   |   1 +
 5 files changed, 351 insertions(+)
 create mode 100644 Documentation/ABI/stable/sysfs-driver-aspeed-vuart
 create mode 100644 drivers/tty/serial/8250/8250_aspeed_vuart.c

diff --git a/Documentation/ABI/stable/sysfs-driver-aspeed-vuart 
b/Documentation/ABI/stable/sysfs-driver-aspeed-vuart
new file mode 100644
index ..8062953ce77b
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-driver-aspeed-vuart
@@ -0,0 +1,15 @@
+What:  /sys/bus/platform/drivers/aspeed-vuart/*/lpc_address
+Date:  April 2017
+Contact:   Jeremy Kerr 
+Description:   Configures which IO port the host side of the UART
+   will appear on the host <-> BMC LPC bus.
+Users: OpenBMC.  Proposed changes should be mailed to
+   open...@lists.ozlabs.org
+
+What:  /sys/bus/platform/drivers/aspeed-vuart*/sirq
+Date:  April 2017
+Contact:   Jeremy Kerr 
+Description:   Configures which interrupt number the host side of
+   the UART will appear on the host <-> BMC LPC bus.
+Users: OpenBMC.  Proposed changes should be mailed to
+   open...@lists.ozlabs.org
diff --git a/Documentation/devicetree/bindings/serial/8250.txt 
b/Documentation/devicetree/bindings/serial/8250.txt
index 10276a46ecef..656733949309 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -20,6 +20,8 @@ Required properties:
- "fsl,16550-FIFO64"
- "fsl,ns16550"
- "ti,da830-uart"
+   - "aspeed,ast2400-vuart"
+   - "aspeed,ast2500-vuart"
- "serial" if the port type is unknown.
 - reg : offset and length of the register set for the device.
 - interrupts : should contain uart interrupt.
diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c 
b/drivers/tty/serial/8250/8250_aspeed_vuart.c
new file mode 100644
index ..5db0023e0225
--- /dev/null
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -0,0 +1,323 @@
+/*
+ *  Serial Port driver for Aspeed VUART device
+ *
+ *Copyright (C) 2016 Jeremy Kerr , IBM Corp.
+ *Copyright (C) 2006 Arnd Bergmann , IBM Corp.
+ *
+ *  This program is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU General Public License
+ *  as published by the Free Software Foundation; either version
+ *  2 of the License, or (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "8250.h"
+
+#define ASPEED_VUART_GCRA  0x20
+#define ASPEED_VUART_GCRA_VUART_EN BIT(0)
+#define ASPEED_VUART_GCRA_DISABLE_HOST_TX_DISCARD BIT(5)
+#define ASPEED_VUART_GCRB  0x24
+#define 

[PATCH v3 2/2] drivers/serial: Add driver for Aspeed virtual UART

[Joel Stanley]

From: Jeremy Kerr 

This change adds a driver for the 16550-based Aspeed virtual UART
device. We use a similar process to the of_serial driver for device
probe, but expose some VUART-specific functions through sysfs too.

The VUART is two UART 'front ends' connected by their FIFO (no actual
serial line in between). One is on the BMC side (management controller)
and one is on the host CPU side.

This driver is for the BMC side. The sysfs files allow the BMC
userspace, which owns the system configuration policy, to specify at
what IO port and interrupt number the host side will appear to the host
on the Host <-> BMC LPC bus. It could be different on a different system
(though most of them use 3f8/4).

OpenPOWER host firmware doesn't like it when the host-side of the
VUART's FIFO is not drained. This driver only disables host TX discard
mode when the port is in use. We set the VUART enabled bit when we bind
to the device, and clear it on unbind.

We don't want to do this on open/release, as the host may be using this
bit to configure serial output modes, which is independent of whether
the devices has been opened by BMC userspace.

Signed-off-by: Jeremy Kerr 
Signed-off-by: Joel Stanley 
Acked-by: Rob Herring 

---
v3:
 - remove whitespace in header
 - reformat comment
 - don't check for reg-io-width property; we don't need any special
   accessors for reading/writing bytes
 - move file to 8250_aspeed_vuart.c

v2:
 - Use attribute groups and DEVICE_ATTR_RW
 - Use platform_get_resource/devm_ioremap_resource
 - of_find_property -> of_property_read_bool
 - Drop unncessary 0xff mask
 - Fix comment style
 - Use BIT and GENMASK where pssible
 - Move to 8250 directory
 - Rename ast -> aspeed to match other Aspeed drivers
 - Add documentation of sysfs file
 - Add detail to the commit message

 Documentation/ABI/stable/sysfs-driver-aspeed-vuart |  15 +
 Documentation/devicetree/bindings/serial/8250.txt  |   2 +
 drivers/tty/serial/8250/8250_aspeed_vuart.c| 323 +
 drivers/tty/serial/8250/Kconfig|  10 +
 drivers/tty/serial/8250/Makefile   |   1 +
 5 files changed, 351 insertions(+)
 create mode 100644 Documentation/ABI/stable/sysfs-driver-aspeed-vuart
 create mode 100644 drivers/tty/serial/8250/8250_aspeed_vuart.c

diff --git a/Documentation/ABI/stable/sysfs-driver-aspeed-vuart 
b/Documentation/ABI/stable/sysfs-driver-aspeed-vuart
new file mode 100644
index ..8062953ce77b
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-driver-aspeed-vuart
@@ -0,0 +1,15 @@
+What:  /sys/bus/platform/drivers/aspeed-vuart/*/lpc_address
+Date:  April 2017
+Contact:   Jeremy Kerr 
+Description:   Configures which IO port the host side of the UART
+   will appear on the host <-> BMC LPC bus.
+Users: OpenBMC.  Proposed changes should be mailed to
+   open...@lists.ozlabs.org
+
+What:  /sys/bus/platform/drivers/aspeed-vuart*/sirq
+Date:  April 2017
+Contact:   Jeremy Kerr 
+Description:   Configures which interrupt number the host side of
+   the UART will appear on the host <-> BMC LPC bus.
+Users: OpenBMC.  Proposed changes should be mailed to
+   open...@lists.ozlabs.org
diff --git a/Documentation/devicetree/bindings/serial/8250.txt 
b/Documentation/devicetree/bindings/serial/8250.txt
index 10276a46ecef..656733949309 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -20,6 +20,8 @@ Required properties:
- "fsl,16550-FIFO64"
- "fsl,ns16550"
- "ti,da830-uart"
+   - "aspeed,ast2400-vuart"
+   - "aspeed,ast2500-vuart"
- "serial" if the port type is unknown.
 - reg : offset and length of the register set for the device.
 - interrupts : should contain uart interrupt.
diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c 
b/drivers/tty/serial/8250/8250_aspeed_vuart.c
new file mode 100644
index ..5db0023e0225
--- /dev/null
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -0,0 +1,323 @@
+/*
+ *  Serial Port driver for Aspeed VUART device
+ *
+ *Copyright (C) 2016 Jeremy Kerr , IBM Corp.
+ *Copyright (C) 2006 Arnd Bergmann , IBM Corp.
+ *
+ *  This program is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU General Public License
+ *  as published by the Free Software Foundation; either version
+ *  2 of the License, or (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "8250.h"
+
+#define ASPEED_VUART_GCRA  0x20
+#define ASPEED_VUART_GCRA_VUART_EN BIT(0)
+#define ASPEED_VUART_GCRA_DISABLE_HOST_TX_DISCARD BIT(5)
+#define ASPEED_VUART_GCRB  0x24
+#define ASPEED_VUART_GCRB_HOST_SIRQ_MASK   GENMASK(7, 4)
+#define ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT  4
+#define ASPEED_VUART_ADDRL 

[PATCH v3 0/2] drivers: serial: Aspeed VUART driver

[Joel Stanley]

This is v3 of a driver for the Aspeed VUART. This version addresses feedback
from Andy and Greg, and includes Rob's ack for the bindings change.

The VUART is a serial device on the BMC side of the LPC bus that connects a BMC
to it's host processor.

We add a flag to the serial core to allow the driver to skip probing of the
THRE irq behaviour, which could hang due to the host not reading bytes out of
the buffer.

We've been using this on systems for over a year, so it has seen a good amount
of testing.

Cheers,

Joel

Jeremy Kerr (1):
  drivers/serial: Add driver for Aspeed virtual UART

Joel Stanley (1):
  serial: 8250: Add flag so drivers can avoid THRE probe

 Documentation/ABI/stable/sysfs-driver-aspeed-vuart |  15 +
 Documentation/devicetree/bindings/serial/8250.txt  |   2 +
 drivers/tty/serial/8250/8250_aspeed_vuart.c| 323 +
 drivers/tty/serial/8250/8250_port.c|   2 +-
 drivers/tty/serial/8250/Kconfig|  10 +
 drivers/tty/serial/8250/Makefile   |   1 +
 include/linux/serial_core.h|   1 +
 7 files changed, 353 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/stable/sysfs-driver-aspeed-vuart
 create mode 100644 drivers/tty/serial/8250/8250_aspeed_vuart.c

-- 
2.11.0

[PATCH v3 0/2] drivers: serial: Aspeed VUART driver

[Joel Stanley]

This is v3 of a driver for the Aspeed VUART. This version addresses feedback
from Andy and Greg, and includes Rob's ack for the bindings change.

The VUART is a serial device on the BMC side of the LPC bus that connects a BMC
to it's host processor.

We add a flag to the serial core to allow the driver to skip probing of the
THRE irq behaviour, which could hang due to the host not reading bytes out of
the buffer.

We've been using this on systems for over a year, so it has seen a good amount
of testing.

Cheers,

Joel

Jeremy Kerr (1):
  drivers/serial: Add driver for Aspeed virtual UART

Joel Stanley (1):
  serial: 8250: Add flag so drivers can avoid THRE probe

 Documentation/ABI/stable/sysfs-driver-aspeed-vuart |  15 +
 Documentation/devicetree/bindings/serial/8250.txt  |   2 +
 drivers/tty/serial/8250/8250_aspeed_vuart.c| 323 +
 drivers/tty/serial/8250/8250_port.c|   2 +-
 drivers/tty/serial/8250/Kconfig|  10 +
 drivers/tty/serial/8250/Makefile   |   1 +
 include/linux/serial_core.h|   1 +
 7 files changed, 353 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/stable/sysfs-driver-aspeed-vuart
 create mode 100644 drivers/tty/serial/8250/8250_aspeed_vuart.c

-- 
2.11.0

[PATCH v3 1/2] serial: 8250: Add flag so drivers can avoid THRE probe

[Joel Stanley]

The probing of THRE irq behaviour assumes the other end will be reading
bytes out of the buffer in order to probe the port at driver init. In
some cases the other end cannot be relied upon to read these bytes, so
provide a flag for them to skip this step.

Bit 19 was chosen as the flags are a int and the top bits are taken.

Acked-by: Benjamin Herrenschmidt 
Signed-off-by: Joel Stanley 

---
v3:
 - Correct the bit number in the changelog

v2:
 - No change

 drivers/tty/serial/8250/8250_port.c | 2 +-
 include/linux/serial_core.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_port.c 
b/drivers/tty/serial/8250/8250_port.c
index 6119516ef5fc..60a6c247340f 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2229,7 +2229,7 @@ int serial8250_do_startup(struct uart_port *port)
}
}
 
-   if (port->irq) {
+   if (port->irq && !(up->port.flags & UPF_NO_THRE_TEST)) {
unsigned char iir1;
/*
 * Test for UARTs that do not reassert THRE when the
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 58484fb35cc8..260245deec94 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -195,6 +195,7 @@ struct uart_port {
 #define UPF_NO_TXEN_TEST   ((__force upf_t) (1 << 15))
 #define UPF_MAGIC_MULTIPLIER   ((__force upf_t) ASYNC_MAGIC_MULTIPLIER /* 16 
*/ )
 
+#define UPF_NO_THRE_TEST   ((__force upf_t) (1 << 19))
 /* Port has hardware-assisted h/w flow control */
 #define UPF_AUTO_CTS   ((__force upf_t) (1 << 20))
 #define UPF_AUTO_RTS   ((__force upf_t) (1 << 21))
-- 
2.11.0

[PATCH v3 1/2] serial: 8250: Add flag so drivers can avoid THRE probe

[Joel Stanley]

The probing of THRE irq behaviour assumes the other end will be reading
bytes out of the buffer in order to probe the port at driver init. In
some cases the other end cannot be relied upon to read these bytes, so
provide a flag for them to skip this step.

Bit 19 was chosen as the flags are a int and the top bits are taken.

Acked-by: Benjamin Herrenschmidt 
Signed-off-by: Joel Stanley 

---
v3:
 - Correct the bit number in the changelog

v2:
 - No change

 drivers/tty/serial/8250/8250_port.c | 2 +-
 include/linux/serial_core.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_port.c 
b/drivers/tty/serial/8250/8250_port.c
index 6119516ef5fc..60a6c247340f 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2229,7 +2229,7 @@ int serial8250_do_startup(struct uart_port *port)
}
}
 
-   if (port->irq) {
+   if (port->irq && !(up->port.flags & UPF_NO_THRE_TEST)) {
unsigned char iir1;
/*
 * Test for UARTs that do not reassert THRE when the
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 58484fb35cc8..260245deec94 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -195,6 +195,7 @@ struct uart_port {
 #define UPF_NO_TXEN_TEST   ((__force upf_t) (1 << 15))
 #define UPF_MAGIC_MULTIPLIER   ((__force upf_t) ASYNC_MAGIC_MULTIPLIER /* 16 
*/ )
 
+#define UPF_NO_THRE_TEST   ((__force upf_t) (1 << 19))
 /* Port has hardware-assisted h/w flow control */
 #define UPF_AUTO_CTS   ((__force upf_t) (1 << 20))
 #define UPF_AUTO_RTS   ((__force upf_t) (1 << 21))
-- 
2.11.0

linux-next: manual merge of the kvm-arm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm-arm tree got conflicts in:

  virt/kvm/arm/vgic/vgic-v2.c
  virt/kvm/arm/vgic/vgic.h

between commit:

  5b0d2cc28058 ("KVM: arm64: Ensure LRs are clear when they should be")

from Linus' tree and commits:

  328e56647944 ("KVM: arm/arm64: vgic: Defer touching GICH_VMCR to 
vcpu_load/put")
  af0614991ab6 ("KVM: arm/arm64: vgic: Get rid of unnecessary 
process_maintenance operation")

from the kvm-arm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc virt/kvm/arm/vgic/vgic-v2.c
index b637d9c7afe3,025b57d5787e..
--- a/virt/kvm/arm/vgic/vgic-v2.c
+++ b/virt/kvm/arm/vgic/vgic-v2.c
@@@ -22,36 -22,7 +22,22 @@@
  
  #include "vgic.h"
  
- /*
-  * Call this function to convert a u64 value to an unsigned long * bitmask
-  * in a way that works on both 32-bit and 64-bit LE and BE platforms.
-  *
-  * Warning: Calling this function may modify *val.
-  */
- static unsigned long *u64_to_bitmask(u64 *val)
- {
- #if defined(CONFIG_CPU_BIG_ENDIAN) && BITS_PER_LONG == 32
-   *val = (*val >> 32) | (*val << 32);
- #endif
-   return (unsigned long *)val;
- }
- 
 +static inline void vgic_v2_write_lr(int lr, u32 val)
 +{
 +  void __iomem *base = kvm_vgic_global_state.vctrl_base;
 +
 +  writel_relaxed(val, base + GICH_LR0 + (lr * 4));
 +}
 +
 +void vgic_v2_init_lrs(void)
 +{
 +  int i;
 +
 +  for (i = 0; i < kvm_vgic_global_state.nr_lr; i++)
 +  vgic_v2_write_lr(i, 0);
 +}
 +
- void vgic_v2_process_maintenance(struct kvm_vcpu *vcpu)
+ void vgic_v2_set_underflow(struct kvm_vcpu *vcpu)
  {
struct vgic_v2_cpu_if *cpuif = >arch.vgic_cpu.vgic_v2;
  
@@@ -206,10 -160,10 +175,10 @@@ void vgic_v2_set_vmcr(struct kvm_vcpu *
GICH_VMCR_ALIAS_BINPOINT_MASK;
vmcr |= (vmcrp->bpr << GICH_VMCR_BINPOINT_SHIFT) &
GICH_VMCR_BINPOINT_MASK;
 -  vmcr |= (vmcrp->pmr << GICH_VMCR_PRIMASK_SHIFT) &
 -  GICH_VMCR_PRIMASK_MASK;
 +  vmcr |= ((vmcrp->pmr >> GICV_PMR_PRIORITY_SHIFT) <<
 +   GICH_VMCR_PRIMASK_SHIFT) & GICH_VMCR_PRIMASK_MASK;
  
-   vcpu->arch.vgic_cpu.vgic_v2.vgic_vmcr = vmcr;
+   cpu_if->vgic_vmcr = vmcr;
  }
  
  void vgic_v2_get_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcrp)
diff --cc virt/kvm/arm/vgic/vgic.h
index 6cf557e9f718,5dac0835..
--- a/virt/kvm/arm/vgic/vgic.h
+++ b/virt/kvm/arm/vgic/vgic.h
@@@ -137,7 -129,8 +136,9 @@@ int vgic_v2_map_resources(struct kvm *k
  int vgic_register_dist_iodev(struct kvm *kvm, gpa_t dist_base_address,
 enum vgic_type);
  
 +void vgic_v2_init_lrs(void);
+ void vgic_v2_load(struct kvm_vcpu *vcpu);
+ void vgic_v2_put(struct kvm_vcpu *vcpu);
  
  static inline void vgic_get_irq_kref(struct vgic_irq *irq)
  {

linux-next: manual merge of the kvm-arm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm-arm tree got conflicts in:

  virt/kvm/arm/vgic/vgic-v2.c
  virt/kvm/arm/vgic/vgic.h

between commit:

  5b0d2cc28058 ("KVM: arm64: Ensure LRs are clear when they should be")

from Linus' tree and commits:

  328e56647944 ("KVM: arm/arm64: vgic: Defer touching GICH_VMCR to 
vcpu_load/put")
  af0614991ab6 ("KVM: arm/arm64: vgic: Get rid of unnecessary 
process_maintenance operation")

from the kvm-arm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc virt/kvm/arm/vgic/vgic-v2.c
index b637d9c7afe3,025b57d5787e..
--- a/virt/kvm/arm/vgic/vgic-v2.c
+++ b/virt/kvm/arm/vgic/vgic-v2.c
@@@ -22,36 -22,7 +22,22 @@@
  
  #include "vgic.h"
  
- /*
-  * Call this function to convert a u64 value to an unsigned long * bitmask
-  * in a way that works on both 32-bit and 64-bit LE and BE platforms.
-  *
-  * Warning: Calling this function may modify *val.
-  */
- static unsigned long *u64_to_bitmask(u64 *val)
- {
- #if defined(CONFIG_CPU_BIG_ENDIAN) && BITS_PER_LONG == 32
-   *val = (*val >> 32) | (*val << 32);
- #endif
-   return (unsigned long *)val;
- }
- 
 +static inline void vgic_v2_write_lr(int lr, u32 val)
 +{
 +  void __iomem *base = kvm_vgic_global_state.vctrl_base;
 +
 +  writel_relaxed(val, base + GICH_LR0 + (lr * 4));
 +}
 +
 +void vgic_v2_init_lrs(void)
 +{
 +  int i;
 +
 +  for (i = 0; i < kvm_vgic_global_state.nr_lr; i++)
 +  vgic_v2_write_lr(i, 0);
 +}
 +
- void vgic_v2_process_maintenance(struct kvm_vcpu *vcpu)
+ void vgic_v2_set_underflow(struct kvm_vcpu *vcpu)
  {
struct vgic_v2_cpu_if *cpuif = >arch.vgic_cpu.vgic_v2;
  
@@@ -206,10 -160,10 +175,10 @@@ void vgic_v2_set_vmcr(struct kvm_vcpu *
GICH_VMCR_ALIAS_BINPOINT_MASK;
vmcr |= (vmcrp->bpr << GICH_VMCR_BINPOINT_SHIFT) &
GICH_VMCR_BINPOINT_MASK;
 -  vmcr |= (vmcrp->pmr << GICH_VMCR_PRIMASK_SHIFT) &
 -  GICH_VMCR_PRIMASK_MASK;
 +  vmcr |= ((vmcrp->pmr >> GICV_PMR_PRIORITY_SHIFT) <<
 +   GICH_VMCR_PRIMASK_SHIFT) & GICH_VMCR_PRIMASK_MASK;
  
-   vcpu->arch.vgic_cpu.vgic_v2.vgic_vmcr = vmcr;
+   cpu_if->vgic_vmcr = vmcr;
  }
  
  void vgic_v2_get_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcrp)
diff --cc virt/kvm/arm/vgic/vgic.h
index 6cf557e9f718,5dac0835..
--- a/virt/kvm/arm/vgic/vgic.h
+++ b/virt/kvm/arm/vgic/vgic.h
@@@ -137,7 -129,8 +136,9 @@@ int vgic_v2_map_resources(struct kvm *k
  int vgic_register_dist_iodev(struct kvm *kvm, gpa_t dist_base_address,
 enum vgic_type);
  
 +void vgic_v2_init_lrs(void);
+ void vgic_v2_load(struct kvm_vcpu *vcpu);
+ void vgic_v2_put(struct kvm_vcpu *vcpu);
  
  static inline void vgic_get_irq_kref(struct vgic_irq *irq)
  {

[PATCH v3 1/2] serial: 8250: Add flag so drivers can avoid THRE probe

[Joel Stanley]

The probing of THRE irq behaviour assumes the other end will be reading
bytes out of the buffer in order to probe the port at driver init. In
some cases the other end cannot be relied upon to read these bytes, so
provide a flag for them to skip this step.

Bit 19 was chosen as the flags are a int and the top bits are taken.

Acked-by: Benjamin Herrenschmidt 
Signed-off-by: Joel Stanley 

---
v3:
 - Correct the bit number in the changelog

v2:
 - No change

 drivers/tty/serial/8250/8250_port.c | 2 +-
 include/linux/serial_core.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_port.c 
b/drivers/tty/serial/8250/8250_port.c
index 6119516ef5fc..60a6c247340f 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2229,7 +2229,7 @@ int serial8250_do_startup(struct uart_port *port)
}
}
 
-   if (port->irq) {
+   if (port->irq && !(up->port.flags & UPF_NO_THRE_TEST)) {
unsigned char iir1;
/*
 * Test for UARTs that do not reassert THRE when the
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 58484fb35cc8..260245deec94 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -195,6 +195,7 @@ struct uart_port {
 #define UPF_NO_TXEN_TEST   ((__force upf_t) (1 << 15))
 #define UPF_MAGIC_MULTIPLIER   ((__force upf_t) ASYNC_MAGIC_MULTIPLIER /* 16 
*/ )
 
+#define UPF_NO_THRE_TEST   ((__force upf_t) (1 << 19))
 /* Port has hardware-assisted h/w flow control */
 #define UPF_AUTO_CTS   ((__force upf_t) (1 << 20))
 #define UPF_AUTO_RTS   ((__force upf_t) (1 << 21))
-- 
2.11.0

[PATCH v3 1/2] serial: 8250: Add flag so drivers can avoid THRE probe

[Joel Stanley]

The probing of THRE irq behaviour assumes the other end will be reading
bytes out of the buffer in order to probe the port at driver init. In
some cases the other end cannot be relied upon to read these bytes, so
provide a flag for them to skip this step.

Bit 19 was chosen as the flags are a int and the top bits are taken.

Acked-by: Benjamin Herrenschmidt 
Signed-off-by: Joel Stanley 

---
v3:
 - Correct the bit number in the changelog

v2:
 - No change

 drivers/tty/serial/8250/8250_port.c | 2 +-
 include/linux/serial_core.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_port.c 
b/drivers/tty/serial/8250/8250_port.c
index 6119516ef5fc..60a6c247340f 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2229,7 +2229,7 @@ int serial8250_do_startup(struct uart_port *port)
}
}
 
-   if (port->irq) {
+   if (port->irq && !(up->port.flags & UPF_NO_THRE_TEST)) {
unsigned char iir1;
/*
 * Test for UARTs that do not reassert THRE when the
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 58484fb35cc8..260245deec94 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -195,6 +195,7 @@ struct uart_port {
 #define UPF_NO_TXEN_TEST   ((__force upf_t) (1 << 15))
 #define UPF_MAGIC_MULTIPLIER   ((__force upf_t) ASYNC_MAGIC_MULTIPLIER /* 16 
*/ )
 
+#define UPF_NO_THRE_TEST   ((__force upf_t) (1 << 19))
 /* Port has hardware-assisted h/w flow control */
 #define UPF_AUTO_CTS   ((__force upf_t) (1 << 20))
 #define UPF_AUTO_RTS   ((__force upf_t) (1 << 21))
-- 
2.11.0

[PATCH v3 0/2] drivers: serial: Aspeed VUART driver

[Joel Stanley]

This is v3 of a driver for the Aspeed VUART. This version addresses feedback
from Andy and Greg, and includes Rob's ack for the bindings change.

The VUART is a serial device on the BMC side of the LPC bus that connects a BMC
to it's host processor.

We add a flag to the serial core to allow the driver to skip probing of the
THRE irq behaviour, which could hang due to the host not reading bytes out of
the buffer.

We've been using this on systems for over a year, so it has seen a good amount
of testing.

Cheers,

Joel

Jeremy Kerr (1):
  drivers/serial: Add driver for Aspeed virtual UART

Joel Stanley (1):
  serial: 8250: Add flag so drivers can avoid THRE probe

 Documentation/ABI/stable/sysfs-driver-aspeed-vuart |  15 +
 Documentation/devicetree/bindings/serial/8250.txt  |   2 +
 drivers/tty/serial/8250/8250_aspeed_vuart.c| 323 +
 drivers/tty/serial/8250/8250_port.c|   2 +-
 drivers/tty/serial/8250/Kconfig|  10 +
 drivers/tty/serial/8250/Makefile   |   1 +
 include/linux/serial_core.h|   1 +
 7 files changed, 353 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/stable/sysfs-driver-aspeed-vuart
 create mode 100644 drivers/tty/serial/8250/8250_aspeed_vuart.c

-- 
2.11.0

[PATCH v3 0/2] drivers: serial: Aspeed VUART driver

[Joel Stanley]

This is v3 of a driver for the Aspeed VUART. This version addresses feedback
from Andy and Greg, and includes Rob's ack for the bindings change.

The VUART is a serial device on the BMC side of the LPC bus that connects a BMC
to it's host processor.

We add a flag to the serial core to allow the driver to skip probing of the
THRE irq behaviour, which could hang due to the host not reading bytes out of
the buffer.

We've been using this on systems for over a year, so it has seen a good amount
of testing.

Cheers,

Joel

Jeremy Kerr (1):
  drivers/serial: Add driver for Aspeed virtual UART

Joel Stanley (1):
  serial: 8250: Add flag so drivers can avoid THRE probe

 Documentation/ABI/stable/sysfs-driver-aspeed-vuart |  15 +
 Documentation/devicetree/bindings/serial/8250.txt  |   2 +
 drivers/tty/serial/8250/8250_aspeed_vuart.c| 323 +
 drivers/tty/serial/8250/8250_port.c|   2 +-
 drivers/tty/serial/8250/Kconfig|  10 +
 drivers/tty/serial/8250/Makefile   |   1 +
 include/linux/serial_core.h|   1 +
 7 files changed, 353 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/stable/sysfs-driver-aspeed-vuart
 create mode 100644 drivers/tty/serial/8250/8250_aspeed_vuart.c

-- 
2.11.0

linux-next: manual merge of the kvm-arm tree with the kvm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm-arm tree got conflicts in:

  Documentation/virtual/kvm/api.txt
  include/uapi/linux/kvm.h

between commits:

  a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities")
  578fd61d2d21 ("KVM: MIPS: Add 64BIT capability")

from the kvm tree and commit:

  3fe17e682616 ("KVM: arm/arm64: Add ARM user space interrupt signaling ABI")

from the kvm-arm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/virtual/kvm/api.txt
index 1a184843bf9c,3b4e76e5201e..
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@@ -4030,67 -4148,44 +4030,108 @@@ available, means that that the kernel c
  hashed page table MMU defined in Power ISA V3.00 (as implemented in
  the POWER9 processor), including in-memory segment tables.
  
 +8.5 KVM_CAP_MIPS_VZ
 +
 +Architectures: mips
 +
 +This capability, if KVM_CHECK_EXTENSION on the main kvm handle indicates that
 +it is available, means that full hardware assisted virtualization capabilities
 +of the hardware are available for use through KVM. An appropriate
 +KVM_VM_MIPS_* type must be passed to KVM_CREATE_VM to create a VM which
 +utilises it.
 +
 +If KVM_CHECK_EXTENSION on a kvm VM handle indicates that this capability is
 +available, it means that the VM is using full hardware assisted virtualization
 +capabilities of the hardware. This is useful to check after creating a VM with
 +KVM_VM_MIPS_DEFAULT.
 +
 +The value returned by KVM_CHECK_EXTENSION should be compared against known
 +values (see below). All other values are reserved. This is to allow for the
 +possibility of other hardware assisted virtualization implementations which
 +may be incompatible with the MIPS VZ ASE.
 +
 + 0: The trap & emulate implementation is in use to run guest code in user
 +mode. Guest virtual memory segments are rearranged to fit the guest in the
 +user mode address space.
 +
 + 1: The MIPS VZ ASE is in use, providing full hardware assisted
 +virtualization, including standard guest virtual memory segments.
 +
 +8.6 KVM_CAP_MIPS_TE
 +
 +Architectures: mips
 +
 +This capability, if KVM_CHECK_EXTENSION on the main kvm handle indicates that
 +it is available, means that the trap & emulate implementation is available to
 +run guest code in user mode, even if KVM_CAP_MIPS_VZ indicates that hardware
 +assisted virtualisation is also available. KVM_VM_MIPS_TE (0) must be passed
 +to KVM_CREATE_VM to create a VM which utilises it.
 +
 +If KVM_CHECK_EXTENSION on a kvm VM handle indicates that this capability is
 +available, it means that the VM is using trap & emulate.
 +
 +8.7 KVM_CAP_MIPS_64BIT
 +
 +Architectures: mips
 +
 +This capability indicates the supported architecture type of the guest, i.e. 
the
 +supported register and address width.
 +
 +The values returned when this capability is checked by KVM_CHECK_EXTENSION on 
a
 +kvm VM handle correspond roughly to the CP0_Config.AT register field, and 
should
 +be checked specifically against known values (see below). All other values are
 +reserved.
 +
 + 0: MIPS32 or microMIPS32.
 +Both registers and addresses are 32-bits wide.
 +It will only be possible to run 32-bit guest code.
 +
 + 1: MIPS64 or microMIPS64 with access only to 32-bit compatibility segments.
 +Registers are 64-bits wide, but addresses are 32-bits wide.
 +64-bit guest code may run but cannot access MIPS64 memory segments.
 +It will also be possible to run 32-bit guest code.
 +
 + 2: MIPS64 or microMIPS64 with access to all address segments.
 +Both registers and addresses are 64-bits wide.
 +It will be possible to run 64-bit or 32-bit guest code.
+ 
 -8.5 KVM_CAP_ARM_USER_IRQ
++8.8 KVM_CAP_ARM_USER_IRQ
+ 
+ Architectures: arm, arm64
+ This capability, if KVM_CHECK_EXTENSION indicates that it is available, means
+ that if userspace creates a VM without an in-kernel interrupt controller, it
+ will be notified of changes to the output level of in-kernel emulated devices,
+ which can generate virtual interrupts, presented to the VM.
+ For such VMs, on every return to userspace, the kernel
+ updates the vcpu's run->s.regs.device_irq_level field to represent the actual
+ output level of the device.
+ 
+ Whenever kvm detects a change in the device output level, kvm guarantees at
+ least one return to userspace before running the VM.  This exit could either
+ be a KVM_EXIT_INTR or any other exit event, like KVM_EXIT_MMIO. This way,
+ userspace can always sample the device output level and re-compute the state 
of
+ the userspace interrupt controller.  Userspace should always check the state
+ of 

linux-next: manual merge of the kvm-arm tree with the kvm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm-arm tree got conflicts in:

  Documentation/virtual/kvm/api.txt
  include/uapi/linux/kvm.h

between commits:

  a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities")
  578fd61d2d21 ("KVM: MIPS: Add 64BIT capability")

from the kvm tree and commit:

  3fe17e682616 ("KVM: arm/arm64: Add ARM user space interrupt signaling ABI")

from the kvm-arm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/virtual/kvm/api.txt
index 1a184843bf9c,3b4e76e5201e..
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@@ -4030,67 -4148,44 +4030,108 @@@ available, means that that the kernel c
  hashed page table MMU defined in Power ISA V3.00 (as implemented in
  the POWER9 processor), including in-memory segment tables.
  
 +8.5 KVM_CAP_MIPS_VZ
 +
 +Architectures: mips
 +
 +This capability, if KVM_CHECK_EXTENSION on the main kvm handle indicates that
 +it is available, means that full hardware assisted virtualization capabilities
 +of the hardware are available for use through KVM. An appropriate
 +KVM_VM_MIPS_* type must be passed to KVM_CREATE_VM to create a VM which
 +utilises it.
 +
 +If KVM_CHECK_EXTENSION on a kvm VM handle indicates that this capability is
 +available, it means that the VM is using full hardware assisted virtualization
 +capabilities of the hardware. This is useful to check after creating a VM with
 +KVM_VM_MIPS_DEFAULT.
 +
 +The value returned by KVM_CHECK_EXTENSION should be compared against known
 +values (see below). All other values are reserved. This is to allow for the
 +possibility of other hardware assisted virtualization implementations which
 +may be incompatible with the MIPS VZ ASE.
 +
 + 0: The trap & emulate implementation is in use to run guest code in user
 +mode. Guest virtual memory segments are rearranged to fit the guest in the
 +user mode address space.
 +
 + 1: The MIPS VZ ASE is in use, providing full hardware assisted
 +virtualization, including standard guest virtual memory segments.
 +
 +8.6 KVM_CAP_MIPS_TE
 +
 +Architectures: mips
 +
 +This capability, if KVM_CHECK_EXTENSION on the main kvm handle indicates that
 +it is available, means that the trap & emulate implementation is available to
 +run guest code in user mode, even if KVM_CAP_MIPS_VZ indicates that hardware
 +assisted virtualisation is also available. KVM_VM_MIPS_TE (0) must be passed
 +to KVM_CREATE_VM to create a VM which utilises it.
 +
 +If KVM_CHECK_EXTENSION on a kvm VM handle indicates that this capability is
 +available, it means that the VM is using trap & emulate.
 +
 +8.7 KVM_CAP_MIPS_64BIT
 +
 +Architectures: mips
 +
 +This capability indicates the supported architecture type of the guest, i.e. 
the
 +supported register and address width.
 +
 +The values returned when this capability is checked by KVM_CHECK_EXTENSION on 
a
 +kvm VM handle correspond roughly to the CP0_Config.AT register field, and 
should
 +be checked specifically against known values (see below). All other values are
 +reserved.
 +
 + 0: MIPS32 or microMIPS32.
 +Both registers and addresses are 32-bits wide.
 +It will only be possible to run 32-bit guest code.
 +
 + 1: MIPS64 or microMIPS64 with access only to 32-bit compatibility segments.
 +Registers are 64-bits wide, but addresses are 32-bits wide.
 +64-bit guest code may run but cannot access MIPS64 memory segments.
 +It will also be possible to run 32-bit guest code.
 +
 + 2: MIPS64 or microMIPS64 with access to all address segments.
 +Both registers and addresses are 64-bits wide.
 +It will be possible to run 64-bit or 32-bit guest code.
+ 
 -8.5 KVM_CAP_ARM_USER_IRQ
++8.8 KVM_CAP_ARM_USER_IRQ
+ 
+ Architectures: arm, arm64
+ This capability, if KVM_CHECK_EXTENSION indicates that it is available, means
+ that if userspace creates a VM without an in-kernel interrupt controller, it
+ will be notified of changes to the output level of in-kernel emulated devices,
+ which can generate virtual interrupts, presented to the VM.
+ For such VMs, on every return to userspace, the kernel
+ updates the vcpu's run->s.regs.device_irq_level field to represent the actual
+ output level of the device.
+ 
+ Whenever kvm detects a change in the device output level, kvm guarantees at
+ least one return to userspace before running the VM.  This exit could either
+ be a KVM_EXIT_INTR or any other exit event, like KVM_EXIT_MMIO. This way,
+ userspace can always sample the device output level and re-compute the state 
of
+ the userspace interrupt controller.  Userspace should always check the state
+ of 

[PATCH v3] arm64: dts: rk3399: add support for firefly-rk3399 board

[Kever Yang]

Firefly-rk3399 is a bord from T-Firefly, you can find detail about
it here:
http://en.t-firefly.com/en/firenow/Firefly_RK3399/

This patch add basic node for the board and make it able to bring
up.

Peripheral works:
- usb hub which connect to ehci controller;
- UART2 debug
- eMMC
- PCIe

Not work:
- USB 3.0 HOST, type-C port
- sdio, sd-card

Not test for other peripheral:
- HDMI
- Ethernet
- OPTICAL
- WiFi/BT
- MIPI CSI/DSI
- IR
- EDP/DP

Signed-off-by: Kever Yang 
---

Changes in v3:
- remove not upstream defined properties;
- remove fusb302 and gsl3673 node

Changes in v2:
- rebase on Heiko's for-next
- using pinctrl binding header definition instead of a number
- other fix by comments from Heiko and Andreas.

 arch/arm64/boot/dts/rockchip/Makefile   |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 714 
 2 files changed, 715 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index b5636bb..bcfa53b 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -5,6 +5,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-orion-r68-meta.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-firefly.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-kevin.dtb
 
 always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
new file mode 100644
index 000..2517219
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -0,0 +1,714 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   model = "Firefly-RK3399 Board";
+   compatible = "firefly,firefly-rk3399", "rockchip,rk3399";
+
+   backlight: backlight {
+   status = "okay";
+   compatible = "pwm-backlight";
+   enable-gpios = < RK_PB5 GPIO_ACTIVE_HIGH>;
+   pwms = < 0 25000 0>;
+   brightness-levels = <
+ 0   1   2   3   4   5   6   7
+ 8   9  10  11  12  13  14  15
+16  17  18  19  20  21  22  23
+24  25  26  27  28  29  30  31
+32  33  34  35  36  37  38  39
+40  41  42  43  44  45  46  47
+48  49  50  51  52  53  54  55
+56  57  58  59  60  61  62  63
+64  65  66  67  68  69  70  71
+72  73  74  75  76  77  78  79
+80  81  82  83  84  85  86  87
+88  89  90  91  92  93  94  95
+96  97  98  99 100 101 102 103
+   104 

[PATCH v3] arm64: dts: rk3399: add support for firefly-rk3399 board

[Kever Yang]

Firefly-rk3399 is a bord from T-Firefly, you can find detail about
it here:
http://en.t-firefly.com/en/firenow/Firefly_RK3399/

This patch add basic node for the board and make it able to bring
up.

Peripheral works:
- usb hub which connect to ehci controller;
- UART2 debug
- eMMC
- PCIe

Not work:
- USB 3.0 HOST, type-C port
- sdio, sd-card

Not test for other peripheral:
- HDMI
- Ethernet
- OPTICAL
- WiFi/BT
- MIPI CSI/DSI
- IR
- EDP/DP

Signed-off-by: Kever Yang 
---

Changes in v3:
- remove not upstream defined properties;
- remove fusb302 and gsl3673 node

Changes in v2:
- rebase on Heiko's for-next
- using pinctrl binding header definition instead of a number
- other fix by comments from Heiko and Andreas.

 arch/arm64/boot/dts/rockchip/Makefile   |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 714 
 2 files changed, 715 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index b5636bb..bcfa53b 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -5,6 +5,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-orion-r68-meta.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-firefly.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-kevin.dtb
 
 always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
new file mode 100644
index 000..2517219
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -0,0 +1,714 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   model = "Firefly-RK3399 Board";
+   compatible = "firefly,firefly-rk3399", "rockchip,rk3399";
+
+   backlight: backlight {
+   status = "okay";
+   compatible = "pwm-backlight";
+   enable-gpios = < RK_PB5 GPIO_ACTIVE_HIGH>;
+   pwms = < 0 25000 0>;
+   brightness-levels = <
+ 0   1   2   3   4   5   6   7
+ 8   9  10  11  12  13  14  15
+16  17  18  19  20  21  22  23
+24  25  26  27  28  29  30  31
+32  33  34  35  36  37  38  39
+40  41  42  43  44  45  46  47
+48  49  50  51  52  53  54  55
+56  57  58  59  60  61  62  63
+64  65  66  67  68  69  70  71
+72  73  74  75  76  77  78  79
+80  81  82  83  84  85  86  87
+88  89  90  91  92  93  94  95
+96  97  98  99 100 101 102 103
+   104 105 106 107 108 109 110 111
+ 

Re: WARNING: at arch/x86/kernel/cpu/perf_event_intel_cqm.c:186 __put_rmid+0x28/0x80()

[Xishi Qiu]

On 2017/3/2 14:55, Xishi Qiu wrote:
ping

> Hi, I test Trinity, and got the following log.
> My OS version is RHEL 7.2, I'm not sure if it has fixed in mainline.
> Any comment is welcome.
> 
> [57676.532593] [ cut here ]
> [57676.537415] WARNING: at arch/x86/kernel/cpu/perf_event_intel_cqm.c:186 
> __put_rmid+0x28/0x80()
> [57676.546299] Modules linked in: 8021q garp stp mrp llc fuse cmtp kernelcapi 
> scsi_transport_iscsi rfcomm dccp_ipv6 dccp_ipv4 dccp ipt_ULOG bluetooth 
> rfkill af_key nfnetlink af_802154 vmw_vsock_vmci_transport vmw_vmci vsock atm 
> pppoe pppox ppp_generic slhc openvswitch ipmi_devintf ipmi_si ipmi_msghandler 
> coretemp intel_rapl crc32_pclmul crc32c_intel ghash_clmulni_intel iTCO_wdt 
> iTCO_vendor_support tg3 aesni_intel lrw gf128mul glue_helper ptp pps_core ses 
> enclosure ablk_helper cryptd sg sb_edac pcspkr edac_core acpi_power_meter 
> i2c_i801 i2c_core mei_me mei shpchp lpc_ich mfd_core ip_tables ext3 mbcache 
> jbd sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common 
> ahci libahci libata megaraid_sas dm_mod nf_conntrack_ipv4 nf_defrag_ipv4 
> vhost_net tun vhost macvtap macvlan vfio_pci irqbypass
> [57676.620009]  vfio_iommu_type1 vfio xt_sctp nf_conntrack_proto_sctp 
> nf_nat_proto_sctp nf_nat nf_conntrack sctp libcrc32c
> [57676.629998] CPU: 11 PID: 114 Comm: kworker/11:0 Not tainted 
> 3.10.0-327.44.58.22.x86_64 #1
> [57676.638525] Hardware name: Huawei RH2288H V3/BC11HGSA0, BIOS 3.31 
> 08/22/2016
> [57676.645746] Workqueue: events intel_cqm_rmid_rotate
> [57676.650821]   701d762a 882027873d60 
> 8163b400
> [57676.658639]  882027873d98 8107b1f0 0001 
> 
> [57676.666458]  88201fba7000 88100ceeb400 8820265730c0 
> 882027873da8
> [57676.674285] Call Trace:
> [57676.676915]  [] dump_stack+0x19/0x1b
> [57676.682227]  [] warn_slowpath_common+0x70/0xb0
> [57676.688404]  [] warn_slowpath_null+0x1a/0x20
> [57676.694409]  [] __put_rmid+0x28/0x80
> [57676.699694]  [] intel_cqm_rmid_rotate+0xba/0x440
> [57676.706051]  [] process_one_work+0x17b/0x470
> [57676.712070]  [] worker_thread+0x11b/0x400
> [57676.717819]  [] ? rescuer_thread+0x400/0x400
> [57676.723830]  [] kthread+0xcf/0xe0
> [57676.728883]  [] ? kthread_create_on_node+0x140/0x140
> [57676.735586]  [] ret_from_fork+0x58/0x90
> [57676.741156]  [] ? kthread_create_on_node+0x140/0x140
> [57676.747860] ---[ end trace dee4db6217e5fc5d ]---
> [57676.752669] BUG: unable to handle kernel NULL pointer dereference at   
> (null)
> [57676.760870] IP: [] __put_rmid+0x36/0x80
> [57676.766458] PGD 1026c33067 PUD 10282c4067 PMD 0 
> [57676.771279] Oops:  [#1] SMP 
> [57676.774722] Modules linked in: 8021q garp stp mrp llc fuse cmtp kernelcapi 
> scsi_transport_iscsi rfcomm dccp_ipv6 dccp_ipv4 dccp ipt_ULOG bluetooth 
> rfkill af_key nfnetlink af_802154 vmw_vsock_vmci_transport vmw_vmci vsock atm 
> pppoe pppox ppp_generic slhc openvswitch ipmi_devintf ipmi_si ipmi_msghandler 
> coretemp intel_rapl crc32_pclmul crc32c_intel ghash_clmulni_intel iTCO_wdt 
> iTCO_vendor_support tg3 aesni_intel lrw gf128mul glue_helper ptp pps_core ses 
> enclosure ablk_helper cryptd sg sb_edac pcspkr edac_core acpi_power_meter 
> i2c_i801 i2c_core mei_me mei shpchp lpc_ich mfd_core ip_tables ext3 mbcache 
> jbd sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common 
> ahci libahci libata megaraid_sas dm_mod nf_conntrack_ipv4 nf_defrag_ipv4 
> vhost_net tun vhost macvtap macvlan vfio_pci irqbypass
> [57676.848405]  vfio_iommu_type1 vfio xt_sctp nf_conntrack_proto_sctp 
> nf_nat_proto_sctp nf_nat nf_conntrack sctp libcrc32c
> [57676.858377] CPU: 11 PID: 114 Comm: kworker/11:0 Tainted: GW  
>  ---   3.10.0-327.44.58.22.x86_64 #1
> [57676.869330] Hardware name: Huawei RH2288H V3/BC11HGSA0, BIOS 3.31 
> 08/22/2016
> [57676.876548] Workqueue: events intel_cqm_rmid_rotate
> [57676.881618] task: 882027868b80 ti: 88202787 task.ti: 
> 88202787
> [57676.889448] RIP: 0010:[]  [] 
> __put_rmid+0x36/0x80
> [57676.897638] RSP: 0018:882027873db8  EFLAGS: 00010296
> [57676.903119] RAX: 8820259e4300 RBX:  RCX: 
> 
> [57676.910419] RDX:  RSI:  RDI: 
> 0009
> [57676.917725] RBP: 882027873dc8 R08: 0092 R09: 
> 880bcec0
> [57676.925031] R10: 00a0 R11: 0050 R12: 
> 
> [57676.932330] R13: 88201fba7000 R14: 88100ceeb400 R15: 
> 8820265730c0
> [57676.939631] FS:  () GS:88203e34() 
> knlGS:
> [57676.948064] CS:  0010 DS:  ES:  CR0: 80050033
> [57676.953982] CR2:  CR3: 001026c32000 CR4: 
> 001407e0
> [57676.961286] DR0: 7f2390b3d000 DR1: 7fc8e188f000 DR2: 
> 
> [57676.968586] DR3:  DR6: 

Re: WARNING: at arch/x86/kernel/cpu/perf_event_intel_cqm.c:186 __put_rmid+0x28/0x80()

[Xishi Qiu]

On 2017/3/2 14:55, Xishi Qiu wrote:
ping

> Hi, I test Trinity, and got the following log.
> My OS version is RHEL 7.2, I'm not sure if it has fixed in mainline.
> Any comment is welcome.
> 
> [57676.532593] [ cut here ]
> [57676.537415] WARNING: at arch/x86/kernel/cpu/perf_event_intel_cqm.c:186 
> __put_rmid+0x28/0x80()
> [57676.546299] Modules linked in: 8021q garp stp mrp llc fuse cmtp kernelcapi 
> scsi_transport_iscsi rfcomm dccp_ipv6 dccp_ipv4 dccp ipt_ULOG bluetooth 
> rfkill af_key nfnetlink af_802154 vmw_vsock_vmci_transport vmw_vmci vsock atm 
> pppoe pppox ppp_generic slhc openvswitch ipmi_devintf ipmi_si ipmi_msghandler 
> coretemp intel_rapl crc32_pclmul crc32c_intel ghash_clmulni_intel iTCO_wdt 
> iTCO_vendor_support tg3 aesni_intel lrw gf128mul glue_helper ptp pps_core ses 
> enclosure ablk_helper cryptd sg sb_edac pcspkr edac_core acpi_power_meter 
> i2c_i801 i2c_core mei_me mei shpchp lpc_ich mfd_core ip_tables ext3 mbcache 
> jbd sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common 
> ahci libahci libata megaraid_sas dm_mod nf_conntrack_ipv4 nf_defrag_ipv4 
> vhost_net tun vhost macvtap macvlan vfio_pci irqbypass
> [57676.620009]  vfio_iommu_type1 vfio xt_sctp nf_conntrack_proto_sctp 
> nf_nat_proto_sctp nf_nat nf_conntrack sctp libcrc32c
> [57676.629998] CPU: 11 PID: 114 Comm: kworker/11:0 Not tainted 
> 3.10.0-327.44.58.22.x86_64 #1
> [57676.638525] Hardware name: Huawei RH2288H V3/BC11HGSA0, BIOS 3.31 
> 08/22/2016
> [57676.645746] Workqueue: events intel_cqm_rmid_rotate
> [57676.650821]   701d762a 882027873d60 
> 8163b400
> [57676.658639]  882027873d98 8107b1f0 0001 
> 
> [57676.666458]  88201fba7000 88100ceeb400 8820265730c0 
> 882027873da8
> [57676.674285] Call Trace:
> [57676.676915]  [] dump_stack+0x19/0x1b
> [57676.682227]  [] warn_slowpath_common+0x70/0xb0
> [57676.688404]  [] warn_slowpath_null+0x1a/0x20
> [57676.694409]  [] __put_rmid+0x28/0x80
> [57676.699694]  [] intel_cqm_rmid_rotate+0xba/0x440
> [57676.706051]  [] process_one_work+0x17b/0x470
> [57676.712070]  [] worker_thread+0x11b/0x400
> [57676.717819]  [] ? rescuer_thread+0x400/0x400
> [57676.723830]  [] kthread+0xcf/0xe0
> [57676.728883]  [] ? kthread_create_on_node+0x140/0x140
> [57676.735586]  [] ret_from_fork+0x58/0x90
> [57676.741156]  [] ? kthread_create_on_node+0x140/0x140
> [57676.747860] ---[ end trace dee4db6217e5fc5d ]---
> [57676.752669] BUG: unable to handle kernel NULL pointer dereference at   
> (null)
> [57676.760870] IP: [] __put_rmid+0x36/0x80
> [57676.766458] PGD 1026c33067 PUD 10282c4067 PMD 0 
> [57676.771279] Oops:  [#1] SMP 
> [57676.774722] Modules linked in: 8021q garp stp mrp llc fuse cmtp kernelcapi 
> scsi_transport_iscsi rfcomm dccp_ipv6 dccp_ipv4 dccp ipt_ULOG bluetooth 
> rfkill af_key nfnetlink af_802154 vmw_vsock_vmci_transport vmw_vmci vsock atm 
> pppoe pppox ppp_generic slhc openvswitch ipmi_devintf ipmi_si ipmi_msghandler 
> coretemp intel_rapl crc32_pclmul crc32c_intel ghash_clmulni_intel iTCO_wdt 
> iTCO_vendor_support tg3 aesni_intel lrw gf128mul glue_helper ptp pps_core ses 
> enclosure ablk_helper cryptd sg sb_edac pcspkr edac_core acpi_power_meter 
> i2c_i801 i2c_core mei_me mei shpchp lpc_ich mfd_core ip_tables ext3 mbcache 
> jbd sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common 
> ahci libahci libata megaraid_sas dm_mod nf_conntrack_ipv4 nf_defrag_ipv4 
> vhost_net tun vhost macvtap macvlan vfio_pci irqbypass
> [57676.848405]  vfio_iommu_type1 vfio xt_sctp nf_conntrack_proto_sctp 
> nf_nat_proto_sctp nf_nat nf_conntrack sctp libcrc32c
> [57676.858377] CPU: 11 PID: 114 Comm: kworker/11:0 Tainted: GW  
>  ---   3.10.0-327.44.58.22.x86_64 #1
> [57676.869330] Hardware name: Huawei RH2288H V3/BC11HGSA0, BIOS 3.31 
> 08/22/2016
> [57676.876548] Workqueue: events intel_cqm_rmid_rotate
> [57676.881618] task: 882027868b80 ti: 88202787 task.ti: 
> 88202787
> [57676.889448] RIP: 0010:[]  [] 
> __put_rmid+0x36/0x80
> [57676.897638] RSP: 0018:882027873db8  EFLAGS: 00010296
> [57676.903119] RAX: 8820259e4300 RBX:  RCX: 
> 
> [57676.910419] RDX:  RSI:  RDI: 
> 0009
> [57676.917725] RBP: 882027873dc8 R08: 0092 R09: 
> 880bcec0
> [57676.925031] R10: 00a0 R11: 0050 R12: 
> 
> [57676.932330] R13: 88201fba7000 R14: 88100ceeb400 R15: 
> 8820265730c0
> [57676.939631] FS:  () GS:88203e34() 
> knlGS:
> [57676.948064] CS:  0010 DS:  ES:  CR0: 80050033
> [57676.953982] CR2:  CR3: 001026c32000 CR4: 
> 001407e0
> [57676.961286] DR0: 7f2390b3d000 DR1: 7fc8e188f000 DR2: 
> 
> [57676.968586] DR3:  DR6: 

Re: [PATCH v2 1/2] arm64: dts: rk3399: add support for firefly-rk3399 board

[Kever Yang]

Hi Heiko,


On 04/08/2017 07:01 AM, Heiko Stuebner wrote:

Hi Kever,

Am Mittwoch, 5. April 2017, 17:33:19 CEST schrieb Kever Yang:

Firefly-rk3399 is a bord from T-Firefly, you can find detail about
it here:
http://en.t-firefly.com/en/firenow/Firefly_RK3399/

This patch add basic node for the board and make it able to bring
up.

Peripheral works:
- usb hub which connect to ehci controller;
- UART2 debug
- eMMC
- PCIe

Not work:
- USB 3.0 HOST, type-C port
- sdio, sd-card

Not test for other peripheral:
- HDMI
- Ethernet
- OPTICAL
- WiFi/BT
- MIPI CSI/DSI
- IR
- EDP/DP

Signed-off-by: Kever Yang 

[...]


+   vdd_log: vdd-log {
+   compatible = "pwm-regulator";
+   pwms = < 0 25000 1>;
+   regulator-name = "vdd_log";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-always-on;
+   regulator-boot-on;
+
+   /* for rockchip boot on */
+   rockchip,pwm_id= <2>;
+   rockchip,pwm_voltage = <100>;

Vendor-kernel stuff, needs to be dropped


Will drop it next version.


[...]


+ {
+   status = "okay";
+   i2c-scl-rising-time-ns = <168>;
+   i2c-scl-falling-time-ns = <4>;
+   clock-frequency = <40>;
+
+   vdd_cpu_b: pmic@40 {
+   compatible = "silergy,syr827";
+   reg = <0x40>;
+   vin-supply = <_sys>;
+   regulator-compatible = "fan53555-reg";
+   regulator-name = "vdd_cpu_b";
+   regulator-min-microvolt = <712500>;
+   regulator-max-microvolt = <150>;
+   regulator-ramp-delay = <1000>;
+   vsel-gpios = < RK_PC2 GPIO_ACTIVE_HIGH>;

non-mainline property


Will drop it next version.



+   fcs,suspend-voltage-selector = <0>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-initial-state = <3>;

non-mainline property


Will drop it next version.



+   regulator-state-mem {

indentation is wrong


+   regulator-off-in-suspend;
+   };
+   };
+
+   vdd_gpu: syr828@41 {
+   compatible = "silergy,syr828";
+   reg = <0x41>;
+   vin-supply = <_sys>;
+   regulator-compatible = "fan53555-reg";
+   regulator-name = "vdd_gpu";
+   regulator-min-microvolt = <712500>;
+   regulator-max-microvolt = <150>;
+   regulator-ramp-delay = <1000>;
+   fcs,suspend-voltage-selector = <1>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-initial-state = <3>;

non-mainline property


Will drop it next version.



+   regulator-state-mem {

indentation is wrong


+   regulator-off-in-suspend;
+   };
+   };
+
+   rk808: pmic@1b {
+   compatible = "rockchip,rk808";
+   reg = <0x1b>;
+   interrupt-parent = <>;
+   interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_int_l>;
+   rockchip,system-power-controller;

system-power-controller without the "rockchip,"?


The driver at drivers/mfd/rk808.c is using "rockchip, 
system-power-controller".



+   wakeup-source;
+   #clock-cells = <1>;
+   clock-output-names = "xin32k", "rk808-clkout2";

[...]


+ {
+   status = "okay";
+   i2c-scl-rising-time-ns = <300>;
+   i2c-scl-falling-time-ns = <15>;
+
+   gsl3673: gsl3673@40 {

gsl3673: touchscreen@40


+   compatible = "GSL,GSL3673";

compatible lowercase?


This is not using upstream driver, need porting, remove it now.



+   reg = <0x40>;
+   screen_max_x = <1536>;
+   screen_max_y = <2048>;
+   irq_gpio_number = < RK_PC4 IRQ_TYPE_LEVEL_LOW>;
+   rst_gpio_number = < RK_PC6 GPIO_ACTIVE_HIGH>;
+   };
+
+   rt5640: rt5640@1c {
+   #sound-dai-cells = <0>;
+   compatible = "realtek,rt5640";
+   reg = <0x1c>;
+   clocks = < SCLK_I2S_8CH_OUT>;
+   clock-names = "mclk";
+   realtek,in1-differential;
+   pinctrl-names = "default";
+   pinctrl-0 = <_hpcon>;
+   hp-con-gpio = < RK_PC5 GPIO_ACTIVE_HIGH>;
+   io-channels = < 4>;
+   hp-det-adc-value = <500>;

these last 3 properties are not contained in the rt5640 binding
document on linux-next-20170407 .


Will drop these properties nex version.



+   };
+};
+
+ {
+   status = "okay";
+   i2c-scl-rising-time-ns = <450>;
+   i2c-scl-falling-time-ns = <15>;
+};
+
+ {
+   status = "okay";
+   i2c-scl-rising-time-ns = <600>;
+   

Re: [PATCH v2 1/2] arm64: dts: rk3399: add support for firefly-rk3399 board

[Kever Yang]

Hi Heiko,


On 04/08/2017 07:01 AM, Heiko Stuebner wrote:

Hi Kever,

Am Mittwoch, 5. April 2017, 17:33:19 CEST schrieb Kever Yang:

Firefly-rk3399 is a bord from T-Firefly, you can find detail about
it here:
http://en.t-firefly.com/en/firenow/Firefly_RK3399/

This patch add basic node for the board and make it able to bring
up.

Peripheral works:
- usb hub which connect to ehci controller;
- UART2 debug
- eMMC
- PCIe

Not work:
- USB 3.0 HOST, type-C port
- sdio, sd-card

Not test for other peripheral:
- HDMI
- Ethernet
- OPTICAL
- WiFi/BT
- MIPI CSI/DSI
- IR
- EDP/DP

Signed-off-by: Kever Yang 

[...]


+   vdd_log: vdd-log {
+   compatible = "pwm-regulator";
+   pwms = < 0 25000 1>;
+   regulator-name = "vdd_log";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-always-on;
+   regulator-boot-on;
+
+   /* for rockchip boot on */
+   rockchip,pwm_id= <2>;
+   rockchip,pwm_voltage = <100>;

Vendor-kernel stuff, needs to be dropped


Will drop it next version.


[...]


+ {
+   status = "okay";
+   i2c-scl-rising-time-ns = <168>;
+   i2c-scl-falling-time-ns = <4>;
+   clock-frequency = <40>;
+
+   vdd_cpu_b: pmic@40 {
+   compatible = "silergy,syr827";
+   reg = <0x40>;
+   vin-supply = <_sys>;
+   regulator-compatible = "fan53555-reg";
+   regulator-name = "vdd_cpu_b";
+   regulator-min-microvolt = <712500>;
+   regulator-max-microvolt = <150>;
+   regulator-ramp-delay = <1000>;
+   vsel-gpios = < RK_PC2 GPIO_ACTIVE_HIGH>;

non-mainline property


Will drop it next version.



+   fcs,suspend-voltage-selector = <0>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-initial-state = <3>;

non-mainline property


Will drop it next version.



+   regulator-state-mem {

indentation is wrong


+   regulator-off-in-suspend;
+   };
+   };
+
+   vdd_gpu: syr828@41 {
+   compatible = "silergy,syr828";
+   reg = <0x41>;
+   vin-supply = <_sys>;
+   regulator-compatible = "fan53555-reg";
+   regulator-name = "vdd_gpu";
+   regulator-min-microvolt = <712500>;
+   regulator-max-microvolt = <150>;
+   regulator-ramp-delay = <1000>;
+   fcs,suspend-voltage-selector = <1>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-initial-state = <3>;

non-mainline property


Will drop it next version.



+   regulator-state-mem {

indentation is wrong


+   regulator-off-in-suspend;
+   };
+   };
+
+   rk808: pmic@1b {
+   compatible = "rockchip,rk808";
+   reg = <0x1b>;
+   interrupt-parent = <>;
+   interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_int_l>;
+   rockchip,system-power-controller;

system-power-controller without the "rockchip,"?


The driver at drivers/mfd/rk808.c is using "rockchip, 
system-power-controller".



+   wakeup-source;
+   #clock-cells = <1>;
+   clock-output-names = "xin32k", "rk808-clkout2";

[...]


+ {
+   status = "okay";
+   i2c-scl-rising-time-ns = <300>;
+   i2c-scl-falling-time-ns = <15>;
+
+   gsl3673: gsl3673@40 {

gsl3673: touchscreen@40


+   compatible = "GSL,GSL3673";

compatible lowercase?


This is not using upstream driver, need porting, remove it now.



+   reg = <0x40>;
+   screen_max_x = <1536>;
+   screen_max_y = <2048>;
+   irq_gpio_number = < RK_PC4 IRQ_TYPE_LEVEL_LOW>;
+   rst_gpio_number = < RK_PC6 GPIO_ACTIVE_HIGH>;
+   };
+
+   rt5640: rt5640@1c {
+   #sound-dai-cells = <0>;
+   compatible = "realtek,rt5640";
+   reg = <0x1c>;
+   clocks = < SCLK_I2S_8CH_OUT>;
+   clock-names = "mclk";
+   realtek,in1-differential;
+   pinctrl-names = "default";
+   pinctrl-0 = <_hpcon>;
+   hp-con-gpio = < RK_PC5 GPIO_ACTIVE_HIGH>;
+   io-channels = < 4>;
+   hp-det-adc-value = <500>;

these last 3 properties are not contained in the rt5640 binding
document on linux-next-20170407 .


Will drop these properties nex version.



+   };
+};
+
+ {
+   status = "okay";
+   i2c-scl-rising-time-ns = <450>;
+   i2c-scl-falling-time-ns = <15>;
+};
+
+ {
+   status = "okay";
+   i2c-scl-rising-time-ns = <600>;
+   i2c-scl-falling-time-ns = <20>;
+
+   

linux-next: manual merge of the clockevents tree with the arm-soc tree

[Stephen Rothwell]

Hi Daniel,

Today's linux-next merge of the clockevents tree got a conflict in:

  arch/arm/boot/dts/rk3188.dtsi

between commit:

  2e1aa605fadd ("ARM: dts: rockchip: fix PPI misconfiguration on Cortex-A9 
socs")

from the arm-soc tree and commit:

  500d0aa918a2 ("ARM: dts: rockchip: disable arm-global-timer for rk3188")

from the clockevents tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/boot/dts/rk3188.dtsi
index fa1bdb8875ae,1aff4ad22fc4..
--- a/arch/arm/boot/dts/rk3188.dtsi
+++ b/arch/arm/boot/dts/rk3188.dtsi
@@@ -529,7 -545,8 +545,8 @@@
  };
  
  _timer {
 -  interrupts = ;
 +  interrupts = ;
+   status = "disabled";
  };
  
  _timer {

linux-next: manual merge of the clockevents tree with the arm-soc tree

[Stephen Rothwell]

Hi Daniel,

Today's linux-next merge of the clockevents tree got a conflict in:

  arch/arm/boot/dts/rk3188.dtsi

between commit:

  2e1aa605fadd ("ARM: dts: rockchip: fix PPI misconfiguration on Cortex-A9 
socs")

from the arm-soc tree and commit:

  500d0aa918a2 ("ARM: dts: rockchip: disable arm-global-timer for rk3188")

from the clockevents tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/boot/dts/rk3188.dtsi
index fa1bdb8875ae,1aff4ad22fc4..
--- a/arch/arm/boot/dts/rk3188.dtsi
+++ b/arch/arm/boot/dts/rk3188.dtsi
@@@ -529,7 -545,8 +545,8 @@@
  };
  
  _timer {
 -  interrupts = ;
 +  interrupts = ;
+   status = "disabled";
  };
  
  _timer {

Re: [PATCH] Documentation: vm, add hugetlbfs reservation overview

[Hillf Danton]

On April 08, 2017 1:43 AM Mike Kravetz wrote: 
> 
> Adding a brief overview of hugetlbfs reservation design and implementation
> as an aid to those making code modifications in this area.
> 
> Signed-off-by: Mike Kravetz 
> ---
You are doing more than I can double thank you, Mike:)

Acked-by: Hillf Danton 

Re: [PATCH] Documentation: vm, add hugetlbfs reservation overview

[Hillf Danton]

On April 08, 2017 1:43 AM Mike Kravetz wrote: 
> 
> Adding a brief overview of hugetlbfs reservation design and implementation
> as an aid to those making code modifications in this area.
> 
> Signed-off-by: Mike Kravetz 
> ---
You are doing more than I can double thank you, Mike:)

Acked-by: Hillf Danton 

Re: [PATCH v2 2/2] drivers/serial: Add driver for Aspeed virtual UART

[Joel Stanley]

On Wed, Apr 5, 2017 at 8:24 PM, Andy Shevchenko
 wrote:
> On Wed, Apr 5, 2017 at 7:03 AM, Joel Stanley  wrote:
>
>> +   port.port.irq = irq_of_parse_and_map(np, 0);
>
> Isn't better to get this via platform_get_irq() ?

I can't see the benefit.

>
>> +   port.port.irqflags = IRQF_SHARED;
>> +   port.port.iotype = UPIO_MEM;
>
>> +   if (of_property_read_u32(np, "reg-io-width", ) == 0) {
>
> I would still go with usual pattern.
>
>> +   switch (prop) {
>> +   case 1:
>> +   port.port.iotype = UPIO_MEM;
>> +   break;
>> +   case 4:
>
>> +   port.port.iotype = of_device_is_big_endian(np) ?
>> +  UPIO_MEM32BE : UPIO_MEM32;
>
> Hmm... And this one is not in align with IO accessors used in this
> driver. (readx()/writex() are little endian IO accessors).

We only perform readb/writeb, however you raise a good point that
we're assuming LE in the register layout. I will remove checking of this
optional property.

I will send v3 with the other cleanups you mentioned.

Cheers,

Joel

>
>> +   break;
>> +   default:
>> +   dev_warn(>dev, "unsupported reg-io-width 
>> (%d)\n",
>> +prop);
>> +   rc = -EINVAL;
>> +   goto err_clk_disable;
>> +   }
>> +   }
>> +

Re: [PATCH v2 2/2] drivers/serial: Add driver for Aspeed virtual UART

[Joel Stanley]

On Wed, Apr 5, 2017 at 8:24 PM, Andy Shevchenko
 wrote:
> On Wed, Apr 5, 2017 at 7:03 AM, Joel Stanley  wrote:
>
>> +   port.port.irq = irq_of_parse_and_map(np, 0);
>
> Isn't better to get this via platform_get_irq() ?

I can't see the benefit.

>
>> +   port.port.irqflags = IRQF_SHARED;
>> +   port.port.iotype = UPIO_MEM;
>
>> +   if (of_property_read_u32(np, "reg-io-width", ) == 0) {
>
> I would still go with usual pattern.
>
>> +   switch (prop) {
>> +   case 1:
>> +   port.port.iotype = UPIO_MEM;
>> +   break;
>> +   case 4:
>
>> +   port.port.iotype = of_device_is_big_endian(np) ?
>> +  UPIO_MEM32BE : UPIO_MEM32;
>
> Hmm... And this one is not in align with IO accessors used in this
> driver. (readx()/writex() are little endian IO accessors).

We only perform readb/writeb, however you raise a good point that
we're assuming LE in the register layout. I will remove checking of this
optional property.

I will send v3 with the other cleanups you mentioned.

Cheers,

Joel

>
>> +   break;
>> +   default:
>> +   dev_warn(>dev, "unsupported reg-io-width 
>> (%d)\n",
>> +prop);
>> +   rc = -EINVAL;
>> +   goto err_clk_disable;
>> +   }
>> +   }
>> +

[PATCH v4 0/1] fix perf build issue when ARCH=x86_64

[jiada_wang]

From: Jiada Wang 

Changes from v4:
 update changlog to describe the reason of build failure
 replace ARCH with SRCARCH in pmu-events/Build and util/header.c

Changes from v3:
 replace ARCH with SRCARCH in perf

Changes from v2:
 added function purify-arch, transforms both HOSTARCH and ARCH
 to supported values

Jiada Wang (1):
  perf tools: fix perf build with ARCH=x86_64

 tools/perf/Makefile.config | 38 +++---
 tools/perf/Makefile.perf   |  2 +-
 tools/perf/arch/Build  |  2 +-
 tools/perf/tests/Build |  2 +-
 4 files changed, 22 insertions(+), 22 deletions(-)

-- 
2.7.4

[PATCH v4 1/1] perf tools: fix perf build with ARCH=x86_64

[jiada_wang]

From: Jiada Wang 

with commit: 0a943cb10ce78 (tools build: Add HOSTARCH Makefile variable)
when build for ARCH=x86_64, ARCH=x86_64 is passed to perf instead of
ARCH=x86, so perf package searchs header files from
tools/arch/x86_64/include, which doesn't exist.

the following build failure is seen when build with ARCH=x86_64

In file included from util/event.c:2:0:
tools/include/uapi/linux/mman.h:4:27: fatal error: uapi/asm/mman.h: No such 
file or directory
compilation terminated.

fix this issue by use SRCARCH instead of ARCH in perf.

Signed-off-by: Jiada Wang 
---
 tools/perf/Makefile.config  | 38 +++---
 tools/perf/Makefile.perf|  2 +-
 tools/perf/arch/Build   |  2 +-
 tools/perf/pmu-events/Build |  4 ++--
 tools/perf/tests/Build  |  2 +-
 tools/perf/util/header.c|  2 +-
 6 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 76c84f0..123fd40 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -19,18 +19,18 @@ CFLAGS := $(EXTRA_CFLAGS) $(EXTRA_WARNINGS)
 
 include $(srctree)/tools/scripts/Makefile.arch
 
-$(call detected_var,ARCH)
+$(call detected_var,SRCARCH)
 
 NO_PERF_REGS := 1
 
 # Additional ARCH settings for ppc
-ifeq ($(ARCH),powerpc)
+ifeq ($(SRCARCH),powerpc)
   NO_PERF_REGS := 0
   LIBUNWIND_LIBS := -lunwind -lunwind-ppc64
 endif
 
 # Additional ARCH settings for x86
-ifeq ($(ARCH),x86)
+ifeq ($(SRCARCH),x86)
   $(call detected,CONFIG_X86)
   ifeq (${IS_64_BIT}, 1)
 CFLAGS += -DHAVE_ARCH_X86_64_SUPPORT -DHAVE_SYSCALL_TABLE 
-I$(OUTPUT)arch/x86/include/generated
@@ -43,12 +43,12 @@ ifeq ($(ARCH),x86)
   NO_PERF_REGS := 0
 endif
 
-ifeq ($(ARCH),arm)
+ifeq ($(SRCARCH),arm)
   NO_PERF_REGS := 0
   LIBUNWIND_LIBS = -lunwind -lunwind-arm
 endif
 
-ifeq ($(ARCH),arm64)
+ifeq ($(SRCARCH),arm64)
   NO_PERF_REGS := 0
   LIBUNWIND_LIBS = -lunwind -lunwind-aarch64
 endif
@@ -61,7 +61,7 @@ endif
 # Disable it on all other architectures in case libdw unwind
 # support is detected in system. Add supported architectures
 # to the check.
-ifneq ($(ARCH),$(filter $(ARCH),x86 arm))
+ifneq ($(SRCARCH),$(filter $(SRCARCH),x86 arm))
   NO_LIBDW_DWARF_UNWIND := 1
 endif
 
@@ -115,9 +115,9 @@ endif
 FEATURE_CHECK_CFLAGS-libbabeltrace := $(LIBBABELTRACE_CFLAGS)
 FEATURE_CHECK_LDFLAGS-libbabeltrace := $(LIBBABELTRACE_LDFLAGS) 
-lbabeltrace-ctf
 
-FEATURE_CHECK_CFLAGS-bpf = -I. -I$(srctree)/tools/include 
-I$(srctree)/tools/arch/$(ARCH)/include/uapi -I$(srctree)/tools/include/uapi
+FEATURE_CHECK_CFLAGS-bpf = -I. -I$(srctree)/tools/include 
-I$(srctree)/tools/arch/$(SRCARCH)/include/uapi -I$(srctree)/tools/include/uapi
 # include ARCH specific config
--include $(src-perf)/arch/$(ARCH)/Makefile
+-include $(src-perf)/arch/$(SRCARCH)/Makefile
 
 ifdef PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET
   CFLAGS += -DHAVE_ARCH_REGS_QUERY_REGISTER_OFFSET
@@ -213,12 +213,12 @@ ifeq ($(DEBUG),0)
 endif
 
 INC_FLAGS += -I$(src-perf)/util/include
-INC_FLAGS += -I$(src-perf)/arch/$(ARCH)/include
+INC_FLAGS += -I$(src-perf)/arch/$(SRCARCH)/include
 INC_FLAGS += -I$(srctree)/tools/include/uapi
 INC_FLAGS += -I$(srctree)/tools/include/
-INC_FLAGS += -I$(srctree)/tools/arch/$(ARCH)/include/uapi
-INC_FLAGS += -I$(srctree)/tools/arch/$(ARCH)/include/
-INC_FLAGS += -I$(srctree)/tools/arch/$(ARCH)/
+INC_FLAGS += -I$(srctree)/tools/arch/$(SRCARCH)/include/uapi
+INC_FLAGS += -I$(srctree)/tools/arch/$(SRCARCH)/include/
+INC_FLAGS += -I$(srctree)/tools/arch/$(SRCARCH)/
 
 # $(obj-perf)  for generated common-cmds.h
 # $(obj-perf)/util for generated bison/flex headers
@@ -332,7 +332,7 @@ ifndef NO_LIBELF
 
   ifndef NO_DWARF
 ifeq ($(origin PERF_HAVE_DWARF_REGS), undefined)
-  msg := $(warning DWARF register mappings have not been defined for 
architecture $(ARCH), DWARF support disabled);
+  msg := $(warning DWARF register mappings have not been defined for 
architecture $(SRCARCH), DWARF support disabled);
   NO_DWARF := 1
 else
   CFLAGS += -DHAVE_DWARF_SUPPORT $(LIBDW_CFLAGS)
@@ -357,7 +357,7 @@ ifndef NO_LIBELF
 CFLAGS += -DHAVE_BPF_PROLOGUE
 $(call detected,CONFIG_BPF_PROLOGUE)
   else
-msg := $(warning BPF prologue is not supported by architecture 
$(ARCH), missing regs_query_register_offset());
+msg := $(warning BPF prologue is not supported by architecture 
$(SRCARCH), missing regs_query_register_offset());
   endif
 else
   msg := $(warning DWARF support is off, BPF prologue is disabled);
@@ -383,7 +383,7 @@ ifdef PERF_HAVE_JITDUMP
   endif
 endif
 
-ifeq ($(ARCH),powerpc)
+ifeq ($(SRCARCH),powerpc)
   ifndef NO_DWARF
 CFLAGS += -DHAVE_SKIP_CALLCHAIN_IDX
   endif
@@ -464,7 +464,7 @@ else
 endif
 
 ifndef NO_LOCAL_LIBUNWIND
-  ifeq ($(ARCH),$(filter $(ARCH),arm arm64))
+  ifeq ($(SRCARCH),$(filter $(SRCARCH),arm arm64))
 $(call 

[PATCH v4 0/1] fix perf build issue when ARCH=x86_64

[jiada_wang]

From: Jiada Wang 

Changes from v4:
 update changlog to describe the reason of build failure
 replace ARCH with SRCARCH in pmu-events/Build and util/header.c

Changes from v3:
 replace ARCH with SRCARCH in perf

Changes from v2:
 added function purify-arch, transforms both HOSTARCH and ARCH
 to supported values

Jiada Wang (1):
  perf tools: fix perf build with ARCH=x86_64

 tools/perf/Makefile.config | 38 +++---
 tools/perf/Makefile.perf   |  2 +-
 tools/perf/arch/Build  |  2 +-
 tools/perf/tests/Build |  2 +-
 4 files changed, 22 insertions(+), 22 deletions(-)

-- 
2.7.4

[PATCH v4 1/1] perf tools: fix perf build with ARCH=x86_64

[jiada_wang]

From: Jiada Wang 

with commit: 0a943cb10ce78 (tools build: Add HOSTARCH Makefile variable)
when build for ARCH=x86_64, ARCH=x86_64 is passed to perf instead of
ARCH=x86, so perf package searchs header files from
tools/arch/x86_64/include, which doesn't exist.

the following build failure is seen when build with ARCH=x86_64

In file included from util/event.c:2:0:
tools/include/uapi/linux/mman.h:4:27: fatal error: uapi/asm/mman.h: No such 
file or directory
compilation terminated.

fix this issue by use SRCARCH instead of ARCH in perf.

Signed-off-by: Jiada Wang 
---
 tools/perf/Makefile.config  | 38 +++---
 tools/perf/Makefile.perf|  2 +-
 tools/perf/arch/Build   |  2 +-
 tools/perf/pmu-events/Build |  4 ++--
 tools/perf/tests/Build  |  2 +-
 tools/perf/util/header.c|  2 +-
 6 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 76c84f0..123fd40 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -19,18 +19,18 @@ CFLAGS := $(EXTRA_CFLAGS) $(EXTRA_WARNINGS)
 
 include $(srctree)/tools/scripts/Makefile.arch
 
-$(call detected_var,ARCH)
+$(call detected_var,SRCARCH)
 
 NO_PERF_REGS := 1
 
 # Additional ARCH settings for ppc
-ifeq ($(ARCH),powerpc)
+ifeq ($(SRCARCH),powerpc)
   NO_PERF_REGS := 0
   LIBUNWIND_LIBS := -lunwind -lunwind-ppc64
 endif
 
 # Additional ARCH settings for x86
-ifeq ($(ARCH),x86)
+ifeq ($(SRCARCH),x86)
   $(call detected,CONFIG_X86)
   ifeq (${IS_64_BIT}, 1)
 CFLAGS += -DHAVE_ARCH_X86_64_SUPPORT -DHAVE_SYSCALL_TABLE 
-I$(OUTPUT)arch/x86/include/generated
@@ -43,12 +43,12 @@ ifeq ($(ARCH),x86)
   NO_PERF_REGS := 0
 endif
 
-ifeq ($(ARCH),arm)
+ifeq ($(SRCARCH),arm)
   NO_PERF_REGS := 0
   LIBUNWIND_LIBS = -lunwind -lunwind-arm
 endif
 
-ifeq ($(ARCH),arm64)
+ifeq ($(SRCARCH),arm64)
   NO_PERF_REGS := 0
   LIBUNWIND_LIBS = -lunwind -lunwind-aarch64
 endif
@@ -61,7 +61,7 @@ endif
 # Disable it on all other architectures in case libdw unwind
 # support is detected in system. Add supported architectures
 # to the check.
-ifneq ($(ARCH),$(filter $(ARCH),x86 arm))
+ifneq ($(SRCARCH),$(filter $(SRCARCH),x86 arm))
   NO_LIBDW_DWARF_UNWIND := 1
 endif
 
@@ -115,9 +115,9 @@ endif
 FEATURE_CHECK_CFLAGS-libbabeltrace := $(LIBBABELTRACE_CFLAGS)
 FEATURE_CHECK_LDFLAGS-libbabeltrace := $(LIBBABELTRACE_LDFLAGS) 
-lbabeltrace-ctf
 
-FEATURE_CHECK_CFLAGS-bpf = -I. -I$(srctree)/tools/include 
-I$(srctree)/tools/arch/$(ARCH)/include/uapi -I$(srctree)/tools/include/uapi
+FEATURE_CHECK_CFLAGS-bpf = -I. -I$(srctree)/tools/include 
-I$(srctree)/tools/arch/$(SRCARCH)/include/uapi -I$(srctree)/tools/include/uapi
 # include ARCH specific config
--include $(src-perf)/arch/$(ARCH)/Makefile
+-include $(src-perf)/arch/$(SRCARCH)/Makefile
 
 ifdef PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET
   CFLAGS += -DHAVE_ARCH_REGS_QUERY_REGISTER_OFFSET
@@ -213,12 +213,12 @@ ifeq ($(DEBUG),0)
 endif
 
 INC_FLAGS += -I$(src-perf)/util/include
-INC_FLAGS += -I$(src-perf)/arch/$(ARCH)/include
+INC_FLAGS += -I$(src-perf)/arch/$(SRCARCH)/include
 INC_FLAGS += -I$(srctree)/tools/include/uapi
 INC_FLAGS += -I$(srctree)/tools/include/
-INC_FLAGS += -I$(srctree)/tools/arch/$(ARCH)/include/uapi
-INC_FLAGS += -I$(srctree)/tools/arch/$(ARCH)/include/
-INC_FLAGS += -I$(srctree)/tools/arch/$(ARCH)/
+INC_FLAGS += -I$(srctree)/tools/arch/$(SRCARCH)/include/uapi
+INC_FLAGS += -I$(srctree)/tools/arch/$(SRCARCH)/include/
+INC_FLAGS += -I$(srctree)/tools/arch/$(SRCARCH)/
 
 # $(obj-perf)  for generated common-cmds.h
 # $(obj-perf)/util for generated bison/flex headers
@@ -332,7 +332,7 @@ ifndef NO_LIBELF
 
   ifndef NO_DWARF
 ifeq ($(origin PERF_HAVE_DWARF_REGS), undefined)
-  msg := $(warning DWARF register mappings have not been defined for 
architecture $(ARCH), DWARF support disabled);
+  msg := $(warning DWARF register mappings have not been defined for 
architecture $(SRCARCH), DWARF support disabled);
   NO_DWARF := 1
 else
   CFLAGS += -DHAVE_DWARF_SUPPORT $(LIBDW_CFLAGS)
@@ -357,7 +357,7 @@ ifndef NO_LIBELF
 CFLAGS += -DHAVE_BPF_PROLOGUE
 $(call detected,CONFIG_BPF_PROLOGUE)
   else
-msg := $(warning BPF prologue is not supported by architecture 
$(ARCH), missing regs_query_register_offset());
+msg := $(warning BPF prologue is not supported by architecture 
$(SRCARCH), missing regs_query_register_offset());
   endif
 else
   msg := $(warning DWARF support is off, BPF prologue is disabled);
@@ -383,7 +383,7 @@ ifdef PERF_HAVE_JITDUMP
   endif
 endif
 
-ifeq ($(ARCH),powerpc)
+ifeq ($(SRCARCH),powerpc)
   ifndef NO_DWARF
 CFLAGS += -DHAVE_SKIP_CALLCHAIN_IDX
   endif
@@ -464,7 +464,7 @@ else
 endif
 
 ifndef NO_LOCAL_LIBUNWIND
-  ifeq ($(ARCH),$(filter $(ARCH),arm arm64))
+  ifeq ($(SRCARCH),$(filter $(SRCARCH),arm arm64))
 $(call feature_check,libunwind-debug-frame)
 ifneq 

Re: [PATCH] Staging: comedidev.h comedi_lrange should be const struct

[kbuild test robot]

Hi Arthur,

[auto build test WARNING on staging/staging-testing]
[also build test WARNING on v4.11-rc6 next-20170407]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Arthur-Brainville-Ybalrid/Staging-comedidev-h-comedi_lrange-should-be-const-struct/20170409-224503
config: x86_64-allmodconfig
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
make ARCH=x86_64  allmodconfig
make ARCH=x86_64 

All warnings (new ones prefixed by >>):


vim +629 drivers/staging/comedi/drivers/../comedidev.h

ed9eccbe8 David Schleef   2008-11-04  613  #define range_digital
range_unipolar5
ed9eccbe8 David Schleef   2008-11-04  614  
5459bc128 Ian Abbott  2015-09-21  615  /**
5459bc128 Ian Abbott  2015-09-21  616   * struct comedi_lrange 
- Describes a COMEDI range table
5459bc128 Ian Abbott  2015-09-21  617   * @length: Number of 
entries in the range table.
5459bc128 Ian Abbott  2015-09-21  618   * @range: Array of 
 comedi_krange, one for each range.
5459bc128 Ian Abbott  2015-09-21  619   *
5459bc128 Ian Abbott  2015-09-21  620   * Each element of 
@range[] describes the minimum and maximum physical range
5459bc128 Ian Abbott  2015-09-21  621   * range and the type of 
units.  Typically, the type of unit is %UNIT_volt
5459bc128 Ian Abbott  2015-09-21  622   * (i.e. volts) and the 
minimum and maximum are in millionths of a volt.
5459bc128 Ian Abbott  2015-09-21  623   * There may also be a 
flag that indicates the minimum and maximum are merely
5459bc128 Ian Abbott  2015-09-21  624   * scale factors for an 
unknown, external reference.
5459bc128 Ian Abbott  2015-09-21  625   */
540e454c2 Arthur Brainville (Ybalrid  2017-04-09  626) const struct 
comedi_lrange {
ed9eccbe8 David Schleef   2008-11-04  627   int length;
3358a0ca2 Cheah Kok Cheong2016-12-22  628   struct comedi_krange 
range[];
ed9eccbe8 David Schleef   2008-11-04 @629  };
ed9eccbe8 David Schleef   2008-11-04  630  
42e558399 Ian Abbott  2015-09-21  631  /**
42e558399 Ian Abbott  2015-09-21  632   * 
comedi_range_is_bipolar() - Test if subdevice range is bipolar
42e558399 Ian Abbott  2015-09-21  633   * @s: COMEDI subdevice.
42e558399 Ian Abbott  2015-09-21  634   * @range: Index of 
range within a range table.
42e558399 Ian Abbott  2015-09-21  635   *
42e558399 Ian Abbott  2015-09-21  636   * Tests whether a range 
is bipolar by checking whether its minimum value
42e558399 Ian Abbott  2015-09-21  637   * is negative.

:: The code at line 629 was first introduced by commit
:: ed9eccbe8970f6eedc1b978c157caf1251a896d4 Staging: add comedi core

:: TO: David Schleef <d...@schleef.org>
:: CC: Greg Kroah-Hartman <gre...@suse.de>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH] Staging: comedidev.h comedi_lrange should be const struct

[kbuild test robot]

Hi Arthur,

[auto build test WARNING on staging/staging-testing]
[also build test WARNING on v4.11-rc6 next-20170407]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Arthur-Brainville-Ybalrid/Staging-comedidev-h-comedi_lrange-should-be-const-struct/20170409-224503
config: x86_64-allmodconfig
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
make ARCH=x86_64  allmodconfig
make ARCH=x86_64 

All warnings (new ones prefixed by >>):


vim +629 drivers/staging/comedi/drivers/../comedidev.h

ed9eccbe8 David Schleef   2008-11-04  613  #define range_digital
range_unipolar5
ed9eccbe8 David Schleef   2008-11-04  614  
5459bc128 Ian Abbott  2015-09-21  615  /**
5459bc128 Ian Abbott  2015-09-21  616   * struct comedi_lrange 
- Describes a COMEDI range table
5459bc128 Ian Abbott  2015-09-21  617   * @length: Number of 
entries in the range table.
5459bc128 Ian Abbott  2015-09-21  618   * @range: Array of 
 comedi_krange, one for each range.
5459bc128 Ian Abbott  2015-09-21  619   *
5459bc128 Ian Abbott  2015-09-21  620   * Each element of 
@range[] describes the minimum and maximum physical range
5459bc128 Ian Abbott  2015-09-21  621   * range and the type of 
units.  Typically, the type of unit is %UNIT_volt
5459bc128 Ian Abbott  2015-09-21  622   * (i.e. volts) and the 
minimum and maximum are in millionths of a volt.
5459bc128 Ian Abbott  2015-09-21  623   * There may also be a 
flag that indicates the minimum and maximum are merely
5459bc128 Ian Abbott  2015-09-21  624   * scale factors for an 
unknown, external reference.
5459bc128 Ian Abbott  2015-09-21  625   */
540e454c2 Arthur Brainville (Ybalrid  2017-04-09  626) const struct 
comedi_lrange {
ed9eccbe8 David Schleef   2008-11-04  627   int length;
3358a0ca2 Cheah Kok Cheong2016-12-22  628   struct comedi_krange 
range[];
ed9eccbe8 David Schleef   2008-11-04 @629  };
ed9eccbe8 David Schleef   2008-11-04  630  
42e558399 Ian Abbott  2015-09-21  631  /**
42e558399 Ian Abbott  2015-09-21  632   * 
comedi_range_is_bipolar() - Test if subdevice range is bipolar
42e558399 Ian Abbott  2015-09-21  633   * @s: COMEDI subdevice.
42e558399 Ian Abbott  2015-09-21  634   * @range: Index of 
range within a range table.
42e558399 Ian Abbott  2015-09-21  635   *
42e558399 Ian Abbott  2015-09-21  636   * Tests whether a range 
is bipolar by checking whether its minimum value
42e558399 Ian Abbott  2015-09-21  637   * is negative.

:: The code at line 629 was first introduced by commit
:: ed9eccbe8970f6eedc1b978c157caf1251a896d4 Staging: add comedi core

:: TO: David Schleef 
:: CC: Greg Kroah-Hartman 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH v3 1/1] perf tools: fix perf build with ARCH=x86_64

[Jiada Wang]

Hello Jiri

On 04/09/2017 10:27 AM, Jiri Olsa wrote:

On Tue, Apr 04, 2017 at 11:25:44PM -0700, jiada_w...@mentor.com wrote:

From: Jiada Wang

with commit: 0a943cb10ce78 (tools build: Add HOSTARCH Makefile variable)
the following build failure is seen when build with ARCH=x86_64

is that described somewhere as a valid building interface?
I never use it so I have no idea.. would you describe your
build env/process?

I used "ARCH=x86_64 make -C tools perf V=1" to build perf for x86_64 ARCH.


In file included from util/event.c:2:0:
 tools/include/uapi/linux/mman.h:4:27: fatal error: uapi/asm/mman.h: No 
such file or directory
 compilation terminated.

fix this issue by use SRCARCH instead of ARCH in perf.

please describe also the the issue itself in the changelog, not just the fix

I will update changelog with detail information about the issue in v4



so objtool is using SRCARCH this way, I guess it's fine

if we go this way, you also need to change the pmu-events/Build
and there's some comment using $(ARCH) in util/header.c

will update pmu-events/Build in v4

thanks,
jirka

Thanks,
Jiada

Re: [PATCH v3 1/1] perf tools: fix perf build with ARCH=x86_64

[Jiada Wang]

Hello Jiri

On 04/09/2017 10:27 AM, Jiri Olsa wrote:

On Tue, Apr 04, 2017 at 11:25:44PM -0700, jiada_w...@mentor.com wrote:

From: Jiada Wang

with commit: 0a943cb10ce78 (tools build: Add HOSTARCH Makefile variable)
the following build failure is seen when build with ARCH=x86_64

is that described somewhere as a valid building interface?
I never use it so I have no idea.. would you describe your
build env/process?

I used "ARCH=x86_64 make -C tools perf V=1" to build perf for x86_64 ARCH.


In file included from util/event.c:2:0:
 tools/include/uapi/linux/mman.h:4:27: fatal error: uapi/asm/mman.h: No 
such file or directory
 compilation terminated.

fix this issue by use SRCARCH instead of ARCH in perf.

please describe also the the issue itself in the changelog, not just the fix

I will update changelog with detail information about the issue in v4



so objtool is using SRCARCH this way, I guess it's fine

if we go this way, you also need to change the pmu-events/Build
and there's some comment using $(ARCH) in util/header.c

will update pmu-events/Build in v4

thanks,
jirka

Thanks,
Jiada

RE: [PATCH v4 0/9] Renesas RZ/A1 pin and gpio controller

[Chris Brandt]

Hi Jacopo,

On Wednesday, April 05, 2017, Jacopo Mondi wrote:
> v3 -> v4:
> - use "pinmux" property in pmx sub-nodes in place of "renesas,pins"
> - use pinconf standard properties to set pin mux additional flags
> - add "bi-directional" and "output-enable" to pinconf generic properties
> - perform pmx function parsing at dt_node_to_map() time
> - change DT bindings to use GENERIC_PINCONF
> - change DT bindings to allow sub-nodes to have "pinmux" property
> specified
> - several renames (register names, DT parse functions, set_mux() function)


I just tested this driver on the RZ/A1 RSK board.
The following worked good.

   SCIF2, I2C, SDHI, Ethernet


SDHI also has bi-direction pins. For your reference, here was my DT:


/* SHDI ch1 on CN1 */
sdhi1_pins: sdhi1 {
pins {
pinmux = ,/* SD_CD_1 */
 ,/* SD_WP_1 */
 ,   /* SD_CLK_1 */
 ;   /* SD_CMD_1 */
};

pins_bidir {
pinmux = ,   /* SD_D1_1 */
 ,   /* SD_D0_1 */
 ,   /* SD_D3_1 */
 ;   /* SD_D2_1 */
bi-directional;
};
};


Thanks,
Chris

RE: [PATCH v4 0/9] Renesas RZ/A1 pin and gpio controller

[Chris Brandt]

Hi Jacopo,

On Wednesday, April 05, 2017, Jacopo Mondi wrote:
> v3 -> v4:
> - use "pinmux" property in pmx sub-nodes in place of "renesas,pins"
> - use pinconf standard properties to set pin mux additional flags
> - add "bi-directional" and "output-enable" to pinconf generic properties
> - perform pmx function parsing at dt_node_to_map() time
> - change DT bindings to use GENERIC_PINCONF
> - change DT bindings to allow sub-nodes to have "pinmux" property
> specified
> - several renames (register names, DT parse functions, set_mux() function)


I just tested this driver on the RZ/A1 RSK board.
The following worked good.

   SCIF2, I2C, SDHI, Ethernet


SDHI also has bi-direction pins. For your reference, here was my DT:


/* SHDI ch1 on CN1 */
sdhi1_pins: sdhi1 {
pins {
pinmux = ,/* SD_CD_1 */
 ,/* SD_WP_1 */
 ,   /* SD_CLK_1 */
 ;   /* SD_CMD_1 */
};

pins_bidir {
pinmux = ,   /* SD_D1_1 */
 ,   /* SD_D0_1 */
 ,   /* SD_D3_1 */
 ;   /* SD_D2_1 */
bi-directional;
};
};


Thanks,
Chris

Re: [patch 1/3] mm: protect set_page_dirty() from ongoing truncation

[alexander . levin]

On Fri, Dec 05, 2014 at 09:52:44AM -0500, Johannes Weiner wrote:
> Tejun, while reviewing the code, spotted the following race condition
> between the dirtying and truncation of a page:
> 
> __set_page_dirty_nobuffers()   __delete_from_page_cache()
>   if (TestSetPageDirty(page))
>  page->mapping = NULL
>if (PageDirty())
>  dec_zone_page_state(page, NR_FILE_DIRTY);
>  dec_bdi_stat(mapping->backing_dev_info, 
> BDI_RECLAIMABLE);
> if (page->mapping)
>   account_page_dirtied(page)
> __inc_zone_page_state(page, NR_FILE_DIRTY);
>   __inc_bdi_stat(mapping->backing_dev_info, BDI_RECLAIMABLE);
> 
> which results in an imbalance of NR_FILE_DIRTY and BDI_RECLAIMABLE.
> 
> Dirtiers usually lock out truncation, either by holding the page lock
> directly, or in case of zap_pte_range(), by pinning the mapcount with
> the page table lock held.  The notable exception to this rule, though,
> is do_wp_page(), for which this race exists.  However, do_wp_page()
> already waits for a locked page to unlock before setting the dirty
> bit, in order to prevent a race where clear_page_dirty() misses the
> page bit in the presence of dirty ptes.  Upgrade that wait to a fully
> locked set_page_dirty() to also cover the situation explained above.
> 
> Afterwards, the code in set_page_dirty() dealing with a truncation
> race is no longer needed.  Remove it.
> 
> Reported-by: Tejun Heo 
> Signed-off-by: Johannes Weiner 
> Cc: 
> Acked-by: Kirill A. Shutemov 

Hi Johannes,

I'm seeing the following while fuzzing with trinity on linux-next (I've changed
the WARN to a VM_BUG_ON_PAGE for some extra page info).

[   18.991007] page:ea000307c8c0 count:3 mapcount:0 
mapping:88010444cbf8 index:0x1^M
[   18.993051] flags: 0x1fffc11(locked|dirty)^M
[   18.993621] raw: 01fffc11 88010444cbf8 0001 
0003^M
[   18.994522] raw: dead0100 dead0200  
880109c38008^M  
   [   18.995418] page dumped because: VM_BUG_ON_PAGE(!PagePrivate(page) && 
!PageUptodate(page))^M
[   18.996381] page->mem_cgroup:880109c38008^M  
  [ 
  18.996935] [ cut here ]^M 
[   
18.997483] kernel BUG at mm/page-writeback.c:2486!^M
  [   
18.998063] invalid opcode:  [#1] SMP DEBUG_PAGEALLOC KASAN^M
[   18.998756] Modules linked in:^M 
  [ 
  18.999129] CPU: 5 PID: 1388 Comm: trinity-c34 Not tainted 
4.11.0-rc5-next-20170407-dirty #12^M
[   19.000117] task: 880106ee5d40 task.stack: 
8800c0f4^M  
[   19.000828] RIP: 0010:__set_page_dirty_nobuffers 
(??:?)
[   19.001491] RSP: 0018:8800c0f47318 EFLAGS: 00010006^M
[   19.002103] RAX:  RBX: 1100181e8e67 RCX: 
^M
[   19.002929] RDX: 0021 RSI: 1100181e8da7 RDI: 
ed00181e8e58^M
[   19.004806] RBP: 8800c0f47440 R08: 3830303833633930 R09: 
31303838^M
[   19.005626] R10: dc00 R11: 1491 R12: 
8800c0f47418^M
[   19.006452] R13: ea000307c8c0 R14: 88010444cc10 R15: 
88010444cbf8^M
[   19.007277] FS:  7ff6a26fb700() GS:88010a34() 
knlGS:^M
[   19.008424] CS:  0010 DS:  ES:  CR0: 80050033^M
[   19.009092] CR2: 7ff6a155267c CR3: cb301000 CR4: 
000406a0^M
[   19.009919] Call Trace:^M
[   19.012266] set_page_dirty (mm/page-writeback.c:2579)
[   19.020028] v9fs_write_end (fs/9p/vfs_addr.c:325)
[   19.022473] generic_perform_write (mm/filemap.c:2842)
[   19.024857] __generic_file_write_iter (mm/filemap.c:2957)
[   19.025830] generic_file_write_iter (./include/linux/fs.h:702 
mm/filemap.c:2985)
[   19.028549] __do_readv_writev (./include/linux/fs.h:1734 fs/read_write.c:696 
fs/read_write.c:862)
[   19.029924] do_readv_writev (fs/read_write.c:895)
[   19.034044] vfs_writev (fs/read_write.c:921)
[   19.035223] do_writev (fs/read_write.c:955)
[   19.036925] SyS_writev (fs/read_write.c:1024)
[   19.037297] do_syscall_64 (arch/x86/entry/common.c:284)
[   19.042085] entry_SYSCALL64_slow_path (arch/x86/entry/entry_64.S:249)
 

Re: [patch 1/3] mm: protect set_page_dirty() from ongoing truncation

[alexander . levin]

On Fri, Dec 05, 2014 at 09:52:44AM -0500, Johannes Weiner wrote:
> Tejun, while reviewing the code, spotted the following race condition
> between the dirtying and truncation of a page:
> 
> __set_page_dirty_nobuffers()   __delete_from_page_cache()
>   if (TestSetPageDirty(page))
>  page->mapping = NULL
>if (PageDirty())
>  dec_zone_page_state(page, NR_FILE_DIRTY);
>  dec_bdi_stat(mapping->backing_dev_info, 
> BDI_RECLAIMABLE);
> if (page->mapping)
>   account_page_dirtied(page)
> __inc_zone_page_state(page, NR_FILE_DIRTY);
>   __inc_bdi_stat(mapping->backing_dev_info, BDI_RECLAIMABLE);
> 
> which results in an imbalance of NR_FILE_DIRTY and BDI_RECLAIMABLE.
> 
> Dirtiers usually lock out truncation, either by holding the page lock
> directly, or in case of zap_pte_range(), by pinning the mapcount with
> the page table lock held.  The notable exception to this rule, though,
> is do_wp_page(), for which this race exists.  However, do_wp_page()
> already waits for a locked page to unlock before setting the dirty
> bit, in order to prevent a race where clear_page_dirty() misses the
> page bit in the presence of dirty ptes.  Upgrade that wait to a fully
> locked set_page_dirty() to also cover the situation explained above.
> 
> Afterwards, the code in set_page_dirty() dealing with a truncation
> race is no longer needed.  Remove it.
> 
> Reported-by: Tejun Heo 
> Signed-off-by: Johannes Weiner 
> Cc: 
> Acked-by: Kirill A. Shutemov 

Hi Johannes,

I'm seeing the following while fuzzing with trinity on linux-next (I've changed
the WARN to a VM_BUG_ON_PAGE for some extra page info).

[   18.991007] page:ea000307c8c0 count:3 mapcount:0 
mapping:88010444cbf8 index:0x1^M
[   18.993051] flags: 0x1fffc11(locked|dirty)^M
[   18.993621] raw: 01fffc11 88010444cbf8 0001 
0003^M
[   18.994522] raw: dead0100 dead0200  
880109c38008^M  
   [   18.995418] page dumped because: VM_BUG_ON_PAGE(!PagePrivate(page) && 
!PageUptodate(page))^M
[   18.996381] page->mem_cgroup:880109c38008^M  
  [ 
  18.996935] [ cut here ]^M 
[   
18.997483] kernel BUG at mm/page-writeback.c:2486!^M
  [   
18.998063] invalid opcode:  [#1] SMP DEBUG_PAGEALLOC KASAN^M
[   18.998756] Modules linked in:^M 
  [ 
  18.999129] CPU: 5 PID: 1388 Comm: trinity-c34 Not tainted 
4.11.0-rc5-next-20170407-dirty #12^M
[   19.000117] task: 880106ee5d40 task.stack: 
8800c0f4^M  
[   19.000828] RIP: 0010:__set_page_dirty_nobuffers 
(??:?)
[   19.001491] RSP: 0018:8800c0f47318 EFLAGS: 00010006^M
[   19.002103] RAX:  RBX: 1100181e8e67 RCX: 
^M
[   19.002929] RDX: 0021 RSI: 1100181e8da7 RDI: 
ed00181e8e58^M
[   19.004806] RBP: 8800c0f47440 R08: 3830303833633930 R09: 
31303838^M
[   19.005626] R10: dc00 R11: 1491 R12: 
8800c0f47418^M
[   19.006452] R13: ea000307c8c0 R14: 88010444cc10 R15: 
88010444cbf8^M
[   19.007277] FS:  7ff6a26fb700() GS:88010a34() 
knlGS:^M
[   19.008424] CS:  0010 DS:  ES:  CR0: 80050033^M
[   19.009092] CR2: 7ff6a155267c CR3: cb301000 CR4: 
000406a0^M
[   19.009919] Call Trace:^M
[   19.012266] set_page_dirty (mm/page-writeback.c:2579)
[   19.020028] v9fs_write_end (fs/9p/vfs_addr.c:325)
[   19.022473] generic_perform_write (mm/filemap.c:2842)
[   19.024857] __generic_file_write_iter (mm/filemap.c:2957)
[   19.025830] generic_file_write_iter (./include/linux/fs.h:702 
mm/filemap.c:2985)
[   19.028549] __do_readv_writev (./include/linux/fs.h:1734 fs/read_write.c:696 
fs/read_write.c:862)
[   19.029924] do_readv_writev (fs/read_write.c:895)
[   19.034044] vfs_writev (fs/read_write.c:921)
[   19.035223] do_writev (fs/read_write.c:955)
[   19.036925] SyS_writev (fs/read_write.c:1024)
[   19.037297] do_syscall_64 (arch/x86/entry/common.c:284)
[   19.042085] entry_SYSCALL64_slow_path (arch/x86/entry/entry_64.S:249)
  [ 
  19.042608] RIP: 0033:0x7ff6a200a8e9^M   

[PATCH] NFS: fix usage of mempools.

[NeilBrown]

When passed GFP flags that allow sleeping (such as
GFP_NOIO), mempool_alloc() will never return NULL, it will
wait until memory is available.

This means that we don't need to handle failure, but that we
do need to ensure one thread doesn't call mempool_alloc()
twice on the one pool without queuing or freeing the first
allocation.  If multiple threads did this during times of
high memory pressure, the pool could be exhausted and a
deadlock could result.

pnfs_generic_alloc_ds_commits() attempts to allocate from
the nfs_commit_mempool while already holding an allocation
from that pool.  This is not safe.  So change
nfs_commitdata_alloc() to take a flag that indicates whether
failure is acceptable.

In pnfs_generic_alloc_ds_commits(), accept failure and
handle it as we currently do.  Else where, do not accept
failure, and do not handle it.

Even when failure is acceptable, we want to succeed if
possible.  That means both
 - using an entry from the pool if there is one
 - waiting for direct reclaim is there isn't.

We call mempool_alloc(GFP_NOWAIT) to achieve the first, then
kmem_cache_alloc(GFP_NOIO|__GFP_NORETRY) to achieve the
second.  Each of these can fail, but together they do the
best they can without blocking indefinitely.

Also, don't test for failure when allocating from
nfs_wdata_mempool.

Signed-off-by: NeilBrown 
---
 fs/nfs/pnfs_nfs.c  | 16 +---
 fs/nfs/write.c | 35 +--
 include/linux/nfs_fs.h |  2 +-
 3 files changed, 27 insertions(+), 26 deletions(-)

diff --git a/fs/nfs/pnfs_nfs.c b/fs/nfs/pnfs_nfs.c
index 7250b95549ec..1edf5b84aba5 100644
--- a/fs/nfs/pnfs_nfs.c
+++ b/fs/nfs/pnfs_nfs.c
@@ -217,7 +217,7 @@ pnfs_generic_alloc_ds_commits(struct nfs_commit_info *cinfo,
for (i = 0; i < fl_cinfo->nbuckets; i++, bucket++) {
if (list_empty(>committing))
continue;
-   data = nfs_commitdata_alloc();
+   data = nfs_commitdata_alloc(false);
if (!data)
break;
data->ds_commit_index = i;
@@ -283,16 +283,10 @@ pnfs_generic_commit_pagelist(struct inode *inode, struct 
list_head *mds_pages,
unsigned int nreq = 0;
 
if (!list_empty(mds_pages)) {
-   data = nfs_commitdata_alloc();
-   if (data != NULL) {
-   data->ds_commit_index = -1;
-   list_add(>pages, );
-   nreq++;
-   } else {
-   nfs_retry_commit(mds_pages, NULL, cinfo, 0);
-   pnfs_generic_retry_commit(cinfo, 0);
-   return -ENOMEM;
-   }
+   data = nfs_commitdata_alloc(true);
+   data->ds_commit_index = -1;
+   list_add(>pages, );
+   nreq++;
}
 
nreq += pnfs_generic_alloc_ds_commits(cinfo, );
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index abb2c8a3be42..bdfe5a7c5874 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -60,14 +60,28 @@ static mempool_t *nfs_wdata_mempool;
 static struct kmem_cache *nfs_cdata_cachep;
 static mempool_t *nfs_commit_mempool;
 
-struct nfs_commit_data *nfs_commitdata_alloc(void)
+struct nfs_commit_data *nfs_commitdata_alloc(bool never_fail)
 {
-   struct nfs_commit_data *p = mempool_alloc(nfs_commit_mempool, GFP_NOIO);
+   struct nfs_commit_data *p;
 
-   if (p) {
-   memset(p, 0, sizeof(*p));
-   INIT_LIST_HEAD(>pages);
+   if (never_fail)
+   p = mempool_alloc(nfs_commit_mempool, GFP_NOIO);
+   else {
+   /* It is OK to do some reclaim, not no safe to wait
+* for anything to be returned to the pool.
+* mempool_alloc() cannot handle that particular combination,
+* so we need two separate attempts.
+*/
+   p = mempool_alloc(nfs_commit_mempool, GFP_NOWAIT);
+   if (!p)
+   p = kmem_cache_alloc(nfs_cdata_cachep, GFP_NOIO |
+__GFP_NOWARN | __GFP_NORETRY);
+   if (!p)
+   return NULL;
}
+
+   memset(p, 0, sizeof(*p));
+   INIT_LIST_HEAD(>pages);
return p;
 }
 EXPORT_SYMBOL_GPL(nfs_commitdata_alloc);
@@ -82,8 +96,7 @@ static struct nfs_pgio_header *nfs_writehdr_alloc(void)
 {
struct nfs_pgio_header *p = mempool_alloc(nfs_wdata_mempool, GFP_NOIO);
 
-   if (p)
-   memset(p, 0, sizeof(*p));
+   memset(p, 0, sizeof(*p));
return p;
 }
 
@@ -1705,19 +1718,13 @@ nfs_commit_list(struct inode *inode, struct list_head 
*head, int how,
if (list_empty(head))
return 0;
 
-   data = nfs_commitdata_alloc();
-
-   if (!data)
-   goto out_bad;
+   data = nfs_commitdata_alloc(true);
 
/* Set up the argument struct */

[PATCH] NFS: fix usage of mempools.

[NeilBrown]

When passed GFP flags that allow sleeping (such as
GFP_NOIO), mempool_alloc() will never return NULL, it will
wait until memory is available.

This means that we don't need to handle failure, but that we
do need to ensure one thread doesn't call mempool_alloc()
twice on the one pool without queuing or freeing the first
allocation.  If multiple threads did this during times of
high memory pressure, the pool could be exhausted and a
deadlock could result.

pnfs_generic_alloc_ds_commits() attempts to allocate from
the nfs_commit_mempool while already holding an allocation
from that pool.  This is not safe.  So change
nfs_commitdata_alloc() to take a flag that indicates whether
failure is acceptable.

In pnfs_generic_alloc_ds_commits(), accept failure and
handle it as we currently do.  Else where, do not accept
failure, and do not handle it.

Even when failure is acceptable, we want to succeed if
possible.  That means both
 - using an entry from the pool if there is one
 - waiting for direct reclaim is there isn't.

We call mempool_alloc(GFP_NOWAIT) to achieve the first, then
kmem_cache_alloc(GFP_NOIO|__GFP_NORETRY) to achieve the
second.  Each of these can fail, but together they do the
best they can without blocking indefinitely.

Also, don't test for failure when allocating from
nfs_wdata_mempool.

Signed-off-by: NeilBrown 
---
 fs/nfs/pnfs_nfs.c  | 16 +---
 fs/nfs/write.c | 35 +--
 include/linux/nfs_fs.h |  2 +-
 3 files changed, 27 insertions(+), 26 deletions(-)

diff --git a/fs/nfs/pnfs_nfs.c b/fs/nfs/pnfs_nfs.c
index 7250b95549ec..1edf5b84aba5 100644
--- a/fs/nfs/pnfs_nfs.c
+++ b/fs/nfs/pnfs_nfs.c
@@ -217,7 +217,7 @@ pnfs_generic_alloc_ds_commits(struct nfs_commit_info *cinfo,
for (i = 0; i < fl_cinfo->nbuckets; i++, bucket++) {
if (list_empty(>committing))
continue;
-   data = nfs_commitdata_alloc();
+   data = nfs_commitdata_alloc(false);
if (!data)
break;
data->ds_commit_index = i;
@@ -283,16 +283,10 @@ pnfs_generic_commit_pagelist(struct inode *inode, struct 
list_head *mds_pages,
unsigned int nreq = 0;
 
if (!list_empty(mds_pages)) {
-   data = nfs_commitdata_alloc();
-   if (data != NULL) {
-   data->ds_commit_index = -1;
-   list_add(>pages, );
-   nreq++;
-   } else {
-   nfs_retry_commit(mds_pages, NULL, cinfo, 0);
-   pnfs_generic_retry_commit(cinfo, 0);
-   return -ENOMEM;
-   }
+   data = nfs_commitdata_alloc(true);
+   data->ds_commit_index = -1;
+   list_add(>pages, );
+   nreq++;
}
 
nreq += pnfs_generic_alloc_ds_commits(cinfo, );
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index abb2c8a3be42..bdfe5a7c5874 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -60,14 +60,28 @@ static mempool_t *nfs_wdata_mempool;
 static struct kmem_cache *nfs_cdata_cachep;
 static mempool_t *nfs_commit_mempool;
 
-struct nfs_commit_data *nfs_commitdata_alloc(void)
+struct nfs_commit_data *nfs_commitdata_alloc(bool never_fail)
 {
-   struct nfs_commit_data *p = mempool_alloc(nfs_commit_mempool, GFP_NOIO);
+   struct nfs_commit_data *p;
 
-   if (p) {
-   memset(p, 0, sizeof(*p));
-   INIT_LIST_HEAD(>pages);
+   if (never_fail)
+   p = mempool_alloc(nfs_commit_mempool, GFP_NOIO);
+   else {
+   /* It is OK to do some reclaim, not no safe to wait
+* for anything to be returned to the pool.
+* mempool_alloc() cannot handle that particular combination,
+* so we need two separate attempts.
+*/
+   p = mempool_alloc(nfs_commit_mempool, GFP_NOWAIT);
+   if (!p)
+   p = kmem_cache_alloc(nfs_cdata_cachep, GFP_NOIO |
+__GFP_NOWARN | __GFP_NORETRY);
+   if (!p)
+   return NULL;
}
+
+   memset(p, 0, sizeof(*p));
+   INIT_LIST_HEAD(>pages);
return p;
 }
 EXPORT_SYMBOL_GPL(nfs_commitdata_alloc);
@@ -82,8 +96,7 @@ static struct nfs_pgio_header *nfs_writehdr_alloc(void)
 {
struct nfs_pgio_header *p = mempool_alloc(nfs_wdata_mempool, GFP_NOIO);
 
-   if (p)
-   memset(p, 0, sizeof(*p));
+   memset(p, 0, sizeof(*p));
return p;
 }
 
@@ -1705,19 +1718,13 @@ nfs_commit_list(struct inode *inode, struct list_head 
*head, int how,
if (list_empty(head))
return 0;
 
-   data = nfs_commitdata_alloc();
-
-   if (!data)
-   goto out_bad;
+   data = nfs_commitdata_alloc(true);
 
/* Set up the argument struct */
nfs_init_commit(data, head, 

[PATCH] sunrpc: don't check for failure from mempool_alloc()

[NeilBrown]

When mempool_alloc() is allowed to sleep (GFP_NOIO allows
sleeping) it cannot fail.
So rpc_alloc_task() cannot fail, so rpc_new_task doesn't need
to test for failure.
Consequently rpc_new_task() cannot fail, so the callers
don't need to test.

Signed-off-by: NeilBrown 
---
 net/sunrpc/clnt.c  | 8 
 net/sunrpc/sched.c | 5 -
 2 files changed, 13 deletions(-)

diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index 52da3ce54bb5..b5cb921775a0 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -1042,8 +1042,6 @@ struct rpc_task *rpc_run_task(const struct rpc_task_setup 
*task_setup_data)
struct rpc_task *task;
 
task = rpc_new_task(task_setup_data);
-   if (IS_ERR(task))
-   goto out;
 
rpc_task_set_client(task, task_setup_data->rpc_client);
rpc_task_set_rpc_message(task, task_setup_data->rpc_message);
@@ -1053,7 +1051,6 @@ struct rpc_task *rpc_run_task(const struct rpc_task_setup 
*task_setup_data)
 
atomic_inc(>tk_count);
rpc_execute(task);
-out:
return task;
 }
 EXPORT_SYMBOL_GPL(rpc_run_task);
@@ -1140,10 +1137,6 @@ struct rpc_task *rpc_run_bc_task(struct rpc_rqst *req)
 * Create an rpc_task to send the data
 */
task = rpc_new_task(_setup_data);
-   if (IS_ERR(task)) {
-   xprt_free_bc_request(req);
-   goto out;
-   }
task->tk_rqstp = req;
 
/*
@@ -1158,7 +1151,6 @@ struct rpc_task *rpc_run_bc_task(struct rpc_rqst *req)
WARN_ON_ONCE(atomic_read(>tk_count) != 2);
rpc_execute(task);
 
-out:
dprintk("RPC: rpc_run_bc_task: task= %p\n", task);
return task;
 }
diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c
index 5db68b371db2..0cc83839c13c 100644
--- a/net/sunrpc/sched.c
+++ b/net/sunrpc/sched.c
@@ -965,11 +965,6 @@ struct rpc_task *rpc_new_task(const struct rpc_task_setup 
*setup_data)
 
if (task == NULL) {
task = rpc_alloc_task();
-   if (task == NULL) {
-   rpc_release_calldata(setup_data->callback_ops,
-   setup_data->callback_data);
-   return ERR_PTR(-ENOMEM);
-   }
flags = RPC_TASK_DYNAMIC;
}
 
-- 
2.12.2



signature.asc
Description: PGP signature

[PATCH] sunrpc: don't check for failure from mempool_alloc()

[NeilBrown]

When mempool_alloc() is allowed to sleep (GFP_NOIO allows
sleeping) it cannot fail.
So rpc_alloc_task() cannot fail, so rpc_new_task doesn't need
to test for failure.
Consequently rpc_new_task() cannot fail, so the callers
don't need to test.

Signed-off-by: NeilBrown 
---
 net/sunrpc/clnt.c  | 8 
 net/sunrpc/sched.c | 5 -
 2 files changed, 13 deletions(-)

diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index 52da3ce54bb5..b5cb921775a0 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -1042,8 +1042,6 @@ struct rpc_task *rpc_run_task(const struct rpc_task_setup 
*task_setup_data)
struct rpc_task *task;
 
task = rpc_new_task(task_setup_data);
-   if (IS_ERR(task))
-   goto out;
 
rpc_task_set_client(task, task_setup_data->rpc_client);
rpc_task_set_rpc_message(task, task_setup_data->rpc_message);
@@ -1053,7 +1051,6 @@ struct rpc_task *rpc_run_task(const struct rpc_task_setup 
*task_setup_data)
 
atomic_inc(>tk_count);
rpc_execute(task);
-out:
return task;
 }
 EXPORT_SYMBOL_GPL(rpc_run_task);
@@ -1140,10 +1137,6 @@ struct rpc_task *rpc_run_bc_task(struct rpc_rqst *req)
 * Create an rpc_task to send the data
 */
task = rpc_new_task(_setup_data);
-   if (IS_ERR(task)) {
-   xprt_free_bc_request(req);
-   goto out;
-   }
task->tk_rqstp = req;
 
/*
@@ -1158,7 +1151,6 @@ struct rpc_task *rpc_run_bc_task(struct rpc_rqst *req)
WARN_ON_ONCE(atomic_read(>tk_count) != 2);
rpc_execute(task);
 
-out:
dprintk("RPC: rpc_run_bc_task: task= %p\n", task);
return task;
 }
diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c
index 5db68b371db2..0cc83839c13c 100644
--- a/net/sunrpc/sched.c
+++ b/net/sunrpc/sched.c
@@ -965,11 +965,6 @@ struct rpc_task *rpc_new_task(const struct rpc_task_setup 
*setup_data)
 
if (task == NULL) {
task = rpc_alloc_task();
-   if (task == NULL) {
-   rpc_release_calldata(setup_data->callback_ops,
-   setup_data->callback_data);
-   return ERR_PTR(-ENOMEM);
-   }
flags = RPC_TASK_DYNAMIC;
}
 
-- 
2.12.2



signature.asc
Description: PGP signature

[PATCH 09/11] f2fs: Remove __GFP_NOFAIL flag from call to mempool_alloc()

[NeilBrown]

Passing __GFP_NOFAIL to mempool_alloc() is strange
because it bypasses the pool functionality provided
by the mempool.  mempool_alloc() will not fail
even without the NOFAIL flag.

So remove the flag and allow the pool to be used properly.

Signed-off-by: NeilBrown 
---
 fs/f2fs/data.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 1602b4bccae6..7e31751ec708 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -204,7 +204,7 @@ static inline void __submit_bio(struct f2fs_sb_info *sbi,
for (; start < F2FS_IO_SIZE(sbi); start++) {
struct page *page =
mempool_alloc(sbi->write_io_dummy,
-   GFP_NOIO | __GFP_ZERO | __GFP_NOFAIL);
+   GFP_NOIO | __GFP_ZERO);
f2fs_bug_on(sbi, !page);
 
SetPagePrivate(page);
-- 
2.12.2



signature.asc
Description: PGP signature

[PATCH 09/11] f2fs: Remove __GFP_NOFAIL flag from call to mempool_alloc()

[NeilBrown]

Passing __GFP_NOFAIL to mempool_alloc() is strange
because it bypasses the pool functionality provided
by the mempool.  mempool_alloc() will not fail
even without the NOFAIL flag.

So remove the flag and allow the pool to be used properly.

Signed-off-by: NeilBrown 
---
 fs/f2fs/data.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 1602b4bccae6..7e31751ec708 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -204,7 +204,7 @@ static inline void __submit_bio(struct f2fs_sb_info *sbi,
for (; start < F2FS_IO_SIZE(sbi); start++) {
struct page *page =
mempool_alloc(sbi->write_io_dummy,
-   GFP_NOIO | __GFP_ZERO | __GFP_NOFAIL);
+   GFP_NOIO | __GFP_ZERO);
f2fs_bug_on(sbi, !page);
 
SetPagePrivate(page);
-- 
2.12.2



signature.asc
Description: PGP signature

[PATCH] virtio_scsi: don't check for failure from mempool_alloc()

[NeilBrown]

mempool_alloc() cannot fail when passed GFP_NOIO or any
other gfp setting that is permitted to sleep.
So remove this pointless code.

Signed-off-by: NeilBrown 
---
 drivers/scsi/virtio_scsi.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 939c47df73fa..7c2a5f7c5fb7 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -688,9 +688,6 @@ static int virtscsi_device_reset(struct scsi_cmnd *sc)
 
sdev_printk(KERN_INFO, sc->device, "device reset\n");
cmd = mempool_alloc(virtscsi_cmd_pool, GFP_NOIO);
-   if (!cmd)
-   return FAILED;
-
memset(cmd, 0, sizeof(*cmd));
cmd->sc = sc;
cmd->req.tmf = (struct virtio_scsi_ctrl_tmf_req){
@@ -725,9 +722,6 @@ static int virtscsi_abort(struct scsi_cmnd *sc)
 
scmd_printk(KERN_INFO, sc, "abort\n");
cmd = mempool_alloc(virtscsi_cmd_pool, GFP_NOIO);
-   if (!cmd)
-   return FAILED;
-
memset(cmd, 0, sizeof(*cmd));
cmd->sc = sc;
cmd->req.tmf = (struct virtio_scsi_ctrl_tmf_req){
-- 
2.12.2



signature.asc
Description: PGP signature

[PATCH] virtio_scsi: don't check for failure from mempool_alloc()

[NeilBrown]

mempool_alloc() cannot fail when passed GFP_NOIO or any
other gfp setting that is permitted to sleep.
So remove this pointless code.

Signed-off-by: NeilBrown 
---
 drivers/scsi/virtio_scsi.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 939c47df73fa..7c2a5f7c5fb7 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -688,9 +688,6 @@ static int virtscsi_device_reset(struct scsi_cmnd *sc)
 
sdev_printk(KERN_INFO, sc->device, "device reset\n");
cmd = mempool_alloc(virtscsi_cmd_pool, GFP_NOIO);
-   if (!cmd)
-   return FAILED;
-
memset(cmd, 0, sizeof(*cmd));
cmd->sc = sc;
cmd->req.tmf = (struct virtio_scsi_ctrl_tmf_req){
@@ -725,9 +722,6 @@ static int virtscsi_abort(struct scsi_cmnd *sc)
 
scmd_printk(KERN_INFO, sc, "abort\n");
cmd = mempool_alloc(virtscsi_cmd_pool, GFP_NOIO);
-   if (!cmd)
-   return FAILED;
-
memset(cmd, 0, sizeof(*cmd));
cmd->sc = sc;
cmd->req.tmf = (struct virtio_scsi_ctrl_tmf_req){
-- 
2.12.2



signature.asc
Description: PGP signature

Re: [PATCH v2] perf: fix double free at function perf_hpp__reset_output_field

[Du, Changbin]

On Sun, Apr 09, 2017 at 07:05:52PM +0200, Jiri Olsa wrote:
> On Wed, Apr 05, 2017 at 10:44:22AM +0800, Du, Changbin wrote:
> > On Tue, Apr 04, 2017 at 12:51:03PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Wed, Apr 05, 2017 at 12:34:59AM +0900, Namhyung Kim escreveu:
> > > > Hi Arnaldo,
> > > > 
> > > > On Wed, Apr 5, 2017 at 12:19 AM, Arnaldo Carvalho de Melo
> > > >  wrote:
> > > > > Em Mon, Mar 27, 2017 at 02:22:55PM +0800, changbin...@intel.com 
> > > > > escreveu:
> > > > >> From: Changbin Du 
> > > > >>
> > > > >> Some perf_hpp_fmt both registered at field and sort list. For such
> > > > >> instance, we only can free it when removed from the both lists. This
> > > > >> function currently only used by self-test code, but still should fix
> > > > >> it.
> > > > >
> > > > > Looks sane, applying,
> > > > >
> > > > > Jiri, Namhyung, please holler (or ack) if needed,
> > > > 
> > > > Did you actually see the double free problem?  AFAICS the old code
> > > 
> > > I assumed that he had seen it, in some self-test code, Changbin, can you
> > > please show command output or further describe when this patch would be
> > > necessary?
> > > 
> > Arnaldo, I did observe this issue but not in self-test code. The self-test 
> > code
> > uses that function but does not have a case that a fmt linked to two both 
> > list. 
> > I found this issue when I try to add 'dynamic sort' feature to perf, which
> > I use this function to reset out fields.
> 
> could you post it with the rest of your patches? might be easier to review
>
jirka, I am sorry that the 'dynamic sort' is only half done. Now I am
very busy with work at hand. I will send the rest of patches when I
finish them. Could we check out this fix first?

> thanks,
> jirka

-- 
Thanks,
Changbin Du


signature.asc
Description: PGP signature

Re: [PATCH v2] perf: fix double free at function perf_hpp__reset_output_field

[Du, Changbin]

On Sun, Apr 09, 2017 at 07:05:52PM +0200, Jiri Olsa wrote:
> On Wed, Apr 05, 2017 at 10:44:22AM +0800, Du, Changbin wrote:
> > On Tue, Apr 04, 2017 at 12:51:03PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Wed, Apr 05, 2017 at 12:34:59AM +0900, Namhyung Kim escreveu:
> > > > Hi Arnaldo,
> > > > 
> > > > On Wed, Apr 5, 2017 at 12:19 AM, Arnaldo Carvalho de Melo
> > > >  wrote:
> > > > > Em Mon, Mar 27, 2017 at 02:22:55PM +0800, changbin...@intel.com 
> > > > > escreveu:
> > > > >> From: Changbin Du 
> > > > >>
> > > > >> Some perf_hpp_fmt both registered at field and sort list. For such
> > > > >> instance, we only can free it when removed from the both lists. This
> > > > >> function currently only used by self-test code, but still should fix
> > > > >> it.
> > > > >
> > > > > Looks sane, applying,
> > > > >
> > > > > Jiri, Namhyung, please holler (or ack) if needed,
> > > > 
> > > > Did you actually see the double free problem?  AFAICS the old code
> > > 
> > > I assumed that he had seen it, in some self-test code, Changbin, can you
> > > please show command output or further describe when this patch would be
> > > necessary?
> > > 
> > Arnaldo, I did observe this issue but not in self-test code. The self-test 
> > code
> > uses that function but does not have a case that a fmt linked to two both 
> > list. 
> > I found this issue when I try to add 'dynamic sort' feature to perf, which
> > I use this function to reset out fields.
> 
> could you post it with the rest of your patches? might be easier to review
>
jirka, I am sorry that the 'dynamic sort' is only half done. Now I am
very busy with work at hand. I will send the rest of patches when I
finish them. Could we check out this fix first?

> thanks,
> jirka

-- 
Thanks,
Changbin Du


signature.asc
Description: PGP signature

[PATCH] scsi: ibmvfc: don't check for failure from mempool_alloc()

[NeilBrown]

mempool_alloc() cannot fail when passed GFP_NOIO or any
other gfp setting that is permitted to sleep.
So remove this pointless code.

Signed-off-by: NeilBrown 
---
 drivers/scsi/ibmvscsi/ibmvfc.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 2c92dabb55f6..26cd3c28186a 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -3910,12 +3910,6 @@ static int ibmvfc_alloc_target(struct ibmvfc_host 
*vhost, u64 scsi_id)
spin_unlock_irqrestore(vhost->host->host_lock, flags);
 
tgt = mempool_alloc(vhost->tgt_pool, GFP_NOIO);
-   if (!tgt) {
-   dev_err(vhost->dev, "Target allocation failure for scsi id 
%08llx\n",
-   scsi_id);
-   return -ENOMEM;
-   }
-
memset(tgt, 0, sizeof(*tgt));
tgt->scsi_id = scsi_id;
tgt->new_scsi_id = scsi_id;
-- 
2.12.2



signature.asc
Description: PGP signature

[PATCH] scsi: ibmvfc: don't check for failure from mempool_alloc()

[NeilBrown]

mempool_alloc() cannot fail when passed GFP_NOIO or any
other gfp setting that is permitted to sleep.
So remove this pointless code.

Signed-off-by: NeilBrown 
---
 drivers/scsi/ibmvscsi/ibmvfc.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 2c92dabb55f6..26cd3c28186a 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -3910,12 +3910,6 @@ static int ibmvfc_alloc_target(struct ibmvfc_host 
*vhost, u64 scsi_id)
spin_unlock_irqrestore(vhost->host->host_lock, flags);
 
tgt = mempool_alloc(vhost->tgt_pool, GFP_NOIO);
-   if (!tgt) {
-   dev_err(vhost->dev, "Target allocation failure for scsi id 
%08llx\n",
-   scsi_id);
-   return -ENOMEM;
-   }
-
memset(tgt, 0, sizeof(*tgt));
tgt->scsi_id = scsi_id;
tgt->new_scsi_id = scsi_id;
-- 
2.12.2



signature.asc
Description: PGP signature

[PATCH] dm-verity-fec: don't check for failure from mempool_alloc(GFP_NOIO)

[NeilBrown]

mempool_alloc() cannot fail for GFP_NOIO allocation,
so there is no point testing for failure.

One place the code tested for failure was passing "0" as the GFP
flags.  This is most unusually and is probably meant to be GFP_NOIO,
so that is changed.

Allocation from ->extra_pool and ->prealloc_pool are repeated before
releasing the previous allocation.  This can deadlock if the code is
servicing a write under high memory pressure.  To avoid deadlocks,
change these to use GFP_NOWAIT and leave the error handling in place.

Signed-off-by: NeilBrown 
---
 drivers/md/dm-verity-fec.c | 21 +
 1 file changed, 5 insertions(+), 16 deletions(-)

diff --git a/drivers/md/dm-verity-fec.c b/drivers/md/dm-verity-fec.c
index 78f36012eaca..16e224fbd356 100644
--- a/drivers/md/dm-verity-fec.c
+++ b/drivers/md/dm-verity-fec.c
@@ -308,19 +308,14 @@ static int fec_alloc_bufs(struct dm_verity *v, struct 
dm_verity_fec_io *fio)
 {
unsigned n;
 
-   if (!fio->rs) {
-   fio->rs = mempool_alloc(v->fec->rs_pool, 0);
-   if (unlikely(!fio->rs)) {
-   DMERR("failed to allocate RS");
-   return -ENOMEM;
-   }
-   }
+   if (!fio->rs)
+   fio->rs = mempool_alloc(v->fec->rs_pool, GFP_NOIO);
 
fec_for_each_prealloc_buffer(n) {
if (fio->bufs[n])
continue;
 
-   fio->bufs[n] = mempool_alloc(v->fec->prealloc_pool, GFP_NOIO);
+   fio->bufs[n] = mempool_alloc(v->fec->prealloc_pool, GFP_NOWAIT);
if (unlikely(!fio->bufs[n])) {
DMERR("failed to allocate FEC buffer");
return -ENOMEM;
@@ -332,22 +327,16 @@ static int fec_alloc_bufs(struct dm_verity *v, struct 
dm_verity_fec_io *fio)
if (fio->bufs[n])
continue;
 
-   fio->bufs[n] = mempool_alloc(v->fec->extra_pool, GFP_NOIO);
+   fio->bufs[n] = mempool_alloc(v->fec->extra_pool, GFP_NOWAIT);
/* we can manage with even one buffer if necessary */
if (unlikely(!fio->bufs[n]))
break;
}
fio->nbufs = n;
 
-   if (!fio->output) {
+   if (!fio->output)
fio->output = mempool_alloc(v->fec->output_pool, GFP_NOIO);
 
-   if (!fio->output) {
-   DMERR("failed to allocate FEC page");
-   return -ENOMEM;
-   }
-   }
-
return 0;
 }
 
-- 
2.12.2



signature.asc
Description: PGP signature

[PATCH] dm-verity-fec: don't check for failure from mempool_alloc(GFP_NOIO)

[NeilBrown]

mempool_alloc() cannot fail for GFP_NOIO allocation,
so there is no point testing for failure.

One place the code tested for failure was passing "0" as the GFP
flags.  This is most unusually and is probably meant to be GFP_NOIO,
so that is changed.

Allocation from ->extra_pool and ->prealloc_pool are repeated before
releasing the previous allocation.  This can deadlock if the code is
servicing a write under high memory pressure.  To avoid deadlocks,
change these to use GFP_NOWAIT and leave the error handling in place.

Signed-off-by: NeilBrown 
---
 drivers/md/dm-verity-fec.c | 21 +
 1 file changed, 5 insertions(+), 16 deletions(-)

diff --git a/drivers/md/dm-verity-fec.c b/drivers/md/dm-verity-fec.c
index 78f36012eaca..16e224fbd356 100644
--- a/drivers/md/dm-verity-fec.c
+++ b/drivers/md/dm-verity-fec.c
@@ -308,19 +308,14 @@ static int fec_alloc_bufs(struct dm_verity *v, struct 
dm_verity_fec_io *fio)
 {
unsigned n;
 
-   if (!fio->rs) {
-   fio->rs = mempool_alloc(v->fec->rs_pool, 0);
-   if (unlikely(!fio->rs)) {
-   DMERR("failed to allocate RS");
-   return -ENOMEM;
-   }
-   }
+   if (!fio->rs)
+   fio->rs = mempool_alloc(v->fec->rs_pool, GFP_NOIO);
 
fec_for_each_prealloc_buffer(n) {
if (fio->bufs[n])
continue;
 
-   fio->bufs[n] = mempool_alloc(v->fec->prealloc_pool, GFP_NOIO);
+   fio->bufs[n] = mempool_alloc(v->fec->prealloc_pool, GFP_NOWAIT);
if (unlikely(!fio->bufs[n])) {
DMERR("failed to allocate FEC buffer");
return -ENOMEM;
@@ -332,22 +327,16 @@ static int fec_alloc_bufs(struct dm_verity *v, struct 
dm_verity_fec_io *fio)
if (fio->bufs[n])
continue;
 
-   fio->bufs[n] = mempool_alloc(v->fec->extra_pool, GFP_NOIO);
+   fio->bufs[n] = mempool_alloc(v->fec->extra_pool, GFP_NOWAIT);
/* we can manage with even one buffer if necessary */
if (unlikely(!fio->bufs[n]))
break;
}
fio->nbufs = n;
 
-   if (!fio->output) {
+   if (!fio->output)
fio->output = mempool_alloc(v->fec->output_pool, GFP_NOIO);
 
-   if (!fio->output) {
-   DMERR("failed to allocate FEC page");
-   return -ENOMEM;
-   }
-   }
-
return 0;
 }
 
-- 
2.12.2



signature.asc
Description: PGP signature

Re: linux-next: build failure after merge of the mfd tree

[Stephen Rothwell]

Hi all,

On Tue, 04 Apr 2017 15:31:15 +0300 Andy Shevchenko 
 wrote:
>
> On Tue, 2017-04-04 at 09:21 +0100, Lee Jones wrote:
> > On Tue, 04 Apr 2017, Lee Jones wrote:
> >   
> > > On Tue, 04 Apr 2017, Stephen Rothwell wrote:
> > >   
> > > > After merging the mfd tree, today's linux-next build (powerpc
> > > > allyesconfig) failed like this:
> > > > 
> > > > /home/sfr/next/next/drivers/mfd/intel_soc_pmic_bxtwc.c:25:31:
> > > > fatal error: asm/intel_pmc_ipc.h: No such file or directory
> > > > 
> > > > Caused by commit
> > > > 
> > > >   eb2a445f7d8f ("mfd: intel_soc_pmic: Fix a mess with compilation
> > > > units")
> > > > 
> > > > I have reverted that commit for today.  
> > > 
> > > Andy,
> > > 
> > > I'm pulling this commit.  Despite you thinking the error is unrelated
> > > to your patch, something is clearly wrong and I don't have time to
> > > investigate.
> > > 
> > > Ball is in your court.  
> > 
> > Okay, I've had a *very* quick looks.  
> 
> > Seems as if you should be depending on INTEL_PMC_IPC.  
> 
> As a quick fix, yes. As a proper fix the PMC/SCU mess should be fixed in
> a way to provide a header in include/platform_data/x86.
> 
> I will prepare v4.
> Thanks.

Ping?

-- 
Cheers,
Stephen Rothwell

[PATCH] dm-region-hash: fix strange usage of mempool_alloc.

[NeilBrown]

mempool_alloc() should only be called with GFP_ATOMIC when
it is not safe to wait. Passing __GFP_NOFAIL to kmalloc()
says that it is safe to wait indefinitely.  So this code is
inconsistent.

Clearly it is OK to wait indefinitely in this code, and
mempool_alloc() is able to do that.  So just use
mempool_alloc, and allow it to sleep.  If no memory is
available it will wait for something to be returned to the
pool, and will retry a normal allocation regularly.

Signed-off-by: NeilBrown 
---
 drivers/md/dm-region-hash.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/md/dm-region-hash.c b/drivers/md/dm-region-hash.c
index 85c32b22a420..a6279f5d779e 100644
--- a/drivers/md/dm-region-hash.c
+++ b/drivers/md/dm-region-hash.c
@@ -287,9 +287,7 @@ static struct dm_region *__rh_alloc(struct dm_region_hash 
*rh, region_t region)
 {
struct dm_region *reg, *nreg;
 
-   nreg = mempool_alloc(rh->region_pool, GFP_ATOMIC);
-   if (unlikely(!nreg))
-   nreg = kmalloc(sizeof(*nreg), GFP_NOIO | __GFP_NOFAIL);
+   nreg = mempool_alloc(rh->region_pool, GFP_NOIO);
 
nreg->state = rh->log->type->in_sync(rh->log, region, 1) ?
  DM_RH_CLEAN : DM_RH_NOSYNC;
-- 
2.12.2



signature.asc
Description: PGP signature

Re: linux-next: build failure after merge of the mfd tree

[Stephen Rothwell]

Hi all,

On Tue, 04 Apr 2017 15:31:15 +0300 Andy Shevchenko 
 wrote:
>
> On Tue, 2017-04-04 at 09:21 +0100, Lee Jones wrote:
> > On Tue, 04 Apr 2017, Lee Jones wrote:
> >   
> > > On Tue, 04 Apr 2017, Stephen Rothwell wrote:
> > >   
> > > > After merging the mfd tree, today's linux-next build (powerpc
> > > > allyesconfig) failed like this:
> > > > 
> > > > /home/sfr/next/next/drivers/mfd/intel_soc_pmic_bxtwc.c:25:31:
> > > > fatal error: asm/intel_pmc_ipc.h: No such file or directory
> > > > 
> > > > Caused by commit
> > > > 
> > > >   eb2a445f7d8f ("mfd: intel_soc_pmic: Fix a mess with compilation
> > > > units")
> > > > 
> > > > I have reverted that commit for today.  
> > > 
> > > Andy,
> > > 
> > > I'm pulling this commit.  Despite you thinking the error is unrelated
> > > to your patch, something is clearly wrong and I don't have time to
> > > investigate.
> > > 
> > > Ball is in your court.  
> > 
> > Okay, I've had a *very* quick looks.  
> 
> > Seems as if you should be depending on INTEL_PMC_IPC.  
> 
> As a quick fix, yes. As a proper fix the PMC/SCU mess should be fixed in
> a way to provide a header in include/platform_data/x86.
> 
> I will prepare v4.
> Thanks.

Ping?

-- 
Cheers,
Stephen Rothwell

[PATCH] dm-region-hash: fix strange usage of mempool_alloc.

[NeilBrown]

mempool_alloc() should only be called with GFP_ATOMIC when
it is not safe to wait. Passing __GFP_NOFAIL to kmalloc()
says that it is safe to wait indefinitely.  So this code is
inconsistent.

Clearly it is OK to wait indefinitely in this code, and
mempool_alloc() is able to do that.  So just use
mempool_alloc, and allow it to sleep.  If no memory is
available it will wait for something to be returned to the
pool, and will retry a normal allocation regularly.

Signed-off-by: NeilBrown 
---
 drivers/md/dm-region-hash.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/md/dm-region-hash.c b/drivers/md/dm-region-hash.c
index 85c32b22a420..a6279f5d779e 100644
--- a/drivers/md/dm-region-hash.c
+++ b/drivers/md/dm-region-hash.c
@@ -287,9 +287,7 @@ static struct dm_region *__rh_alloc(struct dm_region_hash 
*rh, region_t region)
 {
struct dm_region *reg, *nreg;
 
-   nreg = mempool_alloc(rh->region_pool, GFP_ATOMIC);
-   if (unlikely(!nreg))
-   nreg = kmalloc(sizeof(*nreg), GFP_NOIO | __GFP_NOFAIL);
+   nreg = mempool_alloc(rh->region_pool, GFP_NOIO);
 
nreg->state = rh->log->type->in_sync(rh->log, region, 1) ?
  DM_RH_CLEAN : DM_RH_NOSYNC;
-- 
2.12.2



signature.asc
Description: PGP signature