Re: [PATCH v3 0/3] thermal: introduce by-name softlink

[Sandeep Patil]

Hi Wei,

(resending because I accidentally replied only to you. Also adding everyone
else back in the thread, not sure what happened before).

On Wed, Dec 11, 2019 at 02:19:03PM -0800, Wei Wang wrote:
> On Wed, Dec 11, 2019 at 1:11 PM Daniel Lezcano
> <daniel.lezcano@xxxxxxxxxx> wrote:
> >
> > On 11/12/2019 21:11, Wei Wang wrote:
> > > On Wed, Dec 11, 2019 at 12:54 AM Greg Kroah-Hartman
> > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > >>
> > >> On Tue, Dec 10, 2019 at 09:54:11PM +0100, Daniel Lezcano wrote:
> > >>> On 10/12/2019 21:01, Wei Wang wrote:
> > >>>> On Tue, Dec 10, 2019 at 6:36 AM Daniel Lezcano
> > >>>> <daniel.lezcano@xxxxxxxxxx> wrote:
> > >>>>>
> > >>>>> On 05/12/2019 08:19, Wei Wang wrote:
> > >>>>>> The paths thermal_zone%d and cooling_device%d are not intuitive and the
> > >>>>>> numbers are subject to change due to device tree change. This usually
> > >>>>>> leads to tree traversal in userspace code.
> > >>
> > >> tree traversal is supposed to be done in userspace code :)
> > >>
> > > Yes, that can be done in userspace, but given the amount of thermal
> > > zones we have in some mobile devices, this will bring a lot of
> > > convenience.
> >
> > But usually all these thermal zones are fixed and building the name<->tz
> > association is just a question of a few lines of code from userspace,
> > no? What would be the benefit of adding more ABI?
> 
> 
> code reuse as tz mapping is per device tree setup and we try to use
> the same _type_  in thermal zone in shared client code for Android
> thermal API.

CMIIW, but the tz mapping today can still be done by parsing through the
directory the other way? (i.e. tz->type) instead of type->tz?

Also, I understand the resistance to add a new ABI since it will have to be
kept around forever. What would be worth knowing is if these mappings are
static (built once) or you have to go through and parse the directories every
time? AFAIU, the parsing (map creation) seems to only happen once during
boot, so we (Android) should be ok?

> 
> >
> > If there is a thermal zone change, then a notification can be used, so
> > the userspace code rebuild the name<->tz, no?
> 
> 
> Assuming you meant for type<->tz, this mapping won't change in runtime
> in our case (not unloading things), but it could be changed due to
> device tree change, e.g. adding/removing thermal zones.

I actually think we might need this after all. This assumes all tz devices
are registered when userspace (thermal hal/daemon) is coming up. However,
that may soon not be the case and we have to adjust for devices being added
in parallel with userspace?

So, may be we need to start monitoring uevents like we do for power supplies
too? In that case, the mapping can also be done dynamically.

Lastly, I think we can make a case further if there are benefits we can share
here other than convenience. Like startup time, handing hardware variations
etc? (Also point to the current userspace code that uses this)

- ssp
> 
> 
> >
> > > e.g. this is on Pixel 4 XL:
> > > coral:/ # ls  /sys/devices/virtual/thermal/
> > > cdev-by-name      cooling_device15  cooling_device22  cooling_device3
> > >  cooling_device9  thermal_zone15  thermal_zone22  thermal_zone3
> > > thermal_zone37  thermal_zone44  thermal_zone51  thermal_zone59
> > > thermal_zone66  thermal_zone73  thermal_zone80  thermal_zone88
> > > cooling_device0   cooling_device16  cooling_device23  cooling_device30
> > >  thermal_zone0    thermal_zone16  thermal_zone23  thermal_zone30
> > > thermal_zone38  thermal_zone45  thermal_zone52  thermal_zone6
> > > thermal_zone67  thermal_zone74  thermal_zone81  thermal_zone9
> > > cooling_device1   cooling_device17  cooling_device24  cooling_device31
> > >  thermal_zone1    thermal_zone17  thermal_zone24  thermal_zone31
> > > thermal_zone39  thermal_zone46  thermal_zone53  thermal_zone60
> > > thermal_zone68  thermal_zone75  thermal_zone82  tz-by-name
> > > cooling_device10  cooling_device18  cooling_device25  cooling_device4
> > >  thermal_zone10   thermal_zone18  thermal_zone25  thermal_zone32
> > > thermal_zone4   thermal_zone47  thermal_zone54  thermal_zone61
> > > thermal_zone69  thermal_zone76  thermal_zone83
> > > cooling_device11  cooling_device19  cooling_device26  cooling_device5
> > >  thermal_zone11   thermal_zone19  thermal_zone26  thermal_zone33
> > > thermal_zone40  thermal_zone48  thermal_zone55  thermal_zone62
> > > thermal_zone7   thermal_zone77  thermal_zone84
> > > cooling_device12  cooling_device2   cooling_device27  cooling_device6
> > >  thermal_zone12   thermal_zone2   thermal_zone27  thermal_zone34
> > > thermal_zone41  thermal_zone49  thermal_zone56  thermal_zone63
> > > thermal_zone70  thermal_zone78  thermal_zone85
> > > cooling_device13  cooling_device20  cooling_device28  cooling_device7
> > >  thermal_zone13   thermal_zone20  thermal_zone28  thermal_zone35
> > > thermal_zone42  thermal_zone5   thermal_zone57  thermal_zone64
> > > thermal_zone71  thermal_zone79  thermal_zone86
> > > cooling_device14  cooling_device21  cooling_device29  cooling_device8
> > >  thermal_zone14   thermal_zone21  thermal_zone29  thermal_zone36
> > > thermal_zone43  thermal_zone50  thermal_zone58  thermal_zone65
> > > thermal_zone72  thermal_zone8   thermal_zone87
> > >
> > >
> > >> But what userspace code needs to do this, and for what?
> > > In Android, thermal daemon and thermal HAL as well as some init.rc
> > > script would use those thermal paths for managing and monitoring
> > > thermal. The daemon/HAL could have logic pipled in, however Android's
> > > init.rc script would be really tricky.
> > > On a related note, we also create /dev/block/by-name links from userspace.
> > >
> > > Thanks!
> > > -Wei
> > >>
> > >> thanks,
> > >>
> > >> greg k-h
> >
> >
> > --
> >  <http://www.linaro.org/> Linaro.org â Open source software for ARM SoCs
> >
> > Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> > <http://twitter.com/#!/linaroorg> Twitter |
> > <http://www.linaro.org/linaro-blog/> Blog
> >