Re: [PATCH] extcon: adc-jack: add suspend/resume support

[Chanwoo Choi]

Hi Venkat,

Applied it.

Thanks,
Chanwoo Choi


2016-06-30 17:54 GMT+09:00 Venkat Reddy Talla :
> adding suspend and resume funtionality for extcon-adc-jack
> driver to configure system wake up for extcon events,
> also adding support to enable/disable system wakeup
> through flag wakeup_source based on platform requirement.
>
> Signed-off-by: Venkat Reddy Talla 
> ---
>  drivers/extcon/extcon-adc-jack.c   | 34 
> ++
>  include/linux/extcon/extcon-adc-jack.h |  2 ++
>  2 files changed, 36 insertions(+)
>
> diff --git a/drivers/extcon/extcon-adc-jack.c 
> b/drivers/extcon/extcon-adc-jack.c
> index 7fc0ae1..44e48aa 100644
> --- a/drivers/extcon/extcon-adc-jack.c
> +++ b/drivers/extcon/extcon-adc-jack.c
> @@ -38,6 +38,7 @@
>   * @chan:  iio channel being queried.
>   */
>  struct adc_jack_data {
> +   struct device *dev;
> struct extcon_dev *edev;
>
> const unsigned int **cable_names;
> @@ -49,6 +50,7 @@ struct adc_jack_data {
> struct delayed_work handler;
>
> struct iio_channel *chan;
> +   bool wakeup_source;
>  };
>
>  static void adc_jack_handler(struct work_struct *work)
> @@ -105,6 +107,7 @@ static int adc_jack_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> +   data->dev = >dev;
> data->edev = devm_extcon_dev_allocate(>dev, pdata->cable_names);
> if (IS_ERR(data->edev)) {
> dev_err(>dev, "failed to allocate extcon device\n");
> @@ -128,6 +131,7 @@ static int adc_jack_probe(struct platform_device *pdev)
> return PTR_ERR(data->chan);
>
> data->handling_delay = msecs_to_jiffies(pdata->handling_delay_ms);
> +   data->wakeup_source = pdata->wakeup_source;
>
> INIT_DEFERRABLE_WORK(>handler, adc_jack_handler);
>
> @@ -151,6 +155,9 @@ static int adc_jack_probe(struct platform_device *pdev)
> return err;
> }
>
> +   if (data->wakeup_source)
> +   device_init_wakeup(>dev, 1);
> +
> return 0;
>  }
>
> @@ -165,11 +172,38 @@ static int adc_jack_remove(struct platform_device *pdev)
> return 0;
>  }
>
> +#ifdef CONFIG_PM_SLEEP
> +static int adc_jack_suspend(struct device *dev)
> +{
> +   struct adc_jack_data *data = dev_get_drvdata(dev);
> +
> +   cancel_delayed_work_sync(>handler);
> +   if (device_may_wakeup(data->dev))
> +   enable_irq_wake(data->irq);
> +
> +   return 0;
> +}
> +
> +static int adc_jack_resume(struct device *dev)
> +{
> +   struct adc_jack_data *data = dev_get_drvdata(dev);
> +
> +   if (device_may_wakeup(data->dev))
> +   disable_irq_wake(data->irq);
> +
> +   return 0;
> +}
> +#endif /* CONFIG_PM_SLEEP */
> +
> +static SIMPLE_DEV_PM_OPS(adc_jack_pm_ops,
> +   adc_jack_suspend, adc_jack_resume);
> +
>  static struct platform_driver adc_jack_driver = {
> .probe  = adc_jack_probe,
> .remove = adc_jack_remove,
> .driver = {
> .name   = "adc-jack",
> +   .pm = _jack_pm_ops,
> },
>  };
>
> diff --git a/include/linux/extcon/extcon-adc-jack.h 
> b/include/linux/extcon/extcon-adc-jack.h
> index 53c6080..ac85f20 100644
> --- a/include/linux/extcon/extcon-adc-jack.h
> +++ b/include/linux/extcon/extcon-adc-jack.h
> @@ -53,6 +53,7 @@ struct adc_jack_cond {
>   * milli-seconds after the interrupt occurs. You may
>   * describe such delays with @handling_delay_ms, which
>   * is rounded-off by jiffies.
> + * @wakeup_source: flag to wake up the system for extcon events.
>   */
>  struct adc_jack_pdata {
> const char *name;
> @@ -65,6 +66,7 @@ struct adc_jack_pdata {
>
> unsigned long irq_flags;
> unsigned long handling_delay_ms; /* in ms */
> +   bool wakeup_source;
>  };
>
>  #endif /* _EXTCON_ADC_JACK_H */
> --
> 2.1.4
>

Re: [PATCH] extcon: adc-jack: add suspend/resume support

[Chanwoo Choi]

Hi Venkat,

Applied it.

Thanks,
Chanwoo Choi


2016-06-30 17:54 GMT+09:00 Venkat Reddy Talla :
> adding suspend and resume funtionality for extcon-adc-jack
> driver to configure system wake up for extcon events,
> also adding support to enable/disable system wakeup
> through flag wakeup_source based on platform requirement.
>
> Signed-off-by: Venkat Reddy Talla 
> ---
>  drivers/extcon/extcon-adc-jack.c   | 34 
> ++
>  include/linux/extcon/extcon-adc-jack.h |  2 ++
>  2 files changed, 36 insertions(+)
>
> diff --git a/drivers/extcon/extcon-adc-jack.c 
> b/drivers/extcon/extcon-adc-jack.c
> index 7fc0ae1..44e48aa 100644
> --- a/drivers/extcon/extcon-adc-jack.c
> +++ b/drivers/extcon/extcon-adc-jack.c
> @@ -38,6 +38,7 @@
>   * @chan:  iio channel being queried.
>   */
>  struct adc_jack_data {
> +   struct device *dev;
> struct extcon_dev *edev;
>
> const unsigned int **cable_names;
> @@ -49,6 +50,7 @@ struct adc_jack_data {
> struct delayed_work handler;
>
> struct iio_channel *chan;
> +   bool wakeup_source;
>  };
>
>  static void adc_jack_handler(struct work_struct *work)
> @@ -105,6 +107,7 @@ static int adc_jack_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> +   data->dev = >dev;
> data->edev = devm_extcon_dev_allocate(>dev, pdata->cable_names);
> if (IS_ERR(data->edev)) {
> dev_err(>dev, "failed to allocate extcon device\n");
> @@ -128,6 +131,7 @@ static int adc_jack_probe(struct platform_device *pdev)
> return PTR_ERR(data->chan);
>
> data->handling_delay = msecs_to_jiffies(pdata->handling_delay_ms);
> +   data->wakeup_source = pdata->wakeup_source;
>
> INIT_DEFERRABLE_WORK(>handler, adc_jack_handler);
>
> @@ -151,6 +155,9 @@ static int adc_jack_probe(struct platform_device *pdev)
> return err;
> }
>
> +   if (data->wakeup_source)
> +   device_init_wakeup(>dev, 1);
> +
> return 0;
>  }
>
> @@ -165,11 +172,38 @@ static int adc_jack_remove(struct platform_device *pdev)
> return 0;
>  }
>
> +#ifdef CONFIG_PM_SLEEP
> +static int adc_jack_suspend(struct device *dev)
> +{
> +   struct adc_jack_data *data = dev_get_drvdata(dev);
> +
> +   cancel_delayed_work_sync(>handler);
> +   if (device_may_wakeup(data->dev))
> +   enable_irq_wake(data->irq);
> +
> +   return 0;
> +}
> +
> +static int adc_jack_resume(struct device *dev)
> +{
> +   struct adc_jack_data *data = dev_get_drvdata(dev);
> +
> +   if (device_may_wakeup(data->dev))
> +   disable_irq_wake(data->irq);
> +
> +   return 0;
> +}
> +#endif /* CONFIG_PM_SLEEP */
> +
> +static SIMPLE_DEV_PM_OPS(adc_jack_pm_ops,
> +   adc_jack_suspend, adc_jack_resume);
> +
>  static struct platform_driver adc_jack_driver = {
> .probe  = adc_jack_probe,
> .remove = adc_jack_remove,
> .driver = {
> .name   = "adc-jack",
> +   .pm = _jack_pm_ops,
> },
>  };
>
> diff --git a/include/linux/extcon/extcon-adc-jack.h 
> b/include/linux/extcon/extcon-adc-jack.h
> index 53c6080..ac85f20 100644
> --- a/include/linux/extcon/extcon-adc-jack.h
> +++ b/include/linux/extcon/extcon-adc-jack.h
> @@ -53,6 +53,7 @@ struct adc_jack_cond {
>   * milli-seconds after the interrupt occurs. You may
>   * describe such delays with @handling_delay_ms, which
>   * is rounded-off by jiffies.
> + * @wakeup_source: flag to wake up the system for extcon events.
>   */
>  struct adc_jack_pdata {
> const char *name;
> @@ -65,6 +66,7 @@ struct adc_jack_pdata {
>
> unsigned long irq_flags;
> unsigned long handling_delay_ms; /* in ms */
> +   bool wakeup_source;
>  };
>
>  #endif /* _EXTCON_ADC_JACK_H */
> --
> 2.1.4
>

[PATCH] device-tree: nexus7: Set phy mode to otg instead of host

[John Stultz]

In order to have the usb phy work in gadget mode, override
the default host mode with otg mode.

This allows gadget mode to work w/o any hacks to the dtsi file.

Cc: Rob Herring 
Cc: Andy Gross 
Cc: Bjorn Andersson 
Cc: Stephen Boyd 
Cc: linux-arm-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Signed-off-by: John Stultz 
---
 arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts 
b/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts
index 7b05f07..94e9cbb 100644
--- a/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts
@@ -253,6 +253,7 @@
vddcx-supply= <_s3>;
v3p3-supply = <_l3>;
v1p8-supply = <_l4>;
+   dr_mode = "otg";
};
 
gadget@1250 {
-- 
1.9.1

[PATCH] device-tree: nexus7: Set phy mode to otg instead of host

[John Stultz]

In order to have the usb phy work in gadget mode, override
the default host mode with otg mode.

This allows gadget mode to work w/o any hacks to the dtsi file.

Cc: Rob Herring 
Cc: Andy Gross 
Cc: Bjorn Andersson 
Cc: Stephen Boyd 
Cc: linux-arm-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Signed-off-by: John Stultz 
---
 arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts 
b/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts
index 7b05f07..94e9cbb 100644
--- a/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts
@@ -253,6 +253,7 @@
vddcx-supply= <_s3>;
v3p3-supply = <_l3>;
v1p8-supply = <_l4>;
+   dr_mode = "otg";
};
 
gadget@1250 {
-- 
1.9.1

Re: [PATCH 03/12] PM,devfreq: Employ atomic_fetch_inc()

[Chanwoo Choi]

Hi Davidlohr,


Acked-by: Chanwoo Choi 

Thanks,
Chanwoo Choi


2016-06-21 5:05 GMT+09:00 Davidlohr Bueso :
> Now that we have fetch_inc() we can stop using inc_return() - 1.
>
> These are very similar to the existing OP-RETURN primitives we already
> have, except they return the value of the atomic variable _before_
> modification.
>
> Cc: Chanwoo Choi 
> Cc: linux...@vger.kernel.org
> Signed-off-by: Davidlohr Bueso 
> ---
>  drivers/devfreq/devfreq-event.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/devfreq/devfreq-event.c b/drivers/devfreq/devfreq-event.c
> index 39b048eda2ce..45b02d3d7e7d 100644
> --- a/drivers/devfreq/devfreq-event.c
> +++ b/drivers/devfreq/devfreq-event.c
> @@ -329,7 +329,7 @@ struct devfreq_event_dev *devfreq_event_add_edev(struct 
> device *dev,
> edev->dev.class = devfreq_event_class;
> edev->dev.release = devfreq_event_release_edev;
>
> -   dev_set_name(>dev, "event.%d", atomic_inc_return(_no) - 
> 1);
> +   dev_set_name(>dev, "event.%d", atomic_fetch_inc(_no));
> ret = device_register(>dev);
> if (ret < 0) {
> put_device(>dev);
> --
> 2.6.6
>

Re: [PATCH 03/12] PM,devfreq: Employ atomic_fetch_inc()

[Chanwoo Choi]

Hi Davidlohr,


Acked-by: Chanwoo Choi 

Thanks,
Chanwoo Choi


2016-06-21 5:05 GMT+09:00 Davidlohr Bueso :
> Now that we have fetch_inc() we can stop using inc_return() - 1.
>
> These are very similar to the existing OP-RETURN primitives we already
> have, except they return the value of the atomic variable _before_
> modification.
>
> Cc: Chanwoo Choi 
> Cc: linux...@vger.kernel.org
> Signed-off-by: Davidlohr Bueso 
> ---
>  drivers/devfreq/devfreq-event.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/devfreq/devfreq-event.c b/drivers/devfreq/devfreq-event.c
> index 39b048eda2ce..45b02d3d7e7d 100644
> --- a/drivers/devfreq/devfreq-event.c
> +++ b/drivers/devfreq/devfreq-event.c
> @@ -329,7 +329,7 @@ struct devfreq_event_dev *devfreq_event_add_edev(struct 
> device *dev,
> edev->dev.class = devfreq_event_class;
> edev->dev.release = devfreq_event_release_edev;
>
> -   dev_set_name(>dev, "event.%d", atomic_inc_return(_no) - 
> 1);
> +   dev_set_name(>dev, "event.%d", atomic_fetch_inc(_no));
> ret = device_register(>dev);
> if (ret < 0) {
> put_device(>dev);
> --
> 2.6.6
>

Re: [PATCH 7/7] devfreq: exynos-bus: add missing of_node_put after calling of_parse_phandle

[Chanwoo Choi]

Hi Peter,

2016-07-01 18:42 GMT+09:00 Peter Chen :
> of_node_put needs to be called when the device node which is got
> from of_parse_phandle has finished using.
>
> Cc: Chanwoo Choi 
> Cc: MyungJoo Ham 
> Cc: Kyungmin Park 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Signed-off-by: Peter Chen 
> ---
>  drivers/devfreq/exynos-bus.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index 2363d0a..a38b5ec 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -383,7 +383,7 @@ err_clk:
>  static int exynos_bus_probe(struct platform_device *pdev)
>  {
> struct device *dev = >dev;
> -   struct device_node *np = dev->of_node;
> +   struct device_node *np = dev->of_node, node;
> struct devfreq_dev_profile *profile;
> struct devfreq_simple_ondemand_data *ondemand_data;
> struct devfreq_passive_data *passive_data;
> @@ -415,10 +415,13 @@ static int exynos_bus_probe(struct platform_device 
> *pdev)
> goto err;
> }
>
> -   if (of_parse_phandle(dev->of_node, "devfreq", 0))
> +   node = of_parse_phandle(dev->of_node, "devfreq", 0);
> +   if (node) {
> +   of_node_put(node);
> goto passive;
> -   else
> +   } else {
> ret = exynos_bus_parent_parse_of(np, bus);
> +   }
>
> if (ret < 0)
> goto err;

Acked-by: Chanwoo Choi 

Regards,
Chanwoo Choi

Re: [PATCH 7/7] devfreq: exynos-bus: add missing of_node_put after calling of_parse_phandle

[Chanwoo Choi]

Hi Peter,

2016-07-01 18:42 GMT+09:00 Peter Chen :
> of_node_put needs to be called when the device node which is got
> from of_parse_phandle has finished using.
>
> Cc: Chanwoo Choi 
> Cc: MyungJoo Ham 
> Cc: Kyungmin Park 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Signed-off-by: Peter Chen 
> ---
>  drivers/devfreq/exynos-bus.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index 2363d0a..a38b5ec 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -383,7 +383,7 @@ err_clk:
>  static int exynos_bus_probe(struct platform_device *pdev)
>  {
> struct device *dev = >dev;
> -   struct device_node *np = dev->of_node;
> +   struct device_node *np = dev->of_node, node;
> struct devfreq_dev_profile *profile;
> struct devfreq_simple_ondemand_data *ondemand_data;
> struct devfreq_passive_data *passive_data;
> @@ -415,10 +415,13 @@ static int exynos_bus_probe(struct platform_device 
> *pdev)
> goto err;
> }
>
> -   if (of_parse_phandle(dev->of_node, "devfreq", 0))
> +   node = of_parse_phandle(dev->of_node, "devfreq", 0);
> +   if (node) {
> +   of_node_put(node);
> goto passive;
> -   else
> +   } else {
> ret = exynos_bus_parent_parse_of(np, bus);
> +   }
>
> if (ret < 0)
> goto err;

Acked-by: Chanwoo Choi 

Regards,
Chanwoo Choi

Re: [PATCH] [media] rc: ir-spi: add support for IR LEDs connected with SPI

[kbuild test robot]

Hi,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.7-rc5 next-20160701]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andi-Shyti/rc-ir-spi-add-support-for-IR-LEDs-connected-with-SPI/20160702-102955
base:   git://linuxtv.org/media_tree.git master
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   include/linux/compiler.h:232:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
   drivers/media/rc/ir-spi.c:156:14: sparse: undefined identifier 
'LIRC_SET_LENGTH'
>> drivers/media/rc/ir-spi.c:156:14: sparse: incompatible types for 'case' 
>> statement
   drivers/media/rc/ir-spi.c:156:14: sparse: Expected constant expression in 
case statement
   drivers/media/rc/ir-spi.c: In function 'ir_spi_chardev_ioctl':
   drivers/media/rc/ir-spi.c:156:7: error: 'LIRC_SET_LENGTH' undeclared (first 
use in this function)
 case LIRC_SET_LENGTH: {
  ^~~
   drivers/media/rc/ir-spi.c:156:7: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/case +156 drivers/media/rc/ir-spi.c

   140  
   141  static long ir_spi_chardev_ioctl(struct file *file, unsigned int cmd,
   142  unsigned long arg)
   143  {
   144  __u32 p;
   145  s32 ret;
   146  struct ir_spi_data *idata = file->private_data;
   147  
   148  switch (cmd) {
   149  case LIRC_GET_FEATURES:
   150  return put_user(idata->lirc_driver.features,
   151  (__u32 __user *) arg);
   152  
   153  case LIRC_GET_LENGTH:
   154  return put_user(idata->xfer.len, (__u32 __user *) arg);
   155  
 > 156  case LIRC_SET_LENGTH: {
   157  void *new;
   158  
   159  ret = get_user(p, (__u32 __user *) arg);
   160  if (ret)
   161  return ret;
   162  
   163  /*
   164   * the user is trying to set the same

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

Re: [PATCH] [media] rc: ir-spi: add support for IR LEDs connected with SPI

[kbuild test robot]

Hi,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.7-rc5 next-20160701]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andi-Shyti/rc-ir-spi-add-support-for-IR-LEDs-connected-with-SPI/20160702-102955
base:   git://linuxtv.org/media_tree.git master
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   include/linux/compiler.h:232:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
   drivers/media/rc/ir-spi.c:156:14: sparse: undefined identifier 
'LIRC_SET_LENGTH'
>> drivers/media/rc/ir-spi.c:156:14: sparse: incompatible types for 'case' 
>> statement
   drivers/media/rc/ir-spi.c:156:14: sparse: Expected constant expression in 
case statement
   drivers/media/rc/ir-spi.c: In function 'ir_spi_chardev_ioctl':
   drivers/media/rc/ir-spi.c:156:7: error: 'LIRC_SET_LENGTH' undeclared (first 
use in this function)
 case LIRC_SET_LENGTH: {
  ^~~
   drivers/media/rc/ir-spi.c:156:7: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/case +156 drivers/media/rc/ir-spi.c

   140  
   141  static long ir_spi_chardev_ioctl(struct file *file, unsigned int cmd,
   142  unsigned long arg)
   143  {
   144  __u32 p;
   145  s32 ret;
   146  struct ir_spi_data *idata = file->private_data;
   147  
   148  switch (cmd) {
   149  case LIRC_GET_FEATURES:
   150  return put_user(idata->lirc_driver.features,
   151  (__u32 __user *) arg);
   152  
   153  case LIRC_GET_LENGTH:
   154  return put_user(idata->xfer.len, (__u32 __user *) arg);
   155  
 > 156  case LIRC_SET_LENGTH: {
   157  void *new;
   158  
   159  ret = get_user(p, (__u32 __user *) arg);
   160  if (ret)
   161  return ret;
   162  
   163  /*
   164   * the user is trying to set the same

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

Re: [PATCH 1/7] extcon: add missing of_node_put after calling of_parse_phandle

[Chanwoo Choi]

Hi Peter,

Applied it.

Regards,
Chanwoo Choi

2016-07-01 18:41 GMT+09:00 Peter Chen :
> of_node_put needs to be called when the device node which is got
> from of_parse_phandle has finished using.
>
> Cc: MyungJoo Ham 
> Cc: Chanwoo Choi 
> Signed-off-by: Peter Chen 
> ---
>  drivers/extcon/extcon.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
> index 21a123c..86ea14d 100644
> --- a/drivers/extcon/extcon.c
> +++ b/drivers/extcon/extcon.c
> @@ -1107,10 +1107,12 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct 
> device *dev, int index)
> list_for_each_entry(edev, _dev_list, entry) {
> if (edev->dev.parent && edev->dev.parent->of_node == node) {
> mutex_unlock(_dev_list_lock);
> +   of_node_put(node);
> return edev;
> }
> }
> mutex_unlock(_dev_list_lock);
> +   of_node_put(node);
>
> return ERR_PTR(-EPROBE_DEFER);
>  }
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/7] extcon: add missing of_node_put after calling of_parse_phandle

[Chanwoo Choi]

Hi Peter,

Applied it.

Regards,
Chanwoo Choi

2016-07-01 18:41 GMT+09:00 Peter Chen :
> of_node_put needs to be called when the device node which is got
> from of_parse_phandle has finished using.
>
> Cc: MyungJoo Ham 
> Cc: Chanwoo Choi 
> Signed-off-by: Peter Chen 
> ---
>  drivers/extcon/extcon.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
> index 21a123c..86ea14d 100644
> --- a/drivers/extcon/extcon.c
> +++ b/drivers/extcon/extcon.c
> @@ -1107,10 +1107,12 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct 
> device *dev, int index)
> list_for_each_entry(edev, _dev_list, entry) {
> if (edev->dev.parent && edev->dev.parent->of_node == node) {
> mutex_unlock(_dev_list_lock);
> +   of_node_put(node);
> return edev;
> }
> }
> mutex_unlock(_dev_list_lock);
> +   of_node_put(node);
>
> return ERR_PTR(-EPROBE_DEFER);
>  }
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] firmware: qcom: scm: Change initcall to subsys

[Andy Gross]

The patch changes the initcall for SCM to use subsys_initcall
instead of arch_initcall.  This corrects the order so that we don't
probe defer when trying to get clks which causes issues later when
the spm driver makes calls to qcom_set_warm_boot_addr().

The order became an issue due to the changes to use arch_initcall_sync
for of_platform_default_populate_init().

Signed-off-by: Andy Gross 
---
 drivers/firmware/qcom_scm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 89c3775..e64a501 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -415,7 +415,7 @@ static int __init qcom_scm_init(void)
return platform_driver_register(_scm_driver);
 }
 
-arch_initcall(qcom_scm_init);
+subsys_initcall(qcom_scm_init);
 
 static void __exit qcom_scm_exit(void)
 {
-- 
1.9.1

[PATCH] firmware: qcom: scm: Change initcall to subsys

[Andy Gross]

The patch changes the initcall for SCM to use subsys_initcall
instead of arch_initcall.  This corrects the order so that we don't
probe defer when trying to get clks which causes issues later when
the spm driver makes calls to qcom_set_warm_boot_addr().

The order became an issue due to the changes to use arch_initcall_sync
for of_platform_default_populate_init().

Signed-off-by: Andy Gross 
---
 drivers/firmware/qcom_scm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 89c3775..e64a501 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -415,7 +415,7 @@ static int __init qcom_scm_init(void)
return platform_driver_register(_scm_driver);
 }
 
-arch_initcall(qcom_scm_init);
+subsys_initcall(qcom_scm_init);
 
 static void __exit qcom_scm_exit(void)
 {
-- 
1.9.1

[PATCH] perf/x86: fix 32-bit perf user callgraph collection

[Josh Poimboeuf]

A basic perf callgraph record operation causes an immediate panic on a
32-bit kernel compiled with CONFIG_CC_STACKPROTECTOR:

  $ perf record -g ls
  Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: 
c0404fbd

  CPU: 0 PID: 998 Comm: ls Not tainted 4.7.0-rc5+ #1
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 
04/01/2014
   c0dd5967 ff7afe1c 0086 f41dbc2c c07445a0 464c457f f41dbca8 f41dbc44
   c05646f4 f41dbca8 464c457f f41dbca8 464c457f f41dbc54 c04625be c0ce56fc
   c0404fbd f41dbc88 c0404fbd b74668f0 f41dc000  c000 
  Call Trace:
   [] dump_stack+0x58/0x78
   [] panic+0x8e/0x1c6
   [] __stack_chk_fail+0x1e/0x30
   [] ? perf_callchain_user+0x22d/0x230
   [] perf_callchain_user+0x22d/0x230
   [] get_perf_callchain+0x1ff/0x270
   [] perf_callchain+0x78/0x90
   [] perf_prepare_sample+0x24b/0x370
   [] perf_event_output_forward+0x24/0x70
   [] __perf_event_overflow+0xa0/0x210
   [] ? cpu_clock_event_read+0x43/0x50
   [] perf_swevent_hrtimer+0x101/0x180
   [] ? kmap_atomic_prot+0x35/0x140
   [] ? get_page_from_freelist+0x279/0x950
   [] ? vma_interval_tree_remove+0x158/0x230
   [] ? wp_page_copy.isra.82+0x2f4/0x630
   [] ? page_add_file_rmap+0x1d/0x50
   [] ? unlock_page+0x61/0x80
   [] ? filemap_map_pages+0x305/0x320
   [] ? handle_mm_fault+0xb7f/0x1560
   [] ? timerqueue_del+0x1b/0x70
   [] ? __remove_hrtimer+0x2e/0x60
   [] __hrtimer_run_queues+0xcb/0x2a0
   [] ? __perf_event_overflow+0x210/0x210
   [] hrtimer_interrupt+0x8a/0x180
   [] local_apic_timer_interrupt+0x32/0x60
   [] smp_apic_timer_interrupt+0x33/0x50
   [] apic_timer_interrupt+0x34/0x3c
  Kernel Offset: disabled
  ---[ end Kernel panic - not syncing: stack-protector: Kernel stack is 
corrupted in: c0404fbd

The panic is caused by the fact that perf_callchain_user() mistakenly
assumes it's 64-bit only and ends up corrupting the stack.

Fixes: 75925e1ad7f5 ("perf/x86: Optimize stack walk user accesses")
Cc: sta...@vger.kernel.org
Signed-off-by: Josh Poimboeuf 
---
 arch/x86/events/core.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 929655d..d265e9eb 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -2342,7 +2342,7 @@ void
 perf_callchain_user(struct perf_callchain_entry_ctx *entry, struct pt_regs 
*regs)
 {
struct stack_frame frame;
-   const void __user *fp;
+   const unsigned long __user *fp;
 
if (perf_guest_cbs && perf_guest_cbs->is_in_guest()) {
/* TODO: We don't support guest os callchain now */
@@ -2355,7 +2355,7 @@ perf_callchain_user(struct perf_callchain_entry_ctx 
*entry, struct pt_regs *regs
if (regs->flags & (X86_VM_MASK | PERF_EFLAGS_VM))
return;
 
-   fp = (void __user *)regs->bp;
+   fp = (unsigned long __user *)regs->bp;
 
perf_callchain_store(entry, regs->ip);
 
@@ -2368,16 +2368,19 @@ perf_callchain_user(struct perf_callchain_entry_ctx 
*entry, struct pt_regs *regs
pagefault_disable();
while (entry->nr < entry->max_stack) {
unsigned long bytes;
+
frame.next_frame = NULL;
frame.return_address = 0;
 
-   if (!access_ok(VERIFY_READ, fp, 16))
+   if (!access_ok(VERIFY_READ, fp, sizeof(*fp) * 2))
break;
 
-   bytes = __copy_from_user_nmi(_frame, fp, 8);
+   bytes = __copy_from_user_nmi(_frame, fp,
+sizeof(*fp));
if (bytes != 0)
break;
-   bytes = __copy_from_user_nmi(_address, fp+8, 8);
+   bytes = __copy_from_user_nmi(_address,
+fp + 1, sizeof(*fp));
if (bytes != 0)
break;
 
-- 
2.7.4

[PATCH] perf/x86: fix 32-bit perf user callgraph collection

[Josh Poimboeuf]

A basic perf callgraph record operation causes an immediate panic on a
32-bit kernel compiled with CONFIG_CC_STACKPROTECTOR:

  $ perf record -g ls
  Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: 
c0404fbd

  CPU: 0 PID: 998 Comm: ls Not tainted 4.7.0-rc5+ #1
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 
04/01/2014
   c0dd5967 ff7afe1c 0086 f41dbc2c c07445a0 464c457f f41dbca8 f41dbc44
   c05646f4 f41dbca8 464c457f f41dbca8 464c457f f41dbc54 c04625be c0ce56fc
   c0404fbd f41dbc88 c0404fbd b74668f0 f41dc000  c000 
  Call Trace:
   [] dump_stack+0x58/0x78
   [] panic+0x8e/0x1c6
   [] __stack_chk_fail+0x1e/0x30
   [] ? perf_callchain_user+0x22d/0x230
   [] perf_callchain_user+0x22d/0x230
   [] get_perf_callchain+0x1ff/0x270
   [] perf_callchain+0x78/0x90
   [] perf_prepare_sample+0x24b/0x370
   [] perf_event_output_forward+0x24/0x70
   [] __perf_event_overflow+0xa0/0x210
   [] ? cpu_clock_event_read+0x43/0x50
   [] perf_swevent_hrtimer+0x101/0x180
   [] ? kmap_atomic_prot+0x35/0x140
   [] ? get_page_from_freelist+0x279/0x950
   [] ? vma_interval_tree_remove+0x158/0x230
   [] ? wp_page_copy.isra.82+0x2f4/0x630
   [] ? page_add_file_rmap+0x1d/0x50
   [] ? unlock_page+0x61/0x80
   [] ? filemap_map_pages+0x305/0x320
   [] ? handle_mm_fault+0xb7f/0x1560
   [] ? timerqueue_del+0x1b/0x70
   [] ? __remove_hrtimer+0x2e/0x60
   [] __hrtimer_run_queues+0xcb/0x2a0
   [] ? __perf_event_overflow+0x210/0x210
   [] hrtimer_interrupt+0x8a/0x180
   [] local_apic_timer_interrupt+0x32/0x60
   [] smp_apic_timer_interrupt+0x33/0x50
   [] apic_timer_interrupt+0x34/0x3c
  Kernel Offset: disabled
  ---[ end Kernel panic - not syncing: stack-protector: Kernel stack is 
corrupted in: c0404fbd

The panic is caused by the fact that perf_callchain_user() mistakenly
assumes it's 64-bit only and ends up corrupting the stack.

Fixes: 75925e1ad7f5 ("perf/x86: Optimize stack walk user accesses")
Cc: sta...@vger.kernel.org
Signed-off-by: Josh Poimboeuf 
---
 arch/x86/events/core.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 929655d..d265e9eb 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -2342,7 +2342,7 @@ void
 perf_callchain_user(struct perf_callchain_entry_ctx *entry, struct pt_regs 
*regs)
 {
struct stack_frame frame;
-   const void __user *fp;
+   const unsigned long __user *fp;
 
if (perf_guest_cbs && perf_guest_cbs->is_in_guest()) {
/* TODO: We don't support guest os callchain now */
@@ -2355,7 +2355,7 @@ perf_callchain_user(struct perf_callchain_entry_ctx 
*entry, struct pt_regs *regs
if (regs->flags & (X86_VM_MASK | PERF_EFLAGS_VM))
return;
 
-   fp = (void __user *)regs->bp;
+   fp = (unsigned long __user *)regs->bp;
 
perf_callchain_store(entry, regs->ip);
 
@@ -2368,16 +2368,19 @@ perf_callchain_user(struct perf_callchain_entry_ctx 
*entry, struct pt_regs *regs
pagefault_disable();
while (entry->nr < entry->max_stack) {
unsigned long bytes;
+
frame.next_frame = NULL;
frame.return_address = 0;
 
-   if (!access_ok(VERIFY_READ, fp, 16))
+   if (!access_ok(VERIFY_READ, fp, sizeof(*fp) * 2))
break;
 
-   bytes = __copy_from_user_nmi(_frame, fp, 8);
+   bytes = __copy_from_user_nmi(_frame, fp,
+sizeof(*fp));
if (bytes != 0)
break;
-   bytes = __copy_from_user_nmi(_address, fp+8, 8);
+   bytes = __copy_from_user_nmi(_address,
+fp + 1, sizeof(*fp));
if (bytes != 0)
break;
 
-- 
2.7.4

Re: [PATCH] [media] rc: ir-spi: add support for IR LEDs connected with SPI

[kbuild test robot]

Hi,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.7-rc5 next-20160701]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andi-Shyti/rc-ir-spi-add-support-for-IR-LEDs-connected-with-SPI/20160702-102955
base:   git://linuxtv.org/media_tree.git master
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/media/rc/ir-spi.c: In function 'ir_spi_chardev_ioctl':
>> drivers/media/rc/ir-spi.c:156:7: error: 'LIRC_SET_LENGTH' undeclared (first 
>> use in this function)
 case LIRC_SET_LENGTH: {
  ^~~
   drivers/media/rc/ir-spi.c:156:7: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/LIRC_SET_LENGTH +156 drivers/media/rc/ir-spi.c

   150  return put_user(idata->lirc_driver.features,
   151  (__u32 __user *) arg);
   152  
   153  case LIRC_GET_LENGTH:
   154  return put_user(idata->xfer.len, (__u32 __user *) arg);
   155  
 > 156  case LIRC_SET_LENGTH: {
   157  void *new;
   158  
   159  ret = get_user(p, (__u32 __user *) arg);

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


.config.gz
Description: Binary data

Re: [PATCH] [media] rc: ir-spi: add support for IR LEDs connected with SPI

[kbuild test robot]

Hi,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.7-rc5 next-20160701]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andi-Shyti/rc-ir-spi-add-support-for-IR-LEDs-connected-with-SPI/20160702-102955
base:   git://linuxtv.org/media_tree.git master
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/media/rc/ir-spi.c: In function 'ir_spi_chardev_ioctl':
>> drivers/media/rc/ir-spi.c:156:7: error: 'LIRC_SET_LENGTH' undeclared (first 
>> use in this function)
 case LIRC_SET_LENGTH: {
  ^~~
   drivers/media/rc/ir-spi.c:156:7: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/LIRC_SET_LENGTH +156 drivers/media/rc/ir-spi.c

   150  return put_user(idata->lirc_driver.features,
   151  (__u32 __user *) arg);
   152  
   153  case LIRC_GET_LENGTH:
   154  return put_user(idata->xfer.len, (__u32 __user *) arg);
   155  
 > 156  case LIRC_SET_LENGTH: {
   157  void *new;
   158  
   159  ret = get_user(p, (__u32 __user *) arg);

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


.config.gz
Description: Binary data

Re: [PATCH v2] arm64: dts: rockchip: add the power domain node for rk3399

[William Wu]

Dear Caesar & Doug,


On 07/02/2016 09:34 AM, Caesar Wang wrote:
>
> On 2016年07月02日 00:56, Doug Anderson wrote:
>> Caesar
>>
>> On Thu, Jun 30, 2016 at 9:32 PM, Caesar Wang  wrote:
>>> From: Elaine Zhang 
>>>
>>> In order to meet low power requirements, a power management unit
>>> (PMU) is
>>> designed for controlling power resources in RK3399. The RK3399 PMU is
>>> dedicated for managing the power of the whole chip.
>>>
>>> 1. add pd node for RK3399 Soc
>>> 2. create power domain tree
>>> 3. add qos node for domain
>>>
>>> From the DT/binds and driver can get more detail information:
>>> The driver:
>>> drivers/soc/rockchip/pm_domains.c
>>> The document:
>>> Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
>>> ---
>>>
>>> Changes in v2:
>>> - As Doug/Heiko commnets on
>>> https://patchwork.kernel.org/patch/9206415/.
>>> drop the debugfs-dump and Add the comments for alphabetical order.
>>>
>>> Note: As the TRM lists many voltage domains and power domains, then
>>> in actual we just need control some domains for driver.
>>> Due to some domains (e.g. emmc, usb, core)...We can't turn off it on
>>> bootup.
>> I'm curious: why can't you turn off USB power domains if a board
>> doesn't usb USB? ...or GMAC on boards that don't use Ethernet? ...or
>> eDP on boards that don't use EDP?
>>
>> Maybe the driver for these things isn't ready to handle power domains
>> yet so that's why they are left out for now?
>>
>> It seems like GMAC could at least be added because we don't even have
>> the GMAC listed in the current device tree so therefore there can't be
>> any users of it. When it's added we can make sure that the power
>> domains are added.
>
> At least, the gmac had been supported in rockchip inside.
> That's seem the gmac driver can't handle the power domain enough.
> -- 
>
> Frankly, I'm no test the GMAC，then this patch should support most of
> devices.
> We can send another patch to support it if someone（usb/gmac) can
> handle the power domain.
>
>>
>> I think in the current upstream dtsi file there is also no xhci node,
>> so does that mean you could add the USB3 power domain?
>>
>>
>
> willam@RK, what's think of it？
RK3399 support XHCI controller, but it's integrated in DWC3 IP core,
and we don't need to add xhci node separately, but just add dwc3
node like this:
usbdrd3_0: usb@fe80 {
compatible = "rockchip,rk3399-dwc3";
..
ranges;
status = "disabled";
usbdrd_dwc3_0: dwc3@fe80 {
compatible = "snps,dwc3";
reg = <0x0 0xfe80 0x0 0x10>;
interrupts = ;
dr_mode = "otg";
..
};
};

And I'm working on DWC3 upstream.
RK3399 have two usb power domain (pd_perihp usb2 and pd_usb3),
usb driver isn't ready to handle power domain for the time being,
but we're trying to support usb power domain control.

Best regards,
William Wu
>
>>> Signed-off-by: Elaine Zhang 
>>> Signed-off-by: Caesar Wang 
>>> Cc: linux-arm-ker...@lists.infradead.org
>>> Cc: linux-rockc...@lists.infradead.org
>>> Cc: Heiko Stuebner 
>>>
>>> ---
>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 179
>>> +++
>>> 1 file changed, 179 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> index a6dd623..103e185 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> @@ -45,6 +45,7 @@
>>> #include 
>>> #include 
>>> #include 
>>> +#include 
>>> #include 
>>>
>>> / {
>>> @@ -594,6 +595,184 @@
>>> status = "disabled";
>>> };
>>>
>>> + qos_hdcp: qos_hdcp@ffa9 {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffa9 0x0 0x20>;
>>> + };
>>> +
>>> + qos_iep: qos_iep@ffa98000 {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffa98000 0x0 0x20>;
>>> + };
>>> +
>>> + qos_isp0_m0: qos_isp0_m0@ffaa {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffaa 0x0 0x20>;
>>> + };
>>> +
>>> + qos_isp0_m1: qos_isp0_m1@ffaa0080 {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffaa0080 0x0 0x20>;
>>> + };
>>> +
>>> + qos_isp1_m0: qos_isp1_m0@ffaa8000 {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffaa8000 0x0 0x20>;
>>> + };
>>> +
>>> + qos_isp1_m1: qos_isp1_m1@ffaa8080 {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffaa8080 0x0 0x20>;
>>> + };
>>> +
>>> + qos_rga_r: qos_rga_r@ffab {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffab 0x0 0x20>;
>>> + };
>>> +
>>> + qos_rga_w: qos_rga_w@ffab0080 {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffab0080 0x0 0x20>;
>>> + };
>>> +
>>> + qos_video_m0: qos_video_m0@ffab8000 {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffab8000 0x0 0x20>;
>>> + };
>>> +
>>> + qos_video_m1_r: qos_video_m1_r@ffac {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffac 0x0 0x20>;
>>> + };
>>> +
>>> + qos_video_m1_w: qos_video_m1_w@ffac0080 {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffac0080 0x0 0x20>;
>>> + 

Re: [PATCH v2] arm64: dts: rockchip: add the power domain node for rk3399

[William Wu]

Dear Caesar & Doug,


On 07/02/2016 09:34 AM, Caesar Wang wrote:
>
> On 2016年07月02日 00:56, Doug Anderson wrote:
>> Caesar
>>
>> On Thu, Jun 30, 2016 at 9:32 PM, Caesar Wang  wrote:
>>> From: Elaine Zhang 
>>>
>>> In order to meet low power requirements, a power management unit
>>> (PMU) is
>>> designed for controlling power resources in RK3399. The RK3399 PMU is
>>> dedicated for managing the power of the whole chip.
>>>
>>> 1. add pd node for RK3399 Soc
>>> 2. create power domain tree
>>> 3. add qos node for domain
>>>
>>> From the DT/binds and driver can get more detail information:
>>> The driver:
>>> drivers/soc/rockchip/pm_domains.c
>>> The document:
>>> Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
>>> ---
>>>
>>> Changes in v2:
>>> - As Doug/Heiko commnets on
>>> https://patchwork.kernel.org/patch/9206415/.
>>> drop the debugfs-dump and Add the comments for alphabetical order.
>>>
>>> Note: As the TRM lists many voltage domains and power domains, then
>>> in actual we just need control some domains for driver.
>>> Due to some domains (e.g. emmc, usb, core)...We can't turn off it on
>>> bootup.
>> I'm curious: why can't you turn off USB power domains if a board
>> doesn't usb USB? ...or GMAC on boards that don't use Ethernet? ...or
>> eDP on boards that don't use EDP?
>>
>> Maybe the driver for these things isn't ready to handle power domains
>> yet so that's why they are left out for now?
>>
>> It seems like GMAC could at least be added because we don't even have
>> the GMAC listed in the current device tree so therefore there can't be
>> any users of it. When it's added we can make sure that the power
>> domains are added.
>
> At least, the gmac had been supported in rockchip inside.
> That's seem the gmac driver can't handle the power domain enough.
> -- 
>
> Frankly, I'm no test the GMAC，then this patch should support most of
> devices.
> We can send another patch to support it if someone（usb/gmac) can
> handle the power domain.
>
>>
>> I think in the current upstream dtsi file there is also no xhci node,
>> so does that mean you could add the USB3 power domain?
>>
>>
>
> willam@RK, what's think of it？
RK3399 support XHCI controller, but it's integrated in DWC3 IP core,
and we don't need to add xhci node separately, but just add dwc3
node like this:
usbdrd3_0: usb@fe80 {
compatible = "rockchip,rk3399-dwc3";
..
ranges;
status = "disabled";
usbdrd_dwc3_0: dwc3@fe80 {
compatible = "snps,dwc3";
reg = <0x0 0xfe80 0x0 0x10>;
interrupts = ;
dr_mode = "otg";
..
};
};

And I'm working on DWC3 upstream.
RK3399 have two usb power domain (pd_perihp usb2 and pd_usb3),
usb driver isn't ready to handle power domain for the time being,
but we're trying to support usb power domain control.

Best regards,
William Wu
>
>>> Signed-off-by: Elaine Zhang 
>>> Signed-off-by: Caesar Wang 
>>> Cc: linux-arm-ker...@lists.infradead.org
>>> Cc: linux-rockc...@lists.infradead.org
>>> Cc: Heiko Stuebner 
>>>
>>> ---
>>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 179
>>> +++
>>> 1 file changed, 179 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> index a6dd623..103e185 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> @@ -45,6 +45,7 @@
>>> #include 
>>> #include 
>>> #include 
>>> +#include 
>>> #include 
>>>
>>> / {
>>> @@ -594,6 +595,184 @@
>>> status = "disabled";
>>> };
>>>
>>> + qos_hdcp: qos_hdcp@ffa9 {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffa9 0x0 0x20>;
>>> + };
>>> +
>>> + qos_iep: qos_iep@ffa98000 {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffa98000 0x0 0x20>;
>>> + };
>>> +
>>> + qos_isp0_m0: qos_isp0_m0@ffaa {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffaa 0x0 0x20>;
>>> + };
>>> +
>>> + qos_isp0_m1: qos_isp0_m1@ffaa0080 {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffaa0080 0x0 0x20>;
>>> + };
>>> +
>>> + qos_isp1_m0: qos_isp1_m0@ffaa8000 {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffaa8000 0x0 0x20>;
>>> + };
>>> +
>>> + qos_isp1_m1: qos_isp1_m1@ffaa8080 {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffaa8080 0x0 0x20>;
>>> + };
>>> +
>>> + qos_rga_r: qos_rga_r@ffab {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffab 0x0 0x20>;
>>> + };
>>> +
>>> + qos_rga_w: qos_rga_w@ffab0080 {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffab0080 0x0 0x20>;
>>> + };
>>> +
>>> + qos_video_m0: qos_video_m0@ffab8000 {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffab8000 0x0 0x20>;
>>> + };
>>> +
>>> + qos_video_m1_r: qos_video_m1_r@ffac {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffac 0x0 0x20>;
>>> + };
>>> +
>>> + qos_video_m1_w: qos_video_m1_w@ffac0080 {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffac0080 0x0 0x20>;
>>> + };
>>> +
>>> + qos_vop_big_r: qos_vop_big_r@ffac8000 {
>>> + compatible = "syscon";
>>> + reg = <0x0 0xffac8000 

kernel/trace/trace.h:516:28: error: 'struct task_struct' has no member named 'trace_recursion'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   dbdc3bb74faeec5fd92e28c15c945045d5aab426
commit: 7ef224d1d0e3a1ade02d02c01ce1dcffb736d2c3 tracing: Add 'hist' event 
trigger command
date:   2 months ago
config: x86_64-randconfig-s0-07021107 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
git checkout 7ef224d1d0e3a1ade02d02c01ce1dcffb736d2c3
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from kernel/trace/tracing_map.c:29:0:
   kernel/trace/trace.h: In function 'trace_test_and_set_recursion':
>> kernel/trace/trace.h:516:28: error: 'struct task_struct' has no member named 
>> 'trace_recursion'
 unsigned int val = current->trace_recursion;
   ^~
   kernel/trace/trace.h:528:9: error: 'struct task_struct' has no member named 
'trace_recursion'
 current->trace_recursion = val;
^~
   kernel/trace/trace.h: In function 'trace_clear_recursion':
   kernel/trace/trace.h:536:28: error: 'struct task_struct' has no member named 
'trace_recursion'
 unsigned int val = current->trace_recursion;
   ^~
   kernel/trace/trace.h:545:9: error: 'struct task_struct' has no member named 
'trace_recursion'
 current->trace_recursion = val;
^~

vim +516 kernel/trace/trace.h

edc15caf Steven Rostedt 2012-11-02  510  
edc15caf Steven Rostedt 2012-11-02  511 return bit;
edc15caf Steven Rostedt 2012-11-02  512  }
edc15caf Steven Rostedt 2012-11-02  513  
edc15caf Steven Rostedt 2012-11-02  514  static __always_inline int 
trace_test_and_set_recursion(int start, int max)
edc15caf Steven Rostedt 2012-11-02  515  {
edc15caf Steven Rostedt 2012-11-02 @516 unsigned int val = 
current->trace_recursion;
edc15caf Steven Rostedt 2012-11-02  517 int bit;
edc15caf Steven Rostedt 2012-11-02  518  
edc15caf Steven Rostedt 2012-11-02  519 /* A previous recursion check 
was made */

:: The code at line 516 was first introduced by commit
:: edc15cafcbfa3d73f819cae99885a2e35e4cbce5 tracing: Avoid unnecessary 
multiple recursion checks

:: TO: Steven Rostedt 
:: CC: Steven Rostedt 

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


.config.gz
Description: Binary data

kernel/trace/trace.h:516:28: error: 'struct task_struct' has no member named 'trace_recursion'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   dbdc3bb74faeec5fd92e28c15c945045d5aab426
commit: 7ef224d1d0e3a1ade02d02c01ce1dcffb736d2c3 tracing: Add 'hist' event 
trigger command
date:   2 months ago
config: x86_64-randconfig-s0-07021107 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
git checkout 7ef224d1d0e3a1ade02d02c01ce1dcffb736d2c3
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from kernel/trace/tracing_map.c:29:0:
   kernel/trace/trace.h: In function 'trace_test_and_set_recursion':
>> kernel/trace/trace.h:516:28: error: 'struct task_struct' has no member named 
>> 'trace_recursion'
 unsigned int val = current->trace_recursion;
   ^~
   kernel/trace/trace.h:528:9: error: 'struct task_struct' has no member named 
'trace_recursion'
 current->trace_recursion = val;
^~
   kernel/trace/trace.h: In function 'trace_clear_recursion':
   kernel/trace/trace.h:536:28: error: 'struct task_struct' has no member named 
'trace_recursion'
 unsigned int val = current->trace_recursion;
   ^~
   kernel/trace/trace.h:545:9: error: 'struct task_struct' has no member named 
'trace_recursion'
 current->trace_recursion = val;
^~

vim +516 kernel/trace/trace.h

edc15caf Steven Rostedt 2012-11-02  510  
edc15caf Steven Rostedt 2012-11-02  511 return bit;
edc15caf Steven Rostedt 2012-11-02  512  }
edc15caf Steven Rostedt 2012-11-02  513  
edc15caf Steven Rostedt 2012-11-02  514  static __always_inline int 
trace_test_and_set_recursion(int start, int max)
edc15caf Steven Rostedt 2012-11-02  515  {
edc15caf Steven Rostedt 2012-11-02 @516 unsigned int val = 
current->trace_recursion;
edc15caf Steven Rostedt 2012-11-02  517 int bit;
edc15caf Steven Rostedt 2012-11-02  518  
edc15caf Steven Rostedt 2012-11-02  519 /* A previous recursion check 
was made */

:: The code at line 516 was first introduced by commit
:: edc15cafcbfa3d73f819cae99885a2e35e4cbce5 tracing: Avoid unnecessary 
multiple recursion checks

:: TO: Steven Rostedt 
:: CC: Steven Rostedt 

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


.config.gz
Description: Binary data

[PATCH] block: do not merge requests without consulting with io scheduler

[Tahsin Erdogan]

Before merging a bio into an existing request, io scheduler is called to
get its approval first. However, the requests that come from a plug
flush may get merged by block layer without consulting with io
scheduler.

In case of CFQ, this can cause fairness problems. For instance, if a
request gets merged into a low weight cgroup's request, high weight cgroup
now will depend on low weight cgroup to get scheduled. If high weigt cgroup
needs that io request to complete before submitting more requests, then it
will also lose its timeslice.

Following script demonstrates the problem. Group g1 has a low weight, g2
and g3 have equal high weights but g2's requests are adjacent to g1's
requests so they are subject to merging. Due to these merges, g2 gets
poor disk time allocation.

cat > cfq-merge-repro.sh << "EOF"
#!/bin/bash
set -e

IO_ROOT=/mnt-cgroup/io

mkdir -p $IO_ROOT

if ! mount | grep -qw $IO_ROOT; then
  mount -t cgroup none -oblkio $IO_ROOT
fi

cd $IO_ROOT

for i in g1 g2 g3; do
  if [ -d $i ]; then
rmdir $i
  fi
done

mkdir g1 && echo 10 > g1/blkio.weight
mkdir g2 && echo 495 > g2/blkio.weight
mkdir g3 && echo 495 > g3/blkio.weight

RUNTIME=10

(echo $BASHPID > g1/cgroup.procs &&
 fio --readonly --name name1 --filename /dev/sdb \
 --rw read --size 64k --bs 64k --time_based \
 --runtime=$RUNTIME --offset=0k &> /dev/null)&

(echo $BASHPID > g2/cgroup.procs &&
 fio --readonly --name name1 --filename /dev/sdb \
 --rw read --size 64k --bs 64k --time_based \
 --runtime=$RUNTIME --offset=64k &> /dev/null)&

(echo $BASHPID > g3/cgroup.procs &&
 fio --readonly --name name1 --filename /dev/sdb \
 --rw read --size 64k --bs 64k --time_based \
 --runtime=$RUNTIME --offset=256k &> /dev/null)&

sleep $((RUNTIME+1))

for i in g1 g2 g3; do
  echo  $i 
  cat $i/blkio.time
done

EOF
# ./cfq-merge-repro.sh
 g1 
8:16 162
 g2 
8:16 165
 g3 
8:16 686

After applying the patch:

# ./cfq-merge-repro.sh
 g1 
8:16 90
 g2 
8:16 445
 g3 
8:16 471

Signed-off-by: Tahsin Erdogan 
---
 block/blk-merge.c|  6 ++
 block/cfq-iosched.c  | 15 +++
 block/deadline-iosched.c |  2 +-
 block/elevator.c | 16 
 include/linux/elevator.h | 11 ---
 5 files changed, 34 insertions(+), 16 deletions(-)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index 261353166dcf..624171db0942 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -743,6 +743,12 @@ int attempt_front_merge(struct request_queue *q, struct 
request *rq)
 int blk_attempt_req_merge(struct request_queue *q, struct request *rq,
  struct request *next)
 {
+   struct elevator_queue *e = q->elevator;
+
+   if (e->type->ops.elevator_allow_rq_merge_fn)
+   if (!e->type->ops.elevator_allow_rq_merge_fn(q, rq, next))
+   return 0;
+
return attempt_merge(q, rq, next);
 }
 
diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index 4a349787bc62..2209e2bf9636 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -2531,7 +2531,7 @@ static int cfq_merge(struct request_queue *q, struct 
request **req,
struct request *__rq;
 
__rq = cfq_find_rq_fmerge(cfqd, bio);
-   if (__rq && elv_rq_merge_ok(__rq, bio)) {
+   if (__rq && elv_bio_merge_ok(__rq, bio)) {
*req = __rq;
return ELEVATOR_FRONT_MERGE;
}
@@ -2588,8 +2588,8 @@ cfq_merged_requests(struct request_queue *q, struct 
request *rq,
cfq_del_cfqq_rr(cfqd, cfqq);
 }
 
-static int cfq_allow_merge(struct request_queue *q, struct request *rq,
-  struct bio *bio)
+static int cfq_allow_bio_merge(struct request_queue *q, struct request *rq,
+  struct bio *bio)
 {
struct cfq_data *cfqd = q->elevator->elevator_data;
struct cfq_io_cq *cic;
@@ -2613,6 +2613,12 @@ static int cfq_allow_merge(struct request_queue *q, 
struct request *rq,
return cfqq == RQ_CFQQ(rq);
 }
 
+static int cfq_allow_rq_merge(struct request_queue *q, struct request *rq,
+ struct request *next)
+{
+   return RQ_CFQQ(rq) == RQ_CFQQ(next);
+}
+
 static inline void cfq_del_timer(struct cfq_data *cfqd, struct cfq_queue *cfqq)
 {
del_timer(>idle_slice_timer);
@@ -4729,7 +4735,8 @@ static struct elevator_type iosched_cfq = {
.elevator_merge_fn =cfq_merge,
.elevator_merged_fn =   cfq_merged_request,
.elevator_merge_req_fn =cfq_merged_requests,
-   .elevator_allow_merge_fn =  cfq_allow_merge,
+   .elevator_allow_bio_merge_fn =  cfq_allow_bio_merge,
+   .elevator_allow_rq_merge_fn =   cfq_allow_rq_merge,
.elevator_bio_merged_fn =   cfq_bio_merged,
.elevator_dispatch_fn = cfq_dispatch_requests,
 

[PATCH] block: do not merge requests without consulting with io scheduler

[Tahsin Erdogan]

Before merging a bio into an existing request, io scheduler is called to
get its approval first. However, the requests that come from a plug
flush may get merged by block layer without consulting with io
scheduler.

In case of CFQ, this can cause fairness problems. For instance, if a
request gets merged into a low weight cgroup's request, high weight cgroup
now will depend on low weight cgroup to get scheduled. If high weigt cgroup
needs that io request to complete before submitting more requests, then it
will also lose its timeslice.

Following script demonstrates the problem. Group g1 has a low weight, g2
and g3 have equal high weights but g2's requests are adjacent to g1's
requests so they are subject to merging. Due to these merges, g2 gets
poor disk time allocation.

cat > cfq-merge-repro.sh << "EOF"
#!/bin/bash
set -e

IO_ROOT=/mnt-cgroup/io

mkdir -p $IO_ROOT

if ! mount | grep -qw $IO_ROOT; then
  mount -t cgroup none -oblkio $IO_ROOT
fi

cd $IO_ROOT

for i in g1 g2 g3; do
  if [ -d $i ]; then
rmdir $i
  fi
done

mkdir g1 && echo 10 > g1/blkio.weight
mkdir g2 && echo 495 > g2/blkio.weight
mkdir g3 && echo 495 > g3/blkio.weight

RUNTIME=10

(echo $BASHPID > g1/cgroup.procs &&
 fio --readonly --name name1 --filename /dev/sdb \
 --rw read --size 64k --bs 64k --time_based \
 --runtime=$RUNTIME --offset=0k &> /dev/null)&

(echo $BASHPID > g2/cgroup.procs &&
 fio --readonly --name name1 --filename /dev/sdb \
 --rw read --size 64k --bs 64k --time_based \
 --runtime=$RUNTIME --offset=64k &> /dev/null)&

(echo $BASHPID > g3/cgroup.procs &&
 fio --readonly --name name1 --filename /dev/sdb \
 --rw read --size 64k --bs 64k --time_based \
 --runtime=$RUNTIME --offset=256k &> /dev/null)&

sleep $((RUNTIME+1))

for i in g1 g2 g3; do
  echo  $i 
  cat $i/blkio.time
done

EOF
# ./cfq-merge-repro.sh
 g1 
8:16 162
 g2 
8:16 165
 g3 
8:16 686

After applying the patch:

# ./cfq-merge-repro.sh
 g1 
8:16 90
 g2 
8:16 445
 g3 
8:16 471

Signed-off-by: Tahsin Erdogan 
---
 block/blk-merge.c|  6 ++
 block/cfq-iosched.c  | 15 +++
 block/deadline-iosched.c |  2 +-
 block/elevator.c | 16 
 include/linux/elevator.h | 11 ---
 5 files changed, 34 insertions(+), 16 deletions(-)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index 261353166dcf..624171db0942 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -743,6 +743,12 @@ int attempt_front_merge(struct request_queue *q, struct 
request *rq)
 int blk_attempt_req_merge(struct request_queue *q, struct request *rq,
  struct request *next)
 {
+   struct elevator_queue *e = q->elevator;
+
+   if (e->type->ops.elevator_allow_rq_merge_fn)
+   if (!e->type->ops.elevator_allow_rq_merge_fn(q, rq, next))
+   return 0;
+
return attempt_merge(q, rq, next);
 }
 
diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index 4a349787bc62..2209e2bf9636 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -2531,7 +2531,7 @@ static int cfq_merge(struct request_queue *q, struct 
request **req,
struct request *__rq;
 
__rq = cfq_find_rq_fmerge(cfqd, bio);
-   if (__rq && elv_rq_merge_ok(__rq, bio)) {
+   if (__rq && elv_bio_merge_ok(__rq, bio)) {
*req = __rq;
return ELEVATOR_FRONT_MERGE;
}
@@ -2588,8 +2588,8 @@ cfq_merged_requests(struct request_queue *q, struct 
request *rq,
cfq_del_cfqq_rr(cfqd, cfqq);
 }
 
-static int cfq_allow_merge(struct request_queue *q, struct request *rq,
-  struct bio *bio)
+static int cfq_allow_bio_merge(struct request_queue *q, struct request *rq,
+  struct bio *bio)
 {
struct cfq_data *cfqd = q->elevator->elevator_data;
struct cfq_io_cq *cic;
@@ -2613,6 +2613,12 @@ static int cfq_allow_merge(struct request_queue *q, 
struct request *rq,
return cfqq == RQ_CFQQ(rq);
 }
 
+static int cfq_allow_rq_merge(struct request_queue *q, struct request *rq,
+ struct request *next)
+{
+   return RQ_CFQQ(rq) == RQ_CFQQ(next);
+}
+
 static inline void cfq_del_timer(struct cfq_data *cfqd, struct cfq_queue *cfqq)
 {
del_timer(>idle_slice_timer);
@@ -4729,7 +4735,8 @@ static struct elevator_type iosched_cfq = {
.elevator_merge_fn =cfq_merge,
.elevator_merged_fn =   cfq_merged_request,
.elevator_merge_req_fn =cfq_merged_requests,
-   .elevator_allow_merge_fn =  cfq_allow_merge,
+   .elevator_allow_bio_merge_fn =  cfq_allow_bio_merge,
+   .elevator_allow_rq_merge_fn =   cfq_allow_rq_merge,
.elevator_bio_merged_fn =   cfq_bio_merged,
.elevator_dispatch_fn = cfq_dispatch_requests,

[PATCHv2 1/1] thermal: sysfs: lock tz while on access to mode properties

[Eduardo Valentin]

Serialized calls to tz.ops in user facing
sysfs handler mode_show()  and mode_store().

Because several drivers do the following pattern:
.set_mode()
   ...
   local_data->mode = new_mode;
   thermal_zone_device_update(tz);

makes sense to simply do the thermal_zone_device_update()
in thermal core, after setting the new mode.

as .set_mode()  is now called always with tz->lock held.

Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: linux-a...@vger.kernel.org
Cc: "Lee, Chun-Yi" 
Cc: Darren Hart 
Cc: Zhang Rui 
Cc: Keerthy 
Cc: linux-kernel@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/acpi/thermal.c |  1 -
 drivers/platform/x86/acerhdf.c |  1 -
 drivers/thermal/imx_thermal.c  |  1 -
 drivers/thermal/of-thermal.c   |  5 -
 drivers/thermal/thermal_sysfs.c| 14 +++---
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c |  5 -
 6 files changed, 11 insertions(+), 16 deletions(-)

diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 82707f9..03c3460 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -581,7 +581,6 @@ static int thermal_set_mode(struct thermal_zone_device 
*thermal,
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"%s kernel ACPI thermal control\n",
tz->tz_enabled ? "Enable" : "Disable"));
-   acpi_thermal_check(tz);
}
return 0;
 }
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 460fa67..aee33ba 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -405,7 +405,6 @@ static inline void acerhdf_enable_kernelmode(void)
kernelmode = 1;
 
thz_dev->polling_delay = interval*1000;
-   thermal_zone_device_update(thz_dev);
pr_notice("kernel mode fan control ON\n");
 }
 
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index c5547bd..a413eb6 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -246,7 +246,6 @@ static int imx_set_mode(struct thermal_zone_device *tz,
}
 
data->mode = mode;
-   thermal_zone_device_update(tz);
 
return 0;
 }
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index b8e509c..95c47da 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -282,17 +282,12 @@ static int of_thermal_set_mode(struct thermal_zone_device 
*tz,
 {
struct __thermal_zone *data = tz->devdata;
 
-   mutex_lock(>lock);
-
if (mode == THERMAL_DEVICE_ENABLED)
tz->polling_delay = data->polling_delay;
else
tz->polling_delay = 0;
 
-   mutex_unlock(>lock);
-
data->mode = mode;
-   thermal_zone_device_update(tz);
 
return 0;
 }
diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c
index ee983ca..1e223d4 100644
--- a/drivers/thermal/thermal_sysfs.c
+++ b/drivers/thermal/thermal_sysfs.c
@@ -62,7 +62,9 @@ mode_show(struct device *dev, struct device_attribute *attr, 
char *buf)
if (!tz->ops->get_mode)
return -EPERM;
 
+   mutex_lock(>lock);
result = tz->ops->get_mode(tz, );
+   mutex_unlock(>lock);
if (result)
return result;
 
@@ -75,17 +77,23 @@ mode_store(struct device *dev, struct device_attribute 
*attr,
   const char *buf, size_t count)
 {
struct thermal_zone_device *tz = to_thermal_zone(dev);
+   enum thermal_device_mode mode = THERMAL_DEVICE_DISABLED;
int result;
 
if (!tz->ops->set_mode)
return -EPERM;
 
if (!strncmp(buf, "enabled", sizeof("enabled") - 1))
-   result = tz->ops->set_mode(tz, THERMAL_DEVICE_ENABLED);
+   mode = THERMAL_DEVICE_ENABLED;
else if (!strncmp(buf, "disabled", sizeof("disabled") - 1))
-   result = tz->ops->set_mode(tz, THERMAL_DEVICE_DISABLED);
+   mode = THERMAL_DEVICE_DISABLED;
else
-   result = -EINVAL;
+   return -EINVAL;
+
+   mutex_lock(>lock);
+   result = tz->ops->set_mode(tz, mode);
+   mutex_unlock(>lock);
+   thermal_zone_device_update(tz);
 
if (result)
return result;
diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c 
b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index 15c0a9a..5dce053 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -193,19 +193,14 @@ static int ti_thermal_set_mode(struct thermal_zone_device 
*thermal,
return 0;

[PATCHv2 1/1] thermal: sysfs: lock tz while on access to mode properties

[Eduardo Valentin]

Serialized calls to tz.ops in user facing
sysfs handler mode_show()  and mode_store().

Because several drivers do the following pattern:
.set_mode()
   ...
   local_data->mode = new_mode;
   thermal_zone_device_update(tz);

makes sense to simply do the thermal_zone_device_update()
in thermal core, after setting the new mode.

as .set_mode()  is now called always with tz->lock held.

Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: linux-a...@vger.kernel.org
Cc: "Lee, Chun-Yi" 
Cc: Darren Hart 
Cc: Zhang Rui 
Cc: Keerthy 
Cc: linux-kernel@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/acpi/thermal.c |  1 -
 drivers/platform/x86/acerhdf.c |  1 -
 drivers/thermal/imx_thermal.c  |  1 -
 drivers/thermal/of-thermal.c   |  5 -
 drivers/thermal/thermal_sysfs.c| 14 +++---
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c |  5 -
 6 files changed, 11 insertions(+), 16 deletions(-)

diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 82707f9..03c3460 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -581,7 +581,6 @@ static int thermal_set_mode(struct thermal_zone_device 
*thermal,
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"%s kernel ACPI thermal control\n",
tz->tz_enabled ? "Enable" : "Disable"));
-   acpi_thermal_check(tz);
}
return 0;
 }
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 460fa67..aee33ba 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -405,7 +405,6 @@ static inline void acerhdf_enable_kernelmode(void)
kernelmode = 1;
 
thz_dev->polling_delay = interval*1000;
-   thermal_zone_device_update(thz_dev);
pr_notice("kernel mode fan control ON\n");
 }
 
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index c5547bd..a413eb6 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -246,7 +246,6 @@ static int imx_set_mode(struct thermal_zone_device *tz,
}
 
data->mode = mode;
-   thermal_zone_device_update(tz);
 
return 0;
 }
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index b8e509c..95c47da 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -282,17 +282,12 @@ static int of_thermal_set_mode(struct thermal_zone_device 
*tz,
 {
struct __thermal_zone *data = tz->devdata;
 
-   mutex_lock(>lock);
-
if (mode == THERMAL_DEVICE_ENABLED)
tz->polling_delay = data->polling_delay;
else
tz->polling_delay = 0;
 
-   mutex_unlock(>lock);
-
data->mode = mode;
-   thermal_zone_device_update(tz);
 
return 0;
 }
diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c
index ee983ca..1e223d4 100644
--- a/drivers/thermal/thermal_sysfs.c
+++ b/drivers/thermal/thermal_sysfs.c
@@ -62,7 +62,9 @@ mode_show(struct device *dev, struct device_attribute *attr, 
char *buf)
if (!tz->ops->get_mode)
return -EPERM;
 
+   mutex_lock(>lock);
result = tz->ops->get_mode(tz, );
+   mutex_unlock(>lock);
if (result)
return result;
 
@@ -75,17 +77,23 @@ mode_store(struct device *dev, struct device_attribute 
*attr,
   const char *buf, size_t count)
 {
struct thermal_zone_device *tz = to_thermal_zone(dev);
+   enum thermal_device_mode mode = THERMAL_DEVICE_DISABLED;
int result;
 
if (!tz->ops->set_mode)
return -EPERM;
 
if (!strncmp(buf, "enabled", sizeof("enabled") - 1))
-   result = tz->ops->set_mode(tz, THERMAL_DEVICE_ENABLED);
+   mode = THERMAL_DEVICE_ENABLED;
else if (!strncmp(buf, "disabled", sizeof("disabled") - 1))
-   result = tz->ops->set_mode(tz, THERMAL_DEVICE_DISABLED);
+   mode = THERMAL_DEVICE_DISABLED;
else
-   result = -EINVAL;
+   return -EINVAL;
+
+   mutex_lock(>lock);
+   result = tz->ops->set_mode(tz, mode);
+   mutex_unlock(>lock);
+   thermal_zone_device_update(tz);
 
if (result)
return result;
diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c 
b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index 15c0a9a..5dce053 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -193,19 +193,14 @@ static int ti_thermal_set_mode(struct thermal_zone_device 
*thermal,
return 0;
}
 
-   mutex_lock(>ti_thermal->lock);
-
if (mode == THERMAL_DEVICE_ENABLED)

Re: [PATCH v6 3/5] thermal: streamline get_trend callbacks

[Eduardo Valentin]

On Wed, Jun 22, 2016 at 04:42:03PM +0800, Caesar Wang wrote:
> From: Sascha Hauer 
> 
> The .get_trend callback in struct thermal_zone_device_ops has
> the prototype:
> int (*get_trend) (struct thermal_zone_device *, int,
>   enum thermal_trend *);
> whereas the .get_trend callback in struct thermal_zone_of_device_ops
> has:
> int (*get_trend)(void *, long *);
> 
> Streamline both prototypes and add the trip argument to the OF callback
> aswell and use enum thermal_trend * instead of an integer pointer.
> 
> While the OF prototype may be the better one, this should be decided at
> framework level and not on OF level.
> 
> Signed-off-by: Sascha Hauer 
> Signed-off-by: Caesar Wang 
> Cc: Zhang Rui 
> Cc: Eduardo Valentin 
> Cc: linux...@vger.kernel.org
> Reviewed-by: Keerthy 

I had to append the following diff, because I merged a new qsens driver:


diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
index b182272..446f70b 100644
--- a/drivers/thermal/qcom/tsens.c
+++ b/drivers/thermal/qcom/tsens.c
@@ -29,13 +29,13 @@ static int tsens_get_temp(void *data, int *temp)
return tmdev->ops->get_temp(tmdev, s->id, temp);
 }
 
-static int tsens_get_trend(void *data, long *temp)
+static int tsens_get_trend(void *p, int trip, enum thermal_trend *trend)
 {
-   const struct tsens_sensor *s = data;
+   const struct tsens_sensor *s = p;
struct tsens_device *tmdev = s->tmdev;
 
if (tmdev->ops->get_trend)
-   return tmdev->ops->get_trend(tmdev, s->id, temp);
+   return  tmdev->ops->get_trend(tmdev, s->id, trend);
 
return -ENOTSUPP;
 }

> 
> ---
> 
> Changes in v6:
> - as the Keerthy comments on https://patchwork.kernel.org/patch/9157913/,
>   change the get_trend for of_thermal.c.
> 
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/thermal/of-thermal.c   | 16 +-
>  drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 25 
> +++---
>  include/linux/thermal.h|  2 +-
>  3 files changed, 10 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> index 2d2a06f..20822ab 100644
> --- a/drivers/thermal/of-thermal.c
> +++ b/drivers/thermal/of-thermal.c
> @@ -202,25 +202,11 @@ static int of_thermal_get_trend(struct 
> thermal_zone_device *tz, int trip,
>   enum thermal_trend *trend)
>  {
>   struct __thermal_zone *data = tz->devdata;
> - long dev_trend;
> - int r;
>  
>   if (!data->ops->get_trend)
>   return -EINVAL;
>  
> - r = data->ops->get_trend(data->sensor_data, _trend);
> - if (r)
> - return r;
> -
> - /* TODO: These intervals might have some thresholds, but in core code */
> - if (dev_trend > 0)
> - *trend = THERMAL_TREND_RAISING;
> - else if (dev_trend < 0)
> - *trend = THERMAL_TREND_DROPPING;
> - else
> - *trend = THERMAL_TREND_STABLE;
> -
> - return 0;
> + return data->ops->get_trend(data->sensor_data, trip, trend);
>  }
>  
>  static int of_thermal_bind(struct thermal_zone_device *thermal,
> diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c 
> b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> index 15c0a9a..4a6757c 100644
> --- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> +++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> @@ -239,7 +239,7 @@ static int ti_thermal_get_trip_temp(struct 
> thermal_zone_device *thermal,
>   return 0;
>  }
>  
> -static int __ti_thermal_get_trend(void *p, long *trend)
> +static int __ti_thermal_get_trend(void *p, int trip, enum thermal_trend 
> *trend)
>  {
>   struct ti_thermal_data *data = p;
>   struct ti_bandgap *bgp;
> @@ -252,22 +252,6 @@ static int __ti_thermal_get_trend(void *p, long *trend)
>   if (ret)
>   return ret;
>  
> - *trend = tr;
> -
> - return 0;
> -}
> -
> -/* Get the temperature trend callback functions for thermal zone */
> -static int ti_thermal_get_trend(struct thermal_zone_device *thermal,
> - int trip, enum thermal_trend *trend)
> -{
> - int ret;
> - long tr;
> -
> - ret = __ti_thermal_get_trend(thermal->devdata, );
> - if (ret)
> - return ret;
> -
>   if (tr > 0)
>   *trend = THERMAL_TREND_RAISING;
>   else if (tr < 0)
> @@ -278,6 +262,13 @@ static int ti_thermal_get_trend(struct 
> thermal_zone_device *thermal,
>   return 0;
>  }
>  
> +/* Get the temperature trend callback functions for thermal zone */
> +static int ti_thermal_get_trend(struct thermal_zone_device *thermal,
> + int trip, enum thermal_trend *trend)
> +{
> 

Re: [PATCH v6 3/5] thermal: streamline get_trend callbacks

[Eduardo Valentin]

On Wed, Jun 22, 2016 at 04:42:03PM +0800, Caesar Wang wrote:
> From: Sascha Hauer 
> 
> The .get_trend callback in struct thermal_zone_device_ops has
> the prototype:
> int (*get_trend) (struct thermal_zone_device *, int,
>   enum thermal_trend *);
> whereas the .get_trend callback in struct thermal_zone_of_device_ops
> has:
> int (*get_trend)(void *, long *);
> 
> Streamline both prototypes and add the trip argument to the OF callback
> aswell and use enum thermal_trend * instead of an integer pointer.
> 
> While the OF prototype may be the better one, this should be decided at
> framework level and not on OF level.
> 
> Signed-off-by: Sascha Hauer 
> Signed-off-by: Caesar Wang 
> Cc: Zhang Rui 
> Cc: Eduardo Valentin 
> Cc: linux...@vger.kernel.org
> Reviewed-by: Keerthy 

I had to append the following diff, because I merged a new qsens driver:


diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
index b182272..446f70b 100644
--- a/drivers/thermal/qcom/tsens.c
+++ b/drivers/thermal/qcom/tsens.c
@@ -29,13 +29,13 @@ static int tsens_get_temp(void *data, int *temp)
return tmdev->ops->get_temp(tmdev, s->id, temp);
 }
 
-static int tsens_get_trend(void *data, long *temp)
+static int tsens_get_trend(void *p, int trip, enum thermal_trend *trend)
 {
-   const struct tsens_sensor *s = data;
+   const struct tsens_sensor *s = p;
struct tsens_device *tmdev = s->tmdev;
 
if (tmdev->ops->get_trend)
-   return tmdev->ops->get_trend(tmdev, s->id, temp);
+   return  tmdev->ops->get_trend(tmdev, s->id, trend);
 
return -ENOTSUPP;
 }

> 
> ---
> 
> Changes in v6:
> - as the Keerthy comments on https://patchwork.kernel.org/patch/9157913/,
>   change the get_trend for of_thermal.c.
> 
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/thermal/of-thermal.c   | 16 +-
>  drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 25 
> +++---
>  include/linux/thermal.h|  2 +-
>  3 files changed, 10 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> index 2d2a06f..20822ab 100644
> --- a/drivers/thermal/of-thermal.c
> +++ b/drivers/thermal/of-thermal.c
> @@ -202,25 +202,11 @@ static int of_thermal_get_trend(struct 
> thermal_zone_device *tz, int trip,
>   enum thermal_trend *trend)
>  {
>   struct __thermal_zone *data = tz->devdata;
> - long dev_trend;
> - int r;
>  
>   if (!data->ops->get_trend)
>   return -EINVAL;
>  
> - r = data->ops->get_trend(data->sensor_data, _trend);
> - if (r)
> - return r;
> -
> - /* TODO: These intervals might have some thresholds, but in core code */
> - if (dev_trend > 0)
> - *trend = THERMAL_TREND_RAISING;
> - else if (dev_trend < 0)
> - *trend = THERMAL_TREND_DROPPING;
> - else
> - *trend = THERMAL_TREND_STABLE;
> -
> - return 0;
> + return data->ops->get_trend(data->sensor_data, trip, trend);
>  }
>  
>  static int of_thermal_bind(struct thermal_zone_device *thermal,
> diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c 
> b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> index 15c0a9a..4a6757c 100644
> --- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> +++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
> @@ -239,7 +239,7 @@ static int ti_thermal_get_trip_temp(struct 
> thermal_zone_device *thermal,
>   return 0;
>  }
>  
> -static int __ti_thermal_get_trend(void *p, long *trend)
> +static int __ti_thermal_get_trend(void *p, int trip, enum thermal_trend 
> *trend)
>  {
>   struct ti_thermal_data *data = p;
>   struct ti_bandgap *bgp;
> @@ -252,22 +252,6 @@ static int __ti_thermal_get_trend(void *p, long *trend)
>   if (ret)
>   return ret;
>  
> - *trend = tr;
> -
> - return 0;
> -}
> -
> -/* Get the temperature trend callback functions for thermal zone */
> -static int ti_thermal_get_trend(struct thermal_zone_device *thermal,
> - int trip, enum thermal_trend *trend)
> -{
> - int ret;
> - long tr;
> -
> - ret = __ti_thermal_get_trend(thermal->devdata, );
> - if (ret)
> - return ret;
> -
>   if (tr > 0)
>   *trend = THERMAL_TREND_RAISING;
>   else if (tr < 0)
> @@ -278,6 +262,13 @@ static int ti_thermal_get_trend(struct 
> thermal_zone_device *thermal,
>   return 0;
>  }
>  
> +/* Get the temperature trend callback functions for thermal zone */
> +static int ti_thermal_get_trend(struct thermal_zone_device *thermal,
> + int trip, enum thermal_trend *trend)
> +{
> + return __ti_thermal_get_trend(thermal->devdata, trip, trend);
> +}
> +
>  /* Get critical temperature callback functions 

Re: [PATCH v4 1/2] Documentation: bindings: add dt doc for Rockchip PCIe controller

[Brian Norris]

Hi,

On Fri, Jul 01, 2016 at 02:01:09PM +0100, Marc Zyngier wrote:
> On 01/07/16 02:24, Shawn Lin wrote:
> > This patch adds a binding that describes the Rockchip PCIe controller
> > found on Rockchip SoCs PCIe interface.
> > 
> > Signed-off-by: Shawn Lin 
> > 
> > ---
> > 
> > Changes in v4:
> > - fix example of adding intermediate interrupt controller for pcie
> >   legacy interrrupt
> > 
> > Changes in v3:
> > - fix example dts code suggested by Rob and Marc
> > - remove driver's behaviour of regulator
> > 
> > Changes in v2:
> > - fix lots clk/reset stuff suggested by Heiko
> > - remove msi-parent and add msi-map suggested by Marc
> > - drop phy related stuff
> > - some others minor fixes
> > 
> >  .../devicetree/bindings/pci/rockchip-pcie.txt  | 91 
> > ++
> >  1 file changed, 91 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt 
> > b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> > new file mode 100644
> > index 000..8092fc5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> > @@ -0,0 +1,91 @@
> > +* Rockchip AXI PCIe Root Port Bridge DT description
> > +
> > +Required properties:
> > +- #address-cells: Address representation for root ports, set to <3>
> > +- #size-cells: Size representation for root ports, set to <2>
> > +- #interrupt-cells: specifies the number of cells needed to encode an
> > +   interrupt source. The value must be 1.

I think this propoerty should be in a separate section, since it's going
under a sub-node (not the main node). Right?

> > +- compatible: Should contain "rockchip,rk3399-pcie"
> > +- reg: Two register ranges as listed in the reg-names property
> > +- reg-names: Must include the following names
> > +   - "axi-base"
> > +   - "apb-base"
> > +- 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:
> > +   - "aclk"
> > +   - "aclk-perf"
> > +   - "hclk"
> > +   - "pm"
> > +- msi-map: Maps a Requester ID to an MSI controller and associated.
> > +   See ./pci-msi.txt
> > +- phys: From PHY bindings: Phandle for the Generic PHY for PCIe.
> > +- phy-names:  MUST be "pcie-phy".
> > +- interrupts: Three interrupt entries must be specified.
> > +- interrupt-names: Must include the following names
> > +   - "sys"
> > +   - "legacy"
> > +   - "client"
> > +- resets: Must contain five entries for each entry in reset-names.
> > +  See ../reset/reset.txt for details.
> > +- reset-names: Must include the following names
> > +   - "core"
> > +   - "mgmt"
> > +   - "mgmt-sticky"
> > +   - "pipe"
> > +- pinctrl-names : The pin control state names
> > +- pinctrl-0: The "default" pinctrl state
> > +- interrupt-map-mask and interrupt-map: standard PCI properties
> > +- interrupt-controller: identifies the node as an interrupt controller

Same with this property.

> > +
> > +Optional Property:
> > +- ep-gpios: contain the entry for pre-reset gpio
> > +- num-lanes: number of lanes to use
> > +- vpcie3v3-supply: The phandle to the 3.3v regulator to use for pcie.
> > +- vpcie1v8-supply: The phandle to the 1.8v regulator to use for pcie.
> > +- vpcie0v9-supply: The phandle to the 0.9v regulator to use for pcie.

e.g., you might start a new section here describing how this controller
acts as an intermediate IRQ controller, and that the
interrupt-controller-related properties should be placed under a subnode.
(Did you also need an interrupt-parent property? I'm a little fuzzy on
the details myself, actually...)

> > +
> > +Example:
> > +
> > +pcie0: pcie@f800 {
> > +   compatible = "rockchip,rk3399-pcie";
> > +   #address-cells = <3>;
> > +   #size-cells = <2>;
> > +   clocks = < ACLK_PCIE>, < ACLK_PERF_PCIE>,
> > +< PCLK_PCIE>, < SCLK_PCIE_PM>;
> > +   clock-names = "aclk", "aclk-perf",
> > + "hclk", "pm";
> > +   bus-range = <0x0 0x1>;
> > +   interrupts = ,  > IRQ_TYPE_LEVEL_HIGH>,
> > +;
> > +   interrupt-names = "sys", "legacy", "client";
> > +   assigned-clocks = < SCLK_PCIEPHY_REF>;
> > +   assigned-clock-parents = < SCLK_PCIEPHY_REF100M>;
> > +   assigned-clock-rates = <1>;
> > +   ep-gpios = < 13 GPIO_ACTIVE_HIGH>;
> > +   ranges = <0x8300 0x0 0xfa00 0x0 0xfa00 0x0 0x60
> > + 0x8100 0x0 0xfa60 0x0 0xfa60 0x0 0x10>;
> > +   num-lanes = <4>;
> > +   msi-map = <0x0  0x0 0x1000>;
> > +   reg = < 0x0 0xf800 0x0 0x200 >, < 0x0 0xfd00 0x0 0x100 
> > >;
> > +   reg-names = "axi-base", "apb-base";
> > +   resets = < SRST_PCIE_CORE>, < SRST_PCIE_MGMT>,
> > +< SRST_PCIE_MGMT_STICKY>, < SRST_PCIE_PIPE>;
> > +   reset-names = "core", "mgmt", "mgmt-sticky", "pipe";
> > +   phys = <_phy>;
> > +   phy-names = 

Re: [PATCH v4 1/2] Documentation: bindings: add dt doc for Rockchip PCIe controller

[Brian Norris]

Hi,

On Fri, Jul 01, 2016 at 02:01:09PM +0100, Marc Zyngier wrote:
> On 01/07/16 02:24, Shawn Lin wrote:
> > This patch adds a binding that describes the Rockchip PCIe controller
> > found on Rockchip SoCs PCIe interface.
> > 
> > Signed-off-by: Shawn Lin 
> > 
> > ---
> > 
> > Changes in v4:
> > - fix example of adding intermediate interrupt controller for pcie
> >   legacy interrrupt
> > 
> > Changes in v3:
> > - fix example dts code suggested by Rob and Marc
> > - remove driver's behaviour of regulator
> > 
> > Changes in v2:
> > - fix lots clk/reset stuff suggested by Heiko
> > - remove msi-parent and add msi-map suggested by Marc
> > - drop phy related stuff
> > - some others minor fixes
> > 
> >  .../devicetree/bindings/pci/rockchip-pcie.txt  | 91 
> > ++
> >  1 file changed, 91 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt 
> > b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> > new file mode 100644
> > index 000..8092fc5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> > @@ -0,0 +1,91 @@
> > +* Rockchip AXI PCIe Root Port Bridge DT description
> > +
> > +Required properties:
> > +- #address-cells: Address representation for root ports, set to <3>
> > +- #size-cells: Size representation for root ports, set to <2>
> > +- #interrupt-cells: specifies the number of cells needed to encode an
> > +   interrupt source. The value must be 1.

I think this propoerty should be in a separate section, since it's going
under a sub-node (not the main node). Right?

> > +- compatible: Should contain "rockchip,rk3399-pcie"
> > +- reg: Two register ranges as listed in the reg-names property
> > +- reg-names: Must include the following names
> > +   - "axi-base"
> > +   - "apb-base"
> > +- 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:
> > +   - "aclk"
> > +   - "aclk-perf"
> > +   - "hclk"
> > +   - "pm"
> > +- msi-map: Maps a Requester ID to an MSI controller and associated.
> > +   See ./pci-msi.txt
> > +- phys: From PHY bindings: Phandle for the Generic PHY for PCIe.
> > +- phy-names:  MUST be "pcie-phy".
> > +- interrupts: Three interrupt entries must be specified.
> > +- interrupt-names: Must include the following names
> > +   - "sys"
> > +   - "legacy"
> > +   - "client"
> > +- resets: Must contain five entries for each entry in reset-names.
> > +  See ../reset/reset.txt for details.
> > +- reset-names: Must include the following names
> > +   - "core"
> > +   - "mgmt"
> > +   - "mgmt-sticky"
> > +   - "pipe"
> > +- pinctrl-names : The pin control state names
> > +- pinctrl-0: The "default" pinctrl state
> > +- interrupt-map-mask and interrupt-map: standard PCI properties
> > +- interrupt-controller: identifies the node as an interrupt controller

Same with this property.

> > +
> > +Optional Property:
> > +- ep-gpios: contain the entry for pre-reset gpio
> > +- num-lanes: number of lanes to use
> > +- vpcie3v3-supply: The phandle to the 3.3v regulator to use for pcie.
> > +- vpcie1v8-supply: The phandle to the 1.8v regulator to use for pcie.
> > +- vpcie0v9-supply: The phandle to the 0.9v regulator to use for pcie.

e.g., you might start a new section here describing how this controller
acts as an intermediate IRQ controller, and that the
interrupt-controller-related properties should be placed under a subnode.
(Did you also need an interrupt-parent property? I'm a little fuzzy on
the details myself, actually...)

> > +
> > +Example:
> > +
> > +pcie0: pcie@f800 {
> > +   compatible = "rockchip,rk3399-pcie";
> > +   #address-cells = <3>;
> > +   #size-cells = <2>;
> > +   clocks = < ACLK_PCIE>, < ACLK_PERF_PCIE>,
> > +< PCLK_PCIE>, < SCLK_PCIE_PM>;
> > +   clock-names = "aclk", "aclk-perf",
> > + "hclk", "pm";
> > +   bus-range = <0x0 0x1>;
> > +   interrupts = ,  > IRQ_TYPE_LEVEL_HIGH>,
> > +;
> > +   interrupt-names = "sys", "legacy", "client";
> > +   assigned-clocks = < SCLK_PCIEPHY_REF>;
> > +   assigned-clock-parents = < SCLK_PCIEPHY_REF100M>;
> > +   assigned-clock-rates = <1>;
> > +   ep-gpios = < 13 GPIO_ACTIVE_HIGH>;
> > +   ranges = <0x8300 0x0 0xfa00 0x0 0xfa00 0x0 0x60
> > + 0x8100 0x0 0xfa60 0x0 0xfa60 0x0 0x10>;
> > +   num-lanes = <4>;
> > +   msi-map = <0x0  0x0 0x1000>;
> > +   reg = < 0x0 0xf800 0x0 0x200 >, < 0x0 0xfd00 0x0 0x100 
> > >;
> > +   reg-names = "axi-base", "apb-base";
> > +   resets = < SRST_PCIE_CORE>, < SRST_PCIE_MGMT>,
> > +< SRST_PCIE_MGMT_STICKY>, < SRST_PCIE_PIPE>;
> > +   reset-names = "core", "mgmt", "mgmt-sticky", "pipe";
> > +   phys = <_phy>;
> > +   phy-names = "pcie-phy";
> > +   

Re: [PATCH 1/4] spi: Add option to wake a device by toggling CS

[Andrey Pronin]

On Fri, Jul 01, 2016 at 07:17:08PM +0200, Mark Brown wrote:
> On Fri, Jul 01, 2016 at 10:05:50AM -0700, Doug Anderson wrote:
> 
> > I'm curious why you you need a timer at all.  Can't you just keep
> > track of the jiffies that you last sent and do subtraction?  ...or you
> > could get even more accurate and use a ktime_t.  That avoids a whole
> > lot of synchronization / locking issues too...
> 
> Yeah, that'd be a lot better.
> 
> > Also: presumably you'll need to make sure that there's some margin in
> > this whole thing.  I'd imagine that if the timeout is 1
> > nanoseconds and you do the calculation and you last sent 
> > nanoseconds ago then you might decide that the other side isn't asleep
> > yet.  ...but by the time the transfer starts it might be asleep...
> 
> Indeed.

Lots of godd points in the feedback. Let me re-visit the whole idea.
And may be I'll move it to a more device-specific driver.

Re: [PATCH 1/4] spi: Add option to wake a device by toggling CS

[Andrey Pronin]

On Fri, Jul 01, 2016 at 07:17:08PM +0200, Mark Brown wrote:
> On Fri, Jul 01, 2016 at 10:05:50AM -0700, Doug Anderson wrote:
> 
> > I'm curious why you you need a timer at all.  Can't you just keep
> > track of the jiffies that you last sent and do subtraction?  ...or you
> > could get even more accurate and use a ktime_t.  That avoids a whole
> > lot of synchronization / locking issues too...
> 
> Yeah, that'd be a lot better.
> 
> > Also: presumably you'll need to make sure that there's some margin in
> > this whole thing.  I'd imagine that if the timeout is 1
> > nanoseconds and you do the calculation and you last sent 
> > nanoseconds ago then you might decide that the other side isn't asleep
> > yet.  ...but by the time the transfer starts it might be asleep...
> 
> Indeed.

Lots of godd points in the feedback. Let me re-visit the whole idea.
And may be I'll move it to a more device-specific driver.

[PATCH 1/1] thermal: core: move slop and offset helpers to thermal_helpers.c

[Eduardo Valentin]

Reorganize code to reflect better placement.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/thermal_core.c| 30 --
 drivers/thermal/thermal_helpers.c | 30 ++
 2 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 84857bdf..792aab7 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1350,36 +1350,6 @@ exit:
 }
 EXPORT_SYMBOL_GPL(thermal_zone_get_zone_by_name);
 
-/**
- * thermal_zone_get_slope - return the slope attribute of the thermal zone
- * @tz: thermal zone device with the slope attribute
- *
- * Return: If the thermal zone device has a slope attribute, return it, else
- * return 1.
- */
-int thermal_zone_get_slope(struct thermal_zone_device *tz)
-{
-   if (tz && tz->tzp)
-   return tz->tzp->slope;
-   return 1;
-}
-EXPORT_SYMBOL_GPL(thermal_zone_get_slope);
-
-/**
- * thermal_zone_get_offset - return the offset attribute of the thermal zone
- * @tz: thermal zone device with the offset attribute
- *
- * Return: If the thermal zone device has a offset attribute, return it, else
- * return 0.
- */
-int thermal_zone_get_offset(struct thermal_zone_device *tz)
-{
-   if (tz && tz->tzp)
-   return tz->tzp->offset;
-   return 0;
-}
-EXPORT_SYMBOL_GPL(thermal_zone_get_offset);
-
 #ifdef CONFIG_NET
 static const struct genl_multicast_group thermal_event_mcgrps[] = {
{ .name = THERMAL_GENL_MCAST_GROUP_NAME, },
diff --git a/drivers/thermal/thermal_helpers.c 
b/drivers/thermal/thermal_helpers.c
index 5e1c160..2d37d9d 100644
--- a/drivers/thermal/thermal_helpers.c
+++ b/drivers/thermal/thermal_helpers.c
@@ -142,3 +142,33 @@ void thermal_cdev_update(struct thermal_cooling_device 
*cdev)
dev_dbg(>device, "set to state %lu\n", target);
 }
 EXPORT_SYMBOL(thermal_cdev_update);
+
+/**
+ * thermal_zone_get_slope - return the slope attribute of the thermal zone
+ * @tz: thermal zone device with the slope attribute
+ *
+ * Return: If the thermal zone device has a slope attribute, return it, else
+ * return 1.
+ */
+int thermal_zone_get_slope(struct thermal_zone_device *tz)
+{
+   if (tz && tz->tzp)
+   return tz->tzp->slope;
+   return 1;
+}
+EXPORT_SYMBOL_GPL(thermal_zone_get_slope);
+
+/**
+ * thermal_zone_get_offset - return the offset attribute of the thermal zone
+ * @tz: thermal zone device with the offset attribute
+ *
+ * Return: If the thermal zone device has a offset attribute, return it, else
+ * return 0.
+ */
+int thermal_zone_get_offset(struct thermal_zone_device *tz)
+{
+   if (tz && tz->tzp)
+   return tz->tzp->offset;
+   return 0;
+}
+EXPORT_SYMBOL_GPL(thermal_zone_get_offset);
-- 
2.1.4

[PATCH 1/1] thermal: core: move slop and offset helpers to thermal_helpers.c

[Eduardo Valentin]

Reorganize code to reflect better placement.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/thermal_core.c| 30 --
 drivers/thermal/thermal_helpers.c | 30 ++
 2 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 84857bdf..792aab7 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1350,36 +1350,6 @@ exit:
 }
 EXPORT_SYMBOL_GPL(thermal_zone_get_zone_by_name);
 
-/**
- * thermal_zone_get_slope - return the slope attribute of the thermal zone
- * @tz: thermal zone device with the slope attribute
- *
- * Return: If the thermal zone device has a slope attribute, return it, else
- * return 1.
- */
-int thermal_zone_get_slope(struct thermal_zone_device *tz)
-{
-   if (tz && tz->tzp)
-   return tz->tzp->slope;
-   return 1;
-}
-EXPORT_SYMBOL_GPL(thermal_zone_get_slope);
-
-/**
- * thermal_zone_get_offset - return the offset attribute of the thermal zone
- * @tz: thermal zone device with the offset attribute
- *
- * Return: If the thermal zone device has a offset attribute, return it, else
- * return 0.
- */
-int thermal_zone_get_offset(struct thermal_zone_device *tz)
-{
-   if (tz && tz->tzp)
-   return tz->tzp->offset;
-   return 0;
-}
-EXPORT_SYMBOL_GPL(thermal_zone_get_offset);
-
 #ifdef CONFIG_NET
 static const struct genl_multicast_group thermal_event_mcgrps[] = {
{ .name = THERMAL_GENL_MCAST_GROUP_NAME, },
diff --git a/drivers/thermal/thermal_helpers.c 
b/drivers/thermal/thermal_helpers.c
index 5e1c160..2d37d9d 100644
--- a/drivers/thermal/thermal_helpers.c
+++ b/drivers/thermal/thermal_helpers.c
@@ -142,3 +142,33 @@ void thermal_cdev_update(struct thermal_cooling_device 
*cdev)
dev_dbg(>device, "set to state %lu\n", target);
 }
 EXPORT_SYMBOL(thermal_cdev_update);
+
+/**
+ * thermal_zone_get_slope - return the slope attribute of the thermal zone
+ * @tz: thermal zone device with the slope attribute
+ *
+ * Return: If the thermal zone device has a slope attribute, return it, else
+ * return 1.
+ */
+int thermal_zone_get_slope(struct thermal_zone_device *tz)
+{
+   if (tz && tz->tzp)
+   return tz->tzp->slope;
+   return 1;
+}
+EXPORT_SYMBOL_GPL(thermal_zone_get_slope);
+
+/**
+ * thermal_zone_get_offset - return the offset attribute of the thermal zone
+ * @tz: thermal zone device with the offset attribute
+ *
+ * Return: If the thermal zone device has a offset attribute, return it, else
+ * return 0.
+ */
+int thermal_zone_get_offset(struct thermal_zone_device *tz)
+{
+   if (tz && tz->tzp)
+   return tz->tzp->offset;
+   return 0;
+}
+EXPORT_SYMBOL_GPL(thermal_zone_get_offset);
-- 
2.1.4

Re: [PATCH 1/4] spi: Add option to wake a device by toggling CS

[Andrey Pronin]

On Fri, Jul 01, 2016 at 09:02:30AM +0100, Mark Brown wrote:
> On Wed, Jun 29, 2016 at 08:54:24PM -0700, apro...@chromium.org wrote:
> > From: Andrey Pronin 
> > 
> > Some SPI devices may go to sleep after a period of inactivity
> > on SPI. For such devices, if enough time has passed since the
> > last SPI transaction, toggle CS and wait for the device to
> > start before communicating with it.
> 
> This seems incredibly specialist, I can imagine someone might implement
> something like this but it really feels like something I'd expect the
> driver for the device to be doing rather than the core.  Is it really a
> bounce that's needed and not something like putting a small delay after
> asserting chip select?

Yes, I agree it's quite device-specific, though, I guess, more than a
single device can benefit from that. I'm playing with it now to see if
I can indeed move it to a more device-specific driver from generic spi.

It is indeed a bounce and a rather long delay to let the device actually
wake from a long sleep, go through internal startup, test, etc.

Re: [PATCH 1/4] spi: Add option to wake a device by toggling CS

[Andrey Pronin]

On Fri, Jul 01, 2016 at 09:02:30AM +0100, Mark Brown wrote:
> On Wed, Jun 29, 2016 at 08:54:24PM -0700, apro...@chromium.org wrote:
> > From: Andrey Pronin 
> > 
> > Some SPI devices may go to sleep after a period of inactivity
> > on SPI. For such devices, if enough time has passed since the
> > last SPI transaction, toggle CS and wait for the device to
> > start before communicating with it.
> 
> This seems incredibly specialist, I can imagine someone might implement
> something like this but it really feels like something I'd expect the
> driver for the device to be doing rather than the core.  Is it really a
> bounce that's needed and not something like putting a small delay after
> asserting chip select?

Yes, I agree it's quite device-specific, though, I guess, more than a
single device can benefit from that. I'm playing with it now to see if
I can indeed move it to a more device-specific driver from generic spi.

It is indeed a bounce and a rather long delay to let the device actually
wake from a long sleep, go through internal startup, test, etc.

Re: [PATCH v5 1/5] thermal: Add support for hardware-tracked trip points

[Eduardo Valentin]

On Wed, Jun 22, 2016 at 11:15:19AM +0800, Zhang Rui wrote:
> On 一, 2016-06-06 at 19:44 +0800, Caesar Wang wrote:
> > From: Sascha Hauer 
> > 
> > This adds support for hardware-tracked trip points to the device tree
> > thermal sensor framework.
> > 
> > The framework supports an arbitrary number of trip points. Whenever
> > the current temperature is updated, the trip points immediately
> > below and above the current temperature are found. A .set_trips
> > callback is then called with the temperatures. If there is no trip
> > point above or below the current temperature, the passed trip
> > temperature will be -INT_MAX or INT_MAX respectively. In this
> > callback,
> > the driver should program the hardware such that it is notified
> > when either of these trip points are triggered. When a trip point
> > is triggered, the driver should call `thermal_zone_device_update'
> > for the respective thermal zone. This will cause the trip points
> > to be updated again.
> > 
> > If .set_trips is not implemented, the framework behaves as before.
> > 
> > This patch is based on an earlier version from Mikko Perttunen
> > 
> > 
> > Signed-off-by: Sascha Hauer 
> > Signed-off-by: Caesar Wang 
> > Cc: Zhang Rui 
> > Cc: Eduardo Valentin 
> > Cc: linux...@vger.kernel.org
> > 
> > ---
> > 
> > Changes in v5:
> > - add the lock for thermal_zone_set_trips function.
> > - change based on next kernel.
> > 
> > Changes in v4:
> > - Missing the lock added in v3.
> > 
> > Changes in v3:
> > - as Javi comments on https://patchwork.kernel.org/patch/9001281/.
> > - add the lock for preventing the called from multi placce
> > - add the note for pre_low/high_trip.
> > 
> > Changes in v2:
> > - update the sysfs-api.txt for set_trips.
> > 
> >  Documentation/thermal/sysfs-api.txt |  7 +
> >  drivers/thermal/thermal_core.c  | 54
> > +
> >  drivers/thermal/thermal_sysfs.c |  3 +++
> >  include/linux/thermal.h | 10 +++
> >  4 files changed, 74 insertions(+)
> > 
> > diff --git a/Documentation/thermal/sysfs-api.txt
> > b/Documentation/thermal/sysfs-api.txt
> > index efc3f3d..75d8838 100644
> > --- a/Documentation/thermal/sysfs-api.txt
> > +++ b/Documentation/thermal/sysfs-api.txt
> > @@ -49,6 +49,9 @@ temperature) and throttle appropriate devices.
> >     .bind: bind the thermal zone device with a thermal cooling
> > device.
> >     .unbind: unbind the thermal zone device with a thermal
> > cooling device.
> >     .get_temp: get the current temperature of the thermal zone.
> > +   .set_trips: set the trip points window. Whenever the current
> > temperature
> > +   is updated, the trip points immediately below
> > and above the
> > +   current temperature are found.
> >     .get_mode: get the current mode (enabled/disabled) of the
> > thermal zone.
> >     - "enabled" means the kernel thermal management is
> > enabled.
> >     - "disabled" will prevent kernel thermal driver action
> > upon trip points
> > @@ -95,6 +98,10 @@ temperature) and throttle appropriate devices.
> >     get_temp:   a pointer to a function
> > that reads the
> >     sensor temperature. This is
> > mandatory
> >     callback provided by sensor
> > driver.
> > +   set_trips:  a pointer to a function that
> > sets a
> > +   temperature window. When
> > this window is
> > +   left the driver must inform
> > the thermal
> > +   core via
> > thermal_zone_device_update.
> >     get_trend:  a pointer to a function
> > that reads the
> >     sensor temperature trend.
> >     set_emul_temp:  a pointer to a
> > function that sets
> > diff --git a/drivers/thermal/thermal_core.c
> > b/drivers/thermal/thermal_core.c
> > index 792aab7..e69aee2 100644
> > --- a/drivers/thermal/thermal_core.c
> > +++ b/drivers/thermal/thermal_core.c
> > @@ -368,6 +368,56 @@ static void handle_thermal_trip(struct
> > thermal_zone_device *tz, int trip)
> >     monitor_thermal_zone(tz);
> >  }
> >  
> > +void thermal_zone_set_trips(struct thermal_zone_device *tz)
> > +{
> > +   int low = -INT_MAX;
> > +   int high = INT_MAX;
> > +   int trip_temp, hysteresis;
> > +   int i, ret;
> > +
> > +   mutex_lock(>lock);
> > +
> > +   if (!tz->ops->set_trips)
> > +   goto exit;
> > +
>   if (!tz->ops->get_trip_hyst)
>   goto exit;
> 
> otherwise, the patch looks good to me.

Agreed here, you need to check if get_trip_hyst is present before
calling it. Not all drivers have it.

Besides, I would prefer you to lock after the checks:

if (!tz->ops->set_trips)
return;

Re: [PATCH v5 1/5] thermal: Add support for hardware-tracked trip points

[Eduardo Valentin]

On Wed, Jun 22, 2016 at 11:15:19AM +0800, Zhang Rui wrote:
> On 一, 2016-06-06 at 19:44 +0800, Caesar Wang wrote:
> > From: Sascha Hauer 
> > 
> > This adds support for hardware-tracked trip points to the device tree
> > thermal sensor framework.
> > 
> > The framework supports an arbitrary number of trip points. Whenever
> > the current temperature is updated, the trip points immediately
> > below and above the current temperature are found. A .set_trips
> > callback is then called with the temperatures. If there is no trip
> > point above or below the current temperature, the passed trip
> > temperature will be -INT_MAX or INT_MAX respectively. In this
> > callback,
> > the driver should program the hardware such that it is notified
> > when either of these trip points are triggered. When a trip point
> > is triggered, the driver should call `thermal_zone_device_update'
> > for the respective thermal zone. This will cause the trip points
> > to be updated again.
> > 
> > If .set_trips is not implemented, the framework behaves as before.
> > 
> > This patch is based on an earlier version from Mikko Perttunen
> > 
> > 
> > Signed-off-by: Sascha Hauer 
> > Signed-off-by: Caesar Wang 
> > Cc: Zhang Rui 
> > Cc: Eduardo Valentin 
> > Cc: linux...@vger.kernel.org
> > 
> > ---
> > 
> > Changes in v5:
> > - add the lock for thermal_zone_set_trips function.
> > - change based on next kernel.
> > 
> > Changes in v4:
> > - Missing the lock added in v3.
> > 
> > Changes in v3:
> > - as Javi comments on https://patchwork.kernel.org/patch/9001281/.
> > - add the lock for preventing the called from multi placce
> > - add the note for pre_low/high_trip.
> > 
> > Changes in v2:
> > - update the sysfs-api.txt for set_trips.
> > 
> >  Documentation/thermal/sysfs-api.txt |  7 +
> >  drivers/thermal/thermal_core.c  | 54
> > +
> >  drivers/thermal/thermal_sysfs.c |  3 +++
> >  include/linux/thermal.h | 10 +++
> >  4 files changed, 74 insertions(+)
> > 
> > diff --git a/Documentation/thermal/sysfs-api.txt
> > b/Documentation/thermal/sysfs-api.txt
> > index efc3f3d..75d8838 100644
> > --- a/Documentation/thermal/sysfs-api.txt
> > +++ b/Documentation/thermal/sysfs-api.txt
> > @@ -49,6 +49,9 @@ temperature) and throttle appropriate devices.
> >     .bind: bind the thermal zone device with a thermal cooling
> > device.
> >     .unbind: unbind the thermal zone device with a thermal
> > cooling device.
> >     .get_temp: get the current temperature of the thermal zone.
> > +   .set_trips: set the trip points window. Whenever the current
> > temperature
> > +   is updated, the trip points immediately below
> > and above the
> > +   current temperature are found.
> >     .get_mode: get the current mode (enabled/disabled) of the
> > thermal zone.
> >     - "enabled" means the kernel thermal management is
> > enabled.
> >     - "disabled" will prevent kernel thermal driver action
> > upon trip points
> > @@ -95,6 +98,10 @@ temperature) and throttle appropriate devices.
> >     get_temp:   a pointer to a function
> > that reads the
> >     sensor temperature. This is
> > mandatory
> >     callback provided by sensor
> > driver.
> > +   set_trips:  a pointer to a function that
> > sets a
> > +   temperature window. When
> > this window is
> > +   left the driver must inform
> > the thermal
> > +   core via
> > thermal_zone_device_update.
> >     get_trend:  a pointer to a function
> > that reads the
> >     sensor temperature trend.
> >     set_emul_temp:  a pointer to a
> > function that sets
> > diff --git a/drivers/thermal/thermal_core.c
> > b/drivers/thermal/thermal_core.c
> > index 792aab7..e69aee2 100644
> > --- a/drivers/thermal/thermal_core.c
> > +++ b/drivers/thermal/thermal_core.c
> > @@ -368,6 +368,56 @@ static void handle_thermal_trip(struct
> > thermal_zone_device *tz, int trip)
> >     monitor_thermal_zone(tz);
> >  }
> >  
> > +void thermal_zone_set_trips(struct thermal_zone_device *tz)
> > +{
> > +   int low = -INT_MAX;
> > +   int high = INT_MAX;
> > +   int trip_temp, hysteresis;
> > +   int i, ret;
> > +
> > +   mutex_lock(>lock);
> > +
> > +   if (!tz->ops->set_trips)
> > +   goto exit;
> > +
>   if (!tz->ops->get_trip_hyst)
>   goto exit;
> 
> otherwise, the patch looks good to me.

Agreed here, you need to check if get_trip_hyst is present before
calling it. Not all drivers have it.

Besides, I would prefer you to lock after the checks:

if (!tz->ops->set_trips)
return;

if (!tz->ops->get_trip_hyst)
return;

mutex_lock(>lock);

> 
> thanks,
> rui
> > +   for (i = 0; i < tz->trips; 

Re: [PATCH v2] arm64: dts: rockchip: add the power domain node for rk3399

[Caesar Wang]

On 2016年07月02日 00:56, Doug Anderson wrote:

Caesar

On Thu, Jun 30, 2016 at 9:32 PM, Caesar Wang  wrote:

From: Elaine Zhang 

In order to meet low power requirements, a power management unit (PMU) is
designed for controlling power resources in RK3399. The RK3399 PMU is
dedicated for managing the power of the whole chip.

1. add pd node for RK3399 Soc
2. create power domain tree
3. add qos node for domain

 From the DT/binds and driver can get more detail information:
The driver:
 drivers/soc/rockchip/pm_domains.c
The document:
 Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
---

Changes in v2:
- As Doug/Heiko commnets on https://patchwork.kernel.org/patch/9206415/.
   drop the debugfs-dump and Add the comments for alphabetical order.

Note: As the TRM lists many voltage domains and power domains, then
in actual we just need control some domains for driver.
Due to some domains (e.g. emmc, usb, core)...We can't turn off it on
bootup.

I'm curious: why can't you turn off USB power domains if a board
doesn't usb USB?  ...or GMAC on boards that don't use Ethernet?  ...or
eDP on boards that don't use EDP?

Maybe the driver for these things isn't ready to handle power domains
yet so that's why they are left out for now?

It seems like GMAC could at least be added because we don't even have
the GMAC listed in the current device tree so therefore there can't be
any users of it.  When it's added we can make sure that the power
domains are added.


At least, the gmac had been supported in rockchip inside.
That's seem the gmac driver can't handle the power domain enough.
--

Frankly, I'm no test the GMAC，then this patch should support most of 
devices.
We can send another patch to support it if someone（usb/gmac) can handle 
the power domain.




I think in the current upstream dtsi file there is also no xhci node,
so does that mean you could add the USB3 power domain?




willam@RK, what's think of it？


Signed-off-by: Elaine Zhang 
Signed-off-by: Caesar Wang 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: Heiko Stuebner 

---
  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 179 +++
  1 file changed, 179 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index a6dd623..103e185 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -45,6 +45,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 

  / {
@@ -594,6 +595,184 @@
 status = "disabled";
 };

+   qos_hdcp: qos_hdcp@ffa9 {
+   compatible = "syscon";
+   reg = <0x0 0xffa9 0x0 0x20>;
+   };
+
+   qos_iep: qos_iep@ffa98000 {
+   compatible = "syscon";
+   reg = <0x0 0xffa98000 0x0 0x20>;
+   };
+
+   qos_isp0_m0: qos_isp0_m0@ffaa {
+   compatible = "syscon";
+   reg = <0x0 0xffaa 0x0 0x20>;
+   };
+
+   qos_isp0_m1: qos_isp0_m1@ffaa0080 {
+   compatible = "syscon";
+   reg = <0x0 0xffaa0080 0x0 0x20>;
+   };
+
+   qos_isp1_m0: qos_isp1_m0@ffaa8000 {
+   compatible = "syscon";
+   reg = <0x0 0xffaa8000 0x0 0x20>;
+   };
+
+   qos_isp1_m1: qos_isp1_m1@ffaa8080 {
+   compatible = "syscon";
+   reg = <0x0 0xffaa8080 0x0 0x20>;
+   };
+
+   qos_rga_r: qos_rga_r@ffab {
+   compatible = "syscon";
+   reg = <0x0 0xffab 0x0 0x20>;
+   };
+
+   qos_rga_w: qos_rga_w@ffab0080 {
+   compatible = "syscon";
+   reg = <0x0 0xffab0080 0x0 0x20>;
+   };
+
+   qos_video_m0: qos_video_m0@ffab8000 {
+   compatible = "syscon";
+   reg = <0x0 0xffab8000 0x0 0x20>;
+   };
+
+   qos_video_m1_r: qos_video_m1_r@ffac {
+   compatible = "syscon";
+   reg = <0x0 0xffac 0x0 0x20>;
+   };
+
+   qos_video_m1_w: qos_video_m1_w@ffac0080 {
+   compatible = "syscon";
+   reg = <0x0 0xffac0080 0x0 0x20>;
+   };
+
+   qos_vop_big_r: qos_vop_big_r@ffac8000 {
+   compatible = "syscon";
+   reg = <0x0 0xffac8000 0x0 0x20>;
+   };
+
+   qos_vop_big_w: qos_vop_big_w@ffac8080 {
+   compatible = "syscon";
+   reg = <0x0 0xffac8080 0x0 0x20>;
+   };
+
+   qos_vop_little: qos_vop_little@ffad {
+   compatible = "syscon";
+   reg = <0x0 0xffad 0x0 0x20>;
+   };
+
+   qos_gpu: qos_gpu@ffae {
+   compatible = "syscon";
+   reg = <0x0 0xffae 0x0 0x20>;
+   };
+
+   pmu: power-management@ff31 {
+   compatible = "rockchip,rk3399-pmu", 

Re: [PATCH v2] arm64: dts: rockchip: add the power domain node for rk3399

[Caesar Wang]

On 2016年07月02日 00:56, Doug Anderson wrote:

Caesar

On Thu, Jun 30, 2016 at 9:32 PM, Caesar Wang  wrote:

From: Elaine Zhang 

In order to meet low power requirements, a power management unit (PMU) is
designed for controlling power resources in RK3399. The RK3399 PMU is
dedicated for managing the power of the whole chip.

1. add pd node for RK3399 Soc
2. create power domain tree
3. add qos node for domain

 From the DT/binds and driver can get more detail information:
The driver:
 drivers/soc/rockchip/pm_domains.c
The document:
 Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
---

Changes in v2:
- As Doug/Heiko commnets on https://patchwork.kernel.org/patch/9206415/.
   drop the debugfs-dump and Add the comments for alphabetical order.

Note: As the TRM lists many voltage domains and power domains, then
in actual we just need control some domains for driver.
Due to some domains (e.g. emmc, usb, core)...We can't turn off it on
bootup.

I'm curious: why can't you turn off USB power domains if a board
doesn't usb USB?  ...or GMAC on boards that don't use Ethernet?  ...or
eDP on boards that don't use EDP?

Maybe the driver for these things isn't ready to handle power domains
yet so that's why they are left out for now?

It seems like GMAC could at least be added because we don't even have
the GMAC listed in the current device tree so therefore there can't be
any users of it.  When it's added we can make sure that the power
domains are added.


At least, the gmac had been supported in rockchip inside.
That's seem the gmac driver can't handle the power domain enough.
--

Frankly, I'm no test the GMAC，then this patch should support most of 
devices.
We can send another patch to support it if someone（usb/gmac) can handle 
the power domain.




I think in the current upstream dtsi file there is also no xhci node,
so does that mean you could add the USB3 power domain?




willam@RK, what's think of it？


Signed-off-by: Elaine Zhang 
Signed-off-by: Caesar Wang 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: Heiko Stuebner 

---
  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 179 +++
  1 file changed, 179 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index a6dd623..103e185 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -45,6 +45,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 

  / {
@@ -594,6 +595,184 @@
 status = "disabled";
 };

+   qos_hdcp: qos_hdcp@ffa9 {
+   compatible = "syscon";
+   reg = <0x0 0xffa9 0x0 0x20>;
+   };
+
+   qos_iep: qos_iep@ffa98000 {
+   compatible = "syscon";
+   reg = <0x0 0xffa98000 0x0 0x20>;
+   };
+
+   qos_isp0_m0: qos_isp0_m0@ffaa {
+   compatible = "syscon";
+   reg = <0x0 0xffaa 0x0 0x20>;
+   };
+
+   qos_isp0_m1: qos_isp0_m1@ffaa0080 {
+   compatible = "syscon";
+   reg = <0x0 0xffaa0080 0x0 0x20>;
+   };
+
+   qos_isp1_m0: qos_isp1_m0@ffaa8000 {
+   compatible = "syscon";
+   reg = <0x0 0xffaa8000 0x0 0x20>;
+   };
+
+   qos_isp1_m1: qos_isp1_m1@ffaa8080 {
+   compatible = "syscon";
+   reg = <0x0 0xffaa8080 0x0 0x20>;
+   };
+
+   qos_rga_r: qos_rga_r@ffab {
+   compatible = "syscon";
+   reg = <0x0 0xffab 0x0 0x20>;
+   };
+
+   qos_rga_w: qos_rga_w@ffab0080 {
+   compatible = "syscon";
+   reg = <0x0 0xffab0080 0x0 0x20>;
+   };
+
+   qos_video_m0: qos_video_m0@ffab8000 {
+   compatible = "syscon";
+   reg = <0x0 0xffab8000 0x0 0x20>;
+   };
+
+   qos_video_m1_r: qos_video_m1_r@ffac {
+   compatible = "syscon";
+   reg = <0x0 0xffac 0x0 0x20>;
+   };
+
+   qos_video_m1_w: qos_video_m1_w@ffac0080 {
+   compatible = "syscon";
+   reg = <0x0 0xffac0080 0x0 0x20>;
+   };
+
+   qos_vop_big_r: qos_vop_big_r@ffac8000 {
+   compatible = "syscon";
+   reg = <0x0 0xffac8000 0x0 0x20>;
+   };
+
+   qos_vop_big_w: qos_vop_big_w@ffac8080 {
+   compatible = "syscon";
+   reg = <0x0 0xffac8080 0x0 0x20>;
+   };
+
+   qos_vop_little: qos_vop_little@ffad {
+   compatible = "syscon";
+   reg = <0x0 0xffad 0x0 0x20>;
+   };
+
+   qos_gpu: qos_gpu@ffae {
+   compatible = "syscon";
+   reg = <0x0 0xffae 0x0 0x20>;
+   };
+
+   pmu: power-management@ff31 {
+   compatible = "rockchip,rk3399-pmu", "syscon", "simple-mfd";
+   reg = <0x0 0xff31 0x0 0x1000>;
+
+   /*
+   

Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer.

[Thiago Jung Bauermann]

Am Freitag, 01 Juli 2016, 17:02:23 schrieb Thiago Jung Bauermann:
> Am Freitag, 01 Juli 2016, 14:36:02 schrieb Dave Young:
> > On 07/01/16 at 02:51pm, Thiago Jung Bauermann wrote:
> > > Am Donnerstag, 30 Juni 2016, 17:43:57 schrieb Dave Young:
> > > > On 06/30/16 at 01:42pm, Thiago Jung Bauermann wrote:
> > > > > Am Donnerstag, 30 Juni 2016, 12:49:44 schrieb Thiago Jung Bauermann:
> > > I understand that this is all somewhat subjective, so if you still
> > > disagree with my points I can provide a patch set implementing the
> > > change above.
> > 
> > I still feel it should be changed if more callbacks being introduced,
> > though you can regard it is internal api, like above comment we do not
> > need to assign them seperately, the member values can be assigned
> > from the beginning.
> 
> Ok, I'll implement the changes and submit a v4. Thanks for your review.

Sorry for creating more email traffic, but it'll be better if I ask this 
before I change all other places in the code. Is the code below what you
have in mind?

In particular, this version doesn't do the memset(, 0, sizeof(buf))
that the previous code I sent earlier did. Is that ok?

@@ -643,13 +632,14 @@ static int __kexec_load_purgatory(struct kimage *image, 
unsigned long min,
  unsigned long max, int top_down)
 {
struct purgatory_info *pi = >purgatory_info;
-   unsigned long align, buf_align, bss_align, buf_sz, bss_sz, bss_pad;
-   unsigned long memsz, entry, load_addr, curr_load_addr, bss_addr, offset;
+   unsigned long align, bss_align, bss_sz, bss_pad;
+   unsigned long entry, load_addr, curr_load_addr, bss_addr, offset;
unsigned char *buf_addr, *src;
int i, ret = 0, entry_sidx = -1;
const Elf_Shdr *sechdrs_c;
Elf_Shdr *sechdrs = NULL;
-   void *purgatory_buf = NULL;
+   struct kexec_buf buf = { .image = image, .buf_min = min,
+   .buf_max = max, .top_down = top_down };
 
/*
 * sechdrs_c points to section headers in purgatory and are read
@@ -715,9 +705,9 @@ static int __kexec_load_purgatory(struct kimage *image, 
unsigned long min,
}
 
/* Determine how much memory is needed to load relocatable object. */
-   buf_align = 1;
+   buf.buf_align = 1;
bss_align = 1;
-   buf_sz = 0;
+   buf.bufsz = 0;
bss_sz = 0;
 
for (i = 0; i < pi->ehdr->e_shnum; i++) {
@@ -726,10 +716,10 @@ static int __kexec_load_purgatory(struct kimage *image, 
unsigned long min,
 
align = sechdrs[i].sh_addralign;
if (sechdrs[i].sh_type != SHT_NOBITS) {
-   if (buf_align < align)
-   buf_align = align;
-   buf_sz = ALIGN(buf_sz, align);
-   buf_sz += sechdrs[i].sh_size;
+   if (buf.buf_align < align)
+   buf.buf_align = align;
+   buf.bufsz = ALIGN(buf.bufsz, align);
+   buf.bufsz += sechdrs[i].sh_size;
} else {
/* bss section */
if (bss_align < align)
@@ -741,32 +731,31 @@ static int __kexec_load_purgatory(struct kimage *image, 
unsigned long min,
 
/* Determine the bss padding required to align bss properly */
bss_pad = 0;
-   if (buf_sz & (bss_align - 1))
-   bss_pad = bss_align - (buf_sz & (bss_align - 1));
+   if (buf.bufsz & (bss_align - 1))
+   bss_pad = bss_align - (buf.bufsz & (bss_align - 1));
 
-   memsz = buf_sz + bss_pad + bss_sz;
+   buf.memsz = buf.bufsz + bss_pad + bss_sz;
 
/* Allocate buffer for purgatory */
-   purgatory_buf = vzalloc(buf_sz);
-   if (!purgatory_buf) {
+   buf.buffer = vzalloc(buf.bufsz);
+   if (!buf.buffer) {
ret = -ENOMEM;
goto out;
}
 
-   if (buf_align < bss_align)
-   buf_align = bss_align;
+   if (buf.buf_align < bss_align)
+   buf.buf_align = bss_align;
 
/* Add buffer to segment list */
-   ret = kexec_add_buffer(image, purgatory_buf, buf_sz, memsz,
-   buf_align, min, max, top_down,
-   >purgatory_load_addr);
+   ret = kexec_add_buffer();
if (ret)
goto out;
+   pi->purgatory_load_addr = buf.mem;
 
/* Load SHF_ALLOC sections */
-   buf_addr = purgatory_buf;
+   buf_addr = buf.buffer;
load_addr = curr_load_addr = pi->purgatory_load_addr;
-   bss_addr = load_addr + buf_sz + bss_pad;
+   bss_addr = load_addr + buf.bufsz + bss_pad;
 
for (i = 0; i < pi->ehdr->e_shnum; i++) {
if (!(sechdrs[i].sh_flags & SHF_ALLOC))
@@ -812,11 +801,11 @@ static int __kexec_load_purgatory(struct kimage *image, 
unsigned long min,
 * Used later to identify which section is purgatory 

Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer.

[Thiago Jung Bauermann]

Am Freitag, 01 Juli 2016, 17:02:23 schrieb Thiago Jung Bauermann:
> Am Freitag, 01 Juli 2016, 14:36:02 schrieb Dave Young:
> > On 07/01/16 at 02:51pm, Thiago Jung Bauermann wrote:
> > > Am Donnerstag, 30 Juni 2016, 17:43:57 schrieb Dave Young:
> > > > On 06/30/16 at 01:42pm, Thiago Jung Bauermann wrote:
> > > > > Am Donnerstag, 30 Juni 2016, 12:49:44 schrieb Thiago Jung Bauermann:
> > > I understand that this is all somewhat subjective, so if you still
> > > disagree with my points I can provide a patch set implementing the
> > > change above.
> > 
> > I still feel it should be changed if more callbacks being introduced,
> > though you can regard it is internal api, like above comment we do not
> > need to assign them seperately, the member values can be assigned
> > from the beginning.
> 
> Ok, I'll implement the changes and submit a v4. Thanks for your review.

Sorry for creating more email traffic, but it'll be better if I ask this 
before I change all other places in the code. Is the code below what you
have in mind?

In particular, this version doesn't do the memset(, 0, sizeof(buf))
that the previous code I sent earlier did. Is that ok?

@@ -643,13 +632,14 @@ static int __kexec_load_purgatory(struct kimage *image, 
unsigned long min,
  unsigned long max, int top_down)
 {
struct purgatory_info *pi = >purgatory_info;
-   unsigned long align, buf_align, bss_align, buf_sz, bss_sz, bss_pad;
-   unsigned long memsz, entry, load_addr, curr_load_addr, bss_addr, offset;
+   unsigned long align, bss_align, bss_sz, bss_pad;
+   unsigned long entry, load_addr, curr_load_addr, bss_addr, offset;
unsigned char *buf_addr, *src;
int i, ret = 0, entry_sidx = -1;
const Elf_Shdr *sechdrs_c;
Elf_Shdr *sechdrs = NULL;
-   void *purgatory_buf = NULL;
+   struct kexec_buf buf = { .image = image, .buf_min = min,
+   .buf_max = max, .top_down = top_down };
 
/*
 * sechdrs_c points to section headers in purgatory and are read
@@ -715,9 +705,9 @@ static int __kexec_load_purgatory(struct kimage *image, 
unsigned long min,
}
 
/* Determine how much memory is needed to load relocatable object. */
-   buf_align = 1;
+   buf.buf_align = 1;
bss_align = 1;
-   buf_sz = 0;
+   buf.bufsz = 0;
bss_sz = 0;
 
for (i = 0; i < pi->ehdr->e_shnum; i++) {
@@ -726,10 +716,10 @@ static int __kexec_load_purgatory(struct kimage *image, 
unsigned long min,
 
align = sechdrs[i].sh_addralign;
if (sechdrs[i].sh_type != SHT_NOBITS) {
-   if (buf_align < align)
-   buf_align = align;
-   buf_sz = ALIGN(buf_sz, align);
-   buf_sz += sechdrs[i].sh_size;
+   if (buf.buf_align < align)
+   buf.buf_align = align;
+   buf.bufsz = ALIGN(buf.bufsz, align);
+   buf.bufsz += sechdrs[i].sh_size;
} else {
/* bss section */
if (bss_align < align)
@@ -741,32 +731,31 @@ static int __kexec_load_purgatory(struct kimage *image, 
unsigned long min,
 
/* Determine the bss padding required to align bss properly */
bss_pad = 0;
-   if (buf_sz & (bss_align - 1))
-   bss_pad = bss_align - (buf_sz & (bss_align - 1));
+   if (buf.bufsz & (bss_align - 1))
+   bss_pad = bss_align - (buf.bufsz & (bss_align - 1));
 
-   memsz = buf_sz + bss_pad + bss_sz;
+   buf.memsz = buf.bufsz + bss_pad + bss_sz;
 
/* Allocate buffer for purgatory */
-   purgatory_buf = vzalloc(buf_sz);
-   if (!purgatory_buf) {
+   buf.buffer = vzalloc(buf.bufsz);
+   if (!buf.buffer) {
ret = -ENOMEM;
goto out;
}
 
-   if (buf_align < bss_align)
-   buf_align = bss_align;
+   if (buf.buf_align < bss_align)
+   buf.buf_align = bss_align;
 
/* Add buffer to segment list */
-   ret = kexec_add_buffer(image, purgatory_buf, buf_sz, memsz,
-   buf_align, min, max, top_down,
-   >purgatory_load_addr);
+   ret = kexec_add_buffer();
if (ret)
goto out;
+   pi->purgatory_load_addr = buf.mem;
 
/* Load SHF_ALLOC sections */
-   buf_addr = purgatory_buf;
+   buf_addr = buf.buffer;
load_addr = curr_load_addr = pi->purgatory_load_addr;
-   bss_addr = load_addr + buf_sz + bss_pad;
+   bss_addr = load_addr + buf.bufsz + bss_pad;
 
for (i = 0; i < pi->ehdr->e_shnum; i++) {
if (!(sechdrs[i].sh_flags & SHF_ALLOC))
@@ -812,11 +801,11 @@ static int __kexec_load_purgatory(struct kimage *image, 
unsigned long min,
 * Used later to identify which section is purgatory 

Re: [PATCH v9 01/10] clk: fix initial state of critical clock's parents

[Stephen Boyd]

(Resending to everyone)

On 06/22, Erin Lo wrote:
> From: James Liao 
> 
> This patch fixed wrong state of parent clocks if they are registered
> after critical clocks.
> 
> Signed-off-by: James Liao 
> Signed-off-by: Erin Lo 

It would be nice if you included the information about the
problem from James' previous mail. This says what it does, but
doesn't explain what the problem is and how it is fixing it.

> ---
>  drivers/clk/clk.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index d584004..e9f5f89 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2388,8 +2388,15 @@ static int __clk_core_init(struct clk_core *core)
>   hlist_for_each_entry_safe(orphan, tmp2, _orphan_list, child_node) {
>   struct clk_core *parent = __clk_init_parent(orphan);
>  
> - if (parent)
> + if (parent) {
>   clk_core_reparent(orphan, parent);
> +
> + if (orphan->prepare_count)
> + clk_core_prepare(parent);
> +
> + if (orphan->enable_count)
> + clk_core_enable(parent);
> + }
>   }

I'm pretty sure I pointed this problem out to Mike when the
critical clk patches were being pushed. I can't recall what the
plan was though to fix the problem. I'm pretty sure he said that
clk_core_reparent() would take care of it, but obviously it is
not doing that. Or perhaps it was that clk handoff should figure
out that the parents of a critical clk are also on and thus keep
them on.

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

Re: [PATCH v9 01/10] clk: fix initial state of critical clock's parents

[Stephen Boyd]

(Resending to everyone)

On 06/22, Erin Lo wrote:
> From: James Liao 
> 
> This patch fixed wrong state of parent clocks if they are registered
> after critical clocks.
> 
> Signed-off-by: James Liao 
> Signed-off-by: Erin Lo 

It would be nice if you included the information about the
problem from James' previous mail. This says what it does, but
doesn't explain what the problem is and how it is fixing it.

> ---
>  drivers/clk/clk.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index d584004..e9f5f89 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2388,8 +2388,15 @@ static int __clk_core_init(struct clk_core *core)
>   hlist_for_each_entry_safe(orphan, tmp2, _orphan_list, child_node) {
>   struct clk_core *parent = __clk_init_parent(orphan);
>  
> - if (parent)
> + if (parent) {
>   clk_core_reparent(orphan, parent);
> +
> + if (orphan->prepare_count)
> + clk_core_prepare(parent);
> +
> + if (orphan->enable_count)
> + clk_core_enable(parent);
> + }
>   }

I'm pretty sure I pointed this problem out to Mike when the
critical clk patches were being pushed. I can't recall what the
plan was though to fix the problem. I'm pretty sure he said that
clk_core_reparent() would take care of it, but obviously it is
not doing that. Or perhaps it was that clk handoff should figure
out that the parents of a critical clk are also on and thus keep
them on.

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

Re: [Nouveau] [PATCH 2/6] drm/nouveau/core: make use of new strtolower() function

[Alexandre Courbot]

On Fri, Jul 1, 2016 at 8:50 AM, Markus Mayer <mma...@broadcom.com> wrote:
> Call strtolower() rather than walking the string explicitly to convert
> it to lowercase.
>
> Signed-off-by: Markus Mayer <mma...@broadcom.com>
> ---
>  drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c 
> b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
> index 34ecd4a..c50594c 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
> @@ -36,16 +36,11 @@ nvkm_firmware_get(struct nvkm_device *device, const char 
> *fwname,
>  {
> char f[64];
> char cname[16];
> -   int i;
>
> /* Convert device name to lowercase */
> strncpy(cname, device->chip->name, sizeof(cname));
> cname[sizeof(cname) - 1] = '\0';
> -   i = strlen(cname);
> -   while (i) {
> -   --i;
> -   cname[i] = tolower(cname[i]);
> -   }
> +   strtolower(cname);

This function doesn't seem to exist as of next-20160701, where have
you found it?

Re: [Nouveau] [PATCH 2/6] drm/nouveau/core: make use of new strtolower() function

[Alexandre Courbot]

On Fri, Jul 1, 2016 at 8:50 AM, Markus Mayer  wrote:
> Call strtolower() rather than walking the string explicitly to convert
> it to lowercase.
>
> Signed-off-by: Markus Mayer 
> ---
>  drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c 
> b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
> index 34ecd4a..c50594c 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
> @@ -36,16 +36,11 @@ nvkm_firmware_get(struct nvkm_device *device, const char 
> *fwname,
>  {
> char f[64];
> char cname[16];
> -   int i;
>
> /* Convert device name to lowercase */
> strncpy(cname, device->chip->name, sizeof(cname));
> cname[sizeof(cname) - 1] = '\0';
> -   i = strlen(cname);
> -   while (i) {
> -   --i;
> -   cname[i] = tolower(cname[i]);
> -   }
> +   strtolower(cname);

This function doesn't seem to exist as of next-20160701, where have
you found it?

Re: [PATCH RFC 0/7] support clk setting during kernel early boot

[Stephen Boyd]

On 06/29, Dong Aisheng wrote:
> Recently several people met the kernel complaining
> "bad: scheduling from the idle thread!" issue which caused by
> sleeping during kernel early booting phase by calling clk
> APIs like clk_prepare_enable.
> 
> See:
> https://lkml.org/lkml/fancy/2016/1/29/695
> https://lkml.org/lkml/2016/6/10/779
> http://www.spinics.net/lists/linux-clk/msg08635.html

That last one was another bug that happened to trigger this
problem mistakenly. I doubt critical clks are an issue (more
below).

> 
> The calling sequence simply could be like:
> start_kernel
>   ->time_init
> ->of_clk_init
>   ->clk_core_prepare
> ->clk_pllv3_prepare
>   ->usleep_range
> ->dequeue_task_idle
> 
> This issue is mainly caused during time_init, the irq is still
> not enabled and scheduler is still not ready, thus there's no way
> to allow sleep at that time.
> 
> However, there're many exist platforms calling clk_prepare_enable/
> clk_get_rate/clk_set_parent at that time in CLK_OF_DECLARE init
> function.
> e.g
> drivers/clk/imx/clk-{soc}.c
> drivers/clk/rockchip/clk-rk3188.c
> drivers/clk/ti/clk-44xx.c
> ...
> 
> And irqchip and clock source is also initialized before it which
> may requires to do clk settings.
> 
> Furthermore, current clk framework also supports critical clocks
> flagged by CLK_IS_CRITICAL which will be prepared and
> enabled during clk_register by clk core, that is also happened
> quite early in of_clk_init usually.
> 
> And clk framework also supports assign default clk rate and parent for
> each registered clk provider which also happens early in of_clk_init.
> (see of_clk_set_defaults())
> 
> Above are all possible cases which may cause sleeping during kernel
> early booting.

How many of these cases are really happening and causing problems
though?

> 
> So it seems we'd like to have the requirement to make kernel support
> calling clk APIs during kernel early boot without sleep.

I wonder if the problem is more that the framework doesn't know
the hardware state of on/off when it initializes? So we call the
clk_ops prepare/enable functions when we really shouldn't be
doing that at all because the clk is already prepared/enabled.
Presumably for critical clks, we shouldn't go and touch any
hardware to turn them on, because by definition they're critical
and should already be on anyway.

> 
> Since many of them is actually mostly implemented unsleepable already,
> e.g. recalc_rate, recalc_accuracy, get/set_phase
> but due to the definition allows them sleep, we may still have to add
> xxx_hw and xxx_done for them.
> Not sure if any better idea to avoid adding so many new callbacks.
> 
> 5) The most important issue may be callbacks (round_rate and determine_rate)
> which may recursively call its parent.
> For this case, we may not be able to convert it to xx_hw type.
> e.g. drivers/clk/clk-divider.c
> .round_rate
> -> clk_divider_round_rate
>-> clk_hw_round_rate(clk_hw_get_parent(hw), rate) if CLK_SET_RATE_PARENT
> 
> clk_hw_round_rate is sleepable in theory.
> Thus we may not convert .round_rate to .round_rate_hw since we can't
> predict whether it's parent round_rate is sleepable or not.
> 
> This issue may cause us unable to convert the common clk-divider and clk-mux
> which could be a potential issue since clk_set_rate will indirectly call
> .round_rate and .determinte_rate which may results in possible sleep.
> 
> Any good ideas for this issue?
> 
> 6) Not sure your guys's option on calling clk_prepare which acqures a mutex
> when irq is disalbed.
> Ideally we probably may should not call mutex_lock with irq disabled.
> But seems we may can't avoid and during booting, it seems still safe to
> call it.
> 

It seems fine to call mutex lock during of_clk_init(). At least
from what I can tell we're saved here because there's only one
task during of_clk_init() time so we're not able to be blocked by
any other task and fall into the mutex slowpath.

The problem seems to be entering the scheduler directly from
usleep_range() called from clk ops because that effectively
becomes a scheduler call. Given that of_clk_init() is mostly for
clk drivers to register clks for their timers and interrupt
controllers, we should be able to avoid making any clk_ops calls
besides recalculating rates and checking if clks are enabled or
not. All other clks should be registered and configured from
device drivers later on when the scheduler is running.

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

Re: [PATCH RFC 0/7] support clk setting during kernel early boot

[Stephen Boyd]

On 06/29, Dong Aisheng wrote:
> Recently several people met the kernel complaining
> "bad: scheduling from the idle thread!" issue which caused by
> sleeping during kernel early booting phase by calling clk
> APIs like clk_prepare_enable.
> 
> See:
> https://lkml.org/lkml/fancy/2016/1/29/695
> https://lkml.org/lkml/2016/6/10/779
> http://www.spinics.net/lists/linux-clk/msg08635.html

That last one was another bug that happened to trigger this
problem mistakenly. I doubt critical clks are an issue (more
below).

> 
> The calling sequence simply could be like:
> start_kernel
>   ->time_init
> ->of_clk_init
>   ->clk_core_prepare
> ->clk_pllv3_prepare
>   ->usleep_range
> ->dequeue_task_idle
> 
> This issue is mainly caused during time_init, the irq is still
> not enabled and scheduler is still not ready, thus there's no way
> to allow sleep at that time.
> 
> However, there're many exist platforms calling clk_prepare_enable/
> clk_get_rate/clk_set_parent at that time in CLK_OF_DECLARE init
> function.
> e.g
> drivers/clk/imx/clk-{soc}.c
> drivers/clk/rockchip/clk-rk3188.c
> drivers/clk/ti/clk-44xx.c
> ...
> 
> And irqchip and clock source is also initialized before it which
> may requires to do clk settings.
> 
> Furthermore, current clk framework also supports critical clocks
> flagged by CLK_IS_CRITICAL which will be prepared and
> enabled during clk_register by clk core, that is also happened
> quite early in of_clk_init usually.
> 
> And clk framework also supports assign default clk rate and parent for
> each registered clk provider which also happens early in of_clk_init.
> (see of_clk_set_defaults())
> 
> Above are all possible cases which may cause sleeping during kernel
> early booting.

How many of these cases are really happening and causing problems
though?

> 
> So it seems we'd like to have the requirement to make kernel support
> calling clk APIs during kernel early boot without sleep.

I wonder if the problem is more that the framework doesn't know
the hardware state of on/off when it initializes? So we call the
clk_ops prepare/enable functions when we really shouldn't be
doing that at all because the clk is already prepared/enabled.
Presumably for critical clks, we shouldn't go and touch any
hardware to turn them on, because by definition they're critical
and should already be on anyway.

> 
> Since many of them is actually mostly implemented unsleepable already,
> e.g. recalc_rate, recalc_accuracy, get/set_phase
> but due to the definition allows them sleep, we may still have to add
> xxx_hw and xxx_done for them.
> Not sure if any better idea to avoid adding so many new callbacks.
> 
> 5) The most important issue may be callbacks (round_rate and determine_rate)
> which may recursively call its parent.
> For this case, we may not be able to convert it to xx_hw type.
> e.g. drivers/clk/clk-divider.c
> .round_rate
> -> clk_divider_round_rate
>-> clk_hw_round_rate(clk_hw_get_parent(hw), rate) if CLK_SET_RATE_PARENT
> 
> clk_hw_round_rate is sleepable in theory.
> Thus we may not convert .round_rate to .round_rate_hw since we can't
> predict whether it's parent round_rate is sleepable or not.
> 
> This issue may cause us unable to convert the common clk-divider and clk-mux
> which could be a potential issue since clk_set_rate will indirectly call
> .round_rate and .determinte_rate which may results in possible sleep.
> 
> Any good ideas for this issue?
> 
> 6) Not sure your guys's option on calling clk_prepare which acqures a mutex
> when irq is disalbed.
> Ideally we probably may should not call mutex_lock with irq disabled.
> But seems we may can't avoid and during booting, it seems still safe to
> call it.
> 

It seems fine to call mutex lock during of_clk_init(). At least
from what I can tell we're saved here because there's only one
task during of_clk_init() time so we're not able to be blocked by
any other task and fall into the mutex slowpath.

The problem seems to be entering the scheduler directly from
usleep_range() called from clk ops because that effectively
becomes a scheduler call. Given that of_clk_init() is mostly for
clk drivers to register clks for their timers and interrupt
controllers, we should be able to avoid making any clk_ops calls
besides recalculating rates and checking if clks are enabled or
not. All other clks should be registered and configured from
device drivers later on when the scheduler is running.

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

[PATCH 1/1] thermal: qcom: remove declare local symbols as static

[Eduardo Valentin]

Trivial: remove the following:
drivers/thermal/qcom/tsens-8916.c:103:24: warning: symbol 'ops_8916' was not 
declared. Should it be static?
drivers/thermal/qcom/tsens-8996.c:76:24: warning: symbol 'ops_8996' was not 
declared. Should it be static?
drivers/thermal/qcom/tsens-8974.c:235:24: warning: symbol 'ops_8974' was not 
declared. Should it be static?
drivers/thermal/qcom/tsens-8960.c:279:24: warning: symbol 'ops_8960' was not 
declared. Should it be static?

Cc: Zhang Rui 
Cc: Rajendra Nayak 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/qcom/tsens-8916.c | 2 +-
 drivers/thermal/qcom/tsens-8960.c | 2 +-
 drivers/thermal/qcom/tsens-8974.c | 2 +-
 drivers/thermal/qcom/tsens-8996.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/qcom/tsens-8916.c 
b/drivers/thermal/qcom/tsens-8916.c
index beb3afa..fdf561b 100644
--- a/drivers/thermal/qcom/tsens-8916.c
+++ b/drivers/thermal/qcom/tsens-8916.c
@@ -100,7 +100,7 @@ static int calibrate_8916(struct tsens_device *tmdev)
return 0;
 }
 
-const struct tsens_ops ops_8916 = {
+static const struct tsens_ops ops_8916 = {
.init   = init_common,
.calibrate  = calibrate_8916,
.get_temp   = get_temp_common,
diff --git a/drivers/thermal/qcom/tsens-8960.c 
b/drivers/thermal/qcom/tsens-8960.c
index 1d60916..0451277 100644
--- a/drivers/thermal/qcom/tsens-8960.c
+++ b/drivers/thermal/qcom/tsens-8960.c
@@ -276,7 +276,7 @@ static int get_temp_8960(struct tsens_device *tmdev, int 
id, int *temp)
return -ETIMEDOUT;
 }
 
-const struct tsens_ops ops_8960 = {
+static const struct tsens_ops ops_8960 = {
.init   = init_8960,
.calibrate  = calibrate_8960,
.get_temp   = get_temp_8960,
diff --git a/drivers/thermal/qcom/tsens-8974.c 
b/drivers/thermal/qcom/tsens-8974.c
index da3ca4c..9baf77e 100644
--- a/drivers/thermal/qcom/tsens-8974.c
+++ b/drivers/thermal/qcom/tsens-8974.c
@@ -232,7 +232,7 @@ static int calibrate_8974(struct tsens_device *tmdev)
return 0;
 }
 
-const struct tsens_ops ops_8974 = {
+static const struct tsens_ops ops_8974 = {
.init   = init_common,
.calibrate  = calibrate_8974,
.get_temp   = get_temp_common,
diff --git a/drivers/thermal/qcom/tsens-8996.c 
b/drivers/thermal/qcom/tsens-8996.c
index e2e1274..e1f7781 100644
--- a/drivers/thermal/qcom/tsens-8996.c
+++ b/drivers/thermal/qcom/tsens-8996.c
@@ -73,7 +73,7 @@ done:
return 0;
 }
 
-const struct tsens_ops ops_8996 = {
+static const struct tsens_ops ops_8996 = {
.init   = init_common,
.get_temp   = get_temp_8996,
 };
-- 
2.1.4

[PATCH 1/1] thermal: qcom: remove declare local symbols as static

[Eduardo Valentin]

Trivial: remove the following:
drivers/thermal/qcom/tsens-8916.c:103:24: warning: symbol 'ops_8916' was not 
declared. Should it be static?
drivers/thermal/qcom/tsens-8996.c:76:24: warning: symbol 'ops_8996' was not 
declared. Should it be static?
drivers/thermal/qcom/tsens-8974.c:235:24: warning: symbol 'ops_8974' was not 
declared. Should it be static?
drivers/thermal/qcom/tsens-8960.c:279:24: warning: symbol 'ops_8960' was not 
declared. Should it be static?

Cc: Zhang Rui 
Cc: Rajendra Nayak 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/qcom/tsens-8916.c | 2 +-
 drivers/thermal/qcom/tsens-8960.c | 2 +-
 drivers/thermal/qcom/tsens-8974.c | 2 +-
 drivers/thermal/qcom/tsens-8996.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/qcom/tsens-8916.c 
b/drivers/thermal/qcom/tsens-8916.c
index beb3afa..fdf561b 100644
--- a/drivers/thermal/qcom/tsens-8916.c
+++ b/drivers/thermal/qcom/tsens-8916.c
@@ -100,7 +100,7 @@ static int calibrate_8916(struct tsens_device *tmdev)
return 0;
 }
 
-const struct tsens_ops ops_8916 = {
+static const struct tsens_ops ops_8916 = {
.init   = init_common,
.calibrate  = calibrate_8916,
.get_temp   = get_temp_common,
diff --git a/drivers/thermal/qcom/tsens-8960.c 
b/drivers/thermal/qcom/tsens-8960.c
index 1d60916..0451277 100644
--- a/drivers/thermal/qcom/tsens-8960.c
+++ b/drivers/thermal/qcom/tsens-8960.c
@@ -276,7 +276,7 @@ static int get_temp_8960(struct tsens_device *tmdev, int 
id, int *temp)
return -ETIMEDOUT;
 }
 
-const struct tsens_ops ops_8960 = {
+static const struct tsens_ops ops_8960 = {
.init   = init_8960,
.calibrate  = calibrate_8960,
.get_temp   = get_temp_8960,
diff --git a/drivers/thermal/qcom/tsens-8974.c 
b/drivers/thermal/qcom/tsens-8974.c
index da3ca4c..9baf77e 100644
--- a/drivers/thermal/qcom/tsens-8974.c
+++ b/drivers/thermal/qcom/tsens-8974.c
@@ -232,7 +232,7 @@ static int calibrate_8974(struct tsens_device *tmdev)
return 0;
 }
 
-const struct tsens_ops ops_8974 = {
+static const struct tsens_ops ops_8974 = {
.init   = init_common,
.calibrate  = calibrate_8974,
.get_temp   = get_temp_common,
diff --git a/drivers/thermal/qcom/tsens-8996.c 
b/drivers/thermal/qcom/tsens-8996.c
index e2e1274..e1f7781 100644
--- a/drivers/thermal/qcom/tsens-8996.c
+++ b/drivers/thermal/qcom/tsens-8996.c
@@ -73,7 +73,7 @@ done:
return 0;
 }
 
-const struct tsens_ops ops_8996 = {
+static const struct tsens_ops ops_8996 = {
.init   = init_common,
.get_temp   = get_temp_8996,
 };
-- 
2.1.4

Re: [PATCH v2] arm64: dts: rockchip: add the power domain node for rk3399

[Caesar Wang]

On 2016年07月02日 01:09, Javier Martinez Canillas wrote:

Hello Caesar,

On Fri, Jul 1, 2016 at 12:32 AM, Caesar Wang  wrote:

From: Elaine Zhang 

In order to meet low power requirements, a power management unit (PMU) is
designed for controlling power resources in RK3399. The RK3399 PMU is
dedicated for managing the power of the whole chip.

1. add pd node for RK3399 Soc
2. create power domain tree
3. add qos node for domain

 From the DT/binds and driver can get more detail information:
The driver:
 drivers/soc/rockchip/pm_domains.c
The document:
 Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
---

Everything from here to the actual diff will omitted by tools like git-am...


Hmm

I think the '---' cause the broken with patman tool.

Thanks,
Caesar



Changes in v2:
- As Doug/Heiko commnets on https://patchwork.kernel.org/patch/9206415/.
   drop the debugfs-dump and Add the comments for alphabetical order.

Note: As the TRM lists many voltage domains and power domains, then
in actual we just need control some domains for driver.
Due to some domains (e.g. emmc, usb, core)...We can't turn off it on
bootup.

Signed-off-by: Elaine Zhang 
Signed-off-by: Caesar Wang 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: Heiko Stuebner 


...but you have your S-o-B and collected tags here so these are going
to be stripped. You should move those before the first '---'
separator.
Best regards,
Javier

___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
caesar wang | software engineer | w...@rock-chip.com

Re: [PATCH v2] arm64: dts: rockchip: add the power domain node for rk3399

[Caesar Wang]

On 2016年07月02日 01:09, Javier Martinez Canillas wrote:

Hello Caesar,

On Fri, Jul 1, 2016 at 12:32 AM, Caesar Wang  wrote:

From: Elaine Zhang 

In order to meet low power requirements, a power management unit (PMU) is
designed for controlling power resources in RK3399. The RK3399 PMU is
dedicated for managing the power of the whole chip.

1. add pd node for RK3399 Soc
2. create power domain tree
3. add qos node for domain

 From the DT/binds and driver can get more detail information:
The driver:
 drivers/soc/rockchip/pm_domains.c
The document:
 Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
---

Everything from here to the actual diff will omitted by tools like git-am...


Hmm

I think the '---' cause the broken with patman tool.

Thanks,
Caesar



Changes in v2:
- As Doug/Heiko commnets on https://patchwork.kernel.org/patch/9206415/.
   drop the debugfs-dump and Add the comments for alphabetical order.

Note: As the TRM lists many voltage domains and power domains, then
in actual we just need control some domains for driver.
Due to some domains (e.g. emmc, usb, core)...We can't turn off it on
bootup.

Signed-off-by: Elaine Zhang 
Signed-off-by: Caesar Wang 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: Heiko Stuebner 


...but you have your S-o-B and collected tags here so these are going
to be stripped. You should move those before the first '---'
separator.
Best regards,
Javier

___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
caesar wang | software engineer | w...@rock-chip.com

Re: [PATCH V3 4/8] clk: core: support clocks which requires parents enable (part 2)

[Stephen Boyd]

On 06/30, Dong Aisheng wrote:
> On Freescale i.MX7D platform, all clocks operations, including
> enable/disable, rate change and re-parent, requires its parent clock on.
> Current clock core can not support it well.
> This patch adding flag CLK_OPS_PARENT_ENABLE to handle this special case in
> clock core that enable its parent clock firstly for each operation and
> disable it later after operation complete.
> 
> The patch part 2 fixes set clock rate and set parent while its parent
> is off. The most special case is for set_parent() operation which requires
> all parents including both old and new one to be enabled at the same time
> during the operation.
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> ---

Applied to clk-next

> @@ -1502,6 +1514,9 @@ static void clk_change_rate(struct clk_core *core)
>  
>   trace_clk_set_rate(core, core->new_rate);
>  
> + if (core->flags & CLK_OPS_PARENT_ENABLE)
> + clk_core_prepare_enable(parent);
> +

I swapped this with trace_clk_set_rate() so the tracepoint is
closer to the hw operation.

>   if (!skip_set_rate && core->ops->set_rate)
>   core->ops->set_rate(core->hw, core->new_rate, best_parent_rate);
>  

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

Re: [PATCH V3 3/8] clk: core: support clocks which requires parents enable (part 1)

[Stephen Boyd]

On 06/30, Dong Aisheng wrote:
> On Freescale i.MX7D platform, all clocks operations, including
> enable/disable, rate change and re-parent, requires its parent
> clock enable. Current clock core can not support it well.
> This patch introduce a new flag CLK_OPS_PARENT_ENABLE to handle this
> special case in clock core that enable its parent clock firstly for
> each operation and disable it later after operation complete.
> 
> The patch part 1 fixes the possible disabling clocks while its parent
> is off during kernel booting phase in clk_disable_unused_subtree().
> 
> Before the completion of kernel booting, clock tree is still not built
> completely, there may be a case that the child clock is on but its
> parent is off which could be caused by either HW initial reset state
> or bootloader initialization.
> 
> Taking bootloader as an example, we may enable all clocks in HW by default.
> And during kernel booting time, the parent clock could be disabled in its
> driver probe due to calling clk_prepare_enable and clk_disable_unprepare.
> Because it's child clock is only enabled in HW while its SW usecount
> in clock tree is still 0, so clk_disable of parent clock will gate
> the parent clock in both HW and SW usecount ultimately. Then there will
> be a child clock is still on in HW but its parent is already off.
> 
> Later in clk_disable_unused(), this clock disable accessing while its
> parent off will cause system hang due to the limitation of HW which
> must require its parent on.
> 
> This patch simply enables the parent clock first before disabling
> if flag CLK_OPS_PARENT_ENABLE is set in clk_disable_unused_subtree().
> This is a simple solution and only affects booting time.
> 
> After kernel booting up the clock tree is already created, there will
> be no case that child is off but its parent is off.
> So no need do this checking for normal clk_disable() later.
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> ---

Applied to clk-next

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

Re: [PATCH V3 4/8] clk: core: support clocks which requires parents enable (part 2)

[Stephen Boyd]

On 06/30, Dong Aisheng wrote:
> On Freescale i.MX7D platform, all clocks operations, including
> enable/disable, rate change and re-parent, requires its parent clock on.
> Current clock core can not support it well.
> This patch adding flag CLK_OPS_PARENT_ENABLE to handle this special case in
> clock core that enable its parent clock firstly for each operation and
> disable it later after operation complete.
> 
> The patch part 2 fixes set clock rate and set parent while its parent
> is off. The most special case is for set_parent() operation which requires
> all parents including both old and new one to be enabled at the same time
> during the operation.
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> ---

Applied to clk-next

> @@ -1502,6 +1514,9 @@ static void clk_change_rate(struct clk_core *core)
>  
>   trace_clk_set_rate(core, core->new_rate);
>  
> + if (core->flags & CLK_OPS_PARENT_ENABLE)
> + clk_core_prepare_enable(parent);
> +

I swapped this with trace_clk_set_rate() so the tracepoint is
closer to the hw operation.

>   if (!skip_set_rate && core->ops->set_rate)
>   core->ops->set_rate(core->hw, core->new_rate, best_parent_rate);
>  

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

Re: [PATCH V3 3/8] clk: core: support clocks which requires parents enable (part 1)

[Stephen Boyd]

On 06/30, Dong Aisheng wrote:
> On Freescale i.MX7D platform, all clocks operations, including
> enable/disable, rate change and re-parent, requires its parent
> clock enable. Current clock core can not support it well.
> This patch introduce a new flag CLK_OPS_PARENT_ENABLE to handle this
> special case in clock core that enable its parent clock firstly for
> each operation and disable it later after operation complete.
> 
> The patch part 1 fixes the possible disabling clocks while its parent
> is off during kernel booting phase in clk_disable_unused_subtree().
> 
> Before the completion of kernel booting, clock tree is still not built
> completely, there may be a case that the child clock is on but its
> parent is off which could be caused by either HW initial reset state
> or bootloader initialization.
> 
> Taking bootloader as an example, we may enable all clocks in HW by default.
> And during kernel booting time, the parent clock could be disabled in its
> driver probe due to calling clk_prepare_enable and clk_disable_unprepare.
> Because it's child clock is only enabled in HW while its SW usecount
> in clock tree is still 0, so clk_disable of parent clock will gate
> the parent clock in both HW and SW usecount ultimately. Then there will
> be a child clock is still on in HW but its parent is already off.
> 
> Later in clk_disable_unused(), this clock disable accessing while its
> parent off will cause system hang due to the limitation of HW which
> must require its parent on.
> 
> This patch simply enables the parent clock first before disabling
> if flag CLK_OPS_PARENT_ENABLE is set in clk_disable_unused_subtree().
> This is a simple solution and only affects booting time.
> 
> After kernel booting up the clock tree is already created, there will
> be no case that child is off but its parent is off.
> So no need do this checking for normal clk_disable() later.
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> ---

Applied to clk-next

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

Re: [PATCH 1/3] namei: add LOOKUP_DFD_ROOT to use dfd as root

[Omar Sandoval]

On Tue, Jun 28, 2016 at 10:38:28AM -0700, Andrey Vagin wrote:
> The problem is that a pathname can contain absolute symlinks and now
> they are resolved relative to the current root.
> 
> If we want to open a file in another mount namespaces and we have a file
> descriptor to its root directory, we probably want to resolve pathname
> in the target mount namespace. For this we add this new flag.
> 
> If LOOKUP_DFD_ROOT is set, path_init() initializes nd->root and nd->path
> to the same value.
> 
> Signed-off-by: Andrey Vagin 

Hi, Andrey,

Seems like a useful feature. Make sure to cc linux-...@vger.kernel.org
for new userspace interfaces. One comment on the implementation below.

> ---
>  fs/namei.c| 12 +++-
>  include/linux/namei.h |  2 ++
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/namei.c b/fs/namei.c
> index 70580ab..5f08b69 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -2148,7 +2148,7 @@ static const char *path_init(struct nameidata *nd, 
> unsigned flags)
>   nd->path.dentry = NULL;
>  
>   nd->m_seq = read_seqbegin(_lock);
> - if (*s == '/') {
> + if (*s == '/' && !(flags & LOOKUP_DFD_ROOT)) {
>   if (flags & LOOKUP_RCU)
>   rcu_read_lock();
>   set_root(nd);
> @@ -2174,6 +2174,11 @@ static const char *path_init(struct nameidata *nd, 
> unsigned flags)
>   get_fs_pwd(current->fs, >path);
>   nd->inode = nd->path.dentry->d_inode;
>   }
> + if (flags & LOOKUP_DFD_ROOT) {
> + nd->root = nd->path;
> + if (!(flags & LOOKUP_RCU))
> + path_get(>root);

You're not initializing nd->root_seq here. That means that if we end up
going through unlazy_walk(), we're going to call legitimize_path() (and
thus read_seqcount_retry()) with stack garbage, get a spurious ECHILD,
and do an unnecessary restart of the path lookup instead of dropping
into ref-walk mode.

> + }
>   return s;
>   } else {
>   /* Caller must check execute permissions on the starting path 
> component */
> @@ -2202,6 +2207,11 @@ static const char *path_init(struct nameidata *nd, 
> unsigned flags)
>   nd->inode = nd->path.dentry->d_inode;
>   }
>   fdput(f);
> + if (flags & LOOKUP_DFD_ROOT) {
> + nd->root = nd->path;
> + if (!(flags & LOOKUP_RCU))
> + path_get(>root);
> + }

Same here.

The following should do the trick:

diff --git a/fs/namei.c b/fs/namei.c
index 9958b605e822..101d1fb8d3cb 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2176,7 +2176,9 @@ static const char *path_init(struct nameidata *nd, 
unsigned flags)
}
if (flags & LOOKUP_DFD_ROOT) {
nd->root = nd->path;
-   if (!(flags & LOOKUP_RCU))
+   if (flags & LOOKUP_RCU)
+   nd->root_seq = nd->seq;
+   else
path_get(>root);
}
return s;
@@ -2209,7 +2211,9 @@ static const char *path_init(struct nameidata *nd, 
unsigned flags)
fdput(f);
if (flags & LOOKUP_DFD_ROOT) {
nd->root = nd->path;
-   if (!(flags & LOOKUP_RCU))
+   if (flags & LOOKUP_RCU)
+   nd->root_seq = nd->seq;
+   else
path_get(>root);
}
return s;

-- 
Omar

Re: [PATCH 1/3] namei: add LOOKUP_DFD_ROOT to use dfd as root

[Omar Sandoval]

On Tue, Jun 28, 2016 at 10:38:28AM -0700, Andrey Vagin wrote:
> The problem is that a pathname can contain absolute symlinks and now
> they are resolved relative to the current root.
> 
> If we want to open a file in another mount namespaces and we have a file
> descriptor to its root directory, we probably want to resolve pathname
> in the target mount namespace. For this we add this new flag.
> 
> If LOOKUP_DFD_ROOT is set, path_init() initializes nd->root and nd->path
> to the same value.
> 
> Signed-off-by: Andrey Vagin 

Hi, Andrey,

Seems like a useful feature. Make sure to cc linux-...@vger.kernel.org
for new userspace interfaces. One comment on the implementation below.

> ---
>  fs/namei.c| 12 +++-
>  include/linux/namei.h |  2 ++
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/namei.c b/fs/namei.c
> index 70580ab..5f08b69 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -2148,7 +2148,7 @@ static const char *path_init(struct nameidata *nd, 
> unsigned flags)
>   nd->path.dentry = NULL;
>  
>   nd->m_seq = read_seqbegin(_lock);
> - if (*s == '/') {
> + if (*s == '/' && !(flags & LOOKUP_DFD_ROOT)) {
>   if (flags & LOOKUP_RCU)
>   rcu_read_lock();
>   set_root(nd);
> @@ -2174,6 +2174,11 @@ static const char *path_init(struct nameidata *nd, 
> unsigned flags)
>   get_fs_pwd(current->fs, >path);
>   nd->inode = nd->path.dentry->d_inode;
>   }
> + if (flags & LOOKUP_DFD_ROOT) {
> + nd->root = nd->path;
> + if (!(flags & LOOKUP_RCU))
> + path_get(>root);

You're not initializing nd->root_seq here. That means that if we end up
going through unlazy_walk(), we're going to call legitimize_path() (and
thus read_seqcount_retry()) with stack garbage, get a spurious ECHILD,
and do an unnecessary restart of the path lookup instead of dropping
into ref-walk mode.

> + }
>   return s;
>   } else {
>   /* Caller must check execute permissions on the starting path 
> component */
> @@ -2202,6 +2207,11 @@ static const char *path_init(struct nameidata *nd, 
> unsigned flags)
>   nd->inode = nd->path.dentry->d_inode;
>   }
>   fdput(f);
> + if (flags & LOOKUP_DFD_ROOT) {
> + nd->root = nd->path;
> + if (!(flags & LOOKUP_RCU))
> + path_get(>root);
> + }

Same here.

The following should do the trick:

diff --git a/fs/namei.c b/fs/namei.c
index 9958b605e822..101d1fb8d3cb 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2176,7 +2176,9 @@ static const char *path_init(struct nameidata *nd, 
unsigned flags)
}
if (flags & LOOKUP_DFD_ROOT) {
nd->root = nd->path;
-   if (!(flags & LOOKUP_RCU))
+   if (flags & LOOKUP_RCU)
+   nd->root_seq = nd->seq;
+   else
path_get(>root);
}
return s;
@@ -2209,7 +2211,9 @@ static const char *path_init(struct nameidata *nd, 
unsigned flags)
fdput(f);
if (flags & LOOKUP_DFD_ROOT) {
nd->root = nd->path;
-   if (!(flags & LOOKUP_RCU))
+   if (flags & LOOKUP_RCU)
+   nd->root_seq = nd->seq;
+   else
path_get(>root);
}
return s;

-- 
Omar

Re: [PATCH V3 1/8] clk: introduce clk_core_enable_lock and clk_core_disable_lock functions

[Stephen Boyd]

On 06/30, Dong Aisheng wrote:
> This can be useful when clock core wants to enable/disable clocks.
> Then we don't have to convert the struct clk_core to struct clk to call
> clk_enable/clk_disable which is a bit un-align with exist using.
> 
> And after introduce clk_core_{enable|disable}_lock, we can refine
> clk_enable and clk_disable a bit.
> 
> As well as clk_core_{enable|disable}_lock, we also added
> clk_core_{prepare|unprepare}_lock and clk_core_prepare_enable/
> clk_core_unprepare_disable for clock core to easily use.
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> ---

Applied to clk-next

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

Re: [PATCH V3 2/8] clk: move clk_disable_unused after clk_core_disable_unprepare function

[Stephen Boyd]

On 06/30, Dong Aisheng wrote:
> No function level change, just moving code place.
> clk_disable_unused function will need to call clk_core_prepare_enable/
> clk_core_disable_unprepare when adding CLK_OPS_PARENT_ENABLE features.
> So move it after clk_core_disable_unprepare to avoid adding forward
> declared functions later.
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> ---

Applied to clk-next

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

Re: [PATCH V3 1/8] clk: introduce clk_core_enable_lock and clk_core_disable_lock functions

[Stephen Boyd]

On 06/30, Dong Aisheng wrote:
> This can be useful when clock core wants to enable/disable clocks.
> Then we don't have to convert the struct clk_core to struct clk to call
> clk_enable/clk_disable which is a bit un-align with exist using.
> 
> And after introduce clk_core_{enable|disable}_lock, we can refine
> clk_enable and clk_disable a bit.
> 
> As well as clk_core_{enable|disable}_lock, we also added
> clk_core_{prepare|unprepare}_lock and clk_core_prepare_enable/
> clk_core_unprepare_disable for clock core to easily use.
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> ---

Applied to clk-next

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

Re: [PATCH V3 2/8] clk: move clk_disable_unused after clk_core_disable_unprepare function

[Stephen Boyd]

On 06/30, Dong Aisheng wrote:
> No function level change, just moving code place.
> clk_disable_unused function will need to call clk_core_prepare_enable/
> clk_core_disable_unprepare when adding CLK_OPS_PARENT_ENABLE features.
> So move it after clk_core_disable_unprepare to avoid adding forward
> declared functions later.
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> ---

Applied to clk-next

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

Re: [PATCH V3 5/8] clk: imx: re-order and concentrate the same type of clk api

[Stephen Boyd]

On 06/30, Dong Aisheng wrote:
> Re-order and concentrate the same type of clk api for better
> code maintenance.
> 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> ---

Applied to clk-next

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

Re: [PATCH V3 6/8] clk: imx: add clk api for supporting CLK_OPS_PARENT_ENABLE clocks

[Stephen Boyd]

On 06/30, Dong Aisheng wrote:
> IMX SoCs like i.MX7D requires using CLK_OPS_PARENT_ENABLE flags,
> adding the corresponding clock APIs variants for easily to use.
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> ---

Applied to clk-next

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

Re: [PATCH V3 5/8] clk: imx: re-order and concentrate the same type of clk api

[Stephen Boyd]

On 06/30, Dong Aisheng wrote:
> Re-order and concentrate the same type of clk api for better
> code maintenance.
> 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> ---

Applied to clk-next

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

Re: [PATCH V3 6/8] clk: imx: add clk api for supporting CLK_OPS_PARENT_ENABLE clocks

[Stephen Boyd]

On 06/30, Dong Aisheng wrote:
> IMX SoCs like i.MX7D requires using CLK_OPS_PARENT_ENABLE flags,
> adding the corresponding clock APIs variants for easily to use.
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> ---

Applied to clk-next

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

Re: [PATCH V3 7/8] clk: imx7d: using api with flag CLK_OPS_PARENT_ENABLE

[Stephen Boyd]

On 06/30, Dong Aisheng wrote:
> i.MX7D requires all clocks operations including enable/disable,
> rate change and re-parent with its parent clock on.
> Changing to the correct APIs to tell clk core such requirement.
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> ---

Applied to clk-next

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

Re: [PATCH V3 8/8] clk: imx7d: only enable minimum required clocks

[Stephen Boyd]

On 06/30, Dong Aisheng wrote:
> Formerly clk core does not support imx7d clock type well that all
> its clock operations requires the parent clock on.
> Therefore we enabled all clocks by default in clock driver
> initialization for other module clocks operate well.
> 
> After patch 'clk: imx7d: using api with flag CLK_OPS_PARENT_ENABLE',
> clk core can handle such clock type well, so we don't have to enable
> them all by default anymore. Instead, we only enable a minimum required
> set of clocks.
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> ---

Applied to clk-next

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

Re: [PATCH V3 8/8] clk: imx7d: only enable minimum required clocks

[Stephen Boyd]

On 06/30, Dong Aisheng wrote:
> Formerly clk core does not support imx7d clock type well that all
> its clock operations requires the parent clock on.
> Therefore we enabled all clocks by default in clock driver
> initialization for other module clocks operate well.
> 
> After patch 'clk: imx7d: using api with flag CLK_OPS_PARENT_ENABLE',
> clk core can handle such clock type well, so we don't have to enable
> them all by default anymore. Instead, we only enable a minimum required
> set of clocks.
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> ---

Applied to clk-next

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

Re: [PATCH V3 7/8] clk: imx7d: using api with flag CLK_OPS_PARENT_ENABLE

[Stephen Boyd]

On 06/30, Dong Aisheng wrote:
> i.MX7D requires all clocks operations including enable/disable,
> rate change and re-parent with its parent clock on.
> Changing to the correct APIs to tell clk core such requirement.
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Signed-off-by: Dong Aisheng 
> ---

Applied to clk-next

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

Re: [PATCH v3 5/7] PCI: Do not use IORESOURCE_STARTALIGN to identify bridge resources

[Gavin Shan]

On Fri, Jul 01, 2016 at 03:04:10PM +0800, Yongji Xie wrote:
>Hi Gavin,
>
>On 2016/7/1 10:34, Gavin Shan wrote:
>
>>On Thu, Jun 30, 2016 at 06:53:11PM +0800, Yongji Xie wrote:
>>>Now we use the IORESOURCE_STARTALIGN to identify bridge resources
>>>in __assign_resources_sorted(). That's quite fragile. We may also
>>>set flag IORESOURCE_STARTALIGN for SR-IOV resources in some cases,
>>>for example, using the option "noresize" of parameter
>>>"pci=resource_alignment".
>>>
>>>In this patch, we try to use a more robust way to identify
>>>bridge resources.
>>>
>>>Signed-off-by: Yongji Xie 
>>Reviewed-by: Gavin Shan 
>>
>>Yongji, I think this doesn't have to be part of this series, meaning
>>it can be sent or merged separately.
>>
>
>Seems like I give a wrong example in my changelog.  The
>parameter "pci=resource_alignment" would not set flag
>IORESOURCE_STARTALIGN for SR-IOV resources as I replied
>to you in previous patch. So this patch has nothing to do
>with this series now, I will remove it as you suggested.
>

Thanks, please refine the changelog as it's not related to the
enforced alignment as you claimed when resending it separately.

Thanks,
Gavin

Re: [PATCH v3 5/7] PCI: Do not use IORESOURCE_STARTALIGN to identify bridge resources

[Gavin Shan]

On Fri, Jul 01, 2016 at 03:04:10PM +0800, Yongji Xie wrote:
>Hi Gavin,
>
>On 2016/7/1 10:34, Gavin Shan wrote:
>
>>On Thu, Jun 30, 2016 at 06:53:11PM +0800, Yongji Xie wrote:
>>>Now we use the IORESOURCE_STARTALIGN to identify bridge resources
>>>in __assign_resources_sorted(). That's quite fragile. We may also
>>>set flag IORESOURCE_STARTALIGN for SR-IOV resources in some cases,
>>>for example, using the option "noresize" of parameter
>>>"pci=resource_alignment".
>>>
>>>In this patch, we try to use a more robust way to identify
>>>bridge resources.
>>>
>>>Signed-off-by: Yongji Xie 
>>Reviewed-by: Gavin Shan 
>>
>>Yongji, I think this doesn't have to be part of this series, meaning
>>it can be sent or merged separately.
>>
>
>Seems like I give a wrong example in my changelog.  The
>parameter "pci=resource_alignment" would not set flag
>IORESOURCE_STARTALIGN for SR-IOV resources as I replied
>to you in previous patch. So this patch has nothing to do
>with this series now, I will remove it as you suggested.
>

Thanks, please refine the changelog as it's not related to the
enforced alignment as you claimed when resending it separately.

Thanks,
Gavin

Re: [PATCH v3 2/7] PCI: Ignore enforced alignment to VF BARs

[Gavin Shan]

On Fri, Jul 01, 2016 at 02:40:16PM +0800, Yongji Xie wrote:
>Hi Gavin,
>
>On 2016/7/1 14:05, Gavin Shan wrote:
>
>>On Fri, Jul 01, 2016 at 01:27:17PM +0800, Yongji Xie wrote:
On Thu, Jun 30, 2016 at 06:53:08PM +0800, Yongji Xie wrote:
>VF BARs are read-only zeroes according to SRIOV spec,
>the normal way(writing BARs) of allocating resources wouldn't
>be applied to VFs. The VFs' resources would be allocated
>when we enable SR-IOV capability. So we should not try to
>reassign alignment after we enable VFs. It's meaningless
>and will release the allocated resources which leads to a bug.
>
>Signed-off-by: Yongji Xie 
>---
>drivers/pci/pci.c |4 
>1 file changed, 4 insertions(+)
>
>diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>index be8f72c..6ae02de 100644
>--- a/drivers/pci/pci.c
>+++ b/drivers/pci/pci.c
>@@ -4822,6 +4822,10 @@ void pci_reassigndev_resource_alignment(struct 
>pci_dev *dev)
>   resource_size_t align, size;
>   u16 command;
>
>+  /* We should never try to reassign VF's alignment */
>+  if (dev->is_virtfn)
>+  return;
>+
Yongji, I think it's correct to ignore VF's BARs. Another concern is:
it's safe to apply alignment to PF's IOV BARs? Lets have an extreme
example here: one PF has 16 VFs; each VF has only one 1KB. It means
the only PF IOV BAR is 16KB. I don't see how it works after expanding
it to 64KB which is the page size. It might be not a problem on PowerNV
platform, but potentially a issue on x86?
>>>Seems like the alignment would not be applied to IOV BARs because
>>>pci_reassigndev_resource_alignment() will be called before
>>>sriov_init().
>>>
>>Correct, thanks for the claim. I guess the alignment applied to PF IOV
>>BARs should be ignored as well? Anyway, the IOV BARs are retireved from
>>SRIOV capability. It deserves a comment if you plan to take the change.
>>Actually, the comment here (for ignoring alignment to VF BARs) can be
>>improved a bit as well, it'd better why the alignment cannot be applied.
>>
>
>Do you mean we should ignore PF IOV BARs like this:
>
>--- a/drivers/pci/pci.c
>+++ b/drivers/pci/pci.c
>@@ -4833,7 +4833,7 @@ void pci_reassigndev_resource_alignment(struct pci_dev
>*dev)
>command &= ~PCI_COMMAND_MEMORY;
>pci_write_config_word(dev, PCI_COMMAND, command);
>
>-   for (i = 0; i < PCI_BRIDGE_RESOURCES; i++) {
>+   for (i = 0; i <= PCI_ROM_RESOURCE; i++) {
>r = >resource[i];
>if (!(r->flags & IORESOURCE_MEM))
>continue;
>

Yeah, I think it's what I expected. Please add a comment to explain
why PCI bridge windows and PF's IOV BARs are not involed.

Thanks,
Gavin

Re: [PATCH v3 2/7] PCI: Ignore enforced alignment to VF BARs

[Gavin Shan]

On Fri, Jul 01, 2016 at 02:40:16PM +0800, Yongji Xie wrote:
>Hi Gavin,
>
>On 2016/7/1 14:05, Gavin Shan wrote:
>
>>On Fri, Jul 01, 2016 at 01:27:17PM +0800, Yongji Xie wrote:
On Thu, Jun 30, 2016 at 06:53:08PM +0800, Yongji Xie wrote:
>VF BARs are read-only zeroes according to SRIOV spec,
>the normal way(writing BARs) of allocating resources wouldn't
>be applied to VFs. The VFs' resources would be allocated
>when we enable SR-IOV capability. So we should not try to
>reassign alignment after we enable VFs. It's meaningless
>and will release the allocated resources which leads to a bug.
>
>Signed-off-by: Yongji Xie 
>---
>drivers/pci/pci.c |4 
>1 file changed, 4 insertions(+)
>
>diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>index be8f72c..6ae02de 100644
>--- a/drivers/pci/pci.c
>+++ b/drivers/pci/pci.c
>@@ -4822,6 +4822,10 @@ void pci_reassigndev_resource_alignment(struct 
>pci_dev *dev)
>   resource_size_t align, size;
>   u16 command;
>
>+  /* We should never try to reassign VF's alignment */
>+  if (dev->is_virtfn)
>+  return;
>+
Yongji, I think it's correct to ignore VF's BARs. Another concern is:
it's safe to apply alignment to PF's IOV BARs? Lets have an extreme
example here: one PF has 16 VFs; each VF has only one 1KB. It means
the only PF IOV BAR is 16KB. I don't see how it works after expanding
it to 64KB which is the page size. It might be not a problem on PowerNV
platform, but potentially a issue on x86?
>>>Seems like the alignment would not be applied to IOV BARs because
>>>pci_reassigndev_resource_alignment() will be called before
>>>sriov_init().
>>>
>>Correct, thanks for the claim. I guess the alignment applied to PF IOV
>>BARs should be ignored as well? Anyway, the IOV BARs are retireved from
>>SRIOV capability. It deserves a comment if you plan to take the change.
>>Actually, the comment here (for ignoring alignment to VF BARs) can be
>>improved a bit as well, it'd better why the alignment cannot be applied.
>>
>
>Do you mean we should ignore PF IOV BARs like this:
>
>--- a/drivers/pci/pci.c
>+++ b/drivers/pci/pci.c
>@@ -4833,7 +4833,7 @@ void pci_reassigndev_resource_alignment(struct pci_dev
>*dev)
>command &= ~PCI_COMMAND_MEMORY;
>pci_write_config_word(dev, PCI_COMMAND, command);
>
>-   for (i = 0; i < PCI_BRIDGE_RESOURCES; i++) {
>+   for (i = 0; i <= PCI_ROM_RESOURCE; i++) {
>r = >resource[i];
>if (!(r->flags & IORESOURCE_MEM))
>continue;
>

Yeah, I think it's what I expected. Please add a comment to explain
why PCI bridge windows and PF's IOV BARs are not involed.

Thanks,
Gavin

[GIT PULL] irqchip: Core changes for v4.8 (second set)

[Jason Cooper]

Hi Thomas,

Here's the second round of changes for irqchip.  This driver for Aspeed
has been in -next for six runs.

This is an incremental pull request from tags/irqchip-core-4.8 up to
tags/irqchip-core-4.8-2 on the irqchip/core branch.

Please pull.

thx,

Jason.


The following changes since commit e04558cbfe61cd06d762eaaa587616798d9b65b6:

  Merge branch 'irqchip/misc' into irqchip/core (2016-06-23 19:08:40 +)

are available in the git repository at:

  git://git.infradead.org/users/jcooper/linux.git tags/irqchip-core-4.8-2

for you to fetch changes up to 7a9243b950ff2f26720d1cb975b3548162da08de:

  Merge branch 'irqchip/aspeed' into irqchip/core (2016-07-02 00:12:06 +)


irqchip core changes for v4.8 (second set)

 - Add Aspeed VIC driver


Benjamin Herrenschmidt (1):
  irqchip/aspeed-vic: Add irq controller for Aspeed

Jason Cooper (1):
  Merge branch 'irqchip/aspeed' into irqchip/core

Joel Stanley (1):
  doc/devicetree: Add Aspeed VIC bindings

 .../interrupt-controller/aspeed,ast2400-vic.txt|  22 ++
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-aspeed-vic.c   | 230 +
 3 files changed, 253 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-vic.txt
 create mode 100644 drivers/irqchip/irq-aspeed-vic.c

[GIT PULL] irqchip: Core changes for v4.8 (second set)

[Jason Cooper]

Hi Thomas,

Here's the second round of changes for irqchip.  This driver for Aspeed
has been in -next for six runs.

This is an incremental pull request from tags/irqchip-core-4.8 up to
tags/irqchip-core-4.8-2 on the irqchip/core branch.

Please pull.

thx,

Jason.


The following changes since commit e04558cbfe61cd06d762eaaa587616798d9b65b6:

  Merge branch 'irqchip/misc' into irqchip/core (2016-06-23 19:08:40 +)

are available in the git repository at:

  git://git.infradead.org/users/jcooper/linux.git tags/irqchip-core-4.8-2

for you to fetch changes up to 7a9243b950ff2f26720d1cb975b3548162da08de:

  Merge branch 'irqchip/aspeed' into irqchip/core (2016-07-02 00:12:06 +)


irqchip core changes for v4.8 (second set)

 - Add Aspeed VIC driver


Benjamin Herrenschmidt (1):
  irqchip/aspeed-vic: Add irq controller for Aspeed

Jason Cooper (1):
  Merge branch 'irqchip/aspeed' into irqchip/core

Joel Stanley (1):
  doc/devicetree: Add Aspeed VIC bindings

 .../interrupt-controller/aspeed,ast2400-vic.txt|  22 ++
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-aspeed-vic.c   | 230 +
 3 files changed, 253 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-vic.txt
 create mode 100644 drivers/irqchip/irq-aspeed-vic.c

Re: [PATCH v2] clk: fixed-factor: add optional dt-binding clock-flags

[Stephen Boyd]

On 06/29, Jongsung Kim wrote:
> On 2016년 06월 29일 06:18, Michael Turquette wrote:
> > Quoting Rob Herring (2016-06-28 13:55:18)
> >> On Fri, Jun 24, 2016 at 01:12:52PM +0900, Jongsung Kim wrote:
> >>> There is no way to set additional flags for a DT-initialized fixed-
> >>> factor-clock, and it can be problematic i.e., when the clock rate
> >>> needs to be changed. [1][2]
> >>>
> >>> This patch introduces an optional dt-binding named "clock-flags" to
> >>> be used for passing any needed flags from dts.
> >> I don't think we want this in DT. If we did, the flags would need some 
> >> documentation about what the flags mean.
> > Flags are specific to Linux implementation, so I agree with Rob. Better
> > to create a compatible string for your hardware that bakes in the flags.
> 
> Thank you for your comment, Mike. This conversation starts from lacking 
> method to set CLK_SET_RATE_PARENT from DT. I understand compatible string can 
> be a solution. But.. if someone starts talking about lacking method to set 
> another flag, i.e., CLK_SET_PARENT_GATE, then we'll need another compatible 
> string list.
> How do you think about defining possible required subset of the flags and 
> using some more neutral flag-names acceptable in DT?

Do you actually have an IC on the board that is doing some fixed
factor calculation? Or is this a clk driver design where we are
listing out each piece of an SoC's clk controller in DT?

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

Re: [PATCH v2] clk: fixed-factor: add optional dt-binding clock-flags

[Stephen Boyd]

On 06/29, Jongsung Kim wrote:
> On 2016년 06월 29일 06:18, Michael Turquette wrote:
> > Quoting Rob Herring (2016-06-28 13:55:18)
> >> On Fri, Jun 24, 2016 at 01:12:52PM +0900, Jongsung Kim wrote:
> >>> There is no way to set additional flags for a DT-initialized fixed-
> >>> factor-clock, and it can be problematic i.e., when the clock rate
> >>> needs to be changed. [1][2]
> >>>
> >>> This patch introduces an optional dt-binding named "clock-flags" to
> >>> be used for passing any needed flags from dts.
> >> I don't think we want this in DT. If we did, the flags would need some 
> >> documentation about what the flags mean.
> > Flags are specific to Linux implementation, so I agree with Rob. Better
> > to create a compatible string for your hardware that bakes in the flags.
> 
> Thank you for your comment, Mike. This conversation starts from lacking 
> method to set CLK_SET_RATE_PARENT from DT. I understand compatible string can 
> be a solution. But.. if someone starts talking about lacking method to set 
> another flag, i.e., CLK_SET_PARENT_GATE, then we'll need another compatible 
> string list.
> How do you think about defining possible required subset of the flags and 
> using some more neutral flag-names acceptable in DT?

Do you actually have an IC on the board that is doing some fixed
factor calculation? Or is this a clk driver design where we are
listing out each piece of an SoC's clk controller in DT?

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

Re: [PATCH v5 1/2] Input: Driver for SiS 9200 family I2C touchscreen controller.

[Dmitry Torokhov]

Hi Mika,

On Fri, May 06, 2016 at 08:22:16AM +0300, mika.pentt...@nextfour.com wrote:
> From: Mika Penttilä 
> 
> Multitouch protocol B support.
> 
> v5:
>   - rebased to 4.6.0-rc6
> 
> v4:
>   - cleanups and fixes according to review feedback
>   - irq and reset gpios are now optional,
> if not spesified it is expected the firmware / hw
> takes care of reset states and irq flow
>   - irq and reset gpio polarities come from dts/firmware
>   - report parsing and reporting are done at once
>   - error handling improvements
>   - misc cleanups
>   - added comments
> 
> v3:
>   - cleanup unused defines
>   - added acked-bys from SiS
> 
> v2:
>   - use gpio descriptor api
>   - probe cleanups
>   - error handling cleanups
> 
> Signed-off-by: Mika Penttilä 
> Acked-by: Tammy Tseng 
> Acked-by: Yuger Yu 
> ---
>  drivers/input/touchscreen/Kconfig   |  12 +
>  drivers/input/touchscreen/Makefile  |   1 +
>  drivers/input/touchscreen/sis_i2c.c | 461 
> 
>  3 files changed, 474 insertions(+)
>  create mode 100644 drivers/input/touchscreen/sis_i2c.c
> 
> diff --git a/drivers/input/touchscreen/Kconfig 
> b/drivers/input/touchscreen/Kconfig
> index 8ecdc38..8f06ae7 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -1155,4 +1155,16 @@ config TOUCHSCREEN_ROHM_BU21023
> To compile this driver as a module, choose M here: the
> module will be called bu21023_ts.
>  
> +config TOUCHSCREEN_SIS_I2C
> + tristate "SiS 9200 family I2C touchscreen driver"
> + depends on I2C
> + depends on GPIOLIB
> + help
> +   This enables support for SiS 9200 family over I2C based touchscreens.
> +
> +   If unsure, say N.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called sis_i2c.
> +
>  endif
> diff --git a/drivers/input/touchscreen/Makefile 
> b/drivers/input/touchscreen/Makefile
> index f42975e..0839e99 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -63,6 +63,7 @@ obj-$(CONFIG_TOUCHSCREEN_PCAP)  += pcap_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_PENMOUNT)   += penmount.o
>  obj-$(CONFIG_TOUCHSCREEN_PIXCIR) += pixcir_i2c_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_S3C2410)+= s3c2410_ts.o
> +obj-$(CONFIG_TOUCHSCREEN_SIS_I2C)   += sis_i2c.o
>  obj-$(CONFIG_TOUCHSCREEN_ST1232) += st1232.o
>  obj-$(CONFIG_TOUCHSCREEN_STMPE)  += stmpe-ts.o
>  obj-$(CONFIG_TOUCHSCREEN_SUN4I)  += sun4i-ts.o
> diff --git a/drivers/input/touchscreen/sis_i2c.c 
> b/drivers/input/touchscreen/sis_i2c.c
> new file mode 100644
> index 000..f1b66fa
> --- /dev/null
> +++ b/drivers/input/touchscreen/sis_i2c.c
> @@ -0,0 +1,461 @@
> +/* drivers/input/touchscreen/sis_i2c.c
> + *  - I2C Touch panel driver for SiS 9200 family
> + *
> + * Copyright (C) 2011 SiS, Inc.
> + * Copyright (C) 2015 Nextfour Group
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Not needed I think.

> +#include 

Not needed.

> +#include 

Not needed.

> +#include 
> +#include 

Not needed (but gpio/consumer.h is)

> +#include 
> +#include 

Not needed I think.

> +#include 
> +#include 
> +
> +#define SIS_I2C_NAME "sis_i2c_ts"
> +#define MAX_FINGERS  10
> +
> +#define SIS_MAX_X4095
> +#define SIS_MAX_Y4095
> +
> +#define PACKET_BUFFER_SIZE   128
> +
> +#define SIS_CMD_NORMAL   0x0
> +
> +#define TOUCHDOWN   0x3
> +#define TOUCHUP 0x0
> +#define MAX_BYTE  64
> +#define PRESSURE_MAX255
> +
> +/* Resolution diagonal */
> +#define AREA_LENGTH_LONGER   5792
> +/*((SIS_MAX_X^2) + (SIS_MAX_Y^2))^0.5*/
> +#define AREA_LENGTH_SHORT5792
> +#define AREA_UNIT(5792/32)
> +
> +#define P_BYTECOUNT  0
> +#define ALL_IN_ONE_PACKAGE   0x10
> +#define IS_TOUCH(x)  ((x) & 0x1)
> +#define IS_HIDI2C(x) (((x) & 0xF) == 0x06)
> 

Re: [PATCH v5 1/2] Input: Driver for SiS 9200 family I2C touchscreen controller.

[Dmitry Torokhov]

Hi Mika,

On Fri, May 06, 2016 at 08:22:16AM +0300, mika.pentt...@nextfour.com wrote:
> From: Mika Penttilä 
> 
> Multitouch protocol B support.
> 
> v5:
>   - rebased to 4.6.0-rc6
> 
> v4:
>   - cleanups and fixes according to review feedback
>   - irq and reset gpios are now optional,
> if not spesified it is expected the firmware / hw
> takes care of reset states and irq flow
>   - irq and reset gpio polarities come from dts/firmware
>   - report parsing and reporting are done at once
>   - error handling improvements
>   - misc cleanups
>   - added comments
> 
> v3:
>   - cleanup unused defines
>   - added acked-bys from SiS
> 
> v2:
>   - use gpio descriptor api
>   - probe cleanups
>   - error handling cleanups
> 
> Signed-off-by: Mika Penttilä 
> Acked-by: Tammy Tseng 
> Acked-by: Yuger Yu 
> ---
>  drivers/input/touchscreen/Kconfig   |  12 +
>  drivers/input/touchscreen/Makefile  |   1 +
>  drivers/input/touchscreen/sis_i2c.c | 461 
> 
>  3 files changed, 474 insertions(+)
>  create mode 100644 drivers/input/touchscreen/sis_i2c.c
> 
> diff --git a/drivers/input/touchscreen/Kconfig 
> b/drivers/input/touchscreen/Kconfig
> index 8ecdc38..8f06ae7 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -1155,4 +1155,16 @@ config TOUCHSCREEN_ROHM_BU21023
> To compile this driver as a module, choose M here: the
> module will be called bu21023_ts.
>  
> +config TOUCHSCREEN_SIS_I2C
> + tristate "SiS 9200 family I2C touchscreen driver"
> + depends on I2C
> + depends on GPIOLIB
> + help
> +   This enables support for SiS 9200 family over I2C based touchscreens.
> +
> +   If unsure, say N.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called sis_i2c.
> +
>  endif
> diff --git a/drivers/input/touchscreen/Makefile 
> b/drivers/input/touchscreen/Makefile
> index f42975e..0839e99 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -63,6 +63,7 @@ obj-$(CONFIG_TOUCHSCREEN_PCAP)  += pcap_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_PENMOUNT)   += penmount.o
>  obj-$(CONFIG_TOUCHSCREEN_PIXCIR) += pixcir_i2c_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_S3C2410)+= s3c2410_ts.o
> +obj-$(CONFIG_TOUCHSCREEN_SIS_I2C)   += sis_i2c.o
>  obj-$(CONFIG_TOUCHSCREEN_ST1232) += st1232.o
>  obj-$(CONFIG_TOUCHSCREEN_STMPE)  += stmpe-ts.o
>  obj-$(CONFIG_TOUCHSCREEN_SUN4I)  += sun4i-ts.o
> diff --git a/drivers/input/touchscreen/sis_i2c.c 
> b/drivers/input/touchscreen/sis_i2c.c
> new file mode 100644
> index 000..f1b66fa
> --- /dev/null
> +++ b/drivers/input/touchscreen/sis_i2c.c
> @@ -0,0 +1,461 @@
> +/* drivers/input/touchscreen/sis_i2c.c
> + *  - I2C Touch panel driver for SiS 9200 family
> + *
> + * Copyright (C) 2011 SiS, Inc.
> + * Copyright (C) 2015 Nextfour Group
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Not needed I think.

> +#include 

Not needed.

> +#include 

Not needed.

> +#include 
> +#include 

Not needed (but gpio/consumer.h is)

> +#include 
> +#include 

Not needed I think.

> +#include 
> +#include 
> +
> +#define SIS_I2C_NAME "sis_i2c_ts"
> +#define MAX_FINGERS  10
> +
> +#define SIS_MAX_X4095
> +#define SIS_MAX_Y4095
> +
> +#define PACKET_BUFFER_SIZE   128
> +
> +#define SIS_CMD_NORMAL   0x0
> +
> +#define TOUCHDOWN   0x3
> +#define TOUCHUP 0x0
> +#define MAX_BYTE  64
> +#define PRESSURE_MAX255
> +
> +/* Resolution diagonal */
> +#define AREA_LENGTH_LONGER   5792
> +/*((SIS_MAX_X^2) + (SIS_MAX_Y^2))^0.5*/
> +#define AREA_LENGTH_SHORT5792
> +#define AREA_UNIT(5792/32)
> +
> +#define P_BYTECOUNT  0
> +#define ALL_IN_ONE_PACKAGE   0x10
> +#define IS_TOUCH(x)  ((x) & 0x1)
> +#define IS_HIDI2C(x) (((x) & 0xF) == 0x06)
> +#define IS_AREA(x)   (((x) >> 4) & 0x1)
> +#define 

Re: [PATCH RFC] sched: Make wake_up_nohz_cpu() handle CPUs going offline

[Paul E. McKenney]

On Sat, Jul 02, 2016 at 01:49:56AM +0200, Frederic Weisbecker wrote:
> On Fri, Jul 01, 2016 at 11:40:54AM -0700, Paul E. McKenney wrote:
> > On Fri, Jul 01, 2016 at 01:29:59AM +0200, Frederic Weisbecker wrote:
> > > > +/*
> > > > + * Wake up the specified CPU.  If the CPU is going offline, it is the
> > > > + * caller's responsibility to deal with the lost wakeup, for example,
> > > > + * by hooking into the CPU_DEAD notifier like timers and hrtimers do.
> > > > + */
> > > >  void wake_up_nohz_cpu(int cpu)
> > > >  {
> > > > -   if (!wake_up_full_nohz_cpu(cpu))
> > > > +   if (cpu_online(cpu) && !wake_up_full_nohz_cpu(cpu))
> > > 
> > > So at this point, as we passed CPU_DYING, I believe the CPU isn't visible 
> > > in the domains
> > > anymore (correct me if I'm wrong), therefore get_nohz_timer_target() 
> > > can't return it,
> > > unless smp_processor_id() is the only alternative.
> > 
> > Right, but the timers have been posted long before even CPU_UP_PREPARE.
> > From what I can see, they are left alone until CPU_DEAD.  Which means
> > that if you try to mod_timer() them between CPU_DYING and CPU_DEAD,
> > you can get the above splat.
> > 
> > Or am I missing somthing subtle here?
> 
> Yes that's exactly what I meant. It happens on mod_timer() calls
> between CPU_DYING and CPU_DEAD. I just wanted to clarify the
> conditions for it to happen: the fact that it shouldn't concern
> remote CPU targets, only local pinned timers.

OK.  What happens in the following sequence of events?

o   CPU 5 posts a timer, which might well be locally pinned.
This is rcu_torture_reader() posting its on-stack timer
creatively named "t".

o   CPU 5 starts going offline, so that rcu_torture_reader() gets
migrated to CPU 6.

o   CPU 5 reaches CPU_DYING but has not yet reached CPU_DEAD.

o   CPU 6 invokes mod_timer() on its timer "t".

Wouldn't that trigger the scenario that I am seeing?

> > > Hence, that call to wake_up_nohz_cpu() can only happen to online CPUs or 
> > > the current
> > > one (pinned). And wake_up_idle_cpu() on the current CPU is a no-op. So 
> > > only
> > > wake_up_full_nohz_cpu() is concerned. Then perhaps it would be better to 
> > > move that
> > > cpu_online() check to wake_up_full_nohz_cpu() ?
> > 
> > As in the patch shown below?  Either way works for me.
> 
> Hmm, the patch doesn't seem to be different than the previous one :-)

Indeed it does not!  How about the one shown below this time?

> > > BTW, it seems that rcutorture stops its kthreads after CPU_DYING, is it 
> > > expected that
> > > it queues timers at this stage?
> > 
> > Hmmm...  From what I can see, rcutorture cleans up its priority-boost
> > kthreads at CPU_DOWN_PREPARE time.  The other threads are allowed to
> > migrate wherever the scheduler wants, give or take the task shuffling.
> > The task shuffling only excludes one CPU at a time, and I have seen
> > this occur when multiple CPUs were running, e.g., 0, 2, and 3 while
> > offlining 1.
> 
> But if rcutorture kthreads are cleaned up at CPU_DOWN_PREPARE, they
> shouldn't be calling mod_timer() on CPU_DYING time. Or there are other
> rcutorture threads?

The rcu_torture_reader() kthreads aren't associated with any particular
CPU, so when CPUs go offline, they just get migrated to other CPUs.
This allows them to execute on those other CPUs between CPU_DYING and
CPU_DEAD time, correct?

Other rcutorture kthreads -are- bound to specific CPUs, but they are
testing priority boosting, not simple reading.

> > Besides which, doesn't the scheduler prevent anything but the idle
> > thread from running after CPU_DYING time?
> 
> Indeed migrate_tasks() is called on CPU_DYING but pinned kthreads, outside
> smpboot, have their own way to deal with hotplug through notifiers.

Agreed, but the rcu_torture_reader() kthreads aren't pinned, so they
should migrate automatically at CPU_DYING time.

Thanx, Paul



diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 7f2cae4620c7..1a91fc733a0f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -580,6 +580,8 @@ static bool wake_up_full_nohz_cpu(int cpu)
 * If needed we can still optimize that later with an
 * empty IRQ.
 */
+   if (cpu_is_offline(cpu))
+   return true;
if (tick_nohz_full_cpu(cpu)) {
if (cpu != smp_processor_id() ||
tick_nohz_tick_stopped())
@@ -590,6 +592,11 @@ static bool wake_up_full_nohz_cpu(int cpu)
return false;
 }
 
+/*
+ * Wake up the specified CPU.  If the CPU is going offline, it is the
+ * caller's responsibility to deal with the lost wakeup, for example,
+ * by hooking into the CPU_DEAD notifier like timers and hrtimers do.
+ */
 void wake_up_nohz_cpu(int cpu)
 {
if (!wake_up_full_nohz_cpu(cpu))

Re: [PATCH RFC] sched: Make wake_up_nohz_cpu() handle CPUs going offline

[Paul E. McKenney]

On Sat, Jul 02, 2016 at 01:49:56AM +0200, Frederic Weisbecker wrote:
> On Fri, Jul 01, 2016 at 11:40:54AM -0700, Paul E. McKenney wrote:
> > On Fri, Jul 01, 2016 at 01:29:59AM +0200, Frederic Weisbecker wrote:
> > > > +/*
> > > > + * Wake up the specified CPU.  If the CPU is going offline, it is the
> > > > + * caller's responsibility to deal with the lost wakeup, for example,
> > > > + * by hooking into the CPU_DEAD notifier like timers and hrtimers do.
> > > > + */
> > > >  void wake_up_nohz_cpu(int cpu)
> > > >  {
> > > > -   if (!wake_up_full_nohz_cpu(cpu))
> > > > +   if (cpu_online(cpu) && !wake_up_full_nohz_cpu(cpu))
> > > 
> > > So at this point, as we passed CPU_DYING, I believe the CPU isn't visible 
> > > in the domains
> > > anymore (correct me if I'm wrong), therefore get_nohz_timer_target() 
> > > can't return it,
> > > unless smp_processor_id() is the only alternative.
> > 
> > Right, but the timers have been posted long before even CPU_UP_PREPARE.
> > From what I can see, they are left alone until CPU_DEAD.  Which means
> > that if you try to mod_timer() them between CPU_DYING and CPU_DEAD,
> > you can get the above splat.
> > 
> > Or am I missing somthing subtle here?
> 
> Yes that's exactly what I meant. It happens on mod_timer() calls
> between CPU_DYING and CPU_DEAD. I just wanted to clarify the
> conditions for it to happen: the fact that it shouldn't concern
> remote CPU targets, only local pinned timers.

OK.  What happens in the following sequence of events?

o   CPU 5 posts a timer, which might well be locally pinned.
This is rcu_torture_reader() posting its on-stack timer
creatively named "t".

o   CPU 5 starts going offline, so that rcu_torture_reader() gets
migrated to CPU 6.

o   CPU 5 reaches CPU_DYING but has not yet reached CPU_DEAD.

o   CPU 6 invokes mod_timer() on its timer "t".

Wouldn't that trigger the scenario that I am seeing?

> > > Hence, that call to wake_up_nohz_cpu() can only happen to online CPUs or 
> > > the current
> > > one (pinned). And wake_up_idle_cpu() on the current CPU is a no-op. So 
> > > only
> > > wake_up_full_nohz_cpu() is concerned. Then perhaps it would be better to 
> > > move that
> > > cpu_online() check to wake_up_full_nohz_cpu() ?
> > 
> > As in the patch shown below?  Either way works for me.
> 
> Hmm, the patch doesn't seem to be different than the previous one :-)

Indeed it does not!  How about the one shown below this time?

> > > BTW, it seems that rcutorture stops its kthreads after CPU_DYING, is it 
> > > expected that
> > > it queues timers at this stage?
> > 
> > Hmmm...  From what I can see, rcutorture cleans up its priority-boost
> > kthreads at CPU_DOWN_PREPARE time.  The other threads are allowed to
> > migrate wherever the scheduler wants, give or take the task shuffling.
> > The task shuffling only excludes one CPU at a time, and I have seen
> > this occur when multiple CPUs were running, e.g., 0, 2, and 3 while
> > offlining 1.
> 
> But if rcutorture kthreads are cleaned up at CPU_DOWN_PREPARE, they
> shouldn't be calling mod_timer() on CPU_DYING time. Or there are other
> rcutorture threads?

The rcu_torture_reader() kthreads aren't associated with any particular
CPU, so when CPUs go offline, they just get migrated to other CPUs.
This allows them to execute on those other CPUs between CPU_DYING and
CPU_DEAD time, correct?

Other rcutorture kthreads -are- bound to specific CPUs, but they are
testing priority boosting, not simple reading.

> > Besides which, doesn't the scheduler prevent anything but the idle
> > thread from running after CPU_DYING time?
> 
> Indeed migrate_tasks() is called on CPU_DYING but pinned kthreads, outside
> smpboot, have their own way to deal with hotplug through notifiers.

Agreed, but the rcu_torture_reader() kthreads aren't pinned, so they
should migrate automatically at CPU_DYING time.

Thanx, Paul



diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 7f2cae4620c7..1a91fc733a0f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -580,6 +580,8 @@ static bool wake_up_full_nohz_cpu(int cpu)
 * If needed we can still optimize that later with an
 * empty IRQ.
 */
+   if (cpu_is_offline(cpu))
+   return true;
if (tick_nohz_full_cpu(cpu)) {
if (cpu != smp_processor_id() ||
tick_nohz_tick_stopped())
@@ -590,6 +592,11 @@ static bool wake_up_full_nohz_cpu(int cpu)
return false;
 }
 
+/*
+ * Wake up the specified CPU.  If the CPU is going offline, it is the
+ * caller's responsibility to deal with the lost wakeup, for example,
+ * by hooking into the CPU_DEAD notifier like timers and hrtimers do.
+ */
 void wake_up_nohz_cpu(int cpu)
 {
if (!wake_up_full_nohz_cpu(cpu))

[GIT PULL] clk fixes for v4.7-rc5

[Stephen Boyd]

The following changes since commit 72ad679aa7182d23d269cbe4d655f7e129d3b057:

  clk: nxp: Select MFD_SYSCON for creg driver (2016-06-01 15:14:06 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git 
tags/clk-fixes-for-linus

for you to fetch changes up to 086347705be7530feabb6274a3ad81dd545e7914:

  Merge tag 'v4.7-rockchip-clk-fixes1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into 
clk-fixes (2016-06-20 17:01:45 -0700)


A small fix for the newly added oxnas clk driver and a handful of
rockchip clk driver fixes for newly added rk3399 support.


Brian Norris (1):
  clk: rockchip: mark rk3399 GIC clocks as critical

Douglas Anderson (1):
  clk: rockchip: Revert "clk: rockchip: reset init state before mmc card 
initialization"

Heiko Stuebner (1):
  clk: rockchip: initialize flags of clk_init_data in mmc-phase clock

Shawn Lin (1):
  clk: rockchip: release io resource when failing to init clk on rk3399

Stephen Boyd (1):
  Merge tag 'v4.7-rockchip-clk-fixes1' of 
git://git.kernel.org/.../mmind/linux-rockchip into clk-fixes

Wei Yongjun (1):
  clk: Fix return value check in oxnas_stdclk_probe()

Xing Zheng (2):
  clk: rockchip: fix incorrect parent for rk3399's {c,g}pll_aclk_perihp_src
  clk: rockchip: fix cpuclk registration error handling

 drivers/clk/clk-oxnas.c  |  4 ++--
 drivers/clk/rockchip/clk-cpu.c   |  4 ++--
 drivers/clk/rockchip/clk-mmc-phase.c | 12 +---
 drivers/clk/rockchip/clk-rk3399.c|  8 ++--
 4 files changed, 11 insertions(+), 17 deletions(-)

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

[GIT PULL] clk fixes for v4.7-rc5

[Stephen Boyd]

The following changes since commit 72ad679aa7182d23d269cbe4d655f7e129d3b057:

  clk: nxp: Select MFD_SYSCON for creg driver (2016-06-01 15:14:06 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git 
tags/clk-fixes-for-linus

for you to fetch changes up to 086347705be7530feabb6274a3ad81dd545e7914:

  Merge tag 'v4.7-rockchip-clk-fixes1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into 
clk-fixes (2016-06-20 17:01:45 -0700)


A small fix for the newly added oxnas clk driver and a handful of
rockchip clk driver fixes for newly added rk3399 support.


Brian Norris (1):
  clk: rockchip: mark rk3399 GIC clocks as critical

Douglas Anderson (1):
  clk: rockchip: Revert "clk: rockchip: reset init state before mmc card 
initialization"

Heiko Stuebner (1):
  clk: rockchip: initialize flags of clk_init_data in mmc-phase clock

Shawn Lin (1):
  clk: rockchip: release io resource when failing to init clk on rk3399

Stephen Boyd (1):
  Merge tag 'v4.7-rockchip-clk-fixes1' of 
git://git.kernel.org/.../mmind/linux-rockchip into clk-fixes

Wei Yongjun (1):
  clk: Fix return value check in oxnas_stdclk_probe()

Xing Zheng (2):
  clk: rockchip: fix incorrect parent for rk3399's {c,g}pll_aclk_perihp_src
  clk: rockchip: fix cpuclk registration error handling

 drivers/clk/clk-oxnas.c  |  4 ++--
 drivers/clk/rockchip/clk-cpu.c   |  4 ++--
 drivers/clk/rockchip/clk-mmc-phase.c | 12 +---
 drivers/clk/rockchip/clk-rk3399.c|  8 ++--
 4 files changed, 11 insertions(+), 17 deletions(-)

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

Re: [PATCH v2] clk: Add fractional scale clock support

[Hoan Tran]

Hi Stephen,

On Fri, Jul 1, 2016 at 11:38 AM, Stephen Boyd  wrote:
> Sorry I replied offlist before. Pressed the wrong key.
>
> On 06/30, Hoan Tran wrote:
>> On Thu, Jun 30, 2016 at 1:23 PM, Stephen Boyd  wrote:
>> >
>> > How is this different from clk-fractional-divider.c?
>> >
>>
>> This is a driver which clock output is multiplied with a fixed fractional
>> scale (denominator).
>> A field inside a register is used to configure the multiplier.
>>
>> Example: With fractional scale is 1/8.
>> Freq_out = Freq_parent * multiplier * (1/8)
>>
>> For fractional-divider, there are 2 fields of a register are used which
>>  - A field for numerator
>>  - A field for denominator
>> Freq_out = Freq_parent * numerator / denominator
>>
>
> Ok so the difference is that the denominator is a fixed value?

The major difference is a fixed denominator.
Another difference is:
In case CLK_FRACTIONAL_SCALE_INVERTED=1, the freq_out is calculated as below

Freq_out = Freq_parent * (fixed_denominator - multiplier) / fixed_denominator.

> Perhaps that can be modeled as a clk-multiplier that is used as
> the only parent of a fixed divider?

Because of CLK_FRACTIONAL_SCALE_INVERTED flag, I don't know how to
model as a clk-multiplier. And how to pass the fixed denominator into
a clk-multiplier.

> Or we can add a flag to the
> clk-fractional-divider code to handle this minor difference.

This driver is used 2 register fields for numerator, denominator and
calculates both of them.
Do you think I can integrate this fractional scale into it ?

Thanks
Hoan

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

Re: [PATCH v2] clk: Add fractional scale clock support

[Hoan Tran]

Hi Stephen,

On Fri, Jul 1, 2016 at 11:38 AM, Stephen Boyd  wrote:
> Sorry I replied offlist before. Pressed the wrong key.
>
> On 06/30, Hoan Tran wrote:
>> On Thu, Jun 30, 2016 at 1:23 PM, Stephen Boyd  wrote:
>> >
>> > How is this different from clk-fractional-divider.c?
>> >
>>
>> This is a driver which clock output is multiplied with a fixed fractional
>> scale (denominator).
>> A field inside a register is used to configure the multiplier.
>>
>> Example: With fractional scale is 1/8.
>> Freq_out = Freq_parent * multiplier * (1/8)
>>
>> For fractional-divider, there are 2 fields of a register are used which
>>  - A field for numerator
>>  - A field for denominator
>> Freq_out = Freq_parent * numerator / denominator
>>
>
> Ok so the difference is that the denominator is a fixed value?

The major difference is a fixed denominator.
Another difference is:
In case CLK_FRACTIONAL_SCALE_INVERTED=1, the freq_out is calculated as below

Freq_out = Freq_parent * (fixed_denominator - multiplier) / fixed_denominator.

> Perhaps that can be modeled as a clk-multiplier that is used as
> the only parent of a fixed divider?

Because of CLK_FRACTIONAL_SCALE_INVERTED flag, I don't know how to
model as a clk-multiplier. And how to pass the fixed denominator into
a clk-multiplier.

> Or we can add a flag to the
> clk-fractional-divider code to handle this minor difference.

This driver is used 2 register fields for numerator, denominator and
calculates both of them.
Do you think I can integrate this fractional scale into it ?

Thanks
Hoan

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

Re: [PATCH v2] pinctrl: qcom: add support for EBI2

[Bjorn Andersson]

On Fri 01 Jul 16:56 PDT 2016, Linus Walleij wrote:

> Add support to mux in the second external bus interface as
> follows:
> 
> - CS1 and CS2 on GPIO39 and GPIO40 as func 2
> - ADDR_7 thru ADDR_0 on GPIO123 thru GPIO130 as func 1
> - CS4, CS3 and CS0 on GPIO132, GPIO133, GPIO134 as func 1
> - DATA_15 thru DATA_0 on GPIO135 thru GPIO150 as func 1
> - OE on GPIO151 as func 1
> - ADV on GPIO153 as func 1
> - WE on GPIO157 as func 1
> 
> This external bus is used on the APQ8060 Dragonboard to connect
> an external SMSC9211 ethernet adapter, but there are many other
> usecases for the EBI2.
> 
> Cc: Stephen Boyd 
> Cc: Bjorn Andersson 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v1->v2:
> - Pick out the exact right pin assignments from the old codebase.
> ---
>  drivers/pinctrl/qcom/pinctrl-msm8660.c | 72 
> +++---
>  1 file changed, 41 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm8660.c 
> b/drivers/pinctrl/qcom/pinctrl-msm8660.c
> index 3e8f7ac2ac8a..debc90101553 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm8660.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm8660.c
> @@ -506,6 +506,7 @@ enum msm8660_functions {
>   MSM_MUX_usb_fs2_oe_n,
>   MSM_MUX_vfe,
>   MSM_MUX_vsens_alarm,
> + MSM_MUX_ebi2,
>   MSM_MUX__,
>  };
>  
> @@ -696,6 +697,14 @@ static const char * const vfe_groups[] = {
>  static const char * const vsens_alarm_groups[] = {
>   "gpio127"
>  };
> +static const char * const ebi2_groups[] = {
> + "gpio39", "gpio40", "gpio123", "gpio124", "gpio125", "gpio126",
> + "gpio127", "gpio128", "gpio129", "gpio130", "gpio132", "gpio133",
> + "gpio134", "gpio135", "gpio136", "gpio137", "gpio138", "gpio139"
> + "gpio140", "gpio141", "gpio142", "gpio143", "gpio144", "gpio145",
> + "gpio146", "gpio147", "gpio148", "gpio149", "gpio150", "gpio151",
> + "gpio153", "gpio157"
> +};
>  
>  static const struct msm_function msm8660_functions[] = {
>   FUNCTION(gpio),
> @@ -749,6 +758,7 @@ static const struct msm_function msm8660_functions[] = {
>   FUNCTION(usb_fs2_oe_n),
>   FUNCTION(vfe),
>   FUNCTION(vsens_alarm),
> + FUNCTION(ebi2),
>  };
>  
>  static const struct msm_pingroup msm8660_groups[] = {
> @@ -791,8 +801,8 @@ static const struct msm_pingroup msm8660_groups[] = {
>   PINGROUP(36, gsbi1, _, _, _, _, _, _),
>   PINGROUP(37, gsbi2, _, _, _, _, _, _),
>   PINGROUP(38, gsbi2, _, _, _, _, _, _),
> - PINGROUP(39, gsbi2, _, mdp_vsync, _, _, _, _),
> - PINGROUP(40, gsbi2, _, _, _, _, _, _),
> + PINGROUP(39, gsbi2, ebi2, mdp_vsync, _, _, _, _),
> + PINGROUP(40, gsbi2, ebi2, _, _, _, _, _),
>   PINGROUP(41, gsbi3, mdp_vsync, _, _, _, _, _),
>   PINGROUP(42, gsbi3, vfe, _, _, _, _, _),
>   PINGROUP(43, gsbi3, _, _, _, _, _, _),
> @@ -875,41 +885,41 @@ static const struct msm_pingroup msm8660_groups[] = {
>   PINGROUP(120, i2s, _, _, _, _, _, _),
>   PINGROUP(121, i2s, _, _, _, _, _, _),
>   PINGROUP(122, i2s, gp_clk_1b, _, _, _, _, _),
> - PINGROUP(123, _, gsbi2_spi_cs1_n, _, _, _, _, _),
> - PINGROUP(124, _, gsbi2_spi_cs2_n, _, _, _, _, _),
> - PINGROUP(125, _, gsbi2_spi_cs3_n, _, _, _, _, _),
> - PINGROUP(126, _, _, _, _, _, _, _),
> - PINGROUP(127, _, vsens_alarm, _, _, _, _, _),
> - PINGROUP(128, _, _, _, _, _, _, _),
> - PINGROUP(129, _, _, _, _, _, _, _),
> - PINGROUP(130, _, _, _, _, _, _, _),
> + PINGROUP(123, ebi2, gsbi2_spi_cs1_n, _, _, _, _, _),
> + PINGROUP(124, ebi2, gsbi2_spi_cs2_n, _, _, _, _, _),
> + PINGROUP(125, ebi2, gsbi2_spi_cs3_n, _, _, _, _, _),
> + PINGROUP(126, ebi2, _, _, _, _, _, _),
> + PINGROUP(127, ebi2, vsens_alarm, _, _, _, _, _),
> + PINGROUP(128, ebi2, _, _, _, _, _, _),
> + PINGROUP(129, ebi2, _, _, _, _, _, _),
> + PINGROUP(130, ebi2, _, _, _, _, _, _),
>   PINGROUP(131, _, _, _, _, _, _, _),
> - PINGROUP(132, _, _, _, _, _, _, _),
> - PINGROUP(133, _, _, _, _, _, _, _),
> + PINGROUP(132, ebi2, _, _, _, _, _, _),
> + PINGROUP(133, ebi2, _, _, _, _, _, _),
>   PINGROUP(134, _, _, _, _, _, _, _),
> - PINGROUP(135, _, _, _, _, _, _, _),
> - PINGROUP(136, _, _, _, _, _, _, _),
> - PINGROUP(137, _, _, _, _, _, _, _),
> - PINGROUP(138, _, _, _, _, _, _, _),
> - PINGROUP(139, _, _, _, _, _, _, _),
> - PINGROUP(140, _, _, _, _, _, _, _),
> - PINGROUP(141, _, _, _, _, _, _, _),
> - PINGROUP(142, _, _, _, _, _, _, _),
> - PINGROUP(143, _, sdc2, _, _, _, _, _),
> - PINGROUP(144, _, sdc2, _, _, _, _, _),
> - PINGROUP(145, _, sdc2, _, _, _, _, _),
> - PINGROUP(146, _, sdc2, _, _, _, _, _),
> - PINGROUP(147, _, sdc2, _, _, _, _, _),
> - PINGROUP(148, _, sdc2, _, _, _, _, _),
> - PINGROUP(149, _, sdc2, _, _, _, _, _),

Re: [PATCH v2] pinctrl: qcom: add support for EBI2

[Bjorn Andersson]

On Fri 01 Jul 16:56 PDT 2016, Linus Walleij wrote:

> Add support to mux in the second external bus interface as
> follows:
> 
> - CS1 and CS2 on GPIO39 and GPIO40 as func 2
> - ADDR_7 thru ADDR_0 on GPIO123 thru GPIO130 as func 1
> - CS4, CS3 and CS0 on GPIO132, GPIO133, GPIO134 as func 1
> - DATA_15 thru DATA_0 on GPIO135 thru GPIO150 as func 1
> - OE on GPIO151 as func 1
> - ADV on GPIO153 as func 1
> - WE on GPIO157 as func 1
> 
> This external bus is used on the APQ8060 Dragonboard to connect
> an external SMSC9211 ethernet adapter, but there are many other
> usecases for the EBI2.
> 
> Cc: Stephen Boyd 
> Cc: Bjorn Andersson 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v1->v2:
> - Pick out the exact right pin assignments from the old codebase.
> ---
>  drivers/pinctrl/qcom/pinctrl-msm8660.c | 72 
> +++---
>  1 file changed, 41 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm8660.c 
> b/drivers/pinctrl/qcom/pinctrl-msm8660.c
> index 3e8f7ac2ac8a..debc90101553 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm8660.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm8660.c
> @@ -506,6 +506,7 @@ enum msm8660_functions {
>   MSM_MUX_usb_fs2_oe_n,
>   MSM_MUX_vfe,
>   MSM_MUX_vsens_alarm,
> + MSM_MUX_ebi2,
>   MSM_MUX__,
>  };
>  
> @@ -696,6 +697,14 @@ static const char * const vfe_groups[] = {
>  static const char * const vsens_alarm_groups[] = {
>   "gpio127"
>  };
> +static const char * const ebi2_groups[] = {
> + "gpio39", "gpio40", "gpio123", "gpio124", "gpio125", "gpio126",
> + "gpio127", "gpio128", "gpio129", "gpio130", "gpio132", "gpio133",
> + "gpio134", "gpio135", "gpio136", "gpio137", "gpio138", "gpio139"
> + "gpio140", "gpio141", "gpio142", "gpio143", "gpio144", "gpio145",
> + "gpio146", "gpio147", "gpio148", "gpio149", "gpio150", "gpio151",
> + "gpio153", "gpio157"
> +};
>  
>  static const struct msm_function msm8660_functions[] = {
>   FUNCTION(gpio),
> @@ -749,6 +758,7 @@ static const struct msm_function msm8660_functions[] = {
>   FUNCTION(usb_fs2_oe_n),
>   FUNCTION(vfe),
>   FUNCTION(vsens_alarm),
> + FUNCTION(ebi2),
>  };
>  
>  static const struct msm_pingroup msm8660_groups[] = {
> @@ -791,8 +801,8 @@ static const struct msm_pingroup msm8660_groups[] = {
>   PINGROUP(36, gsbi1, _, _, _, _, _, _),
>   PINGROUP(37, gsbi2, _, _, _, _, _, _),
>   PINGROUP(38, gsbi2, _, _, _, _, _, _),
> - PINGROUP(39, gsbi2, _, mdp_vsync, _, _, _, _),
> - PINGROUP(40, gsbi2, _, _, _, _, _, _),
> + PINGROUP(39, gsbi2, ebi2, mdp_vsync, _, _, _, _),
> + PINGROUP(40, gsbi2, ebi2, _, _, _, _, _),
>   PINGROUP(41, gsbi3, mdp_vsync, _, _, _, _, _),
>   PINGROUP(42, gsbi3, vfe, _, _, _, _, _),
>   PINGROUP(43, gsbi3, _, _, _, _, _, _),
> @@ -875,41 +885,41 @@ static const struct msm_pingroup msm8660_groups[] = {
>   PINGROUP(120, i2s, _, _, _, _, _, _),
>   PINGROUP(121, i2s, _, _, _, _, _, _),
>   PINGROUP(122, i2s, gp_clk_1b, _, _, _, _, _),
> - PINGROUP(123, _, gsbi2_spi_cs1_n, _, _, _, _, _),
> - PINGROUP(124, _, gsbi2_spi_cs2_n, _, _, _, _, _),
> - PINGROUP(125, _, gsbi2_spi_cs3_n, _, _, _, _, _),
> - PINGROUP(126, _, _, _, _, _, _, _),
> - PINGROUP(127, _, vsens_alarm, _, _, _, _, _),
> - PINGROUP(128, _, _, _, _, _, _, _),
> - PINGROUP(129, _, _, _, _, _, _, _),
> - PINGROUP(130, _, _, _, _, _, _, _),
> + PINGROUP(123, ebi2, gsbi2_spi_cs1_n, _, _, _, _, _),
> + PINGROUP(124, ebi2, gsbi2_spi_cs2_n, _, _, _, _, _),
> + PINGROUP(125, ebi2, gsbi2_spi_cs3_n, _, _, _, _, _),
> + PINGROUP(126, ebi2, _, _, _, _, _, _),
> + PINGROUP(127, ebi2, vsens_alarm, _, _, _, _, _),
> + PINGROUP(128, ebi2, _, _, _, _, _, _),
> + PINGROUP(129, ebi2, _, _, _, _, _, _),
> + PINGROUP(130, ebi2, _, _, _, _, _, _),
>   PINGROUP(131, _, _, _, _, _, _, _),
> - PINGROUP(132, _, _, _, _, _, _, _),
> - PINGROUP(133, _, _, _, _, _, _, _),
> + PINGROUP(132, ebi2, _, _, _, _, _, _),
> + PINGROUP(133, ebi2, _, _, _, _, _, _),
>   PINGROUP(134, _, _, _, _, _, _, _),
> - PINGROUP(135, _, _, _, _, _, _, _),
> - PINGROUP(136, _, _, _, _, _, _, _),
> - PINGROUP(137, _, _, _, _, _, _, _),
> - PINGROUP(138, _, _, _, _, _, _, _),
> - PINGROUP(139, _, _, _, _, _, _, _),
> - PINGROUP(140, _, _, _, _, _, _, _),
> - PINGROUP(141, _, _, _, _, _, _, _),
> - PINGROUP(142, _, _, _, _, _, _, _),
> - PINGROUP(143, _, sdc2, _, _, _, _, _),
> - PINGROUP(144, _, sdc2, _, _, _, _, _),
> - PINGROUP(145, _, sdc2, _, _, _, _, _),
> - PINGROUP(146, _, sdc2, _, _, _, _, _),
> - PINGROUP(147, _, sdc2, _, _, _, _, _),
> - PINGROUP(148, _, sdc2, _, _, _, _, _),
> - PINGROUP(149, _, sdc2, _, _, _, _, _),
> - PINGROUP(150, _, sdc2, _, _, _, _, _),
> - PINGROUP(151, _, sdc2, _, _, _, _, _),
> + 

[PATCH v2] pinctrl: qcom: add support for EBI2

[Linus Walleij]

Add support to mux in the second external bus interface as
follows:

- CS1 and CS2 on GPIO39 and GPIO40 as func 2
- ADDR_7 thru ADDR_0 on GPIO123 thru GPIO130 as func 1
- CS4, CS3 and CS0 on GPIO132, GPIO133, GPIO134 as func 1
- DATA_15 thru DATA_0 on GPIO135 thru GPIO150 as func 1
- OE on GPIO151 as func 1
- ADV on GPIO153 as func 1
- WE on GPIO157 as func 1

This external bus is used on the APQ8060 Dragonboard to connect
an external SMSC9211 ethernet adapter, but there are many other
usecases for the EBI2.

Cc: Stephen Boyd 
Cc: Bjorn Andersson 
Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Pick out the exact right pin assignments from the old codebase.
---
 drivers/pinctrl/qcom/pinctrl-msm8660.c | 72 +++---
 1 file changed, 41 insertions(+), 31 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-msm8660.c 
b/drivers/pinctrl/qcom/pinctrl-msm8660.c
index 3e8f7ac2ac8a..debc90101553 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm8660.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm8660.c
@@ -506,6 +506,7 @@ enum msm8660_functions {
MSM_MUX_usb_fs2_oe_n,
MSM_MUX_vfe,
MSM_MUX_vsens_alarm,
+   MSM_MUX_ebi2,
MSM_MUX__,
 };
 
@@ -696,6 +697,14 @@ static const char * const vfe_groups[] = {
 static const char * const vsens_alarm_groups[] = {
"gpio127"
 };
+static const char * const ebi2_groups[] = {
+   "gpio39", "gpio40", "gpio123", "gpio124", "gpio125", "gpio126",
+   "gpio127", "gpio128", "gpio129", "gpio130", "gpio132", "gpio133",
+   "gpio134", "gpio135", "gpio136", "gpio137", "gpio138", "gpio139"
+   "gpio140", "gpio141", "gpio142", "gpio143", "gpio144", "gpio145",
+   "gpio146", "gpio147", "gpio148", "gpio149", "gpio150", "gpio151",
+   "gpio153", "gpio157"
+};
 
 static const struct msm_function msm8660_functions[] = {
FUNCTION(gpio),
@@ -749,6 +758,7 @@ static const struct msm_function msm8660_functions[] = {
FUNCTION(usb_fs2_oe_n),
FUNCTION(vfe),
FUNCTION(vsens_alarm),
+   FUNCTION(ebi2),
 };
 
 static const struct msm_pingroup msm8660_groups[] = {
@@ -791,8 +801,8 @@ static const struct msm_pingroup msm8660_groups[] = {
PINGROUP(36, gsbi1, _, _, _, _, _, _),
PINGROUP(37, gsbi2, _, _, _, _, _, _),
PINGROUP(38, gsbi2, _, _, _, _, _, _),
-   PINGROUP(39, gsbi2, _, mdp_vsync, _, _, _, _),
-   PINGROUP(40, gsbi2, _, _, _, _, _, _),
+   PINGROUP(39, gsbi2, ebi2, mdp_vsync, _, _, _, _),
+   PINGROUP(40, gsbi2, ebi2, _, _, _, _, _),
PINGROUP(41, gsbi3, mdp_vsync, _, _, _, _, _),
PINGROUP(42, gsbi3, vfe, _, _, _, _, _),
PINGROUP(43, gsbi3, _, _, _, _, _, _),
@@ -875,41 +885,41 @@ static const struct msm_pingroup msm8660_groups[] = {
PINGROUP(120, i2s, _, _, _, _, _, _),
PINGROUP(121, i2s, _, _, _, _, _, _),
PINGROUP(122, i2s, gp_clk_1b, _, _, _, _, _),
-   PINGROUP(123, _, gsbi2_spi_cs1_n, _, _, _, _, _),
-   PINGROUP(124, _, gsbi2_spi_cs2_n, _, _, _, _, _),
-   PINGROUP(125, _, gsbi2_spi_cs3_n, _, _, _, _, _),
-   PINGROUP(126, _, _, _, _, _, _, _),
-   PINGROUP(127, _, vsens_alarm, _, _, _, _, _),
-   PINGROUP(128, _, _, _, _, _, _, _),
-   PINGROUP(129, _, _, _, _, _, _, _),
-   PINGROUP(130, _, _, _, _, _, _, _),
+   PINGROUP(123, ebi2, gsbi2_spi_cs1_n, _, _, _, _, _),
+   PINGROUP(124, ebi2, gsbi2_spi_cs2_n, _, _, _, _, _),
+   PINGROUP(125, ebi2, gsbi2_spi_cs3_n, _, _, _, _, _),
+   PINGROUP(126, ebi2, _, _, _, _, _, _),
+   PINGROUP(127, ebi2, vsens_alarm, _, _, _, _, _),
+   PINGROUP(128, ebi2, _, _, _, _, _, _),
+   PINGROUP(129, ebi2, _, _, _, _, _, _),
+   PINGROUP(130, ebi2, _, _, _, _, _, _),
PINGROUP(131, _, _, _, _, _, _, _),
-   PINGROUP(132, _, _, _, _, _, _, _),
-   PINGROUP(133, _, _, _, _, _, _, _),
+   PINGROUP(132, ebi2, _, _, _, _, _, _),
+   PINGROUP(133, ebi2, _, _, _, _, _, _),
PINGROUP(134, _, _, _, _, _, _, _),
-   PINGROUP(135, _, _, _, _, _, _, _),
-   PINGROUP(136, _, _, _, _, _, _, _),
-   PINGROUP(137, _, _, _, _, _, _, _),
-   PINGROUP(138, _, _, _, _, _, _, _),
-   PINGROUP(139, _, _, _, _, _, _, _),
-   PINGROUP(140, _, _, _, _, _, _, _),
-   PINGROUP(141, _, _, _, _, _, _, _),
-   PINGROUP(142, _, _, _, _, _, _, _),
-   PINGROUP(143, _, sdc2, _, _, _, _, _),
-   PINGROUP(144, _, sdc2, _, _, _, _, _),
-   PINGROUP(145, _, sdc2, _, _, _, _, _),
-   PINGROUP(146, _, sdc2, _, _, _, _, _),
-   PINGROUP(147, _, sdc2, _, _, _, _, _),
-   PINGROUP(148, _, sdc2, _, _, _, _, _),
-   PINGROUP(149, _, sdc2, _, _, _, _, _),
-   PINGROUP(150, _, sdc2, _, _, _, _, _),
-   PINGROUP(151, _, sdc2, _, _, _, _, _),
+   PINGROUP(135, ebi2, _, _, _, _, _, _),
+   PINGROUP(136, ebi2, _, _, _, _, _, _),
+   PINGROUP(137, ebi2, _, _, 

[PATCH v2] pinctrl: qcom: add support for EBI2

[Linus Walleij]

Add support to mux in the second external bus interface as
follows:

- CS1 and CS2 on GPIO39 and GPIO40 as func 2
- ADDR_7 thru ADDR_0 on GPIO123 thru GPIO130 as func 1
- CS4, CS3 and CS0 on GPIO132, GPIO133, GPIO134 as func 1
- DATA_15 thru DATA_0 on GPIO135 thru GPIO150 as func 1
- OE on GPIO151 as func 1
- ADV on GPIO153 as func 1
- WE on GPIO157 as func 1

This external bus is used on the APQ8060 Dragonboard to connect
an external SMSC9211 ethernet adapter, but there are many other
usecases for the EBI2.

Cc: Stephen Boyd 
Cc: Bjorn Andersson 
Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Pick out the exact right pin assignments from the old codebase.
---
 drivers/pinctrl/qcom/pinctrl-msm8660.c | 72 +++---
 1 file changed, 41 insertions(+), 31 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-msm8660.c 
b/drivers/pinctrl/qcom/pinctrl-msm8660.c
index 3e8f7ac2ac8a..debc90101553 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm8660.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm8660.c
@@ -506,6 +506,7 @@ enum msm8660_functions {
MSM_MUX_usb_fs2_oe_n,
MSM_MUX_vfe,
MSM_MUX_vsens_alarm,
+   MSM_MUX_ebi2,
MSM_MUX__,
 };
 
@@ -696,6 +697,14 @@ static const char * const vfe_groups[] = {
 static const char * const vsens_alarm_groups[] = {
"gpio127"
 };
+static const char * const ebi2_groups[] = {
+   "gpio39", "gpio40", "gpio123", "gpio124", "gpio125", "gpio126",
+   "gpio127", "gpio128", "gpio129", "gpio130", "gpio132", "gpio133",
+   "gpio134", "gpio135", "gpio136", "gpio137", "gpio138", "gpio139"
+   "gpio140", "gpio141", "gpio142", "gpio143", "gpio144", "gpio145",
+   "gpio146", "gpio147", "gpio148", "gpio149", "gpio150", "gpio151",
+   "gpio153", "gpio157"
+};
 
 static const struct msm_function msm8660_functions[] = {
FUNCTION(gpio),
@@ -749,6 +758,7 @@ static const struct msm_function msm8660_functions[] = {
FUNCTION(usb_fs2_oe_n),
FUNCTION(vfe),
FUNCTION(vsens_alarm),
+   FUNCTION(ebi2),
 };
 
 static const struct msm_pingroup msm8660_groups[] = {
@@ -791,8 +801,8 @@ static const struct msm_pingroup msm8660_groups[] = {
PINGROUP(36, gsbi1, _, _, _, _, _, _),
PINGROUP(37, gsbi2, _, _, _, _, _, _),
PINGROUP(38, gsbi2, _, _, _, _, _, _),
-   PINGROUP(39, gsbi2, _, mdp_vsync, _, _, _, _),
-   PINGROUP(40, gsbi2, _, _, _, _, _, _),
+   PINGROUP(39, gsbi2, ebi2, mdp_vsync, _, _, _, _),
+   PINGROUP(40, gsbi2, ebi2, _, _, _, _, _),
PINGROUP(41, gsbi3, mdp_vsync, _, _, _, _, _),
PINGROUP(42, gsbi3, vfe, _, _, _, _, _),
PINGROUP(43, gsbi3, _, _, _, _, _, _),
@@ -875,41 +885,41 @@ static const struct msm_pingroup msm8660_groups[] = {
PINGROUP(120, i2s, _, _, _, _, _, _),
PINGROUP(121, i2s, _, _, _, _, _, _),
PINGROUP(122, i2s, gp_clk_1b, _, _, _, _, _),
-   PINGROUP(123, _, gsbi2_spi_cs1_n, _, _, _, _, _),
-   PINGROUP(124, _, gsbi2_spi_cs2_n, _, _, _, _, _),
-   PINGROUP(125, _, gsbi2_spi_cs3_n, _, _, _, _, _),
-   PINGROUP(126, _, _, _, _, _, _, _),
-   PINGROUP(127, _, vsens_alarm, _, _, _, _, _),
-   PINGROUP(128, _, _, _, _, _, _, _),
-   PINGROUP(129, _, _, _, _, _, _, _),
-   PINGROUP(130, _, _, _, _, _, _, _),
+   PINGROUP(123, ebi2, gsbi2_spi_cs1_n, _, _, _, _, _),
+   PINGROUP(124, ebi2, gsbi2_spi_cs2_n, _, _, _, _, _),
+   PINGROUP(125, ebi2, gsbi2_spi_cs3_n, _, _, _, _, _),
+   PINGROUP(126, ebi2, _, _, _, _, _, _),
+   PINGROUP(127, ebi2, vsens_alarm, _, _, _, _, _),
+   PINGROUP(128, ebi2, _, _, _, _, _, _),
+   PINGROUP(129, ebi2, _, _, _, _, _, _),
+   PINGROUP(130, ebi2, _, _, _, _, _, _),
PINGROUP(131, _, _, _, _, _, _, _),
-   PINGROUP(132, _, _, _, _, _, _, _),
-   PINGROUP(133, _, _, _, _, _, _, _),
+   PINGROUP(132, ebi2, _, _, _, _, _, _),
+   PINGROUP(133, ebi2, _, _, _, _, _, _),
PINGROUP(134, _, _, _, _, _, _, _),
-   PINGROUP(135, _, _, _, _, _, _, _),
-   PINGROUP(136, _, _, _, _, _, _, _),
-   PINGROUP(137, _, _, _, _, _, _, _),
-   PINGROUP(138, _, _, _, _, _, _, _),
-   PINGROUP(139, _, _, _, _, _, _, _),
-   PINGROUP(140, _, _, _, _, _, _, _),
-   PINGROUP(141, _, _, _, _, _, _, _),
-   PINGROUP(142, _, _, _, _, _, _, _),
-   PINGROUP(143, _, sdc2, _, _, _, _, _),
-   PINGROUP(144, _, sdc2, _, _, _, _, _),
-   PINGROUP(145, _, sdc2, _, _, _, _, _),
-   PINGROUP(146, _, sdc2, _, _, _, _, _),
-   PINGROUP(147, _, sdc2, _, _, _, _, _),
-   PINGROUP(148, _, sdc2, _, _, _, _, _),
-   PINGROUP(149, _, sdc2, _, _, _, _, _),
-   PINGROUP(150, _, sdc2, _, _, _, _, _),
-   PINGROUP(151, _, sdc2, _, _, _, _, _),
+   PINGROUP(135, ebi2, _, _, _, _, _, _),
+   PINGROUP(136, ebi2, _, _, _, _, _, _),
+   PINGROUP(137, ebi2, _, _, _, _, _, _),
+   PINGROUP(138, ebi2, _, _, _, _, _, _),
+   

Re: [PATCH RFC] sched: Make wake_up_nohz_cpu() handle CPUs going offline

[Frederic Weisbecker]

On Fri, Jul 01, 2016 at 11:40:54AM -0700, Paul E. McKenney wrote:
> On Fri, Jul 01, 2016 at 01:29:59AM +0200, Frederic Weisbecker wrote:
> > > +/*
> > > + * Wake up the specified CPU.  If the CPU is going offline, it is the
> > > + * caller's responsibility to deal with the lost wakeup, for example,
> > > + * by hooking into the CPU_DEAD notifier like timers and hrtimers do.
> > > + */
> > >  void wake_up_nohz_cpu(int cpu)
> > >  {
> > > - if (!wake_up_full_nohz_cpu(cpu))
> > > + if (cpu_online(cpu) && !wake_up_full_nohz_cpu(cpu))
> > 
> > So at this point, as we passed CPU_DYING, I believe the CPU isn't visible 
> > in the domains
> > anymore (correct me if I'm wrong), therefore get_nohz_timer_target() can't 
> > return it,
> > unless smp_processor_id() is the only alternative.
> 
> Right, but the timers have been posted long before even CPU_UP_PREPARE.
> From what I can see, they are left alone until CPU_DEAD.  Which means
> that if you try to mod_timer() them between CPU_DYING and CPU_DEAD,
> you can get the above splat.
> 
> Or am I missing somthing subtle here?

Yes that's exactly what I meant. It happens on mod_timer() calls
between CPU_DYING and CPU_DEAD. I just wanted to clarify the
conditions for it to happen: the fact that it shouldn't concern
remote CPU targets, only local pinned timers.

> > Hence, that call to wake_up_nohz_cpu() can only happen to online CPUs or 
> > the current
> > one (pinned). And wake_up_idle_cpu() on the current CPU is a no-op. So only
> > wake_up_full_nohz_cpu() is concerned. Then perhaps it would be better to 
> > move that
> > cpu_online() check to wake_up_full_nohz_cpu() ?
> 
> As in the patch shown below?  Either way works for me.

Hmm, the patch doesn't seem to be different than the previous one :-)

> 
> > BTW, it seems that rcutorture stops its kthreads after CPU_DYING, is it 
> > expected that
> > it queues timers at this stage?
> 
> Hmmm...  From what I can see, rcutorture cleans up its priority-boost
> kthreads at CPU_DOWN_PREPARE time.  The other threads are allowed to
> migrate wherever the scheduler wants, give or take the task shuffling.
> The task shuffling only excludes one CPU at a time, and I have seen
> this occur when multiple CPUs were running, e.g., 0, 2, and 3 while
> offlining 1.

But if rcutorture kthreads are cleaned up at CPU_DOWN_PREPARE, they
shouldn't be calling mod_timer() on CPU_DYING time. Or there are other
rcutorture threads?

> 
> Besides which, doesn't the scheduler prevent anything but the idle
> thread from running after CPU_DYING time?

Indeed migrate_tasks() is called on CPU_DYING but pinned kthreads, outside
smpboot, have their own way to deal with hotplug through notifiers.

Thanks.

> 
>   Thanx, Paul
> 
> 
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 7f2cae4620c7..08502966e7df 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -590,9 +590,14 @@ static bool wake_up_full_nohz_cpu(int cpu)
>   return false;
>  }
>  
> +/*
> + * Wake up the specified CPU.  If the CPU is going offline, it is the
> + * caller's responsibility to deal with the lost wakeup, for example,
> + * by hooking into the CPU_DEAD notifier like timers and hrtimers do.
> + */
>  void wake_up_nohz_cpu(int cpu)
>  {
> - if (!wake_up_full_nohz_cpu(cpu))
> + if (cpu_online(cpu) && !wake_up_full_nohz_cpu(cpu))
>   wake_up_idle_cpu(cpu);
>  }
>  
> 

Re: [PATCH RFC] sched: Make wake_up_nohz_cpu() handle CPUs going offline

[Frederic Weisbecker]

On Fri, Jul 01, 2016 at 11:40:54AM -0700, Paul E. McKenney wrote:
> On Fri, Jul 01, 2016 at 01:29:59AM +0200, Frederic Weisbecker wrote:
> > > +/*
> > > + * Wake up the specified CPU.  If the CPU is going offline, it is the
> > > + * caller's responsibility to deal with the lost wakeup, for example,
> > > + * by hooking into the CPU_DEAD notifier like timers and hrtimers do.
> > > + */
> > >  void wake_up_nohz_cpu(int cpu)
> > >  {
> > > - if (!wake_up_full_nohz_cpu(cpu))
> > > + if (cpu_online(cpu) && !wake_up_full_nohz_cpu(cpu))
> > 
> > So at this point, as we passed CPU_DYING, I believe the CPU isn't visible 
> > in the domains
> > anymore (correct me if I'm wrong), therefore get_nohz_timer_target() can't 
> > return it,
> > unless smp_processor_id() is the only alternative.
> 
> Right, but the timers have been posted long before even CPU_UP_PREPARE.
> From what I can see, they are left alone until CPU_DEAD.  Which means
> that if you try to mod_timer() them between CPU_DYING and CPU_DEAD,
> you can get the above splat.
> 
> Or am I missing somthing subtle here?

Yes that's exactly what I meant. It happens on mod_timer() calls
between CPU_DYING and CPU_DEAD. I just wanted to clarify the
conditions for it to happen: the fact that it shouldn't concern
remote CPU targets, only local pinned timers.

> > Hence, that call to wake_up_nohz_cpu() can only happen to online CPUs or 
> > the current
> > one (pinned). And wake_up_idle_cpu() on the current CPU is a no-op. So only
> > wake_up_full_nohz_cpu() is concerned. Then perhaps it would be better to 
> > move that
> > cpu_online() check to wake_up_full_nohz_cpu() ?
> 
> As in the patch shown below?  Either way works for me.

Hmm, the patch doesn't seem to be different than the previous one :-)

> 
> > BTW, it seems that rcutorture stops its kthreads after CPU_DYING, is it 
> > expected that
> > it queues timers at this stage?
> 
> Hmmm...  From what I can see, rcutorture cleans up its priority-boost
> kthreads at CPU_DOWN_PREPARE time.  The other threads are allowed to
> migrate wherever the scheduler wants, give or take the task shuffling.
> The task shuffling only excludes one CPU at a time, and I have seen
> this occur when multiple CPUs were running, e.g., 0, 2, and 3 while
> offlining 1.

But if rcutorture kthreads are cleaned up at CPU_DOWN_PREPARE, they
shouldn't be calling mod_timer() on CPU_DYING time. Or there are other
rcutorture threads?

> 
> Besides which, doesn't the scheduler prevent anything but the idle
> thread from running after CPU_DYING time?

Indeed migrate_tasks() is called on CPU_DYING but pinned kthreads, outside
smpboot, have their own way to deal with hotplug through notifiers.

Thanks.

> 
>   Thanx, Paul
> 
> 
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 7f2cae4620c7..08502966e7df 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -590,9 +590,14 @@ static bool wake_up_full_nohz_cpu(int cpu)
>   return false;
>  }
>  
> +/*
> + * Wake up the specified CPU.  If the CPU is going offline, it is the
> + * caller's responsibility to deal with the lost wakeup, for example,
> + * by hooking into the CPU_DEAD notifier like timers and hrtimers do.
> + */
>  void wake_up_nohz_cpu(int cpu)
>  {
> - if (!wake_up_full_nohz_cpu(cpu))
> + if (cpu_online(cpu) && !wake_up_full_nohz_cpu(cpu))
>   wake_up_idle_cpu(cpu);
>  }
>  
> 

[PATCH 3/4] tracing: Use __get_str() when manipulating strings

[Daniel Bristot de Oliveira]

Use __get_str(str) rather than __get_dynamic_array(str) when
deadling with strings.

It is just a code cleanup, no changes on tracepoint ABI.

Suggested-by: Steven Rostedt 
Signed-off-by: Daniel Bristot de Oliveira 
Reviewed-by: Steven Rostedt 
Cc: Trond Myklebust 
Cc: Anna Schumaker 
Cc: Steven Rostedt 
Cc: Ingo Molnar 
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

---
 fs/nfs/nfs4trace.h| 4 ++--
 fs/nfs/nfstrace.h | 4 ++--
 include/trace/events/printk.h | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/fs/nfs/nfs4trace.h b/fs/nfs/nfs4trace.h
index 2c8d05d..adec59a 100644
--- a/fs/nfs/nfs4trace.h
+++ b/fs/nfs/nfs4trace.h
@@ -1235,8 +1235,8 @@ DECLARE_EVENT_CLASS(nfs4_idmap_event,
len = 0;
__entry->error = error < 0 ? error : 0;
__entry->id = id;
-   memcpy(__get_dynamic_array(name), name, len);
-   ((char *)__get_dynamic_array(name))[len] = 0;
+   memcpy(__get_str(name), name, len);
+   __get_str(name)[len] = 0;
),
 
TP_printk(
diff --git a/fs/nfs/nfstrace.h b/fs/nfs/nfstrace.h
index 9f80a08..32ff934 100644
--- a/fs/nfs/nfstrace.h
+++ b/fs/nfs/nfstrace.h
@@ -707,9 +707,9 @@ TRACE_EVENT(nfs_sillyrename_unlink,
__entry->dev = dir->i_sb->s_dev;
__entry->dir = NFS_FILEID(dir);
__entry->error = error;
-   memcpy(__get_dynamic_array(name),
+   memcpy(__get_str(name),
data->args.name.name, len);
-   ((char *)__get_dynamic_array(name))[len] = 0;
+   __get_str(name)[len] = 0;
),
 
TP_printk(
diff --git a/include/trace/events/printk.h b/include/trace/events/printk.h
index c008bc9..542a755 100644
--- a/include/trace/events/printk.h
+++ b/include/trace/events/printk.h
@@ -16,8 +16,8 @@ TRACE_EVENT(console,
),
 
TP_fast_assign(
-   memcpy(__get_dynamic_array(msg), text, len);
-   ((char *)__get_dynamic_array(msg))[len] = 0;
+   memcpy(__get_str(msg), text, len);
+   __get_str(msg)[len] = 0;
),
 
TP_printk("%s", __get_str(msg))
-- 
2.7.4

[PATCH 3/4] tracing: Use __get_str() when manipulating strings

[Daniel Bristot de Oliveira]

Use __get_str(str) rather than __get_dynamic_array(str) when
deadling with strings.

It is just a code cleanup, no changes on tracepoint ABI.

Suggested-by: Steven Rostedt 
Signed-off-by: Daniel Bristot de Oliveira 
Reviewed-by: Steven Rostedt 
Cc: Trond Myklebust 
Cc: Anna Schumaker 
Cc: Steven Rostedt 
Cc: Ingo Molnar 
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

---
 fs/nfs/nfs4trace.h| 4 ++--
 fs/nfs/nfstrace.h | 4 ++--
 include/trace/events/printk.h | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/fs/nfs/nfs4trace.h b/fs/nfs/nfs4trace.h
index 2c8d05d..adec59a 100644
--- a/fs/nfs/nfs4trace.h
+++ b/fs/nfs/nfs4trace.h
@@ -1235,8 +1235,8 @@ DECLARE_EVENT_CLASS(nfs4_idmap_event,
len = 0;
__entry->error = error < 0 ? error : 0;
__entry->id = id;
-   memcpy(__get_dynamic_array(name), name, len);
-   ((char *)__get_dynamic_array(name))[len] = 0;
+   memcpy(__get_str(name), name, len);
+   __get_str(name)[len] = 0;
),
 
TP_printk(
diff --git a/fs/nfs/nfstrace.h b/fs/nfs/nfstrace.h
index 9f80a08..32ff934 100644
--- a/fs/nfs/nfstrace.h
+++ b/fs/nfs/nfstrace.h
@@ -707,9 +707,9 @@ TRACE_EVENT(nfs_sillyrename_unlink,
__entry->dev = dir->i_sb->s_dev;
__entry->dir = NFS_FILEID(dir);
__entry->error = error;
-   memcpy(__get_dynamic_array(name),
+   memcpy(__get_str(name),
data->args.name.name, len);
-   ((char *)__get_dynamic_array(name))[len] = 0;
+   __get_str(name)[len] = 0;
),
 
TP_printk(
diff --git a/include/trace/events/printk.h b/include/trace/events/printk.h
index c008bc9..542a755 100644
--- a/include/trace/events/printk.h
+++ b/include/trace/events/printk.h
@@ -16,8 +16,8 @@ TRACE_EVENT(console,
),
 
TP_fast_assign(
-   memcpy(__get_dynamic_array(msg), text, len);
-   ((char *)__get_dynamic_array(msg))[len] = 0;
+   memcpy(__get_str(msg), text, len);
+   __get_str(msg)[len] = 0;
),
 
TP_printk("%s", __get_str(msg))
-- 
2.7.4

[PATCH 2/4] tracing, RAS: Cleanup on __get_str() usage

[Daniel Bristot de Oliveira]

__get_str(msg) does not need (char *) operator overloading to access
mgs's elements anymore. This patch substitutes
((char *)__get_str(msg))[0] usage to __get_str(msg)[0].

It is just a code cleanup, no changes on tracepoint ABI.

Signed-off-by: Daniel Bristot de Oliveira 
Reviewed-by: Steven Rostedt 
Cc: Steven Rostedt 
Cc: Ingo Molnar 
Cc: linux-kernel@vger.kernel.org
---
 include/ras/ras_event.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
index 1443d79..1791a12 100644
--- a/include/ras/ras_event.h
+++ b/include/ras/ras_event.h
@@ -147,7 +147,7 @@ TRACE_EVENT(mc_event,
  __entry->error_count,
  mc_event_error_type(__entry->error_type),
  __entry->error_count > 1 ? "s" : "",
- ((char *)__get_str(msg))[0] ? " " : "",
+ __get_str(msg)[0] ? " " : "",
  __get_str(msg),
  __get_str(label),
  __entry->mc_index,
@@ -157,7 +157,7 @@ TRACE_EVENT(mc_event,
  __entry->address,
  1 << __entry->grain_bits,
  __entry->syndrome,
- ((char *)__get_str(driver_detail))[0] ? " " : "",
+ __get_str(driver_detail)[0] ? " " : "",
  __get_str(driver_detail))
 );
 
-- 
2.7.4

[PATCH 0/4] tracing: printk:console fix and __get_str() cleanup

[Daniel Bristot de Oliveira]

This patch series fixes a problem on printk:console tracepoint
that prints a blank line in the trace output after each printk
message that finishes with '\n'.

It also does some cleanup on __get_str() usage, that
was found while fixing the printk:console tracepoint.

Daniel Bristot de Oliveira (4):
  tracing: Use outer () on __get_str() definition
  tracing, RAS: Cleanup on __get_str() usage
  tracing: Use __get_str() when manipulating strings
  printk, tracing: Avoiding unneeded blank lines

 fs/nfs/nfs4trace.h|  4 ++--
 fs/nfs/nfstrace.h |  4 ++--
 include/ras/ras_event.h   |  4 ++--
 include/trace/events/printk.h | 12 ++--
 include/trace/perf.h  |  2 +-
 include/trace/trace_events.h  |  2 +-
 6 files changed, 18 insertions(+), 10 deletions(-)

-- 
2.7.4

[PATCH 4/4] printk, tracing: Avoiding unneeded blank lines

[Daniel Bristot de Oliveira]

Printk messages often finish with '\n' to cause a new line.
But as each tracepoint is already printed in a new line,
printk messages that finish with '\n' ends up adding a blank
line to the trace output. For example:

 kworker/0:1-86[000] d...46.006949: console: [   46.006946] usb 
1-3: USB disconnect, device number 3

 kworker/2:2-374   [002] d...48.699342: console: [   48.699339] usb 
1-3: new high-speed USB device number 4 using ehci-pci

 kworker/2:2-374   [002] d...49.041450: console: [   49.041448] usb 
1-3: New USB device found, idVendor=5986, idProduct=0

To avoid unneeded blank lines, this patch checks if the printk
message finishes with '\n', if so, it cut is off the '\n' to
avoid blank lines.

In a patched kernel, the same messages are printed without
extra blank lines. For example:

 kworker/0:4-185   [000] d...23.641738: console: [   23.641736] usb 
1-3: USB disconnect, device number 3
 kworker/0:4-185   [000] d...24.918703: console: [   24.918700] usb 
1-3: new high-speed USB device number 4 using ehci-pci
 kworker/0:4-185   [000] d...25.228308: console: [   25.228306] usb 
1-3: New USB device found, idVendor=5986, idProduct=02d5


Signed-off-by: Daniel Bristot de Oliveira 
Reviewed-by: Steven Rostedt 
Cc: Steven Rostedt 
Cc: Ingo Molnar 
Cc: linux-kernel@vger.kernel.org
---
 include/trace/events/printk.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/trace/events/printk.h b/include/trace/events/printk.h
index 542a755..bc9139d29 100644
--- a/include/trace/events/printk.h
+++ b/include/trace/events/printk.h
@@ -16,6 +16,14 @@ TRACE_EVENT(console,
),
 
TP_fast_assign(
+   /*
+* Each trace entry is printed in a new line.
+* If the msg finishes with '\n', cut it off
+* to avoid blank lines in the trace.
+*/
+   if ((len > 0) && (text[len-1] == '\n'))
+   len -= 1;
+
memcpy(__get_str(msg), text, len);
__get_str(msg)[len] = 0;
),
-- 
2.7.4

[PATCH 1/4] tracing: Use outer () on __get_str() definition

[Daniel Bristot de Oliveira]

__get_str(str)'s definition includes a (char *) operator
overloading that is not protected with outer ().

This patch adds () around __get_str()'s definition, enabling
some code cleanup.

Suggested-by: Steven Rostedt 
Signed-off-by: Daniel Bristot de Oliveira 
Reviewed-by: Steven Rostedt 
Cc: Steven Rostedt 
Cc: Ingo Molnar 
Cc: linux-kernel@vger.kernel.org
---
 include/trace/perf.h | 2 +-
 include/trace/trace_events.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/trace/perf.h b/include/trace/perf.h
index 26486fc..7144550 100644
--- a/include/trace/perf.h
+++ b/include/trace/perf.h
@@ -15,7 +15,7 @@
((__entry->__data_loc_##field >> 16) & 0x)
 
 #undef __get_str
-#define __get_str(field) (char *)__get_dynamic_array(field)
+#define __get_str(field) ((char *)__get_dynamic_array(field))
 
 #undef __get_bitmask
 #define __get_bitmask(field) (char *)__get_dynamic_array(field)
diff --git a/include/trace/trace_events.h b/include/trace/trace_events.h
index 170c93b..427e4aa 100644
--- a/include/trace/trace_events.h
+++ b/include/trace/trace_events.h
@@ -256,7 +256,7 @@ TRACE_MAKE_SYSTEM_STR();
((__entry->__data_loc_##field >> 16) & 0x)
 
 #undef __get_str
-#define __get_str(field) (char *)__get_dynamic_array(field)
+#define __get_str(field) ((char *)__get_dynamic_array(field))
 
 #undef __get_bitmask
 #define __get_bitmask(field)   \
-- 
2.7.4

[PATCH 2/4] tracing, RAS: Cleanup on __get_str() usage

[Daniel Bristot de Oliveira]

__get_str(msg) does not need (char *) operator overloading to access
mgs's elements anymore. This patch substitutes
((char *)__get_str(msg))[0] usage to __get_str(msg)[0].

It is just a code cleanup, no changes on tracepoint ABI.

Signed-off-by: Daniel Bristot de Oliveira 
Reviewed-by: Steven Rostedt 
Cc: Steven Rostedt 
Cc: Ingo Molnar 
Cc: linux-kernel@vger.kernel.org
---
 include/ras/ras_event.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
index 1443d79..1791a12 100644
--- a/include/ras/ras_event.h
+++ b/include/ras/ras_event.h
@@ -147,7 +147,7 @@ TRACE_EVENT(mc_event,
  __entry->error_count,
  mc_event_error_type(__entry->error_type),
  __entry->error_count > 1 ? "s" : "",
- ((char *)__get_str(msg))[0] ? " " : "",
+ __get_str(msg)[0] ? " " : "",
  __get_str(msg),
  __get_str(label),
  __entry->mc_index,
@@ -157,7 +157,7 @@ TRACE_EVENT(mc_event,
  __entry->address,
  1 << __entry->grain_bits,
  __entry->syndrome,
- ((char *)__get_str(driver_detail))[0] ? " " : "",
+ __get_str(driver_detail)[0] ? " " : "",
  __get_str(driver_detail))
 );
 
-- 
2.7.4

[PATCH 0/4] tracing: printk:console fix and __get_str() cleanup

[Daniel Bristot de Oliveira]

This patch series fixes a problem on printk:console tracepoint
that prints a blank line in the trace output after each printk
message that finishes with '\n'.

It also does some cleanup on __get_str() usage, that
was found while fixing the printk:console tracepoint.

Daniel Bristot de Oliveira (4):
  tracing: Use outer () on __get_str() definition
  tracing, RAS: Cleanup on __get_str() usage
  tracing: Use __get_str() when manipulating strings
  printk, tracing: Avoiding unneeded blank lines

 fs/nfs/nfs4trace.h|  4 ++--
 fs/nfs/nfstrace.h |  4 ++--
 include/ras/ras_event.h   |  4 ++--
 include/trace/events/printk.h | 12 ++--
 include/trace/perf.h  |  2 +-
 include/trace/trace_events.h  |  2 +-
 6 files changed, 18 insertions(+), 10 deletions(-)

-- 
2.7.4