Re: [PATCH v4 0/2] driver: thermal: Move some drivers into subdirs

2018-12-07 Thread Zhang Rui
applied. But please do remember to send the patches to linux-pm mailing
list next time so that I can catch them via patchwork.

thanks,
rui

On 五, 2018-12-07 at 12:25 +0530, Amit Kucheria wrote:
> (Apologies for the build failure. My scripts to enable these configs
> and
> build-test them failed. They've been fixed now)
> 
> Move the various drivers for Intel platforms into their own subdir.
> Also
> consolidate Qualcomm drivers into the qcom subdir.
> 
> This cleans up the directory making it easier to find things.
> 
> There is no great time to send patches that move files around. So
> here's an
> attempt to sneak it into 4.21 before everything else.
> 
> This was generated and compile-tested against 4.20-rc4. If you would
> like
> me to try again a bit later, I'm happy to do so.
> 
> Changes since v3:
> - Fix build failure on QCOM_SPMI_TEMP_ALARM
> 
> Changes since v2:
> - Rebased on top of 4.20-rc4
> 
> Changes since v1:
> - Removed a stray character that snuck into the Makefile
> - Added Acks
> - Rebased to v4.19-rc6
> 
> 
> Amit Kucheria (2):
>   drivers: thermal: Move various drivers for intel platforms into a
> subdir
>   drivers: thermal: Move QCOM_SPMI_TEMP_ALARM into the qcom subdir
> 
>  drivers/thermal/Kconfig   | 94 +--
> 
>  drivers/thermal/Makefile  | 10 +-
>  drivers/thermal/intel/Kconfig | 77 +++
>  drivers/thermal/intel/Makefile| 12 +++
>  .../{ => intel}/int340x_thermal/Kconfig   |  0
>  .../{ => intel}/int340x_thermal/Makefile  |  0
>  .../int340x_thermal/acpi_thermal_rel.c|  0
>  .../int340x_thermal/acpi_thermal_rel.h|  0
>  .../int340x_thermal/int3400_thermal.c |  0
>  .../int340x_thermal/int3402_thermal.c |  0
>  .../int340x_thermal/int3403_thermal.c |  0
>  .../int340x_thermal/int3406_thermal.c |  0
>  .../int340x_thermal/int340x_thermal_zone.c|  0
>  .../int340x_thermal/int340x_thermal_zone.h|  0
>  .../processor_thermal_device.c|  0
>  .../{ => intel}/intel_bxt_pmic_thermal.c  |  0
>  .../thermal/{ => intel}/intel_pch_thermal.c   |  0
>  .../thermal/{ => intel}/intel_powerclamp.c|  0
>  .../{ => intel}/intel_quark_dts_thermal.c |  0
>  .../thermal/{ => intel}/intel_soc_dts_iosf.c  |  0
>  .../thermal/{ => intel}/intel_soc_dts_iosf.h  |  0
>  .../{ => intel}/intel_soc_dts_thermal.c   |  0
>  .../{ => intel}/x86_pkg_temp_thermal.c|  0
>  drivers/thermal/qcom/Kconfig  | 11 +++
>  drivers/thermal/qcom/Makefile |  1 +
>  .../thermal/{ => qcom}/qcom-spmi-temp-alarm.c |  2 +-
>  26 files changed, 108 insertions(+), 99 deletions(-)
>  create mode 100644 drivers/thermal/intel/Kconfig
>  create mode 100644 drivers/thermal/intel/Makefile
>  rename drivers/thermal/{ => intel}/int340x_thermal/Kconfig (100%)
>  rename drivers/thermal/{ => intel}/int340x_thermal/Makefile (100%)
>  rename drivers/thermal/{ =>
> intel}/int340x_thermal/acpi_thermal_rel.c (100%)
>  rename drivers/thermal/{ =>
> intel}/int340x_thermal/acpi_thermal_rel.h (100%)
>  rename drivers/thermal/{ => intel}/int340x_thermal/int3400_thermal.c
> (100%)
>  rename drivers/thermal/{ => intel}/int340x_thermal/int3402_thermal.c
> (100%)
>  rename drivers/thermal/{ => intel}/int340x_thermal/int3403_thermal.c
> (100%)
>  rename drivers/thermal/{ => intel}/int340x_thermal/int3406_thermal.c
> (100%)
>  rename drivers/thermal/{ =>
> intel}/int340x_thermal/int340x_thermal_zone.c (100%)
>  rename drivers/thermal/{ =>
> intel}/int340x_thermal/int340x_thermal_zone.h (100%)
>  rename drivers/thermal/{ =>
> intel}/int340x_thermal/processor_thermal_device.c (100%)
>  rename drivers/thermal/{ => intel}/intel_bxt_pmic_thermal.c (100%)
>  rename drivers/thermal/{ => intel}/intel_pch_thermal.c (100%)
>  rename drivers/thermal/{ => intel}/intel_powerclamp.c (100%)
>  rename drivers/thermal/{ => intel}/intel_quark_dts_thermal.c (100%)
>  rename drivers/thermal/{ => intel}/intel_soc_dts_iosf.c (100%)
>  rename drivers/thermal/{ => intel}/intel_soc_dts_iosf.h (100%)
>  rename drivers/thermal/{ => intel}/intel_soc_dts_thermal.c (100%)
>  rename drivers/thermal/{ => intel}/x86_pkg_temp_thermal.c (100%)
>  rename drivers/thermal/{ => qcom}/qcom-spmi-temp-alarm.c (99%)
> 


Re: [PATCH v3 1/2] drivers: thermal: Move various drivers for intel platforms into a subdir

2018-12-05 Thread Zhang Rui
On 三, 2018-11-28 at 00:28 +0530, Amit Kucheria wrote:
> This cleans up the directory a bit, now that we have several other
> platforms using platform-specific sub-directories. Compile-tested
> with
> ARCH=x86 defconfig and the drivers explicitly enabled with
> menuconfig.
> 
> Signed-off-by: Amit Kucheria 
> Acked-by: Daniel Lezcano 
> ---
>  drivers/thermal/Kconfig   | 83 ++---
> --
>  drivers/thermal/Makefile  | 11 +--
>  drivers/thermal/intel/Kconfig | 77 +
>  drivers/thermal/intel/Makefile| 12 +++
>  .../{ => intel}/int340x_thermal/Kconfig   |  0
>  .../{ => intel}/int340x_thermal/Makefile  |  0
>  .../int340x_thermal/acpi_thermal_rel.c|  0
>  .../int340x_thermal/acpi_thermal_rel.h|  0
>  .../int340x_thermal/int3400_thermal.c |  0
>  .../int340x_thermal/int3402_thermal.c |  0
>  .../int340x_thermal/int3403_thermal.c |  0
>  .../int340x_thermal/int3406_thermal.c |  0
>  .../int340x_thermal/int340x_thermal_zone.c|  0
>  .../int340x_thermal/int340x_thermal_zone.h|  0
>  .../processor_thermal_device.c|  0
>  .../{ => intel}/intel_bxt_pmic_thermal.c  |  0
>  .../thermal/{ => intel}/intel_pch_thermal.c   |  0
>  .../thermal/{ => intel}/intel_powerclamp.c|  0
>  .../{ => intel}/intel_quark_dts_thermal.c |  0
>  .../thermal/{ => intel}/intel_soc_dts_iosf.c  |  0
>  .../thermal/{ => intel}/intel_soc_dts_iosf.h  |  0
>  .../{ => intel}/intel_soc_dts_thermal.c   |  0
>  .../{ => intel}/x86_pkg_temp_thermal.c|  0
>  23 files changed, 96 insertions(+), 87 deletions(-)
>  create mode 100644 drivers/thermal/intel/Kconfig
>  create mode 100644 drivers/thermal/intel/Makefile
>  rename drivers/thermal/{ => intel}/int340x_thermal/Kconfig (100%)
>  rename drivers/thermal/{ => intel}/int340x_thermal/Makefile (100%)
>  rename drivers/thermal/{ =>
> intel}/int340x_thermal/acpi_thermal_rel.c (100%)
>  rename drivers/thermal/{ =>
> intel}/int340x_thermal/acpi_thermal_rel.h (100%)
>  rename drivers/thermal/{ => intel}/int340x_thermal/int3400_thermal.c
> (100%)
>  rename drivers/thermal/{ => intel}/int340x_thermal/int3402_thermal.c
> (100%)
>  rename drivers/thermal/{ => intel}/int340x_thermal/int3403_thermal.c
> (100%)
>  rename drivers/thermal/{ => intel}/int340x_thermal/int3406_thermal.c
> (100%)
>  rename drivers/thermal/{ =>
> intel}/int340x_thermal/int340x_thermal_zone.c (100%)
>  rename drivers/thermal/{ =>
> intel}/int340x_thermal/int340x_thermal_zone.h (100%)
>  rename drivers/thermal/{ =>
> intel}/int340x_thermal/processor_thermal_device.c (100%)
>  rename drivers/thermal/{ => intel}/intel_bxt_pmic_thermal.c (100%)
>  rename drivers/thermal/{ => intel}/intel_pch_thermal.c (100%)
>  rename drivers/thermal/{ => intel}/intel_powerclamp.c (100%)
>  rename drivers/thermal/{ => intel}/intel_quark_dts_thermal.c (100%)
>  rename drivers/thermal/{ => intel}/intel_soc_dts_iosf.c (100%)
>  rename drivers/thermal/{ => intel}/intel_soc_dts_iosf.h (100%)
>  rename drivers/thermal/{ => intel}/intel_soc_dts_thermal.c (100%)
>  rename drivers/thermal/{ => intel}/x86_pkg_temp_thermal.c (100%)
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 5422523c03f8..772ab9dadda7 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -326,84 +326,6 @@ config DA9062_THERMAL
>     zone.
>     Compatible with the DA9062 and DA9061 PMICs.
>  
> -config INTEL_POWERCLAMP
> - tristate "Intel PowerClamp idle injection driver"
> - depends on THERMAL
> - depends on X86
> - depends on CPU_SUP_INTEL
> - help
> -   Enable this to enable Intel PowerClamp idle injection
> driver. This
> -   enforce idle time which results in more package C-state
> residency. The
> -   user interface is exposed via generic thermal framework.
> -
> -config X86_PKG_TEMP_THERMAL
> - tristate "X86 package temperature thermal driver"
> - depends on X86_THERMAL_VECTOR
> - select THERMAL_GOV_USER_SPACE
> - select THERMAL_WRITABLE_TRIPS
> - default m
> - help
> -   Enable this to register CPU digital sensor for package
> temperature as
> -   thermal zone. Each package will have its own thermal zone.
> There are
> -   two trip points which can be set by user to get
> notifications via thermal
> -   notification methods.
> -
> -config INTEL_SOC_DTS_IOSF_CORE
> - tristate
> - depends on X86 && PCI
> - select IOSF_MBI
> - help
> -   This is becoming a common feature for Intel SoCs to expose
> the additional
> -   digital temperature sensors (DTSs) using side band
> interface (IOSF). This
> -   implements the common set of helper functions to register,
> get temperature
> -   and get/set thresholds on DTSs.
> -
> -config INTEL_SOC_DTS_THERMAL
> - tristate "Intel SoCs DTS thermal driver"
> - depends on X86 && PCI && ACPI
> - 

Re: [PATCH 1/2] thermal/int340x_thermal: Add additional UUIDs

2018-12-03 Thread Zhang Rui
Hi, Matthew,

On 三, 2018-10-10 at 01:30 -0700, Matthew Garrett wrote:
> Platforms support more DPTF policies than the driver currently
> exposes.
> Add them. This effectively reverts
> 31908f45a583e8f21db37f402b6e8d5739945afd which removed several UUIDs
> without explaining why.
> 
I'm going to apply this patch series, just with two minor changes,
1. 31908f45a583e8f21db37f402b6e8d5739945afd does not follow the git
commit description style 'commit <12+ chars of sha1> ("")'
2. the UUIDs were removed previously because these policies were not
used.

thanks,
rui

> Signed-off-by: Matthew Garrett 
> Cc: Zhang Rui 
> Cc: Nisha Aram 
> ---
>  drivers/thermal/int340x_thermal/int3400_thermal.c | 14
> ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/thermal/int340x_thermal/int3400_thermal.c
> b/drivers/thermal/int340x_thermal/int3400_thermal.c
> index e26b01c05e82..51c9097eaf7a 100644
> --- a/drivers/thermal/int340x_thermal/int3400_thermal.c
> +++ b/drivers/thermal/int340x_thermal/int3400_thermal.c
> @@ -22,6 +22,13 @@ enum int3400_thermal_uuid {
>   INT3400_THERMAL_PASSIVE_1,
>   INT3400_THERMAL_ACTIVE,
>   INT3400_THERMAL_CRITICAL,
> + INT3400_THERMAL_ADAPTIVE_PERFORMANCE,
> + INT3400_THERMAL_EMERGENCY_CALL_MODE,
> + INT3400_THERMAL_PASSIVE_2,
> + INT3400_THERMAL_POWER_BOSS,
> + INT3400_THERMAL_VIRTUAL_SENSOR,
> + INT3400_THERMAL_COOLING_MODE,
> + INT3400_THERMAL_HARDWARE_DUTY_CYCLING,
>   INT3400_THERMAL_MAXIMUM_UUID,
>  };
>  
> @@ -29,6 +36,13 @@ static char
> *int3400_thermal_uuids[INT3400_THERMAL_MAXIMUM_UUID] = {
>   "42A441D6-AE6A-462b-A84B-4A8CE79027D3",
>   "3A95C389-E4B8-4629-A526-C52C88626BAE",
>   "97C68AE7-15FA-499c-B8C9-5DA81D606E0A",
> + "63BE270F-1C11-48FD-A6F7-3AF253FF3E2D",
> + "5349962F-71E6-431D-9AE8-0A635B710AEE",
> + "9E04115A-AE87-4D1C-9500-0F3E340BFE75",
> + "F5A35014-C209-46A4-993A-EB56DE7530A1",
> + "6ED722A7-9240-48A5-B479-31EEF723D7CF",
> + "16CAF1B7-DD38-40ED-B1C1-1B8A1913D531",
> + "BE84BABF-C4D4-403D-B495-3128FD44dAC1",
>  };
>  
>  struct int3400_thermal_priv {


Re: [PATCH v2 0/2] driver: thermal: Move some drivers into subdirs

2018-11-25 Thread Zhang Rui
On 五, 2018-11-23 at 00:17 +0530, Amit Kucheria wrote:
> On Fri, Oct 26, 2018 at 2:21 PM Amit Kucheria  rg> wrote:
> > 
> > 
> > Hi Rui,
> > 
> > On Thu, Oct 4, 2018 at 1:22 PM Amit Kucheria  > org> wrote:
> > > 
> > > 
> > > Move the various drivers for Intel platforms into their own
> > > subdir. Also
> > > consolidate Qualcomm drivers into the qcom subdir.
> > > 
> > > This cleans up the directory making it easier to find things.
> > Any comments on these changes?
> Rui? Eduardo?
> 
the patches were not sent to linux-pm mailing list, and that's why I
overlooked this patch set in patchwork.

thanks,
rui
> > 
> > > 
> > > There is no great time to send patches that move files around,
> > > but I'm told
> > > that towards the end of the merge window is nicer. So here's an
> > > attempt to
> > > sneak it into 4.20 after everything else and hoping that these
> > > files won't
> > > change after 4.19-rc6. :-)
> > > 
> > > This was generated and compile-tested against 4.19-rc6. If you
> > > would like
> > > me to try again a bit later, I'm happy to do so.
> > > 
> > > Changes since v1:
> > > - Removed a stray character that snuck into the Makefile
> > > - Added Acks
> > > - Rebased to v4.19-rc6
> > > 
> > > Amit Kucheria (2):
> > >   drivers: thermal: Move various drivers for intel platforms into
> > > a
> > > subdir
> > >   drivers: thermal: Move QCOM_SPMI_TEMP_ALARM into the qcom
> > > subdir
> > > 
> > >  drivers/thermal/Kconfig   | 94 +--
> > > 
> > >  drivers/thermal/Makefile  | 10 +-
> > >  drivers/thermal/intel/Kconfig | 77
> > > +++
> > >  drivers/thermal/intel/Makefile| 12 +++
> > >  .../{ => intel}/int340x_thermal/Kconfig   |  0
> > >  .../{ => intel}/int340x_thermal/Makefile  |  0
> > >  .../int340x_thermal/acpi_thermal_rel.c|  0
> > >  .../int340x_thermal/acpi_thermal_rel.h|  0
> > >  .../int340x_thermal/int3400_thermal.c |  0
> > >  .../int340x_thermal/int3402_thermal.c |  0
> > >  .../int340x_thermal/int3403_thermal.c |  0
> > >  .../int340x_thermal/int3406_thermal.c |  0
> > >  .../int340x_thermal/int340x_thermal_zone.c|  0
> > >  .../int340x_thermal/int340x_thermal_zone.h|  0
> > >  .../processor_thermal_device.c|  0
> > >  .../{ => intel}/intel_bxt_pmic_thermal.c  |  0
> > >  .../thermal/{ => intel}/intel_pch_thermal.c   |  0
> > >  .../thermal/{ => intel}/intel_powerclamp.c|  0
> > >  .../{ => intel}/intel_quark_dts_thermal.c |  0
> > >  .../thermal/{ => intel}/intel_soc_dts_iosf.c  |  0
> > >  .../thermal/{ => intel}/intel_soc_dts_iosf.h  |  0
> > >  .../{ => intel}/intel_soc_dts_thermal.c   |  0
> > >  .../{ => intel}/x86_pkg_temp_thermal.c|  0
> > >  drivers/thermal/qcom/Kconfig  | 11 +++
> > >  drivers/thermal/qcom/Makefile |  1 +
> > >  .../thermal/{ => qcom}/qcom-spmi-temp-alarm.c |  0
> > >  26 files changed, 107 insertions(+), 98 deletions(-)
> > >  create mode 100644 drivers/thermal/intel/Kconfig
> > >  create mode 100644 drivers/thermal/intel/Makefile
> > >  rename drivers/thermal/{ => intel}/int340x_thermal/Kconfig
> > > (100%)
> > >  rename drivers/thermal/{ => intel}/int340x_thermal/Makefile
> > > (100%)
> > >  rename drivers/thermal/{ =>
> > > intel}/int340x_thermal/acpi_thermal_rel.c (100%)
> > >  rename drivers/thermal/{ =>
> > > intel}/int340x_thermal/acpi_thermal_rel.h (100%)
> > >  rename drivers/thermal/{ =>
> > > intel}/int340x_thermal/int3400_thermal.c (100%)
> > >  rename drivers/thermal/{ =>
> > > intel}/int340x_thermal/int3402_thermal.c (100%)
> > >  rename drivers/thermal/{ =>
> > > intel}/int340x_thermal/int3403_thermal.c (100%)
> > >  rename drivers/thermal/{ =>
> > > intel}/int340x_thermal/int3406_thermal.c (100%)
> > >  rename drivers/thermal/{ =>
> > > intel}/int340x_thermal/int340x_thermal_zone.c (100%)
> > >  rename drivers/thermal/{ =>
> > > intel}/int340x_thermal/int340x_thermal_zone.h (100%)
> > >  rename drivers/thermal/{ =>
> > > intel}/int340x_thermal/processor_thermal_device.c (100%)
> > >  rename drivers/thermal/{ => intel}/intel_bxt_pmic_thermal.c
> > > (100%)
> > >  rename drivers/thermal/{ => intel}/intel_pch_thermal.c (100%)
> > >  rename drivers/thermal/{ => intel}/intel_powerclamp.c (100%)
> > >  rename drivers/thermal/{ => intel}/intel_quark_dts_thermal.c
> > > (100%)
> > >  rename drivers/thermal/{ => intel}/intel_soc_dts_iosf.c (100%)
> > >  rename drivers/thermal/{ => intel}/intel_soc_dts_iosf.h (100%)
> > >  rename drivers/thermal/{ => intel}/intel_soc_dts_thermal.c
> > > (100%)
> > >  rename drivers/thermal/{ => intel}/x86_pkg_temp_thermal.c (100%)
> > >  rename drivers/thermal/{ => qcom}/qcom-spmi-temp-alarm.c (100%)
> > > 
> > > --
> > > 2.17.1
> > > 


Re: [PATCH v3] thermal: qoriq: add multiple sensors support

2018-11-22 Thread Zhang Rui
On 三, 2018-11-21 at 09:43 +0100, Daniel Lezcano wrote:
> On 21/11/2018 02:34, Andy Tang wrote:
> > 
> > Hi all,
> > 
> > Do you have any comments on this patch?
> > 
> > I found for our thermal driver(qoriq_thermal.c) there are different
> > between the following two git trees:
> > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git 
> > branch: next  
> > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-
> > thermal.git.
> > branch: next
> > 
> > Could you please clarify which git tree/branch should I use?
> SoC changes are submitted against linux-soc-thermal.git.
> 
> Generic thermal framework are sent against Zhang Rui's tree but it
> happens sometimes Eduardo pick them also when the changes are related
> to
> SoC behavior.
> 
> However, I agree that can be confusing :)
> 

In the beginning, for soc thermal driver changes, I used to take them
with Acked-by/Reviewed-by from Eduardo or the driver maintainers.
Later, we have Eduardo to take the soc-thermal patches and send me pull
request so that I can merge them altogether before merge window.
Recently, we started to send separate pull requests to see how it goes.

So to make it easier, I agree we'd better stick with one tree.

thanks,
rui

> Eduardo, Rui,
> 
> how about to add a section in the maintainer handbook for the thermal
> to
> clarify the expectations and the flow?
> 
> > 
> > > 
> > > -Original Message-
> > > From: Andy Tang
> > > Sent: 2018年11月14日 15:29
> > > To: rui.zh...@intel.com; daniel.lezc...@linaro.org
> > > Cc: edubez...@gmail.com; linux...@vger.kernel.org;
> > > linux-kernel@vger.kernel.org
> > > Subject: RE: [PATCH v3] thermal: qoriq: add multiple sensors
> > > support
> > > 
> > > PING.
> > > 
> > > BR,
> > > Andy
> > > 
> > > > 
> > > > -Original Message-
> > > > From: andy.t...@nxp.com 
> > > > Sent: 2018年10月30日 9:00
> > > > To: rui.zh...@intel.com; daniel.lezc...@linaro.org
> > > > Cc: edubez...@gmail.com; linux...@vger.kernel.org;
> > > > linux-kernel@vger.kernel.org; Andy Tang 
> > > > Subject: [PATCH v3] thermal: qoriq: add multiple sensors
> > > > support
> > > > 
> > > > From: Yuantian Tang 
> > > > 
> > > > The QorIQ Layerscape SoC has several thermal sensors but the
> > > > current
> > > > driver only supports one.
> > > > 
> > > > Massage the code to be sensor oriented and allow the support
> > > > for
> > > > multiple sensors.
> > > > 
> > > > Signed-off-by: Yuantian Tang 
> > > > Reviewed-by: Daniel Lezcano 
> > > > ---
> > > > v3:
> > > >   - add Reviewed-by
> > > > v2:
> > > >   - update the commit message
> > > >   - refine the qoriq_tmu_register_tmu_zone()
> > > > 
> > > >  drivers/thermal/qoriq_thermal.c |  100
> > > > ++-
> > > >  1 files changed, 46 insertions(+), 54 deletions(-)
> > > > 
> > > > diff --git a/drivers/thermal/qoriq_thermal.c
> > > > b/drivers/thermal/qoriq_thermal.c index 450ed66..8beb344 100644
> > > > --- a/drivers/thermal/qoriq_thermal.c
> > > > +++ b/drivers/thermal/qoriq_thermal.c
> > > > @@ -59,14 +59,21 @@ struct qoriq_tmu_regs {
> > > >     u32 ttr3cr; /* Temperature Range 3
> > > > Control Register */
> > > >  };
> > > > 
> > > > +struct qoriq_tmu_data;
> > > > +
> > > >  /*
> > > >   * Thermal zone data
> > > >   */
> > > > +struct qoriq_sensor {
> > > > +   struct thermal_zone_device  *tzd;
> > > > +   struct qoriq_tmu_data   *qdata;
> > > > +   int id;
> > > > +};
> > > > +
> > > >  struct qoriq_tmu_data {
> > > > -   struct thermal_zone_device *tz;
> > > >     struct qoriq_tmu_regs __iomem *regs;
> > > > -   int sensor_id;
> > > >     bool little_endian;
> > > > +   struct qoriq_sensor *sensor[SITES_MAX];
> > > >  };
> > > > 
> > > >  static void tmu_write(struct qoriq_tmu_data *p, u32 val, void
> > > > __iomem
> > > > *addr) @@ -87,48 +94,51 @@ static u32 tmu_read(struct
> > > qoriq_tmu_data
> > > > 
> > > > *p, void __iomem *addr)
> > > > 
> > > >  static int tmu_get_temp(void *p, int *temp)  {
> > > > +   struct qoriq_sensor *qsensor = p;
> > > > +   struct qoriq_tmu_data *qdata = qsensor->qdata;
> > > >     u32 val;
> > > > -   struct qoriq_tmu_data *data = p;
> > > > 
> > > > -   val = tmu_read(data, >regs->site[data-
> > > > >sensor_id].tritsr);
> > > > +   val = tmu_read(qdata, >regs->site[qsensor-
> > > > >id].tritsr);
> > > >     *temp = (val & 0xff) * 1000;
> > > > 
> > > >     return 0;
> > > >  }
> > > > 
> > > > -static int qoriq_tmu_get_sensor_id(void)
> > > > +static const struct thermal_zone_of_device_ops tmu_tz_ops = {
> > > > +   .get_temp = tmu_get_temp,
> > > > +};
> > > > +
> > > > +static int qoriq_tmu_register_tmu_zone(struct platform_device
> > > > *pdev)
> > > >  {
> > > > -   int ret, id;
> > > > -   struct of_phandle_args sensor_specs;
> > > > -   struct device_node *np, *sensor_np;
> > > > +   struct qoriq_tmu_data *qdata =
> > > > 

Re: [PATCH v2 01/17] thermal: add thermal_zone_set_mode() helper

2018-11-06 Thread Zhang Rui
On 三, 2018-10-17 at 17:52 +0200, Bartlomiej Zolnierkiewicz wrote:
> In order to remove the code duplication and prepare for further
> changes:
> 
> * Add thermal_zone_set_mode() helper. Then update core code and
>   drivers to use it.
> 
> There should be no functional changes caused by this patch.
> 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
>  drivers/thermal/hisi_thermal.c | 14 ++
>  drivers/thermal/of-thermal.c   |  3 ++-
>  drivers/thermal/rockchip_thermal.c | 26 +-
>  drivers/thermal/thermal_helpers.c  | 14 ++
>  drivers/thermal/thermal_sysfs.c|  8 +---
>  include/linux/thermal.h|  5 +
>  6 files changed, 37 insertions(+), 33 deletions(-)
> 
> 
>  
> diff --git a/drivers/thermal/thermal_helpers.c
> b/drivers/thermal/thermal_helpers.c
> index 2ba756a..b18cee2 100644
> --- a/drivers/thermal/thermal_helpers.c
> +++ b/drivers/thermal/thermal_helpers.c
> @@ -224,3 +224,17 @@ int thermal_zone_get_offset(struct
> thermal_zone_device *tz)
>   return 0;
>  }
>  EXPORT_SYMBOL_GPL(thermal_zone_get_offset);
> +
> +/**
> + * thermal_zone_set_mode() - sets mode of thermal zone device
> + * @tz: a valid pointer to a struct thermal_zone_device
> + * @mode: mode to be set
> + *
> + * Return: On success returns 0, an error code otherwise.
> + */
> +int thermal_zone_set_mode(struct thermal_zone_device *tz,
> +   enum thermal_device_mode mode)
> +{
> + return tz->ops->set_mode(tz, mode);

better to check tz->ops->set_mode first.

thanks,
rui
> +}
> +EXPORT_SYMBOL_GPL(thermal_zone_set_mode);
> diff --git a/drivers/thermal/thermal_sysfs.c
> b/drivers/thermal/thermal_sysfs.c
> index 2241cea..2e9e762 100644
> --- a/drivers/thermal/thermal_sysfs.c
> +++ b/drivers/thermal/thermal_sysfs.c
> @@ -69,17 +69,19 @@
>  {
>   struct thermal_zone_device *tz = to_thermal_zone(dev);
>   int result;
> + enum thermal_device_mode mode;
>  
>   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;
>  
> + result = thermal_zone_set_mode(tz, mode);
>   if (result)
>   return result;
>  
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index 5f4705f..9d21fd1 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -452,6 +452,8 @@ struct thermal_cooling_device *
>  int thermal_zone_get_temp(struct thermal_zone_device *tz, int
> *temp);
>  int thermal_zone_get_slope(struct thermal_zone_device *tz);
>  int thermal_zone_get_offset(struct thermal_zone_device *tz);
> +int thermal_zone_set_mode(struct thermal_zone_device *tz,
> +   enum thermal_device_mode mode);
>  
>  int get_tz_trend(struct thermal_zone_device *, int);
>  struct thermal_instance *get_thermal_instance(struct
> thermal_zone_device *,
> @@ -518,6 +520,9 @@ static inline int thermal_zone_get_slope(
>  static inline int thermal_zone_get_offset(
>   struct thermal_zone_device *tz)
>  { return -ENODEV; }
> +static inline int thermal_zone_set_mode(
> + struct thermal_zone_device *tz, enum
> thermal_device_mode mode)
> +{ return -ENODEV; }
>  static inline int get_tz_trend(struct thermal_zone_device *tz, int
> trip)
>  { return -ENODEV; }
>  static inline struct thermal_instance *


Re: [PATCH v2 00/17] thermal: enable+check sensor after its setup is finished

2018-11-05 Thread Zhang Rui
Hi, Bartlomiej,

On 一, 2018-11-05 at 17:35 +0100, Bartlomiej Zolnierkiewicz wrote:
> On 11/05/2018 04:04 AM, Zhang Rui wrote:
> > 
> > Hi, Bartlomiej,
> Hi Rui,
> 
> > 
> > Interesting, I'm about to bring this issue to Linux Plumber
> > Conference
> > this year for discussion, and I'm also proposing a solution to fix
> > the
> > issues, but only with thermal core part finished yet.
> > can you please take a look at it?
> > https://patchwork.kernel.org/project/linux-pm/list/?series=38181
> Thank you for the patches but they seem to be far from being
> a complete solution for issues fixed by my patchset.

Right, as I said, this is a draft patch to illustrate my idea for those
issues. And it is not targeting for upstream.

>  Even
> thermal core part is not finished yet as it doesn't provide
> a way to register disabled sensors for DT thermal drivers (only
> for platform ones)..

we need sequential change of of_thermal to set tzp->disable
in of_parse_thermal_zones.

> 
> Why not simply apply my patchset now and incrementally work
> on top of it to implement fixes for issues your patchset is
> addressing?

The main concern is that, as you point out, we have too many private
mode implementation, and I'm looking for the possibility to handle them
in the thermal core framework.

> 
> My patchset may not be a perfect solution but IMO it is good
> enough and it has been practically ready since v1 posted in
> April (v2 fixes all issues requested by Eduardo's review from
> September)..

I'm not against doing this, as long as it fixes something and doesn't
break the others.
But, I still have a couple of comments about your patches, and let me
comment in lines.

thanks,
rui
> 
> > 
> > thanks,
> > rui
> > 
> > On 三, 2018-10-17 at 17:52 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > 
> > > Hi,
> > > 
> > > [devm]_thermal_zone_of_sensor_register() is used to register
> > > thermal sensor by thermal drivers using DeviceTree. Besides
> > > registering sensor this function also immediately:
> > > 
> > > - enables it:
> > > 
> > >   tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED)
> > >   (->set_mode is set to of_thermal_set_mode() in of-thermal.c)
> > > 
> > > - checks it (indirectly by using of_thermal_set_mode()):
> > > 
> > >   thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED);
> > >   (which in turn ends up using ->get_temp method).
> > > 
> > > For many DT thermal drivers this causes a problem because:
> > > 
> > > - [devm]_thermal_zone_of_sensor_register() need to be called in
> > >   order to obtain data about thermal trips which are then used to
> > >   finish hardware sensor setup (only after which ->get_temp can
> > >   be used)
> > > 
> > > There is also related issue for DT thermal drivers that support
> > > IRQ (i.e. exynos and rockchip ones):
> > > 
> > > - sensor hardware should be enabled only after IRQ handler is
> > >   requested (because otherwise we might get IRQs that we can't
> > >   handle)
> > > 
> > > - IRQ handler needs tzd structure which is obtained from
> > >   [devm_]thermal_zone_of_sensor_register()
> > > 
> > > - after [devm_]thermal_zone_of_sensor_register() call core
> > >   thermal code assumes that sensor is enabled and ready to use
> > >   (i.e. that IRQ handler has been requested and sensor hardware
> > >   has been enabled)
> > > 
> > > In order to fix all abovementioned issues sensor registration,
> > > enable and check operations are separated in the core DT thermal
> > > code and corresponding DT thermal drivers are modified to do
> > > sensor
> > > setup correctly.
> > > 
> > > Changes since v1:
> > > - rebased on the current -next kernel (next-20181015)
> > > - enhanced patch descriptions and cover letter
> > > - renamed thermal_zone_device_toggler() to
> > > thermal_zone_set_mode()
> > > - converted thermal_zone_set_mode() to use enum
> > > thermal_device_mode
> > > - added CONFIG_THERMAL=n stubs for thermal_zone_set_mode() and
> > >   thermal_zone_device_check()
> > > - fixed uses of [devm]_thermal_zone_of_sensor_register() outside
> > > of
> > >   drivers/thermal/
> > > - changed ordering between patch #2 and #3 in order to add all
> > >   needed core helpers first before fixing sensor setup code
> > > - changed ordering between patch #3 and #4 in order to simplify
> >

[GIT PULL] Thermal management updates for v4.20-rc1

2018-10-30 Thread Zhang Rui
Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next

to receive the latest Thermal management updates for v4.20-rc1 with
top-most commit c2b59d279dbbac750958f6a1bc4841e431d934e3:

  thermal: core: using power_efficient_wq for thermal worker (2018-10-
10 21:48:50 +0800)

on top of commit 0238df646e6224016a45505d2c111a24669ebe21:

  Linux 4.19-rc7 (2018-10-07 17:26:02 +0200)

Specifics:
- Fix a use-after-free issue when unregistering a thermal cooling
device.(Dmitry Osipenko)

- use power_efficient_wq for thermal worker to save more power. (Jeson
Gao)

thanks,
rui


Dmitry Osipenko (1):
  thermal: core: Fix use-after-free in
thermal_cooling_device_destroy_sysfs

Jeson Gao (1):
  thermal: core: using power_efficient_wq for thermal worker

 drivers/thermal/thermal_core.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)


Re: 4.18: early boot crash in thermal_cooling_device_destroy_sysfs

2018-10-30 Thread Zhang Rui
Hi, Randy,

On 五, 2018-10-26 at 20:35 -0700, Randy Dunlap wrote:
> On 10/26/18 2:14 AM, Rafael J. Wysocki wrote:
> > 
> > On Monday, October 22, 2018 8:37:25 PM CEST Randy Dunlap wrote:
> > > 
> > > 
> > > On 8/16/18 2:33 PM, Randy Dunlap wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > Sorry for the photo.  That's all I have available so far.
> > > > 
> > > > https://www.infradead.org/~rdunlap/doc/IMG_20180816_133254743_H
> > > > DR.jpg
> > > > 
> > > > 
> > > > Does anyone recognize this?
> > > > 
> > > > This is an (older) Toshiba laptop.  The kernel .config is
> > > > mostly an
> > > > allmodconfig with some DEBUG options disabled and other options
> > > > enabled
> > > > so that it can boot without using an initramfs.  (and with
> > > > COMPILE_TEST
> > > > disabled :)
> > > > 
> > > > 
> > > > The full kernel .config file is attached.
> > > > 
> > > > Thanks,
> > > > 
> > > This is a result of CONFIG_DEBUG_TEST_DRIVER_REMOVE=y.
> > > [switch from 64-bit to 32-bit machine]
> > > 
> > > 
> > > When using CONFIG_DEBUG_VM=y, it BUGs at:
> > > [5.553603] [ cut here ]
> > > [5.553733] kernel BUG at arch/x86/mm/physaddr.c:75!
> > > [5.557788] invalid opcode:  [#1] PREEMPT SMP
> > > DEBUG_PAGEALLOC
> > > [5.558738] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.19.0-
> > > rc7 #4
> > > [5.558738] Hardware name: Dell Inc. Inspiron
> > > 1318   /0C236D, BIOS A04 01/15/2009
> > > [5.558738] EIP: __phys_addr+0x40/0x90
> > > [5.558738] Code: 00 40 75 2e 8b 15 00 57 23 d5 85 d2 74 12 89
> > > d9 c1 e9 0c 39 ca 72 5b e8 2e ca ff ff 39 d8 75 4a 89 d8 5b 5d c3
> > > 8d 74 26 00 90 <0f> 0b 8d b6 00 00 00 00 8b 0d 80 56 23 d5 8d 91
> > > 00 00 80 00 39 d0
> > > [5.558738] EAX: 6b6b6b6b EBX: 6b6b6b6b ECX: 00140011 EDX:
> > > 
> > > [5.558738] ESI: f489 EDI: d4a58d60 EBP: f40c1e0c ESP:
> > > f40c1e08
> > > [5.558738] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> > > EFLAGS: 00210a97
> > > [5.558738] CR0: 80050033 CR2:  CR3: 14cad000 CR4:
> > > 000406d0
> > > [5.558738] Call Trace:
> > > [5.558738]  kfree+0x1f/0x160
> > > [5.558738]  thermal_cooling_device_destroy_sysfs+0x11/0x20
> > > [5.558738]  thermal_cooling_device_unregister+0x168/0x180
> > > [5.558738]  acpi_pss_perf_exit.isra.4+0x32/0x50
> > > [5.558738]  acpi_processor_stop+0x4d/0x60
> > > [5.558738]  really_probe+0xa3/0x3e0
> > > [5.558738]  driver_probe_device+0x5b/0x120
> > > [5.558738]  __driver_attach+0xd9/0x100
> > > [5.558738]  ? driver_probe_device+0x120/0x120
> > > [5.558738]  bus_for_each_dev+0x56/0x90
> > > [5.558738]  driver_attach+0x14/0x20
> > > [5.558738]  ? driver_probe_device+0x120/0x120
> > > [5.558738]  bus_add_driver+0x117/0x210
> > > [5.558738]  driver_register+0x61/0xb0
> > > [5.558738]  acpi_processor_driver_init+0x19/0x88
> > > [5.558738]  ? acpi_pci_slot_init+0xf/0xf
> > > [5.558738]  do_one_initcall+0x3e/0x15a
> > > [5.558738]  ? do_early_param+0x75/0x75
> > > [5.558738]  kernel_init_freeable+0x170/0x1f3
> > > [5.558738]  ? rest_init+0xcd/0xcd
> > > [5.558738]  kernel_init+0x8/0xdb
> > > [5.558738]  ret_from_fork+0x2e/0x38
> > > [5.558738] Modules linked in:
> > > [5.625269] _warn_unseeded_randomness: 1 callbacks suppressed
> > > [5.625272] random: get_random_bytes called from
> > > init_oops_id+0x3a/0x40 with crng_init=0
> > > [5.629758] ---[ end trace 65b17bf4d18e7692 ]---
> > > [5.631573] EIP: __phys_addr+0x40/0x90
> > > [5.633242] Code: 00 40 75 2e 8b 15 00 57 23 d5 85 d2 74 12 89
> > > d9 c1 e9 0c 39 ca 72 5b e8 2e ca ff ff 39 d8 75 4a 89 d8 5b 5d c3
> > > 8d 74 26 00 90 <0f> 0b 8d b6 00 00 00 00 8b 0d 80 56 23 d5 8d 91
> > > 00 00 80 00 39 d0
> > > [5.638618] EAX: 6b6b6b6b EBX: 6b6b6b6b ECX: 00140011 EDX:
> > > 
> > > [5.640703] ESI: f489 EDI: d4a58d60 EBP: f40c1e0c ESP:
> > > d4cb13dc
> > > [5.642801] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> > > EFLAGS: 00210a97
> > > [5.645053] CR0: 80050033 CR2:  CR3: 14cad000 CR4:
> > > 000406d0
> > > [5.647179] Kernel panic - not syncing: Fatal exception
> > > [5.648172] Kernel Offset: 0x1300 from 0xc100
> > > (relocation range: 0xc000-0xf77fdfff)
> > > [5.648172] ---[ end Kernel panic - not syncing: Fatal
> > > exception ]---
> > > 
> > > 
> > > When not using CONFIG_DEBUG_VM, it BUGs in kfree:
> > > [5.497864] [ cut here ]
> > > [5.498215] kernel BUG at mm/slub.c:3901!
> > > [5.501739] invalid opcode:  [#1] PREEMPT SMP
> > > [5.502720] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.0-
> > > rc7 #3
> > > [5.502720] Hardware name: Dell Inc. Inspiron
> > > 1318   /0C236D, BIOS A04 01/15/2009
> > > [5.502720] EIP: kfree+0x117/0x150
> > > [5.502720] Code: 74 21 8b 06 31 d2 f6 c4 80 74 04 0f b6 56 31
> > > 89 f0 e8 7d e0 fa ff e9 7b ff ff ff 8d b4 

[PATCH] ACPI / LPSS: Force lpss quirks on boot

2018-09-04 Thread Zhang Rui
On 一, 2018-09-03 at 10:38 +0800, Zhang Rui wrote:
> Hi, William,
> 
> On 六, 2018-09-01 at 12:59 -0500, William Lieurance wrote:
> > 
> > For some number of systems with lpss_quirks enabled, on boot the
> > system
> > goes through an acpi_lpss_resume() without a corresponding
> > acpi_lpss_suspend() having been called.
> I read the code but didn't find out why this could happen, but if it
> is
> true, please check if the below patch helps
> 
> From 27fda1ab0d800966b0ec1c444fe356812bd2f04e Mon Sep 17 00:00:00
> 2001
> From: Zhang Rui 
> Date: Mon, 3 Sep 2018 10:00:07 +0800
> Subject: [PATCH] ACPI / LPSS: Force lpss quirks on boot
> 
> Commit 12864ff8545f ("ACPI / LPSS: Avoid PM quirks on suspend and
> resume
> from hibernation") bypasses lpss quirks for S3 and S4, by setting a
> flag
> for S3/S4 in acpi_lpss_suspend(), and check that flag in
> acpi_lpss_resume().
> 
> But this overlooks the boot case where acpi_lpss_resume() may get
> called
> without a corresponding acpi_lpss_suspend() having been called.
> 
> Thus force setting the flag during boot.
> 
> Fixes: 12864ff8545f (ACPI / LPSS: Avoid PM quirks on suspend and
> resume from hibernation)
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=200989
> Signed-off-by: Zhang Rui 

According to https://bugzilla.kernel.org/show_bug.cgi?id=200989#c6,
the patch has been confirmed to fix the problem.
Don't know why the patch does not show up in patchwork.
Let me resend.

>From f07303f10e41c2b61d0d4da5f74e98a3bf8e7147 Mon Sep 17 00:00:00 2001
From: Zhang Rui 
Date: Mon, 3 Sep 2018 10:00:07 +0800
Subject: [PATCH] ACPI / LPSS: Force lpss quirks on boot

Commit 12864ff8545f ("ACPI / LPSS: Avoid PM quirks on suspend and resume
from hibernation") bypasses lpss quirks for S3 and S4, by setting a flag
for S3/S4 in acpi_lpss_suspend(), and check that flag in
acpi_lpss_resume().

But this overlooks the boot case where acpi_lpss_resume() may get called
without a corresponding acpi_lpss_suspend() having been called.

Thus force setting the flag during boot.

Fixes: 12864ff8545f (ACPI / LPSS: Avoid PM quirks on suspend and resume from 
hibernation)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200989
Reported-and-tested-by: William Lieurance 
Signed-off-by: Zhang Rui 
---
 drivers/acpi/acpi_lpss.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 9706613..bf64cfa 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -879,7 +879,7 @@ static void acpi_lpss_dismiss(struct device *dev)
 #define LPSS_GPIODEF0_DMA_LLP  BIT(13)
 
 static DEFINE_MUTEX(lpss_iosf_mutex);
-static bool lpss_iosf_d3_entered;
+static bool lpss_iosf_d3_entered = true;
 
 static void lpss_iosf_enter_d3_state(void)
 {
-- 
2.7.4



Re: [PATCH] ACPI / LPSS: Ensure LPIOEP is always set on resume

2018-09-02 Thread Zhang Rui
Hi, William,

On 六, 2018-09-01 at 12:59 -0500, William Lieurance wrote:
> For some number of systems with lpss_quirks enabled, on boot the
> system
> goes through an acpi_lpss_resume() without a corresponding
> acpi_lpss_suspend() having been called.

I read the code but didn't find out why this could happen, but if it is
true, please check if the below patch helps

>From 27fda1ab0d800966b0ec1c444fe356812bd2f04e Mon Sep 17 00:00:00 2001
From: Zhang Rui 
Date: Mon, 3 Sep 2018 10:00:07 +0800
Subject: [PATCH] ACPI / LPSS: Force lpss quirks on boot

Commit 12864ff8545f ("ACPI / LPSS: Avoid PM quirks on suspend and resume
from hibernation") bypasses lpss quirks for S3 and S4, by setting a flag
for S3/S4 in acpi_lpss_suspend(), and check that flag in
acpi_lpss_resume().

But this overlooks the boot case where acpi_lpss_resume() may get called
without a corresponding acpi_lpss_suspend() having been called.

Thus force setting the flag during boot.

Fixes: 12864ff8545f (ACPI / LPSS: Avoid PM quirks on suspend and resume from 
hibernation)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200989
Signed-off-by: Zhang Rui 
---
 drivers/acpi/acpi_lpss.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 9706613..bf64cfa 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -879,7 +879,7 @@ static void acpi_lpss_dismiss(struct device *dev)
 #define LPSS_GPIODEF0_DMA_LLP  BIT(13)
 
 static DEFINE_MUTEX(lpss_iosf_mutex);
-static bool lpss_iosf_d3_entered;
+static bool lpss_iosf_d3_entered = true;
 
 static void lpss_iosf_enter_d3_state(void)
 {
-- 
2.7.4




Re: [PATCH 0/2] dt: thermal: Fix broken cooling-maps

2018-08-06 Thread Zhang Rui
On 五, 2018-08-03 at 14:10 +0530, Viresh Kumar wrote:
> On 31-07-18, 14:00, Zhang Rui wrote:
> > 
> > I suppose this patch should go via Eduardo' tree.
> > Eduardo, can you please take a look at this patch set?
> Zhang,
> 
> Since Eduardo isn't replying, will it be possible for you to pick it
> up as I
> don't want to miss 4.19-rc1.
> 
Okay, I will keep queue it in my tree first.

thanks,
rui


Re: [PATCH 0/2] dt: thermal: Fix broken cooling-maps

2018-07-31 Thread Zhang Rui
On 二, 2018-07-31 at 10:21 +0530, Viresh Kumar wrote:
> On 05-07-18, 10:39, Viresh Kumar wrote:
> > 
> > Hi,
> > 
> > This is an attempt to fix the broken or partially defined DT
> > bindings
> > for cooling-maps. We should list every device that participates in
> > cooling down at a certain trip point, instead of just the first in
> > the
> > list as that depends on certain ordering of events to work
> > properly.
> > 
> > The first patch extends the binding to allow a list of phandles in
> > "cooling-device" property and the second patch fixes one of the
> > platform's DT.
> > 
> > This will be followed up by fixing all platform DT bindings that
> > have
> > these issues after this set is accepted.
> > 
> > The kernel also requires some changes to handle the phandle list,
> > but
> > wouldn't break with these changes as it reads the first phandle in
> > the
> > list for now. We can update that separately.
> @Zhang: Are you going to apply this for 4.19-rc1 ? There are lot of
> patches that
> I am holding up until this gets merged,
> 
I suppose this patch should go via Eduardo' tree.
Eduardo, can you please take a look at this patch set?

thanks,
rui


Re: [PATCH] MAINTAINERS: Add myself as designated reviewer for thermal

2018-07-27 Thread Zhang Rui
On 四, 2018-07-26 at 14:12 -0700, Eduardo Valentin wrote:
> On Thu, Jul 26, 2018 at 12:29:40PM +0200, Daniel Lezcano wrote:
> > 
> > I would like to participate in the review process effort for the
> > thermal framework, especially the SoC part.
> > 
> > Instead of capturing emails with message filters, I would like to
> > humbly add myself as reviewer so I can receive the patches directly
> > in
> > my INBOX and focus on their review.
> > 
> > Signed-off-by: Daniel Lezcano 
> Acked-by: Eduardo Valentin 
> 
> Thanks for the help Daniel.
> 
> Rui, want to take care of this?
> 

yes, I will take this patch

thanks,
rui
> > 
> > ---
> >  MAINTAINERS | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 0fe4228..1890aad 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -14119,6 +14119,7 @@ F:  drivers/media/radio/radio-
> > raremono.c
> >  THERMAL
> >  M: Zhang Rui 
> >  M: Eduardo Valentin 
> > +R: Daniel Lezcano 
> >  L: linux...@vger.kernel.org
> >  T: git
> > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git
> >  T: git
> > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-
> > thermal.git


Re: [PATCH] drivers: thermal: do not clobber cooling dev state from userspace

2018-07-26 Thread Zhang Rui
On 一, 2018-05-07 at 11:55 -0600, Lina Iyer wrote:
> From: Ram Chandrasekar 
> 
> Let userspace be another voter for cooling device state instead of
> the
> overriding authority. It is possible that the thermal governor may
> find
> a higher cooling state desirable than what is recommended by the
> userspace. Separate out the current cooling device state from the
> userspace request and aggregate the userspace request with the
> governors' recommendation.
> 

hmmm, I don't understand this.
If the governor does not work well, we should either improve the
governor or use userspace governor instead.
do you have any examples that the kernel governor chooses improper
cooling state?

thanks,
rui

> Signed-off-by: Lina Iyer 
> ---
>  drivers/thermal/thermal_core.c| 1 +
>  drivers/thermal/thermal_helpers.c | 2 +-
>  drivers/thermal/thermal_sysfs.c   | 8 +++-
>  include/linux/thermal.h   | 1 +
>  4 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/thermal/thermal_core.c
> b/drivers/thermal/thermal_core.c
> index 589925ac0994..c2e13e122934 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -970,6 +970,7 @@ __thermal_cooling_device_register(struct
> device_node *np,
>   cdev->updated = false;
>   cdev->device.class = _class;
>   cdev->devdata = devdata;
> + cdev->sysfs_req = 0;
>   thermal_cooling_device_setup_sysfs(cdev);
>   dev_set_name(>device, "cooling_device%d", cdev->id);
>   result = device_register(>device);
> diff --git a/drivers/thermal/thermal_helpers.c
> b/drivers/thermal/thermal_helpers.c
> index 2ba756af76b7..f550fdee0f9b 100644
> --- a/drivers/thermal/thermal_helpers.c
> +++ b/drivers/thermal/thermal_helpers.c
> @@ -166,7 +166,7 @@ EXPORT_SYMBOL_GPL(thermal_zone_set_trips);
>  void thermal_cdev_update(struct thermal_cooling_device *cdev)
>  {
>   struct thermal_instance *instance;
> - unsigned long target = 0;
> + unsigned long target = cdev->sysfs_req;
>  
>   mutex_lock(>lock);
>   /* cooling device is updated*/
> diff --git a/drivers/thermal/thermal_sysfs.c
> b/drivers/thermal/thermal_sysfs.c
> index 275ffee292bf..eddada715ad2 100644
> --- a/drivers/thermal/thermal_sysfs.c
> +++ b/drivers/thermal/thermal_sysfs.c
> @@ -719,7 +719,13 @@ thermal_cooling_device_cur_state_store(struct
> device *dev,
>   result = cdev->ops->set_cur_state(cdev, state);
>   if (result)
>   return result;
> - thermal_cooling_device_stats_update(cdev, state);
> +
> + cdev->sysfs_req = state;
> + mutex_lock(>lock);
> + cdev->updated = false;
> + mutex_unlock(>lock);
> + thermal_cdev_update(cdev);
> +
>   return count;
>  }
>  
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index 5f4705f46c2f..7a133bd6ff86 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -139,6 +139,7 @@ struct thermal_cooling_device {
>   struct mutex lock; /* protect thermal_instances list */
>   struct list_head thermal_instances;
>   struct list_head node;
> + unsigned long sysfs_req;
>  };
>  
>  struct thermal_attr {


Re: [PATCH] drivers: thermal: step_wise: add support for hysteresis

2018-07-26 Thread Zhang Rui
Hi, Lina,

On 一, 2018-05-07 at 11:54 -0600, Lina Iyer wrote:
> From: Ram Chandrasekar 
> 
> From: Ram Chandrasekar 
> 
> Step wise governor increases the mitigation level when the
> temperature
> goes above a threshold and will decrease the mitigation when the
> temperature falls below the threshold. If it were a case, where the
> temperature hovers around a threshold, the mitigation will be applied
> and removed at every iteration. This reaction to the temperature is
> inefficient for performance.
> 
> The use of hysteresis temperature could avoid this ping-pong of
> mitigation by relaxing the mitigation to happen only when the
> temperature goes below this lower hysteresis value.
> 
the idea looks okay to me, just some minor comments.

> Signed-off-by: Ram Chandrasekar 
> Signed-off-by: Lina Iyer 
> ---
>  drivers/thermal/step_wise.c | 33 +++--
>  1 file changed, 23 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/thermal/step_wise.c
> b/drivers/thermal/step_wise.c
> index ee047ca43084..cf07e2269291 100644
> --- a/drivers/thermal/step_wise.c
> +++ b/drivers/thermal/step_wise.c
> @@ -36,7 +36,7 @@
>   *   for this trip point
>   *d. if the trend is THERMAL_TREND_DROP_FULL, use lower limit
>   *   for this trip point
> - * If the temperature is lower than a trip point,
> + * If the temperature is lower than a hysteresis temperature,

1. if you update this, you should update "if the temperature is higher
than ..." as well.

2. the updated comment does not fully match the code change you made
below.

>   *a. if the trend is THERMAL_TREND_RAISING, do nothing
>   *b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
>   *   state for this trip point, if the cooling state already
> @@ -127,7 +127,7 @@ static void update_passive_instance(struct
> thermal_zone_device *tz,
>  
>  static void thermal_zone_trip_update(struct thermal_zone_device *tz,
> int trip)
>  {
> - int trip_temp;
> + int trip_temp, hyst_temp;
>   enum thermal_trip_type trip_type;
>   enum thermal_trend trend;
>   struct thermal_instance *instance;
> @@ -135,22 +135,23 @@ static void thermal_zone_trip_update(struct
> thermal_zone_device *tz, int trip)
>   int old_target;
>  
>   if (trip == THERMAL_TRIPS_NONE) {
> - trip_temp = tz->forced_passive;
> + hyst_temp = trip_temp = tz->forced_passive;
>   trip_type = THERMAL_TRIPS_NONE;
>   } else {
>   tz->ops->get_trip_temp(tz, trip, _temp);
> + hyst_temp = trip_temp;
> + if (tz->ops->get_trip_hyst) {
> + tz->ops->get_trip_hyst(tz, trip,
> _temp);
> + hyst_temp = trip_temp - hyst_temp;
> + }
>   tz->ops->get_trip_type(tz, trip, _type);
>   }
>  
>   trend = get_tz_trend(tz, trip);
>  
> - if (tz->temperature >= trip_temp) {
> - throttle = true;
> - trace_thermal_zone_trip(tz, trip, trip_type);
> - }
> -
> - dev_dbg(>device,
> "Trip%d[type=%d,temp=%d]:trend=%d,throttle=%d\n",
> - trip, trip_type, trip_temp, trend,
> throttle);
> + dev_dbg(>device,
> + "Trip%d[type=%d,temp=%d,hyst=%d]:trend=%d,throttle=%
> d\n",
> + trip, trip_type, trip_temp, hyst_temp, trend,
> throttle);
>  
throttle is not set properly here, so this debug message does not make
sense.

thanks,
rui
>   mutex_lock(>lock);
>  
> @@ -159,6 +160,18 @@ static void thermal_zone_trip_update(struct
> thermal_zone_device *tz, int trip)
>   continue;
>  
>   old_target = instance->target;
> + throttle = false;
> + /*
> +  * Lower the mitigation only if the temperature
> +  * goes below the hysteresis temperature.
> +  */
> + if (tz->temperature >= trip_temp ||
> +    (tz->temperature >= hyst_temp &&
> +    old_target != THERMAL_NO_TARGET)) {
> + throttle = true;
> + trace_thermal_zone_trip(tz, trip,
> trip_type);
> + }
> +

>   instance->target = get_target_state(instance, trend,
> throttle);
>   dev_dbg(>cdev->device, "old_target=%d,
> target=%d\n",
>   old_target, (int)instance-
> >target);


[GIT PULL] Thermal management updates for v4.18-rc1 #2

2018-06-12 Thread Zhang Rui
Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-
thermal.git linus

to receive the latest Thermal SoC management updates for v4.18-rc1 with
top-most commit 6d7c70d1cd6526dc79e3d3b3faae1c40c1681168:

  thermal: qcom: tsens: Allow number of sensors to come from DT (2018-
06-01 15:09:15 -0700)

on top of commit 701e39d05119229b92ecca4add7b7ed2193622c3:

  Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
(2018-05-06 05:46:29 -1000)

Specifics:

- imx thermal driver now supports i.MX7 thermal sensor (Anson Huang).

- exynos thermal driver dropped support for exynos 5440 (Krzysztof
Kozlowski).

- rcar_thermal now supports r8a77995 (Yoshihiro Kaneko).

- rcar_gen3_thermal now supports r8a77965 (Niklas Söderlund).

- qcom-spmi-temp-alarm now supports GEN2 PMIC peripherals (David
Collins).

- uniphier thermal now supports UniPhier PXs3 (Kunihiko Hayashi).

- mediatek thermal now supports MT7622 SoC (Sean Wang).

- considerable refactoring of exynos driver (Bartlomiej
Zolnierkiewicz).

- Small fixes all over the place on different drivers.

thanks,
rui


Anson Huang (1):
  thermal: imx: add i.MX7 thermal sensor support

Bartlomiej Zolnierkiewicz (28):
  thermal: exynos: remove unused "type" field from struct
exynos_tmu_platform_data
  thermal: exynos: remove parsing of samsung,
tmu_default_temp_offset property
  thermal: exynos: remove parsing of samsung, tmu_[first,
second]_point_trim properties
  thermal: exynos: remove parsing of samsung, tmu_noise_cancel_mode
property
  thermal: exynos: remove parsing of samsung, tmu[_min,
_max]_efuse_value properties
  thermal: exynos: remove parsing of samsung, tmu_reference_voltage
property
  thermal: exynos: remove parsing of samsung,tmu_gain property
  thermal: exynos: remove parsing of samsung, tmu_cal_type property
  thermal: exynos: remove separate exynos_tmu.h header file
  thermal: exynos: fix setting rising_threshold for Exynos5433
  thermal: exynos: always check for trips points existence
  thermal: exynos: always check for critical trip points existence
  thermal: exynos: check STATUS register in exynos_tmu_initialize()
  thermal: exynos: use sanitize_temp_error() in
exynos7_tmu_initialize()
  thermal: exynos: fix trips limit checking in get_th_reg()
  thermal: exynos: remove threshold_code checking from
exynos4210_tmu_initialize()
  thermal: exynos: make ->tmu_initialize method void
  thermal: exynos: clear IRQs later in exynos4412_tmu_initialize()
  thermal: exynos: move IRQs clearing to exynos_tmu_initialize()
  thermal: exynos: add exynos*_tmu_set_[trip,hyst]() helpers
  thermal: exynos: do not use trips structure directly in
->tmu_initialize
  thermal: exynos: set trips in ascending order in
exynos7_tmu_initialize()
  thermal: exynos: move trips setting to exynos_tmu_initialize()
  thermal: exynos: check return values of ->get_trip_[temp, hyst]
methods
  thermal: exynos: cleanup code for enabling threshold interrupts
  thermal: exynos: remove unused defines for Exynos5433
  thermal: exynos: remove trip reporting to user-space
  thermal: ti-soc-thermal: fix incorrect entry in
omap5430_adc_to_temp[]

Bjorn Andersson (1):
  thermal: qcom: tsens: Allow number of sensors to come from DT

David Collins (1):
  thermal: qcom-spmi-temp-alarm: add support for GEN2 PMIC
peripherals

Ezequiel Garcia (1):
  thermal: tegra: Nuke clk_{readl,writel} helpers

Fabio Estevam (1):
  thermal: imx: Switch to SPDX identifier

Hien Dang (1):
  thermal: rcar_gen3_thermal: Update calculation formula due to HW
evaluation

Krzysztof Kozlowski (2):
  thermal: samsung: Remove support for Exynos5440
  thermal: exynos: Reduce severity of too early temperature read

Kunihiko Hayashi (2):
  dt-bindings: thermal: uniphier: add a compatible string for PXs3
  thermal: uniphier: add UniPhier PXs3 support

Maciej Purski (1):
  thermal: exynos: Read soc_type from match data

Marek Szyprowski (2):
  thermal: exynos: Reading temperature makes sense only when TMU is
turned on
  thermal: exynos: Propagate error value from tmu_read()

Niklas Söderlund (3):
  thermal: rcar_gen3_thermal: update max temperature clamp
  dt-bindings: thermal: rcar-gen3-thermal: add r8a77965
  thermal: rcar_gen3_thermal: add r8a77965 support

Ryder Lee (1):
  thermal: mediatek: use of_device_get_match_data()

Sean Wang (2):
  dt-bindings: thermal: add binding for MT7622 SoC
  thermal: mediatek: add support for MT7622 SoC

Yoshihiro Kaneko (2):
  dt-bindings: thermal: rcar-thermal: add R8A77995 support
  thermal: rcar_thermal: add r8a77995 support

srplinux2008 (1):
  thermal: tegra: soctherm: add const to struct
thermal_cooling_device_ops

 .../devicetree/bindings/thermal/exynos-thermal.txt |  14 +-
 

[GIT PULL] Thermal management updates for v4.18-rc1 #1

2018-06-12 Thread Zhang Rui
Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next

to receive the latest Thermal Management updates for v4.18-rc1 with
top-most commit e9ed3ee61aa62ce280aadeeea1ec959f0c66a290:

  Merge branches 'thermal-core' and 'thermal-intel' into next (2018-05-30 
14:54:20 +0800)

on top of commit 771c577c23bac90597c685971d7297ea00f99d11:

  Linux 4.17-rc6 (2018-05-20 15:31:38 -0700)

Specifics:

- convert thermal sysfs attributes to use DEVICE_ATTR_{RO|RW|WO}() variants 
(Viresh Kumar).

- update license to SPDX format (Lina Iyer).

- add GeminiLake support for int340x processor_thermal driver (Sumeet Pawnikar).

- Prevent error in reading trip hysteresis attribute for int340x thermal driver 
(Srinivas Pandruvada).

I merged the thermal-soc changes from Eduardo some days ago, but without any 
merge message in the changelog. And I realize this is wrong after reading the 
discussion for the libnvdimm pull request. So, to avoid a pretty new merge 
commit in my pull request, I decided to send the pull requests separately this 
time, one for thermal core and intel thermal driver changes, and another for 
the other thermal soc driver changes.

BTW, for the top-most merge commit in this pull request, thermal-core and 
thermal-intel are not strictly topic branches, they are just collections of 
small patches, for thermal core framework and for Intel platform specific 
thermal drivers. Are you suggesting I should append the detailed specifics 
(like above) into the merge message as well?

thanks,
rui


Lina Iyer (1):
  drivers: thermal: Update license to SPDX format

Srinivas Pandruvada (1):
  thermal: int340x: Prevent error in reading trip hysteresis
attribute

Sumeet Pawnikar (1):
  thermal: int340x: processor_thermal: Add GeminiLake support

Viresh Kumar (2):
  thermal: Shorten name of sysfs callbacks
  thermal: Use DEVICE_ATTR_{RO|RW|WO}() variants

Zhang Rui (1):
  Merge branches 'thermal-core' and 'thermal-intel' into next

 .../thermal/int340x_thermal/int340x_thermal_zone.c |  6 +-
 .../int340x_thermal/processor_thermal_device.c |  4 ++
 drivers/thermal/of-thermal.c   | 19 +
 drivers/thermal/thermal_core.c | 11 ++-
 drivers/thermal/thermal_core.h | 30 ++--
 drivers/thermal/thermal_helpers.c  |  5 +-
 drivers/thermal/thermal_hwmon.c| 17 +
 drivers/thermal/thermal_hwmon.h| 17 +
 drivers/thermal/thermal_sysfs.c| 81 
--
 include/linux/thermal.h| 17 +
 10 files changed, 50 insertions(+), 157 deletions(-)


[GIT PULL] Thermal management updates for v4.17-rc5

2018-05-12 Thread Zhang Rui
Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next

to receive the latest Thermal Management updates for v4.17-rc5 with
top-most commit 60abce9f43d812dfec6687a10ca30be380f6f97a:

  Merge branch 'thermal-soc' into next (2018-05-11 09:37:21 +0800)

on top of commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e:

  Linux 4.17-rc2 (2018-04-22 19:20:09 -0700)

Specifics:

- Fix NULL pointer deref on module load/probe, for int3403_thermal
driver.

- Fix an emergency shutdown issue on exynos thermal driver.


thanks,
rui


Hans de Goede (1):
  thermal: int3403_thermal: Fix NULL pointer deref on module load /
probe

Marek Szyprowski (2):
  thermal: exynos: Reading temperature makes sense only when TMU is
turned on
  thermal: exynos: Propagate error value from tmu_read()

Zhang Rui (1):
  Merge branch 'thermal-soc' into next

 drivers/thermal/int340x_thermal/int3403_thermal.c |  3 +--
 drivers/thermal/samsung/exynos_tmu.c  | 14 +++---
 2 files changed, 12 insertions(+), 5 deletions(-)



Re: linux-next: Signed-off-by missing for commits in the thermal tree

2018-05-10 Thread Zhang Rui
On 三, 2018-05-09 at 19:10 -0700, Eduardo Valentin wrote:
> Hey Rui,
> 
> On Wed, May 09, 2018 at 09:43:41PM +1000, Stephen Rothwell wrote:
> > 
> > Hi Zhang,
> > 
> > Commits
> > 
> >   a2ace598c00a ("thermal: exynos: Reading temperature makes sense
> > only when TMU is turned on")
> >   f9cd6a904e6e ("thermal: exynos: Propagate error value from
> > tmu_read()")
> > 
> > are missing a Signed-off-by from their committer.
> Did you cherry-pick them instead of merging? If cherry-picking you
> have
> to add your Signed-off-by..
> 
I merged them, and then did a rebase to drop some of the patch, hmmm,
could that be the problem?
Anyway, I will re-merge your tree and push them out sometime tomorrow.

thanks,
rui



Re: [GIT PULL] Thermal management updates for v4.17-rc2

2018-04-24 Thread Zhang Rui
Hi, Eduardo,

On 五, 2018-04-20 at 09:18 -0700, Eduardo Valentin wrote:
> Hello Linus,
> 
> Here are a couple of fixes on thermal subsystem.
> Please consider pulling from
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-
> thermal fixes
> 
> to receive Thermal Management updates for v4.17-rc2 with top-most
> 
> e04907dbc25930b88ee2328fe692c776f63ddf2c:
> 
>   dt-bindings: thermal: Remove "cooling-{min|max}-level" properties
> (2018-04-18 07:04:28 -0700)
> 
> on top of commit 60cc43fc888428bb2f18f08997432d426a243338:
> 
>   Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
> 
As this does not hit 4.17-rc2, and I have some thermal core fixes now,
would you mind rebase the patches on top of 4.17-rc2, and send the pull
request to me, including the exynos fixes, so that I can pull and queue
for next -rc?

thanks,
rui
> BR,
> 
> Eduardo Valentin
> 
> 
> Bartlomiej Zolnierkiewicz (1):
>   dt-bindings: thermal: remove no longer needed samsung thermal
> properties
> 
> Viresh Kumar (1):
>   dt-bindings: thermal: Remove "cooling-{min|max}-level"
> properties
> 
>  .../devicetree/bindings/thermal/exynos-thermal.txt | 23 +---
> --
>  .../devicetree/bindings/thermal/thermal.txt| 16 +---
> ---
>  2 files changed, 6 insertions(+), 33 deletions(-)


Re: [GIT PULL V3] Thermal SoC management updates for v4.17-rc1

2018-04-18 Thread Zhang Rui
On 三, 2018-04-18 at 07:10 -0700, Eduardo Valentin wrote:
> Hello,
> 
> On Wed, Apr 18, 2018 at 03:51:29PM +0800, Zhang Rui wrote:
> > 
> > Hi, Eduardo,
> > 
> > On 六, 2018-04-14 at 11:30 -0700, Eduardo Valentin wrote:
> > > 
> > > Hello Linus,
> > > 
> > > Please find thermal-soc changes for v4.17-rc1.
> > > Rui asked me to send the pull request directly to you
> > > as we are close to the end of the merge window.
> > > Essentially this pull removes the series that caused
> > > warning regression. I will work with the developer
> > > to get that fixed later on, but I am still sending
> > > the other few patches that are unrelated to that.
> > > Let me know if this causes any issues and can still
> > > be pulled.
> > > 
> > > Changelog:
> > > - New i.MX7 thermal sensor
> > > - Mediatek driver now supports MT7622 SoC
> > > - Removal of min max cpu cooling DT property
> > > 
> > > Differences in V3:
> > > - Rebased on top current linus/master, to avoid and merge issues
> > > from previous pulled thermal code.
> > > 
> > > Differences in V2:
> > > - Reordered the patches to drop exynos changes for now until we
> > > get
> > > agreement on the fix on that driver for the compilation warns
> > > caused by the confusing conversion functions.
> > > 
> > > 
> > > The following changes since commit
> > > 48023102b7078a6674516b1fe0d639669336049d:
> > > 
> > >   Merge branch 'overlayfs-linus' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs (2018-
> > > 04-
> > > 13 16:55:41 -0700)
> > > 
> > > are available in the git repository at:
> > > 
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-
> > > soc-
> > > thermal linus
> > > 
> > > for you to fetch changes up to
> > > 15a32df1918259be6c23fc36014fc26ee66c836c:
> > > 
> > >   dt-bindings: thermal: Remove "cooling-{min|max}-level"
> > > properties
> > > (2018-04-14 09:37:55 -0700)
> > > 
> > This pull request does not catch this merge window.
> > So do you want to split it into 2 separate pull requests, one for
> > 4.17-
> > rc and another for 4.18-rc1?
> OK. Yeah, I am fine with that.
> 
> > 
> > 
> > > 
> > > 
> > > Anson Huang (1):
> > >   thermal: imx: add i.MX7 thermal sensor support
> > > 
> > > Bartlomiej Zolnierkiewicz (1):
> > >   dt-bindings: thermal: remove no longer needed samsung
> > > thermal
> > > properties
> > > 
> > > Sean Wang (2):
> > >   dt-bindings: thermal: add binding for MT7622 SoC
> > >   thermal: mediatek: add support for MT7622 SoC
> > > 
> > > Viresh Kumar (1):
> > >   dt-bindings: thermal: Remove "cooling-{min|max}-level"
> > > properties
> > > 
> > IMO, together with the refreshed exynos fixes, the one from Viresh
> > and
> > the one from Bartlomiej can be queued for 4.17-rc, and the others
> > have
> > to wait until next merge window.
> > 
> Correct, the new chip support will need to wait for the next merge
> window. I have already split the patches into the two categories.
> The patches removing stuff are in my -fixes branch. All the other
> adding
> new chip support are in my -linus branch.
> 
> Now, Do you have anything for this -rc2 ? If not, I will send
> directly
> to Linus the stuff in my -fixes branch. Let me know.
> 
No, I don't have anything for -rc2. so please send pull request to
Linux directly.

thanks,
rui


Re: [GIT PULL V3] Thermal SoC management updates for v4.17-rc1

2018-04-18 Thread Zhang Rui
Hi, Eduardo,

On 六, 2018-04-14 at 11:30 -0700, Eduardo Valentin wrote:
> Hello Linus,
> 
> Please find thermal-soc changes for v4.17-rc1.
> Rui asked me to send the pull request directly to you
> as we are close to the end of the merge window.
> Essentially this pull removes the series that caused
> warning regression. I will work with the developer
> to get that fixed later on, but I am still sending
> the other few patches that are unrelated to that.
> Let me know if this causes any issues and can still
> be pulled.
> 
> Changelog:
> - New i.MX7 thermal sensor
> - Mediatek driver now supports MT7622 SoC
> - Removal of min max cpu cooling DT property
> 
> Differences in V3:
> - Rebased on top current linus/master, to avoid and merge issues
> from previous pulled thermal code.
> 
> Differences in V2:
> - Reordered the patches to drop exynos changes for now until we get
> agreement on the fix on that driver for the compilation warns
> caused by the confusing conversion functions.
> 
> 
> The following changes since commit
> 48023102b7078a6674516b1fe0d639669336049d:
> 
>   Merge branch 'overlayfs-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs (2018-04-
> 13 16:55:41 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-
> thermal linus
> 
> for you to fetch changes up to
> 15a32df1918259be6c23fc36014fc26ee66c836c:
> 
>   dt-bindings: thermal: Remove "cooling-{min|max}-level" properties
> (2018-04-14 09:37:55 -0700)
> 
This pull request does not catch this merge window.
So do you want to split it into 2 separate pull requests, one for 4.17-
rc and another for 4.18-rc1?

> 
> Anson Huang (1):
>   thermal: imx: add i.MX7 thermal sensor support
> 
> Bartlomiej Zolnierkiewicz (1):
>   dt-bindings: thermal: remove no longer needed samsung thermal
> properties
> 
> Sean Wang (2):
>   dt-bindings: thermal: add binding for MT7622 SoC
>   thermal: mediatek: add support for MT7622 SoC
> 
> Viresh Kumar (1):
>   dt-bindings: thermal: Remove "cooling-{min|max}-level"
> properties
> 
IMO, together with the refreshed exynos fixes, the one from Viresh and
the one from Bartlomiej can be queued for 4.17-rc, and the others have
to wait until next merge window.

thanks,
rui


>  .../devicetree/bindings/thermal/exynos-thermal.txt |  23 +-
>  .../devicetree/bindings/thermal/imx-thermal.txt|   9 +-
>  .../bindings/thermal/mediatek-thermal.txt  |   1 +
>  .../devicetree/bindings/thermal/thermal.txt|  16 +-
>  drivers/thermal/imx_thermal.c  | 295
> -
>  drivers/thermal/mtk_thermal.c  |  35 +++
>  6 files changed, 281 insertions(+), 98 deletions(-)


[GIT PULL V2] Thermal management updates for v4.17-rc1

2018-04-13 Thread Zhang Rui
Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next

to receive the latest Thermal Management updates for v4.17-rc1 with
top-most commit b907b408ca64482989cd95dacef804ce509a3673:

  Merge branches 'thermal-core' and 'thermal-soc' into next (2018-04-13 
14:11:53 +0800)

on top of commit 0c8efd610b58cb23cefdfa12015799079aef94ae:

  Linux 4.16-rc5 (2018-03-11 17:25:09 -0700)

Differences in V2:
- Dropped all patches from thermal-soc tree, including the exynos patch
that introduces the compiler warnings.

Specifics:

- Fix race condition in imx_thermal_probe(). (Mikhail Lappo)

- Add cooling device's statistics in sysfs. (Viresh Kumar)

thanks,
rui


Mikhail Lappo (1):
  thermal: imx: Fix race condition in imx_thermal_probe()

Viresh Kumar (1):
  thermal: Add cooling device's statistics in sysfs

Zhang Rui (1):
  Merge branches 'thermal-core' and 'thermal-soc' into next

 Documentation/thermal/sysfs-api.txt |  31 +
 drivers/thermal/Kconfig |   7 ++
 drivers/thermal/imx_thermal.c   |   6 +-
 drivers/thermal/thermal_core.c  |   3 +-
 drivers/thermal/thermal_core.h  |  10 ++
 drivers/thermal/thermal_helpers.c   |   5 +-
 drivers/thermal/thermal_sysfs.c | 225

 include/linux/thermal.h |   1 +
 8 files changed, 283 insertions(+), 5 deletions(-)


Re: [GIT PULL] Thermal management updates for v4.17-rc1

2018-04-12 Thread Zhang Rui
Hi, Eduardo,

On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> Hello,
> 
> On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> > 
> > On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui <rui.zh...@intel.com>
> > wrote:
> > > 
> > > 
> > > could you please illustrate me what the kconfig & warning is?
> > Just "make allmodconfig" and the warning is about a uninitialized
> > variable.
> > 
> > Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell
> > history
> > is to be believed.
> > 
> > Linus
> Yeah, this has also passed my local compilation error. Somehow my
> gcc4.9
> is not catching it. Using an older gcc (gcc4.6) does catch it.
> 
> Anyways, given that the conversion functions are written to cover
> for unexpected cal_type, the right way of fixing this is to rewrite
> the conversion functions to allow for returning error codes and
> adjusting the callers as expected.
> 
> Rui, bzolnier, please consider the following fix:
> 
as it is late in this merge window, I'd prefer to
1. drop all the thermal-soc material in the first pull request which I
will send out soon.
2. you can prepare another pull request containing the thermal-soc
materials except the exynos fixes
3. exynos fixes with the problem solved can be queued for -rc2 or
later.

thanks,
rui

> From 2aaf94f80c0021a21b4122c9f4197acff08ea398 Mon Sep 17 00:00:00
> 2001
> From: Eduardo Valentin <edubez...@gmail.com>
> Date: Thu, 12 Apr 2018 21:00:48 -0700
> Subject: [PATCH 1/1] thermal: exynos: fix compilation warning around
>  conversion functions
> 
> In order to fix the warns:
> drivers/thermal/samsung/exynos_tmu.c:931:37: warning: 'temp' may be
> used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/thermal/samsung/exynos_tmu.c:304:9: warning: 'temp_code' may
> be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> the conversion functions should allow return error codes
> and the not mix the converted value with error code.
> 
> This patch change the conversion functions to return
> error code or success and adjusts the callers accordingly.
> 
> Signed-off-by: Eduardo Valentin <edubez...@gmail.com>
> ---
>  drivers/thermal/samsung/exynos_tmu.c | 120 -
> --
>  1 file changed, 84 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 2ec8548..b3f0704 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -282,52 +282,54 @@ static void exynos_report_trigger(struct
> exynos_tmu_data *p)
>   * TMU treats temperature as a mapped temperature code.
>   * The temperature is converted differently depending on the
> calibration type.
>   */
> -static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
> +static int temp_to_code(struct exynos_tmu_data *data, u8 temp, int
> *temp_code)
>  {
> - int temp_code;
> + int ret = 0;
>  
>   switch (data->cal_type) {
>   case TYPE_TWO_POINT_TRIMMING:
> - temp_code = (temp - EXYNOS_FIRST_POINT_TRIM) *
> + *temp_code = (temp - EXYNOS_FIRST_POINT_TRIM) *
>   (data->temp_error2 - data->temp_error1) /
>   (EXYNOS_SECOND_POINT_TRIM -
> EXYNOS_FIRST_POINT_TRIM) +
>   data->temp_error1;
>   break;
>   case TYPE_ONE_POINT_TRIMMING:
> - temp_code = temp + data->temp_error1 -
> EXYNOS_FIRST_POINT_TRIM;
> + *temp_code = temp + data->temp_error1 -
> EXYNOS_FIRST_POINT_TRIM;
>   break;
>   default:
>   WARN_ON(1);
> + ret = -EINVAL;
>   break;
>   }
>  
> - return temp_code;
> + return ret;
>  }
>  
>  /*
>   * Calculate a temperature value from a temperature code.
>   * The unit of the temperature is degree Celsius.
>   */
> -static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code)
> +static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code,
> int *temp)
>  {
> - int temp;
> + int ret = 0;
>  
>   switch (data->cal_type) {
>   case TYPE_TWO_POINT_TRIMMING:
> - temp = (temp_code - data->temp_error1) *
> + *temp = (temp_code - data->temp_error1) *
>   (EXYNOS_SECOND_POINT_TRIM -
> EXYNOS_FIRST_POINT_TRIM) /
>   (data->temp_error2 - data->temp_error1) +
>   EXYNOS_FIRST_POINT_TRIM;
>   break;
>   case TYPE_ONE_

Re: [GIT PULL] Thermal management updates for v4.17-rc1

2018-04-12 Thread Zhang Rui
On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> Hello,
> 
> On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> > 
> > On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui <rui.zh...@intel.com>
> > wrote:
> > > 
> > > 
> > > could you please illustrate me what the kconfig & warning is?
> > Just "make allmodconfig" and the warning is about a uninitialized
> > variable.
> > 
> > Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell
> > history
> > is to be believed.
> > 
> > Linus
> Yeah, this has also passed my local compilation error. Somehow my
> gcc4.9
> is not catching it. Using an older gcc (gcc4.6) does catch it.
> 

I think there are two problems here

1. Actually, this error has been raised by 0-day earlier.
https://marc.info/?l=linux-pm=152107340117077=2
Don't know why it still goes into thermal-soc tree.

2. After pulled the thermal-soc changes, I also asked 0-day to run
build test, but I didn't get any warning report (email attached), CC
Philip and Shun to look at this issue.

thanks,
rui

bin_6r1piPKmQ.bin
Description: application/mbox


Re: [GIT PULL] Thermal management updates for v4.17-rc1

2018-04-11 Thread Zhang Rui
Hi, Linus,

On 三, 2018-04-11 at 17:01 -0700, Linus Torvalds wrote:
> On Wed, Apr 11, 2018 at 1:41 AM, Zhang Rui <rui.zh...@intel.com>
> wrote:
> > 
> > 
> > Please pull from
> >   git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git
> > next
> Pulled, and then immediately unpulled again.
> 
> The code causes new compiler warnings, and the warnings are valid.
> 
> If people don't care enough about their code to even check the
> warnings, I'm not going to waste one second pulling the resulting
> garbage. It's that simple.
> 

I'm really sorry for this.
could you please illustrate me what the kconfig & warning is?
I didn't
get such warnings from 0-day.

thanks,
rui


[GIT PULL] Thermal management updates for v4.17-rc1

2018-04-11 Thread Zhang Rui
Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next

to receive the latest Thermal Management updates for v4.17-rc1 with
top-most commit f8837aac36cdc7430422cd65f4466071b42654bb:

  Merge branches 'thermal-core' and 'thermal-soc' into next (2018-04-02 
21:49:31 +0800)

on top of commit 0c8efd610b58cb23cefdfa12015799079aef94ae:

  Linux 4.16-rc5 (2018-03-11 17:25:09 -0700)

Specifics:

- Fix race condition in imx_thermal_probe(). (Mikhail Lappo)

- Add cooling device's statistics in sysfs. (Viresh Kumar)

- add support for i.MX7 thermal sensor in imx_thermal driver. (Anson
Huang)

- add support for MT7622 SoC in mtk_thermal driver. (Sean Wang)

- Remove unused min/max cpu cooling DT property. (Viresh Kumar).

- A series of fixes on exynos driver. (Bartlomiej Zolnierkiewicz,
Maciej Purski, Marek Szyprowski)

thanks,
rui




Anson Huang (1):
  thermal: imx: add i.MX7 thermal sensor support

Bartlomiej Zolnierkiewicz (10):
  thermal: exynos: remove unused "type" field from struct
exynos_tmu_platform_data
  thermal: exynos: remove parsing of samsung,
tmu_default_temp_offset property
  thermal: exynos: remove parsing of samsung, tmu_[first,
second]_point_trim properties
  thermal: exynos: remove parsing of samsung, tmu_noise_cancel_mode
property
  thermal: exynos: remove parsing of samsung, tmu[_min,
_max]_efuse_value properties
  thermal: exynos: remove parsing of samsung, tmu_reference_voltage
property
  thermal: exynos: remove parsing of samsung,tmu_gain property
  thermal: exynos: remove parsing of samsung, tmu_cal_type property
  thermal: exynos: remove separate exynos_tmu.h header file
  dt-bindings: thermal: remove no longer needed samsung thermal
properties

Maciej Purski (1):
  thermal: exynos: Read soc_type from match data

Marek Szyprowski (2):
  thermal: exynos: Reading temperature makes sense only when TMU is
turned on
  thermal: exynos: Propagate error value from tmu_read()

Mikhail Lappo (1):
  thermal: imx: Fix race condition in imx_thermal_probe()

Sean Wang (2):
  dt-bindings: thermal: add binding for MT7622 SoC
  thermal: mediatek: add support for MT7622 SoC

Viresh Kumar (2):
  dt-bindings: thermal: Remove "cooling-{min|max}-level" properties
  thermal: Add cooling device's statistics in sysfs

Zhang Rui (2):
  Merge branch 'linus' of git://git.kernel.org/.../evalenti/linux-
soc-thermal into thermal-soc
  Merge branches 'thermal-core' and 'thermal-soc' into next

 .../devicetree/bindings/thermal/exynos-thermal.txt |  23 +-
 .../devicetree/bindings/thermal/imx-thermal.txt|   9 +-
 .../bindings/thermal/mediatek-thermal.txt  |   1 +
 .../devicetree/bindings/thermal/thermal.txt|  16 +-
 Documentation/thermal/sysfs-api.txt|  31 +++
 drivers/thermal/Kconfig|   7 +
 drivers/thermal/imx_thermal.c  | 301
-
 drivers/thermal/mtk_thermal.c  |  35 +++
 drivers/thermal/samsung/exynos_tmu.c   | 268 +--
---
 drivers/thermal/samsung/exynos_tmu.h   |  75 -
 drivers/thermal/thermal_core.c |   3 +-
 drivers/thermal/thermal_core.h |  10 +
 drivers/thermal/thermal_helpers.c  |   5 +-
 drivers/thermal/thermal_sysfs.c| 225
+++
 include/linux/thermal.h|   1 +
 15 files changed, 706 insertions(+), 304 deletions(-)
 delete mode 100644 drivers/thermal/samsung/exynos_tmu.h


Re: [PATCH] time: export nsec_to_clock_t

2018-03-29 Thread Zhang Rui
On 三, 2018-03-28 at 16:11 +0200, Arnd Bergmann wrote:
> nsec_to_clock_t was traditionally used only in the core kernel, now
> we
> have a sysfs file that needs it from a loadable module, causing a
> link-time error:
> 
> ERROR: "nsec_to_clock_t" [drivers/thermal/thermal_sys.ko] undefined!
> 
> This exports the function the same way that we do for related
> interfaces.
> 
> Fixes: 96cea33badc5 ("thermal: Add cooling device's statistics in
> sysfs")
> Signed-off-by: Arnd Bergmann 

Thanks for the fix.
can I take this patch through thermal tree?

thanks,
rui
> ---
>  kernel/time/time.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/time/time.c b/kernel/time/time.c
> index 6fa99213fc72..97a262531f68 100644
> --- a/kernel/time/time.c
> +++ b/kernel/time/time.c
> @@ -768,6 +768,7 @@ u64 nsec_to_clock_t(u64 x)
>   return div_u64(x * 9, (9ull * NSEC_PER_SEC + (USER_HZ / 2))
> / USER_HZ);
>  #endif
>  }
> +EXPORT_SYMBOL(nsec_to_clock_t);
>  
>  u64 jiffies64_to_nsecs(u64 j)
>  {


RE: linux-next: Tree for Mar 22 (thermal)

2018-03-26 Thread Zhang, Rui


> -Original Message-
> From: Eduardo Valentin [mailto:edubez...@gmail.com]
> Sent: Tuesday, March 27, 2018 5:05 AM
> To: Randy Dunlap <rdun...@infradead.org>
> Cc: Stephen Rothwell <s...@canb.auug.org.au>; Linux-Next Mailing List  n...@vger.kernel.org>; Linux Kernel Mailing List  ker...@vger.kernel.org>; Linux PM list <linux...@vger.kernel.org>; Zhang,
> Rui <rui.zh...@intel.com>
> Subject: Re: linux-next: Tree for Mar 22 (thermal)
> Importance: High
> 
> Rui,
> 
> On Thu, Mar 22, 2018 at 10:36:38AM -0700, Randy Dunlap wrote:
> > On 03/22/2018 01:38 AM, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Changes since 20180321:
> > >
> > > The vfs tree still had its build failure for which I reverted a commit.
> > >
> >
> > on i386:
> >
> > ERROR: "nsec_to_clock_t" [drivers/thermal/thermal_sys.ko] undefined!
> >
> > so in drivers/thermal/thermal_sysfs.c, please add:
> >
> > #include 
> >
> >
> > Reported-by: Randy Dunlap <rdun...@infradead.org>
> 
> Are you taking care of this?
> 
No, I missed that email.
Will check it today.

Thanks,
rui
> >
> > thanks,
> > --
> > ~Randy


Re: [PATCH 10/10] dt-bindings: thermal: Remove "cooling-{min|max}-level" properties

2018-03-20 Thread Zhang Rui
On 一, 2018-03-12 at 10:08 +0530, Viresh Kumar wrote:
> On 09-02-18, 14:28, Viresh Kumar wrote:
> > 
> > The "cooling-min-level" and "cooling-max-level" properties are not
> > parsed by any part of kernel currently and the max cooling state of
> > a
> > CPU cooling device is found by referring to the cpufreq table
> > instead.
> > 
> > Remove the unused bindings.
> > 
> > Signed-off-by: Viresh Kumar 
> > ---
> >  Documentation/devicetree/bindings/thermal/thermal.txt | 16 +
> > ---
> >  1 file changed, 1 insertion(+), 15 deletions(-)
> @Zhang/Eduardo: Can you please pick this patch (10/10) as almost
> everything else
> is already lined up for 4.17 ?

I think Eduardo should have reviewed all the DT thermal patches in the
list, but I didn't see his response about this one.

Eduardo,
did you miss this one?

thanks,
rui
> 


Re: [PATCH V4] thermal: Add cooling device's statistics in sysfs

2018-03-19 Thread Zhang Rui
On 二, 2018-03-20 at 09:38 +0800, Viresh Kumar wrote:
> On 14-03-18, 13:44, Viresh Kumar wrote:
> > 
> > I got those warnings as well, and I quietly ignored them :)
> > 
> > I ignored the renaming part for the sake of consistency. The other
> > existing
> > routines for similar purpose are named as:
> > 
> > thermal_cooling_device_type_show
> > thermal_cooling_device_max_state_show
> > thermal_cooling_device_cur_state_show
> > thermal_cooling_device_cur_state_store
> > 
> > for me it made more sense to follow that naming convention. And I
> > didn't use the
> > _RO and _WO variants for the same reason.
> > 
> > Now here is what I propose now:
> > 
> > - You apply this patch as-is and ignore the warning.
> > 
> > - I will send few patches on top of that to do:
> >   - renaming of all such routines to shorter versions.
> >   - Use the _RO or _WO variants of the macro everywhere.
> > 
> > What do you say ?
> @Zhang: Can you please share the way you want this to get merged ?
> And if the
> above is fine with you ?
> 
yes, it works for me.
I will apply the patch later today.

thanks,
rui


Re: [PATCH V4] thermal: Add cooling device's statistics in sysfs

2018-03-14 Thread Zhang Rui
On 二, 2018-03-13 at 15:02 +0800, Zhang Rui wrote:
> Hi, Viresh,
> 
> I will queue it for 4.17, with just one minor fix below.
> 
I got the following warning from checkpatch.pl
---

WARNING: please write a paragraph that describes the config symbol
fully
#147: FILE: drivers/thermal/Kconfig:18:
+config THERMAL_STATISTICS

WARNING: Consider renaming function(s)
'thermal_cooling_device_total_trans_show' to 'total_trans_show'
#391: FILE: drivers/thermal/thermal_sysfs.c:901:
+}

WARNING: Consider renaming function(s)
'thermal_cooling_device_time_in_state_show' to 'time_in_state_show'
#395: FILE: drivers/thermal/thermal_sysfs.c:905:
+static DEVICE_ATTR(time_in_state, 0444,

WARNING: Consider renaming function(s)
'thermal_cooling_device_reset_store' to 'reset_store'
#397: FILE: drivers/thermal/thermal_sysfs.c:907:
+static DEVICE_ATTR(reset, 0200, NULL,
thermal_cooling_device_reset_store);

WARNING: Consider renaming function(s)
'thermal_cooling_device_trans_table_show' to 'trans_table_show'
#398: FILE: drivers/thermal/thermal_sysfs.c:908:
+static DEVICE_ATTR(trans_table, 0444,

total: 0 errors, 5 warnings, 366 lines checked


I'm okay with the first one because the description does not have to be
larger than 3 lines.
the last 4 warnings makes sense to me. I think we should rename the
function and use DEVICE_ATTR_RO() and DEVICE_ATTR_WO() instead.

what do you think?

thanks,
rui

> On 二, 2018-01-16 at 15:22 +0530, Viresh Kumar wrote:
> > 
> > This extends the sysfs interface for thermal cooling devices and
> > exposes
> > some pretty useful statistics. These statistics have proven to be
> > quite
> > useful specially while doing benchmarks related to the task
> > scheduler,
> > where we want to make sure that nothing has disrupted the test,
> > specially the cooling device which may have put constraints on the
> > CPUs.
> > The information exposed here tells us to what extent the CPUs were
> > constrained by the thermal framework.
> > 
> > The write-only "reset" file is used to reset the statistics.
> > 
> > The read-only "time_in_state" file shows the clock_t time spent by
> > the
> > device in the respective cooling states, and it prints one line per
> > cooling state.
> > 
> > The read-only "total_trans" file shows single positive integer
> > value
> > showing the total number of cooling state transitions the device
> > has
> > gone through since the time the cooling device is registered or the
> > time
> > when statistics were reset last.
> > 
> > The read-only "trans_table" file shows a two dimensional matrix,
> > where
> > an entry <i,j> (row i, column j) represents the number of
> > transitions
> > from State_i to State_j.
> > 
> > This is how the directory structure looks like for a single cooling
> > device:
> > 
> > $ ls -R /sys/class/thermal/cooling_device0/
> > /sys/class/thermal/cooling_device0/:
> > cur_state  max_state  power  stats  subsystem  type  uevent
> > 
> > /sys/class/thermal/cooling_device0/power:
> > autosuspend_delay_ms  runtime_active_time  runtime_suspended_time
> > control   runtime_status
> > 
> > /sys/class/thermal/cooling_device0/stats:
> > reset  time_in_state  total_trans  trans_table
> > 
> > This is tested on ARM 64-bit Hisilicon hikey620 board running
> > Ubuntu
> > and
> > ARM 64-bit Hisilicon hikey960 board running Android.
> > 
> > Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
> [snip]
> 
> > 
> > +static void cooling_device_stats_setup(struct
> > thermal_cooling_device
> > *cdev)
> > +{
> > +   struct cooling_dev_stats *stats;
> > +   unsigned long states;
> > +   int var;
> > +
> > +   if (cdev->ops->get_max_state(cdev, ))
> > +   return;
> > +
> > +   states++; /* Total number of states is highest state + 1
> > */
> > +
> > +   var = sizeof(*stats);
> > +   var += sizeof(*stats->time_in_state) * states;
> > +   var += sizeof(*stats->trans_table) * states * states;
> > +
> > +   stats = kzalloc(var, GFP_KERNEL);
> > +   if (!stats)
> > +   return;
> > +
> > +   stats->time_in_state = (ktime_t *)(stats + 1);
> > +   stats->trans_table = (unsigned int *)(stats->time_in_state 
> > +
> > states);
> > +   cdev->stats = stats;
> > +   stats->last_time = ktime_get();
> > +   stats->max_states = states;
> > +   cdev->stats = stats;
> > +
> cdev->stats is set twice here, I will remove the first one.
> 
> thanks,
> rui


Re: int3403_driver_init needs over 330 ms to finish

2018-03-14 Thread Zhang Rui
On 二, 2018-03-13 at 20:39 +0100, Paul Menzel wrote:
> Dear Linux folks,
> 
> 
> Booting the Dell XPS 13 9370 with Linux 4.16-rc4+ and
> `initcall_debug`, 
> shows it is shown that int3403_driver_init needs over 330 ms to run.
> 
>  [2.524839] initcall int3403_driver_init+0x0/0x1000 
> [int3403_thermal] returned 0 after 333972 usecs
> 
I guess most of the time are spent in evaluating ACPI ASL code.
But anyway, please create a bugzilla report and attach both dmesg and
acpidump there.

thanks,
rui
> Please find all Linux messages attached.
> 
> Is there a way to reduce that time?
> 
> 
> Kind regards,
> 
> Paul


Re: [PATCH V4] thermal: Add cooling device's statistics in sysfs

2018-03-13 Thread Zhang Rui
Hi, Viresh,

I will queue it for 4.17, with just one minor fix below.

On 二, 2018-01-16 at 15:22 +0530, Viresh Kumar wrote:
> This extends the sysfs interface for thermal cooling devices and
> exposes
> some pretty useful statistics. These statistics have proven to be
> quite
> useful specially while doing benchmarks related to the task
> scheduler,
> where we want to make sure that nothing has disrupted the test,
> specially the cooling device which may have put constraints on the
> CPUs.
> The information exposed here tells us to what extent the CPUs were
> constrained by the thermal framework.
> 
> The write-only "reset" file is used to reset the statistics.
> 
> The read-only "time_in_state" file shows the clock_t time spent by
> the
> device in the respective cooling states, and it prints one line per
> cooling state.
> 
> The read-only "total_trans" file shows single positive integer value
> showing the total number of cooling state transitions the device has
> gone through since the time the cooling device is registered or the
> time
> when statistics were reset last.
> 
> The read-only "trans_table" file shows a two dimensional matrix,
> where
> an entry  (row i, column j) represents the number of transitions
> from State_i to State_j.
> 
> This is how the directory structure looks like for a single cooling
> device:
> 
> $ ls -R /sys/class/thermal/cooling_device0/
> /sys/class/thermal/cooling_device0/:
> cur_state  max_state  power  stats  subsystem  type  uevent
> 
> /sys/class/thermal/cooling_device0/power:
> autosuspend_delay_ms  runtime_active_time  runtime_suspended_time
> control   runtime_status
> 
> /sys/class/thermal/cooling_device0/stats:
> reset  time_in_state  total_trans  trans_table
> 
> This is tested on ARM 64-bit Hisilicon hikey620 board running Ubuntu
> and
> ARM 64-bit Hisilicon hikey960 board running Android.
> 
> Signed-off-by: Viresh Kumar 

[snip]

> +static void cooling_device_stats_setup(struct thermal_cooling_device
> *cdev)
> +{
> + struct cooling_dev_stats *stats;
> + unsigned long states;
> + int var;
> +
> + if (cdev->ops->get_max_state(cdev, ))
> + return;
> +
> + states++; /* Total number of states is highest state + 1 */
> +
> + var = sizeof(*stats);
> + var += sizeof(*stats->time_in_state) * states;
> + var += sizeof(*stats->trans_table) * states * states;
> +
> + stats = kzalloc(var, GFP_KERNEL);
> + if (!stats)
> + return;
> +
> + stats->time_in_state = (ktime_t *)(stats + 1);
> + stats->trans_table = (unsigned int *)(stats->time_in_state +
> states);
> + cdev->stats = stats;
> + stats->last_time = ktime_get();
> + stats->max_states = states;
> + cdev->stats = stats;
> +

cdev->stats is set twice here, I will remove the first one.

thanks,
rui


Re: [PATCH V6 2/2] thermal: imx: add i.MX7 thermal sensor support

2018-03-13 Thread Zhang Rui
yeah, will review it and get back to you later.

On 二, 2018-03-13 at 06:13 +, Anson Huang wrote:
> Ping...
> 
> @rui.zh...@intel.com, can you help review this patch?
> 
> Anson Huang
> Best Regards!
> 
> 
> > 
> > -Original Message-
> > From: linux-arm-kernel [mailto:linux-arm-kernel-bounces@lists.infra
> > dead.org]
> > On Behalf Of Anson Huang
> > Sent: Friday, March 2, 2018 10:00 AM
> > To: Leonard Crestez ; rui.zh...@intel.com;
> > edubez...@gmail.com; robh...@kernel.org; mark.rutl...@arm.com;
> > shawn...@kernel.org; ker...@pengutronix.de; Fabio Estevam
> > ; li...@armlinux.org.uk
> > Cc: linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.or
> > g;
> > dl-linux-imx ; linux-kernel@vger.kernel.org;
> > linux...@vger.kernel.org
> > Subject: [PATCH V6 2/2] thermal: imx: add i.MX7 thermal sensor
> > support
> > 
> > This patch adds i.MX7 thermal sensor support, most of the i.MX7
> > thermal sensor
> > functions are same with
> > i.MX6 except the registers offset/layout, so we move those
> > registers
> > offset/layout definitions to soc data structure.
> > 
> > i.MX7 uses single calibration data @25C, the calibration data is
> > located at
> > OCOTP offset 0x4F0, bit[17:9], the formula is as below:
> > 
> > Tmeas = (Nmeas - n1) + 25; n1 is the fuse value for 25C.
> > 
> > Signed-off-by: Anson Huang 
> > Signed-off-by: Bai Ping 
> > Acked-by: Dong Aisheng 
> > Acked-by: Shawn Guo 
> > Reviewed-by: Rob Herring 
> > ---
> > changes since V5:
> > no code change, just add Reviewed-by.
> >  .../devicetree/bindings/thermal/imx-thermal.txt|   9 +-
> >  drivers/thermal/imx_thermal.c  | 295
> > -
> >  2 files changed, 239 insertions(+), 65 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/thermal/imx-
> > thermal.txt
> > b/Documentation/devicetree/bindings/thermal/imx-thermal.txt
> > index 28be51a..38bffcc 100644
> > --- a/Documentation/devicetree/bindings/thermal/imx-thermal.txt
> > +++ b/Documentation/devicetree/bindings/thermal/imx-thermal.txt
> > @@ -1,8 +1,13 @@
> >  * Temperature Monitor (TEMPMON) on Freescale i.MX SoCs
> > 
> >  Required properties:
> > -- compatible : "fsl,imx6q-tempmon" for i.MX6Q, "fsl,imx6sx-
> > tempmon" for
> > i.MX6SX.
> > -  i.MX6SX has two more IRQs than i.MX6Q, one is IRQ_LOW and the
> > other is
> > IRQ_PANIC,
> > +- compatible : must be one of following:
> > +  - "fsl,imx6q-tempmon" for i.MX6Q,
> > +  - "fsl,imx6sx-tempmon" for i.MX6SX,
> > +  - "fsl,imx7d-tempmon" for i.MX7S/D.
> > +- interrupts : the interrupt output of the controller:
> > +  i.MX6Q has one IRQ which will be triggered when temperature is
> > higher
> > +than high threshold,
> > +  i.MX6SX and i.MX7S/D have two more IRQs than i.MX6Q, one is
> > IRQ_LOW
> > +and the other is IRQ_PANIC,
> >    when temperature is below than low threshold, IRQ_LOW will be
> > triggered,
> > when temperature
> >    is higher than panic threshold, system will auto reboot by SRC
> > module.
> >  - fsl,tempmon : phandle pointer to system controller that contains
> > TEMPMON
> > diff --git a/drivers/thermal/imx_thermal.c
> > b/drivers/thermal/imx_thermal.c
> > index a67781b..569d41b 100644
> > --- a/drivers/thermal/imx_thermal.c
> > +++ b/drivers/thermal/imx_thermal.c
> > @@ -31,35 +31,57 @@
> >  #define REG_CLR0x8
> >  #define REG_TOG0xc
> > 
> > -#define MISC0  0x0150
> > -#define MISC0_REFTOP_SELBIASOFF(1 << 3)
> > -#define MISC1  0x0160
> > -#define MISC1_IRQ_TEMPHIGH (1 << 29)
> > +/* i.MX6 specific */
> > +#define IMX6_MISC0 0x0150
> > +#define IMX6_MISC0_REFTOP_SELBIASOFF   (1 << 3)
> > +#define IMX6_MISC1 0x0160
> > +#define IMX6_MISC1_IRQ_TEMPHIGH(1 << 29)
> >  /* Below LOW and PANIC bits are only for TEMPMON_IMX6SX */
> > -#define MISC1_IRQ_TEMPLOW  (1 << 28)
> > -#define MISC1_IRQ_TEMPPANIC(1 << 27)
> > -
> > -#define TEMPSENSE0 0x0180
> > -#define TEMPSENSE0_ALARM_VALUE_SHIFT   20
> > -#define TEMPSENSE0_ALARM_VALUE_MASK(0xfff <<
> > TEMPSENSE0_ALARM_VALUE_SHIFT)
> > -#define TEMPSENSE0_TEMP_CNT_SHIFT  8
> > -#define TEMPSENSE0_TEMP_CNT_MASK   (0xfff <<
> > TEMPSENSE0_TEMP_CNT_SHIFT)
> > -#define TEMPSENSE0_FINISHED(1 << 2)
> > -#define TEMPSENSE0_MEASURE_TEMP(1 << 1)
> > -#define TEMPSENSE0_POWER_DOWN  (1 << 0)
> > -
> > -#define TEMPSENSE1 0x0190
> > -#define TEMPSENSE1_MEASURE_FREQ0x
> > -/* Below TEMPSENSE2 is only for TEMPMON_IMX6SX */
> > -#define TEMPSENSE2 0x0290
> > -#define TEMPSENSE2_LOW_VALUE_SHIFT 0
> > -#define TEMPSENSE2_LOW_VALUE_MASK  0xfff
> > 

Re: [RESEND PATCH v3 1/2] acpi: thermal: initialize tz_enabled to 1

2018-02-27 Thread Zhang Rui
On Tue, 2018-02-27 at 17:17 +0100, Rafael J. Wysocki wrote:
> On Mon, Feb 26, 2018 at 3:41 PM, Enric Balletbo i Serra
> <enric.balle...@collabora.com> wrote:
> > 
> > From: Sameer Nanda <sna...@chromium.org>
> > 
> > In the acpi_thermal_add path, acpi_thermal_get_info gets called
> > before
> > acpi_thermal_register_thermal_zone.  Since tz_enabled was getting
> > set to
> > 1 only in acpi_thermal_register_thermal_zone, acpi_thermal_get_info
> > ended up disabling thermal polling.
> > 
> > Moved setting of tz_enabled to 1 into acpi_thermal_add itself.
> > 
> > Signed-off-by: Sameer Nanda <sna...@chromium.org>
> > Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com
> > >
> > ---
> > That's another attempt to land these to patches that were sent long
> > time
> > ago but never got merged, although, apparently, there is no issue
> > with
> > it. Latest discussion about these here:
> > 
> >  https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg14360
> > 81.html
> I can apply this one, but the other one has to go in through the
> Rui's tree.
> 
No, the patch set was queued in my tree and then dropped.

This is because, the second patch makes the assumption that the soc
thermal driver .get_mode() must reflect the real thermal zone status
upon the thermal zone registration, but this is not true after checking
some of the driver code.

To apply patch 2/2, extra effort, which checks and fixes all the
thermal drivers one by one, is needed. It would be nice if someone can
do this, or else I will work on this, but some time later.

thanks,
rui
> > 
> > Changes in v3:
> > - [1/2] Make sure tz->tz_enabled is set properly before registering
> > the
> >   zone (Zhang Rui)
> > 
> > Changes in v2:
> > - [1/2] This patch is new from v1
> >   (https://patchwork.kernel.org/patch/9804229/)
> > 
> >  drivers/acpi/thermal.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
> > index 551b71a24b85..1d8f185e96c6 100644
> > --- a/drivers/acpi/thermal.c
> > +++ b/drivers/acpi/thermal.c
> > @@ -930,8 +930,6 @@ static int
> > acpi_thermal_register_thermal_zone(struct acpi_thermal *tz)
> > if (ACPI_FAILURE(status))
> > return -ENODEV;
> > 
> > -   tz->tz_enabled = 1;
> > -
> > dev_info(>device->dev, "registered as
> > thermal_zone%d\n",
> >  tz->thermal_zone->id);
> > return 0;
> > @@ -1088,6 +1086,7 @@ static int acpi_thermal_add(struct
> > acpi_device *device)
> > return -ENOMEM;
> > 
> > tz->device = device;
> > +   tz->tz_enabled = 1;
> > strcpy(tz->name, device->pnp.bus_id);
> > strcpy(acpi_device_name(device), ACPI_THERMAL_DEVICE_NAME);
> > strcpy(acpi_device_class(device), ACPI_THERMAL_CLASS);
> > --
> > 2.16.1
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-
> > acpi" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html


[GIT PULL] Thermal management updates for v4.16-rc1

2018-02-06 Thread Zhang Rui
Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next

to receive the latest Thermal Management updates for v4.16-rc1 with
top-most commit 134f4010799a30acd969e603985c27b9f3e6f58d:

  Merge branches 'thermal-core', 'thermal-intel' and 'thermal-soc' into
next (2018-01-15 13:57:18 +0800)

on top of commit 464e1d5f23cca236b930ef068c328a64cab78fb1:

  Linux 4.15-rc5 (2017-12-23 20:47:16 -0800)

Specifics:
 - Fix a race condition issue in power allocator governor (Yi Zeng).
 - Add support for AP806 and CP110 in armada thermal driver, together
with several improvements (Baruch Siach, Miquel Raynal).
 - Add support for r8z7743 in rcar thermal driver (Biju Das).
 - convert thermal core to use new hwmon API to avoid warning (Fabio
Estevam).
 - Small fixes and cleanups in thermal core and x86_pkg_thermal,
int3400_thermal, hisi_thermal, mtk_thermal and imx_thermal drivers
(Pravin Shedge, Geert Uytterhoeven, Alexey Khoroshilov, Brian Bian,
Matthias Brugger, Nicolin Chen, Uwe Kleine-König).

thanks,
rui

Alexey Khoroshilov (1):
  thermal: int3400_thermal: fix error handling in
int3400_thermal_probe()

Baruch Siach (4):
  dt-bindings: thermal: Describe Armada AP806 and CP110
  thermal: armada: Use msleep for long delays
  thermal: armada: Add support for Armada AP806
  thermal: armada: Add support for Armada CP110

Biju Das (1):
  dt-bindings: thermal: rcar: Add device tree support for r8a7743

Brian Bian (1):
  thermal: int3400_thermal: Ignore Unknown Notification Codes

Fabio Estevam (1):
  thermal: thermal_hwmon: Convert to
hwmon_device_register_with_info()

Geert Uytterhoeven (2):
  thermal/drivers/hisi: Remove bogus const from function return
type
  thermal/x86 pkg temp: Remove debugfs_create_u32() casts

Matthias Brugger (1):
  thermal: mtk: Cleanup unused defines

Miquel Raynal (7):
  thermal: armada: Simplify the check of the validity bit
  thermal: armada: Clarify control registers accesses
  thermal: armada: Use real status register name
  thermal: armada: Update Kconfig and module description
  thermal: armada: Change sensors trim default value
  thermal: armada: Wait sensors validity before exiting the init
callback
  thermal: armada: Give meaningful names to the thermal zones

Nicolin Chen (1):
  thermal: tegra: remove forward declarations

Pravin Shedge (1):
  drivers: thermal: remove duplicate includes

Uwe Kleine-König (4):
  thermal: imx: Use better parameter names than "val"
  thermal: imx: improve comments describing algorithm for temp
calculation
  thermal: imx: use consistent style to write temperatures
  thermal: imx: update to new formula according to NXP AN5215

Yi Zeng (1):
  thermal: power_allocator: fix one race condition issue for
thermal_instances list

Zhang Rui (2):
  Merge branch 'linus' of git://git.kernel.org/.../evalenti/linux-
soc-thermal into thermal-soc
  Merge branches 'thermal-core', 'thermal-intel' and 'thermal-soc'
into next

 .../devicetree/bindings/thermal/armada-thermal.txt |  37 ++-
 .../devicetree/bindings/thermal/rcar-thermal.txt   |   1 +
 drivers/thermal/Kconfig|   4 +-
 drivers/thermal/armada_thermal.c   | 253
+++--
 drivers/thermal/hisi_thermal.c |   2 +-
 drivers/thermal/imx_thermal.c  |  74 +++---
 drivers/thermal/int340x_thermal/int3400_thermal.c  |  12 +-
 drivers/thermal/mtk_thermal.c  |   9 +-
 drivers/thermal/of-thermal.c   |   1 -
 drivers/thermal/power_allocator.c  |   2 +
 drivers/thermal/tegra/soctherm.c   | 103 -
 drivers/thermal/thermal_hwmon.c|  20 +-
 drivers/thermal/x86_pkg_temp_thermal.c |   4 +-
 13 files changed, 312 insertions(+), 210 deletions(-)


Re: [RFC] intel-lpss: remove .prepare() callback

2018-01-26 Thread Zhang Rui
Hi, Andy,

On Thu, 2018-01-25 at 14:28 +0200, Andy Shevchenko wrote:
> On Thu, 2018-01-25 at 16:12 +0800, Zhang Rui wrote:
> > 
> > The .prepare() callback of intel-lpss driver does nothing but wakes
> > up
> > its
> > children. I don't know if there is any reason to do so, but to me,
> > this is
> > not preferred because it should be the child device driver to do so
> > when
> > necessary, not the parent device driver.
> > Plus, .prepare() does not support asynchronization.
> > 
> > For example, on MS Surface Pro 4, there are 4 intel-lpss devices
> > which
> > are runtime suspended before system suspend, resuming each of them
> > takes
> > more than 100 milliseconds. Thus the .prepare() of intel-lpss
> > driver
> > takes
> > 400ms+ on my surface pro 4, and I've seen platforms with 16 intel
> > lpss
> > devices.
> > 
> > With this patch applied, the child devices are resumed in the
> > .suspend()
> > stage of the child device, and they are done in parallel, thus only
> > 100ms
> > is needed, no matter how many intel lpss devices there are.
> > 
> > I have tested it on three different platforms and didn't find any
> > obvious
> > problem caused by this patch, and it indeed reduces the suspend
> > time a
> > lot.
> > 
> > @@ -482,17 +482,6 @@ static int resume_lpss_device(struct device
> > *dev,
> > -   device_for_each_child_reverse(dev, NULL,
> > resume_lpss_device);
> Besides introduced compiler warning, did you check the latest linux-
> pm
> changes? 
> 
> commit 8425ec7faff005500aad89b9fc00e5ba91ac57b9
> Author: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> Date:   Wed Jan 3 01:34:53 2018 +0100
> 
> PM / mfd: intel-lpss: Use DPM_FLAG_SMART_SUSPEND
> 
No, thanks for the pointer, I will check this.

BTW, is there any reason that we need this .prepare() callback?

thanks,
rui


[RFC] intel-lpss: remove .prepare() callback

2018-01-25 Thread Zhang Rui
The .prepare() callback of intel-lpss driver does nothing but wakes up its
children. I don't know if there is any reason to do so, but to me, this is
not preferred because it should be the child device driver to do so when
necessary, not the parent device driver.
Plus, .prepare() does not support asynchronization.

For example, on MS Surface Pro 4, there are 4 intel-lpss devices which
are runtime suspended before system suspend, resuming each of them takes
more than 100 milliseconds. Thus the .prepare() of intel-lpss driver takes
400ms+ on my surface pro 4, and I've seen platforms with 16 intel lpss
devices.

With this patch applied, the child devices are resumed in the .suspend()
stage of the child device, and they are done in parallel, thus only 100ms
is needed, no matter how many intel lpss devices there are.

I have tested it on three different platforms and didn't find any obvious
problem caused by this patch, and it indeed reduces the suspend time a lot.

Signed-off-by: Zhang Rui <rui.zh...@intel.com>
---
 drivers/mfd/intel-lpss.c | 11 ---
 drivers/mfd/intel-lpss.h |  2 --
 2 files changed, 13 deletions(-)

diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
index 0e0ab9b..5ff31e9 100644
--- a/drivers/mfd/intel-lpss.c
+++ b/drivers/mfd/intel-lpss.c
@@ -482,17 +482,6 @@ static int resume_lpss_device(struct device *dev, void 
*data)
return 0;
 }
 
-int intel_lpss_prepare(struct device *dev)
-{
-   /*
-* Resume both child devices before entering system sleep. This
-* ensures that they are in proper state before they get suspended.
-*/
-   device_for_each_child_reverse(dev, NULL, resume_lpss_device);
-   return 0;
-}
-EXPORT_SYMBOL_GPL(intel_lpss_prepare);
-
 int intel_lpss_suspend(struct device *dev)
 {
struct intel_lpss *lpss = dev_get_drvdata(dev);
diff --git a/drivers/mfd/intel-lpss.h b/drivers/mfd/intel-lpss.h
index 865bbea..7913b58 100644
--- a/drivers/mfd/intel-lpss.h
+++ b/drivers/mfd/intel-lpss.h
@@ -31,13 +31,11 @@ int intel_lpss_probe(struct device *dev,
 void intel_lpss_remove(struct device *dev);
 
 #ifdef CONFIG_PM
-int intel_lpss_prepare(struct device *dev);
 int intel_lpss_suspend(struct device *dev);
 int intel_lpss_resume(struct device *dev);
 
 #ifdef CONFIG_PM_SLEEP
 #define INTEL_LPSS_SLEEP_PM_OPS\
-   .prepare = intel_lpss_prepare,  \
SET_LATE_SYSTEM_SLEEP_PM_OPS(intel_lpss_suspend, intel_lpss_resume)
 #else
 #define INTEL_LPSS_SLEEP_PM_OPS
-- 
2.7.4



Re: [PATCH] thermal: power_allocator: fix one race condition issue for thermal_instances list

2017-12-26 Thread Zhang Rui
On Tue, 2017-12-26 at 19:22 +0800, Yi Zeng wrote:
> When invoking allow_maximum_power and traverse tz->thermal_instances,
> we should grab thermal_zone_device->lock to avoid race condition. For
> example, during the system reboot, if the mali GPU device implements
> device shutdown callback and unregister GPU devfreq cooling device,
> the deleted list head may be accessed to cause panic, as the
> following
> log shows:
> 
> [   33.551070] c3 25 (kworker/3:0) Unable to handle kernel paging
> request at virtual address dead0070
> [   33.566708] c3 25 (kworker/3:0) pgd = ffc0ed29
> [   33.572071] c3 25 (kworker/3:0) [dead0070]
> *pgd=0001ed292003, *pud=0001ed292003, *pmd=
> [   33.581515] c3 25 (kworker/3:0) Internal error: Oops: 9604
> [#1] PREEMPT SMP
> [   33.599761] c3 25 (kworker/3:0) CPU: 3 PID: 25 Comm: kworker/3:0
> Not tainted 4.4.35+ #912
> [   33.614137] c3 25 (kworker/3:0) Workqueue: events_freezable
> thermal_zone_device_check
> [   33.620245] c3 25 (kworker/3:0) task: ffc0f32e4200 ti:
> ffc0f32f task.ti: ffc0f32f
> [   33.629466] c3 25 (kworker/3:0) PC is at
> power_allocator_throttle+0x7c8/0x8a4
> [   33.636609] c3 25 (kworker/3:0) LR is at
> power_allocator_throttle+0x808/0x8a4
> [   33.643742] c3 25 (kworker/3:0) pc : [] lr :
> [] pstate: 2145
> [   33.652874] c3 25 (kworker/3:0) sp : ffc0f32f3bb0
> [   34.468519] c3 25 (kworker/3:0) Process kworker/3:0 (pid: 25,
> stack limit = 0xffc0f32f0020)
> [   34.477220] c3 25 (kworker/3:0) Stack: (0xffc0f32f3bb0 to
> 0xffc0f32f4000)
> [   34.819822] c3 25 (kworker/3:0) Call trace:
> [   34.824021] c3 25 (kworker/3:0) Exception stack(0xffc0f32f39c0
> to 0xffc0f32f3af0)
> [   34.924993] c3 25 (kworker/3:0) []
> power_allocator_throttle+0x7c8/0x8a4
> [   34.933184] c3 25 (kworker/3:0) []
> handle_thermal_trip.part.25+0x70/0x224
> [   34.941545] c3 25 (kworker/3:0) []
> thermal_zone_device_update+0xc0/0x20c
> [   34.949818] c3 25 (kworker/3:0) []
> thermal_zone_device_check+0x20/0x2c
> [   34.957924] c3 25 (kworker/3:0) []
> process_one_work+0x168/0x458
> [   34.965414] c3 25 (kworker/3:0) []
> worker_thread+0x13c/0x4b4
> [   34.972650] c3 25 (kworker/3:0) []
> kthread+0xe8/0xfc
> [   34.979187] c3 25 (kworker/3:0) []
> ret_from_fork+0x10/0x40
> [   34.986244] c3 25 (kworker/3:0) Code: f9405e73 eb1302bf d102e273
> 54ffc460 (b9402a61)
> [   34.994339] c3 25 (kworker/3:0) ---[ end trace 32057901e3b7e1db ]-
> --
> 
> Signed-off-by: Yi Zeng 

applied.

thanks,
rui
> ---
>  drivers/thermal/power_allocator.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/thermal/power_allocator.c
> b/drivers/thermal/power_allocator.c
> index b4d3116..3055f9a 100644
> --- a/drivers/thermal/power_allocator.c
> +++ b/drivers/thermal/power_allocator.c
> @@ -523,6 +523,7 @@ static void allow_maximum_power(struct
> thermal_zone_device *tz)
>   struct thermal_instance *instance;
>   struct power_allocator_params *params = tz->governor_data;
>  
> + mutex_lock(>lock);
>   list_for_each_entry(instance, >thermal_instances,
> tz_node) {
>   if ((instance->trip != params-
> >trip_max_desired_temperature) ||
>   (!cdev_is_power_actor(instance->cdev)))
> @@ -534,6 +535,7 @@ static void allow_maximum_power(struct
> thermal_zone_device *tz)
>   mutex_unlock(>cdev->lock);
>   thermal_cdev_update(instance->cdev);
>   }
> + mutex_unlock(>lock);
>  }
>  
>  /**


Re: [PATCH 20/45] drivers: thermal: remove duplicate includes

2017-12-26 Thread Zhang Rui
On Wed, 2017-12-06 at 22:10 +0530, Pravin Shedge wrote:
> These duplicate includes have been found with
> scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
> 
> Signed-off-by: Pravin Shedge 

applied.

thanks,
rui
> ---
>  drivers/thermal/of-thermal.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-
> thermal.c
> index d04ec3b..e09f035 100644
> --- a/drivers/thermal/of-thermal.c
> +++ b/drivers/thermal/of-thermal.c
> @@ -30,7 +30,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #include "thermal_core.h"
>  


Re: [PATCH 1/2] thermal: mtk: Cleanup unused defines

2017-12-21 Thread Zhang Rui
On Thu, 2017-12-21 at 11:01 +0100, Matthias Brugger wrote:
> 
> On 12/01/2017 11:43 AM, Matthias Brugger wrote:
> > 
> > The mtk_thermal has some defiens which are never used within the
> > driver.
> > This patch delets them.
> > 
> > Signed-off-by: Matthias Brugger 
> > ---
> Rui, Eduardo, do you have any comments on this patch?
> 
No, I don't have any.
I suppose Eduardo will review them soon as I need the thermal soc
material for next merge window.

thanks,
rui
> Regards,
> Matthias
> 
> > 
> >  drivers/thermal/mtk_thermal.c | 9 +
> >  1 file changed, 1 insertion(+), 8 deletions(-)
> > 
> > diff --git a/drivers/thermal/mtk_thermal.c
> > b/drivers/thermal/mtk_thermal.c
> > index 1e61c09153c9..c75661a3801a 100644
> > --- a/drivers/thermal/mtk_thermal.c
> > +++ b/drivers/thermal/mtk_thermal.c
> > @@ -32,15 +32,10 @@
> >  #include 
> >  
> >  /* AUXADC Registers */
> > -#define AUXADC_CON0_V  0x000
> > -#define AUXADC_CON1_V  0x004
> >  #define AUXADC_CON1_SET_V  0x008
> >  #define AUXADC_CON1_CLR_V  0x00c
> >  #define AUXADC_CON2_V  0x010
> >  #define AUXADC_DATA(channel)   (0x14 + (channel) * 4)
> > -#define AUXADC_MISC_V  0x094
> > -
> > -#define AUXADC_CON1_CHANNEL(x) BIT(x)
> >  
> >  #define APMIXED_SYS_TS_CON10x604
> >  
> > @@ -158,8 +153,6 @@
> >  /* The number of sensing points per bank */
> >  #define MT2712_NUM_SENSORS_PER_ZONE4
> >  
> > -#define THERMAL_NAME"mtk-thermal"
> > -
> >  struct mtk_thermal;
> >  
> >  struct thermal_bank_cfg {
> > @@ -765,7 +758,7 @@ static struct platform_driver
> > mtk_thermal_driver = {
> >     .probe = mtk_thermal_probe,
> >     .remove = mtk_thermal_remove,
> >     .driver = {
> > -   .name = THERMAL_NAME,
> > +   .name = "mtk-thermal",
> >     .of_match_table = mtk_thermal_of_match,
> >     },
> >  };
> > 


Re: [-next PATCH 4/4] treewide: Use DEVICE_ATTR_WO

2017-12-20 Thread Zhang Rui
On Tue, 2017-12-19 at 10:15 -0800, Joe Perches wrote:
> Convert DEVICE_ATTR uses to DEVICE_ATTR_WO where possible.
> 
> Done with perl script:
> 
> $ git grep -w --name-only DEVICE_ATTR | \
>   xargs perl -i -e 'local $/; while (<>) {
> s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(?:\s*S_IWUSR\s*|\s*0200\s*)\)?
> \s*,\s*NULL\s*,\s*\s_store\s*\)/DEVICE_ATTR_WO(\1)/g; print;}'
> 
> Signed-off-by: Joe Perches <j...@perches.com>
> ---
>  arch/s390/kernel/smp.c | 2 +-
>  arch/x86/kernel/cpu/microcode/core.c   | 2 +-
>  drivers/input/touchscreen/elants_i2c.c | 2 +-
>  drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
>  drivers/net/wimax/i2400m/sysfs.c   | 3 +--
>  drivers/scsi/lpfc/lpfc_attr.c  | 3 +--
>  drivers/thermal/thermal_sysfs.c| 2 +-

For the thermal part,
Acked-by: Zhang Rui <rui.zh...@intel.com>

thanks,
rui

>  7 files changed, 7 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
> index b8c1a85bcf2d..a919b2f0141d 100644
> --- a/arch/s390/kernel/smp.c
> +++ b/arch/s390/kernel/smp.c
> @@ -1151,7 +1151,7 @@ static ssize_t __ref rescan_store(struct device
> *dev,
>   rc = smp_rescan_cpus();
>   return rc ? rc : count;
>  }
> -static DEVICE_ATTR(rescan, 0200, NULL, rescan_store);
> +static DEVICE_ATTR_WO(rescan);
>  #endif /* CONFIG_HOTPLUG_CPU */
>  
>  static int __init s390_smp_init(void)
> diff --git a/arch/x86/kernel/cpu/microcode/core.c
> b/arch/x86/kernel/cpu/microcode/core.c
> index c4fa4a85d4cb..09c74b0560dd 100644
> --- a/arch/x86/kernel/cpu/microcode/core.c
> +++ b/arch/x86/kernel/cpu/microcode/core.c
> @@ -560,7 +560,7 @@ static ssize_t pf_show(struct device *dev,
>   return sprintf(buf, "0x%x\n", uci->cpu_sig.pf);
>  }
>  
> -static DEVICE_ATTR(reload, 0200, NULL, reload_store);
> +static DEVICE_ATTR_WO(reload);
>  static DEVICE_ATTR(version, 0400, version_show, NULL);
>  static DEVICE_ATTR(processor_flags, 0400, pf_show, NULL);
>  
> diff --git a/drivers/input/touchscreen/elants_i2c.c
> b/drivers/input/touchscreen/elants_i2c.c
> index a458e5ec9e41..819213e88f32 100644
> --- a/drivers/input/touchscreen/elants_i2c.c
> +++ b/drivers/input/touchscreen/elants_i2c.c
> @@ -1000,7 +1000,7 @@ static ssize_t show_iap_mode(struct device
> *dev,
>   "Normal" : "Recovery");
>  }
>  
> -static DEVICE_ATTR(calibrate, S_IWUSR, NULL, calibrate_store);
> +static DEVICE_ATTR_WO(calibrate);
>  static DEVICE_ATTR(iap_mode, S_IRUGO, show_iap_mode, NULL);
>  static DEVICE_ATTR(update_fw, S_IWUSR, NULL, write_update_fw);
>  
> diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
> b/drivers/net/ethernet/ibm/ibmvnic.c
> index 1dc4aef37d3a..42b96e1a1b13 100644
> --- a/drivers/net/ethernet/ibm/ibmvnic.c
> +++ b/drivers/net/ethernet/ibm/ibmvnic.c
> @@ -4411,7 +4411,7 @@ static ssize_t failover_store(struct device
> *dev, struct device_attribute *attr,
>   return count;
>  }
>  
> -static DEVICE_ATTR(failover, 0200, NULL, failover_store);
> +static DEVICE_ATTR_WO(failover);
>  
>  static unsigned long ibmvnic_get_desired_dma(struct vio_dev *vdev)
>  {
> diff --git a/drivers/net/wimax/i2400m/sysfs.c
> b/drivers/net/wimax/i2400m/sysfs.c
> index 1237109f251a..8c67df11105c 100644
> --- a/drivers/net/wimax/i2400m/sysfs.c
> +++ b/drivers/net/wimax/i2400m/sysfs.c
> @@ -65,8 +65,7 @@ ssize_t i2400m_idle_timeout_store(struct device
> *dev,
>  }
>  
>  static
> -DEVICE_ATTR(i2400m_idle_timeout, S_IWUSR,
> - NULL, i2400m_idle_timeout_store);
> +DEVICE_ATTR_WO(i2400m_idle_timeout);
>  
>  static
>  struct attribute *i2400m_dev_attrs[] = {
> diff --git a/drivers/scsi/lpfc/lpfc_attr.c
> b/drivers/scsi/lpfc/lpfc_attr.c
> index 517ff203cfde..6ddaf51a23f6 100644
> --- a/drivers/scsi/lpfc/lpfc_attr.c
> +++ b/drivers/scsi/lpfc/lpfc_attr.c
> @@ -2418,8 +2418,7 @@ lpfc_soft_wwn_enable_store(struct device *dev,
> struct device_attribute *attr,
>  
>   return count;
>  }
> -static DEVICE_ATTR(lpfc_soft_wwn_enable, S_IWUSR, NULL,
> -    lpfc_soft_wwn_enable_store);
> +static DEVICE_ATTR_WO(lpfc_soft_wwn_enable);
>  
>  /**
>   * lpfc_soft_wwpn_show - Return the cfg soft ww port name of the
> adapter
> diff --git a/drivers/thermal/thermal_sysfs.c
> b/drivers/thermal/thermal_sysfs.c
> index 2bc964392924..ba81c9080f6e 100644
> --- a/drivers/thermal/thermal_sysfs.c
> +++ b/drivers/thermal/thermal_sysfs.c
> @@ -317,7 +317,7 @@ emul_temp_store(struct device *dev, struct
> device_attribute *attr,
>  
>   return ret ? ret : count;
>  }
> -static DEVICE_ATTR(emul_temp, S_IWUSR, NULL, emul_temp_store);
> +static DEVICE_ATTR_WO(emul_temp);
>  #endif
>  
>  static ssize_t


Re: [-next PATCH 3/4] treewide: Use DEVICE_ATTR_RO

2017-12-20 Thread Zhang Rui
On Tue, 2017-12-19 at 10:15 -0800, Joe Perches wrote:
> Convert DEVICE_ATTR uses to DEVICE_ATTR_RO where possible.
> 
> Done with perl script:
> 
> $ git grep -w --name-only DEVICE_ATTR | \
>   xargs perl -i -e 'local $/; while (<>) {
> s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(?:\s*S_IRUGO\s*|\s*0444\s*)\)?
> \s*,\s*\1_show\s*,\s*NULL\s*\)/DEVICE_ATTR_RO(\1)/g; print;}'
> 
> Signed-off-by: Joe Perches <j...@perches.com>
> ---
>  arch/arm/mach-pxa/sharpsl_pm.c   |  4 ++--
>  arch/sh/drivers/push-switch.c|  2 +-
>  arch/tile/kernel/sysfs.c | 10 +-
>  drivers/acpi/device_sysfs.c  |  6 +++---
>  drivers/char/ipmi/ipmi_msghandler.c  | 17 
> -
>  drivers/gpu/drm/i915/i915_sysfs.c|  6 +++---
>  drivers/nvme/host/core.c | 10 +-
>  drivers/s390/cio/css.c   |  8 
>  drivers/s390/cio/device.c|  8 
>  drivers/s390/crypto/ap_card.c|  2 +-
>  drivers/scsi/hpsa.c  | 10 +-
>  drivers/scsi/lpfc/lpfc_attr.c| 18 
> --
>  drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c |  8 
>  drivers/thermal/thermal_sysfs.c  |  6 +++---

For the thermal part,
ACK-by: Zhang Rui <rui.zh...@intel.com>

thanks,
rui
>  sound/soc/soc-core.c |  2 +-
>  sound/soc/soc-dapm.c |  2 +-
>  16 files changed, 58 insertions(+), 61 deletions(-)
> 
> diff --git a/arch/arm/mach-pxa/sharpsl_pm.c b/arch/arm/mach-
> pxa/sharpsl_pm.c
> index 398ba9ba2632..ef9fd9b759cb 100644
> --- a/arch/arm/mach-pxa/sharpsl_pm.c
> +++ b/arch/arm/mach-pxa/sharpsl_pm.c
> @@ -802,8 +802,8 @@ static ssize_t battery_voltage_show(struct device
> *dev, struct device_attribute
>   return sprintf(buf, "%d\n",
> sharpsl_pm.battstat.mainbat_voltage);
>  }
>  
> -static DEVICE_ATTR(battery_percentage, 0444,
> battery_percentage_show, NULL);
> -static DEVICE_ATTR(battery_voltage, 0444, battery_voltage_show,
> NULL);
> +static DEVICE_ATTR_RO(battery_percentage);
> +static DEVICE_ATTR_RO(battery_voltage);
>  
>  extern void (*apm_get_power_status)(struct apm_power_info *);
>  
> diff --git a/arch/sh/drivers/push-switch.c b/arch/sh/drivers/push-
> switch.c
> index a17181160233..762bc5619910 100644
> --- a/arch/sh/drivers/push-switch.c
> +++ b/arch/sh/drivers/push-switch.c
> @@ -24,7 +24,7 @@ static ssize_t switch_show(struct device *dev,
>   struct push_switch_platform_info *psw_info = dev-
> >platform_data;
>   return sprintf(buf, "%s\n", psw_info->name);
>  }
> -static DEVICE_ATTR(switch, S_IRUGO, switch_show, NULL);
> +static DEVICE_ATTR_RO(switch);
>  
>  static void switch_timer(struct timer_list *t)
>  {
> diff --git a/arch/tile/kernel/sysfs.c b/arch/tile/kernel/sysfs.c
> index af5024f0fb5a..b09456a3d77a 100644
> --- a/arch/tile/kernel/sysfs.c
> +++ b/arch/tile/kernel/sysfs.c
> @@ -38,7 +38,7 @@ static ssize_t chip_width_show(struct device *dev,
>  {
>   return sprintf(page, "%u\n", smp_width);
>  }
> -static DEVICE_ATTR(chip_width, 0444, chip_width_show, NULL);
> +static DEVICE_ATTR_RO(chip_width);
>  
>  static ssize_t chip_height_show(struct device *dev,
>   struct device_attribute *attr,
> @@ -46,7 +46,7 @@ static ssize_t chip_height_show(struct device *dev,
>  {
>   return sprintf(page, "%u\n", smp_height);
>  }
> -static DEVICE_ATTR(chip_height, 0444, chip_height_show, NULL);
> +static DEVICE_ATTR_RO(chip_height);
>  
>  static ssize_t chip_serial_show(struct device *dev,
>   struct device_attribute *attr,
> @@ -54,7 +54,7 @@ static ssize_t chip_serial_show(struct device *dev,
>  {
>   return get_hv_confstr(page, HV_CONFSTR_CHIP_SERIAL_NUM);
>  }
> -static DEVICE_ATTR(chip_serial, 0444, chip_serial_show, NULL);
> +static DEVICE_ATTR_RO(chip_serial);
>  
>  static ssize_t chip_revision_show(struct device *dev,
>     struct device_attribute *attr,
> @@ -62,7 +62,7 @@ static ssize_t chip_revision_show(struct device
> *dev,
>  {
>   return get_hv_confstr(page, HV_CONFSTR_CHIP_REV);
>  }
> -static DEVICE_ATTR(chip_revision, 0444, chip_revision_show, NULL);
> +static DEVICE_ATTR_RO(chip_revision);
>  
>  
>  static ssize_t type_show(struct device *dev,
> @@ -71,7 +71,7 @@ static ssize_t type_show(struct device *dev,
>  {
>   ret

Re: [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW

2017-12-20 Thread Zhang Rui
On Tue, 2017-12-19 at 10:15 -0800, Joe Perches wrote:
> Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible.
> 
> Done with perl script:
> 
> $ git grep -w --name-only DEVICE_ATTR | \
>   xargs perl -i -e 'local $/; while (<>) {
> s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(\s*S_IRUGO\s*\|\s*S_IWUSR|\s*S
> _IWUSR\s*\|\s*S_IRUGO\s*|\s*0644\s*)\)?\s*,\s*\1_show\s*,\s*\1_store\
> s*\)/DEVICE_ATTR_RW(\1)/g; print;}'
> 
> Signed-off-by: Joe Perches <j...@perches.com>
> ---
>  arch/s390/kernel/topology.c  |  3 +--
>  arch/tile/kernel/sysfs.c |  2 +-
>  drivers/gpu/drm/i915/i915_sysfs.c|  6 ++---
>  drivers/platform/x86/compal-laptop.c | 18 +--
>  drivers/s390/cio/device.c|  2 +-
>  drivers/scsi/lpfc/lpfc_attr.c| 43 
> 
>  drivers/thermal/thermal_sysfs.c  |  9 

For the thermal part,
ACK-by: Zhang Rui <rui.zh...@intel.com>

thanks,
rui

>  drivers/tty/serial/sh-sci.c  |  2 +-
>  drivers/usb/host/xhci-dbgcap.c   |  2 +-
>  drivers/usb/phy/phy-tahvo.c  |  2 +-
>  drivers/video/fbdev/auo_k190x.c  |  4 ++--
>  drivers/video/fbdev/w100fb.c |  4 ++--
>  lib/test_firmware.c  | 14 +---
>  lib/test_kmod.c  | 14 +---
>  sound/soc/omap/mcbsp.c   |  4 ++--
>  15 files changed, 49 insertions(+), 80 deletions(-)
> 
> diff --git a/arch/s390/kernel/topology.c
> b/arch/s390/kernel/topology.c
> index 4d5b65e527b5..4b6e0397f66d 100644
> --- a/arch/s390/kernel/topology.c
> +++ b/arch/s390/kernel/topology.c
> @@ -404,8 +404,7 @@ static ssize_t dispatching_store(struct device
> *dev,
>   put_online_cpus();
>   return rc ? rc : count;
>  }
> -static DEVICE_ATTR(dispatching, 0644, dispatching_show,
> -  dispatching_store);
> +static DEVICE_ATTR_RW(dispatching);
>  
>  static ssize_t cpu_polarization_show(struct device *dev,
>    struct device_attribute *attr,
> char *buf)
> diff --git a/arch/tile/kernel/sysfs.c b/arch/tile/kernel/sysfs.c
> index 825867c53853..af5024f0fb5a 100644
> --- a/arch/tile/kernel/sysfs.c
> +++ b/arch/tile/kernel/sysfs.c
> @@ -184,7 +184,7 @@ static ssize_t hv_stats_store(struct device *dev,
>   return n < 0 ? n : count;
>  }
>  
> -static DEVICE_ATTR(hv_stats, 0644, hv_stats_show, hv_stats_store);
> +static DEVICE_ATTR_RW(hv_stats);
>  
>  static int hv_stats_device_add(struct device *dev, struct
> subsys_interface *sif)
>  {
> diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
> b/drivers/gpu/drm/i915/i915_sysfs.c
> index c74a20b80182..1d0ab8ff5915 100644
> --- a/drivers/gpu/drm/i915/i915_sysfs.c
> +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> @@ -447,9 +447,9 @@ static ssize_t gt_min_freq_mhz_store(struct
> device *kdev,
>  
>  static DEVICE_ATTR(gt_act_freq_mhz, S_IRUGO, gt_act_freq_mhz_show,
> NULL);
>  static DEVICE_ATTR(gt_cur_freq_mhz, S_IRUGO, gt_cur_freq_mhz_show,
> NULL);
> -static DEVICE_ATTR(gt_boost_freq_mhz, S_IRUGO | S_IWUSR,
> gt_boost_freq_mhz_show, gt_boost_freq_mhz_store);
> -static DEVICE_ATTR(gt_max_freq_mhz, S_IRUGO | S_IWUSR,
> gt_max_freq_mhz_show, gt_max_freq_mhz_store);
> -static DEVICE_ATTR(gt_min_freq_mhz, S_IRUGO | S_IWUSR,
> gt_min_freq_mhz_show, gt_min_freq_mhz_store);
> +static DEVICE_ATTR_RW(gt_boost_freq_mhz);
> +static DEVICE_ATTR_RW(gt_max_freq_mhz);
> +static DEVICE_ATTR_RW(gt_min_freq_mhz);
>  
>  static DEVICE_ATTR(vlv_rpe_freq_mhz, S_IRUGO, vlv_rpe_freq_mhz_show,
> NULL);
>  
> diff --git a/drivers/platform/x86/compal-laptop.c
> b/drivers/platform/x86/compal-laptop.c
> index 6bcb750e1865..4f9bc72f0584 100644
> --- a/drivers/platform/x86/compal-laptop.c
> +++ b/drivers/platform/x86/compal-laptop.c
> @@ -679,18 +679,12 @@ static int bat_writeable_property(struct
> power_supply *psy,
>  /* == */
>  /* Driver Globals */
>  /* == */
> -static DEVICE_ATTR(wake_up_pme,
> - 0644, wake_up_pme_show, wake_up_pme_s
> tore);
> -static DEVICE_ATTR(wake_up_modem,
> - 0644, wake_up_modem_show,   wake_up_modem_store
> );
> -static DEVICE_ATTR(wake_up_lan,
> - 0644, wake_up_lan_show, wake_up_lan_store);
> -static DEVICE_ATTR(wake_up_wlan,
> - 0644, wake_up_wlan_show,wake_up_wlan_store);
> -static DEVICE_ATTR(wake_up_key,
> - 0644, wake_up_key_show, wake_up_key_store);
> -static DEVICE_ATTR(wake_up_mouse,
> - 0644, wake_up_mouse_show,   wake_up_mouse_store
> );
> +static DEVICE_ATTR_RW(wake_up_pme);
> +static DEVICE_ATTR_RW(wake_up_modem);
> +static DEVICE

Re: Regression: unable to boot after commit bd9240a18edf ("x86/apic: Add TSC_DEADLINE quirk due to errata") - Surface Pro 4 SKL

2017-12-20 Thread Zhang Rui
On Tue, 2017-12-19 at 18:23 +0100, Peter Zijlstra wrote:
> On Tue, Dec 19, 2017 at 05:01:55PM +0100, Peter Zijlstra wrote:
> > 
> > On Tue, Dec 19, 2017 at 11:42:41PM +0800, Zhang Rui wrote:
> > > 
> > > On Tue, 2017-12-19 at 16:23 +0100, Peter Zijlstra wrote:
> > > 
> > > > 
> > > > [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2
> > > > dfl dfl)
> > > > [0.00] ACPI: IRQ0 used by override.
> > > > 
> > > > So your ACPI table has an override for IRQ2 and routes it to
> > > > IRQ0.
> > ^ this
> > 
> > > 
> > > > 
> > > >  The HPET document says:
> > > > 
> > > >   If the ENABLE_CNF bit and the LEG_RT_CNF bit are both set,
> > > > then the
> > > >   interrupts will be routed as follows:
> > > > 
> > > > Timer 0 will be routed to IRQ0 in Non-APIC or IRQ2 in the
> > > > I/O APIC
> > > But AFAICS, the HPET emulated timer interrupts goes to IRQ0
> > Right, so see that ACPI override, that routes I/O APIC IRQ2 to
> > IRQ0, or
> > it _should_.
> > 
> > Clearly something is messed up here.. but I've no idea what. That
> > whole
> > IRQ routing stuff is confusing.
> Does this help?
> 
No.

thanks,
rui
> diff --git a/arch/x86/kernel/time.c b/arch/x86/kernel/time.c
> index 749d189f8cd4..45675072771c 100644
> --- a/arch/x86/kernel/time.c
> +++ b/arch/x86/kernel/time.c
> @@ -69,8 +69,6 @@ static struct irqaction irq0  = {
>  
>  static void __init setup_default_timer_irq(void)
>  {
> - if (!nr_legacy_irqs())
> - return;
>   setup_irq(0, );
>  }
>  


Re: Regression: unable to boot after commit bd9240a18edf ("x86/apic: Add TSC_DEADLINE quirk due to errata") - Surface Pro 4 SKL

2017-12-19 Thread Zhang Rui
On Tue, 2017-12-19 at 16:31 +0100, Peter Zijlstra wrote:
> On Tue, Dec 19, 2017 at 04:23:07PM +0100, Peter Zijlstra wrote:
> > 
> > On Tue, Dec 19, 2017 at 06:48:24PM +0800, Zhang Rui wrote:
> > > 
> > > On Mon, 2017-12-18 at 21:28 +0100, Peter Zijlstra wrote:
> > > > 
> > > > Hi, can you see if this makes you Surface boot?
> > > > 
> > > No, it does not boot.
> > So I'm confused on the lapic calibration.
> > 
> > That stuff uses global_clock_event, which is initially the i8253
> > (PIT),
> > but because !PIC this thing won't be there either on your platform.
> > 
> > Then we initialize I/O APIC, and your machine has:
> > 
> > [0.00] IOAPIC[0]: apic_id 2, version 32, address
> > 0xfec0, GSI 0-119
> > [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl
> > dfl)
> > [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high
> > level)
> > [0.00] ACPI: IRQ0 used by override.
> > [0.00] ACPI: IRQ9 used by override.
> > 
> > So your ACPI table has an override for IRQ2 and routes it to IRQ0.
> > 
> > Then we initialize HPET, and we _always_ do
> > hpet_enable_legacy_int(),
> > which sets the LegacyRouting bit. The HPET document says:
> > 
> >   If the ENABLE_CNF bit and the LEG_RT_CNF bit are both set, then
> > the
> >   interrupts will be routed as follows:
> > 
> > Timer 0 will be routed to IRQ0 in Non-APIC or IRQ2 in the I/O
> > APIC
> > Timer 1 will be routed to IRQ8 in Non-APIC or IRQ8 in the I/O
> > APIC
> > Timer 2-n will be routed as per the routing in the timer n
> > config registers.
> > 
> >   If the LegacyReplacement Route bit is set, the individual routing
> > bits
> >   for timers 0 and 1 (APIC or FSB) will have no impact.
> > 
> > And then we set global_clock_event to _clockevent.
> > 
> > At this point that _SHOULD_ work afaict, even without actual PIC
> > present.
> > 
> > Sometime after that we call into calibrate_APIC_clock() -- because
> > !TSC_DEADLINE -- and this is where you get stuck, because
> > global_clock_event is not in fact delivering interrupts.
> > 
> > Thomas may have more clue, we'll have to wait for him to have a
> > time-slot available.
> What does your /proc/interrupts look like (on a tsc-deadline boot) ?
> 
> 0: is the HPET, LOC: is the lapic/tsc-deadline
> 
> On my SKL desktop I get 21 PIT/HPET ticks on CPU0 before lapic takes
> over.
No irq0.
 LOC: 220071 210079 184892 176494   Local timer
interrupts

thanks,
rui


Re: Regression: unable to boot after commit bd9240a18edf ("x86/apic: Add TSC_DEADLINE quirk due to errata") - Surface Pro 4 SKL

2017-12-19 Thread Zhang Rui
On Tue, 2017-12-19 at 16:23 +0100, Peter Zijlstra wrote:
> On Tue, Dec 19, 2017 at 06:48:24PM +0800, Zhang Rui wrote:
> > 
> > On Mon, 2017-12-18 at 21:28 +0100, Peter Zijlstra wrote:
> > > 
> > > Hi, can you see if this makes you Surface boot?
> > > 
> > No, it does not boot.
> So I'm confused on the lapic calibration.
> 
> That stuff uses global_clock_event, which is initially the i8253
> (PIT),
> but because !PIC this thing won't be there either on your platform.
> 
> Then we initialize I/O APIC, and your machine has:
> 
> [0.00] IOAPIC[0]: apic_id 2, version 32, address 0xfec0,
> GSI 0-119
> [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl
> dfl)
> [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high
> level)
> [0.00] ACPI: IRQ0 used by override.
> [0.00] ACPI: IRQ9 used by override.
> 
> So your ACPI table has an override for IRQ2 and routes it to IRQ0.
> 
> Then we initialize HPET, and we _always_ do hpet_enable_legacy_int(),
> which sets the LegacyRouting bit.

Right.

>  The HPET document says:
> 
>   If the ENABLE_CNF bit and the LEG_RT_CNF bit are both set, then the
>   interrupts will be routed as follows:
> 
> Timer 0 will be routed to IRQ0 in Non-APIC or IRQ2 in the I/O
> APIC

But AFAICS, the HPET emulated timer interrupts goes to IRQ0 on all the
machines I have tested, but on this MS Surface Pro 4, there is no irq 0
row in /proc/interrupts.

$ cat /proc/interrupts 
CPU0   CPU1   CPU2   CPU3   
   8:  0  1  0  0  IR-IO-APIC8-
edge  rtc0
   9:476144   4573132  IR-IO-APIC9-
fasteoi   acpi
  14:  0  0  0  0  IR-IO-APIC   14-
edge  INT344B:00
  16:646   4971  63574   3973  IR-IO-APIC   16-
fasteoi   idma64.0, MRVL_PCIE, i2c_designware.0
  17:  0  0  0  0  IR-IO-APIC   17-
fasteoi   idma64.1, i2c_designware.1
  18:  0  0  0  0  IR-IO-APIC   18-
fasteoi   idma64.2, i2c_designware.2
  19:  0  0  0  0  IR-IO-APIC   19-
fasteoi   idma64.3, i2c_designware.3

Maybe I need to check if IRQ0 is overridden on other platforms, if no,
registering to IRQ2 for HPET Timer 0 could help in this case?

> Timer 1 will be routed to IRQ8 in Non-APIC or IRQ8 in the I/O
> APIC
> Timer 2-n will be routed as per the routing in the timer n config
> registers.
> 
>   If the LegacyReplacement Route bit is set, the individual routing
> bits
>   for timers 0 and 1 (APIC or FSB) will have no impact.
> 
> And then we set global_clock_event to _clockevent.

Yes, I can confirm this.

> 
> At this point that _SHOULD_ work afaict, even without actual PIC
> present.

so IOAPIC is ready when we calibrating Lapic timer?
> 
> Sometime after that we call into calibrate_APIC_clock() -- because
> !TSC_DEADLINE -- and this is where you get stuck, because
> global_clock_event is not in fact delivering interrupts.

right.
> 
> Thomas may have more clue, we'll have to wait for him to have a
> time-slot available.

okay.

thanks,
rui


Re: Regression: unable to boot after commit bd9240a18edf ("x86/apic: Add TSC_DEADLINE quirk due to errata") - Surface Pro 4 SKL

2017-12-19 Thread Zhang Rui
On Tue, 2017-12-19 at 14:15 +0100, Peter Zijlstra wrote:
> On Tue, Dec 19, 2017 at 06:48:24PM +0800, Zhang Rui wrote:
> > 
> > On Mon, 2017-12-18 at 21:28 +0100, Peter Zijlstra wrote:
> > > 
> > > Hi, can you see if this makes you Surface boot?
> > > 
> > No, it does not boot.
> Bah, staring at the lapic calibrate now, that is a bit of a mess..
> 
> > 
> > > 
> > > I tested it on my IVB by making has_legacy_pic() return
> > > unconditional
> > > true.
> > > 
> > > [0.024000] tsc: Unable to calibrate against PIT
> > > [0.025000] tsc: using HPET reference calibration
> > > [0.026000] tsc: Detected 2792.451 MHz processor
> > > 
> > > ---
> > > 
> > > 
> > > diff --git a/arch/x86/include/asm/i8259.h
> > > b/arch/x86/include/asm/i8259.h
> > > index c8376b40e882..e2cfc4b52ee4 100644
> > > --- a/arch/x86/include/asm/i8259.h
> > > +++ b/arch/x86/include/asm/i8259.h
> > > @@ -69,6 +69,11 @@ struct legacy_pic {
> > >  extern struct legacy_pic *legacy_pic;
> > >  extern struct legacy_pic null_legacy_pic;
> > >  
> > > +static inline bool has_legacy_pic(void)
> > > +{
> > > + return legacy_pic == _legacy_pic;
> > > +}
> > > +
> > shouldn't this be
> > return legacy_pic == _legacy_pic;
> > ?
> != , but yes, I mess that up.

I see. I have changed that and the platform can not boot neither.

thanks,
rui


Re: Regression: unable to boot after commit bd9240a18edf ("x86/apic: Add TSC_DEADLINE quirk due to errata") - Surface Pro 4 SKL

2017-12-19 Thread Zhang Rui
On Mon, 2017-12-18 at 21:28 +0100, Peter Zijlstra wrote:
> Hi, can you see if this makes you Surface boot?
> 
No, it does not boot.

> I tested it on my IVB by making has_legacy_pic() return unconditional
> true.
> 
> [0.024000] tsc: Unable to calibrate against PIT
> [0.025000] tsc: using HPET reference calibration
> [0.026000] tsc: Detected 2792.451 MHz processor
> 
> ---
> 
> 
> diff --git a/arch/x86/include/asm/i8259.h
> b/arch/x86/include/asm/i8259.h
> index c8376b40e882..e2cfc4b52ee4 100644
> --- a/arch/x86/include/asm/i8259.h
> +++ b/arch/x86/include/asm/i8259.h
> @@ -69,6 +69,11 @@ struct legacy_pic {
>  extern struct legacy_pic *legacy_pic;
>  extern struct legacy_pic null_legacy_pic;
>  
> +static inline bool has_legacy_pic(void)
> +{
> + return legacy_pic == _legacy_pic;
> +}
> +
shouldn't this be
return legacy_pic == _legacy_pic;
?

thanks,
rui
>  static inline int nr_legacy_irqs(void)
>  {
>   return legacy_pic->nr_legacy_irqs;
> diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
> index 8ea117f8142e..2afc623b2280 100644
> --- a/arch/x86/kernel/tsc.c
> +++ b/arch/x86/kernel/tsc.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  unsigned int __read_mostly cpu_khz;  /* TSC clocks / usec, not
> used here */
>  EXPORT_SYMBOL(cpu_khz);
> @@ -363,6 +364,15 @@ static unsigned long pit_calibrate_tsc(u32
> latch, unsigned long ms, int loopmin)
>   unsigned long tscmin, tscmax;
>   int pitcnt;
>  
> + if (!has_legacy_pic()) {
> + udelay(10 * USEC_PER_MSEC);
> + udelay(10 * USEC_PER_MSEC);
> + udelay(10 * USEC_PER_MSEC);
> + udelay(10 * USEC_PER_MSEC);
> + udelay(10 * USEC_PER_MSEC);
> + return ULONG_MAX;
> + }
> +
>   /* Set the Gate high, disable speaker */
>   outb((inb(0x61) & ~0x02) | 0x01, 0x61);
>  
> @@ -487,6 +497,9 @@ static unsigned long quick_pit_calibrate(void)
>   u64 tsc, delta;
>   unsigned long d1, d2;
>  
> + if (!has_legacy_pic())
> + return 0;
> +
>   /* Set the Gate high, disable speaker */
>   outb((inb(0x61) & ~0x02) | 0x01, 0x61);
>  


Re: Linux 4.15-rc2: Regression in resume from ACPI S3

2017-12-11 Thread Zhang Rui
On Sun, 2017-12-10 at 12:30 -0800, Linus Torvalds wrote:
> On Sun, Dec 10, 2017 at 10:56 AM, Pavel Machek <pa...@ucw.cz> wrote:
> > 
> > 
> > Confirmed, revert fixes it. You see how it moves
> > fix_processor_context
> > around #ifdef CONFIG_X86_32 block? And how people forget 32-bit
> > machines exist? Aha.
> Yeah, people do.
> 
> Andy?
> 
> > 
> > Which brings me to .. various people do automated testing of
> > kernel. Testing 32-bit kernel for boot, and both 32-bit and 64-bit
> > for
> > boot and suspend would be very nice. The last item is not hard,
> > either:
> > 
> > sudo rtcwake -l -m mem -s 5
> > 
> > ...should take 10 seconds or so.
> I'm told 0day does *some* suspend/resume testing, but I think it's
> pretty limited, partly because the kinds of machines it primarily
> works on don't really support suspend/resume at all.

currently, we're running suspend test on 1 platform only, with 64 bit
kernel. suspend test will be enabled on more platforms (laptops) in
next two weeks.

I will check why it does not find the first regression introduced by
ca37e57bbe0c ("x86/entry/64: Add missing irqflags tracing to
native_load_gs_index()").

>  I'm also not sure
> just how many of those machines are 32-bit at all..

for this, I suppose it can be reproduced if we use 32-bit kernel and
rootfs, right? Then it's easier to enable this in 0Day.

thanks,
rui
> 
> But I'm adding Zhang Rui to the cc, to see if my recollection is
> right.
> 
> Because you're right, more suspend/resume automated testing would be
> good to have. And yes, people test mainly 64-bit these days.
> 
> Also, I'm not even sure what the 0day rules are for just plain
> mainline. I don't tend to see a lot of breakage reports, even though
> I'd expect to. This came in from the x86 trees (and those do their
> own
> tests too, but probably not suspend/resume either), but it hit my
> tree
> fairly soon after going into the x86 -tip trees.
> 
> Linus


Re: Regression: unable to boot after commit bd9240a18edf ("x86/apic: Add TSC_DEADLINE quirk due to errata") - Surface Pro 4 SKL

2017-11-29 Thread Zhang Rui
On Tue, 2017-11-28 at 13:36 +0100, Peter Zijlstra wrote:
> On Tue, Nov 28, 2017 at 06:59:01PM +0800, Zhang Rui wrote:
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > My Surface Pro 4 is unable to boot after 4.12. The symptom
> > > > > > is
> > 
> > yes. Tried 4.4 distro and 4.12 vanilla kernel, kernel always
> > freezes
> > with boot option "notscdeadline"/"lapic=notscdeadline".
> Then for some mysterious reason, your Surface thing has a borked
> LAPIC.
> 
I agree. But however, on this platform, forcing a cpu microcode upgrade
after upgrading kernel does not seem like a good solution to users.
Thus I still like to dig into the problem further to see if we can
workaround this "regression" in software.
As the kernel freezes at a very early stage, do you have any advice on
how to narrow down the problem?

thanks,
rui


Re: Regression: unable to boot after commit bd9240a18edf ("x86/apic: Add TSC_DEADLINE quirk due to errata") - Surface Pro 4 SKL

2017-11-28 Thread Zhang Rui
On Tue, 2017-11-28 at 10:34 +0100, Thomas Gleixner wrote:
> On Tue, 28 Nov 2017, Zhang Rui wrote:
> 
> > 
> > On Tue, 2017-11-28 at 09:14 +0100, Peter Zijlstra wrote:
> > > 
> > > On Tue, Nov 28, 2017 at 10:08:53AM +0800, Zhang Rui wrote:
> > > > 
> > > > 
> > > > Hi, All,
> > > > 
> > > > My Surface Pro 4 is unable to boot after 4.12. The symptom is
> > > > that
> > > > kernel freezes during boot, and the last message in the screen
> > > > is
> > > > loading the initrd image. And I have bisected it to this commit
> > > > 
> > > > +// DEADLINE_MODEL_MATCH_REV (
> > > > INTEL_FAM6_SKYLAKE_MOBILE,  
> > > > 0xb2),
> > > And what microcode version do you run? Have you installed the
> > > latest
> > > microcode package and updated your initrd to include it? My
> > > skylake
> > > is
> > > running 0xba.
> > No, I didn't upgrade my microcode.
> > 
> > $ cat /proc/cpuinfo
> > ...
> > processor   : 0
> > vendor_id   : GenuineIntel
> > cpu family  : 6
> > model   : 78
> > model name  : Intel(R) Core(TM) i7-6650U CPU @ 2.20GHz
> > stepping: 3
> > microcode   : 0x9e
> > ...
> > 
> > I suppose the problem should be gone if I upgrade the microcode.
> > But the real problem to me is that the system FREEZES after kernel
> > upgrade.
> Confused. So the match disables the deadline timer due to 0x9e <
> 0xb2. And
> not having deadline timer makes the boot fail despite the fact that
> deadline timer is borked with microcode < 0xb2.
> 
> Can you verify by adding 'lapic=notscdeadline' to the command line of
> a
> 'working' kernel? That should cause a freeze as well then.
> 
yes. Tried 4.4 distro and 4.12 vanilla kernel, kernel always freezes
with boot option "notscdeadline"/"lapic=notscdeadline".

thanks,
rui

> Thanks,
> 
>   tglx


Re: Regression: unable to boot after commit bd9240a18edf ("x86/apic: Add TSC_DEADLINE quirk due to errata") - Surface Pro 4 SKL

2017-11-28 Thread Zhang Rui
On Tue, 2017-11-28 at 09:14 +0100, Peter Zijlstra wrote:
> On Tue, Nov 28, 2017 at 10:08:53AM +0800, Zhang Rui wrote:
> > 
> > Hi, All,
> > 
> > My Surface Pro 4 is unable to boot after 4.12. The symptom is that
> > kernel freezes during boot, and the last message in the screen is
> > loading the initrd image. And I have bisected it to this commit
> > 
> > +// DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_SKYLAKE_MOBILE,   
> > 0xb2),
> And what microcode version do you run? Have you installed the latest
> microcode package and updated your initrd to include it? My skylake
> is
> running 0xba.

No, I didn't upgrade my microcode.

$ cat /proc/cpuinfo
...
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 78
model name  : Intel(R) Core(TM) i7-6650U CPU @ 2.20GHz
stepping: 3
microcode   : 0x9e
...

I suppose the problem should be gone if I upgrade the microcode.
But the real problem to me is that the system FREEZES after kernel
upgrade.

thanks,
rui


Regression: unable to boot after commit bd9240a18edf ("x86/apic: Add TSC_DEADLINE quirk due to errata") - Surface Pro 4 SKL

2017-11-27 Thread Zhang Rui
Hi, All,

My Surface Pro 4 is unable to boot after 4.12. The symptom is that
kernel freezes during boot, and the last message in the screen is
loading the initrd image. And I have bisected it to this commit

commit bd9240a18edfbfa72e957fc2ba831cf1f13ea073 (refs/bisect/bad)
Author: Peter Zijlstra 
AuthorDate: Wed May 31 17:52:03 2017 +0200
Commit: Thomas Gleixner 
CommitDate: Sun Jun 4 21:55:53 2017 +0200

x86/apic: Add TSC_DEADLINE quirk due to errata

Due to errata it is possible for the TSC_DEADLINE timer to
misbehave
after using TSC_ADJUST. A microcode update is available to fix this
situation.

Avoid using the TSC_DEADLINE timer if it is affected by this issue
and
report the required microcode version.

[ tglx: Renamed function to apic_check_deadline_errata() ]

Signed-off-by: Peter Zijlstra (Intel) 
Cc: kevin.b.stan...@intel.com
Link: http://lkml.kernel.org/r/20170531155306.050849877@infradead.o
rg
Signed-off-by: Thomas Gleixner 

Currently, I'm using v4.14 kernel with the following workaround on top.

---
 arch/x86/kernel/apic/apic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index ff89177..cd419d4 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -596,7 +596,7 @@ static const struct x86_cpu_id deadline_match[] = {
    DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_BROADWELL_CORE,   0x25),
    DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_BROADWELL_GT3E,   0x17),
 
-   DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_SKYLAKE_MOBILE,   0xb2),
+// DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_SKYLAKE_MOBILE,   0xb2),
    DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_SKYLAKE_DESKTOP,  0xb2),
 
    DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_KABYLAKE_MOBILE,  0x52),
-- 
2.7.4

I'm reading the related code but have not figured out the root cause yet.
Anyone suggestions?

thanks,
rui



RE: [RFC PATCH v6 1/3] ACPI / EC: Fix possible driver order issue by moving EC event handling earlier

2017-11-22 Thread Zhang, Rui


> -Original Message-
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Lv Zheng
> Sent: Friday, September 29, 2017 10:50 AM
> To: Wysocki, Rafael J ; Rafael J . Wysocki
> ; Brown, Len 
> Cc: Zheng, Lv ; Lv Zheng ; linux-
> ker...@vger.kernel.org; linux-a...@vger.kernel.org
> Subject: [RFC PATCH v6 1/3] ACPI / EC: Fix possible driver order issue by
> moving EC event handling earlier
> 
> This patch tries to detect EC events earlier after resume, so that if an event
> occurred before invoking acpi_ec_unblock_transactions(), it could be
> detected by acpi_ec_unblock_transactions() which is the earliest EC driver
> call after resume.
> 
> However after the noirq stage, if an event ocurred after
> acpi_ec_unblock_transactions() and before acpi_ec_resume(), there was no
> mean to detect and trigger it right then, but can only detect it and handle it
> after acpi_ec_resume().
> 
> Now the final logic is:
> 1. If ec_freeze_events=Y, event handling is stopped in acpi_ec_suspend(),
>restarted in acpi_ec_resume();
> 2. If ec_freeze_events=N, event handling is stopped in
>acpi_ec_block_transactions(), restarted in
>acpi_ec_unblock_transactions();
> 3. In order to handling the conflict of the edge-trigger nature of EC IRQ
>and the Linux noirq stage, advance_transaction() is invoked where the
>event handling is enabled and the noirq stage is ended.
> 
> Known issue:
> 1. Event ocurred between acpi_ec_unblock_transactions() and
>acpi_ec_resume() may still lead to the order issue. This can only be
>fixed by adding a periodic detection mechanism during the noirq stage.
> 
> Signed-off-by: Lv Zheng 
> Tested-by: Tomislav Ivek 
> Tested-by: Luya Tshimbalanga 

I don't know what issue this patch has been tested for. Lv, can you please 
clarify?

I agree with lv that it can probably fix some issues brought by the device 
order issue.
And I'll be glad to push this after we have verified it is really helpful.
Lv,
Do you still remember the bug report for the lid issue?

Thanks,
rui
> ---
>  drivers/acpi/ec.c | 35 ++-
>  1 file changed, 26 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c index df84246..f1f320b
> 100644
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -249,6 +249,11 @@ static bool acpi_ec_started(struct acpi_ec *ec)
>  !test_bit(EC_FLAGS_STOPPED, >flags);  }
> 
> +static bool acpi_ec_no_sleep_events(void) {
> + return acpi_sleep_no_ec_events() && ec_freeze_events; }
> +
>  static bool acpi_ec_event_enabled(struct acpi_ec *ec)  {
>   /*
> @@ -260,14 +265,14 @@ static bool acpi_ec_event_enabled(struct acpi_ec
> *ec)
>   return false;
>   /*
>* However, disabling the event handling is experimental for late
> -  * stage (suspend), and is controlled by the boot parameter of
> -  * "ec_freeze_events":
> +  * stage (suspend), and is controlled by
> +  * "acpi_ec_no_sleep_events()":
>* 1. true:  The EC event handling is disabled before entering
>*   the noirq stage.
>* 2. false: The EC event handling is automatically disabled as
>*   soon as the EC driver is stopped.
>*/
> - if (ec_freeze_events)
> + if (acpi_ec_no_sleep_events())
>   return acpi_ec_started(ec);
>   else
>   return test_bit(EC_FLAGS_STARTED, >flags); @@ -524,8
> +529,8 @@ static bool acpi_ec_query_flushed(struct acpi_ec *ec)  static void
> __acpi_ec_flush_event(struct acpi_ec *ec)  {
>   /*
> -  * When ec_freeze_events is true, we need to flush events in
> -  * the proper position before entering the noirq stage.
> +  * When acpi_ec_no_sleep_events() is true, we need to flush events
> +  * in the proper position before entering the noirq stage.
>*/
>   wait_event(ec->wait, acpi_ec_query_flushed(ec));
>   if (ec_query_wq)
> @@ -948,7 +953,8 @@ static void acpi_ec_start(struct acpi_ec *ec, bool
> resuming)
>   if (!resuming) {
>   acpi_ec_submit_request(ec);
>   ec_dbg_ref(ec, "Increase driver");
> - }
> + } else if (!acpi_ec_no_sleep_events())
> + __acpi_ec_enable_event(ec);
>   ec_log_drv("EC started");
>   }
>   spin_unlock_irqrestore(>lock, flags); @@ -980,7 +986,7 @@
> static void acpi_ec_stop(struct acpi_ec *ec, bool suspending)
>   if (!suspending) {
>   acpi_ec_complete_request(ec);
>   ec_dbg_ref(ec, "Decrease driver");
> - } else if (!ec_freeze_events)
> + } else if (!acpi_ec_no_sleep_events())
>   

RE: [RFC PATCH v6 2/3] ACPI / EC: Add event detection support for noirq stages

2017-11-22 Thread Zhang, Rui


> -Original Message-
> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Lv Zheng
> Sent: Friday, September 29, 2017 10:50 AM
> To: Wysocki, Rafael J ; Rafael J . Wysocki
> ; Brown, Len 
> Cc: Zheng, Lv ; Lv Zheng ; linux-
> ker...@vger.kernel.org; linux-a...@vger.kernel.org
> Subject: [RFC PATCH v6 2/3] ACPI / EC: Add event detection support for noirq
> stages
> 
> This patch adds a timer to poll EC events:
> 1. between acpi_ec_suspend() and acpi_ec_block_transactions(), 2. between
> acpi_ec_unblock_transactions() and acpi_ec_resume().
> During these periods, if an EC event occurred, we have not mean to detect it.
> Thus the events occurred in late S3-entry could be dropped, and the events
> occurred in early S3-exit could be deferred to acpi_ec_resume().
> 
> This patch solves event losses in S3-entry and resume order in S3-exit by
> timely polling EC events during these periods.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=196129 [#1]
> Signed-off-by: Lv Zheng 
> Tested-by: Tomislav Ivek 

No, the patches to fix the Fan spin issue 
(https://bugzilla.kernel.org/show_bug.cgi?id=196129) have already been applied 
by Rafael.
This patch, together with patch 3/3 don't fix anything.
I'm not saying the patch is wrong, but they should be verified to fix a real 
issue before submitting for upstream.

Thanks,
rui
> ---
>  drivers/acpi/ec.c   | 93
> +++--
>  drivers/acpi/internal.h |  1 +
>  2 files changed, 92 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c index f1f320b..389c499
> 100644
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -40,6 +40,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  #include "internal.h"
> @@ -102,6 +103,7 @@ enum ec_command {
>  #define ACPI_EC_CLEAR_MAX100 /* Maximum number of events to
> query
>* when trying to clear the EC */
>  #define ACPI_EC_MAX_QUERIES  16  /* Maximum number of
> parallel queries */
> +#define ACPI_EC_EVENT_INTERVAL   500 /* Detecting event every
> 500ms */
> 
>  enum {
>   EC_FLAGS_QUERY_ENABLED, /* Query is enabled */
> @@ -113,6 +115,7 @@ enum {
>   EC_FLAGS_STARTED,   /* Driver is started */
>   EC_FLAGS_STOPPED,   /* Driver is stopped */
>   EC_FLAGS_GPE_MASKED,/* GPE masked */
> + EC_FLAGS_GPE_POLLING,   /* GPE polling is enabled */
>  };
> 
>  #define ACPI_EC_COMMAND_POLL 0x01 /* Available for
> command byte */
> @@ -154,6 +157,15 @@ static bool ec_no_wakeup __read_mostly;
> module_param(ec_no_wakeup, bool, 0644);
> MODULE_PARM_DESC(ec_no_wakeup, "Do not wake up from suspend-to-
> idle");
> 
> +static bool ec_detect_noirq_events __read_mostly;
> +module_param(ec_detect_noirq_events, bool, 0644);
> +MODULE_PARM_DESC(ec_detect_noirq_events, "Enabling event detection
> +during noirq stage");
> +
> +static unsigned int
> +ec_detect_noirq_interval __read_mostly = ACPI_EC_EVENT_INTERVAL;
> +module_param(ec_detect_noirq_interval, uint, 0644);
> +MODULE_PARM_DESC(ec_detect_noirq_interval, "Event detection
> +interval(ms) during noirq stage");
> +
>  struct acpi_ec_query_handler {
>   struct list_head node;
>   acpi_ec_query_func func;
> @@ -358,6 +370,48 @@ static inline bool acpi_ec_is_gpe_raised(struct
> acpi_ec *ec)
>   return (gpe_status & ACPI_EVENT_FLAG_STATUS_SET) ? true : false;  }
> 
> +static void acpi_ec_gpe_tick(struct acpi_ec *ec) {
> + mod_timer(>timer,
> +   jiffies + msecs_to_jiffies(ec_detect_noirq_interval));
> +}
> +
> +static void ec_start_gpe_poller(struct acpi_ec *ec) {
> + unsigned long flags;
> + bool start_tick = false;
> +
> + if (!acpi_ec_no_sleep_events() || !ec_detect_noirq_events)
> + return;
> + spin_lock_irqsave(>lock, flags);
> + if (!test_and_set_bit(EC_FLAGS_GPE_POLLING, >flags)) {
> + ec_log_drv("GPE poller started");
> + start_tick = true;
> + /* kick off GPE polling without delay */
> + advance_transaction(ec);
> + }
> + spin_unlock_irqrestore(>lock, flags);
> + if (start_tick)
> + acpi_ec_gpe_tick(ec);
> +}
> +
> +static void ec_stop_gpe_poller(struct acpi_ec *ec) {
> + unsigned long flags;
> + bool stop_tick = false;
> +
> + if (!acpi_ec_no_sleep_events() || !ec_detect_noirq_events)
> + return;
> + spin_lock_irqsave(>lock, flags);
> + if (test_and_clear_bit(EC_FLAGS_GPE_POLLING, >flags))
> + stop_tick = true;
> + spin_unlock_irqrestore(>lock, flags);
> + if (stop_tick) {
> + del_timer_sync(>timer);
> + ec_log_drv("GPE poller stopped");
> + }

[GIT PULL] Thermal management updates for v4.15-rc1

2017-11-16 Thread Zhang Rui
Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next

to receive the latest Thermal Management updates for v4.15-rc1 with
top-most commit 1e032393d9680c1f3b5238ec0f3f4eb006ee83d2:

  Merge branches 'thermal-core', 'thermal-tool', 'thermal-intel' and
'thermal-soc' into next (2017-11-02 16:32:25 +0800)

on top of commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

Specifics:

- Introduce brcmstb AVS TMON thermal driver. (Brian Norris)
- Add Rockchip RV1108 support in rockchip thermal driver.
  (Rocky Hao)
- Major rework on HISI driver plus additional support of hisi3660.
  (Daniel Lezcano)
- Add nvmem-cells binding on imx6sx. (Leonard Crestez)
- Fix a NULL pointer dereference on ti thermal driver unloading.
  (Tony Lindgren)
- improve tmon tool to make it easier to cross-compile tmon.
  (Markus Mayer)
- Add Coffee Lake and Cannon Lake support for intel processor and pch
  thermal drivers. (Srinivas Pandruvada)
- Other small fixes and cleanups. (Arvind Yadav, Colin Ian King, Allen
  Wild, Nicolin Chen, Baruch SiachNiklas Söderlund, Arnd Bergmann)

thanks,
rui


Allen Wild (1):
  thermal: enable broadcom menu for arm64 bcm2835

Arnd Bergmann (1):
  thermal: imx: add NVMEM dependency

Arvind Yadav (3):
  thermal : Remove const to make same prototype
  thermal/intel_powerclamp: pr_err()/pr_info() strings should end
with newlines
  thermal: cpu_cooling: pr_err() strings should end with newlines

Baruch Siach (1):
  thermal: armada: fix formula documentation comment

Brian Norris (2):
  Documentation: devicetree: add binding for Broadcom STB AVS TMON
  thermal: add brcmstb AVS TMON driver

Colin Ian King (1):
  thermal: bxt: remove redundant variable trip

Daniel Lezcano (16):
  thermal/drivers/hisi: Fix missing interrupt enablement
  thermal/drivers/hisi: Remove the multiple sensors support
  thermal/drivers/hisi: Fix kernel panic on alarm interrupt
  thermal/drivers/hisi: Simplify the temperature/step computation
  thermal/drivers/hisi: Fix multiple alarm interrupts firing
  thermal/drivers/hisi: Remove pointless lock
  thermal/drivers/hisi: Encapsulate register writes into helpers
  thermal/drivers/hisi: Fix configuration register setting
  thermal/drivers/hisi: Remove costly sensor inspection
  thermal/drivers/hisi: Rename and remove unused field
  thermal/drivers/hisi: Convert long to int
  thermal/drivers/hisi: Remove thermal data back pointer
  thermal/drivers/hisi: Remove mutex_lock in the code
  thermal/drivers/step_wise: Fix temperature regulation misbehavior
  thermal/drivers/generic-iio-adc: Switch tz request to devm
version
  thermal/drivers/qcom-spmi: Use devm_iio_channel_get

Kevin Wangtao (6):
  thermal/drivers/hisi: Move the clk setup in the corresponding
functions
  thermal/drivers/hisi: Use round up step value
  thermal/drivers/hisi: Put platform code together
  thermal/drivers/hisi: Add platform prefix to function name
  thermal/drivers/hisi: Prepare to add support for other hisi
platforms
  thermal/drivers/hisi: Add support for hi3660 SoC

Leonard Crestez (2):
  thermal: imx: Add nvmem-cells alternate binding for OCOTP access
  thermal: imx: Add support for reading OCOTP through nvmem

Markus Mayer (3):
  tools/thermal: tmon: use "-fstack-protector" only if supported
  tools/thermal: tmon: allow $(CC) to be defined externally
  tools/thermal: tmon: use $(PKG_CONFIG) instead of hard-coding
pkg-config

Nicolin Chen (1):
  thermal: tegra: remove null check for dev pointer

Niklas Söderlund (1):
  thermal: rcar_gen3_thermal: fix initialization sequence for H3
ES2.0

Rocky Hao (2):
  dt-bindings: rockchip-thermal: Support the RV1108 SoC compatible
  thermal: rockchip: Support the RV1108 SoC in thermal driver

Srinivas Pandruvada (3):
  thermal: int340x: processor_thermal: Add Cannon Lake support
  thermal: int340x: processor_thermal: Add Coffee Lake support
  thermal: pch: Add Cannon Lake support

Tony Lindgren (1):
  thermal: ti-soc-thermal: Fix ti_thermal_unregister_cpu_cooling
NULL pointer on unload

Zhang Rui (2):
  Merge branch 'imx-nvmem' into thermal-soc
  Merge branches 'thermal-core', 'thermal-tool', 'thermal-intel'
and 'thermal-soc' into next

 .../devicetree/bindings/thermal/brcm,avs-tmon.txt  |  20 +
 .../devicetree/bindings/thermal/imx-thermal.txt|   7 +
 .../bindings/thermal/rockchip-thermal.txt  |   1 +
 MAINTAINERS|   8 +
 drivers/thermal/Kconfig|   3 +-
 drivers/thermal/armada_thermal.c   |   2 +-
 drivers/thermal/broadcom/Kconfig   |   7 +
 drivers/thermal/broadcom/Makefile  |   1 +
 drivers/therma

Re: 4.14 kernel and acpi INT3400:00: Unsupported event [0x86]

2017-11-14 Thread Zhang Rui
Hi, Brian,

thanks for your quick fix, as it is in merge window right now, I will
queue it for for next -rc2.

thanks,
rui

On Tue, 2017-11-14 at 10:50 -0700, Brian Bian wrote:
> I have submitted a patch to suppress such messages. The INT3400
> driver
> currently handles 0x83 thermal-relationship-table-change event
> only, and all other ACPI notification codes are unknown/irrelevant
> to the INT3400 driver.
> 
> Thanks,
> -Brian
> 
> On Mon, 13 Nov 2017, Arkadiusz Miskiewicz wrote:
> 
> > 
> > On Monday 13 of November 2017, Zhang Rui wrote:
> > > 
> > > On Sun, 2017-11-12 at 23:25 +0100, Arkadiusz Miskiewicz wrote:
> > > > 
> > > > Hello.
> > > > 
> > > > On Dell XPS 9530 and 4.14 kernel dmesg is flooded with:
> > > > 
> > > > [  292.580807] acpi INT3400:00: Unsupported event [0x86]
> > > > [  299.284648] acpi INT3400:00: Unsupported event [0x86]
> > > > [  305.648079] acpi INT3400:00: Unsupported event [0x86]
> > > > [  315.444799] acpi INT3400:00: Unsupported event [0x86]
> > > > [  317.432412] acpi INT3400:00: Unsupported event [0x86]
> > > > [  319.420239] acpi INT3400:00: Unsupported event [0x86]
> > > > [  321.408476] acpi INT3400:00: Unsupported event [0x86]
> > > > [  323.400304] acpi INT3400:00: Unsupported event [0x86]
> > > > [  325.388358] acpi INT3400:00: Unsupported event [0x86]
> > > > 
> > > > What 0x86 might mean?
> > > please attach the acpidump output.
> > Attached.
> > 
> > > 
> > > 
> > > thanks,
> > > rui
> > 
> > 
> > -- 
> > Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )


Re: CONFIG_DEBUG_INFO_SPLIT impacts on faddr2line

2017-11-12 Thread Zhang Rui
On Mon, 2017-11-13 at 09:13 +0800, Fengguang Wu wrote:
> CC Andi and more DEBUG_INFO_SPLIT people.
> 
> On Sun, Nov 12, 2017 at 11:31:56AM -0800, Linus Torvalds wrote:
> > 
> > On Wed, Nov 8, 2017 at 9:12 AM, Fengguang Wu  > m> wrote:
> > > 
> > > 
> > > OK. Here is the original faddr2line output:
> > > 
> > > $ ~/linux/scripts/faddr2line vmlinux
> > > vlan_device_event+0x7f5/0xa40
> > > vlan_device_event+0x7f5/0xa40:
> > > vlan_device_event at net/8021q/vlan.h:60
> > > 
> > > And below is call trace embedded with full faddr2line output.
> > > 
> > > I notice that this trace shows no additional inline files at all.
> > > Is it because I did some kconfig option wrong, so that inline
> > > info is
> > > lost? Eg.
> > > 
> > > CONFIG_OPTIMIZE_INLINING=y (it looks better set to N)
> > > CONFIG_DEBUG_INFO_REDUCED=y
> > > CONFIG_DEBUG_INFO_SPLIT=y
> > Ok, this annoyed me, so I went back and looked.
> > 
> > It's the "CONFIG_DEBUG_INFO_SPLIT" thing that makes faddr2line
> > unable
> > to see the inlining information,
> > 
> > Using OPTIMIZE_INLINING is fine.
> Good to know that!
> 
> > 
> > I'm not sure that addr2line could be made to understand the .dwo
> > files
> > that DEBUG_INFO_SPLIT causes (particularly since we munge the
> > vmlinux
> > file itself, who knows how that could confuse things).
> > 
> > So can I ask that you make the 0day build scripts always use
> > 
> >  CONFIG_DEBUG_INFO=y
> >  CONFIG_DEBUG_INFO_REDUCED=y
> >  # CONFIG_DEBUG_INFO_SPLIT is not set
> > 
> > because with that "DEBUG_INFO_REDUCED=y", the use of
> > DEBUG_INFO_SPLIT
> > shouldn't be _that_ big of a deal.
> > 
> > Yes, splitting the debug info does help reduce disk usage for the
> > build, and presumably speed it up a bit too due to less IO and
> > reduced
> > copying of the debug info data, but right now it really makes the
> > debug info much less useful.
> Yes DEBUG_INFO_SPLIT helps reduce build cost. Equally importantly,
> it helps cut down the *.ko sizes, which saves boot test cost, too.
> Since in our test scheme, the below modules.cgz will be loaded as
> part
> of initrd on boot testing. Which will cost memory, and to the lesser
> degree, IO and uncompressing time.
> 
> Here is the diff of the modules.cgz size:
> 
> Big files under /pkg/linux/x86_64-rhel-
> 7.2+CONFIG_DEBUG_INFO_REDUCED/gcc-6/v4.14-rc7/,
> comparing to +CONFIG_DEBUG_INFO_SPLIT:
> 
> =>54M  135M  modules.cgz
>  7.3M  7.3M  vmlinuz-4.14.0-rc7
>  1.2M  1.2M  linux-headers.cgz
>  7.6M  7.7M  linux-selftests.cgz
>   31M   31M  linux-perf.cgz
> 
> Nevertheless, that's machine cost. If DEBUG_INFO_SPLIT hurts our
> ability to analyze bugs, I think the forthright way would be to
> disable it in our tests.
> 
> > 
> > Just to see the difference:
> > 
> > - with DEBUG_INFO_SPLIT=y
> > 
> >    [torvalds@i7 linux]$ ./scripts/faddr2line vmlinux
> > __schedule+0x314
> >    __schedule+0x314/0x840:
> >    __schedule at kernel/sched/stats.h:12
> > 
> > - with DEBUG_INFO_SPLIT is not set
> > 
> >    [torvalds@i7 linux]$ ./scripts/faddr2line vmlinux
> > __schedule+0x314
> >    __schedule+0x314/0x840:
> >    rq_sched_info_arrive at kernel/sched/stats.h:12
> > (inlined by) sched_info_arrive at kernel/sched/stats.h:99
> > (inlined by) __sched_info_switch at kernel/sched/stats.h:151
> > (inlined by) sched_info_switch at kernel/sched/stats.h:158
> > (inlined by) prepare_task_switch at kernel/sched/core.c:2582
> > (inlined by) context_switch at kernel/sched/core.c:2755
> > (inlined by) __schedule at kernel/sched/core.c:3366
> > 
> > and while (once again) this is a pretty extreme case, we do use a
> > lot
> > of inlines, and gcc will add its own inlining. Getting this whole
> > information - particularly for the faulting IP - would really help
> > in
> > some situations.
> > 
> > I love what the 0day robot is doing, this would be another big step
> > forward.
> Thank you for the helpful information and appreciations!
> I'll make the change to disable DEBUG_INFO_SPLIT.
> 
> > 
> > Oh - and talking about "big step forward" - does the 0day robot do
> > any
> > suspend/resume testing at all?
> Yes, we do. CC Rui and Aaron on power testing.
> 
yes, we have added suspend/resume test in 0day, including both
functionality and suspend/resume performance. It is not widely run
because most of the 0Day testboxes are servers/desktops, now we've just
added some client laptops as testboxes, and will add more in the near
future. :)
> > 
> > Even on non-laptop hardware, it should be possible to do something
> > like
> > 
> >    echo platform > /sys/power/pm_test
> >    echo freeze > /sys/power/state
> > 
> > or similar (assuming CONFIG_PM_DEBUG is enabled).
> > 

yes.

I will run native suspend/resume test on laptops and other test boxes
that really support it, and run suspend/resume test in pm_test modes on
the others to help us find more issues.

thanks,
rui
> > Maybe you already do something like this?
> Rui/Aaron have better 

Re: 4.14 kernel and acpi INT3400:00: Unsupported event [0x86]

2017-11-12 Thread Zhang Rui
On Sun, 2017-11-12 at 23:25 +0100, Arkadiusz Miskiewicz wrote:
> Hello.
> 
> On Dell XPS 9530 and 4.14 kernel dmesg is flooded with:
> 
> [  292.580807] acpi INT3400:00: Unsupported event [0x86]
> [  299.284648] acpi INT3400:00: Unsupported event [0x86]
> [  305.648079] acpi INT3400:00: Unsupported event [0x86]
> [  315.444799] acpi INT3400:00: Unsupported event [0x86]
> [  317.432412] acpi INT3400:00: Unsupported event [0x86]
> [  319.420239] acpi INT3400:00: Unsupported event [0x86]
> [  321.408476] acpi INT3400:00: Unsupported event [0x86]
> [  323.400304] acpi INT3400:00: Unsupported event [0x86]
> [  325.388358] acpi INT3400:00: Unsupported event [0x86]
> 
> What 0x86 might mean?
> 
please attach the acpidump output.

thanks,
rui

> It was added by commit:
> 
> commit 38e44da591303d08b0d965a033e11ade284999d0
> Author: Brian Bian <brian.b...@linux.intel.com>
> Date:   Wed Aug 9 11:45:40 2017 -0700
> 
> thermal: int3400_thermal: process "thermal table changed" event
> 
> Some BIOS implement ACPI notification code 0x83 to indicate
> active
> relationship table(ART) and/or thermal relationship table(TRT)
> changes
> to INT3400 device. This event needs to be propagated to user
> space so
> that it can be handled by the user space thermal daemon.
> 
> Signed-off-by: Brian Bian <brian.b...@linux.intel.com>
> Signed-off-by: Zhang Rui <rui.zh...@intel.com>
> 
> # dmesg
> [0.00] microcode: microcode updated early to revision 0x22,
> date = 2017-01-27
> [0.00] Linux version 4.14.0 (arekm@ixion-pld) (gcc version
> 7.2.0 20170814 (release) (PLD-Linux)) #188 SMP PREEMPT Sun Nov 12
> 22:42:24 CET 2017
> [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.14-stable
> root=UUID=af81d682-6bd2-4d3e-86e4-ece699b48fb4 ro panic=120
> init=/bin/systemd systemd.unit=graphical.target pause_on_oops=30
> kaslr intel_pstate=disable 
> systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all
> [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating
> point registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE
> registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX
> registers'
> [0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
> [0.00] x86/fpu: Enabled xstate features 0x7, context size is
> 832 bytes, using 'standard' format.
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009d7ff] 
> usable
> [0.00] BIOS-e820: [mem 0x0009d800-0x0009] 
> reserved
> [0.00] BIOS-e820: [mem 0x000e-0x000f] 
> reserved
> [0.00] BIOS-e820: [mem 0x0010-0xb8446fff] 
> usable
> [0.00] BIOS-e820: [mem 0xb8447000-0xb844dfff] 
> ACPI NVS
> [0.00] BIOS-e820: [mem 0xb844e000-0xb888bfff] 
> usable
> [0.00] BIOS-e820: [mem 0xb888c000-0xb8ea7fff] 
> reserved
> [0.00] BIOS-e820: [mem 0xb8ea8000-0xca793fff] 
> usable
> [0.00] BIOS-e820: [mem 0xca794000-0xcab46fff] 
> reserved
> [0.00] BIOS-e820: [mem 0xcab47000-0xcab69fff] 
> ACPI data
> [0.00] BIOS-e820: [mem 0xcab6a000-0xcb53efff] 
> ACPI NVS
> [0.00] BIOS-e820: [mem 0xcb53f000-0xcbffefff] 
> reserved
> [0.00] BIOS-e820: [mem 0xcbfff000-0xcbff] 
> usable
> [0.00] BIOS-e820: [mem 0xcd00-0xcf1f] 
> reserved
> [0.00] BIOS-e820: [mem 0xf800-0xfbff] 
> reserved
> [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] 
> reserved
> [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] 
> reserved
> [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] 
> reserved
> [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] 
> reserved
> [0.00] BIOS-e820: [mem 0xff00-0x] 
> reserved
> [0.00] BIOS-e820: [mem 0x0001-0x00042fdf] 
> usable
> [0.00] NX (Execute Disable) protection: active
> [0.00] random: fast init done
> [0.00] SMBIOS 2.7 present.
> [0.00] DMI: Dell Inc. XPS 15 9530/XPS 15 9530, BIOS A09
> 07/30/2015
> [0.00] tsc: Fast TSC calibration using PIT
> [0.00] e820: update [mem 0x-0x0fff] usable ==>
> reserved
> [0.00] e820: remove [mem 0x000a-0x000f] usable
> [0.00] e820: last_pfn = 0x42fe00 max_arch_pfn = 0

Re: [PATCH 2/3] thermal: int340x: processor_thermal: Add Coffee Lake support

2017-10-31 Thread Zhang Rui
On Thu, 2017-10-19 at 14:51 -0700, Srinivas Pandruvada wrote:
> Add new PCI id for Coffee lake processor thermal device.
> 
> Signed-off-by: Srinivas Pandruvada  om>
> ---
>  drivers/thermal/int340x_thermal/processor_thermal_device.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git
> a/drivers/thermal/int340x_thermal/processor_thermal_device.c
> b/drivers/thermal/int340x_thermal/processor_thermal_device.c
> index e724a23..1d9f524 100644
> --- a/drivers/thermal/int340x_thermal/processor_thermal_device.c
> +++ b/drivers/thermal/int340x_thermal/processor_thermal_device.c
> @@ -32,6 +32,7 @@
>  
>  /* CannonLake thermal reporting device */
>  #define PCI_DEVICE_ID_PROC_CNL_THERMAL   0x5a03
> +#define PCI_DEVICE_ID_PROC_CFL_THERMAL   0x3E83
>  
shouldn't it be added into proc_thermal_pci_ids[]?

thanks,
rui
>  /* Braswell thermal reporting device */
>  #define PCI_DEVICE_ID_PROC_BSW_THERMAL   0x22DC


Re: [GIT PULL] Thermal SoC management updates for v4.15-rc1 #1

2017-10-31 Thread Zhang Rui
On Mon, 2017-10-30 at 07:30 -0700, Eduardo Valentin wrote:
> Hello Rui,
> 
> Please pull the changes for thermal-soc for the coming v4.15-rc1.
> Changelog:
> - New drivers: Rockchip RV1108 and Broadcom AVS tmon.
> - Major rework on HISI driver plus additional support of hisi3660.
> - Several fixes on diverse drivers and few in core.
> 
> BR,
> 
> The following changes since commit
> 569dbb88e80deb68974ef6fdd6a13edb9d686261:
> 
>   Linux 4.13 (2017-09-03 13:56:17 -0700)
> 
please rebase it on top of v4.14-rc1 to avoid conflict, as we have a
couple of thermal soc changes merged in 4.14-rc1.

thanks,
rui

> are available in the git repository at:
> 
>  
> 
> for you to fetch changes up to
> 877a9aa9dadc7291b0069fb2ccdf2bbc1e3e6a6e:
> 
>   thermal: cpu_cooling: pr_err() strings should end with newlines
> (2017-10-26 11:33:32 -0700)
> 
> 
> Allen Wild (1):
>   thermal: enable broadcom menu for arm64 bcm2835
> 
> Arvind Yadav (1):
>   thermal: cpu_cooling: pr_err() strings should end with newlines
> 
> Baruch Siach (1):
>   thermal: armada: fix formula documentation comment
> 
> Brian Norris (2):
>   Documentation: devicetree: add binding for Broadcom STB AVS
> TMON
>   thermal: add brcmstb AVS TMON driver
> 
> Daniel Lezcano (16):
>   thermal/drivers/hisi: Fix missing interrupt enablement
>   thermal/drivers/hisi: Remove the multiple sensors support
>   thermal/drivers/hisi: Fix kernel panic on alarm interrupt
>   thermal/drivers/hisi: Simplify the temperature/step computation
>   thermal/drivers/hisi: Fix multiple alarm interrupts firing
>   thermal/drivers/hisi: Remove pointless lock
>   thermal/drivers/hisi: Encapsulate register writes into helpers
>   thermal/drivers/hisi: Fix configuration register setting
>   thermal/drivers/hisi: Remove costly sensor inspection
>   thermal/drivers/hisi: Rename and remove unused field
>   thermal/drivers/hisi: Convert long to int
>   thermal/drivers/hisi: Remove thermal data back pointer
>   thermal/drivers/hisi: Remove mutex_lock in the code
>   thermal/drivers/step_wise: Fix temperature regulation
> misbehavior
>   thermal/drivers/generic-iio-adc: Switch tz request to devm
> version
>   thermal/drivers/qcom-spmi: Use devm_iio_channel_get
> 
> Kevin Wangtao (6):
>   thermal/drivers/hisi: Move the clk setup in the corresponding
> functions
>   thermal/drivers/hisi: Use round up step value
>   thermal/drivers/hisi: Put platform code together
>   thermal/drivers/hisi: Add platform prefix to function name
>   thermal/drivers/hisi: Prepare to add support for other hisi
> platforms
>   thermal/drivers/hisi: Add support for hi3660 SoC
> 
> Nicolin Chen (1):
>   thermal: tegra: remove null check for dev pointer
> 
> Niklas Söderlund (1):
>   thermal: rcar_gen3_thermal: fix initialization sequence for H3
> ES2.0
> 
> Rocky Hao (2):
>   dt-bindings: rockchip-thermal: Support the RV1108 SoC
> compatible
>   thermal: rockchip: Support the RV1108 SoC in thermal driver
> 
> Tony Lindgren (1):
>   thermal: ti-soc-thermal: Fix ti_thermal_unregister_cpu_cooling
> NULL pointer on unload
> 
>  .../devicetree/bindings/thermal/brcm,avs-tmon.txt  |  20 +
>  .../bindings/thermal/rockchip-thermal.txt  |   1 +
>  MAINTAINERS|   8 +
>  drivers/thermal/Kconfig|   2 +-
>  drivers/thermal/armada_thermal.c   |   2 +-
>  drivers/thermal/broadcom/Kconfig   |   7 +
>  drivers/thermal/broadcom/Makefile  |   1 +
>  drivers/thermal/broadcom/brcmstb_thermal.c | 387
> +
>  drivers/thermal/cpu_cooling.c  |   2 +-
>  drivers/thermal/hisi_thermal.c | 612
> ++---
>  drivers/thermal/qcom-spmi-temp-alarm.c |  43 +-
>  drivers/thermal/rcar_gen3_thermal.c|  34 +-
>  drivers/thermal/rockchip_thermal.c |  67 +++
>  drivers/thermal/step_wise.c|  11 +-
>  drivers/thermal/tegra/soctherm.c   |   2 +-
>  drivers/thermal/thermal-generic-adc.c  |  24 +-
>  drivers/thermal/ti-soc-thermal/ti-thermal-common.c |   3 +-
>  17 files changed, 940 insertions(+), 286 deletions(-)
>  create mode 100644
> Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt
>  create mode 100644 drivers/thermal/broadcom/brcmstb_thermal.c


Re: [PATCH] MAINTAINERS: thermal: Remove Eduardo's git tree

2017-10-26 Thread Zhang Rui
CC Eduardo.

On Thu, 2017-10-26 at 19:06 +0200, Daniel Lezcano wrote:
> On 26/10/2017 18:59, Florian Fainelli wrote:
> > 
> > On 09/24/2017 02:18 PM, Florian Fainelli wrote:
> > > 
> > > Eduardo's git tree at:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-
> > > thermal.git
> > > 
> > > has not been updated in months, remove it to avoid any confusing
> > > and
> > > patch submissions to stall.
> > > 
> > > Signed-off-by: Florian Fainelli 
> > > ---
> > > This is agains Rui's next branch
> > The very fact that this patch has not received any response is a
> > clear
> > indication that there is something seriously wrong with the SoC
> > thermal
> > drivers maintenance.
> > 
> > Eduardo, if you can't even be bothered to respond to emails and
> > Ack/Nack, then remove yourself so you can set clear expectations
> > with
> > people attempting to get their drivers upstreamed.
> Eduardo reviewed and took my patches recently.
> 
> I don't know the status about merging them in Linus's tree.
> 
> 
Eduardo was busy on some personal stuff during last release cycle, and
now he is back and is taking thermal soc patches for next merge window.

I think he didn't response because he was not CCed.

thanks,
rui


Re: [PATCH 0/3] tools/thermal: tmon: Makefile improvements

2017-10-17 Thread Zhang Rui
On Fri, 2017-10-13 at 13:39 -0700, Markus Mayer wrote:
> On 27 September 2017 at 16:02, Markus Mayer  wrote:
> > 
> > From: Markus Mayer 
> > 
> > This series introduces a number of improvements to tmon's Makefile.
> > The
> > changes are meant to make it easier to cross-compile tmon on a
> > greater
> > number of platforms by giving more control to the person performing
> > the
> > build.
> > 
> > At the same time, sensible defaults are retained so that building
> > tmon
> > will continue to work without any customizations on platforms on
> > which
> > it currently builds.
> Rui, is there any chance you would be able to take this?
> 
yes, patches applied.

thanks,
rui
> Thanks,
> -Markus
> 
> > 
> > Markus Mayer (3):
> >   tools/thermal: tmon: use "-fstack-protector" only if supported
> >   tools/thermal: tmon: allow $(CC) to be defined externally
> >   tools/thermal: tmon: use $(PKG_CONFIG) instead of hard-coding
> > pkg-config
> > 
> >  tools/thermal/tmon/Makefile | 18 --
> >  1 file changed, 12 insertions(+), 6 deletions(-)
> > 
> > --
> > 2.7.4
> > 


Re: linux-next: manual merge of the thermal tree with the imx-mxs tree

2017-10-17 Thread Zhang Rui
Hi, Mark,

thanks for the fix.

On Mon, 2017-10-16 at 10:17 +0100, Mark Brown wrote:
> Hi Zhang,
> 
> Today's linux-next merge of the thermal tree got a conflict in:
> 
>   arch/arm/boot/dts/imx6ul.dtsi
> 
> between commit:
> 
>    efb9adb274754 ("ARM: dts: imx6ul: Remove leading zeroes from unit
> addresses")
> 
> from the imx-mxs tree and commit:
> 
>    1dc31d4981dd9 ("ARM: dts: imx6ul: Add imx6ul-tempmon")
> 
> from the thermal tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your
> tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any
> particularly
> complex conflicts.  Usually DTS changes go through arm-soc to avoid
> issues like this.

Shawn,

https://patchwork.kernel.org/patch/9841191/
https://patchwork.kernel.org/patch/9841193/
Should I drop these two dts patches and leave them to you?

thanks,
rui

> 
> diff --cc arch/arm/boot/dts/imx6ul.dtsi
> index 2057ee695a66,51717d54f285..
> --- a/arch/arm/boot/dts/imx6ul.dtsi
> +++ b/arch/arm/boot/dts/imx6ul.dtsi
> @@@ -860,13 -869,23 +869,23 @@@
>   reg = <0x021b 0x4000>;
>   };
>   
>  -ocotp: ocotp-ctrl@021bc000 {
>  +ocotp: ocotp-ctrl@21bc000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
>   compatible = "fsl,imx6ul-ocotp",
> "syscon";
>   reg = <0x021bc000 0x4000>;
>   clocks = < IMX6UL_CLK_OCOTP>;
> + 
> + tempmon_calib: calib@38 {
> + reg = <0x38 4>;
> + };
> + 
> + tempmon_temp_grade: temp-grade@20 {
> + reg = <0x20 4>;
> + };
>   };
>   
>  -lcdif: lcdif@021c8000 {
>  +lcdif: lcdif@21c8000 {
>   compatible = "fsl,imx6ul-lcdif",
> "fsl,imx28-lcdif";
>   reg = <0x021c8000 0x4000>;
>   interrupts =  IRQ_TYPE_LEVEL_HIGH>;


RE: [PATCH v4 2/4] thermal: add brcmstb AVS TMON driver

2017-09-26 Thread Zhang, Rui
Hi, Florian,

> -Original Message-
> From: Florian Fainelli [mailto:f.faine...@gmail.com]
> Sent: Tuesday, September 26, 2017 12:14 PM
> To: Zhang, Rui <rui.zh...@intel.com>; Rafal Milecki <ra...@milecki.pl>
> Cc: Markus Mayer <c...@mmayer.net>; Eduardo Valentin
> <edubez...@gmail.com>; Rob Herring <robh...@kernel.org>; Mark Rutland
> <mark.rutl...@arm.com>; Doug Berger <open...@gmail.com>; Brian
> Norris <computersforpe...@gmail.com>; Gregory Fong
> <gregory.0...@gmail.com>; Russell King <li...@armlinux.org.uk>; Catalin
> Marinas <catalin.mari...@arm.com>; Will Deacon <will.dea...@arm.com>;
> Arnd Bergmann <a...@arndb.de>; Olof Johansson <o...@lixom.net>;
> Broadcom Kernel List <bcm-kernel-feedback-l...@broadcom.com>; Power
> Management List <linux...@vger.kernel.org>; Device Tree List
> <devicet...@vger.kernel.org>; ARM Kernel List  ker...@lists.infradead.org>; Linux Kernel Mailing List  ker...@vger.kernel.org>; Markus Mayer <mma...@broadcom.com>
> Subject: Re: [PATCH v4 2/4] thermal: add brcmstb AVS TMON driver
> Importance: High
> 
> On 09/25/2017 08:02 PM, Zhang, Rui wrote:
> > Hi, Florian,
> >
> > This patch set was dropped in the last minute because of this
> > discussion https://patchwork.kernel.org/patch/9936325/
> > as I don’t want to rebase the patch before sending the pull request.
> 
> Ah, you wanted to squash that patch into the initial submission?
> 
> >
> > I don’t think we can make it for 4.14.
> > Eduardo will be back and pick the soc patches for 4.15.
> 
> I assume you would want to get that particular patch squashed into a clean
> submission targeting 4.15 now, right?
> 
Yes. As the patch in this thread has not been in upstream yet, I'd prefer the
fix/cleanup meld into the original patch before sending upstream.

Thanks,
Rui

> Thanks
> 
> >
> > Thanks,
> > rui
> >
> >
> >
> > -Original Message-
> > From: Florian Fainelli [mailto:f.faine...@gmail.com]
> > Sent: Monday, September 25, 2017 5:11 AM
> > To: Zhang, Rui <rui.zh...@intel.com>; Rafał Miłecki <ra...@milecki.pl>
> > Cc: Markus Mayer <c...@mmayer.net>; Eduardo Valentin
> > <edubez...@gmail.com>; Rob Herring <robh...@kernel.org>; Mark
> Rutland
> > <mark.rutl...@arm.com>; Doug Berger <open...@gmail.com>; Brian
> Norris
> > <computersforpe...@gmail.com>; Gregory Fong
> <gregory.0...@gmail.com>;
> > Russell King <li...@armlinux.org.uk>; Catalin Marinas
> > <catalin.mari...@arm.com>; Will Deacon <will.dea...@arm.com>; Arnd
> > Bergmann <a...@arndb.de>; Olof Johansson <o...@lixom.net>;
> Broadcom
> > Kernel List <bcm-kernel-feedback-l...@broadcom.com>; Power
> Management
> > List <linux...@vger.kernel.org>; Device Tree List
> > <devicet...@vger.kernel.org>; ARM Kernel List
> > <linux-arm-ker...@lists.infradead.org>; Linux Kernel Mailing List
> > <linux-kernel@vger.kernel.org>; Markus Mayer <mma...@broadcom.com>
> > Subject: Re: [PATCH v4 2/4] thermal: add brcmstb AVS TMON driver
> > Importance: High
> >
> > Le 08/14/17 à 23:48, Zhang Rui a écrit :
> >> On Tue, 2017-08-15 at 08:42 +0200, Rafał Miłecki wrote:
> >>> On 2017-08-15 08:08, Zhang Rui wrote:
> >>>>
> >>>>>
> >>>>> diff --git a/drivers/thermal/broadcom/Kconfig
> >>>>> b/drivers/thermal/broadcom/Kconfig
> >>>>> index 42c098e..c106a15 100644
> >>>>> --- a/drivers/thermal/broadcom/Kconfig
> >>>>> +++ b/drivers/thermal/broadcom/Kconfig
> >>>>> @@ -6,6 +6,13 @@ config BCM2835_THERMAL
> >>>>>     help
> >>>>>       Support for thermal sensors on Broadcom bcm2835 SoCs.
> >>>>>
> >>>>> +config BRCMSTB_THERMAL
> >>>>> +   tristate "Broadcom STB AVS TMON thermal driver"
> >>>>> +   depends on ARCH_BRCMSTB || COMPILE_TEST
> >>>>> +   help
> >>>>> +     Enable this driver if you have a Broadcom STB SoC and
> >>>>> would like
> >>>>> +     thermal framework support.
> >>>>> +
> >>>> I don't understand why I got the following checkpatch warning
> >>>>
> >>>> WARNING: please write a paragraph that describes the config symbol
> >>>> fully
> >>>> #73: FILE: drivers/thermal/broadcom/Kconfig:9:
> >>>> +config BRCMSTB_THERMAL
> >>>>
> >>>> I didn't see this for other Kconfig changes.
> >>> It's because your help message is only 2 lines long (instead of 3).
> >>>
> >>> Some (many?) maintainers aren't pedantic about that, a common sense
> >>> should be applied ;)
> >>
> >> thanks for explaining.
> >> Patch 1 and 2 queued for next merge window.
> >
> > Humm, I don't see this driver in your latest 4.14 pull request to Linus, so
> what happened here exactly? Can we expect this driver to be submitted for
> 4.14 or we just happened to have missed this window now?
> > --
> > Florian
> >
> 
> --
> Florian


RE: [PATCH v4 2/4] thermal: add brcmstb AVS TMON driver

2017-09-25 Thread Zhang, Rui
Hi, Florian,

This patch set was dropped in the last minute because of this discussion
https://patchwork.kernel.org/patch/9936325/
as I don’t want to rebase the patch before sending the pull request.

I don’t think we can make it for 4.14.
Eduardo will be back and pick the soc patches for 4.15.

Thanks,
rui



-Original Message-
From: Florian Fainelli [mailto:f.faine...@gmail.com] 
Sent: Monday, September 25, 2017 5:11 AM
To: Zhang, Rui <rui.zh...@intel.com>; Rafał Miłecki <ra...@milecki.pl>
Cc: Markus Mayer <c...@mmayer.net>; Eduardo Valentin <edubez...@gmail.com>; Rob 
Herring <robh...@kernel.org>; Mark Rutland <mark.rutl...@arm.com>; Doug Berger 
<open...@gmail.com>; Brian Norris <computersforpe...@gmail.com>; Gregory Fong 
<gregory.0...@gmail.com>; Russell King <li...@armlinux.org.uk>; Catalin Marinas 
<catalin.mari...@arm.com>; Will Deacon <will.dea...@arm.com>; Arnd Bergmann 
<a...@arndb.de>; Olof Johansson <o...@lixom.net>; Broadcom Kernel List 
<bcm-kernel-feedback-l...@broadcom.com>; Power Management List 
<linux...@vger.kernel.org>; Device Tree List <devicet...@vger.kernel.org>; ARM 
Kernel List <linux-arm-ker...@lists.infradead.org>; Linux Kernel Mailing List 
<linux-kernel@vger.kernel.org>; Markus Mayer <mma...@broadcom.com>
Subject: Re: [PATCH v4 2/4] thermal: add brcmstb AVS TMON driver
Importance: High

Le 08/14/17 à 23:48, Zhang Rui a écrit :
> On Tue, 2017-08-15 at 08:42 +0200, Rafał Miłecki wrote:
>> On 2017-08-15 08:08, Zhang Rui wrote:
>>>
>>>>
>>>> diff --git a/drivers/thermal/broadcom/Kconfig
>>>> b/drivers/thermal/broadcom/Kconfig
>>>> index 42c098e..c106a15 100644
>>>> --- a/drivers/thermal/broadcom/Kconfig
>>>> +++ b/drivers/thermal/broadcom/Kconfig
>>>> @@ -6,6 +6,13 @@ config BCM2835_THERMAL
>>>>    help
>>>>      Support for thermal sensors on Broadcom bcm2835 SoCs.
>>>>  
>>>> +config BRCMSTB_THERMAL
>>>> +  tristate "Broadcom STB AVS TMON thermal driver"
>>>> +  depends on ARCH_BRCMSTB || COMPILE_TEST
>>>> +  help
>>>> +    Enable this driver if you have a Broadcom STB SoC and
>>>> would like
>>>> +    thermal framework support.
>>>> +
>>> I don't understand why I got the following checkpatch warning
>>>
>>> WARNING: please write a paragraph that describes the config symbol 
>>> fully
>>> #73: FILE: drivers/thermal/broadcom/Kconfig:9:
>>> +config BRCMSTB_THERMAL
>>>
>>> I didn't see this for other Kconfig changes.
>> It's because your help message is only 2 lines long (instead of 3).
>>
>> Some (many?) maintainers aren't pedantic about that, a common sense 
>> should be applied ;)
> 
> thanks for explaining.
> Patch 1 and 2 queued for next merge window.

Humm, I don't see this driver in your latest 4.14 pull request to Linus, so 
what happened here exactly? Can we expect this driver to be submitted for 4.14 
or we just happened to have missed this window now?
--
Florian


Re: [PATCH v2 0/5] thermal: imx: Add nvmem-cells binding on imx6sx

2017-09-19 Thread Zhang Rui
On Thu, 2017-08-31 at 21:11 +0800, Zhang Rui wrote:
> On Thu, 2017-08-31 at 16:48 +0800, Shawn Guo wrote:
> > 
> > On Fri, Jul 14, 2017 at 05:11:05PM +0300, Leonard Crestez wrote:
> > > 
> > > 
> > > Leonard Crestez (5):
> > >   thermal: imx: Add nvmem-cells alternate binding for OCOTP
> > > access
> > >   nvmem: core: Add nvmem_cell_read_u32
> > >   thermal: imx: Add support for reading OCOTP through nvmem
> > >   ARM: dts: imx6sx: Use nvmem-cells for tempmon
> > >   ARM: dts: imx6ul: Add imx6ul-tempmon
> > For last two dts patches,
> > 
> > Acked-by: Shawn Guo <shawn...@kernel.org>
> thanks.
> I will push patch 1,3,4,5 after patch 2/5 merged.
> 
sorry that this patch set didn't catch this merge window.
I've rebased it on top of 4.14-rc1 and queued for 4.15.

thanks,
rui



[GIT PULL] Thermal management updates for v4.14-rc1

2017-09-11 Thread Zhang Rui
Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next

to receive the latest Thermal Management updates for v4.14-rc1 with
top-most commit b32b5e14b4e0d40e06f094d2593b447e00acdf37:

  Merge branches 'thermal-core', 'thermal-soc', 'thermal-intel' and
'const-thermal-zone-structure' into next (2017-09-08 11:20:04 +0800)

on top of commit 16f73eb02d7e1765ccab3d2018e0bd98eb93d973:

  Linux 4.13-rc3 (2017-07-30 12:40:36 -0700)

Specifics:

- Fix resources release in error paths when registering thermal zone.
(Christophe Jaillet)

- Introduce a new thermal driver for on-chip PVT (Process, Voltage and
Temperature) monitoring unit implemented on UniPhier SoCs. This driver
supports temperature monitoring and alert function. (Kunihiko Hayashi)

- Add support for mt2712 chip in the mtk_thermal driver. (Louis Yu)

- Add support for RK3328 SOC in rockchip_thermal driver. (Rocky Hao)

- cleanup a couple of platform thermal drivers to constify
thermal_zone_of_device_ops structures. (Julia Lawall)

- a couple of fixes in int340x and intel_pch_thermal thermal
driver.(Arvind Yadav, Sumeet Pawnikar, Brian Bian, Ed Swierk, Zhang
Rui)

thanks,
rui


Arnd Bergmann (1):
  thermal: fix INTEL_SOC_DTS_IOSF_CORE dependencies

Arvind Yadav (3):
  thermal: int340x: constify attribute_group structures.
  thermal: int340x_thermal: Constify attribute_group structures.
  thermal: intel_pch_thermal: constify pci_device_id.

Brian Bian (1):
  thermal: int3400_thermal: process "thermal table changed" event

Christophe Jaillet (3):
  thermal: core: Add some new helper functions to free resources
  thermal: core: Use the new 'thermal_zone_destroy_device_groups()'
helper function
  thermal: core: Fix resources release in error paths in
thermal_zone_device_register()

Ed Swierk (2):
  thermal: intel_pch_thermal: Read large temp values correctly
  thermal: intel_pch_thermal: Fix enable check on Broadwell-DE

Icenowy Zheng (1):
  thermal: core: fix some format issues on critical shutdown string

Julia Lawall (6):
  thermal: hisilicon: constify thermal_zone_of_device_ops
structures
  thermal: qoriq: constify thermal_zone_of_device_ops structures
  thermal: rcar_gen3_thermal: constify thermal_zone_of_device_ops
structures
  thermal: zx2967: constify thermal_zone_of_device_ops structures
  thermal: exynos: constify thermal_zone_of_device_ops structures
  thermal: bcm2835: constify thermal_zone_of_device_ops structures

Kunihiko Hayashi (2):
  dt-bindings: thermal: add binding documentation for UniPhier
thermal monitor
  thermal: uniphier: add UniPhier thermal driver

Louis Yu (4):
  dt-bindings: thermal: Add binding document for Mediatek thermal
controller
  thermal: mediatek: add Mediatek thermal driver for mt2712
  thermal: mediatek: extend calibration data for mt2712 chip
  thermal: mediatek: minor mtk_thermal.c cleanups

Rocky Hao (2):
  dt-bindings: rockchip-thermal: Support the RK3328 SoC compatible
  thermal: rockchip: Support the RK3328 SOC in thermal driver

Sumeet Pawnikar (1):
  Thermal/int340x: Fix few typos and kernel warn message

Zhang Rui (3):
  Thermal: int3406_thermal: fix thermal sysfs I/F
  Merge branches 'mediatek-mt2712', 'rockchip-rk3328' and
'uniphier-thermal' into thermal-soc
  Merge branches 'thermal-core', 'thermal-soc', 'thermal-intel' and
'const-thermal-zone-structure' into next

 .../bindings/thermal/mediatek-thermal.txt  |   1 +
 .../bindings/thermal/rockchip-thermal.txt  |   1 +
 .../bindings/thermal/uniphier-thermal.txt  |  64 
 drivers/thermal/Kconfig|  12 +-
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/broadcom/bcm2835_thermal.c |   2 +-
 drivers/thermal/hisi_thermal.c |   2 +-
 drivers/thermal/int340x_thermal/acpi_thermal_rel.c |   2 +-
 drivers/thermal/int340x_thermal/acpi_thermal_rel.h |   8 +-
 drivers/thermal/int340x_thermal/int3400_thermal.c  |  43 ++-
 drivers/thermal/int340x_thermal/int3406_thermal.c  |  96 ++
 .../int340x_thermal/processor_thermal_device.c |   2 +-
 drivers/thermal/intel_pch_thermal.c|  12 +-
 drivers/thermal/mtk_thermal.c  |  88 -
 drivers/thermal/qoriq_thermal.c|   2 +-
 drivers/thermal/rcar_gen3_thermal.c|   2 +-
 drivers/thermal/rockchip_thermal.c |  65 
 drivers/thermal/samsung/exynos_tmu.c   |   2 +-
 drivers/thermal/thermal_core.c |  31 +-
 drivers/thermal/thermal_core.h |   1 +
 drivers/thermal/thermal_sysfs.c|  29 ++
 drivers/thermal/uniphier_thermal.c | 384
+
 drivers/thermal/zx2967_thermal.c   |   2 +-
 inc

Re: linux-next: Signed-off-bys missing for commits in the thermal tree

2017-09-04 Thread Zhang Rui
On Tue, 2017-09-05 at 10:57 +1000, Stephen Rothwell wrote:
> Hi Zhang,
> 
> Commits
> 
>   1f0d851d9359 ("Debug patch")
>   083d998842a2 ("debug")
> 
> are missing a Signed-off-bys.
> 
> These are not really appropriate for linux-next inclusion -
> especially
> during the merge window.
> 
oops, sorry, wrong branch merged.

thanks,
rui


Re: [PATCH][next] Thermal: int3406_thermal: fix unused variable warning

2017-09-03 Thread Zhang Rui
On Fri, 2017-09-01 at 10:58 +0100, Colin King wrote:
> From: Colin Ian King 
> 
> The variable index was introduced by an earlier commit and is not
> used, and hence should be removed.
> 
> Cleans up warning: "unused variable 'index'"
> 
> Fixes: c658894562ba ("Thermal: int3406_thermal: fix thermal sysfs
> I/F")
> Signed-off-by: Colin Ian King 

thanks, I will fold this cleanup into the previous commit c658894562ba
("Thermal: int3406_thermal: fix thermal sysfs I/F").

thanks,
rui
> ---
>  drivers/thermal/int340x_thermal/int3406_thermal.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/thermal/int340x_thermal/int3406_thermal.c
> b/drivers/thermal/int340x_thermal/int3406_thermal.c
> index e31509ead1c9..f69ab026ba24 100644
> --- a/drivers/thermal/int340x_thermal/int3406_thermal.c
> +++ b/drivers/thermal/int340x_thermal/int3406_thermal.c
> @@ -113,7 +113,6 @@ static void int3406_thermal_get_limit(struct
> int3406_thermal_data *d)
>  {
>   acpi_status status;
>   unsigned long long lower_limit, upper_limit;
> - int index;
>  
>   status = acpi_evaluate_integer(d->handle, "DDDL", NULL,
> _limit);
>   if (ACPI_SUCCESS(status))


Re: [PATCH v2 5/5] thermal: Add Tegra BPMP thermal sensor driver

2017-08-31 Thread Zhang Rui
On Thu, 2017-08-31 at 14:45 +0200, Thierry Reding wrote:
> On Mon, Aug 21, 2017 at 10:40:44AM +0800, Wei Ni wrote:
> > 
> > 
> > 
> > On Friday, August 11, 2017 10:57 AM, Zhang Rui wrote:
> > > 
> > > On Mon, 2017-07-24 at 19:29 +0300, Mikko Perttunen wrote:
> > > > 
> > > > On Tegra186, the BPMP (Boot and Power Management Processor)
> > > > exposes
> > > > an
> > > > interface to thermal sensors on the system-on-chip. This driver
> > > > implements access to the interface. It supports reading the
> > > > temperature, setting trip points and receiving notification of
> > > > a
> > > > tripped trip point.
> > > > 
> > > > Signed-off-by: Mikko Perttunen <mperttu...@nvidia.com>

Acked-by: Zhang Rui <rui.zh...@intel.com>
for this patch and patch 1/5.


> > > Wei Ni,
> > > 
> > > what do you think of this patch?
> > Reviewed this patch, it looked fine to me.
> Hi Zhang,
> 
> given the build-time dependencies, how about if I take this into the
> Tegra tree with an Acked-by from you?

Sounds okay to me. Done. :)

thanks,
rui

>  I can provide a stable branch with
> the dependencies included if you want to pull it into your tree in
> order
> to resolve dependencies.
> 
> Thierry


Re: [PATCH v2 0/5] thermal: imx: Add nvmem-cells binding on imx6sx

2017-08-31 Thread Zhang Rui
On Thu, 2017-08-31 at 16:48 +0800, Shawn Guo wrote:
> On Fri, Jul 14, 2017 at 05:11:05PM +0300, Leonard Crestez wrote:
> > 
> > Leonard Crestez (5):
> >   thermal: imx: Add nvmem-cells alternate binding for OCOTP access
> >   nvmem: core: Add nvmem_cell_read_u32
> >   thermal: imx: Add support for reading OCOTP through nvmem
> >   ARM: dts: imx6sx: Use nvmem-cells for tempmon
> >   ARM: dts: imx6ul: Add imx6ul-tempmon
> For last two dts patches,
> 
> Acked-by: Shawn Guo 

thanks.
I will push patch 1,3,4,5 after patch 2/5 merged.

-rui


Re: [PATCH] thermal: max77620: constify platform_device_id

2017-08-24 Thread Zhang Rui
On Sun, 2017-08-13 at 17:03 +0530, Arvind Yadav wrote:
> platform_device_id are not supposed to change at runtime. All
> functions
> working with platform_device_id provided by 
> work with const platform_device_id. So mark the non-const structs as
> const.
> 
> Signed-off-by: Arvind Yadav 

applied.

thanks,
rui
> ---
>  drivers/thermal/max77620_thermal.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/max77620_thermal.c
> b/drivers/thermal/max77620_thermal.c
> index 159bbce..3c74b91 100644
> --- a/drivers/thermal/max77620_thermal.c
> +++ b/drivers/thermal/max77620_thermal.c
> @@ -149,7 +149,7 @@ static int max77620_thermal_probe(struct
> platform_device *pdev)
>   return 0;
>  }
>  
> -static struct platform_device_id max77620_thermal_devtype[] = {
> +static const struct platform_device_id max77620_thermal_devtype[] =
> {
>   { .name = "max77620-thermal", },
>   {},
>  };


Re: [PATCH v2 3/5] thermal: imx: Add support for reading OCOTP through nvmem

2017-08-24 Thread Zhang Rui
On Wed, 2017-08-16 at 18:33 +0300, Leonard Crestez wrote:
> On Tue, 2017-08-08 at 20:58 +0800, Zhang Rui wrote:
> > 
> > On Tue, 2017-08-08 at 12:44 +0100, Srinivas Kandagatla wrote:
> > > 
> > > On 08/08/17 12:38, Leonard Crestez wrote:
> > > > 
> > > > On Tue, 2017-08-08 at 12:00 +0100, Srinivas Kandagatla wrote:
> > > > > 
> > > > > On 08/08/17 08:21, Zhang Rui wrote:
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > I'm okay with the thermal change.
> > > > > > We still need ACK for the nvmem changes in this patch
> > > > > > series.
> > 
> > > 
> > > > 
> > > > > 
> > > > > NVMEM changes are already sent to Greg K H with other patches
> > > > > https://lkml.org/lkml/2017/8/8/436, should appear in next.
> > 
> > > 
> > > > 
> > > > These patches have a compile-time dependency on each other.
> > > > Wouldn't it make more sense for the whole series to go through
> > > > a single
> > > > maintainer tree, atomically? Most of the changes are in
> > > > driver/thermal.
> > 
> > > 
> > > I was expecting that the nvmem change go in as fix in a rc
> > > release
> > > so that you could apply the other patches after that.
> > > 
> > > Let me ping Greg about this!!
> > 

Srinivas,

Will you take patch 2/5?
Only after that, we can push the other changes.

thanks,
rui

> > As Shawn is okay with patch 4/5 and 5/5, I guess I can queue patch
> > 1/5,
> > 3/5, 4/5, 5/5 for 4.14-rc1, if the nvmem patch can catch 4.13, or I
> > can
> > queue the full patch set for 4.14, with Srinivas' ACK.
> It's been a week since the last email and it seems that nothing
> happened. I can't find any of these patches in either torvalds/master
> or linux-next. It seems to me that the nvmem series linked above was
> not picked up after all?
> 
> It's not clear how to proceed. It's been more a month since the
> series
> was sent so maybe I should resend it but it's not clear who would
> pick
> it up.
> 
> --
> Regards,
> Leonard


Re: [PATCH V1] thermal: qcom-spmi-temp-alarm: add support for GEN2 PMIC peripherals

2017-08-24 Thread Zhang Rui
On Thu, 2017-08-17 at 13:12 +0530, kgu...@codeaurora.org wrote:
> On 2017-08-16 17:53, kgu...@codeaurora.org wrote:
> > 
> > On 2017-08-08 13:42, Zhang Rui wrote:
> > > 
> > > On Thu, 2017-07-13 at 17:39 +0530, Kiran Gunda wrote:
> > > > 
> > > > From: David Collins <colli...@codeaurora.org>
> > > > 
> > > > Add support for the TEMP_ALARM GEN2 PMIC peripheral
> > > > subtype.  The
> > > > GEN2 subtype defines an over temperature state with hysteresis
> > > > instead of stage in the status register.  There are two GEN2
> > > > states corresponding to stages 1 and 2.
> > > > 
> > > > Signed-off-by: David Collins <colli...@codeaurora.org>
> > > > Signed-off-by: Kiran Gunda <kgu...@codeaurora.org>
> > > Ivan,
> > > 
> > > can you please review this patch and let me know your opinion?
> > > 
> > > thanks,
> > > rui
> > Ivan,
> > Could you please review this patch ?
> > 
> > Thanks,
> > Kiran
> Looks like Ivan is no more reviewing the patches for qcom.
> Adding Bjorn and Stephen Boyd for the review.
> 
Given this is a platform specific change, I will queue it for next
merge window, and let's see if there is any problem reported.

thanks,
rui
> Thanks,
> Kiran
> > 
> > > 
> > > > 
> > > > ---
> > > >  drivers/thermal/qcom-spmi-temp-alarm.c | 92
> > > > ++
> > > >  1 file changed, 71 insertions(+), 21 deletions(-)
> > > > 
> > > > diff --git a/drivers/thermal/qcom-spmi-temp-alarm.c
> > > > b/drivers/thermal/qcom-spmi-temp-alarm.c
> > > > index f502419..a5e17ba 100644
> > > > --- a/drivers/thermal/qcom-spmi-temp-alarm.c
> > > > +++ b/drivers/thermal/qcom-spmi-temp-alarm.c
> > > > @@ -1,5 +1,5 @@
> > > >  /*
> > > > - * Copyright (c) 2011-2015, The Linux Foundation. All rights
> > > > reserved.
> > > > + * Copyright (c) 2011-2015, 2017, The Linux Foundation. All
> > > > rights
> > > > reserved.
> > > >   *
> > > >   * This program is free software; you can redistribute it
> > > > and/or
> > > > modify
> > > >   * it under the terms of the GNU General Public License
> > > > version 2
> > > > and
> > > > @@ -11,6 +11,7 @@
> > > >   * GNU General Public License for more details.
> > > >   */
> > > >  
> > > > +#include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > @@ -29,13 +30,17 @@
> > > >  #define QPNP_TM_REG_ALARM_CTRL 0x46
> > > >  
> > > >  #define QPNP_TM_TYPE   0x09
> > > > -#define QPNP_TM_SUBTYPE0x08
> > > > +#define QPNP_TM_SUBTYPE_GEN1   0x08
> > > > +#define QPNP_TM_SUBTYPE_GEN2   0x09
> > > >  
> > > > -#define STATUS_STAGE_MASK  0x03
> > > > +#define STATUS_GEN1_STAGE_MASK GENMASK(1, 0)
> > > > +#define STATUS_GEN2_STATE_MASK GENMASK(6, 4)
> > > > +#define STATUS_GEN2_STATE_SHIFT4
> > > >  
> > > > -#define SHUTDOWN_CTRL1_THRESHOLD_MASK  0x03
> > > > +#define SHUTDOWN_CTRL1_OVERRIDE_MASK   GENMASK(7, 6)
> > > > +#define SHUTDOWN_CTRL1_THRESHOLD_MASK  GENMASK(1, 0)
> > > >  
> > > > -#define ALARM_CTRL_FORCE_ENABLE0x80
> > > > +#define ALARM_CTRL_FORCE_ENABLEBIT(7)
> > > >  
> > > >  /*
> > > >   * Trip point values based on threshold control
> > > > @@ -58,6 +63,7 @@
> > > >  struct qpnp_tm_chip {
> > > >     struct regmap   *map;
> > > >     struct thermal_zone_device  *tz_dev;
> > > > +   unsigned intsubtype;
> > > >     longtemp;
> > > >     unsigned intthresh;
> > > >     unsigned intstage;
> > > > @@ -66,6 +72,9 @@ struct qpnp_tm_chip {
> > > >     struct iio_channel  *adc;
> > > >  };
> > > >  
> > > > +/* This array maps from GEN2 alarm state to GEN1 alarm stage
> > > > */
> > > > +static const unsigned int alarm_state_map[8] = {0, 1, 1, 2, 2,
>

Re: [PATCH v4 2/4] thermal: add brcmstb AVS TMON driver

2017-08-15 Thread Zhang Rui
On Tue, 2017-08-15 at 08:42 +0200, Rafał Miłecki wrote:
> On 2017-08-15 08:08, Zhang Rui wrote:
> > 
> > > 
> > > diff --git a/drivers/thermal/broadcom/Kconfig
> > > b/drivers/thermal/broadcom/Kconfig
> > > index 42c098e..c106a15 100644
> > > --- a/drivers/thermal/broadcom/Kconfig
> > > +++ b/drivers/thermal/broadcom/Kconfig
> > > @@ -6,6 +6,13 @@ config BCM2835_THERMAL
> > >   help
> > >     Support for thermal sensors on Broadcom bcm2835 SoCs.
> > >  
> > > +config BRCMSTB_THERMAL
> > > + tristate "Broadcom STB AVS TMON thermal driver"
> > > + depends on ARCH_BRCMSTB || COMPILE_TEST
> > > + help
> > > +   Enable this driver if you have a Broadcom STB SoC and
> > > would like
> > > +   thermal framework support.
> > > +
> > I don't understand why I got the following checkpatch warning
> > 
> > WARNING: please write a paragraph that describes the config symbol
> > fully
> > #73: FILE: drivers/thermal/broadcom/Kconfig:9:
> > +config BRCMSTB_THERMAL
> > 
> > I didn't see this for other Kconfig changes.
> It's because your help message is only 2 lines long (instead of 3).
> 
> Some (many?) maintainers aren't pedantic about that, a common sense 
> should
> be applied ;)

thanks for explaining.
Patch 1 and 2 queued for next merge window.

-rui


Re: [PATCH v4 2/4] thermal: add brcmstb AVS TMON driver

2017-08-15 Thread Zhang Rui
On Wed, 2017-08-09 at 15:02 -0700, Markus Mayer wrote:
> From: Brian Norris 
> 
> The AVS TMON core provides temperature readings, a pair of
> configurable
> high- and low-temperature threshold interrupts, and an emergency
> over-temperature chip reset. The driver utilizes the first two to
> provide temperature readings and high-temperature notifications to
> applications. The over-temperature reset is not exposed to
> applications; this reset threshold is critical to the system and
> should
> be set with care within the bootloader.
> 
> Applications may choose to utilize the notification mechanism, the
> temperature reading mechanism (e.g., through polling), or both.
> 
> Signed-off-by: Brian Norris 
> Signed-off-by: Doug Berger 
> Signed-off-by: Markus Mayer 
> ---
>  drivers/thermal/Kconfig|   2 +-
>  drivers/thermal/broadcom/Kconfig   |   7 +
>  drivers/thermal/broadcom/Makefile  |   1 +
>  drivers/thermal/broadcom/brcmstb_thermal.c | 386
> +
>  4 files changed, 395 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/thermal/broadcom/brcmstb_thermal.c
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index b5b5fac..396ad6b 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -408,7 +408,7 @@ config MTK_THERMAL
>     controller present in Mediatek SoCs
>  
>  menu "Broadcom thermal drivers"
> -depends on ARCH_BCM || COMPILE_TEST
> +depends on ARCH_BCM || ARCH_BRCMSTB || COMPILE_TEST
>  source "drivers/thermal/broadcom/Kconfig"
>  endmenu
>  
> diff --git a/drivers/thermal/broadcom/Kconfig
> b/drivers/thermal/broadcom/Kconfig
> index 42c098e..c106a15 100644
> --- a/drivers/thermal/broadcom/Kconfig
> +++ b/drivers/thermal/broadcom/Kconfig
> @@ -6,6 +6,13 @@ config BCM2835_THERMAL
>   help
>     Support for thermal sensors on Broadcom bcm2835 SoCs.
>  
> +config BRCMSTB_THERMAL
> + tristate "Broadcom STB AVS TMON thermal driver"
> + depends on ARCH_BRCMSTB || COMPILE_TEST
> + help
> +   Enable this driver if you have a Broadcom STB SoC and
> would like
> +   thermal framework support.
> +

I don't understand why I got the following checkpatch warning

WARNING: please write a paragraph that describes the config symbol
fully
#73: FILE: drivers/thermal/broadcom/Kconfig:9:
+config BRCMSTB_THERMAL

I didn't see this for other Kconfig changes.

thanks,
rui

>  config BCM_NS_THERMAL
>   tristate "Northstar thermal driver"
>   depends on ARCH_BCM_IPROC || COMPILE_TEST
> diff --git a/drivers/thermal/broadcom/Makefile
> b/drivers/thermal/broadcom/Makefile
> index c6f62e4..fae10ec 100644
> --- a/drivers/thermal/broadcom/Makefile
> +++ b/drivers/thermal/broadcom/Makefile
> @@ -1,2 +1,3 @@
>  obj-$(CONFIG_BCM2835_THERMAL)+= bcm2835_thermal.o
> +obj-$(CONFIG_BRCMSTB_THERMAL)+= brcmstb_thermal.o
>  obj-$(CONFIG_BCM_NS_THERMAL) += ns-thermal.o
> diff --git a/drivers/thermal/broadcom/brcmstb_thermal.c
> b/drivers/thermal/broadcom/brcmstb_thermal.c
> new file mode 100644
> index 000..87b8e7a
> --- /dev/null
> +++ b/drivers/thermal/broadcom/brcmstb_thermal.c
> @@ -0,0 +1,386 @@
> +/*
> + * Broadcom STB AVS TMON thermal sensor driver
> + *
> + * Copyright (c) 2015-2017 Broadcom
> + *
> + * 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.
> + *
> + */
> +
> +#define DRV_NAME "brcmstb_thermal"
> +
> +#define pr_fmt(fmt)  DRV_NAME ": " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define AVS_TMON_STATUS  0x00
> + #define AVS_TMON_STATUS_valid_msk   BIT(11)
> + #define AVS_TMON_STATUS_data_mskGENMASK(10, 1)
> + #define AVS_TMON_STATUS_data_shift  1
> +
> +#define AVS_TMON_EN_OVERTEMP_RESET   0x04
> + #define AVS_TMON_EN_OVERTEMP_RESET_msk  BIT(0)
> +
> +#define AVS_TMON_RESET_THRESH0x08
> + #define AVS_TMON_RESET_THRESH_msk   GENMASK(10, 1)
> + #define AVS_TMON_RESET_THRESH_shift 1
> +
> +#define AVS_TMON_INT_IDLE_TIME   0x10
> +
> +#define AVS_TMON_EN_TEMP_INT_SRCS0x14
> + #define AVS_TMON_EN_TEMP_INT_SRCS_high  BIT(1)
> + #define AVS_TMON_EN_TEMP_INT_SRCS_low   BIT(0)
> +
> +#define AVS_TMON_INT_THRESH  0x18
> + #define AVS_TMON_INT_THRESH_high_mskGENMASK(26, 17)
> + #define AVS_TMON_INT_THRESH_high_shift  17
> + 

Re: [PATCH 1/3 v2] thermal: core: Add some new helper functions to free resources

2017-08-11 Thread Zhang Rui
On Fri, 2017-08-11 at 09:30 +0200, walter harms wrote:
> 
> Am 08.08.2017 16:39, schrieb Christophe JAILLET:
> > 
> > In order to easily free resources allocated by
> > 'thermal_zone_create_device_groups()' we need 2 new helper
> > functions.
> > 
> > The first one undoes 'thermal_zone_create_device_groups()'.
> > The 2nd one undoes 'create_trip_attrs()', which is a function
> > called by
> > 'thermal_zone_create_device_groups()'.
> > 
> > Signed-off-by: Christophe JAILLET 
> > ---
> > These functions will be used in patch 2/3 in order to simplify
> > 'thermal_release()'
> > I've tried to implement it as close a possible as the way the
> > resources have
> > been allocated.
> > However, in 'thermal_release()', the code is simplier without some
> > additionnal 'if'.
> > No sure if we should prefer consistancy with allocation or
> > simplicity of code.
> > ---
> >  drivers/thermal/thermal_core.h  |  1 +
> >  drivers/thermal/thermal_sysfs.c | 29 +
> >  2 files changed, 30 insertions(+)
> > 
> > diff --git a/drivers/thermal/thermal_core.h
> > b/drivers/thermal/thermal_core.h
> > index 2412b3759e16..27e3b1df7360 100644
> > --- a/drivers/thermal/thermal_core.h
> > +++ b/drivers/thermal/thermal_core.h
> > @@ -71,6 +71,7 @@ int thermal_build_list_of_policies(char *buf);
> >  
> >  /* sysfs I/F */
> >  int thermal_zone_create_device_groups(struct thermal_zone_device
> > *, int);
> > +void thermal_zone_destroy_device_groups(struct thermal_zone_device
> > *);
> >  void thermal_cooling_device_setup_sysfs(struct
> > thermal_cooling_device *);
> >  /* used only at binding time */
> >  ssize_t
> > diff --git a/drivers/thermal/thermal_sysfs.c
> > b/drivers/thermal/thermal_sysfs.c
> > index a694de907a26..eb95d64b9446 100644
> > --- a/drivers/thermal/thermal_sysfs.c
> > +++ b/drivers/thermal/thermal_sysfs.c
> > @@ -605,6 +605,24 @@ static int create_trip_attrs(struct
> > thermal_zone_device *tz, int mask)
> >     return 0;
> >  }
> >  
> > +/**
> > + * destroy_trip_attrs() - create attributes for trip points
> > + * @tz:the thermal zone device
> > + *
> > + * helper function to free resources alocated by
> > create_trip_attrs()
> > + */
> > +static void(struct thermal_zone_device *tz)
> > +{
> > +   if (!tz)
> > +   return;
> > +
> > +   kfree(tz->trip_type_attrs);
> > +   kfree(tz->trip_temp_attrs);
> > +   if (tz->ops->get_trip_hyst)
> > +   kfree(tz->trip_hyst_attrs);
> > +   kfree(tz->trips_attribute_group.attrs);
> > +}
> > +
> >  int thermal_zone_create_device_groups(struct thermal_zone_device
> > *tz,
> >       int mask)
> >  {
> > @@ -637,6 +655,17 @@ int thermal_zone_create_device_groups(struct
> > thermal_zone_device *tz,
> >     return 0;
> >  }
> >  
> > +void thermal_zone_destroy_device_groups(struct thermal_zone_device
> > *tz)
> > +{
> > +   if (!tz)
> > +   return;
> > +
> > +   if (tz->trips)
> > +   destroy_trip_attrs(tz);
> why the check for tz->trips ?
> destroy_trip_attrs does not access tz->trips->
> 
tz->trips is an integer represents the number of trip points.

We add this check because there is not any trips attributes if we don't
have any trip points.
It is true that the code also works if we don't have this check as
destroy_trip_attrs() would be no-op when tz->trips equals 0.
But I won't say this check is wrong.

thanks,
rui
> re,
>  wh
> 
> > 
> > +
> > +   kfree(tz->device.groups);
> > +}
> > +
> >  /* sys I/F for cooling device */
> >  static ssize_t
> >  thermal_cooling_device_type_show(struct device *dev,


Re: [PATCH v2 0/5] thermal: rockchip: add tsadc support in thermal driver and IPA thermal control for rk3328 in dts

2017-08-11 Thread Zhang Rui
On Fri, 2017-08-11 at 08:27 +0200, Heiko Stuebner wrote:
> Hi,
> 
> Am Freitag, 11. August 2017, 12:51:35 CEST schrieb Zhang Rui:
> > 
> > On Fri, 2017-08-04 at 16:06 +0800, Rocky Hao wrote:
> > > 
> > > This series patches add the tsadc support in thermal driver and
> > > in
> > > devicetree for rk3328.
> > > Also add thermal control with Intelligent Power Allocation (IPA)
> > > policy by default.  Please
> > > refer to https://developer.arm.com/open-source/intelligent-power-
> > > allo
> > > cation for more information
> > > about IPA.
> > > 
> > > Rocky Hao (5):
> > >   dt-bindings: rockchip-thermal: Support the RK3328 SoC
> > > compatible
> > >   thermal: rockchip: Support the RK3328 SOC in thermal driver
> > >   arm64: dts: rockchip: add tsadc node for rk3328 SoC
> > >   arm64: dts: rockchip: add thermal nodes for rk3328 SoC
> > >   arm64: dts: rockchip: Enable tsadc module on RK3328 eavluation
> > > board
> > > 
> > I can take this patch set if we have ACK for patch 3, 4 and 5.
> I would prefer if you would just apply patches 1+2 alone and I'd take
> the devicetree patches through my tree.
> 
> Having devicetree stuff mingle in a lot of trees produces unnecessary
> conflicts, so the general best practice is having code + binding.txt
> going through the driver tree and devicetree stuff through the
> platform
> tree.
> 
OKay, I will take patch 1 and 2 and queue them for next merge window.

thanks,
rui
> 
> Thanks
> Heiko
> 


Re: [PATCH v4 0/4] thermal: add brcmstb AVS TMON driver

2017-08-10 Thread Zhang Rui
On Wed, 2017-08-09 at 15:02 -0700, Markus Mayer wrote:
> From: Markus Mayer 
> 
> This series adds the brcmstb AVS TMON driver.
> 
> The driver was originally written by Brian Norris.
> 
> This series is also available at
> https://github.com/mmayer/linux/tree/brcmstb-thermal-4.13-v4.
> 
> v1 of this series can be found at https://lkml.org/lkml/2017/6/5/921
> v2 of this series can be found at https://lkml.org/lkml/2017/7/21/585
> v3 of this series can be found at https://lkml.org/lkml/2017/7/31/710
> 
> Changes since v3:
> - Rebased on v4.13-rc3 to resolve conflicts in the MAINTAINERS file
> 
thanks, will apply this if we have ACK for patch 3 and 4.

thanks,
rui
> Changes since v2:
> - replaced calls to pr_debug() with calls to dev_dbg() [PATCH 2/4
> only]
> - all other patches are unchanged from v2
> 
> Changes since v1:
> - Fixed wording in binding document
> - Fixed lincensing to consistently mention GPL v2
> - Use thermal_zone_get_slope() and thermal_zone_get_offset()
> - Some minor clean-ups
> 
> Brian Norris (2):
>   Documentation: devicetree: add binding for Broadcom STB AVS TMON
>   thermal: add brcmstb AVS TMON driver
> 
> Markus Mayer (2):
>   ARM: multi_v7_defconfig: add CONFIG_BRCMSTB_THERMAL
>   arm64: defconfig: add CONFIG_BRCMSTB_THERMAL
> 
>  .../devicetree/bindings/thermal/brcm,avs-tmon.txt  |  20 ++
>  MAINTAINERS|   8 +
>  arch/arm/configs/multi_v7_defconfig|   1 +
>  arch/arm64/configs/defconfig   |   1 +
>  drivers/thermal/Kconfig|   2 +-
>  drivers/thermal/broadcom/Kconfig   |   7 +
>  drivers/thermal/broadcom/Makefile  |   1 +
>  drivers/thermal/broadcom/brcmstb_thermal.c | 386
> +
>  8 files changed, 425 insertions(+), 1 deletion(-)
>  create mode 100644
> Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt
>  create mode 100644 drivers/thermal/broadcom/brcmstb_thermal.c
> 


Re: [PATCH v2 0/5] thermal: rockchip: add tsadc support in thermal driver and IPA thermal control for rk3328 in dts

2017-08-10 Thread Zhang Rui
On Fri, 2017-08-04 at 16:06 +0800, Rocky Hao wrote:
> This series patches add the tsadc support in thermal driver and in
> devicetree for rk3328.
> Also add thermal control with Intelligent Power Allocation (IPA)
> policy by default.  Please
> refer to https://developer.arm.com/open-source/intelligent-power-allo
> cation for more information
> about IPA.
> 
> Rocky Hao (5):
>   dt-bindings: rockchip-thermal: Support the RK3328 SoC compatible
>   thermal: rockchip: Support the RK3328 SOC in thermal driver
>   arm64: dts: rockchip: add tsadc node for rk3328 SoC
>   arm64: dts: rockchip: add thermal nodes for rk3328 SoC
>   arm64: dts: rockchip: Enable tsadc module on RK3328 eavluation
> board
> 
I can take this patch set if we have ACK for patch 3, 4 and 5.

thanks,
rui
>  .../bindings/thermal/rockchip-thermal.txt  |  1 +
>  arch/arm64/boot/dts/rockchip/rk3328-evb.dts|  4 ++
>  arch/arm64/boot/dts/rockchip/rk3328.dtsi   | 63
> +
>  drivers/thermal/rockchip_thermal.c | 65
> ++
>  4 files changed, 133 insertions(+)
> 


Re: [PATCH 0/9 v2] constify thermal_zone_of_device_ops structures

2017-08-10 Thread Zhang Rui
On Tue, 2017-08-08 at 17:08 +0200, Julia Lawall wrote:
> The thermal_zone_of_device_ops structures are only passed as the
> fourth
> argument to thermal_zone_of_sensor_register or
> devm_thermal_zone_of_sensor_register, both of which are declared as
> const.
> Thus the thermal_zone_of_device_ops structures themselves can be
> const.
> 
> v2: add structures passed to devm_thermal_zone_of_sensor_register
> also.
> 
> Done with the help of Coccinelle.
> 
I don't see the patches changes out of drivers/thermal.

As there is no dependencies between these patches, I guess I will only
take patches that changes drivers/thermal.

thanks,
rui
> ---
> 
>  drivers/hwmon/hwmon.c  |2 +-
>  drivers/hwmon/scpi-hwmon.c |2 +-
>  drivers/input/touchscreen/sun4i-ts.c   |2 +-
>  drivers/thermal/broadcom/bcm2835_thermal.c |2 +-
>  drivers/thermal/hisi_thermal.c |2 +-
>  drivers/thermal/qoriq_thermal.c|2 +-
>  drivers/thermal/rcar_gen3_thermal.c|2 +-
>  drivers/thermal/samsung/exynos_tmu.c   |2 +-
>  drivers/thermal/zx2967_thermal.c   |2 +-
>  9 files changed, 9 insertions(+), 9 deletions(-)


Re: [PATCH 1/3 v2] thermal: core: Add some new helper functions to free resources

2017-08-10 Thread Zhang Rui
On Fri, 2017-08-11 at 11:23 +0800, Zhang Rui wrote:
> On Tue, 2017-08-08 at 16:39 +0200, Christophe JAILLET wrote:
> > 
> > In order to easily free resources allocated by
> > 'thermal_zone_create_device_groups()' we need 2 new helper
> > functions.
> > 
> > The first one undoes 'thermal_zone_create_device_groups()'.
> > The 2nd one undoes 'create_trip_attrs()', which is a function
> > called
> > by
> > 'thermal_zone_create_device_groups()'.
> > 
> > Signed-off-by: Christophe JAILLET <christophe.jail...@wanadoo.fr>
> > ---
> > These functions will be used in patch 2/3 in order to simplify
> > 'thermal_release()'
> > I've tried to implement it as close a possible as the way the
> > resources have
> > been allocated.
> > However, in 'thermal_release()', the code is simplier without some
> > additionnal 'if'.
> > No sure if we should prefer consistancy with allocation or
> > simplicity
> > of code.
> > ---
> >  drivers/thermal/thermal_core.h  |  1 +
> >  drivers/thermal/thermal_sysfs.c | 29 +
> >  2 files changed, 30 insertions(+)
> > 
> > diff --git a/drivers/thermal/thermal_core.h
> > b/drivers/thermal/thermal_core.h
> > index 2412b3759e16..27e3b1df7360 100644
> > --- a/drivers/thermal/thermal_core.h
> > +++ b/drivers/thermal/thermal_core.h
> > @@ -71,6 +71,7 @@ int thermal_build_list_of_policies(char *buf);
> >  
> >  /* sysfs I/F */
> >  int thermal_zone_create_device_groups(struct thermal_zone_device
> > *,
> > int);
> > +void thermal_zone_destroy_device_groups(struct thermal_zone_device
> > *);
> >  void thermal_cooling_device_setup_sysfs(struct
> > thermal_cooling_device *);
> >  /* used only at binding time */
> >  ssize_t
> > diff --git a/drivers/thermal/thermal_sysfs.c
> > b/drivers/thermal/thermal_sysfs.c
> > index a694de907a26..eb95d64b9446 100644
> > --- a/drivers/thermal/thermal_sysfs.c
> > +++ b/drivers/thermal/thermal_sysfs.c
> > @@ -605,6 +605,24 @@ static int create_trip_attrs(struct
> > thermal_zone_device *tz, int mask)
> >     return 0;
> >  }
> >  
> > +/**
> > + * destroy_trip_attrs() - create attributes for trip points
> s/create/destroy
> 
> > 
> > + * @tz:the thermal zone device
> > + *
> > + * helper function to free resources alocated by
> > create_trip_attrs()
> s/alocated/allocated
> 
as I have only two minor comments for this patch set, I will apply it
directly, with these two typos fixed.

thanks,
rui
> thanks,
> rui
> > 
> > + */
> > +static void destroy_trip_attrs(struct thermal_zone_device *tz)
> > +{
> > +   if (!tz)
> > +   return;
> > +
> > +   kfree(tz->trip_type_attrs);
> > +   kfree(tz->trip_temp_attrs);
> > +   if (tz->ops->get_trip_hyst)
> > +   kfree(tz->trip_hyst_attrs);
> > +   kfree(tz->trips_attribute_group.attrs);
> > +}
> > +
> >  int thermal_zone_create_device_groups(struct thermal_zone_device
> > *tz,
> >       int mask)
> >  {
> > @@ -637,6 +655,17 @@ int thermal_zone_create_device_groups(struct
> > thermal_zone_device *tz,
> >     return 0;
> >  }
> >  
> > +void thermal_zone_destroy_device_groups(struct thermal_zone_device
> > *tz)
> > +{
> > +   if (!tz)
> > +   return;
> > +
> > +   if (tz->trips)
> > +   destroy_trip_attrs(tz);
> > +
> > +   kfree(tz->device.groups);
> > +}
> > +
> >  /* sys I/F for cooling device */
> >  static ssize_t
> >  thermal_cooling_device_type_show(struct device *dev,


Re: [PATCH 1/3 v2] thermal: core: Add some new helper functions to free resources

2017-08-10 Thread Zhang Rui
On Tue, 2017-08-08 at 16:39 +0200, Christophe JAILLET wrote:
> In order to easily free resources allocated by
> 'thermal_zone_create_device_groups()' we need 2 new helper functions.
> 
> The first one undoes 'thermal_zone_create_device_groups()'.
> The 2nd one undoes 'create_trip_attrs()', which is a function called
> by
> 'thermal_zone_create_device_groups()'.
> 
> Signed-off-by: Christophe JAILLET 
> ---
> These functions will be used in patch 2/3 in order to simplify
> 'thermal_release()'
> I've tried to implement it as close a possible as the way the
> resources have
> been allocated.
> However, in 'thermal_release()', the code is simplier without some
> additionnal 'if'.
> No sure if we should prefer consistancy with allocation or simplicity
> of code.
> ---
>  drivers/thermal/thermal_core.h  |  1 +
>  drivers/thermal/thermal_sysfs.c | 29 +
>  2 files changed, 30 insertions(+)
> 
> diff --git a/drivers/thermal/thermal_core.h
> b/drivers/thermal/thermal_core.h
> index 2412b3759e16..27e3b1df7360 100644
> --- a/drivers/thermal/thermal_core.h
> +++ b/drivers/thermal/thermal_core.h
> @@ -71,6 +71,7 @@ int thermal_build_list_of_policies(char *buf);
>  
>  /* sysfs I/F */
>  int thermal_zone_create_device_groups(struct thermal_zone_device *,
> int);
> +void thermal_zone_destroy_device_groups(struct thermal_zone_device
> *);
>  void thermal_cooling_device_setup_sysfs(struct
> thermal_cooling_device *);
>  /* used only at binding time */
>  ssize_t
> diff --git a/drivers/thermal/thermal_sysfs.c
> b/drivers/thermal/thermal_sysfs.c
> index a694de907a26..eb95d64b9446 100644
> --- a/drivers/thermal/thermal_sysfs.c
> +++ b/drivers/thermal/thermal_sysfs.c
> @@ -605,6 +605,24 @@ static int create_trip_attrs(struct
> thermal_zone_device *tz, int mask)
>   return 0;
>  }
>  
> +/**
> + * destroy_trip_attrs() - create attributes for trip points

s/create/destroy

> + * @tz:  the thermal zone device
> + *
> + * helper function to free resources alocated by create_trip_attrs()

s/alocated/allocated

thanks,
rui
> + */
> +static void destroy_trip_attrs(struct thermal_zone_device *tz)
> +{
> + if (!tz)
> + return;
> +
> + kfree(tz->trip_type_attrs);
> + kfree(tz->trip_temp_attrs);
> + if (tz->ops->get_trip_hyst)
> + kfree(tz->trip_hyst_attrs);
> + kfree(tz->trips_attribute_group.attrs);
> +}
> +
>  int thermal_zone_create_device_groups(struct thermal_zone_device
> *tz,
>     int mask)
>  {
> @@ -637,6 +655,17 @@ int thermal_zone_create_device_groups(struct
> thermal_zone_device *tz,
>   return 0;
>  }
>  
> +void thermal_zone_destroy_device_groups(struct thermal_zone_device
> *tz)
> +{
> + if (!tz)
> + return;
> +
> + if (tz->trips)
> + destroy_trip_attrs(tz);
> +
> + kfree(tz->device.groups);
> +}
> +
>  /* sys I/F for cooling device */
>  static ssize_t
>  thermal_cooling_device_type_show(struct device *dev,


Re: [PATCH] thermal/drivers/hisi: Remove confusing error message

2017-08-10 Thread Zhang Rui
On Tue, 2017-08-08 at 21:29 +0800, Leo Yan wrote:
> On Tue, Aug 08, 2017 at 08:48:51PM +0800, Zhang Rui wrote:
> 
> [...]
> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > @@ -352,10 +353,9 @@ static int hisi_thermal_probe(struct
> > > > > platform_device *pdev)
> > > > >   ret = hisi_thermal_register_sensor(pdev,
> > > > > data,
> > > > >      
> > > > > > 
> > > > > > 
> > > > > > sensors[i], i);
> > > > >   if (ret)
> > > > > - dev_err(>dev,
> > > > > - "failed to register thermal
> > > > > sensor:
> > > > > %d\n", ret);
> > > > > - else
> > > > > - hisi_thermal_toggle_sensor(
> > > > > > 
> > > > > > 
> > > > > > sensors[i], true);
> > > > > + continue;
> > > > > +
> > > > > + hisi_thermal_toggle_sensor(
> > > > > >sensors[i],
> > > > > true);
> > > > >   }
> > > > >  
> > > > >   return 0;
> > > > With these removed, is there any other information in dmesg
> > > > that
> > > > suggests this failure?
> > > The problem is there are always failures showed in dmesg. The
> > > init
> > > function is based on the assumption there is HISI_MAX_SENSORS
> > > sensors
> > > which is not true for the hi6220 and that raises at boot time
> > > errors.
> > > 
> > > Why HISI_MAX_SENSORS(=4) while there is only one on hi6220 AFAIK?
> > > and
> > > this driver is only used for hi6220 (now).
> > > 
> > right, I think we should remove one error log, and then change the
> > HISI_MAX_SENSORS to reflect the reality instead.
> > 
> > XinWei and Leo,
> > can you please help check this?
> Sure.
> 
> Here I am a bit confusion and I think this is a common question for
> SoC thermal driver.
> 
> Hi6220 does has 4 thermal sensors, but we now only use one sensor of
> them (thermal sensor id 2) to bind with thermal zone and other three
> sensors are not bound to any thermal zone. So this is the reason the
> booting reports the failure.
> 
> I think changing HISI_MAX_SENSORS value cannot resolve this issue,
> due
> we are using thermal id 2. How about below change? We change to use
> warning for sensors without binding, and remove redundant log.
> 
Now we will get three "thermal sensor %d has not bound" messages for
every normal probe, and an extra "failed to register thermal sensor:"
for a real failure probe?

If that's the case, as we are not using the sensors on purpose, why not
keep silence for -ENODEV?

thanks,
rui

> diff --git a/drivers/thermal/hisi_thermal.c
> b/drivers/thermal/hisi_thermal.c
> index 9c3ce34..6d34980 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -260,8 +260,6 @@ static int hisi_thermal_register_sensor(struct
> platform_device *pdev,
> if (IS_ERR(sensor->tzd)) {
> ret = PTR_ERR(sensor->tzd);
> sensor->tzd = NULL;
> -   dev_err(>dev, "failed to register sensor id %d:
> %d\n",
> -   sensor->id, ret);
> return ret;
> }
>  
> @@ -351,7 +349,10 @@ static int hisi_thermal_probe(struct
> platform_device *pdev)
> for (i = 0; i < HISI_MAX_SENSORS; ++i) {
> ret = hisi_thermal_register_sensor(pdev, data,
>    >sensors[i], 
> i);
> -   if (ret)
> +   if (ret == -ENODEV)
> +   dev_warn(>dev,
> +"thermal sensor %d has not bound\n",
> i);
> +   else if (ret)
> dev_err(>dev,
> "failed to register thermal sensor:
> %d\n", ret);
> else
> 
> Thanks,
> Leo Yan


Re: [PATCH] thermal: rockchip: fix error return code in rockchip_thermal_probe()

2017-08-10 Thread Zhang Rui
On Mon, 2017-08-07 at 23:35 -0500, Gustavo A. R. Silva wrote:
> platform_get_irq() returns an error code, but the rockchip_thermal
> driver
> ignores it and always returns -EINVAL. This is not correct and,
> prevents
> -EPROBE_DEFER from being propagated properly.
> 
> Notice that platform_get_irq() no longer returns 0 on error:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/co
> mmit/?id=e330b9a6bb35dc7097a4f02cb1ae7b6f96df92af
> 
> Print and propagate the return value of platform_get_irq on failure.
> 
> This issue was detected with the help of Coccinelle.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.

thanks,
rui
> ---
>  drivers/thermal/rockchip_thermal.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/thermal/rockchip_thermal.c
> b/drivers/thermal/rockchip_thermal.c
> index 4c77965..6ca9747 100644
> --- a/drivers/thermal/rockchip_thermal.c
> +++ b/drivers/thermal/rockchip_thermal.c
> @@ -1068,8 +1068,8 @@ static int rockchip_thermal_probe(struct
> platform_device *pdev)
>  
>   irq = platform_get_irq(pdev, 0);
>   if (irq < 0) {
> - dev_err(>dev, "no irq resource?\n");
> - return -EINVAL;
> + dev_err(>dev, "no irq resource: %d\n", irq);
> + return irq;
>   }
>  
>   thermal = devm_kzalloc(>dev, sizeof(struct
> rockchip_thermal_data),


Re: [PATCH 2/5] thermal: rockchip: Support the RK3328 SOC in thermal driver

2017-08-10 Thread Zhang Rui
On Tue, 2017-07-25 at 17:09 +0800, Rocky Hao wrote:
> RK3328 SOC has one Temperature Sensor for CPU.
> 
> Change-Id: I176c76bae1801d815a513986cfefcb55272c69a8
> Signed-off-by: Rocky Hao 

Caesar,

what do you think of this patch?

thanks,
rui

> ---
>  drivers/thermal/rockchip_thermal.c | 65
> ++
>  1 file changed, 65 insertions(+)
> 
> diff --git a/drivers/thermal/rockchip_thermal.c
> b/drivers/thermal/rockchip_thermal.c
> index 4c7796512453..206035139110 100644
> --- a/drivers/thermal/rockchip_thermal.c
> +++ b/drivers/thermal/rockchip_thermal.c
> @@ -320,6 +320,44 @@ struct tsadc_table {
>   {0, 125000},
>  };
>  
> +static const struct tsadc_table rk3328_code_table[] = {
> + {0, -4},
> + {296, -4},
> + {304, -35000},
> + {313, -3},
> + {331, -2},
> + {340, -15000},
> + {349, -1},
> + {359, -5000},
> + {368, 0},
> + {378, 5000},
> + {388, 1},
> + {398, 15000},
> + {408, 2},
> + {418, 25000},
> + {429, 3},
> + {440, 35000},
> + {451, 4},
> + {462, 45000},
> + {473, 5},
> + {485, 55000},
> + {496, 6},
> + {508, 65000},
> + {521, 7},
> + {533, 75000},
> + {546, 8},
> + {559, 85000},
> + {572, 9},
> + {586, 95000},
> + {600, 10},
> + {614, 105000},
> + {629, 11},
> + {644, 115000},
> + {659, 12},
> + {675, 125000},
> + {TSADCV2_DATA_MASK, 125000},
> +};
> +
>  static const struct tsadc_table rk3368_code_table[] = {
>   {0, -4},
>   {106, -4},
> @@ -790,6 +828,29 @@ static void rk_tsadcv2_tshut_mode(int chn, void
> __iomem *regs,
>   },
>  };
>  
> +static const struct rockchip_tsadc_chip rk3328_tsadc_data = {
> + .chn_id[SENSOR_CPU] = 0, /* cpu sensor is channel 0 */
> + .chn_num = 1, /* one channels for tsadc */
> +
> + .tshut_mode = TSHUT_MODE_CRU, /* default TSHUT via CRU */
> + .tshut_temp = 95000,
> +
> + .initialize = rk_tsadcv2_initialize,
> + .irq_ack = rk_tsadcv3_irq_ack,
> + .control = rk_tsadcv3_control,
> + .get_temp = rk_tsadcv2_get_temp,
> + .set_alarm_temp = rk_tsadcv2_alarm_temp,
> + .set_tshut_temp = rk_tsadcv2_tshut_temp,
> + .set_tshut_mode = rk_tsadcv2_tshut_mode,
> +
> + .table = {
> + .id = rk3328_code_table,
> + .length = ARRAY_SIZE(rk3328_code_table),
> + .data_mask = TSADCV2_DATA_MASK,
> + .mode = ADC_INCREMENT,
> + },
> +};
> +
>  static const struct rockchip_tsadc_chip rk3366_tsadc_data = {
>   .chn_id[SENSOR_CPU] = 0, /* cpu sensor is channel 0 */
>   .chn_id[SENSOR_GPU] = 1, /* gpu sensor is channel 1 */
> @@ -875,6 +936,10 @@ static void rk_tsadcv2_tshut_mode(int chn, void
> __iomem *regs,
>   .data = (void *)_tsadc_data,
>   },
>   {
> + .compatible = "rockchip,rk3328-tsadc",
> + .data = (void *)_tsadc_data,
> + },
> + {
>   .compatible = "rockchip,rk3366-tsadc",
>   .data = (void *)_tsadc_data,
>   },


Re: [PATCH v2 5/5] thermal: Add Tegra BPMP thermal sensor driver

2017-08-10 Thread Zhang Rui
On Mon, 2017-07-24 at 19:29 +0300, Mikko Perttunen wrote:
> On Tegra186, the BPMP (Boot and Power Management Processor) exposes
> an
> interface to thermal sensors on the system-on-chip. This driver
> implements access to the interface. It supports reading the
> temperature, setting trip points and receiving notification of a
> tripped trip point.
> 
> Signed-off-by: Mikko Perttunen 

Wei Ni,

what do you think of this patch?

thanks,
rui
> ---
> v2:
> - don't allocate space for disabled zones
> - allow compilation with COMPILE_TEST
> 
>  drivers/thermal/Makefile |   2 +-
>  drivers/thermal/tegra/Kconfig|   7 +
>  drivers/thermal/tegra/Makefile   |   3 +-
>  drivers/thermal/tegra/bpmp-thermal.c | 263
> +++
>  4 files changed, 273 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/thermal/tegra/bpmp-thermal.c
> 
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 094d7039981c..c03dccdba7b8 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -54,7 +54,7 @@ obj-$(CONFIG_INTEL_BXT_PMIC_THERMAL) +=
> intel_bxt_pmic_thermal.o
>  obj-$(CONFIG_INTEL_PCH_THERMAL)  += intel_pch_thermal.o
>  obj-$(CONFIG_ST_THERMAL) += st/
>  obj-$(CONFIG_QCOM_TSENS) += qcom/
> -obj-$(CONFIG_TEGRA_SOCTHERM) += tegra/
> +obj-y+= tegra/
>  obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
>  obj-$(CONFIG_MTK_THERMAL)+= mtk_thermal.o
>  obj-$(CONFIG_GENERIC_ADC_THERMAL)+= thermal-generic-adc.o
> diff --git a/drivers/thermal/tegra/Kconfig
> b/drivers/thermal/tegra/Kconfig
> index cec586ec7e4b..f8740f7852e3 100644
> --- a/drivers/thermal/tegra/Kconfig
> +++ b/drivers/thermal/tegra/Kconfig
> @@ -10,4 +10,11 @@ config TEGRA_SOCTHERM
>     zones to manage temperatures. This option is also required
> for the
>     emergency thermal reset (thermtrip) feature to function.
>  
> +config TEGRA_BPMP_THERMAL
> + tristate "Tegra BPMP thermal sensing"
> + depends on TEGRA_BPMP || COMPILE_TEST
> + help
> +  Enable this option for support for sensing system
> temperature of NVIDIA
> +  Tegra systems-on-chip with the BPMP coprocessor (Tegra186).
> +
>  endmenu
> diff --git a/drivers/thermal/tegra/Makefile
> b/drivers/thermal/tegra/Makefile
> index 1ce1af2cf0f5..757abcd1feaf 100644
> --- a/drivers/thermal/tegra/Makefile
> +++ b/drivers/thermal/tegra/Makefile
> @@ -1,4 +1,5 @@
> -obj-$(CONFIG_TEGRA_SOCTHERM) += tegra-soctherm.o
> +obj-$(CONFIG_TEGRA_SOCTHERM) += tegra-soctherm.o
> +obj-$(CONFIG_TEGRA_BPMP_THERMAL) += bpmp-thermal.o
>  
>  tegra-soctherm-y := soctherm.o
> soctherm-fuse.o
>  tegra-soctherm-$(CONFIG_ARCH_TEGRA_124_SOC)  += tegra124-
> soctherm.o
> diff --git a/drivers/thermal/tegra/bpmp-thermal.c
> b/drivers/thermal/tegra/bpmp-thermal.c
> new file mode 100644
> index ..b0980dbca3b3
> --- /dev/null
> +++ b/drivers/thermal/tegra/bpmp-thermal.c
> @@ -0,0 +1,263 @@
> +/*
> + * Copyright (c) 2015-2017, NVIDIA CORPORATION.  All rights
> reserved.
> + *
> + * Author:
> + *   Mikko Perttunen 
> + *   Aapo Vienamo
> + *
> + * 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 
> +
> +struct tegra_bpmp_thermal_zone {
> + struct tegra_bpmp_thermal *tegra;
> + struct thermal_zone_device *tzd;
> + struct work_struct tz_device_update_work;
> + unsigned int idx;
> +};
> +
> +struct tegra_bpmp_thermal {
> + struct device *dev;
> + struct tegra_bpmp *bpmp;
> + unsigned int num_zones;
> + struct tegra_bpmp_thermal_zone **zones;
> +};
> +
> +static int tegra_bpmp_thermal_get_temp(void *data, int *out_temp)
> +{
> + struct tegra_bpmp_thermal_zone *zone = data;
> + struct mrq_thermal_host_to_bpmp_request req;
> + union mrq_thermal_bpmp_to_host_response reply;
> + struct tegra_bpmp_message msg;
> + int err;
> +
> + memset(, 0, sizeof(req));
> + req.type = CMD_THERMAL_GET_TEMP;
> + req.get_temp.zone = zone->idx;
> +
> + memset(, 0, sizeof(msg));
> + msg.mrq = MRQ_THERMAL;
> + msg.tx.data = 
> + msg.tx.size = sizeof(req);
> + msg.rx.data = 
> + msg.rx.size = sizeof(reply);
> +
> + err = tegra_bpmp_transfer(zone->tegra->bpmp, );
> + if (err)
> + return err;
> +
> + *out_temp = reply.get_temp.temp;
> +
> + return 0;

Re: [PATCH 0/4] constify thermal_zone_of_device_ops structures

2017-08-08 Thread Zhang Rui
On Sat, 2017-08-05 at 22:37 +0200, Julia Lawall wrote:
> The thermal_zone_of_device_ops structures are only passed as the
> fourth
> argument to thermal_zone_of_sensor_register, which is declared as
> const.
> Thus the thermal_zone_of_device_ops structures themselves can be
> const.
> 
> Done with the help of Coccinelle.

I still see the same problem in other thermal drivers, which is not
covered by this patch set. Can we fix them all in one time?

thanks,
rui
> 
> ---
> 
>  drivers/thermal/broadcom/bcm2835_thermal.c |2 +-
>  drivers/thermal/qoriq_thermal.c|2 +-
>  drivers/thermal/samsung/exynos_tmu.c   |2 +-
>  drivers/thermal/zx2967_thermal.c   |2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)


Re: [PATCH v6 2/2] thermal: uniphier: add UniPhier thermal driver

2017-08-08 Thread Zhang Rui
On Tue, 2017-08-01 at 17:04 +0900, Kunihiko Hayashi wrote:
> Add a thermal driver for on-chip PVT (Process, Voltage and
> Temperature)
> monitoring unit implemented on UniPhier SoCs. This driver supports
> temperature monitoring and alert function.
> 
> Signed-off-by: Kunihiko Hayashi 
> ---
>  drivers/thermal/Kconfig|   8 +
>  drivers/thermal/Makefile   |   1 +
>  drivers/thermal/uniphier_thermal.c | 384
> +
>  3 files changed, 393 insertions(+)
>  create mode 100644 drivers/thermal/uniphier_thermal.c
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index b5b5fac..b9f2365 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -473,4 +473,12 @@ config ZX2967_THERMAL
>     the primitive temperature sensor embedded in zx2967 SoCs.
>     This sensor generates the real time die temperature.
>  
> +config UNIPHIER_THERMAL
> + tristate "Socionext UniPhier thermal driver"
> + depends on ARCH_UNIPHIER || COMPILE_TEST
> + depends on THERMAL_OF && MFD_SYSCON
> + help
> +   Enable this to plug in UniPhier on-chip PVT thermal driver
> into the
> +   thermal framework. The driver supports CPU thermal zone
> temperature
> +   reporting and a couple of trip points.

just one minor comments.

you mentioned trip points here, but I don't find the code support.

thanks,
rui

>  endif
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 094d703..8b79bca 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -59,3 +59,4 @@ obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
>  obj-$(CONFIG_MTK_THERMAL)+= mtk_thermal.o
>  obj-$(CONFIG_GENERIC_ADC_THERMAL)+= thermal-generic-adc.o
>  obj-$(CONFIG_ZX2967_THERMAL) += zx2967_thermal.o
> +obj-$(CONFIG_UNIPHIER_THERMAL)   += uniphier_thermal.o
> diff --git a/drivers/thermal/uniphier_thermal.c
> b/drivers/thermal/uniphier_thermal.c
> new file mode 100644
> index 000..9570473
> --- /dev/null
> +++ b/drivers/thermal/uniphier_thermal.c
> @@ -0,0 +1,384 @@
> +/**
> + * uniphier_thermal.c - Socionext UniPhier thermal driver
> + *
> + * Copyright 2014  Panasonic Corporation
> + * Copyright 2016-2017 Socionext Inc.
> + * All rights reserved.
> + *
> + * Author:
> + *   Kunihiko Hayashi 
> + *
> + * This program is free software: you can redistribute it and/or
> modify
> + * it under the terms of the GNU General Public License version
> 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * 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 
> +#include 
> +#include 
> +
> +#include "thermal_core.h"
> +
> +/*
> + * block registers
> + * addresses are the offset from .block_base
> + */
> +#define PVTCTLEN 0x
> +#define PVTCTLEN_EN  BIT(0)
> +
> +#define PVTCTLMODE   0x0004
> +#define PVTCTLMODE_MASK  0xf
> +#define PVTCTLMODE_TEMPMON   0x5
> +
> +#define EMONREPEAT   0x0040
> +#define EMONREPEAT_ENDLESS   BIT(24)
> +#define EMONREPEAT_PERIODGENMASK(3, 0)
> +#define EMONREPEAT_PERIOD_1000x9
> +
> +/*
> + * common registers
> + * addresses are the offset from .map_base
> + */
> +#define PVTCTLSEL0x0900
> +#define PVTCTLSEL_MASK   GENMASK(2, 0)
> +#define PVTCTLSEL_MONITOR0
> +
> +#define SETALERT00x0910
> +#define SETALERT10x0914
> +#define SETALERT20x0918
> +#define SETALERT_TEMP_OVF(GENMASK(7, 0) << 16)
> +#define SETALERT_TEMP_OVF_VALUE(val) (((val) & GENMASK(7, 0))
> << 16)
> +#define SETALERT_EN  BIT(0)
> +
> +#define PMALERTINTCTL0x0920
> +#define PMALERTINTCTL_CLR(ch)BIT(4 * (ch) + 2)
> +#define PMALERTINTCTL_SET(ch)BIT(4 * (ch) + 1)
> +#define PMALERTINTCTL_EN(ch) BIT(4 * (ch) + 0)
> +#define PMALERTINTCTL_MASK   (GENMASK(10, 8) |
> GENMASK(6, 4) | \
> +  GENMASK(2, 0))
> +
> +#define TMOD 0x0928
> +#define TMOD_WIDTH   9
> +
> +#define TMODCOEF 0x0e5c
> +
> +#define TMODSETUP0_ENBIT(30)
> +#define TMODSETUP0_VAL(val)  (((val) & GENMASK(13, 0))
> << 16)
> +#define TMODSETUP1_ENBIT(15)
> +#define TMODSETUP1_VAL(val)  ((val) & GENMASK(14, 0))
> +
> +/* SoC critical temperature */
> +#define CRITICAL_TEMP_LIMIT  

Re: [PATCH 2/3] thermal: core: Reorder 'thermal_zone_device_register()' error handling code

2017-08-08 Thread Zhang Rui
On Tue, 2017-08-08 at 14:31 +0200, Christophe JAILLET wrote:
> Le 08/08/2017 à 10:49, Zhang Rui a écrit :
> > 
> > On Sun, 2017-07-16 at 08:59 +0200, Christophe JAILLET wrote:
> > > 
> > > Reorder code in the error handling path in order to match the way
> > > resources
> > > have been allocated.
> > > 
> > > With this new order, we can avoid a call to 'device_unregister()'
> > > if
> > > 'thermal_zone_create_device_groups'()' fails. At this point,
> > > 'device_register()' has not been called yet.
> > > 
> > > Signed-off-by: Christophe JAILLET <christophe.jail...@wanadoo.fr>
> > > ---
> > >   drivers/thermal/thermal_core.c | 5 +++--
> > >   1 file changed, 3 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/thermal/thermal_core.c
> > > b/drivers/thermal/thermal_core.c
> > > index 9743f3e65eb0..c58714800660 100644
> > > --- a/drivers/thermal/thermal_core.c
> > > +++ b/drivers/thermal/thermal_core.c
> > > @@ -1232,7 +1232,7 @@ thermal_zone_device_register(const char
> > > *type,
> > > int trips, int mask,
> > >   /* Add nodes that are always present via .groups */
> > >   result = thermal_zone_create_device_groups(tz, mask);
> > >   if (result)
> > > - goto unregister;
> > > + goto remove_id;
> > > 
> > I agree we should release ida and free tz, like you did in this
> > patch.
> > 
> > But the problem is in the code below, where device_register()
> > fails,
> > we should free the resources allocated in
> > thermal_zone_create_device_groups() explicitly.
> > 
> > thanks,
> > rui
> Hi,
> 
> Thanks for the review.
> 
> 
> I will propose a v2 patch serie with some new helper functions:
> void destroy_trip_attrs(struct thermal_zone_device *tz)
> void thermal_zone_destroy_device_groups(struct
> thermal_zone_device *tz)
> 
> 'thermal_zone_destroy_device_groups()' will then be called in the
> error 
> handling path of 'thermal_zone_device_register()', when 
> 'device_register()' fails.
> 
> 
> Would you like me to keep the same patch granularity:
> - (new patch in the serie) - Add some new helper functions to
> free 
> resources

agreed.

> - add kfree(tz) in the actual error handling path(despite
> your 
> comment on patch 1/3, I still think it is needed in thie error
> handling 
> path)
> - reorder error handling code
> - avoid code duplication

we don't need to invoke kfree(tz) after device unregistered.
so if you want to share error handling code, there should be two error
handling paths, one before device registered, which needs kfree(tz),
and one after device registered.

thanks,
rui

> 
> Or the 3 last ones can be merged together under a generic "Fix
> resources 
> release in error paths in thermal_zone_device_register()" ?
> 
> CJ
> 
> > 
> > > 
> > >   /* A new thermal zone needs to be updated anyway. */
> > >   atomic_set(>need_update, 1);
> > > @@ -1294,8 +1294,9 @@ thermal_zone_device_register(const char
> > > *type,
> > > int trips, int mask,
> > >   return tz;
> > >   
> > >   unregister:
> > > - ida_simple_remove(_tz_ida, tz->id);
> > >   device_unregister(>device);
> > > +remove_id:
> > > + ida_simple_remove(_tz_ida, tz->id);
> > >   kfree(tz);
> > >   return ERR_PTR(result);
> > >   }
> 


Re: [PATCH v2 3/5] thermal: imx: Add support for reading OCOTP through nvmem

2017-08-08 Thread Zhang Rui
On Tue, 2017-08-08 at 12:44 +0100, Srinivas Kandagatla wrote:
> > 


> 
> On 08/08/17 12:38, Leonard Crestez wrote:
> > 
> > On Tue, 2017-08-08 at 12:00 +0100, Srinivas Kandagatla wrote:
> > > 
> > > On 08/08/17 08:21, Zhang Rui wrote:
> > > > 
> > > > On Tue, 2017-07-25 at 16:08 +0800, Shawn Guo wrote:
> > > > > 
> > > > > On Fri, Jul 14, 2017 at 05:11:08PM +0300, Leonard Crestez
> > > > > wrote:
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > On newer imx SOCs accessing OCOTP directly is wrong because
> > > > > > the
> > > > > > ocotp clock
> > > > > > needs to be enabled first. Add support for reading those
> > > > > > same
> > > > > > values through
> > > > > > the nvmem API instead.
> > > > > > 
> > > > > > The older path is preserved for compatibility with older
> > > > > > dts and
> > > > > > because it
> > > > > > works correctly on imx6qdl chips.
> > > > > > 
> > > > > > Signed-off-by: Leonard Crestez <leonard.cres...@nxp.com>
> > > > > Acked-by: Shawn Guo <shawn...@kernel.org>
> > > 
> > > > 
> > > > I'm okay with the thermal change.
> > > > We still need ACK for the nvmem changes in this patch series.
> > > 
> > > NVMEM changes are already sent to Greg K H with other patches
> > > (https://lkml.org/lkml/2017/7/26/164), should appear in next.
> > These patches have a compile-time dependency on each other.
> > Wouldn't it
> > make more sense for the whole series to go through a single
> > maintainer
> > tree, atomically? Most of the changes are in driver/thermal.
> I was expecting that the nvmem change go in as fix in a rc release
> so 
> that you could apply the other patches after that.
> 
> Let me ping Greg about this!!

As Shawn is okay with patch 4/5 and 5/5, I guess I can queue patch 1/5,
3/5, 4/5, 5/5 for 4.14-rc1, if the nvmem patch can catch 4.13, or I can
queue the full patch set for 4.14, with Srinivas' ACK.

thanks,
rui
> > 
> > I'm really very confused about how series that touch multiple areas
> > are
> > applied. It seems to be a mostly ad-hoc process.
> > 
> > --
> > Regards,
> > Leonard
> > 


Re: [PATCH] thermal/drivers/hisi: Remove confusing error message

2017-08-08 Thread Zhang Rui
On Tue, 2017-08-08 at 12:15 +0200, Daniel Lezcano wrote:
> On 08/08/2017 09:55, Zhang Rui wrote:
> > 
> > On Fri, 2017-07-07 at 17:03 +0200, Daniel Lezcano wrote:
> > > 
> > > The sensor id is unknown at init time and we use all id in the
> > > authorized
> > > MAX_SENSORS interval to register the sensor. On this SoC there is
> > > one
> > > thermal-zone with one sensor on it. No need to spit on the
> > > console
> > > everytime we
> > > failed to register thermal sensors, information which is
> > > deliberaly
> > > known as it
> > > is part of the discovery process.
> > > 
> > >  hisi_thermal f7030700.tsensor: failed to register sensor id 0:
> > > -19
> > >  hisi_thermal f7030700.tsensor: failed to register thermal
> > > sensor:
> > > -19
> > >  hisi_thermal f7030700.tsensor: failed to register sensor id 1:
> > > -19
> > >  hisi_thermal f7030700.tsensor: failed to register thermal
> > > sensor:
> > > -19
> > >  hisi_thermal f7030700.tsensor: failed to register sensor id 3:
> > > -19
> > >  hisi_thermal f7030700.tsensor: failed to register thermal
> > > sensor:
> > > -19
> > > 
> > > Remove the error messages.
> > > 
> > > Signed-off-by: Daniel Lezcano <daniel.lezc...@linaro.org>
> > > ---
> > >  drivers/thermal/hisi_thermal.c | 12 ++--
> > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/thermal/hisi_thermal.c
> > > b/drivers/thermal/hisi_thermal.c
> > > index f642966..2cc98c6 100644
> > > --- a/drivers/thermal/hisi_thermal.c
> > > +++ b/drivers/thermal/hisi_thermal.c
> > > @@ -187,6 +187,9 @@ static int hisi_thermal_get_temp(void
> > > *_sensor,
> > > int *temp)
> > >  
> > >   dev_dbg(>pdev->dev, "id=%d, irq=%d, temp=%d,
> > > thres=%d\n",
> > >   sensor->id, data->irq_enabled, *temp, sensor-
> > > > 
> > > > thres_temp);
> > > +
> > > + printk("id=%d, irq=%d, temp=%d, thres=%d\n",
> > > + sensor->id, data->irq_enabled, *temp, sensor-
> > > > 
> > > > thres_temp);
> > what's this printk for?
> Argh. It shouldn't be there.
> 
> > 
> > > 
> > >   /*
> > >    * Bind irq to sensor for two cases:
> > >    *   Reenable alarm IRQ if temperature below threshold;
> > > @@ -260,8 +263,6 @@ static int
> > > hisi_thermal_register_sensor(struct
> > > platform_device *pdev,
> > >   if (IS_ERR(sensor->tzd)) {
> > >   ret = PTR_ERR(sensor->tzd);
> > >   sensor->tzd = NULL;
> > > - dev_err(>dev, "failed to register sensor
> > > id
> > > %d: %d\n",
> > > - sensor->id, ret);
> > >   return ret;
> > >   }
> > >  
> > > @@ -352,10 +353,9 @@ static int hisi_thermal_probe(struct
> > > platform_device *pdev)
> > >   ret = hisi_thermal_register_sensor(pdev, data,
> > >      
> > > > 
> > > > sensors[i], i);
> > >   if (ret)
> > > - dev_err(>dev,
> > > - "failed to register thermal
> > > sensor:
> > > %d\n", ret);
> > > - else
> > > - hisi_thermal_toggle_sensor(
> > > > 
> > > > sensors[i], true);
> > > + continue;
> > > +
> > > + hisi_thermal_toggle_sensor(>sensors[i],
> > > true);
> > >   }
> > >  
> > >   return 0;
> > With these removed, is there any other information in dmesg that
> > suggests this failure?
> The problem is there are always failures showed in dmesg. The init
> function is based on the assumption there is HISI_MAX_SENSORS sensors
> which is not true for the hi6220 and that raises at boot time errors.
> 
> Why HISI_MAX_SENSORS(=4) while there is only one on hi6220 AFAIK? and
> this driver is only used for hi6220 (now).
> 
right, I think we should remove one error log, and then change the
HISI_MAX_SENSORS to reflect the reality instead.

XinWei and Leo,
can you please help check this?

thanks,
rui
> That ends up with 3 errors in dmesg for nothing.
> 
> 
> 
> 
> 


Re: [PATCH v3 1/4] Documentation: devicetree: add binding for Broadcom STB AVS TMON

2017-08-08 Thread Zhang Rui
On Mon, 2017-07-31 at 12:26 -0700, Markus Mayer wrote:
> From: Brian Norris 
> 
> Add binding for Broadcom STB thermal.
> 
> Signed-off-by: Brian Norris 
> Signed-off-by: Markus Mayer 

$ file v3-1-4-Documentation-devicetree-add-binding-for-Broadcom-STB-
AVS-TMON.patch 
unified diff output, UTF-8 Unicode text

BTW, can you please rebase this patch set on top of v4.13-rc3?
At least there are some conflicts in MAINTAINER file, introduced in
-rc2.

thanks,
rui
> ---
>  .../devicetree/bindings/thermal/brcm,avs-tmon.txt| 20
> 
>  MAINTAINERS  |  8 
>  2 files changed, 28 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt
> 
> diff --git a/Documentation/devicetree/bindings/thermal/brcm,avs-
> tmon.txt b/Documentation/devicetree/bindings/thermal/brcm,avs-
> tmon.txt
> new file mode 100644
> index 000..9d43553
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt
> @@ -0,0 +1,20 @@
> +* Broadcom STB thermal management
> +
> +Thermal management core, provided by the AVS TMON hardware block.
> +
> +Required properties:
> +- compatible: must be "brcm,avs-tmon" and/or "brcm,avs-tmon-bcm7445"
> +- reg: address range for the AVS TMON registers
> +- interrupts: temperature monitor interrupt, for high/low threshold
> triggers
> +- interrupt-names: should be "tmon"
> +- interrupt-parent: the parent interrupt controller
> +
> +Example:
> +
> + thermal@f04d1500 {
> + compatible = "brcm,avs-tmon-bcm7445", "brcm,avs-
> tmon";
> + reg = <0xf04d1500 0x28>;
> + interrupts = <0x6>;
> + interrupt-names = "tmon";
> + interrupt-parent = <_host_l2_intc>;
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 205d397..a683d4c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2928,6 +2928,14 @@ S: Maintained
>  F:   Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-
> cpu-freq.txt
>  F:   drivers/cpufreq/brcmstb*
>  
> +BROADCOM STB AVS TMON DRIVER
> +M:   Markus Mayer 
> +M:   bcm-kernel-feedback-l...@broadcom.com
> +L:   linux...@vger.kernel.org
> +S:   Maintained
> +F:   Documentation/devicetree/bindings/thermal/brcm,avs-
> tmon.txt
> +F:   drivers/thermal/broadcom/brcmstb*
> +
>  BROADCOM SPECIFIC AMBA DRIVER (BCMA)
>  M:   Rafał Miłecki 
>  L:   linux-wirel...@vger.kernel.org


Re: [PATCH v3 0/4] thermal: add brcmstb AVS TMON driver

2017-08-08 Thread Zhang Rui
On Mon, 2017-08-07 at 10:52 -0700, Florian Fainelli wrote:
> On 07/31/2017 12:26 PM, Markus Mayer wrote:
> > 
> > From: Markus Mayer 
> > 
> > This series adds the brcmstb AVS TMON driver.
> > 
> > The driver was originally written by Brian Norris.
> > 
> > v1 of this series can be found at https://lkml.org/lkml/2017/6/5/92
> > 1
> > v2 of this series can be found at https://lkml.org/lkml/2017/7/21/5
> > 85
> FWIW, this looks good to me, Eduardo, Rui, can we get this moving?
> 
Usually, Eduardo will take the arm soc thermal patches. But he is not
able to take it this time as he is really busy.
To me, the thermal framework related code looks good, and I will queue
it for next merge window, although I don't have the knowledge about the
hardware details.

thanks,
rui

> > 
> > 
> > Changes since v2:
> > - replaced calls to pr_debug() with calls to dev_dbg() [PATCH 2/4
> > only]
> > - all other patches are unchanged from v2
> > 
> > Changes since v1:
> > - Fixed wording in binding document
> > - Fixed lincensing to consistently mention GPL v2
> > - Use thermal_zone_get_slope() and thermal_zone_get_offset()
> > - Some minor clean-ups
> > 
> > Brian Norris (2):
> >   Documentation: devicetree: add binding for Broadcom STB AVS TMON
> >   thermal: add brcmstb AVS TMON driver
> > 
> > Markus Mayer (2):
> >   ARM: multi_v7_defconfig: add CONFIG_BRCMSTB_THERMAL
> >   arm64: defconfig: add CONFIG_BRCMSTB_THERMAL
> > 
> >  .../devicetree/bindings/thermal/brcm,avs-tmon.txt  |  20 ++
> >  MAINTAINERS|   8 +
> >  arch/arm/configs/multi_v7_defconfig|   1 +
> >  arch/arm64/configs/defconfig   |   1 +
> >  drivers/thermal/Kconfig|   2 +-
> >  drivers/thermal/broadcom/Kconfig   |   7 +
> >  drivers/thermal/broadcom/Makefile  |   1 +
> >  drivers/thermal/broadcom/brcmstb_thermal.c | 386
> > +
> >  8 files changed, 425 insertions(+), 1 deletion(-)
> >  create mode 100644
> > Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt
> >  create mode 100644 drivers/thermal/broadcom/brcmstb_thermal.c
> > 
> 


Re: [PATCH] thermal: core: fix some format issues on critical shutdown string

2017-08-08 Thread Zhang Rui
On Sun, 2017-07-23 at 22:21 +0800, Icenowy Zheng wrote:
> The critical shutdown notice string used to have some spaces missing,
> which makes it not so pretty.
> 
> Add the spaces to satisfy usual English space rules.
> 
> Reported-by: Mingcong Bai 
> Signed-off-by: Icenowy Zheng 

applied.

thanks,
rui
> ---
>  drivers/thermal/thermal_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/thermal_core.c
> b/drivers/thermal/thermal_core.c
> index 5a51c740e372..671e4d15599d 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -390,7 +390,7 @@ static void handle_critical_trips(struct
> thermal_zone_device *tz,
>  
>   if (trip_type == THERMAL_TRIP_CRITICAL) {
>   dev_emerg(>device,
> -   "critical temperature reached(%d
> C),shutting down\n",
> +   "critical temperature reached (%d C),
> shutting down\n",
>     tz->temperature / 1000);
>   mutex_lock(_lock);
>   if (!power_off_triggered) {


Re: [PATCH] thermal: fix INTEL_SOC_DTS_IOSF_CORE dependencies

2017-08-08 Thread Zhang Rui
On Sat, 2017-07-29 at 13:22 -0600, Pandruvada, Srinivas wrote:
> On Fri, 2017-07-21 at 18:16 +0200, Arnd Bergmann wrote:
> > 
> > We get a Kconfig warning when selecting this without also enabling
> > CONFIG_PCI:
> > 
> > warning: (X86_INTEL_LPSS && INTEL_SOC_DTS_IOSF_CORE &&
> > SND_SST_IPC_ACPI && MMC_SDHCI_ACPI && PUNIT_ATOM_DEBUG) selects
> > IOSF_MBI which has unmet direct dependencies (PCI)
> > 
> > This adds a new depedency.
> > 
> > Fixes: 3a2419f865a6 ("Thermal: Intel SoC: DTS thermal use common
> > APIs")
> > Signed-off-by: Arnd Bergmann 
> Reviewed-by: Srinivas Pandruvada  >
> 
> > 
> > ---
> >  drivers/thermal/Kconfig | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> > index b5b5facb8747..ac2a53823576 100644
> > --- a/drivers/thermal/Kconfig
> > +++ b/drivers/thermal/Kconfig
> > @@ -342,7 +342,7 @@ config X86_PKG_TEMP_THERMAL
> >  
> >  config INTEL_SOC_DTS_IOSF_CORE
> >     tristate
> > -   depends on X86
> > +   depends on X86 && PCI
> >     select IOSF_MBI
> >     help
> >       This is becoming a common feature for Intel SoCs to
> > expose
> > the additional
> > @@ -352,7 +352,7 @@ config INTEL_SOC_DTS_IOSF_CORE
> >  
> >  config INTEL_SOC_DTS_THERMAL
> >     tristate "Intel SoCs DTS thermal driver"
> > -   depends on X86
> > +   depends on X86 && PCI
> >     select INTEL_SOC_DTS_IOSF_CORE
> >     select THERMAL_WRITABLE_TRIPS
> >     help


  1   2   3   4   5   6   7   8   >