On Sun, Dec 5, 2021 at 11:50 AM Evgeny Boger <boger@xxxxxxxxxxxxxx> wrote:
> >> Agreed those tables would be needed whatever the solution. We might
> >> stick to 'standard' tables for simple cases but someone will always wire
> >> a circuit up that does something we haven't thought of.
> > What we usually do is model the wiring in the device tree like we (I) have
> > already done with much pain in:
> > Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml
>
> Earlier in this thread I mentioned our use case with AXP221s: we ended
> up wiring 10k NTC in series with 12k fixed resistance.
> The only reason was to work around poorly-designed AXP NTC detection
> "feature", which would turn off protection whenever
> the voltage on TS pin drops below 0.2V.
>
> How would you suggest to handle such a wiring?
Correct me if I'm wrong but it is pretty standard to connect an extra
resistor in series with a thermistor, for example batteries often have
an BTI "Battery Type Indicator" resistor in series with the thermistor.
If you check the NTC bindings:
Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml
they already cover this, in two different ways depending of how
the voltage is measured and if the resistor is in series with the
thermistor to ground or to VCC.
The thermistor table goes in the driver for the 10k resistor
and the 12k resistor is pullup-ohm or pulldown-ohm.
> > battery: battery {
> > compatible = "simple-battery";
> >
> > ntc-resistor {
> > ...
> > };
> > };
> >
> > For the Samsung batteries my plan is to spawn a platform device from inside the
> > Samsung battery driver and add pull-down resistor value and
> > compatible using software nodes from within the kernel.
>
> In this example, the ntc-resistor node will be handled by current NTC
> hwmon driver, right?
Yes
> Frankly, I'm quite confused about hwmon vs iio choice in this case.
> Wouldn't it be better to use iio here, say, by extending iio-afe?
The hwmon driver uses IIO for voltage sampling. It is in the hwmon
driver folder because the driver provides a temperature and for
historical reasons: it was used for hwmon use cases.
It is possible to refactor it to a driver in
drivers/iio/temperature/* if so desired, and make sure all users
are moved over and the Kconfig symbols are resolved to the
new driver. After that it can be used by hwmon using the
iio-to-hwmon bridge driver.
It's just work, someone who want to fix it can step in and submit
the patches and drive the change.
> But you still need to describe the particular NTC model in device tree,
> right?
No. Drivers can spawn devices including fwnode properties that will
work identical to a device spawn from a device tree node.
We can instatiate an NTC as a subdevice of a battery without
the need of sich a NTC node in the device tree, This is the
ambition of the fwnode concept,
Yours,
Linus Walleij
