Re: [PATCH v5 3/3] clk: meson: add sub MMC clock controller driver

[Jianxin Pan]

On 2018/10/20 2:03, Stephen Boyd wrote:
> Quoting Jianxin Pan (2018-10-19 09:12:53)
>> On 2018/10/19 1:13, Stephen Boyd wrote:
>>> Quoting Jianxin Pan (2018-10-17 22:07:25)
 diff --git a/drivers/clk/meson/clk-regmap.c 
 b/drivers/clk/meson/clk-regmap.c
 index 305ee30..f96314d 100644
 --- a/drivers/clk/meson/clk-regmap.c
 +++ b/drivers/clk/meson/clk-regmap.c
 @@ -113,8 +113,25 @@ static int clk_regmap_div_set_rate(struct clk_hw *hw, 
 unsigned long rate,
   clk_div_mask(div->width) << div->shift, 
 val);
  };
  
 -/* Would prefer clk_regmap_div_ro_ops but clashes with qcom */
 +static void clk_regmap_div_init(struct clk_hw *hw)
 +{
 +   struct clk_regmap *clk = to_clk_regmap(hw);
 +   struct clk_regmap_div_data *div = clk_get_regmap_div_data(clk);
 +   unsigned int val;
 +   int ret;
 +
 +   ret = regmap_read(clk->map, div->offset, );
 +   if (ret)
 +   return;
  
 +   val &= (clk_div_mask(div->width) << div->shift);
 +   if (!val)
 +   regmap_update_bits(clk->map, div->offset,
 +  clk_div_mask(div->width) << div->shift,
 +  clk_div_mask(div->width));
 +}
 +
 +/* Would prefer clk_regmap_div_ro_ops but clashes with qcom */
>>>
>>> We should add a patch to rename the symbol for qcom, i.e.
>>> qcom_clk_regmap_div_ro_ops, and then any symbols in this directory
>>> should be meson_clk_regmap_div_ro_ops.
>> "/* Would prefer clk_regmap_div_ro_ops but clashes with qcom */"
>> This comment is not introduced in this patch.
>> I followed the naming style in this file and add 
>> clk_regmap_divider_with_init_ops.
>>
>> @Jerome， What's your suggestion about this？
> 
> Yes you don't need to fix anything in this series. Just saying that in
> the future we should work on cleaning this up.
> 
OK. Thank you!
> .
> 

Re: [PATCH v5 3/3] clk: meson: add sub MMC clock controller driver

[Jianxin Pan]

On 2018/10/20 2:03, Stephen Boyd wrote:
> Quoting Jianxin Pan (2018-10-19 09:12:53)
>> On 2018/10/19 1:13, Stephen Boyd wrote:
>>> Quoting Jianxin Pan (2018-10-17 22:07:25)
 diff --git a/drivers/clk/meson/clk-regmap.c 
 b/drivers/clk/meson/clk-regmap.c
 index 305ee30..f96314d 100644
 --- a/drivers/clk/meson/clk-regmap.c
 +++ b/drivers/clk/meson/clk-regmap.c
 @@ -113,8 +113,25 @@ static int clk_regmap_div_set_rate(struct clk_hw *hw, 
 unsigned long rate,
   clk_div_mask(div->width) << div->shift, 
 val);
  };
  
 -/* Would prefer clk_regmap_div_ro_ops but clashes with qcom */
 +static void clk_regmap_div_init(struct clk_hw *hw)
 +{
 +   struct clk_regmap *clk = to_clk_regmap(hw);
 +   struct clk_regmap_div_data *div = clk_get_regmap_div_data(clk);
 +   unsigned int val;
 +   int ret;
 +
 +   ret = regmap_read(clk->map, div->offset, );
 +   if (ret)
 +   return;
  
 +   val &= (clk_div_mask(div->width) << div->shift);
 +   if (!val)
 +   regmap_update_bits(clk->map, div->offset,
 +  clk_div_mask(div->width) << div->shift,
 +  clk_div_mask(div->width));
 +}
 +
 +/* Would prefer clk_regmap_div_ro_ops but clashes with qcom */
>>>
>>> We should add a patch to rename the symbol for qcom, i.e.
>>> qcom_clk_regmap_div_ro_ops, and then any symbols in this directory
>>> should be meson_clk_regmap_div_ro_ops.
>> "/* Would prefer clk_regmap_div_ro_ops but clashes with qcom */"
>> This comment is not introduced in this patch.
>> I followed the naming style in this file and add 
>> clk_regmap_divider_with_init_ops.
>>
>> @Jerome， What's your suggestion about this？
> 
> Yes you don't need to fix anything in this series. Just saying that in
> the future we should work on cleaning this up.
> 
OK. Thank you!
> .
> 

Re: [PATCH v5 6/6] power: supply: Add Spreadtrum SC27XX fuel gauge unit driver

[Baolin Wang]

Hi Sebastian,

On 22 October 2018 at 00:52, Sebastian Reichel  wrote:
> Hi,
>
> On Fri, Oct 19, 2018 at 06:53:15PM +0800, Baolin Wang wrote:
>> This patch adds the Spreadtrum SC27XX serial PMICs fuel gauge support,
>> which is used to calculate the battery capacity.
>>
>> Original-by: Yuanjiang Yu 
>> Signed-off-by: Baolin Wang 
>> Acked-by: Linus Walleij 
>> ---
>
> Looks mostly good. I have a few comments still. My plan is to merge
> this early after the merge window, if the final version is finished
> at this point.
>
>> Changes from v4:
>>  - None.
>>
>> Changes from v3:
>>  - None.
>>
>> Changes from v2:
>>  - Use core helper functions to look up OCV capacity table.
>>  - Use device_property_read_u32() instead of of_property_read_u32().
>>  - Add acked tag from Linus.
>>
>> Changes from v1:
>>  - Use battery standard properties to get internal resistance and ocv table.
>>  - Change devm_gpiod_get_optional() to devm_gpiod_get().
>>  - Add power_supply_changed() when detecting battery present change.
>>  - Return micro volts for sc27xx_fgu_get_vbat_ocv().
>> ---
>>  drivers/power/supply/Kconfig |7 +
>>  drivers/power/supply/Makefile|1 +
>>  drivers/power/supply/sc27xx_fuel_gauge.c |  661 
>> ++
>>  3 files changed, 669 insertions(+)
>>  create mode 100644 drivers/power/supply/sc27xx_fuel_gauge.c
>>
>> diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
>> index f27cf07..917f4b7 100644
>> --- a/drivers/power/supply/Kconfig
>> +++ b/drivers/power/supply/Kconfig
>> @@ -652,4 +652,11 @@ config CHARGER_SC2731
>>Say Y here to enable support for battery charging with SC2731
>>PMIC chips.
>>
>> +config FUEL_GAUGE_SC27XX
>> + tristate "Spreadtrum SC27XX fuel gauge driver"
>> + depends on MFD_SC27XX_PMIC || COMPILE_TEST
>> + help
>> +  Say Y here to enable support for fuel gauge with SC27XX
>> +  PMIC chips.
>> +
>>  endif # POWER_SUPPLY
>> diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
>> index 767105b..b731c2a 100644
>> --- a/drivers/power/supply/Makefile
>> +++ b/drivers/power/supply/Makefile
>> @@ -86,3 +86,4 @@ obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
>>  obj-$(CONFIG_AXP288_CHARGER) += axp288_charger.o
>>  obj-$(CONFIG_CHARGER_CROS_USBPD) += cros_usbpd-charger.o
>>  obj-$(CONFIG_CHARGER_SC2731) += sc2731_charger.o
>> +obj-$(CONFIG_FUEL_GAUGE_SC27XX)  += sc27xx_fuel_gauge.o
>> diff --git a/drivers/power/supply/sc27xx_fuel_gauge.c 
>> b/drivers/power/supply/sc27xx_fuel_gauge.c
>> new file mode 100644
>> index 000..1c0b856
>> --- /dev/null
>> +++ b/drivers/power/supply/sc27xx_fuel_gauge.c
>> @@ -0,0 +1,661 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (C) 2018 Spreadtrum Communications Inc.
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* PMIC global control registers definition */
>> +#define SC27XX_MODULE_EN00xc08
>> +#define SC27XX_CLK_EN0   0xc18
>> +#define SC27XX_FGU_ENBIT(7)
>> +#define SC27XX_FGU_RTC_ENBIT(6)
>> +
>> +/* FGU registers definition */
>> +#define SC27XX_FGU_START 0x0
>> +#define SC27XX_FGU_CONFIG0x4
>> +#define SC27XX_FGU_ADC_CONFIG0x8
>> +#define SC27XX_FGU_STATUS0xc
>> +#define SC27XX_FGU_INT_EN0x10
>> +#define SC27XX_FGU_INT_CLR   0x14
>> +#define SC27XX_FGU_INT_STS   0x1c
>> +#define SC27XX_FGU_VOLTAGE   0x20
>> +#define SC27XX_FGU_OCV   0x24
>> +#define SC27XX_FGU_POCV  0x28
>> +#define SC27XX_FGU_CURRENT   0x2c
>> +#define SC27XX_FGU_CLBCNT_SETH   0x50
>> +#define SC27XX_FGU_CLBCNT_SETL   0x54
>> +#define SC27XX_FGU_CLBCNT_VALH   0x68
>> +#define SC27XX_FGU_CLBCNT_VALL   0x6c
>> +#define SC27XX_FGU_CLBCNT_QMAXL  0x74
>> +
>> +#define SC27XX_WRITE_SELCLB_EN   BIT(0)
>> +#define SC27XX_FGU_CLBCNT_MASK   GENMASK(15, 0)
>> +#define SC27XX_FGU_CLBCNT_SHIFT  16
>> +
>> +#define SC27XX_FGU_1000MV_ADC686
>> +#define SC27XX_FGU_1000MA_ADC1372
>> +#define SC27XX_FGU_CUR_BASIC_ADC 8192
>> +#define SC27XX_FGU_SAMPLE_HZ 2
>> +
>> +/*
>> + * struct sc27xx_fgu_data: describe the FGU device
>> + * @regmap: regmap for register access
>> + * @dev: platform device
>> + * @battery: battery power supply
>> + * @base: the base offset for the controller
>> + * @lock: protect the structure
>> + * @gpiod: GPIO for battery detection
>> + * @channel: IIO channel to get battery temperature
>> + * @internal_resist: the battery internal resistance in mOhm
>> + * @total_cap: the total capacity of the battery in mAh
>> + * @init_cap: the initial capacity of the battery in mAh
>> + * @init_clbcnt: the 

Re: [PATCH v5 6/6] power: supply: Add Spreadtrum SC27XX fuel gauge unit driver

[Baolin Wang]

Hi Sebastian,

On 22 October 2018 at 00:52, Sebastian Reichel  wrote:
> Hi,
>
> On Fri, Oct 19, 2018 at 06:53:15PM +0800, Baolin Wang wrote:
>> This patch adds the Spreadtrum SC27XX serial PMICs fuel gauge support,
>> which is used to calculate the battery capacity.
>>
>> Original-by: Yuanjiang Yu 
>> Signed-off-by: Baolin Wang 
>> Acked-by: Linus Walleij 
>> ---
>
> Looks mostly good. I have a few comments still. My plan is to merge
> this early after the merge window, if the final version is finished
> at this point.
>
>> Changes from v4:
>>  - None.
>>
>> Changes from v3:
>>  - None.
>>
>> Changes from v2:
>>  - Use core helper functions to look up OCV capacity table.
>>  - Use device_property_read_u32() instead of of_property_read_u32().
>>  - Add acked tag from Linus.
>>
>> Changes from v1:
>>  - Use battery standard properties to get internal resistance and ocv table.
>>  - Change devm_gpiod_get_optional() to devm_gpiod_get().
>>  - Add power_supply_changed() when detecting battery present change.
>>  - Return micro volts for sc27xx_fgu_get_vbat_ocv().
>> ---
>>  drivers/power/supply/Kconfig |7 +
>>  drivers/power/supply/Makefile|1 +
>>  drivers/power/supply/sc27xx_fuel_gauge.c |  661 
>> ++
>>  3 files changed, 669 insertions(+)
>>  create mode 100644 drivers/power/supply/sc27xx_fuel_gauge.c
>>
>> diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
>> index f27cf07..917f4b7 100644
>> --- a/drivers/power/supply/Kconfig
>> +++ b/drivers/power/supply/Kconfig
>> @@ -652,4 +652,11 @@ config CHARGER_SC2731
>>Say Y here to enable support for battery charging with SC2731
>>PMIC chips.
>>
>> +config FUEL_GAUGE_SC27XX
>> + tristate "Spreadtrum SC27XX fuel gauge driver"
>> + depends on MFD_SC27XX_PMIC || COMPILE_TEST
>> + help
>> +  Say Y here to enable support for fuel gauge with SC27XX
>> +  PMIC chips.
>> +
>>  endif # POWER_SUPPLY
>> diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
>> index 767105b..b731c2a 100644
>> --- a/drivers/power/supply/Makefile
>> +++ b/drivers/power/supply/Makefile
>> @@ -86,3 +86,4 @@ obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
>>  obj-$(CONFIG_AXP288_CHARGER) += axp288_charger.o
>>  obj-$(CONFIG_CHARGER_CROS_USBPD) += cros_usbpd-charger.o
>>  obj-$(CONFIG_CHARGER_SC2731) += sc2731_charger.o
>> +obj-$(CONFIG_FUEL_GAUGE_SC27XX)  += sc27xx_fuel_gauge.o
>> diff --git a/drivers/power/supply/sc27xx_fuel_gauge.c 
>> b/drivers/power/supply/sc27xx_fuel_gauge.c
>> new file mode 100644
>> index 000..1c0b856
>> --- /dev/null
>> +++ b/drivers/power/supply/sc27xx_fuel_gauge.c
>> @@ -0,0 +1,661 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (C) 2018 Spreadtrum Communications Inc.
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* PMIC global control registers definition */
>> +#define SC27XX_MODULE_EN00xc08
>> +#define SC27XX_CLK_EN0   0xc18
>> +#define SC27XX_FGU_ENBIT(7)
>> +#define SC27XX_FGU_RTC_ENBIT(6)
>> +
>> +/* FGU registers definition */
>> +#define SC27XX_FGU_START 0x0
>> +#define SC27XX_FGU_CONFIG0x4
>> +#define SC27XX_FGU_ADC_CONFIG0x8
>> +#define SC27XX_FGU_STATUS0xc
>> +#define SC27XX_FGU_INT_EN0x10
>> +#define SC27XX_FGU_INT_CLR   0x14
>> +#define SC27XX_FGU_INT_STS   0x1c
>> +#define SC27XX_FGU_VOLTAGE   0x20
>> +#define SC27XX_FGU_OCV   0x24
>> +#define SC27XX_FGU_POCV  0x28
>> +#define SC27XX_FGU_CURRENT   0x2c
>> +#define SC27XX_FGU_CLBCNT_SETH   0x50
>> +#define SC27XX_FGU_CLBCNT_SETL   0x54
>> +#define SC27XX_FGU_CLBCNT_VALH   0x68
>> +#define SC27XX_FGU_CLBCNT_VALL   0x6c
>> +#define SC27XX_FGU_CLBCNT_QMAXL  0x74
>> +
>> +#define SC27XX_WRITE_SELCLB_EN   BIT(0)
>> +#define SC27XX_FGU_CLBCNT_MASK   GENMASK(15, 0)
>> +#define SC27XX_FGU_CLBCNT_SHIFT  16
>> +
>> +#define SC27XX_FGU_1000MV_ADC686
>> +#define SC27XX_FGU_1000MA_ADC1372
>> +#define SC27XX_FGU_CUR_BASIC_ADC 8192
>> +#define SC27XX_FGU_SAMPLE_HZ 2
>> +
>> +/*
>> + * struct sc27xx_fgu_data: describe the FGU device
>> + * @regmap: regmap for register access
>> + * @dev: platform device
>> + * @battery: battery power supply
>> + * @base: the base offset for the controller
>> + * @lock: protect the structure
>> + * @gpiod: GPIO for battery detection
>> + * @channel: IIO channel to get battery temperature
>> + * @internal_resist: the battery internal resistance in mOhm
>> + * @total_cap: the total capacity of the battery in mAh
>> + * @init_cap: the initial capacity of the battery in mAh
>> + * @init_clbcnt: the 

Re: [RFC PATCH] dt-bindings: opp: Extend qcom-opp bindings with properties needed for CPR

[Viresh Kumar]

On 15-10-18, 14:47, Niklas Cassel wrote:
> Extend qcom-opp bindings with properties needed for Core Power Reduction
> (CPR).
> 
> CPR is included in a great variety of Qualcomm SoC, e.g. msm8916 and
> msm8996, and was first introduced in msm8974.
> 
> Signed-off-by: Niklas Cassel 
> ---
> Hello Rob, Rajendra,
> 
> Sorry for not replying sooner.
> Since Rob wanted the binding to be complete before merging,
> this is my proposal to extend the OPP binding with properties
> needed to support CPR (both for msm8916 and msm8996).
> I've discussed the proposal with Viresh, and this proposal
> seems better than what I previously suggested here:
> https://lore.kernel.org/lkml/20181005204424.ga29...@centauri.lan/
> 
>  .../devicetree/bindings/opp/qcom-opp.txt  | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/opp/qcom-opp.txt 
> b/Documentation/devicetree/bindings/opp/qcom-opp.txt
> index db4d970c7ec7..3ab5dd84de86 100644
> --- a/Documentation/devicetree/bindings/opp/qcom-opp.txt
> +++ b/Documentation/devicetree/bindings/opp/qcom-opp.txt
> @@ -23,3 +23,22 @@ Required properties:
>  representing a corner/level that's communicated with a remote microprocessor
>  (usually called the RPM) which then translates it into a certain voltage on
>  a voltage rail.
> +
> +Optional properties:
> +- opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer. Even
> +  though a power domain doesn't need a opp-hz, there can be devices in the
> +  power domain that need to know the highest supported frequency for each
> +  corner/level (e.g. CPR), in order to properly initialize the hardware.
> +
> +- qcom,fuse-level: A positive value representing the fuse corner/level
> +  associated with this OPP node. Sometimes several corners/levels shares
> +  a certain fuse corner/level. A fuse corner/level contains e.g. ref uV,
> +  min uV, and max uV.
> +
> +- qcom,fuse-level-: Named qcom,fuse-level property. This is exactly
> +  similar to the above qcom,fuse-level property, but allows multiple
> +  fuse corners/levels to be provided for the same OPP. At runtime, the
> +  platform can pick a  and matching qcom,fuse-level- property
> +  will be enabled for all OPPs. If the platform doesn't pick a specific
> +   or the  doesn't match with any qcom,fuse-level-
> +  properties, then qcom,fuse-level property shall be used, if present.

LGTM.

-- 
viresh

Re: [RFC PATCH] dt-bindings: opp: Extend qcom-opp bindings with properties needed for CPR

[Viresh Kumar]

On 15-10-18, 14:47, Niklas Cassel wrote:
> Extend qcom-opp bindings with properties needed for Core Power Reduction
> (CPR).
> 
> CPR is included in a great variety of Qualcomm SoC, e.g. msm8916 and
> msm8996, and was first introduced in msm8974.
> 
> Signed-off-by: Niklas Cassel 
> ---
> Hello Rob, Rajendra,
> 
> Sorry for not replying sooner.
> Since Rob wanted the binding to be complete before merging,
> this is my proposal to extend the OPP binding with properties
> needed to support CPR (both for msm8916 and msm8996).
> I've discussed the proposal with Viresh, and this proposal
> seems better than what I previously suggested here:
> https://lore.kernel.org/lkml/20181005204424.ga29...@centauri.lan/
> 
>  .../devicetree/bindings/opp/qcom-opp.txt  | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/opp/qcom-opp.txt 
> b/Documentation/devicetree/bindings/opp/qcom-opp.txt
> index db4d970c7ec7..3ab5dd84de86 100644
> --- a/Documentation/devicetree/bindings/opp/qcom-opp.txt
> +++ b/Documentation/devicetree/bindings/opp/qcom-opp.txt
> @@ -23,3 +23,22 @@ Required properties:
>  representing a corner/level that's communicated with a remote microprocessor
>  (usually called the RPM) which then translates it into a certain voltage on
>  a voltage rail.
> +
> +Optional properties:
> +- opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer. Even
> +  though a power domain doesn't need a opp-hz, there can be devices in the
> +  power domain that need to know the highest supported frequency for each
> +  corner/level (e.g. CPR), in order to properly initialize the hardware.
> +
> +- qcom,fuse-level: A positive value representing the fuse corner/level
> +  associated with this OPP node. Sometimes several corners/levels shares
> +  a certain fuse corner/level. A fuse corner/level contains e.g. ref uV,
> +  min uV, and max uV.
> +
> +- qcom,fuse-level-: Named qcom,fuse-level property. This is exactly
> +  similar to the above qcom,fuse-level property, but allows multiple
> +  fuse corners/levels to be provided for the same OPP. At runtime, the
> +  platform can pick a  and matching qcom,fuse-level- property
> +  will be enabled for all OPPs. If the platform doesn't pick a specific
> +   or the  doesn't match with any qcom,fuse-level-
> +  properties, then qcom,fuse-level property shall be used, if present.

LGTM.

-- 
viresh

Re: [RFC PATCH v2 01/17] OPP: Allow to request stub voltage regulators

[Viresh Kumar]

On 21-10-18, 23:54, Dmitry Osipenko wrote:
> Voltage regulators may be not available on some variations of HW, allow to
> request stub voltage regulators by OPP core in a such case to reduce code
> churning within drivers.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/cpufreq/cpufreq-dt.c | 2 +-
>  drivers/cpufreq/ti-cpufreq.c | 3 ++-
>  drivers/opp/core.c   | 9 +++--
>  include/linux/pm_opp.h   | 4 ++--
>  4 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> index e58bfcb1169e..6ebca472ec76 100644
> --- a/drivers/cpufreq/cpufreq-dt.c
> +++ b/drivers/cpufreq/cpufreq-dt.c
> @@ -196,7 +196,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
>*/
>   name = find_supply_name(cpu_dev);
>   if (name) {
> - opp_table = dev_pm_opp_set_regulators(cpu_dev, , 1);
> + opp_table = dev_pm_opp_set_regulators(cpu_dev, , 1, false);
>   if (IS_ERR(opp_table)) {
>   ret = PTR_ERR(opp_table);
>   dev_err(cpu_dev, "Failed to set regulator for cpu%d: 
> %d\n",

Have you actually tested this stuff ? The cpufreq-dt driver will
probably fail to probe if the CPU node has a "-supply" property, but
no regulator matching that.

-- 
viresh

Re: [RFC PATCH v2 01/17] OPP: Allow to request stub voltage regulators

[Viresh Kumar]

On 21-10-18, 23:54, Dmitry Osipenko wrote:
> Voltage regulators may be not available on some variations of HW, allow to
> request stub voltage regulators by OPP core in a such case to reduce code
> churning within drivers.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/cpufreq/cpufreq-dt.c | 2 +-
>  drivers/cpufreq/ti-cpufreq.c | 3 ++-
>  drivers/opp/core.c   | 9 +++--
>  include/linux/pm_opp.h   | 4 ++--
>  4 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> index e58bfcb1169e..6ebca472ec76 100644
> --- a/drivers/cpufreq/cpufreq-dt.c
> +++ b/drivers/cpufreq/cpufreq-dt.c
> @@ -196,7 +196,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
>*/
>   name = find_supply_name(cpu_dev);
>   if (name) {
> - opp_table = dev_pm_opp_set_regulators(cpu_dev, , 1);
> + opp_table = dev_pm_opp_set_regulators(cpu_dev, , 1, false);
>   if (IS_ERR(opp_table)) {
>   ret = PTR_ERR(opp_table);
>   dev_err(cpu_dev, "Failed to set regulator for cpu%d: 
> %d\n",

Have you actually tested this stuff ? The cpufreq-dt driver will
probably fail to probe if the CPU node has a "-supply" property, but
no regulator matching that.

-- 
viresh

Can i trust you?

[Mr Yi Gang]

Can i trust you with a transaction of usd 8.3m?($8,370.000.00) Reply me if 
interested
- Mr Yi Gang

Can i trust you?

[Mr Yi Gang]

Can i trust you with a transaction of usd 8.3m?($8,370.000.00) Reply me if 
interested
- Mr Yi Gang

[tip:x86/mm] x86/stackprotector: Remove the call to boot_init_stack_canary() from cpu_startup_entry()

[tip-bot for Christophe Leroy]

Commit-ID:  977e4be5eb714c48a67afc26a6c477f24130a1f2
Gitweb: https://git.kernel.org/tip/977e4be5eb714c48a67afc26a6c477f24130a1f2
Author: Christophe Leroy 
AuthorDate: Sat, 20 Oct 2018 09:26:49 +0200
Committer:  Ingo Molnar 
CommitDate: Mon, 22 Oct 2018 04:07:24 +0200

x86/stackprotector: Remove the call to boot_init_stack_canary() from 
cpu_startup_entry()

The following commit:

  d7880812b359 ("idle: Add the stack canary init to cpu_startup_entry()")

... added an x86 specific boot_init_stack_canary() call to the generic
cpu_startup_entry() as a temporary hack, with the intention to remove
the #ifdef CONFIG_X86 later.

More than 5 years later let's finally realize that plan! :-)

While implementing stack protector support for PowerPC, we found
that calling boot_init_stack_canary() is also needed for PowerPC
which uses per task (TLS) stack canary like the X86.

However, calling boot_init_stack_canary() would break architectures
using a global stack canary (ARM, SH, MIPS and XTENSA).

Instead of modifying the #ifdef CONFIG_X86 to an even messier:

   #if defined(CONFIG_X86) || defined(CONFIG_PPC)

PowerPC implemented the call to boot_init_stack_canary() in the function
calling cpu_startup_entry().

Let's try the same cleanup on the x86 side as well.

On x86 we have two functions calling cpu_startup_entry():

 - start_secondary()
 - cpu_bringup_and_idle()

start_secondary() already calls boot_init_stack_canary(), so
it's good, and this patch adds the call to boot_init_stack_canary()
in cpu_bringup_and_idle().

I.e. now x86 catches up to the rest of the world and the ugly init
sequence in init/main.c can be removed from cpu_startup_entry().

As a final benefit we can also remove the 
dependency from .

[ mingo: Improved the changelog a bit, added language explaining x86 borkage 
and sched.h change. ]
Signed-off-by: Christophe Leroy 
Reviewed-by: Juergen Gross 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linuxppc-...@lists.ozlabs.org
Cc: xen-de...@lists.xenproject.org
Link: 
http://lkml.kernel.org/r/20181020072649.5b593104...@pc16082vm.idsi0.si.c-s.fr
Signed-off-by: Ingo Molnar 
---
 arch/x86/xen/smp_pv.c |  2 ++
 kernel/sched/idle.c   | 15 ---
 kernel/sched/sched.h  |  1 -
 3 files changed, 2 insertions(+), 16 deletions(-)

diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index e3b18ad49889..145506f9fdbe 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -88,6 +89,7 @@ static void cpu_bringup(void)
 asmlinkage __visible void cpu_bringup_and_idle(void)
 {
cpu_bringup();
+   boot_init_stack_canary();
cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
 }
 
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index 16f84142f2f4..f5516bae0c1b 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -347,21 +347,6 @@ EXPORT_SYMBOL_GPL(play_idle);
 
 void cpu_startup_entry(enum cpuhp_state state)
 {
-   /*
-* This #ifdef needs to die, but it's too late in the cycle to
-* make this generic (ARM and SH have never invoked the canary
-* init for the non boot CPUs!). Will be fixed in 3.11
-*/
-#ifdef CONFIG_X86
-   /*
-* If we're the non-boot CPU, nothing set the stack canary up
-* for us. The boot CPU already has it initialized but no harm
-* in doing it again. This is a good place for updating it, as
-* we wont ever return from this function (so the invalid
-* canaries already on the stack wont ever trigger).
-*/
-   boot_init_stack_canary();
-#endif
arch_cpu_idle_prepare();
cpuhp_online_idle(state);
while (1)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 4a2e8cae63c4..5b00a816a4b3 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -56,7 +56,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 

[tip:x86/mm] x86/stackprotector: Remove the call to boot_init_stack_canary() from cpu_startup_entry()

[tip-bot for Christophe Leroy]

Commit-ID:  977e4be5eb714c48a67afc26a6c477f24130a1f2
Gitweb: https://git.kernel.org/tip/977e4be5eb714c48a67afc26a6c477f24130a1f2
Author: Christophe Leroy 
AuthorDate: Sat, 20 Oct 2018 09:26:49 +0200
Committer:  Ingo Molnar 
CommitDate: Mon, 22 Oct 2018 04:07:24 +0200

x86/stackprotector: Remove the call to boot_init_stack_canary() from 
cpu_startup_entry()

The following commit:

  d7880812b359 ("idle: Add the stack canary init to cpu_startup_entry()")

... added an x86 specific boot_init_stack_canary() call to the generic
cpu_startup_entry() as a temporary hack, with the intention to remove
the #ifdef CONFIG_X86 later.

More than 5 years later let's finally realize that plan! :-)

While implementing stack protector support for PowerPC, we found
that calling boot_init_stack_canary() is also needed for PowerPC
which uses per task (TLS) stack canary like the X86.

However, calling boot_init_stack_canary() would break architectures
using a global stack canary (ARM, SH, MIPS and XTENSA).

Instead of modifying the #ifdef CONFIG_X86 to an even messier:

   #if defined(CONFIG_X86) || defined(CONFIG_PPC)

PowerPC implemented the call to boot_init_stack_canary() in the function
calling cpu_startup_entry().

Let's try the same cleanup on the x86 side as well.

On x86 we have two functions calling cpu_startup_entry():

 - start_secondary()
 - cpu_bringup_and_idle()

start_secondary() already calls boot_init_stack_canary(), so
it's good, and this patch adds the call to boot_init_stack_canary()
in cpu_bringup_and_idle().

I.e. now x86 catches up to the rest of the world and the ugly init
sequence in init/main.c can be removed from cpu_startup_entry().

As a final benefit we can also remove the 
dependency from .

[ mingo: Improved the changelog a bit, added language explaining x86 borkage 
and sched.h change. ]
Signed-off-by: Christophe Leroy 
Reviewed-by: Juergen Gross 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linuxppc-...@lists.ozlabs.org
Cc: xen-de...@lists.xenproject.org
Link: 
http://lkml.kernel.org/r/20181020072649.5b593104...@pc16082vm.idsi0.si.c-s.fr
Signed-off-by: Ingo Molnar 
---
 arch/x86/xen/smp_pv.c |  2 ++
 kernel/sched/idle.c   | 15 ---
 kernel/sched/sched.h  |  1 -
 3 files changed, 2 insertions(+), 16 deletions(-)

diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index e3b18ad49889..145506f9fdbe 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -88,6 +89,7 @@ static void cpu_bringup(void)
 asmlinkage __visible void cpu_bringup_and_idle(void)
 {
cpu_bringup();
+   boot_init_stack_canary();
cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
 }
 
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index 16f84142f2f4..f5516bae0c1b 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -347,21 +347,6 @@ EXPORT_SYMBOL_GPL(play_idle);
 
 void cpu_startup_entry(enum cpuhp_state state)
 {
-   /*
-* This #ifdef needs to die, but it's too late in the cycle to
-* make this generic (ARM and SH have never invoked the canary
-* init for the non boot CPUs!). Will be fixed in 3.11
-*/
-#ifdef CONFIG_X86
-   /*
-* If we're the non-boot CPU, nothing set the stack canary up
-* for us. The boot CPU already has it initialized but no harm
-* in doing it again. This is a good place for updating it, as
-* we wont ever return from this function (so the invalid
-* canaries already on the stack wont ever trigger).
-*/
-   boot_init_stack_canary();
-#endif
arch_cpu_idle_prepare();
cpuhp_online_idle(state);
while (1)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 4a2e8cae63c4..5b00a816a4b3 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -56,7 +56,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 

Re: [PATCH] jffs2: Fix use of uninitialized delayed_work, lockdep breakage

[Daniel Santos]

On 10/21/2018 07:32 PM, Hou Tao wrote:
>
> On 2018/10/19 16:30, Daniel Santos wrote:
>> jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
>> is defined then a write buffer is available and has been initialized.
>> However, this does is not the case when the mtd device has no
>> out-of-band buffer:
>>
>> int jffs2_nand_flash_setup(struct jffs2_sb_info *c)
>> {
>> if (!c->mtd->oobsize)
>> return 0;
>> ...
>>
>> The resulting call to cancel_delayed_work_sync passing a uninitialized
>> (but zeroed) delayed_work struct forces lockdep to become disabled.
>>
>> [   90.050639] overlayfs: upper fs does not support tmpfile.
>> [   90.652264] INFO: trying to register non-static key.
>> [   90.662171] the code is fine but needs lockdep annotation.
>> [   90.673090] turning off the locking correctness validator.
>> [   90.684021] CPU: 0 PID: 1762 Comm: mount_root Not tainted 4.14.63 #0
>> [   90.696672] Stack :   80d8f6a2 0038 805f 80444600 
>> 8fe364f4 805dfbe7
>> [   90.713349] 80563a30 06e2 8068370c 0001  0001 
>> 8e2fdc48 
>> [   90.730020]   80d9  0106  
>> 6465746e 312e3420
>> [   90.746690] 6b636f6c 03bf f800 20676e69  8000 
>>  8e2c2a90
>> [   90.763362] 80d9 0001  8e2c2a90 0003 80260dc0 
>> 08052098 8068
>> [   90.780033] ...
>> [   90.784902] Call Trace:
>> [   90.789793] [<8000f0d8>] show_stack+0xb8/0x148
>> [   90.798659] [<8005a000>] register_lock_class+0x270/0x55c
>> [   90.809247] [<8005cb64>] __lock_acquire+0x13c/0xf7c
>> [   90.818964] [<8005e314>] lock_acquire+0x194/0x1dc
>> [   90.828345] [<8003f27c>] flush_work+0x200/0x24c
>> [   90.837374] [<80041dfc>] __cancel_work_timer+0x158/0x210
>> [   90.847958] [<801a8770>] jffs2_sync_fs+0x20/0x54
>> [   90.857173] [<80125cf4>] iterate_supers+0xf4/0x120
>> [   90.866729] [<80158fc4>] sys_sync+0x44/0x9c
>> [   90.875067] [<80014424>] syscall_common+0x34/0x58
>>
>> Signed-off-by: Daniel Santos 
>> ---
>>  fs/jffs2/super.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
>> index 793ad30970ff..cae4ecda3c50 100644
>> --- a/fs/jffs2/super.c
>> +++ b/fs/jffs2/super.c
>> @@ -101,7 +101,8 @@ static int jffs2_sync_fs(struct super_block *sb, int 
>> wait)
>>  struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
>>  
>>  #ifdef CONFIG_JFFS2_FS_WRITEBUFFER
>> -cancel_delayed_work_sync(>wbuf_dwork);
>> +if (jffs2_is_writebuffered(c))
>> +cancel_delayed_work_sync(>wbuf_dwork);
>>  #endif
>>  
>>  mutex_lock(>alloc_sem);
>>
> Reviewed-by: Hou Tao 
>
> And I am curious that why is there NAND Flash without OOB area ? So for them
> the ECC data must be saved in data area ?
>
> Regards,
>
> Tao

Thank you.

I'm not intimately familiar with these, but it's an SPI NOR chip and I'm
pretty sure they that they don't have ECC.  Specifically a Winbond
w25q128fv using drivers/mtd/devices/m25p80.c.

Thanks,
Daniel

Re: [PATCH] jffs2: Fix use of uninitialized delayed_work, lockdep breakage

[Daniel Santos]

On 10/21/2018 07:32 PM, Hou Tao wrote:
>
> On 2018/10/19 16:30, Daniel Santos wrote:
>> jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
>> is defined then a write buffer is available and has been initialized.
>> However, this does is not the case when the mtd device has no
>> out-of-band buffer:
>>
>> int jffs2_nand_flash_setup(struct jffs2_sb_info *c)
>> {
>> if (!c->mtd->oobsize)
>> return 0;
>> ...
>>
>> The resulting call to cancel_delayed_work_sync passing a uninitialized
>> (but zeroed) delayed_work struct forces lockdep to become disabled.
>>
>> [   90.050639] overlayfs: upper fs does not support tmpfile.
>> [   90.652264] INFO: trying to register non-static key.
>> [   90.662171] the code is fine but needs lockdep annotation.
>> [   90.673090] turning off the locking correctness validator.
>> [   90.684021] CPU: 0 PID: 1762 Comm: mount_root Not tainted 4.14.63 #0
>> [   90.696672] Stack :   80d8f6a2 0038 805f 80444600 
>> 8fe364f4 805dfbe7
>> [   90.713349] 80563a30 06e2 8068370c 0001  0001 
>> 8e2fdc48 
>> [   90.730020]   80d9  0106  
>> 6465746e 312e3420
>> [   90.746690] 6b636f6c 03bf f800 20676e69  8000 
>>  8e2c2a90
>> [   90.763362] 80d9 0001  8e2c2a90 0003 80260dc0 
>> 08052098 8068
>> [   90.780033] ...
>> [   90.784902] Call Trace:
>> [   90.789793] [<8000f0d8>] show_stack+0xb8/0x148
>> [   90.798659] [<8005a000>] register_lock_class+0x270/0x55c
>> [   90.809247] [<8005cb64>] __lock_acquire+0x13c/0xf7c
>> [   90.818964] [<8005e314>] lock_acquire+0x194/0x1dc
>> [   90.828345] [<8003f27c>] flush_work+0x200/0x24c
>> [   90.837374] [<80041dfc>] __cancel_work_timer+0x158/0x210
>> [   90.847958] [<801a8770>] jffs2_sync_fs+0x20/0x54
>> [   90.857173] [<80125cf4>] iterate_supers+0xf4/0x120
>> [   90.866729] [<80158fc4>] sys_sync+0x44/0x9c
>> [   90.875067] [<80014424>] syscall_common+0x34/0x58
>>
>> Signed-off-by: Daniel Santos 
>> ---
>>  fs/jffs2/super.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
>> index 793ad30970ff..cae4ecda3c50 100644
>> --- a/fs/jffs2/super.c
>> +++ b/fs/jffs2/super.c
>> @@ -101,7 +101,8 @@ static int jffs2_sync_fs(struct super_block *sb, int 
>> wait)
>>  struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
>>  
>>  #ifdef CONFIG_JFFS2_FS_WRITEBUFFER
>> -cancel_delayed_work_sync(>wbuf_dwork);
>> +if (jffs2_is_writebuffered(c))
>> +cancel_delayed_work_sync(>wbuf_dwork);
>>  #endif
>>  
>>  mutex_lock(>alloc_sem);
>>
> Reviewed-by: Hou Tao 
>
> And I am curious that why is there NAND Flash without OOB area ? So for them
> the ECC data must be saved in data area ?
>
> Regards,
>
> Tao

Thank you.

I'm not intimately familiar with these, but it's an SPI NOR chip and I'm
pretty sure they that they don't have ECC.  Specifically a Winbond
w25q128fv using drivers/mtd/devices/m25p80.c.

Thanks,
Daniel

Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq

[Sricharan R]

Hi Stephen,

On 10/18/2018 1:46 AM, Stephen Boyd wrote:
> Quoting Stephen Boyd (2018-10-17 08:44:12)
>> Quoting Sricharan R (2018-09-20 06:03:31)
>>>
>>>
>>> On 9/20/2018 1:54 AM, Craig wrote:
 Yup, this patch seems to have fixed the higher frequencies from the quick 
 test I did.

>>>   Thanks !!. Can i take that as 
>>>   Tested-by: Craig Tatlor   ?
>>>
>>
>> Is this patch series going to be resent?
>>
> 
> Nevermind. Looking at it I think I can apply all the clk ones and we're
> good to go. If you can send a followup patch series to change the
> registration and provider APIs to be clk_hw instead of clk based I would
> appreciate it.
> 

Sorry for the late response. Was away.
Only pending thing was separating out the binding documentation for the cpu-freq
driver and fixing the text in documentation.  That means, yes its fine to merge
the clk ones as you said. I will resend that. Also, will send a follow up 
series for clk_hw to
clk change as you mentioned separately.

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq

[Sricharan R]

Hi Stephen,

On 10/18/2018 1:46 AM, Stephen Boyd wrote:
> Quoting Stephen Boyd (2018-10-17 08:44:12)
>> Quoting Sricharan R (2018-09-20 06:03:31)
>>>
>>>
>>> On 9/20/2018 1:54 AM, Craig wrote:
 Yup, this patch seems to have fixed the higher frequencies from the quick 
 test I did.

>>>   Thanks !!. Can i take that as 
>>>   Tested-by: Craig Tatlor   ?
>>>
>>
>> Is this patch series going to be resent?
>>
> 
> Nevermind. Looking at it I think I can apply all the clk ones and we're
> good to go. If you can send a followup patch series to change the
> registration and provider APIs to be clk_hw instead of clk based I would
> appreciate it.
> 

Sorry for the late response. Was away.
Only pending thing was separating out the binding documentation for the cpu-freq
driver and fixing the text in documentation.  That means, yes its fine to merge
the clk ones as you said. I will resend that. Also, will send a follow up 
series for clk_hw to
clk change as you mentioned separately.

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Can i trust you

[Mr Yi Gang]

Can i trust you with a transaction of usd 8.3m?($8,370.000.00) Reply me if 
interested
- Mr Yi Gang

Can i trust you

[Mr Yi Gang]

Can i trust you with a transaction of usd 8.3m?($8,370.000.00) Reply me if 
interested
- Mr Yi Gang

[PATCH] sched/numa: fix choosing isolated CPUs when task_numa_migrate()

[Yi Wang]

When trying to migrate to a CPU in task_numa_migrate(), we invoke
task_numa_find_cpu() to choose a spot, in which function we skip
the CPU which is not in cpus_allowed, but forgot to concern the
isolated CPUs, and this may cause the task would run on the isolcpus.

This patch fixes this issue by checking the load_balance_mask.

Signed-off-by: Yi Wang 
Reviewed-by: Yi Liu 
---
 kernel/sched/fair.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 908c9cd..0fa0cee 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1709,6 +1709,7 @@ static void task_numa_compare(struct task_numa_env *env,
rcu_read_unlock();
 }
 
+static int is_cpu_load_balance(int cpu);
 static void task_numa_find_cpu(struct task_numa_env *env,
long taskimp, long groupimp)
 {
@@ -1731,6 +1732,9 @@ static void task_numa_find_cpu(struct task_numa_env *env,
if (!cpumask_test_cpu(cpu, >p->cpus_allowed))
continue;
 
+   if (!is_cpu_load_balance(cpu))
+   continue;
+
env->dst_cpu = cpu;
task_numa_compare(env, taskimp, groupimp, maymove);
}
@@ -8528,6 +8532,12 @@ static int should_we_balance(struct lb_env *env)
return balance_cpu == env->dst_cpu;
 }
 
+static int is_cpu_load_balance(int cpu)
+{
+   struct cpumask *cpus = this_cpu_cpumask_var_ptr(load_balance_mask);
+
+   return cpumask_test_cpu(cpu, cpus);
+}
+
 /*
  * Check this_cpu to ensure it is balanced within domain. Attempt to move
  * tasks if there is an imbalance.
-- 
1.8.3.1

[PATCH] sched/numa: fix choosing isolated CPUs when task_numa_migrate()

[Yi Wang]

When trying to migrate to a CPU in task_numa_migrate(), we invoke
task_numa_find_cpu() to choose a spot, in which function we skip
the CPU which is not in cpus_allowed, but forgot to concern the
isolated CPUs, and this may cause the task would run on the isolcpus.

This patch fixes this issue by checking the load_balance_mask.

Signed-off-by: Yi Wang 
Reviewed-by: Yi Liu 
---
 kernel/sched/fair.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 908c9cd..0fa0cee 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1709,6 +1709,7 @@ static void task_numa_compare(struct task_numa_env *env,
rcu_read_unlock();
 }
 
+static int is_cpu_load_balance(int cpu);
 static void task_numa_find_cpu(struct task_numa_env *env,
long taskimp, long groupimp)
 {
@@ -1731,6 +1732,9 @@ static void task_numa_find_cpu(struct task_numa_env *env,
if (!cpumask_test_cpu(cpu, >p->cpus_allowed))
continue;
 
+   if (!is_cpu_load_balance(cpu))
+   continue;
+
env->dst_cpu = cpu;
task_numa_compare(env, taskimp, groupimp, maymove);
}
@@ -8528,6 +8532,12 @@ static int should_we_balance(struct lb_env *env)
return balance_cpu == env->dst_cpu;
 }
 
+static int is_cpu_load_balance(int cpu)
+{
+   struct cpumask *cpus = this_cpu_cpumask_var_ptr(load_balance_mask);
+
+   return cpumask_test_cpu(cpu, cpus);
+}
+
 /*
  * Check this_cpu to ensure it is balanced within domain. Attempt to move
  * tasks if there is an imbalance.
-- 
1.8.3.1

Re: [PATCH V2 1/5] mm/hugetlb: Enable PUD level huge page migration

[Anshuman Khandual]

On 10/19/2018 01:39 PM, Michal Hocko wrote:
> I planed to get to review this earlier but been busy. Anyway, this patch
> should be applied only after movability one to prevent from
> (theoretical) bisectability issues.

Sure, I can change the order there.

> 
> I would probably fold it into the one which defines arch specific hook.

Hmm but that may be like doing two functionality changes together. Adding one
more conditional check and at the same time wrapping it over with a new name
which is part of a new scheme. I would suggest keeping the patches separate.

Re: [PATCH V2 1/5] mm/hugetlb: Enable PUD level huge page migration

[Anshuman Khandual]

On 10/19/2018 01:39 PM, Michal Hocko wrote:
> I planed to get to review this earlier but been busy. Anyway, this patch
> should be applied only after movability one to prevent from
> (theoretical) bisectability issues.

Sure, I can change the order there.

> 
> I would probably fold it into the one which defines arch specific hook.

Hmm but that may be like doing two functionality changes together. Adding one
more conditional check and at the same time wrapping it over with a new name
which is part of a new scheme. I would suggest keeping the patches separate.

Re: [PATCH 1/1] Perf: Compile failed when compile with libelf.

[Nick Hu]

Hi Arnaldo,

On Thu, Oct 18, 2018 at 10:56:10PM +0800, Arnaldo Carvalho de Melo wrote:
> Em Thu, Oct 18, 2018 at 04:36:46PM +0800, Nickhu escreveu:
> > The error message:
> > =
> > util/symbol-elf.c:46:12: error: static declaration of 'elf_getphdrnum'
> > follows non-static declaration
> > static int elf_getphdrnum(Elf *elf, size_t *dst)
> > ^~
> > In file included from util/symbol.h:20,
> >  from util/symbol-elf.c:9:
> > /local/nickhu/build-system-3/toolchain/nds32le-linux-glibc-v3-upstream/
> > nds32le-linux/sysroot/usr/include/libelf.h:266:12: note: previous 
> > declaration
> > of 'elf_getphdrnum' was here
> > extern int elf_getphdrnum (Elf *__elf, size_t *__dst);
> > ^~
> > util/symbol-elf.c:62:12: error: static declaration of 'elf_getshdrstrndx'
> > follows non-static declaration
> > static int elf_getshdrstrndx(Elf *elf __maybe_unused, size_t *dst __maybe
> > _unused)
> > ^
> > In file included from util/symbol.h:20,
> >  from util/symbol-elf.c:9:
> > /local/nickhu/build-system-3/toolchain/nds32le-linux-glibc-v3-upstream/
> > nds32le-linux/sysroot/usr/include/libelf.h:316:12: note: previous 
> > declaration
> > of 'elf_getshdrstrndx' was here
> > extern int elf_getshdrstrndx (Elf *__elf, size_t *__dst);
> > =
> > 
> > Fix it.
> 
> Humm, I think the fix lies elsewhere.
> 
> If you find that function in a header, then its probably because you
> _have_ it in your system, right? In that case
> HAVE_ELF_GETPHDRNUM_SUPPORT should be defined and that elf_getphdrnum()
> fallback implementation should not be compiled.
> 
> So looking at where HAVE_ELF_GETPHDRNUM_SUPPORT is defined, in
> tools/build/feature, more specifically here:
> 
> [acme@jouet perf]$ cat tools/build/feature/test-libelf-getphdrnum.c 
> // SPDX-License-Identifier: GPL-2.0
> #include 
> 
> int main(void)
> {
>   size_t dst;
> 
>   return elf_getphdrnum(0, );
> }
> [acme@jouet perf]$ 
> 
> [acme@jouet perf]$ find tools/ -type f | xargs grep 
> HAVE_ELF_GETPHDRNUM_SUPPORT
> tools/perf/Makefile.config:CFLAGS += -DHAVE_ELF_GETPHDRNUM_SUPPORT
> tools/perf/util/symbol-elf.c:#ifndef HAVE_ELF_GETPHDRNUM_SUPPORT
> [acme@jouet perf]$ 
> 
> Can you take a look at:
> 
> [acme@jouet perf]$ ls -la /tmp/build/perf/feature/test-libelf-getphdrnum.*
> -rwxrwxr-x. 1 acme acme 8240 Oct 17 09:20 
> /tmp/build/perf/feature/test-libelf-getphdrnum.bin
> -rw-rw-r--. 1 acme acme 1373 Oct 17 09:20 
> /tmp/build/perf/feature/test-libelf-getphdrnum.d
> -rw-rw-r--. 1 acme acme0 Oct 17 09:20 
> /tmp/build/perf/feature/test-libelf-getphdrnum.make.output
> [acme@jouet perf]$ 
> 
> So in my case, using this libelf:
> 
> [acme@jouet perf]$ rpm -qf /usr/include/libelf.h 
> elfutils-libelf-devel-0.173-1.fc28.x86_64
> [acme@jouet perf]$
> 
> the .make.output file is empty, the build was successful, without
> warnings, that binary was generated:
> 
> [acme@jouet perf]$ ls -la /tmp/build/perf/feature/test-libelf-getphdrnum.bin
> -rwxrwxr-x. 1 acme acme 8240 Oct 17 09:20 
> /tmp/build/perf/feature/test-libelf-getphdrnum.bin
> [acme@jouet perf]$ ldd /tmp/build/perf/feature/test-libelf-getphdrnum.bin
>   linux-vdso.so.1 (0x7ffdf93ea000)
>   libelf.so.1 => /lib64/libelf.so.1 (0x7efc3f2d7000)
>   libc.so.6 => /lib64/libc.so.6 (0x7efc3ef21000)
>   libz.so.1 => /lib64/libz.so.1 (0x7efc3ed0a000)
>   /lib64/ld-linux-x86-64.so.2 (0x7efc3f4ef000)
> [acme@jouet perf]$ nm /tmp/build/perf/feature/test-libelf-getphdrnum.bin | 
> grep getphdrnum
>  U elf_getphdrnum@@ELFUTILS_1.6
> [acme@jouet perf]$
> 
> And here are the headers used:
> 
> [acme@jouet perf]$ cat /tmp/build/perf/feature/test-libelf-getphdrnum.d 
> /tmp/build/perf/feature/test-libelf-getphdrnum.bin: \
>  test-libelf-getphdrnum.c /usr/include/stdc-predef.h \
>  /usr/include/libelf.h \
>  /usr/lib/gcc/x86_64-redhat-linux/7/include/stdint.h \
>  /usr/include/stdint.h /usr/include/bits/libc-header-start.h \
>  /usr/include/features.h /usr/include/sys/cdefs.h \
>  /usr/include/bits/wordsize.h /usr/include/bits/long-double.h \
>  /usr/include/gnu/stubs.h /usr/include/gnu/stubs-64.h \
>  /usr/include/bits/types.h /usr/include/bits/typesizes.h \
>  /usr/include/bits/wchar.h /usr/include/bits/stdint-intn.h \
>  /usr/include/bits/stdint-uintn.h /usr/include/sys/types.h \
>  /usr/include/bits/types/clock_t.h /usr/include/bits/types/clockid_t.h \
>  /usr/include/bits/types/time_t.h /usr/include/bits/types/timer_t.h \
>  /usr/lib/gcc/x86_64-redhat-linux/7/include/stddef.h \
>  /usr/include/endian.h /usr/include/bits/endian.h \
>  /usr/include/bits/byteswap.h /usr/include/bits/byteswap-16.h \
>  /usr/include/bits/uintn-identity.h /usr/include/sys/select.h \
>  /usr/include/bits/select.h /usr/include/bits/types/sigset_t.h \
>  

Re: [PATCH 1/1] Perf: Compile failed when compile with libelf.

[Nick Hu]

Hi Arnaldo,

On Thu, Oct 18, 2018 at 10:56:10PM +0800, Arnaldo Carvalho de Melo wrote:
> Em Thu, Oct 18, 2018 at 04:36:46PM +0800, Nickhu escreveu:
> > The error message:
> > =
> > util/symbol-elf.c:46:12: error: static declaration of 'elf_getphdrnum'
> > follows non-static declaration
> > static int elf_getphdrnum(Elf *elf, size_t *dst)
> > ^~
> > In file included from util/symbol.h:20,
> >  from util/symbol-elf.c:9:
> > /local/nickhu/build-system-3/toolchain/nds32le-linux-glibc-v3-upstream/
> > nds32le-linux/sysroot/usr/include/libelf.h:266:12: note: previous 
> > declaration
> > of 'elf_getphdrnum' was here
> > extern int elf_getphdrnum (Elf *__elf, size_t *__dst);
> > ^~
> > util/symbol-elf.c:62:12: error: static declaration of 'elf_getshdrstrndx'
> > follows non-static declaration
> > static int elf_getshdrstrndx(Elf *elf __maybe_unused, size_t *dst __maybe
> > _unused)
> > ^
> > In file included from util/symbol.h:20,
> >  from util/symbol-elf.c:9:
> > /local/nickhu/build-system-3/toolchain/nds32le-linux-glibc-v3-upstream/
> > nds32le-linux/sysroot/usr/include/libelf.h:316:12: note: previous 
> > declaration
> > of 'elf_getshdrstrndx' was here
> > extern int elf_getshdrstrndx (Elf *__elf, size_t *__dst);
> > =
> > 
> > Fix it.
> 
> Humm, I think the fix lies elsewhere.
> 
> If you find that function in a header, then its probably because you
> _have_ it in your system, right? In that case
> HAVE_ELF_GETPHDRNUM_SUPPORT should be defined and that elf_getphdrnum()
> fallback implementation should not be compiled.
> 
> So looking at where HAVE_ELF_GETPHDRNUM_SUPPORT is defined, in
> tools/build/feature, more specifically here:
> 
> [acme@jouet perf]$ cat tools/build/feature/test-libelf-getphdrnum.c 
> // SPDX-License-Identifier: GPL-2.0
> #include 
> 
> int main(void)
> {
>   size_t dst;
> 
>   return elf_getphdrnum(0, );
> }
> [acme@jouet perf]$ 
> 
> [acme@jouet perf]$ find tools/ -type f | xargs grep 
> HAVE_ELF_GETPHDRNUM_SUPPORT
> tools/perf/Makefile.config:CFLAGS += -DHAVE_ELF_GETPHDRNUM_SUPPORT
> tools/perf/util/symbol-elf.c:#ifndef HAVE_ELF_GETPHDRNUM_SUPPORT
> [acme@jouet perf]$ 
> 
> Can you take a look at:
> 
> [acme@jouet perf]$ ls -la /tmp/build/perf/feature/test-libelf-getphdrnum.*
> -rwxrwxr-x. 1 acme acme 8240 Oct 17 09:20 
> /tmp/build/perf/feature/test-libelf-getphdrnum.bin
> -rw-rw-r--. 1 acme acme 1373 Oct 17 09:20 
> /tmp/build/perf/feature/test-libelf-getphdrnum.d
> -rw-rw-r--. 1 acme acme0 Oct 17 09:20 
> /tmp/build/perf/feature/test-libelf-getphdrnum.make.output
> [acme@jouet perf]$ 
> 
> So in my case, using this libelf:
> 
> [acme@jouet perf]$ rpm -qf /usr/include/libelf.h 
> elfutils-libelf-devel-0.173-1.fc28.x86_64
> [acme@jouet perf]$
> 
> the .make.output file is empty, the build was successful, without
> warnings, that binary was generated:
> 
> [acme@jouet perf]$ ls -la /tmp/build/perf/feature/test-libelf-getphdrnum.bin
> -rwxrwxr-x. 1 acme acme 8240 Oct 17 09:20 
> /tmp/build/perf/feature/test-libelf-getphdrnum.bin
> [acme@jouet perf]$ ldd /tmp/build/perf/feature/test-libelf-getphdrnum.bin
>   linux-vdso.so.1 (0x7ffdf93ea000)
>   libelf.so.1 => /lib64/libelf.so.1 (0x7efc3f2d7000)
>   libc.so.6 => /lib64/libc.so.6 (0x7efc3ef21000)
>   libz.so.1 => /lib64/libz.so.1 (0x7efc3ed0a000)
>   /lib64/ld-linux-x86-64.so.2 (0x7efc3f4ef000)
> [acme@jouet perf]$ nm /tmp/build/perf/feature/test-libelf-getphdrnum.bin | 
> grep getphdrnum
>  U elf_getphdrnum@@ELFUTILS_1.6
> [acme@jouet perf]$
> 
> And here are the headers used:
> 
> [acme@jouet perf]$ cat /tmp/build/perf/feature/test-libelf-getphdrnum.d 
> /tmp/build/perf/feature/test-libelf-getphdrnum.bin: \
>  test-libelf-getphdrnum.c /usr/include/stdc-predef.h \
>  /usr/include/libelf.h \
>  /usr/lib/gcc/x86_64-redhat-linux/7/include/stdint.h \
>  /usr/include/stdint.h /usr/include/bits/libc-header-start.h \
>  /usr/include/features.h /usr/include/sys/cdefs.h \
>  /usr/include/bits/wordsize.h /usr/include/bits/long-double.h \
>  /usr/include/gnu/stubs.h /usr/include/gnu/stubs-64.h \
>  /usr/include/bits/types.h /usr/include/bits/typesizes.h \
>  /usr/include/bits/wchar.h /usr/include/bits/stdint-intn.h \
>  /usr/include/bits/stdint-uintn.h /usr/include/sys/types.h \
>  /usr/include/bits/types/clock_t.h /usr/include/bits/types/clockid_t.h \
>  /usr/include/bits/types/time_t.h /usr/include/bits/types/timer_t.h \
>  /usr/lib/gcc/x86_64-redhat-linux/7/include/stddef.h \
>  /usr/include/endian.h /usr/include/bits/endian.h \
>  /usr/include/bits/byteswap.h /usr/include/bits/byteswap-16.h \
>  /usr/include/bits/uintn-identity.h /usr/include/sys/select.h \
>  /usr/include/bits/select.h /usr/include/bits/types/sigset_t.h \
>  

[PATCH] mfd: mt6397: Do not call irq_domain_remove if PMIC unsupported

[Nicolas Boichat]

If the PMIC ID is unknown, the current code would call
irq_domain_remove and panic, as pmic->irq_domain is only
initialized by mt6397_irq_init.

Return immediately with an error, if the chip ID is unsupported.

Signed-off-by: Nicolas Boichat 
---
 drivers/mfd/mt6397-core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index 77b64bd64df36a..ab24e176ef4487 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -329,8 +329,7 @@ static int mt6397_probe(struct platform_device *pdev)
 
default:
dev_err(>dev, "unsupported chip: %d\n", id);
-   ret = -ENODEV;
-   break;
+   return -ENODEV;
}
 
if (ret) {
-- 
2.19.1.568.g152ad8e336-goog

[PATCH] mfd: mt6397: Do not call irq_domain_remove if PMIC unsupported

[Nicolas Boichat]

If the PMIC ID is unknown, the current code would call
irq_domain_remove and panic, as pmic->irq_domain is only
initialized by mt6397_irq_init.

Return immediately with an error, if the chip ID is unsupported.

Signed-off-by: Nicolas Boichat 
---
 drivers/mfd/mt6397-core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index 77b64bd64df36a..ab24e176ef4487 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -329,8 +329,7 @@ static int mt6397_probe(struct platform_device *pdev)
 
default:
dev_err(>dev, "unsupported chip: %d\n", id);
-   ret = -ENODEV;
-   break;
+   return -ENODEV;
}
 
if (ret) {
-- 
2.19.1.568.g152ad8e336-goog

Re: rcu: Kernel stack is corrupted in: perf_trace_rcu_dyntick

[Phy Bio]

This PoC generated by syzkaller needs ROOT permission to run.
Steven Rostedt  于2018年10月18日周四 上午10:13写道：
>
> On Sat, 29 Sep 2018 17:22:13 +0800
> 王晓东  wrote:
>
> > Hi there,
> >
> > We would like to report a kernel stack corrupted problem we identified
> > in the perf_trace_rcu_dyntick function of tracing events subsystem.
> > And the problem was founded by syzkaller.  We has tested the PoC on
> > the lasted master branch of kernel(4.19.0-rc5+).
> >
> > The crash log generated with KASAN enabled:
> >
> > root@pc:~# ./perf_trace_rcu_dyntick
> > [  582.069938] Kernel panic - not syncing: stack-protector: Kernel
> > stack is corrupted in: perf_trace_rcu_dyntick+0x355/0x4f0
> > [  582.069938]
> > [  582.071341] CPU: 6 PID: 3417 Comm: perf_trace_rcu_ Not tainted 
> > 4.19.0-rc5+ #1
> > [  582.072134] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> > BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
> > [  582.073103] Call Trace:
> > [  582.073364]  
> > [  582.073614]  dump_stack+0x8c/0xce
> > [  582.074039]  panic+0x1cb/0x3aa
> > [  582.074427]  ? refcount_error_report+0x296/0x296
> > [  582.075003]  ? timerqueue_del+0x71/0x130
> > [  582.075553]  ? perf_trace_rcu_dyntick+0x355/0x4f0
> > [  582.076063]  ? __stack_chk_fail+0x6/0x20
> > [  582.076763]  ? perf_trace_rcu_dyntick+0x355/0x4f0
> > [  582.077369]  __stack_chk_fail+0x1f/0x20
> > [  582.077877]  perf_trace_rcu_dyntick+0x355/0x4f0
> > [  582.078442]  ? rcu_gp_is_expedited+0xa0/0xa0
> > [  582.078993]  ? rcu_gp_is_expedited+0xa0/0xa0
> > [  582.079525]  ? check_preempt_curr+0x1c2/0x2a0
> > [  582.080059]  ? sched_clock_cpu+0x18/0x160
> > [  582.080551]  rcu_nmi_enter+0x1f0/0x2f0
> > [  582.081036]  ? rcu_gp_is_expedited+0xa0/0xa0
> > [  582.081507]  irq_enter+0xf/0x80
> > [  582.081914]  smp_apic_timer_interrupt+0x1b/0x2d0
> > [  582.082480]  apic_timer_interrupt+0xf/0x20
> > [  582.082984]  
> > [  582.083219] RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x50
> > [  582.087816] Code: e8 35 0b 20 00 48 8b 14 24 e9 fe fe ff ff 48 89
> > df e8 24 0b 20 00 e9 d9 fe ff ff 4c 89 e7 e8 17 0b 20 00 e9 ab fe ff
> > ff 90 90 <65> 48 8b 04 25 40 dd 01 00 65 8b 15 70 03 8f 63 81 e2 00 01
> > 1f 00
> > [  582.090289] RSP: 0018:8800651bf9e0 EFLAGS: 0206 ORIG_RAX:
> > ff13
> > [  582.091238] RAX:  RBX: 9eed12a5 RCX: 
> > 9c6ca1b6
> > [  582.092873] RDX: 0005 RSI: 9ee31d71 RDI: 
> > 9eed12a4
> > [  582.093934] RBP: 0078 R08: ed000d38dfb2 R09: 
> > ed000d38dfb1
> > [  582.095102] R10: 7350a3ba R11: 880069c6fd8f R12: 
> > 8800651bfa6e
> > [  582.096444] R13: 0001 R14: dc00 R15: 
> > 006a
> > [  582.097414]  ? kallsyms_expand_symbol.constprop.11+0x176/0x250
> > [  582.098518]  kallsyms_expand_symbol.constprop.11+0x12e/0x250
> > [  582.099707]  kallsyms_lookup_name+0xbe/0x1d0
> > [  582.100369]  ? kallsyms_on_each_symbol+0x210/0x210
> > [  582.101436]  ? snprintf+0xbd/0xf0
> > [  582.102029]  ? vsprintf+0x30/0x30
> > [  582.102805]  ? kasan_kmalloc+0xa9/0xd0
> > [  582.103489]  ? alloc_trace_kprobe+0x6c0/0x930
> > [  582.104073]  kprobe_on_func_entry+0x57/0xb0
> > [  582.105421]  register_kretprobe+0x89/0xc10
> > [  582.105930]  ? set_print_fmt+0x32/0xa0
> > [  582.106376]  __register_trace_kprobe.part.10+0x14e/0x2e0
> > [  582.106980]  create_local_trace_kprobe+0x29c/0x3f0
> > [  582.107487]  perf_kprobe_init+0x15f/0x210
> > [  582.107912]  perf_kprobe_event_init+0xc4/0x140
>
> I added Peter to the Cc, because he maintains perf.
>
> I have no idea what's going on here with kretprobes? Non-root can have
> kretprobes added to the kernel?
>
> -- Steve
>
>
> > [  582.108377]  perf_try_init_event+0xcb/0x290
> > [  582.108817]  perf_event_alloc+0x1476/0x2020
> > [  582.109264]  ? find_get_context.isra.106+0x690/0x690
> > [  582.109922]  ? __alloc_fd+0x1a3/0x4e0
> > [  582.120002]  __do_sys_perf_event_open+0x222/0x1f40
> > [  582.123049]  ? avc_has_perm_noaudit+0x340/0x340
> > [  582.131226]  ? perf_event_set_output+0x5f0/0x5f0
> > [  582.134395]  ? handle_mm_fault+0x103/0x350
> > [  582.138102]  ? ksys_ioctl+0x61/0x90
> > [  582.140234]  do_syscall_64+0x9a/0x2c0
> > [  582.142674]  ? prepare_exit_to_usermode+0xbc/0x150
> > [  582.146856]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > [  582.151127] RIP: 0033:0x446159
> > [  582.152816] Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00
> > 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24
> > 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 08 fc ff c3 66 2e 0f 1f 84 00 00
> > 00 00
> > [  582.167257] RSP: 002b:7fffc2b023d8 EFLAGS: 0246 ORIG_RAX:
> > 012a
> > [  582.171375] RAX: ffda RBX: 004002c8 RCX: 
> > 00446159
> > [  582.175760] RDX:  RSI:  RDI: 
> > 2180
> > [  582.176487] RBP: 7fffc2b025b0 R08:  R09: 
> > 
> > [  582.177189] R10: 

Re: rcu: Kernel stack is corrupted in: perf_trace_rcu_dyntick

[Phy Bio]

This PoC generated by syzkaller needs ROOT permission to run.
Steven Rostedt  于2018年10月18日周四 上午10:13写道：
>
> On Sat, 29 Sep 2018 17:22:13 +0800
> 王晓东  wrote:
>
> > Hi there,
> >
> > We would like to report a kernel stack corrupted problem we identified
> > in the perf_trace_rcu_dyntick function of tracing events subsystem.
> > And the problem was founded by syzkaller.  We has tested the PoC on
> > the lasted master branch of kernel(4.19.0-rc5+).
> >
> > The crash log generated with KASAN enabled:
> >
> > root@pc:~# ./perf_trace_rcu_dyntick
> > [  582.069938] Kernel panic - not syncing: stack-protector: Kernel
> > stack is corrupted in: perf_trace_rcu_dyntick+0x355/0x4f0
> > [  582.069938]
> > [  582.071341] CPU: 6 PID: 3417 Comm: perf_trace_rcu_ Not tainted 
> > 4.19.0-rc5+ #1
> > [  582.072134] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> > BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
> > [  582.073103] Call Trace:
> > [  582.073364]  
> > [  582.073614]  dump_stack+0x8c/0xce
> > [  582.074039]  panic+0x1cb/0x3aa
> > [  582.074427]  ? refcount_error_report+0x296/0x296
> > [  582.075003]  ? timerqueue_del+0x71/0x130
> > [  582.075553]  ? perf_trace_rcu_dyntick+0x355/0x4f0
> > [  582.076063]  ? __stack_chk_fail+0x6/0x20
> > [  582.076763]  ? perf_trace_rcu_dyntick+0x355/0x4f0
> > [  582.077369]  __stack_chk_fail+0x1f/0x20
> > [  582.077877]  perf_trace_rcu_dyntick+0x355/0x4f0
> > [  582.078442]  ? rcu_gp_is_expedited+0xa0/0xa0
> > [  582.078993]  ? rcu_gp_is_expedited+0xa0/0xa0
> > [  582.079525]  ? check_preempt_curr+0x1c2/0x2a0
> > [  582.080059]  ? sched_clock_cpu+0x18/0x160
> > [  582.080551]  rcu_nmi_enter+0x1f0/0x2f0
> > [  582.081036]  ? rcu_gp_is_expedited+0xa0/0xa0
> > [  582.081507]  irq_enter+0xf/0x80
> > [  582.081914]  smp_apic_timer_interrupt+0x1b/0x2d0
> > [  582.082480]  apic_timer_interrupt+0xf/0x20
> > [  582.082984]  
> > [  582.083219] RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x50
> > [  582.087816] Code: e8 35 0b 20 00 48 8b 14 24 e9 fe fe ff ff 48 89
> > df e8 24 0b 20 00 e9 d9 fe ff ff 4c 89 e7 e8 17 0b 20 00 e9 ab fe ff
> > ff 90 90 <65> 48 8b 04 25 40 dd 01 00 65 8b 15 70 03 8f 63 81 e2 00 01
> > 1f 00
> > [  582.090289] RSP: 0018:8800651bf9e0 EFLAGS: 0206 ORIG_RAX:
> > ff13
> > [  582.091238] RAX:  RBX: 9eed12a5 RCX: 
> > 9c6ca1b6
> > [  582.092873] RDX: 0005 RSI: 9ee31d71 RDI: 
> > 9eed12a4
> > [  582.093934] RBP: 0078 R08: ed000d38dfb2 R09: 
> > ed000d38dfb1
> > [  582.095102] R10: 7350a3ba R11: 880069c6fd8f R12: 
> > 8800651bfa6e
> > [  582.096444] R13: 0001 R14: dc00 R15: 
> > 006a
> > [  582.097414]  ? kallsyms_expand_symbol.constprop.11+0x176/0x250
> > [  582.098518]  kallsyms_expand_symbol.constprop.11+0x12e/0x250
> > [  582.099707]  kallsyms_lookup_name+0xbe/0x1d0
> > [  582.100369]  ? kallsyms_on_each_symbol+0x210/0x210
> > [  582.101436]  ? snprintf+0xbd/0xf0
> > [  582.102029]  ? vsprintf+0x30/0x30
> > [  582.102805]  ? kasan_kmalloc+0xa9/0xd0
> > [  582.103489]  ? alloc_trace_kprobe+0x6c0/0x930
> > [  582.104073]  kprobe_on_func_entry+0x57/0xb0
> > [  582.105421]  register_kretprobe+0x89/0xc10
> > [  582.105930]  ? set_print_fmt+0x32/0xa0
> > [  582.106376]  __register_trace_kprobe.part.10+0x14e/0x2e0
> > [  582.106980]  create_local_trace_kprobe+0x29c/0x3f0
> > [  582.107487]  perf_kprobe_init+0x15f/0x210
> > [  582.107912]  perf_kprobe_event_init+0xc4/0x140
>
> I added Peter to the Cc, because he maintains perf.
>
> I have no idea what's going on here with kretprobes? Non-root can have
> kretprobes added to the kernel?
>
> -- Steve
>
>
> > [  582.108377]  perf_try_init_event+0xcb/0x290
> > [  582.108817]  perf_event_alloc+0x1476/0x2020
> > [  582.109264]  ? find_get_context.isra.106+0x690/0x690
> > [  582.109922]  ? __alloc_fd+0x1a3/0x4e0
> > [  582.120002]  __do_sys_perf_event_open+0x222/0x1f40
> > [  582.123049]  ? avc_has_perm_noaudit+0x340/0x340
> > [  582.131226]  ? perf_event_set_output+0x5f0/0x5f0
> > [  582.134395]  ? handle_mm_fault+0x103/0x350
> > [  582.138102]  ? ksys_ioctl+0x61/0x90
> > [  582.140234]  do_syscall_64+0x9a/0x2c0
> > [  582.142674]  ? prepare_exit_to_usermode+0xbc/0x150
> > [  582.146856]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > [  582.151127] RIP: 0033:0x446159
> > [  582.152816] Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00
> > 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24
> > 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 08 fc ff c3 66 2e 0f 1f 84 00 00
> > 00 00
> > [  582.167257] RSP: 002b:7fffc2b023d8 EFLAGS: 0246 ORIG_RAX:
> > 012a
> > [  582.171375] RAX: ffda RBX: 004002c8 RCX: 
> > 00446159
> > [  582.175760] RDX:  RSI:  RDI: 
> > 2180
> > [  582.176487] RBP: 7fffc2b025b0 R08:  R09: 
> > 
> > [  582.177189] R10: 

Re: [PATCH v1 2/2] x86/hyperv: make HvNotifyLongSpinWait hypercall

[Yi Sun]

On 18-10-19 16:20:52, Juergen Gross wrote:
> On 19/10/2018 15:13, Yi Sun wrote:

[...]

> > diff --git a/kernel/locking/qspinlock_paravirt.h 
> > b/kernel/locking/qspinlock_paravirt.h
> > index 0130e48..9e88c7e 100644
> > --- a/kernel/locking/qspinlock_paravirt.h
> > +++ b/kernel/locking/qspinlock_paravirt.h
> > @@ -7,6 +7,8 @@
> >  #include 
> >  #include 
> >  
> > +#include 
> > +
> >  /*
> >   * Implement paravirt qspinlocks; the general idea is to halt the vcpus 
> > instead
> >   * of spinning them.
> > @@ -305,6 +307,10 @@ static void pv_wait_node(struct mcs_spinlock *node, 
> > struct mcs_spinlock *prev)
> > wait_early = true;
> > break;
> > }
> > +#if defined(CONFIG_X86_64) && defined(CONFIG_PARAVIRT_SPINLOCKS) && 
> > IS_ENABLED(CONFIG_HYPERV)
> > +   if (!hv_notify_long_spin_wait(SPIN_THRESHOLD - loop))
> > +   break;
> > +#endif
> 
> I don't like that. Why should a KVM or Xen guest call into a hyperv
> specific function?
> 
> Can't you move this to existing hyperv specific paravirt hooks?
> 
hv_notify_long_spin_wait() must be called in this loop but it seems
there is no appropriate existing paravirt hook here. So, can I add
one more hook in pv_lock_ops to do this notification?

> 
> Juergen

Re: [PATCH v1 2/2] x86/hyperv: make HvNotifyLongSpinWait hypercall

[Yi Sun]

On 18-10-19 16:20:52, Juergen Gross wrote:
> On 19/10/2018 15:13, Yi Sun wrote:

[...]

> > diff --git a/kernel/locking/qspinlock_paravirt.h 
> > b/kernel/locking/qspinlock_paravirt.h
> > index 0130e48..9e88c7e 100644
> > --- a/kernel/locking/qspinlock_paravirt.h
> > +++ b/kernel/locking/qspinlock_paravirt.h
> > @@ -7,6 +7,8 @@
> >  #include 
> >  #include 
> >  
> > +#include 
> > +
> >  /*
> >   * Implement paravirt qspinlocks; the general idea is to halt the vcpus 
> > instead
> >   * of spinning them.
> > @@ -305,6 +307,10 @@ static void pv_wait_node(struct mcs_spinlock *node, 
> > struct mcs_spinlock *prev)
> > wait_early = true;
> > break;
> > }
> > +#if defined(CONFIG_X86_64) && defined(CONFIG_PARAVIRT_SPINLOCKS) && 
> > IS_ENABLED(CONFIG_HYPERV)
> > +   if (!hv_notify_long_spin_wait(SPIN_THRESHOLD - loop))
> > +   break;
> > +#endif
> 
> I don't like that. Why should a KVM or Xen guest call into a hyperv
> specific function?
> 
> Can't you move this to existing hyperv specific paravirt hooks?
> 
hv_notify_long_spin_wait() must be called in this loop but it seems
there is no appropriate existing paravirt hook here. So, can I add
one more hook in pv_lock_ops to do this notification?

> 
> Juergen

Re: [PATCH V9 11/21] csky: Atomic operations

[Guo Ren]

Thx Peter, 

Your review has been a great help.

On Sun, Oct 21, 2018 at 10:55:08PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 16, 2018 at 10:58:30AM +0800, Guo Ren wrote:
> > +   smp_mb();
> > +   lock->tickets.owner++;
> 
>   WRITE_ONCE(lock->tickets.owner, lock->tickets.owner + 1);
Yes, approve! I should use WRITE_ONCE/READ_ONCE as necessary.

> > +/*
> > + * Test-and-set spin-locking.
> > + */
> 
> I'm still not entirely sure why you want to have two spinlock
> implementations; to me that is just extra maintenance overhead.
Test and set (spinlock & rwlock) is easier for debug :P, and I don't
know the details of queue-rwlock (maybe I should learn it).

>From education's view, we could teach students both of them in
arch/csky :)

Anyway, I just want to keep both of them.

Thx

> > +   asm volatile (
> > +   "   movi%0, 0\n"
> > +   "   stw %0, (%1) \n"
> > +   : "=" (tmp)
> > +   : "r"(p)
> > +   : "cc");
> 
>   WRITE_ONCE(lock->lock, 0);
> ?
Cool ... I like WRITE_ONCE style. 

> > +
> > +#define arch_spin_is_locked(x) (READ_ONCE((x)->lock) != 0)
> > +
> > +/*
> > + * read lock/unlock/trylock
> > + */
> 
> Idem, why do you want a second rwlock_t implementation?
The same as above of spinlock.

> > +   asm volatile (
> > +   "1: ldex.w  %0, (%1) \n"
> > +   "   movi%0, 0\n"
> > +   "   stex.w  %0, (%1) \n"
> > +   "   bez %0, 1b   \n"
> > +   : "=" (tmp)
> > +   : "r"(p)
> > +   : "cc");
> 
> Isn't that:
> 
>   WRITE_ONCE(lock->lock, 0);
Yes, no need ldex/stex and you've mentioned in spinlock before :P

> > diff --git a/arch/csky/kernel/atomic.S b/arch/csky/kernel/atomic.S
> > new file mode 100644
> > index 000..d2357c8
> > --- /dev/null
> > +++ b/arch/csky/kernel/atomic.S
> > @@ -0,0 +1,87 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> > +
> > +#include 
> > +#include 
> > +
> > +.text
> > +
> > +/*
> > + * int csky_cmpxchg(int oldval, int newval, int *ptr)
> > + *
> > + * If *ptr != oldval && return 1,
> > + * else *ptr = newval return 0.
> > + */
> > +#ifdef CONFIG_CPU_HAS_LDSTEX
> > +ENTRY(csky_cmpxchg)
> > +   USPTOKSP
> > +   mfcra3, epc
> > +   INCTRAP a3
> > +
> > +   subisp, 8
> > +   stw a3, (sp, 0)
> > +   mfcra3, epsr
> > +   stw a3, (sp, 4)
> > + 
> > +   psrset  ee
> > +1:
> > +   ldexa3, (a2)
> > +   cmpne   a0, a3
> > +   bt162f
> > +   mov a3, a1
> > +   stexa3, (a2)
> > +   bez a3, 1b
> > +2:
> > +   sync.is
> > +   mvc a0
> > +   ldw a3, (sp, 0)
> > +   mtcra3, epc
> > +   ldw a3, (sp, 4)
> > +   mtcra3, epsr
> > +   addisp, 8
> > +   KSPTOUSP
> > +   rte
> > +END(csky_cmpxchg)
> 
> I don't understand why you have this; if the CPU has ll/sc, why do you
> need syscall support?
I've really considered your advice before, but from abi view 610/807/810
all have csky_cmpxchg trap and we want to make them the same. Some apps
use the trap directly and not use libc api. Maybe we could delete the
trap in future version of kernel.

> 
> In any case, nothing terminally broken; so I suppose that's good enough
> for starters. I just really don't understand some decisions (like having
> two lock implementations and having that cmpxchg syscall when you have
> hardware ll/sc).
> 
> Acked-by: Peter Zijlstra (Intel) 
Thx peter and the two questions which I've clarified in above.

Best Regards
 Guo Ren

Re: [PATCH V9 11/21] csky: Atomic operations

[Guo Ren]

Thx Peter, 

Your review has been a great help.

On Sun, Oct 21, 2018 at 10:55:08PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 16, 2018 at 10:58:30AM +0800, Guo Ren wrote:
> > +   smp_mb();
> > +   lock->tickets.owner++;
> 
>   WRITE_ONCE(lock->tickets.owner, lock->tickets.owner + 1);
Yes, approve! I should use WRITE_ONCE/READ_ONCE as necessary.

> > +/*
> > + * Test-and-set spin-locking.
> > + */
> 
> I'm still not entirely sure why you want to have two spinlock
> implementations; to me that is just extra maintenance overhead.
Test and set (spinlock & rwlock) is easier for debug :P, and I don't
know the details of queue-rwlock (maybe I should learn it).

>From education's view, we could teach students both of them in
arch/csky :)

Anyway, I just want to keep both of them.

Thx

> > +   asm volatile (
> > +   "   movi%0, 0\n"
> > +   "   stw %0, (%1) \n"
> > +   : "=" (tmp)
> > +   : "r"(p)
> > +   : "cc");
> 
>   WRITE_ONCE(lock->lock, 0);
> ?
Cool ... I like WRITE_ONCE style. 

> > +
> > +#define arch_spin_is_locked(x) (READ_ONCE((x)->lock) != 0)
> > +
> > +/*
> > + * read lock/unlock/trylock
> > + */
> 
> Idem, why do you want a second rwlock_t implementation?
The same as above of spinlock.

> > +   asm volatile (
> > +   "1: ldex.w  %0, (%1) \n"
> > +   "   movi%0, 0\n"
> > +   "   stex.w  %0, (%1) \n"
> > +   "   bez %0, 1b   \n"
> > +   : "=" (tmp)
> > +   : "r"(p)
> > +   : "cc");
> 
> Isn't that:
> 
>   WRITE_ONCE(lock->lock, 0);
Yes, no need ldex/stex and you've mentioned in spinlock before :P

> > diff --git a/arch/csky/kernel/atomic.S b/arch/csky/kernel/atomic.S
> > new file mode 100644
> > index 000..d2357c8
> > --- /dev/null
> > +++ b/arch/csky/kernel/atomic.S
> > @@ -0,0 +1,87 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> > +
> > +#include 
> > +#include 
> > +
> > +.text
> > +
> > +/*
> > + * int csky_cmpxchg(int oldval, int newval, int *ptr)
> > + *
> > + * If *ptr != oldval && return 1,
> > + * else *ptr = newval return 0.
> > + */
> > +#ifdef CONFIG_CPU_HAS_LDSTEX
> > +ENTRY(csky_cmpxchg)
> > +   USPTOKSP
> > +   mfcra3, epc
> > +   INCTRAP a3
> > +
> > +   subisp, 8
> > +   stw a3, (sp, 0)
> > +   mfcra3, epsr
> > +   stw a3, (sp, 4)
> > + 
> > +   psrset  ee
> > +1:
> > +   ldexa3, (a2)
> > +   cmpne   a0, a3
> > +   bt162f
> > +   mov a3, a1
> > +   stexa3, (a2)
> > +   bez a3, 1b
> > +2:
> > +   sync.is
> > +   mvc a0
> > +   ldw a3, (sp, 0)
> > +   mtcra3, epc
> > +   ldw a3, (sp, 4)
> > +   mtcra3, epsr
> > +   addisp, 8
> > +   KSPTOUSP
> > +   rte
> > +END(csky_cmpxchg)
> 
> I don't understand why you have this; if the CPU has ll/sc, why do you
> need syscall support?
I've really considered your advice before, but from abi view 610/807/810
all have csky_cmpxchg trap and we want to make them the same. Some apps
use the trap directly and not use libc api. Maybe we could delete the
trap in future version of kernel.

> 
> In any case, nothing terminally broken; so I suppose that's good enough
> for starters. I just really don't understand some decisions (like having
> two lock implementations and having that cmpxchg syscall when you have
> hardware ll/sc).
> 
> Acked-by: Peter Zijlstra (Intel) 
Thx peter and the two questions which I've clarified in above.

Best Regards
 Guo Ren

RE: [PATCH] thermal: qoriq: add i.mx8mq support

[Anson Huang]

Ping...

Anson Huang
Best Regards!


> -Original Message-
> From: Anson Huang
> Sent: Thursday, September 13, 2018 5:44 PM
> To: 'Rob Herring' 
> Cc: rui.zh...@intel.com; edubez...@gmail.com; robh...@kernel.org;
> mark.rutl...@arm.com; linux...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; dl-linux-imx
> 
> Subject: RE: [PATCH] thermal: qoriq: add i.mx8mq support
> 
> Gentle ping...
> 
> Anson Huang
> Best Regards!
> 
> 
> > -Original Message-
> > From: Rob Herring 
> > Sent: Tuesday, September 4, 2018 9:18 AM
> > To: Anson Huang 
> > Cc: rui.zh...@intel.com; edubez...@gmail.com; robh...@kernel.org;
> > mark.rutl...@arm.com; linux...@vger.kernel.org;
> > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; dl-linux-imx
> > 
> > Subject: Re: [PATCH] thermal: qoriq: add i.mx8mq support
> >
> > On Thu, 30 Aug 2018 10:14:46 +0800, Anson Huang wrote:
> > > Add i.mx8mq specific compatible string.
> > >
> > > Signed-off-by: Anson Huang 
> > > ---
> > >  Documentation/devicetree/bindings/thermal/qoriq-thermal.txt | 6 +++---
> > >  drivers/thermal/qoriq_thermal.c | 1 +
> > >  2 files changed, 4 insertions(+), 3 deletions(-)
> > >
> >
> > Reviewed-by: Rob Herring 

RE: [PATCH 1/2] thermal: imx: improve error message

[Anson Huang]

Ping...

Anson Huang
Best Regards!


> -Original Message-
> From: Anson Huang
> Sent: Friday, October 12, 2018 2:42 PM
> To: 'Daniel Lezcano' ; rui.zh...@intel.com;
> edubez...@gmail.com; linux...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: RE: [PATCH 1/2] thermal: imx: improve error message
> 
> Gentle ping this patch set
> 
> Anson Huang
> Best Regards!
> 
> 
> > -Original Message-
> > From: Daniel Lezcano 
> > Sent: Thursday, September 13, 2018 9:43 PM
> > To: Anson Huang ; rui.zh...@intel.com;
> > edubez...@gmail.com; linux...@vger.kernel.org;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH 1/2] thermal: imx: improve error message
> >
> > On 13/09/2018 11:13, Anson Huang wrote:
> > > Remove the duplicated "from" to improve the error message.
> > >
> > > Signed-off-by: Anson Huang 
> > > ---
> >
> > Reviewed-by: Daniel Lezcano 
> >
> > --
> >
> >
>  > .linaro.org%2Fdata=02%7C01%7CAnson.Huang%40nxp.com%7C74b0
> e3
> >
> 69dea442cd23ca08d6197ee518%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C
> >
> 0%7C0%7C636724430129789013sdata=C9l8QFt58YJVo5prvwHNqSiOP5
> > 4opUMPGOfzyV4PZFA%3Dreserved=0> Linaro.org │ Open source
> software
> > for ARM SoCs
> >
> > Follow Linaro:
> >
>  > .facebook.com%2Fpages%2FLinarodata=02%7C01%7CAnson.Huang%
> 40
> >
> nxp.com%7C74b0e369dea442cd23ca08d6197ee518%7C686ea1d3bc2b4c6fa92
> > cd99c5c301635%7C0%7C0%7C636724430129789013sdata=SqfGf6a4n
> > MQvO5dvAjhXPkxJRKxZm9%2FO37LLx8nBmJ4%3Dreserved=0>
> > Facebook |
> >  > tt
> er.com%2F%23!%2Flinaroorgdata=02%7C01%7CAnson.Huang%40nxp.c
> >
> om%7C74b0e369dea442cd23ca08d6197ee518%7C686ea1d3bc2b4c6fa92cd99
> >
> c5c301635%7C0%7C0%7C636724430129789013sdata=eOf2nvCdJErmV
> > ra12uxlZ42LFjjryHA3u4BqmEFhApE%3Dreserved=0> Twitter |
> >
>  > .linaro.org%2Flinaro-blog%2Fdata=02%7C01%7CAnson.Huang%40nxp.
> c
> >
> om%7C74b0e369dea442cd23ca08d6197ee518%7C686ea1d3bc2b4c6fa92cd99
> >
> c5c301635%7C0%7C0%7C636724430129789013sdata=Vcq2CZ3Wutz6Z
> > xQ77tpow30X2w%2FVsmj43yl1M53GcWU%3Dreserved=0> Blog

RE: [PATCH] thermal: qoriq: add i.mx8mq support

[Anson Huang]

Ping...

Anson Huang
Best Regards!


> -Original Message-
> From: Anson Huang
> Sent: Thursday, September 13, 2018 5:44 PM
> To: 'Rob Herring' 
> Cc: rui.zh...@intel.com; edubez...@gmail.com; robh...@kernel.org;
> mark.rutl...@arm.com; linux...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; dl-linux-imx
> 
> Subject: RE: [PATCH] thermal: qoriq: add i.mx8mq support
> 
> Gentle ping...
> 
> Anson Huang
> Best Regards!
> 
> 
> > -Original Message-
> > From: Rob Herring 
> > Sent: Tuesday, September 4, 2018 9:18 AM
> > To: Anson Huang 
> > Cc: rui.zh...@intel.com; edubez...@gmail.com; robh...@kernel.org;
> > mark.rutl...@arm.com; linux...@vger.kernel.org;
> > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; dl-linux-imx
> > 
> > Subject: Re: [PATCH] thermal: qoriq: add i.mx8mq support
> >
> > On Thu, 30 Aug 2018 10:14:46 +0800, Anson Huang wrote:
> > > Add i.mx8mq specific compatible string.
> > >
> > > Signed-off-by: Anson Huang 
> > > ---
> > >  Documentation/devicetree/bindings/thermal/qoriq-thermal.txt | 6 +++---
> > >  drivers/thermal/qoriq_thermal.c | 1 +
> > >  2 files changed, 4 insertions(+), 3 deletions(-)
> > >
> >
> > Reviewed-by: Rob Herring 

RE: [PATCH 1/2] thermal: imx: improve error message

[Anson Huang]

Ping...

Anson Huang
Best Regards!


> -Original Message-
> From: Anson Huang
> Sent: Friday, October 12, 2018 2:42 PM
> To: 'Daniel Lezcano' ; rui.zh...@intel.com;
> edubez...@gmail.com; linux...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: RE: [PATCH 1/2] thermal: imx: improve error message
> 
> Gentle ping this patch set
> 
> Anson Huang
> Best Regards!
> 
> 
> > -Original Message-
> > From: Daniel Lezcano 
> > Sent: Thursday, September 13, 2018 9:43 PM
> > To: Anson Huang ; rui.zh...@intel.com;
> > edubez...@gmail.com; linux...@vger.kernel.org;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH 1/2] thermal: imx: improve error message
> >
> > On 13/09/2018 11:13, Anson Huang wrote:
> > > Remove the duplicated "from" to improve the error message.
> > >
> > > Signed-off-by: Anson Huang 
> > > ---
> >
> > Reviewed-by: Daniel Lezcano 
> >
> > --
> >
> >
>  > .linaro.org%2Fdata=02%7C01%7CAnson.Huang%40nxp.com%7C74b0
> e3
> >
> 69dea442cd23ca08d6197ee518%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C
> >
> 0%7C0%7C636724430129789013sdata=C9l8QFt58YJVo5prvwHNqSiOP5
> > 4opUMPGOfzyV4PZFA%3Dreserved=0> Linaro.org │ Open source
> software
> > for ARM SoCs
> >
> > Follow Linaro:
> >
>  > .facebook.com%2Fpages%2FLinarodata=02%7C01%7CAnson.Huang%
> 40
> >
> nxp.com%7C74b0e369dea442cd23ca08d6197ee518%7C686ea1d3bc2b4c6fa92
> > cd99c5c301635%7C0%7C0%7C636724430129789013sdata=SqfGf6a4n
> > MQvO5dvAjhXPkxJRKxZm9%2FO37LLx8nBmJ4%3Dreserved=0>
> > Facebook |
> >  > tt
> er.com%2F%23!%2Flinaroorgdata=02%7C01%7CAnson.Huang%40nxp.c
> >
> om%7C74b0e369dea442cd23ca08d6197ee518%7C686ea1d3bc2b4c6fa92cd99
> >
> c5c301635%7C0%7C0%7C636724430129789013sdata=eOf2nvCdJErmV
> > ra12uxlZ42LFjjryHA3u4BqmEFhApE%3Dreserved=0> Twitter |
> >
>  > .linaro.org%2Flinaro-blog%2Fdata=02%7C01%7CAnson.Huang%40nxp.
> c
> >
> om%7C74b0e369dea442cd23ca08d6197ee518%7C686ea1d3bc2b4c6fa92cd99
> >
> c5c301635%7C0%7C0%7C636724430129789013sdata=Vcq2CZ3Wutz6Z
> > xQ77tpow30X2w%2FVsmj43yl1M53GcWU%3Dreserved=0> Blog

Re: [PATCH] memblock: remove stale #else and the code it protects

[Wei Yang]

On Sun, Oct 21, 2018 at 10:30:16AM +0300, Mike Rapoport wrote:
>
>
>On October 19, 2018 11:17:30 AM GMT+03:00, Wei Yang 
> wrote:
>>Which tree it applies?
>
>To mmotm of the end of September.
>

I may lost some background of this change.

The file I am looking at is
https://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git/tree/include/linux/memblock.h
which has CONFIG_HAVE_MEMBLOCK in line 5.

>>On Thu, Sep 27, 2018 at 08:03:45PM +0300, Mike Rapoport wrote:
>>>During removal of HAVE_MEMBLOCK definition, the #else clause of the
>>>
>>> #ifdef CONFIG_HAVE_MEMBLOCK
>>> ...
>>> #else
>>> ...
>>> #endif
>>>
>>>conditional was not removed.
>>>
>>>Remove it now.
>>>
>>>Signed-off-by: Mike Rapoport 
>>>Reported-by: Alexander Duyck 
>>>Cc: Michal Hocko 
>>>---
>>> include/linux/memblock.h | 5 -
>>> 1 file changed, 5 deletions(-)
>>>
>>>diff --git a/include/linux/memblock.h b/include/linux/memblock.h
>>>index d3bc270..d4d0e01 100644
>>>--- a/include/linux/memblock.h
>>>+++ b/include/linux/memblock.h
>>>@@ -597,11 +597,6 @@ static inline void early_memtest(phys_addr_t
>>start, phys_addr_t end)
>>> {
>>> }
>>> #endif
>>>-#else
>>>-static inline phys_addr_t memblock_alloc(phys_addr_t size,
>>phys_addr_t align)
>>>-{
>>>-return 0;
>>>-}
>>> 

And in that file, here is memblock_reserved_memory_within.

I guess this is not the version you are trying to fix.

BTW, if you could put the commit SHA which removes the
CONFIG_HAVE_MEMBLOCK, it would be easier for others to catch up.

>>> #endif /* __KERNEL__ */
>>> 
>>>-- 
>>>2.7.4
>
>-- 
>Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Wei Yang
Help you, Help me

Re: [PATCH] memblock: remove stale #else and the code it protects

[Wei Yang]

On Sun, Oct 21, 2018 at 10:30:16AM +0300, Mike Rapoport wrote:
>
>
>On October 19, 2018 11:17:30 AM GMT+03:00, Wei Yang 
> wrote:
>>Which tree it applies?
>
>To mmotm of the end of September.
>

I may lost some background of this change.

The file I am looking at is
https://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git/tree/include/linux/memblock.h
which has CONFIG_HAVE_MEMBLOCK in line 5.

>>On Thu, Sep 27, 2018 at 08:03:45PM +0300, Mike Rapoport wrote:
>>>During removal of HAVE_MEMBLOCK definition, the #else clause of the
>>>
>>> #ifdef CONFIG_HAVE_MEMBLOCK
>>> ...
>>> #else
>>> ...
>>> #endif
>>>
>>>conditional was not removed.
>>>
>>>Remove it now.
>>>
>>>Signed-off-by: Mike Rapoport 
>>>Reported-by: Alexander Duyck 
>>>Cc: Michal Hocko 
>>>---
>>> include/linux/memblock.h | 5 -
>>> 1 file changed, 5 deletions(-)
>>>
>>>diff --git a/include/linux/memblock.h b/include/linux/memblock.h
>>>index d3bc270..d4d0e01 100644
>>>--- a/include/linux/memblock.h
>>>+++ b/include/linux/memblock.h
>>>@@ -597,11 +597,6 @@ static inline void early_memtest(phys_addr_t
>>start, phys_addr_t end)
>>> {
>>> }
>>> #endif
>>>-#else
>>>-static inline phys_addr_t memblock_alloc(phys_addr_t size,
>>phys_addr_t align)
>>>-{
>>>-return 0;
>>>-}
>>> 

And in that file, here is memblock_reserved_memory_within.

I guess this is not the version you are trying to fix.

BTW, if you could put the commit SHA which removes the
CONFIG_HAVE_MEMBLOCK, it would be easier for others to catch up.

>>> #endif /* __KERNEL__ */
>>> 
>>>-- 
>>>2.7.4
>
>-- 
>Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Wei Yang
Help you, Help me

[tip:perf/core] kprobes/x86: Use preempt_enable() in optimized_callback()

[tip-bot for Masami Hiramatsu]

Commit-ID:  2e62024c265aa69315ed02835623740030435380
Gitweb: https://git.kernel.org/tip/2e62024c265aa69315ed02835623740030435380
Author: Masami Hiramatsu 
AuthorDate: Sat, 20 Oct 2018 18:47:53 +0900
Committer:  Ingo Molnar 
CommitDate: Mon, 22 Oct 2018 03:31:01 +0200

kprobes/x86: Use preempt_enable() in optimized_callback()

The following commit:

  a19b2e3d7839 ("kprobes/x86: Remove IRQ disabling from ftrace-based/optimized 
kprobes”)

removed local_irq_save/restore() from optimized_callback(), the handler
might be interrupted by the rescheduling interrupt and might be
rescheduled - so we must not use the preempt_enable_no_resched() macro.

Use preempt_enable() instead, to not lose preemption events.

[ mingo: Improved the changelog. ]

Reported-by: Nadav Amit 
Signed-off-by: Masami Hiramatsu 
Acked-by: Peter Zijlstra (Intel) 
Cc: 
Cc: Alexei Starovoitov 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Thomas Gleixner 
Cc: d...@amazon.co.uk
Fixes: a19b2e3d7839 ("kprobes/x86: Remove IRQ disabling from 
ftrace-based/optimized kprobes”)
Link: 
http://lkml.kernel.org/r/154002887331.7627.10194920925792947001.stgit@devbox
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/kprobes/opt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index eaf02f2e7300..40b16b270656 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -179,7 +179,7 @@ optimized_callback(struct optimized_kprobe *op, struct 
pt_regs *regs)
opt_pre_handler(>kp, regs);
__this_cpu_write(current_kprobe, NULL);
}
-   preempt_enable_no_resched();
+   preempt_enable();
 }
 NOKPROBE_SYMBOL(optimized_callback);
 

[tip:perf/core] kprobes/x86: Use preempt_enable() in optimized_callback()

[tip-bot for Masami Hiramatsu]

Commit-ID:  2e62024c265aa69315ed02835623740030435380
Gitweb: https://git.kernel.org/tip/2e62024c265aa69315ed02835623740030435380
Author: Masami Hiramatsu 
AuthorDate: Sat, 20 Oct 2018 18:47:53 +0900
Committer:  Ingo Molnar 
CommitDate: Mon, 22 Oct 2018 03:31:01 +0200

kprobes/x86: Use preempt_enable() in optimized_callback()

The following commit:

  a19b2e3d7839 ("kprobes/x86: Remove IRQ disabling from ftrace-based/optimized 
kprobes”)

removed local_irq_save/restore() from optimized_callback(), the handler
might be interrupted by the rescheduling interrupt and might be
rescheduled - so we must not use the preempt_enable_no_resched() macro.

Use preempt_enable() instead, to not lose preemption events.

[ mingo: Improved the changelog. ]

Reported-by: Nadav Amit 
Signed-off-by: Masami Hiramatsu 
Acked-by: Peter Zijlstra (Intel) 
Cc: 
Cc: Alexei Starovoitov 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Thomas Gleixner 
Cc: d...@amazon.co.uk
Fixes: a19b2e3d7839 ("kprobes/x86: Remove IRQ disabling from 
ftrace-based/optimized kprobes”)
Link: 
http://lkml.kernel.org/r/154002887331.7627.10194920925792947001.stgit@devbox
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/kprobes/opt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index eaf02f2e7300..40b16b270656 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -179,7 +179,7 @@ optimized_callback(struct optimized_kprobe *op, struct 
pt_regs *regs)
opt_pre_handler(>kp, regs);
__this_cpu_write(current_kprobe, NULL);
}
-   preempt_enable_no_resched();
+   preempt_enable();
 }
 NOKPROBE_SYMBOL(optimized_callback);
 

Can i trust you

[Mr Yi Gang]

Can i trust you with a transaction of usd 8.3m?($8,370.000.00) Reply me if 
interested
- Mr Yi Gang

Can i trust you

[Mr Yi Gang]

Can i trust you with a transaction of usd 8.3m?($8,370.000.00) Reply me if 
interested
- Mr Yi Gang

Re: [PATCH] jffs2: Fix use of uninitialized delayed_work, lockdep breakage

[Hou Tao]

On 2018/10/19 16:30, Daniel Santos wrote:
> jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
> is defined then a write buffer is available and has been initialized.
> However, this does is not the case when the mtd device has no
> out-of-band buffer:
> 
> int jffs2_nand_flash_setup(struct jffs2_sb_info *c)
> {
> if (!c->mtd->oobsize)
> return 0;
> ...
> 
> The resulting call to cancel_delayed_work_sync passing a uninitialized
> (but zeroed) delayed_work struct forces lockdep to become disabled.
> 
> [   90.050639] overlayfs: upper fs does not support tmpfile.
> [   90.652264] INFO: trying to register non-static key.
> [   90.662171] the code is fine but needs lockdep annotation.
> [   90.673090] turning off the locking correctness validator.
> [   90.684021] CPU: 0 PID: 1762 Comm: mount_root Not tainted 4.14.63 #0
> [   90.696672] Stack :   80d8f6a2 0038 805f 80444600 
> 8fe364f4 805dfbe7
> [   90.713349] 80563a30 06e2 8068370c 0001  0001 
> 8e2fdc48 
> [   90.730020]   80d9  0106  
> 6465746e 312e3420
> [   90.746690] 6b636f6c 03bf f800 20676e69  8000 
>  8e2c2a90
> [   90.763362] 80d9 0001  8e2c2a90 0003 80260dc0 
> 08052098 8068
> [   90.780033] ...
> [   90.784902] Call Trace:
> [   90.789793] [<8000f0d8>] show_stack+0xb8/0x148
> [   90.798659] [<8005a000>] register_lock_class+0x270/0x55c
> [   90.809247] [<8005cb64>] __lock_acquire+0x13c/0xf7c
> [   90.818964] [<8005e314>] lock_acquire+0x194/0x1dc
> [   90.828345] [<8003f27c>] flush_work+0x200/0x24c
> [   90.837374] [<80041dfc>] __cancel_work_timer+0x158/0x210
> [   90.847958] [<801a8770>] jffs2_sync_fs+0x20/0x54
> [   90.857173] [<80125cf4>] iterate_supers+0xf4/0x120
> [   90.866729] [<80158fc4>] sys_sync+0x44/0x9c
> [   90.875067] [<80014424>] syscall_common+0x34/0x58
> 
> Signed-off-by: Daniel Santos 
> ---
>  fs/jffs2/super.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
> index 793ad30970ff..cae4ecda3c50 100644
> --- a/fs/jffs2/super.c
> +++ b/fs/jffs2/super.c
> @@ -101,7 +101,8 @@ static int jffs2_sync_fs(struct super_block *sb, int wait)
>   struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
>  
>  #ifdef CONFIG_JFFS2_FS_WRITEBUFFER
> - cancel_delayed_work_sync(>wbuf_dwork);
> + if (jffs2_is_writebuffered(c))
> + cancel_delayed_work_sync(>wbuf_dwork);
>  #endif
>  
>   mutex_lock(>alloc_sem);
> 

Reviewed-by: Hou Tao 

And I am curious that why is there NAND Flash without OOB area ? So for them
the ECC data must be saved in data area ?

Regards,

Tao

Re: [PATCH] jffs2: Fix use of uninitialized delayed_work, lockdep breakage

[Hou Tao]

On 2018/10/19 16:30, Daniel Santos wrote:
> jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
> is defined then a write buffer is available and has been initialized.
> However, this does is not the case when the mtd device has no
> out-of-band buffer:
> 
> int jffs2_nand_flash_setup(struct jffs2_sb_info *c)
> {
> if (!c->mtd->oobsize)
> return 0;
> ...
> 
> The resulting call to cancel_delayed_work_sync passing a uninitialized
> (but zeroed) delayed_work struct forces lockdep to become disabled.
> 
> [   90.050639] overlayfs: upper fs does not support tmpfile.
> [   90.652264] INFO: trying to register non-static key.
> [   90.662171] the code is fine but needs lockdep annotation.
> [   90.673090] turning off the locking correctness validator.
> [   90.684021] CPU: 0 PID: 1762 Comm: mount_root Not tainted 4.14.63 #0
> [   90.696672] Stack :   80d8f6a2 0038 805f 80444600 
> 8fe364f4 805dfbe7
> [   90.713349] 80563a30 06e2 8068370c 0001  0001 
> 8e2fdc48 
> [   90.730020]   80d9  0106  
> 6465746e 312e3420
> [   90.746690] 6b636f6c 03bf f800 20676e69  8000 
>  8e2c2a90
> [   90.763362] 80d9 0001  8e2c2a90 0003 80260dc0 
> 08052098 8068
> [   90.780033] ...
> [   90.784902] Call Trace:
> [   90.789793] [<8000f0d8>] show_stack+0xb8/0x148
> [   90.798659] [<8005a000>] register_lock_class+0x270/0x55c
> [   90.809247] [<8005cb64>] __lock_acquire+0x13c/0xf7c
> [   90.818964] [<8005e314>] lock_acquire+0x194/0x1dc
> [   90.828345] [<8003f27c>] flush_work+0x200/0x24c
> [   90.837374] [<80041dfc>] __cancel_work_timer+0x158/0x210
> [   90.847958] [<801a8770>] jffs2_sync_fs+0x20/0x54
> [   90.857173] [<80125cf4>] iterate_supers+0xf4/0x120
> [   90.866729] [<80158fc4>] sys_sync+0x44/0x9c
> [   90.875067] [<80014424>] syscall_common+0x34/0x58
> 
> Signed-off-by: Daniel Santos 
> ---
>  fs/jffs2/super.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
> index 793ad30970ff..cae4ecda3c50 100644
> --- a/fs/jffs2/super.c
> +++ b/fs/jffs2/super.c
> @@ -101,7 +101,8 @@ static int jffs2_sync_fs(struct super_block *sb, int wait)
>   struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
>  
>  #ifdef CONFIG_JFFS2_FS_WRITEBUFFER
> - cancel_delayed_work_sync(>wbuf_dwork);
> + if (jffs2_is_writebuffered(c))
> + cancel_delayed_work_sync(>wbuf_dwork);
>  #endif
>  
>   mutex_lock(>alloc_sem);
> 

Reviewed-by: Hou Tao 

And I am curious that why is there NAND Flash without OOB area ? So for them
the ECC data must be saved in data area ?

Regards,

Tao

Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

[Theodore Y. Ts'o]

On Sun, Oct 21, 2018 at 11:26:08PM +0100, Josh Triplett wrote:
> On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> > I call on you, Greg:
> >  - to abandon this divisive attempt to impose a "Code of Conduct"
> >  - to revert 8a104f8b5867c68
> >  - to return to your core competence of building a great team around
> >a great kernel

I would point out that Greg did not chose to "impose" a Code of
Conduct.  That directive came from Linus; the change was signed off by
Linus, and the choice of the timing came from Linus.  That's why the
initial commit went in with very minimal review.  This series of
patches, especially the first two, have a very large number of
Acked-by sign-offs.  That's because there was a *huge* amount of
consultation with the top contributors to the kernel (using git
statistics) before the patch set was posted.

This level of consultation did not take place before Linus took his
break during -rc4, precisely because he didn't want people to think
that Greg did this "behind his back" and so there was no time to do
the sort of consultations which we did with this patch set.

(And when I say we, although the TAB was obviously involved, Greg did
most of the heavy lifting; and this is something that I can say
definitively Greg did out of a sense of duty, and because he was asked
to take on this role.  It obviously has *not* been a fun job, and Greg
has taken a lot of flak.  I, for one, thank Greg for taking on this
thankless task!)

> (I personally *do* want to see most of the patch series that started
> this particular thread dropped, because half of it undermines the point
> of the document. The original commit, however, is a matter of
> celebration.)

Josh, here I think it's clear a very large number of kernel developers
disagree with you.  Part of the concerns that led to creation of the
interpretation document was precisely because there was a lot of fear
mongering from people outside of the kernel development community,
some of them apparently from the Gamergate brigade.

And so while it is certainly true that a huge number of open source
projects use the Contributor's Convenant, and you don't see large
number of people getting "impeached" for stupid stuff from, say, the
GoLang project, there were a lot of people who *were* afraid that
perhaps, some of the insane/silly interpretations that had been flying
around might have actually been true.  Perhaps that's what Neil is so
worried about.

For example, it should have been obvious that if code is rejected for
technical reasons, some shadowy, unacountable group would ***not***
second guess the reasons for a maintainer's decision and magically
eject said maintainer from kernel development.  Maintainers still can
reject code for any technical reason, and in some cases, for good
non-technical reasons, such as the Netfilter team and code
contributions from someone who had been deemed, by his deeds, to be a
copyright troll.  And as always, people who disagree with a
maintainer's decision to reject a patch can always appeal directly to
Linus by sending the change to him.

The Linux kernel adopting the Contributor's Convenant was not going to
change this.  And certainly people haven't been using the
Contributor's Convenant to try to force crap ideas or crap code into
the Go language.  Unfortunately, because the Code of Conduct was
suddenly dropped in with minimal chance for consultations, that fear
was out there.  And that's why IMHO, the interpretation document
became necessary.

Ultimately, what we're after is a cultural change that will hopefully
strengthen the kernel community and make it a better place.  Neil is
correct that ultimately what's important is not words in a document,
but how people behave.  And so, if the words were causing a lot of
anxiety because were afraid that even accidental microagressions would
cause them to be permanently "impeached", and that failing to nit-pick
every possible microagression might be grounds for "impeaching" a
maintainer --- then making it clear that this is not what anyone had
in mind is a very important thing, since anxiety can lead to people
actively resist the cultural change which most of us are want and are
working towards.

Regards,
- Ted

Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

[Theodore Y. Ts'o]

On Sun, Oct 21, 2018 at 11:26:08PM +0100, Josh Triplett wrote:
> On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> > I call on you, Greg:
> >  - to abandon this divisive attempt to impose a "Code of Conduct"
> >  - to revert 8a104f8b5867c68
> >  - to return to your core competence of building a great team around
> >a great kernel

I would point out that Greg did not chose to "impose" a Code of
Conduct.  That directive came from Linus; the change was signed off by
Linus, and the choice of the timing came from Linus.  That's why the
initial commit went in with very minimal review.  This series of
patches, especially the first two, have a very large number of
Acked-by sign-offs.  That's because there was a *huge* amount of
consultation with the top contributors to the kernel (using git
statistics) before the patch set was posted.

This level of consultation did not take place before Linus took his
break during -rc4, precisely because he didn't want people to think
that Greg did this "behind his back" and so there was no time to do
the sort of consultations which we did with this patch set.

(And when I say we, although the TAB was obviously involved, Greg did
most of the heavy lifting; and this is something that I can say
definitively Greg did out of a sense of duty, and because he was asked
to take on this role.  It obviously has *not* been a fun job, and Greg
has taken a lot of flak.  I, for one, thank Greg for taking on this
thankless task!)

> (I personally *do* want to see most of the patch series that started
> this particular thread dropped, because half of it undermines the point
> of the document. The original commit, however, is a matter of
> celebration.)

Josh, here I think it's clear a very large number of kernel developers
disagree with you.  Part of the concerns that led to creation of the
interpretation document was precisely because there was a lot of fear
mongering from people outside of the kernel development community,
some of them apparently from the Gamergate brigade.

And so while it is certainly true that a huge number of open source
projects use the Contributor's Convenant, and you don't see large
number of people getting "impeached" for stupid stuff from, say, the
GoLang project, there were a lot of people who *were* afraid that
perhaps, some of the insane/silly interpretations that had been flying
around might have actually been true.  Perhaps that's what Neil is so
worried about.

For example, it should have been obvious that if code is rejected for
technical reasons, some shadowy, unacountable group would ***not***
second guess the reasons for a maintainer's decision and magically
eject said maintainer from kernel development.  Maintainers still can
reject code for any technical reason, and in some cases, for good
non-technical reasons, such as the Netfilter team and code
contributions from someone who had been deemed, by his deeds, to be a
copyright troll.  And as always, people who disagree with a
maintainer's decision to reject a patch can always appeal directly to
Linus by sending the change to him.

The Linux kernel adopting the Contributor's Convenant was not going to
change this.  And certainly people haven't been using the
Contributor's Convenant to try to force crap ideas or crap code into
the Go language.  Unfortunately, because the Code of Conduct was
suddenly dropped in with minimal chance for consultations, that fear
was out there.  And that's why IMHO, the interpretation document
became necessary.

Ultimately, what we're after is a cultural change that will hopefully
strengthen the kernel community and make it a better place.  Neil is
correct that ultimately what's important is not words in a document,
but how people behave.  And so, if the words were causing a lot of
anxiety because were afraid that even accidental microagressions would
cause them to be permanently "impeached", and that failing to nit-pick
every possible microagression might be grounds for "impeaching" a
maintainer --- then making it clear that this is not what anyone had
in mind is a very important thing, since anxiety can lead to people
actively resist the cultural change which most of us are want and are
working towards.

Regards,
- Ted

Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

[Eric S. Raymond]

Greg Kroah-Hartman :
> This patch series adds this new document to the kernel tree, as well as
> removes a paragraph from the existing Code of Conduct that was
> bothersome to many maintainers.

I think the changes have improved it.

There is still a process issue with how this code was promulgated that
is clearly bothering a lot of people, but I hope that problem is well
enough understood that we don't need to rehash it.  More transparency,
more consultation, and more notice of intent to revise would help
head off future problems.

I do have one content recommendation.  In the version at

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/code-of-conduct.rst

which I presume is current, I see a paragraph that reads as follows:

>In the interest of fostering an open and welcoming environment, we as
>contributors and maintainers pledge to making participation in our project and
>our community a harassment-free experience for everyone, regardless of age, 
>body
>size, disability, ethnicity, sex characteristics, gender identity and
>expression, level of experience, education, socio-economic status, nationality,
>personal appearance, race, religion, or sexual identity and orientation.

I recommend that all the text from "everyone" on be struck as (a) unnecessary,
and (b) tending to embroil the project in politico-cultural wars that can do
it no good - and replaced by "every individual".

That is, the result would read:

>In the interest of fostering an open and welcoming environment, we as
>contributors and maintainers pledge to making participation in our project and
>our community a harassment-free experience for every individual.

That is all that needs to be said. Listing all those specific
categories of "regardless of" implicitly privileges certain kinds of
identity (those listed) and disfavors others (those not listed).
Further, some of the phrases used fo categories are political
shibboleths that unavoidably drag in American presumptions not
appropriate for an international project.

Best to leave the whole mess out and just pledge to treat individuals well.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

[Eric S. Raymond]

Greg Kroah-Hartman :
> This patch series adds this new document to the kernel tree, as well as
> removes a paragraph from the existing Code of Conduct that was
> bothersome to many maintainers.

I think the changes have improved it.

There is still a process issue with how this code was promulgated that
is clearly bothering a lot of people, but I hope that problem is well
enough understood that we don't need to rehash it.  More transparency,
more consultation, and more notice of intent to revise would help
head off future problems.

I do have one content recommendation.  In the version at

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/code-of-conduct.rst

which I presume is current, I see a paragraph that reads as follows:

>In the interest of fostering an open and welcoming environment, we as
>contributors and maintainers pledge to making participation in our project and
>our community a harassment-free experience for everyone, regardless of age, 
>body
>size, disability, ethnicity, sex characteristics, gender identity and
>expression, level of experience, education, socio-economic status, nationality,
>personal appearance, race, religion, or sexual identity and orientation.

I recommend that all the text from "everyone" on be struck as (a) unnecessary,
and (b) tending to embroil the project in politico-cultural wars that can do
it no good - and replaced by "every individual".

That is, the result would read:

>In the interest of fostering an open and welcoming environment, we as
>contributors and maintainers pledge to making participation in our project and
>our community a harassment-free experience for every individual.

That is all that needs to be said. Listing all those specific
categories of "regardless of" implicitly privileges certain kinds of
identity (those listed) and disfavors others (those not listed).
Further, some of the phrases used fo categories are political
shibboleths that unavoidably drag in American presumptions not
appropriate for an international project.

Best to leave the whole mess out and just pledge to treat individuals well.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: [PATCH v5 1/2] x86/speculation: apply IBPB more strictly to avoid cross-process data leak

[Jiri Kosina]

On Sun, 21 Oct 2018, Pavel Machek wrote:

> Imagine JIT running evil code (flash, javascript). JIT will prevent evil 
> code from doing ptrace() (or maybe there is syscall filter in effect or 
> something like that), but if evil code can poison branch buffers and do 
> timings, security problem stays.

JITs sort of remove the traditional unix security domain boundary between 
mutually (un)trusted code (processess and threads), that's a more general 
problem, yes.

> Do we need prctl(I_DONT_RUN_EVIL_CODE)?

That's basically the level of fine-graining Tim's followup patchset 
(that's currently being discussed) is eventually going to achieve.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH v5 1/2] x86/speculation: apply IBPB more strictly to avoid cross-process data leak

[Jiri Kosina]

On Sun, 21 Oct 2018, Pavel Machek wrote:

> Imagine JIT running evil code (flash, javascript). JIT will prevent evil 
> code from doing ptrace() (or maybe there is syscall filter in effect or 
> something like that), but if evil code can poison branch buffers and do 
> timings, security problem stays.

JITs sort of remove the traditional unix security domain boundary between 
mutually (un)trusted code (processess and threads), that's a more general 
problem, yes.

> Do we need prctl(I_DONT_RUN_EVIL_CODE)?

That's basically the level of fine-graining Tim's followup patchset 
(that's currently being discussed) is eventually going to achieve.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

[Randy Dunlap]

On 10/21/18 3:33 PM, Joe Perches wrote:
> On Mon, 2018-10-22 at 08:20 +1100, NeilBrown wrote:
>> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:
>>> As everyone knows by now, we added a new Code of Conduct to the kernel
>>> tree a few weeks ago.
>>
>> I wanted to stay detached from all this, but as remaining (publicly)
>> silent might be seen (publicly) as acquiescing, I hereby declare that:
>>I reject, as illegitimate, this Code and the process by
>>which it is being "developed".
> []
>> I call on any other community members who reject this process to say so,
>> not to remain silent.
> 
> The concept of describing a desire for pleasant interactions
> while
> developing the linux kernel is legitimate and useful.

Agree.

> I do reject this process as well and I think the attempt to
> reform it via a private, non-public method is, at best,
> poor form.

and Agree.

> Joe Perches

Thanks.

-- 
~Randy

Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

[Randy Dunlap]

On 10/21/18 3:33 PM, Joe Perches wrote:
> On Mon, 2018-10-22 at 08:20 +1100, NeilBrown wrote:
>> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:
>>> As everyone knows by now, we added a new Code of Conduct to the kernel
>>> tree a few weeks ago.
>>
>> I wanted to stay detached from all this, but as remaining (publicly)
>> silent might be seen (publicly) as acquiescing, I hereby declare that:
>>I reject, as illegitimate, this Code and the process by
>>which it is being "developed".
> []
>> I call on any other community members who reject this process to say so,
>> not to remain silent.
> 
> The concept of describing a desire for pleasant interactions
> while
> developing the linux kernel is legitimate and useful.

Agree.

> I do reject this process as well and I think the attempt to
> reform it via a private, non-public method is, at best,
> poor form.

and Agree.

> Joe Perches

Thanks.

-- 
~Randy

Re: Reiser4 enhanced Debian 9.x Linux 4.18.xy series hung.

[Ben Hutchings]

On Sun, 2018-10-21 at 05:22 -0700, Metztli Information Technology
wrote:
> Niltze, all-
> 
> Ever since I build reiser4 -patched [1] Linux kernel 4.18.xy
> iterations I have had kernel hanging issues --which manifest
> themselves after considerable load and/or multitasking in my local
> development machine *and* in an vm instance running in Google Compute
> Engine (GCE).
[...]

Please keep debian-kernel out of this.  We have nothing to do with any
Reiser4 stuff.

Ben.

-- 
Ben Hutchings
Knowledge is power.  France is bacon.




signature.asc
Description: This is a digitally signed message part

Re: Reiser4 enhanced Debian 9.x Linux 4.18.xy series hung.

[Ben Hutchings]

On Sun, 2018-10-21 at 05:22 -0700, Metztli Information Technology
wrote:
> Niltze, all-
> 
> Ever since I build reiser4 -patched [1] Linux kernel 4.18.xy
> iterations I have had kernel hanging issues --which manifest
> themselves after considerable load and/or multitasking in my local
> development machine *and* in an vm instance running in Google Compute
> Engine (GCE).
[...]

Please keep debian-kernel out of this.  We have nothing to do with any
Reiser4 stuff.

Ben.

-- 
Ben Hutchings
Knowledge is power.  France is bacon.




signature.asc
Description: This is a digitally signed message part

Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

[Joe Perches]

On Mon, 2018-10-22 at 08:20 +1100, NeilBrown wrote:
> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:
> > As everyone knows by now, we added a new Code of Conduct to the kernel
> > tree a few weeks ago.
> 
> I wanted to stay detached from all this, but as remaining (publicly)
> silent might be seen (publicly) as acquiescing, I hereby declare that:
>I reject, as illegitimate, this Code and the process by
>which it is being "developed".
[]
> I call on any other community members who reject this process to say so,
> not to remain silent.

The concept of describing a desire for pleasant interactions
while
developing the linux kernel is legitimate and useful.

I do reject this process as well and I think the attempt to
reform it via a private, non-public method is, at best,
poor form.

Joe Perches

Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

[Joe Perches]

On Mon, 2018-10-22 at 08:20 +1100, NeilBrown wrote:
> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:
> > As everyone knows by now, we added a new Code of Conduct to the kernel
> > tree a few weeks ago.
> 
> I wanted to stay detached from all this, but as remaining (publicly)
> silent might be seen (publicly) as acquiescing, I hereby declare that:
>I reject, as illegitimate, this Code and the process by
>which it is being "developed".
[]
> I call on any other community members who reject this process to say so,
> not to remain silent.

The concept of describing a desire for pleasant interactions
while
developing the linux kernel is legitimate and useful.

I do reject this process as well and I think the attempt to
reform it via a private, non-public method is, at best,
poor form.

Joe Perches

Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

[Josh Triplett]

On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> I call on you, Greg:
>  - to abandon this divisive attempt to impose a "Code of Conduct"
>  - to revert 8a104f8b5867c68
>  - to return to your core competence of building a great team around
>a great kernel
> 
>  #Isupportreversion
> 
> I call on the community to consider what *does* need to be said, about
> conduct, to people outside the community and who have recently joined.
> What is the document that you would have liked to have read as you were
> starting out?  It is all too long ago for me to remember clearly, and so
> much has changed.

The document I would have liked to have read when starting out is
currently checked into the source tree in
Documentation/process/code-of-conduct.rst .

What is your actual concern? Why does it matter so much to you to push
back against this code of conduct? What does it say that you so
fundamentally object to?

(I personally *do* want to see most of the patch series that started
this particular thread dropped, because half of it undermines the point
of the document. The original commit, however, is a matter of
celebration.)

Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

[Josh Triplett]

On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> I call on you, Greg:
>  - to abandon this divisive attempt to impose a "Code of Conduct"
>  - to revert 8a104f8b5867c68
>  - to return to your core competence of building a great team around
>a great kernel
> 
>  #Isupportreversion
> 
> I call on the community to consider what *does* need to be said, about
> conduct, to people outside the community and who have recently joined.
> What is the document that you would have liked to have read as you were
> starting out?  It is all too long ago for me to remember clearly, and so
> much has changed.

The document I would have liked to have read when starting out is
currently checked into the source tree in
Documentation/process/code-of-conduct.rst .

What is your actual concern? Why does it matter so much to you to push
back against this code of conduct? What does it say that you so
fundamentally object to?

(I personally *do* want to see most of the patch series that started
this particular thread dropped, because half of it undermines the point
of the document. The original commit, however, is a matter of
celebration.)

Re: [PATCH] ALSA: hda/ca0132 - Actually fix microphone issue

[Takashi Iwai]

On Sun, 21 Oct 2018 19:53:03 +0200,
Connor McAdams wrote:
> 
> This patch fixes the microphone issue for all cards. The previous fix
> worked on the ZxR, but not on the AE-5 or Z. This patch has been tested
> to work for all cards.
> 
> Signed-off-by: Connor McAdams 

Thanks, that's a good news.  Merged now.


Takashi

Re: [PATCH] ALSA: hda/ca0132 - Actually fix microphone issue

[Takashi Iwai]

On Sun, 21 Oct 2018 19:53:03 +0200,
Connor McAdams wrote:
> 
> This patch fixes the microphone issue for all cards. The previous fix
> worked on the ZxR, but not on the AE-5 or Z. This patch has been tested
> to work for all cards.
> 
> Signed-off-by: Connor McAdams 

Thanks, that's a good news.  Merged now.


Takashi

[PATCH] thermal: bcm2835: enable hwmon explicitly

[matthias . bgg]

From: Matthias Brugger 

By defaul of-based thermal driver do not enable hwmon.
This patch does this explicitly, so that the temperature can be read
through the common hwmon sysfs.

Signed-off-by: Matthias Brugger 
---
 drivers/thermal/broadcom/bcm2835_thermal.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/thermal/broadcom/bcm2835_thermal.c 
b/drivers/thermal/broadcom/bcm2835_thermal.c
index 23ad4f9f2143..24b006a95142 100644
--- a/drivers/thermal/broadcom/bcm2835_thermal.c
+++ b/drivers/thermal/broadcom/bcm2835_thermal.c
@@ -27,6 +27,8 @@
 #include 
 #include 
 
+#include "../thermal_hwmon.h"
+
 #define BCM2835_TS_TSENSCTL0x00
 #define BCM2835_TS_TSENSSTAT   0x04
 
@@ -275,6 +277,15 @@ static int bcm2835_thermal_probe(struct platform_device 
*pdev)
 
platform_set_drvdata(pdev, tz);
 
+   /*
+* Thermal_zone doesn't enable hwmon as default,
+* enable it here
+*/
+   tz->tzp->no_hwmon = false;
+   err = thermal_add_hwmon_sysfs(tz);
+   if (err)
+   goto err_tz;
+
bcm2835_thermal_debugfs(pdev);
 
return 0;
-- 
2.19.1

[PATCH] thermal: bcm2835: enable hwmon explicitly

[matthias . bgg]

From: Matthias Brugger 

By defaul of-based thermal driver do not enable hwmon.
This patch does this explicitly, so that the temperature can be read
through the common hwmon sysfs.

Signed-off-by: Matthias Brugger 
---
 drivers/thermal/broadcom/bcm2835_thermal.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/thermal/broadcom/bcm2835_thermal.c 
b/drivers/thermal/broadcom/bcm2835_thermal.c
index 23ad4f9f2143..24b006a95142 100644
--- a/drivers/thermal/broadcom/bcm2835_thermal.c
+++ b/drivers/thermal/broadcom/bcm2835_thermal.c
@@ -27,6 +27,8 @@
 #include 
 #include 
 
+#include "../thermal_hwmon.h"
+
 #define BCM2835_TS_TSENSCTL0x00
 #define BCM2835_TS_TSENSSTAT   0x04
 
@@ -275,6 +277,15 @@ static int bcm2835_thermal_probe(struct platform_device 
*pdev)
 
platform_set_drvdata(pdev, tz);
 
+   /*
+* Thermal_zone doesn't enable hwmon as default,
+* enable it here
+*/
+   tz->tzp->no_hwmon = false;
+   err = thermal_add_hwmon_sysfs(tz);
+   if (err)
+   goto err_tz;
+
bcm2835_thermal_debugfs(pdev);
 
return 0;
-- 
2.19.1

Re: [RFC PATCH v2 02/17] soc/tegra: fuse: Export tegra_get_chip_id()

[Dmitry Osipenko]

On 10/21/18 11:54 PM, Dmitry Osipenko wrote:
> This function is used by tegra20-cpufreq driver which can be built as a
> kernel module.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/soc/tegra/fuse/tegra-apbmisc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/soc/tegra/fuse/tegra-apbmisc.c 
> b/drivers/soc/tegra/fuse/tegra-apbmisc.c
> index e5a4d8f98b10..c94dccf3eb30 100644
> --- a/drivers/soc/tegra/fuse/tegra-apbmisc.c
> +++ b/drivers/soc/tegra/fuse/tegra-apbmisc.c
> @@ -51,6 +51,7 @@ u8 tegra_get_chip_id(void)
>  {
>   return (tegra_read_chipid() >> 8) & 0xff;
>  }
> +EXPORT_SYMBOL_GPL(tegra_get_chip_id);
>  
>  u32 tegra_read_straps(void)
>  {
> 

A quick note.. I just recalled about existence of the 
of_machine_is_compatible() which will be more appropriate to use in the driver, 
hence this patch won't be needed.

Re: [RFC PATCH v2 02/17] soc/tegra: fuse: Export tegra_get_chip_id()

[Dmitry Osipenko]

On 10/21/18 11:54 PM, Dmitry Osipenko wrote:
> This function is used by tegra20-cpufreq driver which can be built as a
> kernel module.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/soc/tegra/fuse/tegra-apbmisc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/soc/tegra/fuse/tegra-apbmisc.c 
> b/drivers/soc/tegra/fuse/tegra-apbmisc.c
> index e5a4d8f98b10..c94dccf3eb30 100644
> --- a/drivers/soc/tegra/fuse/tegra-apbmisc.c
> +++ b/drivers/soc/tegra/fuse/tegra-apbmisc.c
> @@ -51,6 +51,7 @@ u8 tegra_get_chip_id(void)
>  {
>   return (tegra_read_chipid() >> 8) & 0xff;
>  }
> +EXPORT_SYMBOL_GPL(tegra_get_chip_id);
>  
>  u32 tegra_read_straps(void)
>  {
> 

A quick note.. I just recalled about existence of the 
of_machine_is_compatible() which will be more appropriate to use in the driver, 
hence this patch won't be needed.

Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

[NeilBrown]

On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:

> Hi all,
>
> As everyone knows by now, we added a new Code of Conduct to the kernel
> tree a few weeks ago.

I wanted to stay detached from all this, but as remaining (publicly)
silent might be seen (publicly) as acquiescing, I hereby declare that:
   I reject, as illegitimate, this Code and the process by
   which it is being "developed".

It is clear from the surrounding discussions that this is well outside our
core competencies.  It will be flawed, it isn't what we need.

I call on any other community members who reject this process to say so,
not to remain silent.
#Iobject

We don't need a "Code of Conduct" nearly as much as we need "Leadership
in conduct".  Without the leadership, any code looks like a joke.

I call on Linus Torvalds to follow up on his confession (which I think
is momentous and worth celebrating - Hurray!!!) with repentance - a clear
demonstration of change of mind.
  Linus: I know your intentions are good and am confident that, now that
  you see the problem, you will be able to effect a solution.  If you
  are not so confident, please be aware that there are many in the
  community who can see clearly where you were blind, and are willing to
  help guide and coach.  Please reach out to someone you trust, and ask.

I call on the community to respond to this confession and repentance
from Linus with forgiveness and restoration.

I have no direct hurts to report and little to forgive, so my
forgiveness can only be worth little.  However, for what it is worth:
  I offer to Linus, and to any who are seeking to improve their
  behaviour, my forgiveness for any past hurts, whether direct or
  indirect.  I hold no grudge, and wish to continue working together as
  the need and opportunity arises.

  #Iforgive

I call on the community to effect whatever reparation is possible to
those who have been hurt. Sometimes an apology is all that is possible,
sometimes it is all that is needed.  If you are ever in a position to do
more, please consider doing so.

  On behalf of my community, I apologise to all those who have been hurt
  by us, for the lack of respect and care which should have been shown.
  Where I have hurt you, whether through action or inaction, I
  unreservedly apologise.

  #Iapologise  (or #Iapologize :-)

I call on you, Greg:
 - to abandon this divisive attempt to impose a "Code of Conduct"
 - to revert 8a104f8b5867c68
 - to return to your core competence of building a great team around
   a great kernel

 #Isupportreversion

I call on the community to consider what *does* need to be said, about
conduct, to people outside the community and who have recently joined.
What is the document that you would have liked to have read as you were
starting out?  It is all too long ago for me to remember clearly, and so
much has changed.

Thanks,
NeilBrown
#Iobject #Iforgive #Iapologise #Isupportreversion


signature.asc
Description: PGP signature

Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

[NeilBrown]

On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:

> Hi all,
>
> As everyone knows by now, we added a new Code of Conduct to the kernel
> tree a few weeks ago.

I wanted to stay detached from all this, but as remaining (publicly)
silent might be seen (publicly) as acquiescing, I hereby declare that:
   I reject, as illegitimate, this Code and the process by
   which it is being "developed".

It is clear from the surrounding discussions that this is well outside our
core competencies.  It will be flawed, it isn't what we need.

I call on any other community members who reject this process to say so,
not to remain silent.
#Iobject

We don't need a "Code of Conduct" nearly as much as we need "Leadership
in conduct".  Without the leadership, any code looks like a joke.

I call on Linus Torvalds to follow up on his confession (which I think
is momentous and worth celebrating - Hurray!!!) with repentance - a clear
demonstration of change of mind.
  Linus: I know your intentions are good and am confident that, now that
  you see the problem, you will be able to effect a solution.  If you
  are not so confident, please be aware that there are many in the
  community who can see clearly where you were blind, and are willing to
  help guide and coach.  Please reach out to someone you trust, and ask.

I call on the community to respond to this confession and repentance
from Linus with forgiveness and restoration.

I have no direct hurts to report and little to forgive, so my
forgiveness can only be worth little.  However, for what it is worth:
  I offer to Linus, and to any who are seeking to improve their
  behaviour, my forgiveness for any past hurts, whether direct or
  indirect.  I hold no grudge, and wish to continue working together as
  the need and opportunity arises.

  #Iforgive

I call on the community to effect whatever reparation is possible to
those who have been hurt. Sometimes an apology is all that is possible,
sometimes it is all that is needed.  If you are ever in a position to do
more, please consider doing so.

  On behalf of my community, I apologise to all those who have been hurt
  by us, for the lack of respect and care which should have been shown.
  Where I have hurt you, whether through action or inaction, I
  unreservedly apologise.

  #Iapologise  (or #Iapologize :-)

I call on you, Greg:
 - to abandon this divisive attempt to impose a "Code of Conduct"
 - to revert 8a104f8b5867c68
 - to return to your core competence of building a great team around
   a great kernel

 #Isupportreversion

I call on the community to consider what *does* need to be said, about
conduct, to people outside the community and who have recently joined.
What is the document that you would have liked to have read as you were
starting out?  It is all too long ago for me to remember clearly, and so
much has changed.

Thanks,
NeilBrown
#Iobject #Iforgive #Iapologise #Isupportreversion


signature.asc
Description: PGP signature

[RFC PATCH v2 02/17] soc/tegra: fuse: Export tegra_get_chip_id()

[Dmitry Osipenko]

This function is used by tegra20-cpufreq driver which can be built as a
kernel module.

Signed-off-by: Dmitry Osipenko 
---
 drivers/soc/tegra/fuse/tegra-apbmisc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/soc/tegra/fuse/tegra-apbmisc.c 
b/drivers/soc/tegra/fuse/tegra-apbmisc.c
index e5a4d8f98b10..c94dccf3eb30 100644
--- a/drivers/soc/tegra/fuse/tegra-apbmisc.c
+++ b/drivers/soc/tegra/fuse/tegra-apbmisc.c
@@ -51,6 +51,7 @@ u8 tegra_get_chip_id(void)
 {
return (tegra_read_chipid() >> 8) & 0xff;
 }
+EXPORT_SYMBOL_GPL(tegra_get_chip_id);
 
 u32 tegra_read_straps(void)
 {
-- 
2.19.0

[RFC PATCH v2 02/17] soc/tegra: fuse: Export tegra_get_chip_id()

[Dmitry Osipenko]

This function is used by tegra20-cpufreq driver which can be built as a
kernel module.

Signed-off-by: Dmitry Osipenko 
---
 drivers/soc/tegra/fuse/tegra-apbmisc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/soc/tegra/fuse/tegra-apbmisc.c 
b/drivers/soc/tegra/fuse/tegra-apbmisc.c
index e5a4d8f98b10..c94dccf3eb30 100644
--- a/drivers/soc/tegra/fuse/tegra-apbmisc.c
+++ b/drivers/soc/tegra/fuse/tegra-apbmisc.c
@@ -51,6 +51,7 @@ u8 tegra_get_chip_id(void)
 {
return (tegra_read_chipid() >> 8) & 0xff;
 }
+EXPORT_SYMBOL_GPL(tegra_get_chip_id);
 
 u32 tegra_read_straps(void)
 {
-- 
2.19.0

[RFC PATCH v2 01/17] OPP: Allow to request stub voltage regulators

[Dmitry Osipenko]

Voltage regulators may be not available on some variations of HW, allow to
request stub voltage regulators by OPP core in a such case to reduce code
churning within drivers.

Signed-off-by: Dmitry Osipenko 
---
 drivers/cpufreq/cpufreq-dt.c | 2 +-
 drivers/cpufreq/ti-cpufreq.c | 3 ++-
 drivers/opp/core.c   | 9 +++--
 include/linux/pm_opp.h   | 4 ++--
 4 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index e58bfcb1169e..6ebca472ec76 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -196,7 +196,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
 */
name = find_supply_name(cpu_dev);
if (name) {
-   opp_table = dev_pm_opp_set_regulators(cpu_dev, , 1);
+   opp_table = dev_pm_opp_set_regulators(cpu_dev, , 1, false);
if (IS_ERR(opp_table)) {
ret = PTR_ERR(opp_table);
dev_err(cpu_dev, "Failed to set regulator for cpu%d: 
%d\n",
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index 3f0e2a14895a..9099c8cdf447 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -268,7 +268,8 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
if (opp_data->soc_data->multi_regulator) {
ti_opp_table = dev_pm_opp_set_regulators(opp_data->cpu_dev,
 reg_names,
-ARRAY_SIZE(reg_names));
+ARRAY_SIZE(reg_names),
+false);
if (IS_ERR(ti_opp_table)) {
dev_pm_opp_put_supported_hw(opp_data->opp_table);
ret =  PTR_ERR(ti_opp_table);
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 2c2df4e4fc14..fba1d7a1eb7c 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1365,6 +1365,7 @@ static void _free_set_opp_data(struct opp_table 
*opp_table)
  * @dev: Device for which regulator name is being set.
  * @names: Array of pointers to the names of the regulator.
  * @count: Number of regulators.
+ * @allow_stub_regulator: Some or all regulators can be missed.
  *
  * In order to support OPP switching, OPP layer needs to know the name of the
  * device's regulators, as the core would be required to switch voltages as
@@ -1374,7 +1375,8 @@ static void _free_set_opp_data(struct opp_table 
*opp_table)
  */
 struct opp_table *dev_pm_opp_set_regulators(struct device *dev,
const char * const names[],
-   unsigned int count)
+   unsigned int count,
+   bool allow_stub_regulator)
 {
struct opp_table *opp_table;
struct regulator *reg;
@@ -1403,7 +1405,10 @@ struct opp_table *dev_pm_opp_set_regulators(struct 
device *dev,
}
 
for (i = 0; i < count; i++) {
-   reg = regulator_get_optional(dev, names[i]);
+   if (allow_stub_regulator)
+   reg = regulator_get(dev, names[i]);
+   else
+   reg = regulator_get_optional(dev, names[i]);
if (IS_ERR(reg)) {
ret = PTR_ERR(reg);
if (ret != -EPROBE_DEFER)
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 5d399eeef172..480666b0a008 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -120,7 +120,7 @@ struct opp_table *dev_pm_opp_set_supported_hw(struct device 
*dev, const u32 *ver
 void dev_pm_opp_put_supported_hw(struct opp_table *opp_table);
 struct opp_table *dev_pm_opp_set_prop_name(struct device *dev, const char 
*name);
 void dev_pm_opp_put_prop_name(struct opp_table *opp_table);
-struct opp_table *dev_pm_opp_set_regulators(struct device *dev, const char * 
const names[], unsigned int count);
+struct opp_table *dev_pm_opp_set_regulators(struct device *dev, const char * 
const names[], unsigned int count, bool allow_stub_regulator);
 void dev_pm_opp_put_regulators(struct opp_table *opp_table);
 struct opp_table *dev_pm_opp_set_clkname(struct device *dev, const char * 
name);
 void dev_pm_opp_put_clkname(struct opp_table *opp_table);
@@ -258,7 +258,7 @@ static inline struct opp_table 
*dev_pm_opp_set_prop_name(struct device *dev, con
 
 static inline void dev_pm_opp_put_prop_name(struct opp_table *opp_table) {}
 
-static inline struct opp_table *dev_pm_opp_set_regulators(struct device *dev, 
const char * const names[], unsigned int count)
+static inline struct opp_table *dev_pm_opp_set_regulators(struct device *dev, 
const char * const names[], unsigned int count, bool allow_stub_regulator)
 {
return ERR_PTR(-ENOTSUPP);
 }
-- 
2.19.0

[RFC PATCH v2 01/17] OPP: Allow to request stub voltage regulators

[Dmitry Osipenko]

Voltage regulators may be not available on some variations of HW, allow to
request stub voltage regulators by OPP core in a such case to reduce code
churning within drivers.

Signed-off-by: Dmitry Osipenko 
---
 drivers/cpufreq/cpufreq-dt.c | 2 +-
 drivers/cpufreq/ti-cpufreq.c | 3 ++-
 drivers/opp/core.c   | 9 +++--
 include/linux/pm_opp.h   | 4 ++--
 4 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index e58bfcb1169e..6ebca472ec76 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -196,7 +196,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
 */
name = find_supply_name(cpu_dev);
if (name) {
-   opp_table = dev_pm_opp_set_regulators(cpu_dev, , 1);
+   opp_table = dev_pm_opp_set_regulators(cpu_dev, , 1, false);
if (IS_ERR(opp_table)) {
ret = PTR_ERR(opp_table);
dev_err(cpu_dev, "Failed to set regulator for cpu%d: 
%d\n",
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index 3f0e2a14895a..9099c8cdf447 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -268,7 +268,8 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
if (opp_data->soc_data->multi_regulator) {
ti_opp_table = dev_pm_opp_set_regulators(opp_data->cpu_dev,
 reg_names,
-ARRAY_SIZE(reg_names));
+ARRAY_SIZE(reg_names),
+false);
if (IS_ERR(ti_opp_table)) {
dev_pm_opp_put_supported_hw(opp_data->opp_table);
ret =  PTR_ERR(ti_opp_table);
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 2c2df4e4fc14..fba1d7a1eb7c 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1365,6 +1365,7 @@ static void _free_set_opp_data(struct opp_table 
*opp_table)
  * @dev: Device for which regulator name is being set.
  * @names: Array of pointers to the names of the regulator.
  * @count: Number of regulators.
+ * @allow_stub_regulator: Some or all regulators can be missed.
  *
  * In order to support OPP switching, OPP layer needs to know the name of the
  * device's regulators, as the core would be required to switch voltages as
@@ -1374,7 +1375,8 @@ static void _free_set_opp_data(struct opp_table 
*opp_table)
  */
 struct opp_table *dev_pm_opp_set_regulators(struct device *dev,
const char * const names[],
-   unsigned int count)
+   unsigned int count,
+   bool allow_stub_regulator)
 {
struct opp_table *opp_table;
struct regulator *reg;
@@ -1403,7 +1405,10 @@ struct opp_table *dev_pm_opp_set_regulators(struct 
device *dev,
}
 
for (i = 0; i < count; i++) {
-   reg = regulator_get_optional(dev, names[i]);
+   if (allow_stub_regulator)
+   reg = regulator_get(dev, names[i]);
+   else
+   reg = regulator_get_optional(dev, names[i]);
if (IS_ERR(reg)) {
ret = PTR_ERR(reg);
if (ret != -EPROBE_DEFER)
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 5d399eeef172..480666b0a008 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -120,7 +120,7 @@ struct opp_table *dev_pm_opp_set_supported_hw(struct device 
*dev, const u32 *ver
 void dev_pm_opp_put_supported_hw(struct opp_table *opp_table);
 struct opp_table *dev_pm_opp_set_prop_name(struct device *dev, const char 
*name);
 void dev_pm_opp_put_prop_name(struct opp_table *opp_table);
-struct opp_table *dev_pm_opp_set_regulators(struct device *dev, const char * 
const names[], unsigned int count);
+struct opp_table *dev_pm_opp_set_regulators(struct device *dev, const char * 
const names[], unsigned int count, bool allow_stub_regulator);
 void dev_pm_opp_put_regulators(struct opp_table *opp_table);
 struct opp_table *dev_pm_opp_set_clkname(struct device *dev, const char * 
name);
 void dev_pm_opp_put_clkname(struct opp_table *opp_table);
@@ -258,7 +258,7 @@ static inline struct opp_table 
*dev_pm_opp_set_prop_name(struct device *dev, con
 
 static inline void dev_pm_opp_put_prop_name(struct opp_table *opp_table) {}
 
-static inline struct opp_table *dev_pm_opp_set_regulators(struct device *dev, 
const char * const names[], unsigned int count)
+static inline struct opp_table *dev_pm_opp_set_regulators(struct device *dev, 
const char * const names[], unsigned int count, bool allow_stub_regulator)
 {
return ERR_PTR(-ENOTSUPP);
 }
-- 
2.19.0

[RFC PATCH v2 05/17] ARM: tegra: Create tegra20-cpufreq device on Tegra30

[Dmitry Osipenko]

Tegra20-cpufreq driver require a platform device in order to be loaded,
instantiate a simple platform device for the driver during of the machines
late initialization. Driver now supports Tegra30 SoC's, hence create the
device on Tegra30 machines.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/mach-tegra/tegra.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index 67d8ae60ac67..b559e22eab76 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -111,6 +111,10 @@ static void __init tegra_dt_init_late(void)
if (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC) &&
of_machine_is_compatible("nvidia,tegra20"))
platform_device_register_simple("tegra20-cpufreq", -1, NULL, 0);
+
+   if (IS_ENABLED(CONFIG_ARCH_TEGRA_3x_SOC) &&
+   of_machine_is_compatible("nvidia,tegra30"))
+   platform_device_register_simple("tegra20-cpufreq", -1, NULL, 0);
 }
 
 static const char * const tegra_dt_board_compat[] = {
-- 
2.19.0

[RFC PATCH v2 05/17] ARM: tegra: Create tegra20-cpufreq device on Tegra30

[Dmitry Osipenko]

Tegra20-cpufreq driver require a platform device in order to be loaded,
instantiate a simple platform device for the driver during of the machines
late initialization. Driver now supports Tegra30 SoC's, hence create the
device on Tegra30 machines.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/mach-tegra/tegra.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index 67d8ae60ac67..b559e22eab76 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -111,6 +111,10 @@ static void __init tegra_dt_init_late(void)
if (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC) &&
of_machine_is_compatible("nvidia,tegra20"))
platform_device_register_simple("tegra20-cpufreq", -1, NULL, 0);
+
+   if (IS_ENABLED(CONFIG_ARCH_TEGRA_3x_SOC) &&
+   of_machine_is_compatible("nvidia,tegra30"))
+   platform_device_register_simple("tegra20-cpufreq", -1, NULL, 0);
 }
 
 static const char * const tegra_dt_board_compat[] = {
-- 
2.19.0

[RFC PATCH v2 04/17] cpufreq: tegra20: Support OPP, thermal cooling, DVFS and Tegra30

[Dmitry Osipenko]

Add support for thermal throttling, Operating Performance Points and DVFS.
Driver now relies on OPP's supplied via device tree and therefore will
work only on devices that use the updated device tree. The generalization
of the driver allows to transparently support Tegra30.

Signed-off-by: Dmitry Osipenko 
---
 drivers/cpufreq/Kconfig.arm  |   2 +
 drivers/cpufreq/cpufreq-dt-platdev.c |   2 +
 drivers/cpufreq/tegra20-cpufreq.c| 832 +++
 3 files changed, 734 insertions(+), 102 deletions(-)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 0cd8eb76ad59..78795d108f5e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -262,7 +262,9 @@ config ARM_TANGO_CPUFREQ
 
 config ARM_TEGRA20_CPUFREQ
tristate "Tegra20 CPUFreq support"
+   depends on !CPU_THERMAL || THERMAL
depends on ARCH_TEGRA
+   select PM_OPP
default y
help
  This adds the CPUFreq driver support for Tegra20 SOCs.
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
b/drivers/cpufreq/cpufreq-dt-platdev.c
index b1c5468dca16..ecc4d3d14850 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -118,6 +118,8 @@ static const struct of_device_id blacklist[] __initconst = {
{ .compatible = "mediatek,mt8173", },
{ .compatible = "mediatek,mt8176", },
 
+   { .compatible = "nvidia,tegra20", },
+   { .compatible = "nvidia,tegra30", },
{ .compatible = "nvidia,tegra124", },
 
{ .compatible = "qcom,apq8096", },
diff --git a/drivers/cpufreq/tegra20-cpufreq.c 
b/drivers/cpufreq/tegra20-cpufreq.c
index 05f57dcd5215..a7d1c2899e3c 100644
--- a/drivers/cpufreq/tegra20-cpufreq.c
+++ b/drivers/cpufreq/tegra20-cpufreq.c
@@ -17,220 +17,848 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
+#include 
 #include 
+#include 
 
-static struct cpufreq_frequency_table freq_table[] = {
-   { .frequency = 216000 },
-   { .frequency = 312000 },
-   { .frequency = 456000 },
-   { .frequency = 608000 },
-   { .frequency = 76 },
-   { .frequency = 816000 },
-   { .frequency = 912000 },
-   { .frequency = 100 },
-   { .frequency = CPUFREQ_TABLE_END },
-};
+#include 
+
+#define PLLX_PREPARE   BIT(0)
+#define PLLX_PREPARED  BIT(1)
 
-struct tegra20_cpufreq {
+struct tegra_cpufreq {
struct device *dev;
+   struct device *cpu_dev;
+   struct regulator *reg_cpu;
+   struct regulator *reg_core;
+   struct regulator *reg_rtc;
+   struct opp_table *opp_table;
struct cpufreq_driver driver;
+   struct thermal_cooling_device *cdev;
+   struct cpufreq_frequency_table *freq_table;
struct clk *cpu_clk;
struct clk *pll_x_clk;
-   struct clk *pll_p_clk;
-   bool pll_x_prepared;
+   struct clk *intermediate_clk;
+   unsigned long intermediate_rate;
+   unsigned int state;
+   unsigned int chip;
+   int cpu_speedo_id;
+
+   /* deferred voltage change */
+   struct delayed_work work;
+   struct dev_pm_opp_supply supply_cpu;
+   unsigned long actual_cpu_uV;
 };
 
+static unsigned int voltage_drop_interval_ms = 500;
+
 static unsigned int tegra_get_intermediate(struct cpufreq_policy *policy,
   unsigned int index)
 {
-   struct tegra20_cpufreq *cpufreq = cpufreq_get_driver_data();
-   unsigned int ifreq = clk_get_rate(cpufreq->pll_p_clk) / 1000;
+   struct tegra_cpufreq *cpufreq = cpufreq_get_driver_data();
+   struct clk *cpu_parent = clk_get_parent(cpufreq->cpu_clk);
+   unsigned long new_rate = cpufreq->freq_table[index].frequency * 1000;
+   int err;
 
/*
-* Don't switch to intermediate freq if:
-* - we are already at it, i.e. policy->cur == ifreq
-* - index corresponds to ifreq
+* Make sure that intermediate clock rate stays consistent during
+* transition by entering into critical section of the intermediate
+* clock.
 */
-   if (freq_table[index].frequency == ifreq || policy->cur == ifreq)
+   err = clk_rate_exclusive_get(cpufreq->intermediate_clk);
+   /* this shouldn't fail */
+   WARN_ON_ONCE(err);
+
+   /*
+* When target rate is equal to intermediate rate, we don't need to
+* switch to intermediate clock and so the intermediate routine isn't
+* called. Also, we wouldn't be using PLLX anymore and must not
+* take extra reference to it, as it can be disabled to save some
+* power.
+*/
+   cpufreq->intermediate_rate = clk_get_rate(cpufreq->intermediate_clk);
+
+   if (new_rate == cpufreq->intermediate_rate)
+   cpufreq->state &= ~PLLX_PREPARE;
+   else
+   cpufreq->state |= PLLX_PREPARE;
+
+   /* don't switch to intermediate 

[RFC PATCH v2 04/17] cpufreq: tegra20: Support OPP, thermal cooling, DVFS and Tegra30

[Dmitry Osipenko]

Add support for thermal throttling, Operating Performance Points and DVFS.
Driver now relies on OPP's supplied via device tree and therefore will
work only on devices that use the updated device tree. The generalization
of the driver allows to transparently support Tegra30.

Signed-off-by: Dmitry Osipenko 
---
 drivers/cpufreq/Kconfig.arm  |   2 +
 drivers/cpufreq/cpufreq-dt-platdev.c |   2 +
 drivers/cpufreq/tegra20-cpufreq.c| 832 +++
 3 files changed, 734 insertions(+), 102 deletions(-)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 0cd8eb76ad59..78795d108f5e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -262,7 +262,9 @@ config ARM_TANGO_CPUFREQ
 
 config ARM_TEGRA20_CPUFREQ
tristate "Tegra20 CPUFreq support"
+   depends on !CPU_THERMAL || THERMAL
depends on ARCH_TEGRA
+   select PM_OPP
default y
help
  This adds the CPUFreq driver support for Tegra20 SOCs.
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
b/drivers/cpufreq/cpufreq-dt-platdev.c
index b1c5468dca16..ecc4d3d14850 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -118,6 +118,8 @@ static const struct of_device_id blacklist[] __initconst = {
{ .compatible = "mediatek,mt8173", },
{ .compatible = "mediatek,mt8176", },
 
+   { .compatible = "nvidia,tegra20", },
+   { .compatible = "nvidia,tegra30", },
{ .compatible = "nvidia,tegra124", },
 
{ .compatible = "qcom,apq8096", },
diff --git a/drivers/cpufreq/tegra20-cpufreq.c 
b/drivers/cpufreq/tegra20-cpufreq.c
index 05f57dcd5215..a7d1c2899e3c 100644
--- a/drivers/cpufreq/tegra20-cpufreq.c
+++ b/drivers/cpufreq/tegra20-cpufreq.c
@@ -17,220 +17,848 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
+#include 
 #include 
+#include 
 
-static struct cpufreq_frequency_table freq_table[] = {
-   { .frequency = 216000 },
-   { .frequency = 312000 },
-   { .frequency = 456000 },
-   { .frequency = 608000 },
-   { .frequency = 76 },
-   { .frequency = 816000 },
-   { .frequency = 912000 },
-   { .frequency = 100 },
-   { .frequency = CPUFREQ_TABLE_END },
-};
+#include 
+
+#define PLLX_PREPARE   BIT(0)
+#define PLLX_PREPARED  BIT(1)
 
-struct tegra20_cpufreq {
+struct tegra_cpufreq {
struct device *dev;
+   struct device *cpu_dev;
+   struct regulator *reg_cpu;
+   struct regulator *reg_core;
+   struct regulator *reg_rtc;
+   struct opp_table *opp_table;
struct cpufreq_driver driver;
+   struct thermal_cooling_device *cdev;
+   struct cpufreq_frequency_table *freq_table;
struct clk *cpu_clk;
struct clk *pll_x_clk;
-   struct clk *pll_p_clk;
-   bool pll_x_prepared;
+   struct clk *intermediate_clk;
+   unsigned long intermediate_rate;
+   unsigned int state;
+   unsigned int chip;
+   int cpu_speedo_id;
+
+   /* deferred voltage change */
+   struct delayed_work work;
+   struct dev_pm_opp_supply supply_cpu;
+   unsigned long actual_cpu_uV;
 };
 
+static unsigned int voltage_drop_interval_ms = 500;
+
 static unsigned int tegra_get_intermediate(struct cpufreq_policy *policy,
   unsigned int index)
 {
-   struct tegra20_cpufreq *cpufreq = cpufreq_get_driver_data();
-   unsigned int ifreq = clk_get_rate(cpufreq->pll_p_clk) / 1000;
+   struct tegra_cpufreq *cpufreq = cpufreq_get_driver_data();
+   struct clk *cpu_parent = clk_get_parent(cpufreq->cpu_clk);
+   unsigned long new_rate = cpufreq->freq_table[index].frequency * 1000;
+   int err;
 
/*
-* Don't switch to intermediate freq if:
-* - we are already at it, i.e. policy->cur == ifreq
-* - index corresponds to ifreq
+* Make sure that intermediate clock rate stays consistent during
+* transition by entering into critical section of the intermediate
+* clock.
 */
-   if (freq_table[index].frequency == ifreq || policy->cur == ifreq)
+   err = clk_rate_exclusive_get(cpufreq->intermediate_clk);
+   /* this shouldn't fail */
+   WARN_ON_ONCE(err);
+
+   /*
+* When target rate is equal to intermediate rate, we don't need to
+* switch to intermediate clock and so the intermediate routine isn't
+* called. Also, we wouldn't be using PLLX anymore and must not
+* take extra reference to it, as it can be disabled to save some
+* power.
+*/
+   cpufreq->intermediate_rate = clk_get_rate(cpufreq->intermediate_clk);
+
+   if (new_rate == cpufreq->intermediate_rate)
+   cpufreq->state &= ~PLLX_PREPARE;
+   else
+   cpufreq->state |= PLLX_PREPARE;
+
+   /* don't switch to intermediate 

[RFC PATCH v2 08/17] ARM: dts: tegra20: colibri: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20-colibri.dtsi | 31 ++
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20-colibri.dtsi 
b/arch/arm/boot/dts/tegra20-colibri.dtsi
index 6162d193e12c..5b3155dbf47a 100644
--- a/arch/arm/boot/dts/tegra20-colibri.dtsi
+++ b/arch/arm/boot/dts/tegra20-colibri.dtsi
@@ -495,17 +495,19 @@
regulator-always-on;
};
 
-   sm0 {
+   core_vdd_reg: sm0 {
regulator-name = "VDD_CORE_1.2V";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = <_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
regulator-always-on;
};
 
-   sm1 {
+   cpu_vdd_reg: sm1 {
regulator-name = "VDD_CPU_1.0V";
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <100>;
+   regulator-min-microvolt = <75>;
+   regulator-max-microvolt = <1125000>;
regulator-always-on;
};
 
@@ -530,10 +532,13 @@
regulator-always-on;
};
 
-   ldo2 {
+   rtc_vdd_reg: ldo2 {
regulator-name = "VDD_RTC_1.2V";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <95>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
+   regulator-always-on;
};
 
/* LDO3 is not connected to anything */
@@ -740,6 +745,14 @@
 <_car TEGRA20_CLK_CDEV1>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_vdd_reg>;
+   core-supply = <_vdd_reg>;
+   rtc-supply = <_vdd_reg>;
+   };
+   };
 };
 
  {
-- 
2.19.0

[RFC PATCH v2 08/17] ARM: dts: tegra20: colibri: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20-colibri.dtsi | 31 ++
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20-colibri.dtsi 
b/arch/arm/boot/dts/tegra20-colibri.dtsi
index 6162d193e12c..5b3155dbf47a 100644
--- a/arch/arm/boot/dts/tegra20-colibri.dtsi
+++ b/arch/arm/boot/dts/tegra20-colibri.dtsi
@@ -495,17 +495,19 @@
regulator-always-on;
};
 
-   sm0 {
+   core_vdd_reg: sm0 {
regulator-name = "VDD_CORE_1.2V";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = <_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
regulator-always-on;
};
 
-   sm1 {
+   cpu_vdd_reg: sm1 {
regulator-name = "VDD_CPU_1.0V";
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <100>;
+   regulator-min-microvolt = <75>;
+   regulator-max-microvolt = <1125000>;
regulator-always-on;
};
 
@@ -530,10 +532,13 @@
regulator-always-on;
};
 
-   ldo2 {
+   rtc_vdd_reg: ldo2 {
regulator-name = "VDD_RTC_1.2V";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <95>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
+   regulator-always-on;
};
 
/* LDO3 is not connected to anything */
@@ -740,6 +745,14 @@
 <_car TEGRA20_CLK_CDEV1>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_vdd_reg>;
+   core-supply = <_vdd_reg>;
+   rtc-supply = <_vdd_reg>;
+   };
+   };
 };
 
  {
-- 
2.19.0

[RFC PATCH v2 13/17] ARM: dts: tegra20: ventana: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20-ventana.dts | 31 +++
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20-ventana.dts 
b/arch/arm/boot/dts/tegra20-ventana.dts
index f44551e2d9d0..ef9cdd7335ae 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -419,17 +419,19 @@
regulator-always-on;
};
 
-   sm0 {
+   core_vdd_reg: sm0 {
regulator-name = "vdd_sm0,vdd_core";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = <_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
regulator-always-on;
};
 
-   sm1 {
+   cpu_vdd_reg: sm1 {
regulator-name = "vdd_sm1,vdd_cpu";
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <100>;
+   regulator-min-microvolt = <75>;
+   regulator-max-microvolt = <1125000>;
regulator-always-on;
};
 
@@ -449,10 +451,13 @@
regulator-always-on;
};
 
-   ldo2 {
+   rtc_vdd_reg: ldo2 {
regulator-name = "vdd_ldo2,vdd_rtc";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <95>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
+   regulator-always-on;
};
 
ldo3 {
@@ -704,4 +709,12 @@
 <_car TEGRA20_CLK_CDEV1>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_vdd_reg>;
+   core-supply = <_vdd_reg>;
+   rtc-supply = <_vdd_reg>;
+   };
+   };
 };
-- 
2.19.0

[RFC PATCH v2 06/17] ARM: dts: tegra20: Add CPU Operating Performance Points

[Dmitry Osipenko]

Add CPU's Operating Performance Points to the device tree, they are used
by the CPUFreq driver and allow to setup thermal throttling for the boards
by linking the cooling device (CPU) with thermal sensors via thermal-zones
description.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20.dtsi | 277 +
 1 file changed, 277 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 185cd074eeff..51ffb5d2b974 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -859,6 +859,271 @@
status = "disabled";
};
 
+   cpu0_opp_table: opp_table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@21600_750 {
+   clock-latency-ns = <2000>;
+   opp-microvolt = <75 75 1125000>;
+   opp-supported-hw = <0xFF 0x>;
+   opp-hz = /bits/ 64 <21600>;
+   opp-suspend;
+   };
+
+   opp@31400_750 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <75 75 1125000>;
+   opp-supported-hw = <0x03 0x0001>;
+   opp-hz = /bits/ 64 <31400>;
+   };
+
+   opp@38000_750 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <75 75 1125000>;
+   opp-supported-hw = <0x01 0x0002>;
+   opp-hz = /bits/ 64 <38000>;
+   };
+
+   opp@38900_750 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <75 75 1125000>;
+   opp-supported-hw = <0x02 0x0002>;
+   opp-hz = /bits/ 64 <38900>;
+   };
+
+   opp@45600_825 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <825000 825000 1125000>;
+   opp-supported-hw = <0x03 0x0001>;
+   opp-hz = /bits/ 64 <45600>;
+   };
+
+   opp@49400_750 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <75 75 1125000>;
+   opp-supported-hw = <0x04 0x0001>;
+   opp-hz = /bits/ 64 <49400>;
+   };
+
+   opp@50300_800 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <80 80 1125000>;
+   opp-supported-hw = <0x03 0x0002>;
+   opp-hz = /bits/ 64 <50300>;
+   };
+
+   opp@59800_750 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <75 75 1125000>;
+   opp-supported-hw = <0x04 0x0002>;
+   opp-hz = /bits/ 64 <59800>;
+   };
+
+   opp@60800_900 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <90 90 1125000>;
+   opp-supported-hw = <0x01 0x0001>;
+   opp-hz = /bits/ 64 <60800>;
+   };
+
+   opp@61800_900 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <90 90 1125000>;
+   opp-supported-hw = <0x02 0x0001>;
+   opp-hz = /bits/ 64 <61800>;
+   };
+
+   opp@65500_850 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <85 85 1125000>;
+   opp-supported-hw = <0x03 0x0002>;
+   opp-hz = /bits/ 64 <65500>;
+   };
+
+   opp@67500_825 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <825000 825000 1125000>;
+   opp-supported-hw = <0x04 0x0001>;
+   opp-hz = /bits/ 64 <67500>;
+   };
+
+   opp@73000_750 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <75 75 1125000>;
+   opp-supported-hw = <0x08 0x0003>;
+   opp-hz = /bits/ 64 <73000>;
+   };
+
+   opp@75000_800 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <80 80 1125000>;
+   opp-supported-hw = <0x04 0x0002>;
+   opp-hz = /bits/ 64 <75000>;
+   };
+
+   opp@76000_775 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <775000 775000 1125000>;

[RFC PATCH v2 17/17] ARM: dts: tegra30: colibri: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra30-colibri.dtsi | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/tegra30-colibri.dtsi 
b/arch/arm/boot/dts/tegra30-colibri.dtsi
index 35af03ca9e90..c59099c1e2c3 100644
--- a/arch/arm/boot/dts/tegra30-colibri.dtsi
+++ b/arch/arm/boot/dts/tegra30-colibri.dtsi
@@ -763,8 +763,11 @@
 
vddctrl_reg: vddctrl {
regulator-name = "+V1.0_VDD_CPU";
-   regulator-min-microvolt = <115>;
-   regulator-max-microvolt = <115>;
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <125>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <30>;
+   regulator-max-step-microvolt = <10>;
regulator-always-on;
};
 
@@ -882,13 +885,16 @@
};
 
/* SW: +V1.2_VDD_CORE */
-   regulator@60 {
+   core_vdd_reg: regulator@60 {
compatible = "ti,tps62362";
reg = <0x60>;
 
regulator-name = "tps62362-vout";
regulator-min-microvolt = <90>;
regulator-max-microvolt = <140>;
+   regulator-coupled-with = <_reg>;
+   regulator-coupled-max-spread = <30>;
+   regulator-max-step-microvolt = <10>;
regulator-boot-on;
regulator-always-on;
ti,vsel0-state-low;
@@ -1027,6 +1033,13 @@
 <_car TEGRA30_CLK_EXTERN1>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_reg>;
+   core-supply = <_vdd_reg>;
+   };
+   };
 };
 
  {
-- 
2.19.0

[RFC PATCH v2 11/17] ARM: dts: tegra20: seaboard: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20-seaboard.dts | 27 +++---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts 
b/arch/arm/boot/dts/tegra20-seaboard.dts
index f91441683aad..85bf7e89ebbe 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -444,16 +444,18 @@
regulator-always-on;
};
 
-   sm0 {
+   core_vdd_reg: sm0 {
regulator-name = "vdd_sm0,vdd_core";
-   regulator-min-microvolt = <130>;
+   regulator-min-microvolt = <100>;
regulator-max-microvolt = <130>;
+   regulator-coupled-with = <_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
regulator-always-on;
};
 
-   sm1 {
+   cpu_vdd_reg: sm1 {
regulator-name = "vdd_sm1,vdd_cpu";
-   regulator-min-microvolt = <1125000>;
+   regulator-min-microvolt = <75>;
regulator-max-microvolt = <1125000>;
regulator-always-on;
};
@@ -474,10 +476,13 @@
regulator-always-on;
};
 
-   ldo2 {
+   rtc_vdd_reg: ldo2 {
regulator-name = "vdd_ldo2,vdd_rtc";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <95>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
+   regulator-always-on;
};
 
ldo3 {
@@ -938,4 +943,12 @@
 <_car TEGRA20_CLK_CDEV1>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_vdd_reg>;
+   core-supply = <_vdd_reg>;
+   rtc-supply = <_vdd_reg>;
+   };
+   };
 };
-- 
2.19.0

[RFC PATCH v2 16/17] ARM: dts: tegra30: cardhu: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra30-cardhu.dtsi | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi 
b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index fb9222b479d2..5fcf5ac09530 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -272,8 +272,11 @@
 
vddctrl_reg: vddctrl {
regulator-name = "vdd_cpu,vdd_sys";
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <100>;
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <125>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <30>;
+   regulator-max-step-microvolt = <10>;
regulator-always-on;
};
 
@@ -342,13 +345,16 @@
interrupts = ;
};
 
-   tps62361@60 {
+   core_vdd_reg: tps62361@60 {
compatible = "ti,tps62361";
reg = <0x60>;
 
regulator-name = "tps62361-vout";
regulator-min-microvolt = <50>;
regulator-max-microvolt = <150>;
+   regulator-coupled-with = <_reg>;
+   regulator-coupled-max-spread = <30>;
+   regulator-max-step-microvolt = <10>;
regulator-boot-on;
regulator-always-on;
ti,vsel0-state-high;
@@ -649,4 +655,11 @@
debounce-interval = <10>;
};
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_reg>;
+   core-supply = <_vdd_reg>;
+   };
+   };
 };
-- 
2.19.0

[RFC PATCH v2 13/17] ARM: dts: tegra20: ventana: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20-ventana.dts | 31 +++
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20-ventana.dts 
b/arch/arm/boot/dts/tegra20-ventana.dts
index f44551e2d9d0..ef9cdd7335ae 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -419,17 +419,19 @@
regulator-always-on;
};
 
-   sm0 {
+   core_vdd_reg: sm0 {
regulator-name = "vdd_sm0,vdd_core";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = <_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
regulator-always-on;
};
 
-   sm1 {
+   cpu_vdd_reg: sm1 {
regulator-name = "vdd_sm1,vdd_cpu";
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <100>;
+   regulator-min-microvolt = <75>;
+   regulator-max-microvolt = <1125000>;
regulator-always-on;
};
 
@@ -449,10 +451,13 @@
regulator-always-on;
};
 
-   ldo2 {
+   rtc_vdd_reg: ldo2 {
regulator-name = "vdd_ldo2,vdd_rtc";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <95>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
+   regulator-always-on;
};
 
ldo3 {
@@ -704,4 +709,12 @@
 <_car TEGRA20_CLK_CDEV1>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_vdd_reg>;
+   core-supply = <_vdd_reg>;
+   rtc-supply = <_vdd_reg>;
+   };
+   };
 };
-- 
2.19.0

[RFC PATCH v2 06/17] ARM: dts: tegra20: Add CPU Operating Performance Points

[Dmitry Osipenko]

Add CPU's Operating Performance Points to the device tree, they are used
by the CPUFreq driver and allow to setup thermal throttling for the boards
by linking the cooling device (CPU) with thermal sensors via thermal-zones
description.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20.dtsi | 277 +
 1 file changed, 277 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 185cd074eeff..51ffb5d2b974 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -859,6 +859,271 @@
status = "disabled";
};
 
+   cpu0_opp_table: opp_table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@21600_750 {
+   clock-latency-ns = <2000>;
+   opp-microvolt = <75 75 1125000>;
+   opp-supported-hw = <0xFF 0x>;
+   opp-hz = /bits/ 64 <21600>;
+   opp-suspend;
+   };
+
+   opp@31400_750 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <75 75 1125000>;
+   opp-supported-hw = <0x03 0x0001>;
+   opp-hz = /bits/ 64 <31400>;
+   };
+
+   opp@38000_750 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <75 75 1125000>;
+   opp-supported-hw = <0x01 0x0002>;
+   opp-hz = /bits/ 64 <38000>;
+   };
+
+   opp@38900_750 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <75 75 1125000>;
+   opp-supported-hw = <0x02 0x0002>;
+   opp-hz = /bits/ 64 <38900>;
+   };
+
+   opp@45600_825 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <825000 825000 1125000>;
+   opp-supported-hw = <0x03 0x0001>;
+   opp-hz = /bits/ 64 <45600>;
+   };
+
+   opp@49400_750 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <75 75 1125000>;
+   opp-supported-hw = <0x04 0x0001>;
+   opp-hz = /bits/ 64 <49400>;
+   };
+
+   opp@50300_800 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <80 80 1125000>;
+   opp-supported-hw = <0x03 0x0002>;
+   opp-hz = /bits/ 64 <50300>;
+   };
+
+   opp@59800_750 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <75 75 1125000>;
+   opp-supported-hw = <0x04 0x0002>;
+   opp-hz = /bits/ 64 <59800>;
+   };
+
+   opp@60800_900 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <90 90 1125000>;
+   opp-supported-hw = <0x01 0x0001>;
+   opp-hz = /bits/ 64 <60800>;
+   };
+
+   opp@61800_900 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <90 90 1125000>;
+   opp-supported-hw = <0x02 0x0001>;
+   opp-hz = /bits/ 64 <61800>;
+   };
+
+   opp@65500_850 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <85 85 1125000>;
+   opp-supported-hw = <0x03 0x0002>;
+   opp-hz = /bits/ 64 <65500>;
+   };
+
+   opp@67500_825 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <825000 825000 1125000>;
+   opp-supported-hw = <0x04 0x0001>;
+   opp-hz = /bits/ 64 <67500>;
+   };
+
+   opp@73000_750 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <75 75 1125000>;
+   opp-supported-hw = <0x08 0x0003>;
+   opp-hz = /bits/ 64 <73000>;
+   };
+
+   opp@75000_800 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <80 80 1125000>;
+   opp-supported-hw = <0x04 0x0002>;
+   opp-hz = /bits/ 64 <75000>;
+   };
+
+   opp@76000_775 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <775000 775000 1125000>;

[RFC PATCH v2 17/17] ARM: dts: tegra30: colibri: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra30-colibri.dtsi | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/tegra30-colibri.dtsi 
b/arch/arm/boot/dts/tegra30-colibri.dtsi
index 35af03ca9e90..c59099c1e2c3 100644
--- a/arch/arm/boot/dts/tegra30-colibri.dtsi
+++ b/arch/arm/boot/dts/tegra30-colibri.dtsi
@@ -763,8 +763,11 @@
 
vddctrl_reg: vddctrl {
regulator-name = "+V1.0_VDD_CPU";
-   regulator-min-microvolt = <115>;
-   regulator-max-microvolt = <115>;
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <125>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <30>;
+   regulator-max-step-microvolt = <10>;
regulator-always-on;
};
 
@@ -882,13 +885,16 @@
};
 
/* SW: +V1.2_VDD_CORE */
-   regulator@60 {
+   core_vdd_reg: regulator@60 {
compatible = "ti,tps62362";
reg = <0x60>;
 
regulator-name = "tps62362-vout";
regulator-min-microvolt = <90>;
regulator-max-microvolt = <140>;
+   regulator-coupled-with = <_reg>;
+   regulator-coupled-max-spread = <30>;
+   regulator-max-step-microvolt = <10>;
regulator-boot-on;
regulator-always-on;
ti,vsel0-state-low;
@@ -1027,6 +1033,13 @@
 <_car TEGRA30_CLK_EXTERN1>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_reg>;
+   core-supply = <_vdd_reg>;
+   };
+   };
 };
 
  {
-- 
2.19.0

[RFC PATCH v2 11/17] ARM: dts: tegra20: seaboard: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20-seaboard.dts | 27 +++---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts 
b/arch/arm/boot/dts/tegra20-seaboard.dts
index f91441683aad..85bf7e89ebbe 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -444,16 +444,18 @@
regulator-always-on;
};
 
-   sm0 {
+   core_vdd_reg: sm0 {
regulator-name = "vdd_sm0,vdd_core";
-   regulator-min-microvolt = <130>;
+   regulator-min-microvolt = <100>;
regulator-max-microvolt = <130>;
+   regulator-coupled-with = <_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
regulator-always-on;
};
 
-   sm1 {
+   cpu_vdd_reg: sm1 {
regulator-name = "vdd_sm1,vdd_cpu";
-   regulator-min-microvolt = <1125000>;
+   regulator-min-microvolt = <75>;
regulator-max-microvolt = <1125000>;
regulator-always-on;
};
@@ -474,10 +476,13 @@
regulator-always-on;
};
 
-   ldo2 {
+   rtc_vdd_reg: ldo2 {
regulator-name = "vdd_ldo2,vdd_rtc";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <95>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
+   regulator-always-on;
};
 
ldo3 {
@@ -938,4 +943,12 @@
 <_car TEGRA20_CLK_CDEV1>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_vdd_reg>;
+   core-supply = <_vdd_reg>;
+   rtc-supply = <_vdd_reg>;
+   };
+   };
 };
-- 
2.19.0

[RFC PATCH v2 16/17] ARM: dts: tegra30: cardhu: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra30-cardhu.dtsi | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi 
b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index fb9222b479d2..5fcf5ac09530 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -272,8 +272,11 @@
 
vddctrl_reg: vddctrl {
regulator-name = "vdd_cpu,vdd_sys";
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <100>;
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <125>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <30>;
+   regulator-max-step-microvolt = <10>;
regulator-always-on;
};
 
@@ -342,13 +345,16 @@
interrupts = ;
};
 
-   tps62361@60 {
+   core_vdd_reg: tps62361@60 {
compatible = "ti,tps62361";
reg = <0x60>;
 
regulator-name = "tps62361-vout";
regulator-min-microvolt = <50>;
regulator-max-microvolt = <150>;
+   regulator-coupled-with = <_reg>;
+   regulator-coupled-max-spread = <30>;
+   regulator-max-step-microvolt = <10>;
regulator-boot-on;
regulator-always-on;
ti,vsel0-state-high;
@@ -649,4 +655,11 @@
debounce-interval = <10>;
};
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_reg>;
+   core-supply = <_vdd_reg>;
+   };
+   };
 };
-- 
2.19.0

[RFC PATCH v2 10/17] ARM: dts: tegra20: paz00: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20-paz00.dts | 31 -
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20-paz00.dts 
b/arch/arm/boot/dts/tegra20-paz00.dts
index 8861e0976e37..51a09ae99f3a 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -337,17 +337,19 @@
regulator-always-on;
};
 
-   sm0 {
+   core_vdd_reg: sm0 {
regulator-name = "+1.2vs_sm0,vdd_core";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = <_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
regulator-always-on;
};
 
-   sm1 {
+   cpu_vdd_reg: sm1 {
regulator-name = "+1.0vs_sm1,vdd_cpu";
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <100>;
+   regulator-min-microvolt = <75>;
+   regulator-max-microvolt = <1125000>;
regulator-always-on;
};
 
@@ -367,10 +369,13 @@
regulator-always-on;
};
 
-   ldo2 {
+   rtc_vdd_reg: ldo2 {
regulator-name = "+1.2vs_ldo2,vdd_rtc";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <95>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
+   regulator-always-on;
};
 
ldo3 {
@@ -603,4 +608,12 @@
 <_car TEGRA20_CLK_CDEV1>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_vdd_reg>;
+   core-supply = <_vdd_reg>;
+   rtc-supply = <_vdd_reg>;
+   };
+   };
 };
-- 
2.19.0

[RFC PATCH v2 14/17] ARM: dts: tegra30: apalis: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra30-apalis.dtsi | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi 
b/arch/arm/boot/dts/tegra30-apalis.dtsi
index 7f112f192fe9..1ca9bec8380f 100644
--- a/arch/arm/boot/dts/tegra30-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra30-apalis.dtsi
@@ -890,8 +890,11 @@
 
vddctrl_reg: vddctrl {
regulator-name = "+V1.0_VDD_CPU";
-   regulator-min-microvolt = <115>;
-   regulator-max-microvolt = <115>;
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <125>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <30>;
+   regulator-max-step-microvolt = <10>;
regulator-always-on;
};
 
@@ -1013,13 +1016,16 @@
};
 
/* SW: +V1.2_VDD_CORE */
-   regulator@60 {
+   core_vdd_reg: regulator@60 {
compatible = "ti,tps62362";
reg = <0x60>;
 
regulator-name = "tps62362-vout";
regulator-min-microvolt = <90>;
regulator-max-microvolt = <140>;
+   regulator-coupled-with = <_reg>;
+   regulator-coupled-max-spread = <30>;
+   regulator-max-step-microvolt = <10>;
regulator-boot-on;
regulator-always-on;
ti,vsel0-state-low;
@@ -1168,4 +1174,11 @@
 <_car TEGRA30_CLK_EXTERN1>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_reg>;
+   core-supply = <_vdd_reg>;
+   };
+   };
 };
-- 
2.19.0

[RFC PATCH v2 12/17] ARM: dts: tegra20: tamonten: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20-tamonten.dtsi | 31 ++---
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi 
b/arch/arm/boot/dts/tegra20-tamonten.dtsi
index 20137fc578b1..e9db60f4c317 100644
--- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
+++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
@@ -357,17 +357,19 @@
regulator-always-on;
};
 
-   sm0 {
+   core_vdd_reg: sm0 {
regulator-name = "vdd_sys_sm0,vdd_core";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = <_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
regulator-always-on;
};
 
-   sm1 {
+   cpu_vdd_reg: sm1 {
regulator-name = "vdd_sys_sm1,vdd_cpu";
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <100>;
+   regulator-min-microvolt = <75>;
+   regulator-max-microvolt = <1125000>;
regulator-always-on;
};
 
@@ -391,10 +393,13 @@
regulator-always-on;
};
 
-   ldo2 {
+   rtc_vdd_reg: ldo2 {
regulator-name = "vdd_ldo2,vdd_rtc";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <95>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
+   regulator-always-on;
};
 
ldo3 {
@@ -531,4 +536,12 @@
enable-active-high;
};
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_vdd_reg>;
+   core-supply = <_vdd_reg>;
+   rtc-supply = <_vdd_reg>;
+   };
+   };
 };
-- 
2.19.0

[RFC PATCH v2 07/17] ARM: dts: tegra30: Add CPU Operating Performance Points

[Dmitry Osipenko]

Add CPU's Operating Performance Points to the device tree, they are used
by the CPUFreq driver and allow to setup thermal throttling for the boards
by linking the cooling device (CPU) with thermal sensors via thermal-zones
description.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra30.dtsi | 688 +
 1 file changed, 688 insertions(+)

diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index 790d3fa7e6d2..0aefc8d9efab 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -980,6 +980,670 @@
status = "disabled";
};
 
+   cpu0_opp_table: opp_table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@40800_800 {
+   clock-latency-ns = <2000>;
+   opp-microvolt = <80 80 125>;
+   opp-supported-hw = <0xFF 0x>;
+   opp-hz = /bits/ 64 <40800>;
+   opp-suspend;
+   };
+
+   opp@46000_800 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <80 80 125>;
+   opp-supported-hw = <0x01 0x0192>;
+   opp-hz = /bits/ 64 <46000>;
+   };
+
+   opp@48000_800 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <80 80 125>;
+   opp-supported-hw = <0x02 0x019E>;
+   opp-hz = /bits/ 64 <48000>;
+   };
+
+   opp@52000_800 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <80 80 125>;
+   opp-supported-hw = <0x04 0x019E>;
+   opp-hz = /bits/ 64 <52000>;
+   };
+
+   opp@55000_800 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <80 80 125>;
+   opp-supported-hw = <0x18 0x31FE>;
+   opp-hz = /bits/ 64 <55000>;
+   };
+
+   opp@55000_850 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <85 85 125>;
+   opp-supported-hw = <0x01 0x0192>;
+   opp-hz = /bits/ 64 <55000>;
+   };
+
+   opp@6_850 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <85 85 125>;
+   opp-supported-hw = <0x1F 0x0800>;
+   opp-hz = /bits/ 64 <6>;
+   };
+
+   opp@65000_850 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <85 85 125>;
+   opp-supported-hw = <0x02 0x019E>;
+   opp-hz = /bits/ 64 <65000>;
+   };
+
+   opp@68000_900 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <90 90 125>;
+   opp-supported-hw = <0x01 0x0192>;
+   opp-hz = /bits/ 64 <68000>;
+   };
+
+   opp@68400_850 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <85 85 125>;
+   opp-supported-hw = <0x01 0x0001>;
+   opp-hz = /bits/ 64 <68400>;
+   };
+
+   opp@7_850 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <85 85 125>;
+   opp-supported-hw = <0x04 0x019E>;
+   opp-hz = /bits/ 64 <7>;
+   };
+
+   opp@77000_850 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <85 85 125>;
+   opp-supported-hw = <0x18 0x31FE>;
+   opp-hz = /bits/ 64 <77000>;
+   };
+
+   opp@78000_900 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <90 90 125>;
+   opp-supported-hw = <0x02 0x019E>;
+   opp-hz = /bits/ 64 <78000>;
+   };
+
+   opp@80700_850 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <85 85 125>;
+   opp-supported-hw = <0x02 0x0001>;
+   opp-hz = /bits/ 64 <80700>;
+   };
+
+   opp@81700_900 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <90 90 125>;
+  

[RFC PATCH v2 10/17] ARM: dts: tegra20: paz00: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20-paz00.dts | 31 -
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20-paz00.dts 
b/arch/arm/boot/dts/tegra20-paz00.dts
index 8861e0976e37..51a09ae99f3a 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -337,17 +337,19 @@
regulator-always-on;
};
 
-   sm0 {
+   core_vdd_reg: sm0 {
regulator-name = "+1.2vs_sm0,vdd_core";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = <_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
regulator-always-on;
};
 
-   sm1 {
+   cpu_vdd_reg: sm1 {
regulator-name = "+1.0vs_sm1,vdd_cpu";
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <100>;
+   regulator-min-microvolt = <75>;
+   regulator-max-microvolt = <1125000>;
regulator-always-on;
};
 
@@ -367,10 +369,13 @@
regulator-always-on;
};
 
-   ldo2 {
+   rtc_vdd_reg: ldo2 {
regulator-name = "+1.2vs_ldo2,vdd_rtc";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <95>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
+   regulator-always-on;
};
 
ldo3 {
@@ -603,4 +608,12 @@
 <_car TEGRA20_CLK_CDEV1>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_vdd_reg>;
+   core-supply = <_vdd_reg>;
+   rtc-supply = <_vdd_reg>;
+   };
+   };
 };
-- 
2.19.0

[RFC PATCH v2 14/17] ARM: dts: tegra30: apalis: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra30-apalis.dtsi | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi 
b/arch/arm/boot/dts/tegra30-apalis.dtsi
index 7f112f192fe9..1ca9bec8380f 100644
--- a/arch/arm/boot/dts/tegra30-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra30-apalis.dtsi
@@ -890,8 +890,11 @@
 
vddctrl_reg: vddctrl {
regulator-name = "+V1.0_VDD_CPU";
-   regulator-min-microvolt = <115>;
-   regulator-max-microvolt = <115>;
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <125>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <30>;
+   regulator-max-step-microvolt = <10>;
regulator-always-on;
};
 
@@ -1013,13 +1016,16 @@
};
 
/* SW: +V1.2_VDD_CORE */
-   regulator@60 {
+   core_vdd_reg: regulator@60 {
compatible = "ti,tps62362";
reg = <0x60>;
 
regulator-name = "tps62362-vout";
regulator-min-microvolt = <90>;
regulator-max-microvolt = <140>;
+   regulator-coupled-with = <_reg>;
+   regulator-coupled-max-spread = <30>;
+   regulator-max-step-microvolt = <10>;
regulator-boot-on;
regulator-always-on;
ti,vsel0-state-low;
@@ -1168,4 +1174,11 @@
 <_car TEGRA30_CLK_EXTERN1>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_reg>;
+   core-supply = <_vdd_reg>;
+   };
+   };
 };
-- 
2.19.0

[RFC PATCH v2 12/17] ARM: dts: tegra20: tamonten: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20-tamonten.dtsi | 31 ++---
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi 
b/arch/arm/boot/dts/tegra20-tamonten.dtsi
index 20137fc578b1..e9db60f4c317 100644
--- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
+++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
@@ -357,17 +357,19 @@
regulator-always-on;
};
 
-   sm0 {
+   core_vdd_reg: sm0 {
regulator-name = "vdd_sys_sm0,vdd_core";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = <_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
regulator-always-on;
};
 
-   sm1 {
+   cpu_vdd_reg: sm1 {
regulator-name = "vdd_sys_sm1,vdd_cpu";
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <100>;
+   regulator-min-microvolt = <75>;
+   regulator-max-microvolt = <1125000>;
regulator-always-on;
};
 
@@ -391,10 +393,13 @@
regulator-always-on;
};
 
-   ldo2 {
+   rtc_vdd_reg: ldo2 {
regulator-name = "vdd_ldo2,vdd_rtc";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <95>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
+   regulator-always-on;
};
 
ldo3 {
@@ -531,4 +536,12 @@
enable-active-high;
};
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_vdd_reg>;
+   core-supply = <_vdd_reg>;
+   rtc-supply = <_vdd_reg>;
+   };
+   };
 };
-- 
2.19.0

[RFC PATCH v2 07/17] ARM: dts: tegra30: Add CPU Operating Performance Points

[Dmitry Osipenko]

Add CPU's Operating Performance Points to the device tree, they are used
by the CPUFreq driver and allow to setup thermal throttling for the boards
by linking the cooling device (CPU) with thermal sensors via thermal-zones
description.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra30.dtsi | 688 +
 1 file changed, 688 insertions(+)

diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index 790d3fa7e6d2..0aefc8d9efab 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -980,6 +980,670 @@
status = "disabled";
};
 
+   cpu0_opp_table: opp_table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@40800_800 {
+   clock-latency-ns = <2000>;
+   opp-microvolt = <80 80 125>;
+   opp-supported-hw = <0xFF 0x>;
+   opp-hz = /bits/ 64 <40800>;
+   opp-suspend;
+   };
+
+   opp@46000_800 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <80 80 125>;
+   opp-supported-hw = <0x01 0x0192>;
+   opp-hz = /bits/ 64 <46000>;
+   };
+
+   opp@48000_800 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <80 80 125>;
+   opp-supported-hw = <0x02 0x019E>;
+   opp-hz = /bits/ 64 <48000>;
+   };
+
+   opp@52000_800 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <80 80 125>;
+   opp-supported-hw = <0x04 0x019E>;
+   opp-hz = /bits/ 64 <52000>;
+   };
+
+   opp@55000_800 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <80 80 125>;
+   opp-supported-hw = <0x18 0x31FE>;
+   opp-hz = /bits/ 64 <55000>;
+   };
+
+   opp@55000_850 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <85 85 125>;
+   opp-supported-hw = <0x01 0x0192>;
+   opp-hz = /bits/ 64 <55000>;
+   };
+
+   opp@6_850 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <85 85 125>;
+   opp-supported-hw = <0x1F 0x0800>;
+   opp-hz = /bits/ 64 <6>;
+   };
+
+   opp@65000_850 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <85 85 125>;
+   opp-supported-hw = <0x02 0x019E>;
+   opp-hz = /bits/ 64 <65000>;
+   };
+
+   opp@68000_900 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <90 90 125>;
+   opp-supported-hw = <0x01 0x0192>;
+   opp-hz = /bits/ 64 <68000>;
+   };
+
+   opp@68400_850 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <85 85 125>;
+   opp-supported-hw = <0x01 0x0001>;
+   opp-hz = /bits/ 64 <68400>;
+   };
+
+   opp@7_850 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <85 85 125>;
+   opp-supported-hw = <0x04 0x019E>;
+   opp-hz = /bits/ 64 <7>;
+   };
+
+   opp@77000_850 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <85 85 125>;
+   opp-supported-hw = <0x18 0x31FE>;
+   opp-hz = /bits/ 64 <77000>;
+   };
+
+   opp@78000_900 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <90 90 125>;
+   opp-supported-hw = <0x02 0x019E>;
+   opp-hz = /bits/ 64 <78000>;
+   };
+
+   opp@80700_850 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <85 85 125>;
+   opp-supported-hw = <0x02 0x0001>;
+   opp-hz = /bits/ 64 <80700>;
+   };
+
+   opp@81700_900 {
+   clock-latency-ns = <5>;
+   opp-microvolt = <90 90 125>;
+  

[RFC PATCH v2 15/17] ARM: dts: tegra30: beaver: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra30-beaver.dts | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/tegra30-beaver.dts 
b/arch/arm/boot/dts/tegra30-beaver.dts
index b0d40ac8ac6e..39941489d005 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -1806,8 +1806,11 @@
 
vddctrl_reg: vddctrl {
regulator-name = "vdd_cpu,vdd_sys";
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <100>;
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <125>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <30>;
+   regulator-max-step-microvolt = <10>;
regulator-always-on;
};
 
@@ -1868,13 +1871,16 @@
};
};
 
-   tps62361@60 {
+   core_vdd_reg: tps62361@60 {
compatible = "ti,tps62361";
reg = <0x60>;
 
regulator-name = "tps62361-vout";
regulator-min-microvolt = <50>;
regulator-max-microvolt = <150>;
+   regulator-coupled-with = <_reg>;
+   regulator-coupled-max-spread = <30>;
+   regulator-max-step-microvolt = <10>;
regulator-boot-on;
regulator-always-on;
ti,vsel0-state-high;
@@ -2114,4 +2120,11 @@
 <_car TEGRA30_CLK_EXTERN1>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_reg>;
+   core-supply = <_vdd_reg>;
+   };
+   };
 };
-- 
2.19.0

[RFC PATCH v2 15/17] ARM: dts: tegra30: beaver: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra30-beaver.dts | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/tegra30-beaver.dts 
b/arch/arm/boot/dts/tegra30-beaver.dts
index b0d40ac8ac6e..39941489d005 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -1806,8 +1806,11 @@
 
vddctrl_reg: vddctrl {
regulator-name = "vdd_cpu,vdd_sys";
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <100>;
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <125>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <30>;
+   regulator-max-step-microvolt = <10>;
regulator-always-on;
};
 
@@ -1868,13 +1871,16 @@
};
};
 
-   tps62361@60 {
+   core_vdd_reg: tps62361@60 {
compatible = "ti,tps62361";
reg = <0x60>;
 
regulator-name = "tps62361-vout";
regulator-min-microvolt = <50>;
regulator-max-microvolt = <150>;
+   regulator-coupled-with = <_reg>;
+   regulator-coupled-max-spread = <30>;
+   regulator-max-step-microvolt = <10>;
regulator-boot-on;
regulator-always-on;
ti,vsel0-state-high;
@@ -2114,4 +2120,11 @@
 <_car TEGRA30_CLK_EXTERN1>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_reg>;
+   core-supply = <_vdd_reg>;
+   };
+   };
 };
-- 
2.19.0

[RFC PATCH v2 03/17] dt-bindings: cpufreq: Add binding for NVIDIA Tegra20/30

[Dmitry Osipenko]

Add device-tree binding that describes CPU frequency-scaling hardware
found on NVIDIA Tegra20/30 SoC's.

Signed-off-by: Dmitry Osipenko 
---
 .../cpufreq/nvidia,tegra20-cpufreq.txt| 96 +++
 1 file changed, 96 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt

diff --git 
a/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt 
b/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt
new file mode 100644
index ..a8023ea7a99f
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt
@@ -0,0 +1,96 @@
+Binding for NVIDIA Tegra20 CPUFreq
+==
+
+Required properties:
+- clocks: Must contain an entry for each entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names: Must include the following entries:
+  - pll_x: main-parent for CPU clock, must be the first entry
+  - intermediate: intermediate-parent for CPU clock
+  - cclk: the CPU clock
+- operating-points-v2: See ../bindings/opp/opp.txt for details.
+- #cooling-cells: Should be 2. See ../thermal/thermal.txt for details.
+
+For each opp entry in 'operating-points-v2' table:
+- opp-supported-hw: Two bitfields indicating:
+   On Tegra20:
+   1. CPU process ID mask
+   2. SoC speedo ID mask
+
+   On Tegra30:
+   1. CPU process ID mask
+   2. CPU speedo ID mask
+
+   A bitwise AND is performed against these values and if any bit
+   matches, the OPP gets enabled.
+
+- opp-microvolt: CPU voltage triplet.
+
+Optional properties:
+- cpu-supply: Phandle to the CPU power supply.
+- core-supply: Phandle to the CORE power supply.
+- rtc-supply: Phandle to the RTC power supply, required only for Tegra20.
+
+Voltage supply requirements:
+- Tegra20:
+   CORE and RTC regulators must be coupled using the regulator-coupled-with
+   property and regulator-coupled-max-spread property must be set to no
+   more than 170mV.
+
+   See ../regulator/regulator.txt for more detail about the properties.
+
+- Tegra30:
+   CORE and CPU regulators must be coupled using the regulator-coupled-with
+   property and regulator-coupled-max-spread property must be set to no
+   more than 300mV. Each of CORE and CPU regulators must set
+   regulator-max-step-microvolt property to no more than 100mV.
+
+   See ../regulator/regulator.txt for more detail about the properties.
+
+
+Example:
+   regulators {
+   cpu_reg: regulator0 {
+   regulator-name = "vdd_cpu";
+   };
+
+   core_reg: regulator1 {
+   regulator-name = "vdd_core";
+   regulator-coupled-with = <_reg>;
+   regulator-coupled-max-spread = <17>;
+   };
+
+   rtc_reg: regulator2 {
+   regulator-name = "vdd_rtc";
+   regulator-coupled-with = <_reg>;
+   regulator-coupled-max-spread = <17>;
+   };
+   };
+
+   cpu0_opp_table: opp_table0 {
+   compatible = "operating-points-v2";
+
+   opp@45600 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <825000 825000 1125000>;
+   opp-supported-hw = <0x03 0x0001>;
+   opp-hz = /bits/ 64 <45600>;
+   };
+
+   ...
+   };
+
+   cpus {
+   cpu@0 {
+   compatible = "arm,cortex-a9";
+   clocks = <_car TEGRA20_CLK_PLL_X>,
+<_car TEGRA20_CLK_PLL_P>,
+<_car TEGRA20_CLK_CCLK>;
+   clock-names = "pll_x", "intermediate", "cclk";
+   operating-points-v2 = <_opp_table>;
+   cpu-supply = <_reg>;
+   core-supply = <_reg>;
+   rtc-supply = <_reg>;
+   #cooling-cells = <2>;
+   };
+   };
-- 
2.19.0

[RFC PATCH v2 00/17] CPUFREQ OPP's, DVFS and Tegra30 support by tegra20-cpufreq driver

[Dmitry Osipenko]

Hello,

This series adds support for CPU frequency/voltage scaling on Tegra20/30,
it adds device tree support that allow to specify clock rate/voltages per
board and to implement thermal throttling. The tegra20-cpufreq driver has
been re-worked to support that all.

Note that this series depends on in-progress clock [0] and regulator [1]
patches.

Changelog:

v2:
- Implemented DVFS support. Currently only CPU rail changes voltage,
  while CORE/RTC locked to maximum. The CORE can be unlocked once all
  of peripheral drivers will gain support for DVFS. See "TODO" comment
  in the driver. On Tegra20 CPU temperature is lower by 5-6 C during
  idling with DVFS. On Tegra30 CPU temperature is lower by 1-2 C, and
  it drops by 6-7 C if CORE rail scaling is unlocked.

- Device-tree binding has been reworked to support voltage regulators
  and HW versioning. Now CPU OPP's are specified per HW version and
  include voltage entry. OPP values are taken from downstream kernel
  [2][3]. The "backup" clock has been renamed to "intermediate".

[0] https://lkml.org/lkml/2018/8/30/960
[1] https://lkml.org/lkml/2018/10/5/682
[2] 
https://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=blob;f=arch/arm/mach-tegra/tegra2_dvfs.c;hb=l4t/l4t-r16-r2
[3] 
https://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=blob;f=arch/arm/mach-tegra/tegra3_dvfs.c;hb=l4t/l4t-r16-r2

Dmitry Osipenko (17):
  OPP: Allow to request stub voltage regulators
  soc/tegra: fuse: Export tegra_get_chip_id()
  dt-bindings: cpufreq: Add binding for NVIDIA Tegra20/30
  cpufreq: tegra20: Support OPP, thermal cooling, DVFS and Tegra30
  ARM: tegra: Create tegra20-cpufreq device on Tegra30
  ARM: dts: tegra20: Add CPU Operating Performance Points
  ARM: dts: tegra30: Add CPU Operating Performance Points
  ARM: dts: tegra20: colibri: Setup voltage regulators for DVFS
  ARM: dts: tegra20: harmony: Setup voltage regulators for DVFS
  ARM: dts: tegra20: paz00: Setup voltage regulators for DVFS
  ARM: dts: tegra20: seaboard: Setup voltage regulators for DVFS
  ARM: dts: tegra20: tamonten: Setup voltage regulators for DVFS
  ARM: dts: tegra20: ventana: Setup voltage regulators for DVFS
  ARM: dts: tegra30: apalis: Setup voltage regulators for DVFS
  ARM: dts: tegra30: beaver: Setup voltage regulators for DVFS
  ARM: dts: tegra30: cardhu: Setup voltage regulators for DVFS
  ARM: dts: tegra30: colibri: Setup voltage regulators for DVFS

 .../cpufreq/nvidia,tegra20-cpufreq.txt|  96 ++
 arch/arm/boot/dts/tegra20-colibri.dtsi|  31 +-
 arch/arm/boot/dts/tegra20-harmony.dts |  31 +-
 arch/arm/boot/dts/tegra20-paz00.dts   |  31 +-
 arch/arm/boot/dts/tegra20-seaboard.dts|  27 +-
 arch/arm/boot/dts/tegra20-tamonten.dtsi   |  31 +-
 arch/arm/boot/dts/tegra20-ventana.dts |  31 +-
 arch/arm/boot/dts/tegra20.dtsi| 277 ++
 arch/arm/boot/dts/tegra30-apalis.dtsi |  19 +-
 arch/arm/boot/dts/tegra30-beaver.dts  |  19 +-
 arch/arm/boot/dts/tegra30-cardhu.dtsi |  19 +-
 arch/arm/boot/dts/tegra30-colibri.dtsi|  19 +-
 arch/arm/boot/dts/tegra30.dtsi| 688 +++
 arch/arm/mach-tegra/tegra.c   |   4 +
 drivers/cpufreq/Kconfig.arm   |   2 +
 drivers/cpufreq/cpufreq-dt-platdev.c  |   2 +
 drivers/cpufreq/cpufreq-dt.c  |   2 +-
 drivers/cpufreq/tegra20-cpufreq.c | 832 +++---
 drivers/cpufreq/ti-cpufreq.c  |   3 +-
 drivers/opp/core.c|   9 +-
 drivers/soc/tegra/fuse/tegra-apbmisc.c|   1 +
 include/linux/pm_opp.h|   4 +-
 22 files changed, 2006 insertions(+), 172 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt

-- 
2.19.0

[RFC PATCH v2 09/17] ARM: dts: tegra20: harmony: Setup voltage regulators for DVFS

[Dmitry Osipenko]

Set min/max regulators voltage and add CPU node that hooks up CPU with
voltage regulators.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20-harmony.dts | 31 +++
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20-harmony.dts 
b/arch/arm/boot/dts/tegra20-harmony.dts
index 1d96d92b72a7..9d720743fd4e 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -339,17 +339,19 @@
regulator-always-on;
};
 
-   sm0 {
+   core_vdd_reg: sm0 {
regulator-name = "vdd_sm0,vdd_core";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = <_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
regulator-always-on;
};
 
-   sm1 {
+   cpu_vdd_reg: sm1 {
regulator-name = "vdd_sm1,vdd_cpu";
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <100>;
+   regulator-min-microvolt = <75>;
+   regulator-max-microvolt = <1125000>;
regulator-always-on;
};
 
@@ -373,10 +375,13 @@
regulator-always-on;
};
 
-   ldo2 {
+   rtc_vdd_reg: ldo2 {
regulator-name = "vdd_ldo2,vdd_rtc";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
+   regulator-min-microvolt = <95>;
+   regulator-max-microvolt = <130>;
+   regulator-coupled-with = 
<_vdd_reg>;
+   regulator-coupled-max-spread = <15>;
+   regulator-always-on;
};
 
ldo3 {
@@ -779,4 +784,12 @@
 <_car TEGRA20_CLK_CDEV1>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};
+
+   cpus {
+   cpu0: cpu@0 {
+   cpu-supply = <_vdd_reg>;
+   core-supply = <_vdd_reg>;
+   rtc-supply = <_vdd_reg>;
+   };
+   };
 };
-- 
2.19.0

[RFC PATCH v2 03/17] dt-bindings: cpufreq: Add binding for NVIDIA Tegra20/30

[Dmitry Osipenko]

Add device-tree binding that describes CPU frequency-scaling hardware
found on NVIDIA Tegra20/30 SoC's.

Signed-off-by: Dmitry Osipenko 
---
 .../cpufreq/nvidia,tegra20-cpufreq.txt| 96 +++
 1 file changed, 96 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt

diff --git 
a/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt 
b/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt
new file mode 100644
index ..a8023ea7a99f
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt
@@ -0,0 +1,96 @@
+Binding for NVIDIA Tegra20 CPUFreq
+==
+
+Required properties:
+- clocks: Must contain an entry for each entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names: Must include the following entries:
+  - pll_x: main-parent for CPU clock, must be the first entry
+  - intermediate: intermediate-parent for CPU clock
+  - cclk: the CPU clock
+- operating-points-v2: See ../bindings/opp/opp.txt for details.
+- #cooling-cells: Should be 2. See ../thermal/thermal.txt for details.
+
+For each opp entry in 'operating-points-v2' table:
+- opp-supported-hw: Two bitfields indicating:
+   On Tegra20:
+   1. CPU process ID mask
+   2. SoC speedo ID mask
+
+   On Tegra30:
+   1. CPU process ID mask
+   2. CPU speedo ID mask
+
+   A bitwise AND is performed against these values and if any bit
+   matches, the OPP gets enabled.
+
+- opp-microvolt: CPU voltage triplet.
+
+Optional properties:
+- cpu-supply: Phandle to the CPU power supply.
+- core-supply: Phandle to the CORE power supply.
+- rtc-supply: Phandle to the RTC power supply, required only for Tegra20.
+
+Voltage supply requirements:
+- Tegra20:
+   CORE and RTC regulators must be coupled using the regulator-coupled-with
+   property and regulator-coupled-max-spread property must be set to no
+   more than 170mV.
+
+   See ../regulator/regulator.txt for more detail about the properties.
+
+- Tegra30:
+   CORE and CPU regulators must be coupled using the regulator-coupled-with
+   property and regulator-coupled-max-spread property must be set to no
+   more than 300mV. Each of CORE and CPU regulators must set
+   regulator-max-step-microvolt property to no more than 100mV.
+
+   See ../regulator/regulator.txt for more detail about the properties.
+
+
+Example:
+   regulators {
+   cpu_reg: regulator0 {
+   regulator-name = "vdd_cpu";
+   };
+
+   core_reg: regulator1 {
+   regulator-name = "vdd_core";
+   regulator-coupled-with = <_reg>;
+   regulator-coupled-max-spread = <17>;
+   };
+
+   rtc_reg: regulator2 {
+   regulator-name = "vdd_rtc";
+   regulator-coupled-with = <_reg>;
+   regulator-coupled-max-spread = <17>;
+   };
+   };
+
+   cpu0_opp_table: opp_table0 {
+   compatible = "operating-points-v2";
+
+   opp@45600 {
+   clock-latency-ns = <125000>;
+   opp-microvolt = <825000 825000 1125000>;
+   opp-supported-hw = <0x03 0x0001>;
+   opp-hz = /bits/ 64 <45600>;
+   };
+
+   ...
+   };
+
+   cpus {
+   cpu@0 {
+   compatible = "arm,cortex-a9";
+   clocks = <_car TEGRA20_CLK_PLL_X>,
+<_car TEGRA20_CLK_PLL_P>,
+<_car TEGRA20_CLK_CCLK>;
+   clock-names = "pll_x", "intermediate", "cclk";
+   operating-points-v2 = <_opp_table>;
+   cpu-supply = <_reg>;
+   core-supply = <_reg>;
+   rtc-supply = <_reg>;
+   #cooling-cells = <2>;
+   };
+   };
-- 
2.19.0