Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
* Dave Hansen: > My assumption has always been that these large, potentially sparse > hardware tables *must* be mmap()'d with MAP_NORESERVE specified. That > should keep them from being problematic with respect to overcommit. MAP_NORESERVE pages still count towards the commit limit. The flag only disables checks at allocation time, for this particular allocation. (At least this was the behavior the last time I looked into this, I believe.) Not sure if this makes a difference here. Thanks, Florian
Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
On Mon 2019-06-10 08:47:45, Yu-cheng Yu wrote: > On Sat, 2019-06-08 at 22:52 +0200, Pavel Machek wrote: > > Hi! > > > > > > I've no idea what the kernel should do; since you failed to answer the > > > > question what happens when you point this to garbage. > > > > > > > > Does it then fault or what? > > > > > > Yeah, I think you'll fault with a rather mysterious CR2 value since > > > you'll go look at the instruction that faulted and not see any > > > references to the CR2 value. > > > > > > I think this new MSR probably needs to get included in oops output when > > > CET is enabled. > > > > > > Why don't we require that a VMA be in place for the entire bitmap? > > > Don't we need a "get" prctl function too in case something like a JIT is > > > running and needs to find the location of this bitmap to set bits itself? > > > > > > Or, do we just go whole-hog and have the kernel manage the bitmap > > > itself. Our interface here could be: > > > > > > prctl(PR_MARK_CODE_AS_LEGACY, start, size); > > > > > > and then have the kernel allocate and set the bitmap for those code > > > locations. > > > > For the record, that sounds like a better interface than userspace knowing > > about the bitmap formats... > > Pavel > > Initially we implemented the bitmap that way. To manage the bitmap, every > time > the application issues a syscall for a .so it loads, and the kernel does > copy_from_user() & copy_to_user() (or similar things). If a system has a few > legacy .so files and every application does the same, it can take a long time > to > boot up. Loading .so is already many syscalls, I'd not expect measurable performance there. Are you sure? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
RE: [PATCH V14 1/5] dt-bindings: fsl: scu: add thermal binding
> From: anson.hu...@nxp.com [mailto:anson.hu...@nxp.com] > Sent: Monday, June 10, 2019 10:53 AM > > NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system > controller, the system controller is in charge of system power, clock and > thermal sensors etc. management, Linux kernel has to communicate with > system controller via MU (message unit) IPC to get temperature from thermal > sensors, this patch adds binding doc for i.MX system controller thermal > driver. > > Signed-off-by: Anson Huang > Reviewed-by: Rob Herring Reviewed-by: Dong Aisheng Regards Dong Aisheng
Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file
On Mon, Jun 10, 2019 at 07:24:43PM +0200, Florian Weimer wrote: > * Yu-cheng Yu: > > > To me, looking at PT_GNU_PROPERTY and not trying to support anything is a > > logical choice. And it breaks only a limited set of toolchains. > > > > I will simplify the parser and leave this patch as-is for anyone who wants > > to > > back-port. Are there any objections or concerns? > > Red Hat Enterprise Linux 8 does not use PT_GNU_PROPERTY and is probably > the largest collection of CET-enabled binaries that exists today. For clarity, RHEL is actively parsing these properties today? > My hope was that we would backport the upstream kernel patches for CET, > port the glibc dynamic loader to the new kernel interface, and be ready > to run with CET enabled in principle (except that porting userspace > libraries such as OpenSSL has not really started upstream, so many > processes where CET is particularly desirable will still run without > it). > > I'm not sure if it is a good idea to port the legacy support if it's not > part of the mainline kernel because it comes awfully close to creating > our own private ABI. I guess we can aim to factor things so that PT_NOTE scanning is available as a fallback on arches for which the absence of PT_GNU_PROPERTY is not authoritative. Can we argue that the lack of PT_GNU_PROPERTY is an ABI bug, fix it for new binaries and hence limit the efforts we go to to support theoretical binaries that lack the phdrs entry? If we can make practical simplifications to the parsing, such as limiting the maximum PT_NOTE size that we will search for the program properties to 1K (say), or requiring NT_NOTE_GNU_PROPERTY_TYPE_0 to sit by itself in a single PT_NOTE then that could help minimse the exec overheads and the number of places for bugs to hide in the kernel. What we can do here depends on what the tools currently do and what binaries are out there. Cheers ---Dave
RE: [PATCH V14 2/5] thermal: of-thermal: add API for getting sensor ID from DT
Hi Anson,
The implementation looks good to me.
A few minor comments on the doc:
> From: anson.hu...@nxp.com [mailto:anson.hu...@nxp.com]
> Sent: Monday, June 10, 2019 10:53 AM
>
> On some platforms like i.MX8QXP, the thermal driver needs a real HW sensor
> ID from DT thermal zone, the HW sensor ID is used to get temperature from
> SCU firmware, and the virtual sensor ID starting from 0 to N is NOT used at
> all,
This API is unware of HW ID or Virtual ID. So we probably no need to mention
It here.
> this patch adds new API thermal_zone_of_get_sensor_id() to provide the
> feature of getting sensor ID from DT thermal zone's node.
>
"It's useful for thermal driver to register the specific thermal zone devices
from DT in a common way."
> Signed-off-by: Anson Huang
> ---
> Changes since V13:
> - add new API into the thermal API doc.
> ---
> Documentation/thermal/sysfs-api.txt | 8 +
> drivers/thermal/of-thermal.c| 66
> -
> include/linux/thermal.h | 10 ++
> 3 files changed, 68 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/thermal/sysfs-api.txt
> b/Documentation/thermal/sysfs-api.txt
> index c3fa500..8d7f1b1 100644
> --- a/Documentation/thermal/sysfs-api.txt
> +++ b/Documentation/thermal/sysfs-api.txt
> @@ -159,6 +159,14 @@ temperature) and throttle appropriate devices.
> for the thermal zone device, which might be useful for platform
> drivers for temperature calculations.
>
> +1.1.9 int thermal_zone_of_get_sensor_id(struct device_node *tz_np,
> + struct device_node *sensor_np,
> + u32 *id)
> +
> + This interface is used to get the sensor id from thermal sensor's
> + phandle argument, it might be necessary for some platforms which
> + have specific sensor ID rather than virtual ID from 0 - N.
Does below one look better?
"This interface is used to get the sensor id from the given thermal zone in
DT, which might be useful for thermal drivers to register specific thermal
zone device in a common way."
> +
> 1.2 thermal cooling device interface
> 1.2.1 struct thermal_cooling_device *thermal_cooling_device_register(char
> *name,
> void *devdata, struct thermal_cooling_device_ops *) diff --git
> a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c index
> dc5093b..a53792b 100644
> --- a/drivers/thermal/of-thermal.c
> +++ b/drivers/thermal/of-thermal.c
> @@ -449,6 +449,54 @@ thermal_zone_of_add_sensor(struct device_node
> *zone, }
>
> /**
> + * thermal_zone_of_get_sensor_id - get sensor ID from a DT thermal zone
> + * @tz_np: a valid thermal zone device node.
> + * @sensor_np: a sensor node of a valid sensor device.
> + * @id: a sensor ID pointer will be passed back.
the sensor ID returned if success
> + *
> + * This function will get sensor ID from a given thermal zone node, use
> + * "thermal-sensors" as list name, and get sensor ID from first
> + phandle's
> + * argument.
"This function will get sensor ID from a given thermal zone node and the sensor
get must match the temperature providers @sensor_np."
Regards
Dong Aisheng
> + *
> + * Return: 0 on success, proper error code otherwise.
> + */
> +
> +int thermal_zone_of_get_sensor_id(struct device_node *tz_np,
> + struct device_node *sensor_np,
> + u32 *id)
> +{
> + struct of_phandle_args sensor_specs;
> + int ret;
> +
> + ret = of_parse_phandle_with_args(tz_np,
> + "thermal-sensors",
> + "#thermal-sensor-cells",
> + 0,
> + &sensor_specs);
> + if (ret)
> + return ret;
> +
> + if (sensor_specs.np != sensor_np) {
> + of_node_put(sensor_specs.np);
> + return -ENODEV;
> + }
> +
> + if (sensor_specs.args_count >= 1) {
> + *id = sensor_specs.args[0];
> + WARN(sensor_specs.args_count > 1,
> + "%pOFn: too many cells in sensor specifier %d\n",
> + sensor_specs.np, sensor_specs.args_count);
> + } else {
> + *id = 0;
> + }
> +
> + of_node_put(sensor_specs.np);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(thermal_zone_of_get_sensor_id);
> +
> +/**
> * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
> * @dev: a valid struct device pointer of a sensor device. Must contain
> * a valid .of_node, for the sensor node.
> @@ -499,36 +547,22 @@ thermal_zone_of_sensor_register(struct device *dev,
> int sensor_id, void *data,
> sensor_np = of_node_get(dev->of_node);
>
> for_each_available_child_of_node(np, child) {
> - struct of_phandle_args sensor_specs;
> int ret, id;
>
> /* For now, thermal framework supports only 1 sensor per zone */
> - ret = of_parse_
RE: [PATCH V14 2/5] thermal: of-thermal: add API for getting sensor ID from DT
Hi, Aisheng
> -Original Message-
> From: Aisheng Dong
> Sent: Tuesday, June 11, 2019 7:47 PM
> To: Anson Huang ; robh...@kernel.org;
> mark.rutl...@arm.com; cor...@lwn.net; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> catalin.mari...@arm.com; will.dea...@arm.com; rui.zh...@intel.com;
> edubez...@gmail.com; daniel.lezc...@linaro.org; ulf.hans...@linaro.org;
> Peng Fan ; mchehab+sams...@kernel.org;
> li...@roeck-us.net; Daniel Baluta ;
> maxime.rip...@bootlin.com; o...@lixom.net; ja...@amarulasolutions.com;
> horms+rene...@verge.net.au; Leonard Crestez ;
> bjorn.anders...@linaro.org; dingu...@kernel.org;
> enric.balle...@collabora.com; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-doc@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux...@vger.kernel.org
> Cc: dl-linux-imx
> Subject: RE: [PATCH V14 2/5] thermal: of-thermal: add API for getting sensor
> ID from DT
>
> Hi Anson,
>
> The implementation looks good to me.
> A few minor comments on the doc:
This patch is pending for so long and even till now I am NOT sure if everyone
is OK for
this change, so I will wait for some comments if there is any, and will improve
the doc
together in next version.
Thanks,
Anson
>
> > From: anson.hu...@nxp.com [mailto:anson.hu...@nxp.com]
> > Sent: Monday, June 10, 2019 10:53 AM
> >
> > On some platforms like i.MX8QXP, the thermal driver needs a real HW
> > sensor ID from DT thermal zone, the HW sensor ID is used to get
> > temperature from SCU firmware, and the virtual sensor ID starting from
> > 0 to N is NOT used at all,
>
> This API is unware of HW ID or Virtual ID. So we probably no need to
> mention It here.
>
> > this patch adds new API thermal_zone_of_get_sensor_id() to provide the
> > feature of getting sensor ID from DT thermal zone's node.
> >
>
> "It's useful for thermal driver to register the specific thermal zone devices
> from DT in a common way."
>
> > Signed-off-by: Anson Huang
> > ---
> > Changes since V13:
> > - add new API into the thermal API doc.
> > ---
> > Documentation/thermal/sysfs-api.txt | 8 +
> > drivers/thermal/of-thermal.c| 66
> > -
> > include/linux/thermal.h | 10 ++
> > 3 files changed, 68 insertions(+), 16 deletions(-)
> >
> > diff --git a/Documentation/thermal/sysfs-api.txt
> > b/Documentation/thermal/sysfs-api.txt
> > index c3fa500..8d7f1b1 100644
> > --- a/Documentation/thermal/sysfs-api.txt
> > +++ b/Documentation/thermal/sysfs-api.txt
> > @@ -159,6 +159,14 @@ temperature) and throttle appropriate devices.
> > for the thermal zone device, which might be useful for platform
> > drivers for temperature calculations.
> >
> > +1.1.9 int thermal_zone_of_get_sensor_id(struct device_node *tz_np,
> > + struct device_node *sensor_np,
> > + u32 *id)
> > +
> > + This interface is used to get the sensor id from thermal sensor's
> > + phandle argument, it might be necessary for some platforms which
> > + have specific sensor ID rather than virtual ID from 0 - N.
>
> Does below one look better?
>
> "This interface is used to get the sensor id from the given thermal zone in
> DT,
> which might be useful for thermal drivers to register specific thermal zone
> device in a common way."
>
> > +
> > 1.2 thermal cooling device interface
> > 1.2.1 struct thermal_cooling_device
> > *thermal_cooling_device_register(char
> > *name,
> > void *devdata, struct thermal_cooling_device_ops *) diff --git
> > a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c index
> > dc5093b..a53792b 100644
> > --- a/drivers/thermal/of-thermal.c
> > +++ b/drivers/thermal/of-thermal.c
> > @@ -449,6 +449,54 @@ thermal_zone_of_add_sensor(struct device_node
> > *zone, }
> >
> > /**
> > + * thermal_zone_of_get_sensor_id - get sensor ID from a DT thermal
> > + zone
> > + * @tz_np: a valid thermal zone device node.
> > + * @sensor_np: a sensor node of a valid sensor device.
> > + * @id: a sensor ID pointer will be passed back.
>
> the sensor ID returned if success
>
> > + *
> > + * This function will get sensor ID from a given thermal zone node,
> > + use
> > + * "thermal-sensors" as list name, and get sensor ID from first
> > + phandle's
> > + * argument.
>
> "This function will get sensor ID from a given thermal zone node and the
> sensor get must match the temperature providers @sensor_np."
>
> Regards
> Dong Aisheng
>
> > + *
> > + * Return: 0 on success, proper error code otherwise.
> > + */
> > +
> > +int thermal_zone_of_get_sensor_id(struct device_node *tz_np,
> > + struct device_node *sensor_np,
> > + u32 *id)
> > +{
> > + struct of_phandle_args sensor_specs;
> > + int ret;
> > +
> > + ret = of_parse_phandle_with_args(tz_np,
> > +"thermal-sensors",
> > +"#ther
Re: [PATCH v12 03/13] dt-bindings: Add doc for the Ingenic TCU drivers
On Sat, May 25, 2019 at 1:13 PM Paul Cercueil wrote: > > > > Le ven. 24 mai 2019 à 22:21, Rob Herring a écrit : > > On Tue, May 21, 2019 at 04:51:31PM +0200, Paul Cercueil wrote: > >> Add documentation about how to properly use the Ingenic TCU > >> (Timer/Counter Unit) drivers from devicetree. > >> > >> Signed-off-by: Paul Cercueil > >> --- > >> > >> Notes: > >> v4: New patch in this series. Corresponds to V2 patches 3-4-5 > >> with > >> added content. > >> > >> v5: - Edited PWM/watchdog DT bindings documentation to point to > >> the new > >> document. > >> - Moved main document to > >> Documentation/devicetree/bindings/timer/ingenic,tcu.txt > >> - Updated documentation to reflect the new devicetree bindings. > >> > >> v6: - Removed PWM/watchdog documentation files as asked by > >> upstream > >> - Removed doc about properties that should be implicit > >> - Removed doc about ingenic,timer-channel / > >> ingenic,clocksource-channel as they are gone > >> - Fix WDT clock name in the binding doc > >> - Fix lengths of register areas in watchdog/pwm nodes > >> > >> v7: No change > >> > >> v8: - Fix address of the PWM node > >> - Added doc about system timer and clocksource children nodes > >> > >> v9: - Remove doc about system timer and clocksource children > >> nodes... > >> - Add doc about ingenic,pwm-channels-mask property > >> > >> v10: No change > >> > >> v11: Fix info about default value of ingenic,pwm-channels-mask > >> > >> v12: Drop sub-nodes for now; they will be introduced in a > >> follow-up > >> patchset. > > > > Why? I believe I acked them. > > The patchset was too big, and I've already been trying to get it > upstream for > more than one year now. So I cut it in half in hope that it'll be > easier to > upstream it that way. You can drop the driver part and keep the binding. Unlike drivers, we don't want bindings to needlessly evolve, and you don't have to wait til a driver implements some functionality to add that to the binding. Rob
Re: [PATCH v7 25/27] mm/mmap: Add Shadow stack pages to memory accounting
On 6/6/19 1:06 PM, Yu-cheng Yu wrote: > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -1703,6 +1703,9 @@ static inline int accountable_mapping(struct file > *file, vm_flags_t vm_flags) > if (file && is_file_hugepages(file)) > return 0; > > + if (arch_copy_pte_mapping(vm_flags)) > + return 1; > + > return (vm_flags & (VM_NORESERVE | VM_SHARED | VM_WRITE)) == VM_WRITE; > } > > @@ -3319,6 +3322,8 @@ void vm_stat_account(struct mm_struct *mm, vm_flags_t > flags, long npages) > mm->stack_vm += npages; > else if (is_data_mapping(flags)) > mm->data_vm += npages; > + else if (arch_copy_pte_mapping(flags)) > + mm->data_vm += npages; > } This classifies shadow stack as data instead of stack. That seems a wee bit counterintuitive. Why did you make this choice?
Re: [PATCH v7 25/27] mm/mmap: Add Shadow stack pages to memory accounting
On Tue, 2019-06-11 at 10:55 -0700, Dave Hansen wrote: > On 6/6/19 1:06 PM, Yu-cheng Yu wrote: > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -1703,6 +1703,9 @@ static inline int accountable_mapping(struct file > > *file, vm_flags_t vm_flags) > > if (file && is_file_hugepages(file)) > > return 0; > > > > + if (arch_copy_pte_mapping(vm_flags)) > > + return 1; > > + > > return (vm_flags & (VM_NORESERVE | VM_SHARED | VM_WRITE)) == > > VM_WRITE; > > } > > > > @@ -3319,6 +3322,8 @@ void vm_stat_account(struct mm_struct *mm, vm_flags_t > > flags, long npages) > > mm->stack_vm += npages; > > else if (is_data_mapping(flags)) > > mm->data_vm += npages; > > + else if (arch_copy_pte_mapping(flags)) > > + mm->data_vm += npages; > > } > > This classifies shadow stack as data instead of stack. That seems a wee > bit counterintuitive. Why did you make this choice? I don't recall the reason; I will change it to stack and test it out. Yu-cheng
Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file
On Tue, 2019-06-11 at 12:41 +0100, Dave Martin wrote: > On Mon, Jun 10, 2019 at 07:24:43PM +0200, Florian Weimer wrote: > > * Yu-cheng Yu: > > > > > To me, looking at PT_GNU_PROPERTY and not trying to support anything is a > > > logical choice. And it breaks only a limited set of toolchains. > > > > > > I will simplify the parser and leave this patch as-is for anyone who wants > > > to > > > back-port. Are there any objections or concerns? > > > > Red Hat Enterprise Linux 8 does not use PT_GNU_PROPERTY and is probably > > the largest collection of CET-enabled binaries that exists today. > > For clarity, RHEL is actively parsing these properties today? > > > My hope was that we would backport the upstream kernel patches for CET, > > port the glibc dynamic loader to the new kernel interface, and be ready > > to run with CET enabled in principle (except that porting userspace > > libraries such as OpenSSL has not really started upstream, so many > > processes where CET is particularly desirable will still run without > > it). > > > > I'm not sure if it is a good idea to port the legacy support if it's not > > part of the mainline kernel because it comes awfully close to creating > > our own private ABI. > > I guess we can aim to factor things so that PT_NOTE scanning is > available as a fallback on arches for which the absence of > PT_GNU_PROPERTY is not authoritative. We can probably check PT_GNU_PROPERTY first, and fallback (based on ld-linux version?) to PT_NOTE scanning? Yu-cheng
[PATCH] sphinx.rst: Add note about code snippets embedded in the text
There's a paragraph that explains how to create fixed width text block, but it doesn't explains how to create fixed width text inline, although this feature is really used through the documentation. Fix that adding a quick note about it. Signed-off-by: André Almeida --- Documentation/doc-guide/sphinx.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/doc-guide/sphinx.rst b/Documentation/doc-guide/sphinx.rst index c039224b404e..f48abc07f4c5 100644 --- a/Documentation/doc-guide/sphinx.rst +++ b/Documentation/doc-guide/sphinx.rst @@ -218,7 +218,7 @@ Here are some specific guidelines for the kernel documentation: examples, etc.), use ``::`` for anything that doesn't really benefit from syntax highlighting, especially short snippets. Use ``.. code-block:: `` for longer code blocks that benefit - from highlighting. + from highlighting. For a short snippet of code embedded in the text, use \`\`. the C domain -- 2.22.0
RE: [PATCH V14 2/5] thermal: of-thermal: add API for getting sensor ID from DT
Hi Eduardo & Rui,
> From: Anson Huang
> Sent: Tuesday, June 11, 2019 8:37 PM
>
> > From: Aisheng Dong
> > Sent: Tuesday, June 11, 2019 7:47 PM
> > Subject: RE: [PATCH V14 2/5] thermal: of-thermal: add API for getting
> > sensor ID from DT
> >
> > Hi Anson,
> >
> > The implementation looks good to me.
> > A few minor comments on the doc:
>
> This patch is pending for so long and even till now I am NOT sure if everyone
> is
> OK for this change, so I will wait for some comments if there is any, and will
> improve the doc together in next version.
>
The API change seems good to me.
But since this is a core changes, we need your inputs to confirm whether this
approach
is ok to you.
So please tell us whether you're fine with this approach.
Regards
Dong Aisheng
> Thanks,
> Anson
>
> >
> > > From: anson.hu...@nxp.com [mailto:anson.hu...@nxp.com]
> > > Sent: Monday, June 10, 2019 10:53 AM
> > >
> > > On some platforms like i.MX8QXP, the thermal driver needs a real HW
> > > sensor ID from DT thermal zone, the HW sensor ID is used to get
> > > temperature from SCU firmware, and the virtual sensor ID starting
> > > from
> > > 0 to N is NOT used at all,
> >
> > This API is unware of HW ID or Virtual ID. So we probably no need to
> > mention It here.
> >
> > > this patch adds new API thermal_zone_of_get_sensor_id() to provide
> > > the feature of getting sensor ID from DT thermal zone's node.
> > >
> >
> > "It's useful for thermal driver to register the specific thermal zone
> > devices from DT in a common way."
> >
> > > Signed-off-by: Anson Huang
> > > ---
> > > Changes since V13:
> > > - add new API into the thermal API doc.
> > > ---
> > > Documentation/thermal/sysfs-api.txt | 8 +
> > > drivers/thermal/of-thermal.c| 66
> > > -
> > > include/linux/thermal.h | 10 ++
> > > 3 files changed, 68 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/Documentation/thermal/sysfs-api.txt
> > > b/Documentation/thermal/sysfs-api.txt
> > > index c3fa500..8d7f1b1 100644
> > > --- a/Documentation/thermal/sysfs-api.txt
> > > +++ b/Documentation/thermal/sysfs-api.txt
> > > @@ -159,6 +159,14 @@ temperature) and throttle appropriate devices.
> > > for the thermal zone device, which might be useful for platform
> > > drivers for temperature calculations.
> > >
> > > +1.1.9 int thermal_zone_of_get_sensor_id(struct device_node *tz_np,
> > > + struct device_node *sensor_np,
> > > + u32 *id)
> > > +
> > > + This interface is used to get the sensor id from thermal sensor's
> > > + phandle argument, it might be necessary for some platforms which
> > > + have specific sensor ID rather than virtual ID from 0 - N.
> >
> > Does below one look better?
> >
> > "This interface is used to get the sensor id from the given thermal
> > zone in DT, which might be useful for thermal drivers to register
> > specific thermal zone device in a common way."
> >
> > > +
> > > 1.2 thermal cooling device interface
> > > 1.2.1 struct thermal_cooling_device
> > > *thermal_cooling_device_register(char
> > > *name,
> > > void *devdata, struct thermal_cooling_device_ops *) diff --git
> > > a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c index
> > > dc5093b..a53792b 100644
> > > --- a/drivers/thermal/of-thermal.c
> > > +++ b/drivers/thermal/of-thermal.c
> > > @@ -449,6 +449,54 @@ thermal_zone_of_add_sensor(struct device_node
> > > *zone, }
> > >
> > > /**
> > > + * thermal_zone_of_get_sensor_id - get sensor ID from a DT thermal
> > > + zone
> > > + * @tz_np: a valid thermal zone device node.
> > > + * @sensor_np: a sensor node of a valid sensor device.
> > > + * @id: a sensor ID pointer will be passed back.
> >
> > the sensor ID returned if success
> >
> > > + *
> > > + * This function will get sensor ID from a given thermal zone node,
> > > + use
> > > + * "thermal-sensors" as list name, and get sensor ID from first
> > > + phandle's
> > > + * argument.
> >
> > "This function will get sensor ID from a given thermal zone node and
> > the sensor get must match the temperature providers @sensor_np."
> >
> > Regards
> > Dong Aisheng
> >
> > > + *
> > > + * Return: 0 on success, proper error code otherwise.
> > > + */
> > > +
> > > +int thermal_zone_of_get_sensor_id(struct device_node *tz_np,
> > > + struct device_node *sensor_np,
> > > + u32 *id)
> > > +{
> > > + struct of_phandle_args sensor_specs;
> > > + int ret;
> > > +
> > > + ret = of_parse_phandle_with_args(tz_np,
> > > + "thermal-sensors",
> > > + "#thermal-sensor-cells",
> > > + 0,
> > > + &sensor_specs);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + if (sensor_specs.np != sensor_np) {
> > > + of_node_put(sensor_specs.np);
> > > + return -ENODEV;
> > > + }
> > > +
> > >
