On 07/03/2016 09:49 AM, Lars-Peter Clausen wrote:

On 07/03/2016 01:17 PM, Jonathan Cameron wrote:

quoted

On 28/06/16 09:18, Quentin Schulz wrote:

quoted

The Allwinner SoCs all have an ADC that can also act as a touchscreen
controller and a thermal sensor. For now, only the ADC and the thermal
sensor drivers are probed by the MFD, the touchscreen controller support
will be added later.

Signed-off-by: Quentin Schulz <redacted>

The code looks fine to me. The 'controversial' bit of this is listing
iio-hwmon as an mfd child to get it to probe as a result of this being
present.  My immediately thought is that it should be separately
described in the devicetree and hence instantiated outside of this driver.

The devicetree is a generic description of the hardware. The iio-hwmon
bridge is a software component that translates between two Linux specific
ABIs. In my opinion putting the later in the former is makes no sense, it is
simply not part of the hardware description.

Actually, this is where people get it wrong.

Its quite terrible that we have the bindings in the first place, but I guess
we have to keep them considering they are ABI and there are existing users.
But we should definitely strongly discourage the introduction of new users.

I do agree that the _bindings_ are bad.

The ultimate problem is to find bindings which do describe the hardware
in a way that would be acceptable to the devicetree community and is at the
same time useful for software when trying to determine what to do with that
hardware. _This_ is the exceptionally hard problem.

One example would be an adc channel connected to a board voltage. I would assume
that it should be permissible to describe this relationship in a way that can
be _used_ by software to expose that adc channel as voltage, by whatever
means necessary (it be through hwmon or as a regulator or whatever).

Similar, some pin on a chip may be connected to a thermal sensor. I would
assume that it should be permissible to describe that thermal sensor (and its
location) in a way that can be _used_ by software in a meaningful way, either
for it to be reported as hardware monitoring attribute or to be used by the
thermal subsystem as a thermal input channel.

In addition to that, there are various other properties which _do_ describe
the hardware, but are commonly seen as "software". Examples for that would
be voltage or temperature limits (or any other limits, for that matter).
Such limits _are_ part of the hardware description, but are not commonly
accepted as such.

It is policy whether an application wants to access a device using the IIO
or hwmon API. As such it must be managed by userspace, this is not something
that can be done using devicetree nor should it be something that is done on
a driver by driver basis.

Agreed. However, the connections from one chip to another, and the use of a chip
on a board, _is_ part of the hardware description. It is determined by the
schematics as well as the board layout. A well defined hardware description
needs to provide more than "this is an ADC channel" or "this is a thermal sensor".

Guenter