On Sat, 1 May 2021 12:05:15 -0700 Guenter Roeck <linux@xxxxxxxxxxxx> wrote: [...] > > Well, I try to give first some missing context. It is about temperature > > compensation, not cooling vs. overheating protection. EPDs behave > > different at different temperatures, so the driver needs a temperature > > to compensate for it. > > EPDs need also a bit more exotic voltages, so usually there is a > > separate PMIC for them. Usually that PMIC can also deliver a > > temperature. So drivers for that should consist of > > - mfd (obvious) > > I would disagree. The presence of a thermal sensor does not make a chip > a multi-function device. Many Ethernet controllers have thermal sensors > nowadays. That doesn't make them multi-function devices. > well, there is one difference here, the ethernet controllers have probably thermal sensors for monitoring themself. Here is thermal sensor is not intended to monitor the EPD PMIC itself. But yes, it makes life easier if I do not need to have a mfd. > > - regulator (also obvious) > > - something for providing the temperature (and that "something" is not > > that clear to me as there are several subsystems dealing with > > temperature) > > > There are distinct use cases. iio is for industrial io, thermal is for > thermal management, and hwmon is to expose sensor data to userspace > for hardware monitoring. Normally one would pick the (or a) primary > use case and go from there. > > For the tps65185, I could imagine using the thermal sensor for hardware > monitoring, and I can imagine its use for thermal control. I don't really > see a use case as industrial io. > [...] Industrial io would be if the main intention is to measure room temperature. > drivers/mmc/host/sdhci-omap.c seems to do something similar, and doesn't > have trouble using a thermal zone for it. > yes, that is similar. > > Vendor kernels in the wild additionally provide temperature by abusing > > the regulator API which is IMHO not acceptable. > > > > But if that thing would in to the iio subsystem, I would simply be able > > to use iio_channel_get() to get the sensor from the device tree and > > iio_channel_read() to read values from it. There is a iio_hwmon and no > > hwmon_iio, so if someone wants a hwmon interface for it, it would not > > block anything. > > > > The main point about writing this mail now is that I do not want to > > submit a driver, spin some polishing rounds, then somebody says:"Please > > go to subsystem Y, not X" > > > > You seem to be set in going along the mfd/iio path, though, which is fine > with me. It is not me you'll have to convince, after all. > I am not that fixed anymore, you opened my eyes for alternatives. Thanks a lot for your explanations and examples, that really has helped me to understand things better. Regards, Andreas
