Message-ID: <57794DB3.2050506@roeck-us.net>
Date:	Sun, 3 Jul 2016 10:38:59 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Lars-Peter Clausen <lars@...afoo.de>,
	Jonathan Cameron <jic23@...nel.org>,
	Quentin Schulz <quentin.schulz@...e-electrons.com>,
	jdelvare@...e.com, knaack.h@....de, pmeerw@...erw.net,
	maxime.ripard@...e-electrons.com, wens@...e.org,
	lee.jones@...aro.org
Cc:	linux-kernel@...r.kernel.org, linux-hwmon@...r.kernel.org,
	linux-iio@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	thomas.petazzoni@...e-electrons.com,
	antoine.tenart@...e-electrons.com
Subject: Re: [PATCH 1/3] mfd: add support for Allwinner SoCs ADC

On 07/03/2016 09:49 AM, Lars-Peter Clausen wrote:
> On 07/03/2016 01:17 PM, Jonathan Cameron wrote:
>> On 28/06/16 09:18, Quentin Schulz wrote:
>>> 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 <quentin.schulz@...e-electrons.com>
>> 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

Powered by blists - more mailing lists