lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DB5PR0401MB221381AD65417D17AAD7B16DF3F60@DB5PR0401MB2213.eurprd04.prod.outlook.com>
Date:   Wed, 24 Oct 2018 02:48:53 +0000
From:   Andy Tang <andy.tang@....com>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>,
        "rui.zhang@...el.com" <rui.zhang@...el.com>
CC:     "edubezval@...il.com" <edubezval@...il.com>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>
Subject: RE: [PATCH] thermal: qoriq: add multiple sensors support

Hi Daniel,

> -----Original Message-----
> From: Daniel Lezcano <daniel.lezcano@...aro.org>
> Sent: 2018年10月16日 19:21
> To: Andy Tang <andy.tang@....com>; rui.zhang@...el.com
> Cc: edubezval@...il.com; linux-pm@...r.kernel.org;
> linux-kernel@...r.kernel.org; Rob Herring <robh+dt@...nel.org>
> Subject: Re: [PATCH] thermal: qoriq: add multiple sensors support
> 
> >>>> The current code is reading the DT in order to get the sensor id
> >>>> and initialize it. IOW, the DT gives the sensors to use.
> >>>>
> >>>> IMO, it would be more self contained if the driver initializes all
> >>>> the sensors without taking care of the DT and let the of- code to
> >>>> do the binding when the thermal zone, no ?
> >>> [Andy] could you please explain more about this way? I am not sure
> >>> how
> >> to implement it.
> >>> But one thing is for sure: we must get the sensor IDs explicitly so
> >>> that we can enable them by the following command:
> tmu_write(qdata,
> >>> sites | TMR_ME | TMR_ALPF, &qdata->regs->tmr);
> >>
> >> What I meant is about code separation between the driver itself and
> >> the of-thermal code.
> >>
> >> The code above re-inspect the DT to find out the sensor ids in order
> >> to enable them and somehow this is not wrong but breaks the self
> >> encapsulation of the driver. I was suggesting if it isn't possible to
> >> enable all the sensors without taking care of digging into the DT.
> >
> > [Andy] I don't want to re-parse the DT here too. But I have to.
> > This driver will be used by all our SOCs with different sensor IDs and
> number.
> > For example: there are 2 sensors on ls1088a platform with ID 0 and 1.
> > While on ls1043a there are 6 sensors with ID 0, 1, 2, 3, 4, 5.
> > If we don't scan the DT we would not know how many sensors it is and
> > what are the sensor's IDs, unless we hardcode it in driver.
> 
> Yes, you are not the only one in this situation IMO and the drivers
> supporting multiple sensors are increasing, so this will repeat again and
> again.
> 
> That could be hardcoded in the driver by using the compatible string but it
> will be nicer if we can fix that in the DT.
> 
> [Cc'ing Rob]
> 
> What is missing is a description of the sensors id in the temperature
> device node. We have the <thermal-sensor-cells> with 0 or 1 telling if
> there is one or several sensors but we can't specify which sensor ids we
> have. The only alternative is to parse the thermal zones to found out which
> sensors are in use and use them to initialize the driver, an approach which
> breaks the self-encapsulation: the of-thermal framework is the one in
> charge of doing the link between the thermal zone and a sensor id.
> 
> Is it acceptable to add the list of the sensors id in the temp device node, so
> the driver can initialize these sensors without parsing the thermal zone in
> the DT ?
> 
Have you got any conclusion yet?
When can I send the next version of this patch?

BR,
Andy
> 
> 
> 
> --
> 
> <https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> www.linaro.org%2F&amp;data=02%7C01%7Candy.tang%40nxp.com%7Cf6
> 343bd28e0643833fa108d6335973ca%7C686ea1d3bc2b4c6fa92cd99c5c
> 301635%7C0%7C0%7C636752856644006568&amp;sdata=OKIXYjHb4Pvc
> 8lmevq%2FwJe9sosvNRFxhvPAb8TT3FWQ%3D&amp;reserved=0>
> Linaro.org │ Open source software for ARM SoCs
> 
> Follow Linaro:
> <https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> www.facebook.com%2Fpages%2FLinaro&amp;data=02%7C01%7Candy.tan
> g%40nxp.com%7Cf6343bd28e0643833fa108d6335973ca%7C686ea1d3b
> c2b4c6fa92cd99c5c301635%7C0%7C0%7C636752856644006568&amp;s
> data=LQ3T5kpXFrqRrQR1Jt9OjY547TWsfxaIU1z8tK%2F6x8Y%3D&amp;res
> erved=0> Facebook |
> <https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ft
> witter.com%2F%23!%2Flinaroorg&amp;data=02%7C01%7Candy.tang%40n
> xp.com%7Cf6343bd28e0643833fa108d6335973ca%7C686ea1d3bc2b4c6
> fa92cd99c5c301635%7C0%7C0%7C636752856644006568&amp;sdata=h
> MOS1WxQBcS%2Bvxyjwz68nkZFaB%2FeZ21E33U50GdF9pY%3D&amp;res
> erved=0> Twitter |
> <https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> www.linaro.org%2Flinaro-blog%2F&amp;data=02%7C01%7Candy.tang%40
> nxp.com%7Cf6343bd28e0643833fa108d6335973ca%7C686ea1d3bc2b4c
> 6fa92cd99c5c301635%7C0%7C0%7C636752856644162836&amp;sdata=
> 2j0bJLJgzXsmlrG8hR6aKSYvmg3RriaH%2Bzt1x4OF8kU%3D&amp;reserved=
> 0> Blog

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ