From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Jonathan Cameron <jic23@kernel.org>, <linux-iio@vger.kernel.org>,
"Navin Sankar Velliangiri" <navin@linumiz.com>,
Paresh Chaudhary <paresh.chaudhary@rockwellcollins.com>
Subject: Re: [PATCH 1/4] iio: ABI: temperature: Unify documentation for thermocouple fault detection.
Date: Tue, 28 Jun 2022 07:44:09 +0100 [thread overview]
Message-ID: <20220628074409.42f0ecae@sal.lan> (raw)
In-Reply-To: <20220627151812.000069d2@Huawei.com>
Em Mon, 27 Jun 2022 15:18:12 +0100
Jonathan Cameron <Jonathan.Cameron@Huawei.com> escreveu:
> On Sun, 26 Jun 2022 23:33:31 +0100
> Mauro Carvalho Chehab <mchehab@kernel.org> wrote:
>
> > Em Sun, 26 Jun 2022 17:55:08 +0100
> > Jonathan Cameron <jic23@kernel.org> escreveu:
> >
> > > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > >
> > > The kernel build docs do not support having multiple definitions for
> > > the same sysfs filename.
> >
> > Actually, this is not a matter of the docs build system not supporting.
> > It is, instead, how the ABI were supposed to work: a given ABI symbol
> > should have consistent behavior on all drivers that use it. Failing to
> > do that is asking for troubles.
> >
> > So, having duplicated symbols either mean that:
> >
> > a) both have the same meaning. They can/should be unified in order to
> > remove redundant documentation;
> >
> > b) the same ABI symbol have different meanings depending on the driver(s)
> > that use it. This makes very hard for userspace, as it is harder to
> > write a program using it, as the behavior/meaning starts to be
> > driver-dependent.
>
> I think we'll disagree on this.
>
> There are circumstances where a particular ABI in a particular driver
> benefits from additional documentation that would be in the 'impdef
> category' for the generic ABI.
If a particular driver needs something different, either:
1. the ABI definition was loose or too tight, not being generic enough to
cover other hardware needing ABI for the same feature;
2. a different ABI symbol would need, as the two symbols with the same
name are mapping completely different ABIs.
> For this particular case it extends the info available from 'wire
> disconnected' in the generic case, to 'which possible wires are
> disconnected' in the specific case.
In the specific case of device faults, it could be mapped in a way
that would be generic enough, yet providing hardware-specific information,
when the hardware supports it.
In this specific case, I would probably create a generic ABI (or ABI set)
to report hardware issues in a way that it would be more generic.
One possibility for this case would be to use something like this:
$ cat /sys/bus/iio/devices/iio:deviceX/fault
no faults
On hardware that can't pinpoint what wire(s) the problem is occurring:
$ cat /sys/bus/iio/devices/iio:deviceX/fault
fault: open circuit
or
$ cat /sys/bus/iio/devices/iio:deviceX/fault
fault: excessive voltage
On more sophisticated hardware that can pinpoint what wires have
issues, it may report, instead:
$ cat /sys/bus/iio/devices/iio:deviceX/fault
fault: open circuit fault at thermocouple wire #2
or
$ cat /sys/bus/iio/devices/iio:deviceX/fault
fault: excessive voltage at thermocouple wires #0 and #1
or even:
$ cat /sys/bus/iio/devices/iio:deviceX/fault
fault: open circuit fault at thermocouple wire #2
fault: excessive voltage at thermocouple wires #0 and #1
The above should be generic enough for a program to identify if there
isn't any failures if such "fault" ABI would return "no faults". Any value
different than that means that there's a fault, and the read value
telling what happened could be output to the user before such program
aborts due to a hardware error.
-
The point is that, when the ABI is made to be subsystem-wide since
the beginning, it tends to be more generic, as the ABI design should
consider that other devices may have different capabilities.
> Neither affects what userspace
> does with it, but they are useful if you are debugging the hardware.
> They are probably not worth expanding the ABI to provide a debugging
> guide, so it that info was in the documentation but is now lost
> (in this case, non critical as it's probably a case of go read the
> datasheet if the hanging wire isn't obvious).
>
> I don't mind just making this patch description vague:
>
> Kernel documentation for a given ABI element should not be duplicated
> in multiple files, so pull them into one higher level documentation file.
Works for me. With that, feel free to add my reviewed-by.
Regards,
Mauro
> > > Hence generalize the documentation a little
> > > and pull it out of device specific files and into
> > > sysfs-bus-iio-thermocouple
> > >
> > > These may well be more general and need pulling into a more generic
> > > file in the future, but we can do that when it is needed.
> > >
> > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > Cc: Navin Sankar Velliangiri <navin@linumiz.com>
> > > Cc: Paresh Chaudhary <paresh.chaudhary@rockwellcollins.com>
> >
> > Except for the above correction, the patch looks OK to me.
> >
> > Reviewed-by: Mauro Carvalho Chehab <mchehab@kernel.org>
> >
> > > ---
> > > .../sysfs-bus-iio-temperature-max31856 | 31 -------------------
> > > .../sysfs-bus-iio-temperature-max31865 | 12 -------
> > > .../ABI/testing/sysfs-bus-iio-thermocouple | 18 +++++++++++
> > > 3 files changed, 18 insertions(+), 43 deletions(-)
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31856 b/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31856
> > > deleted file mode 100644
> > > index e5ef6d8e5da1..000000000000
> > > --- a/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31856
> > > +++ /dev/null
> > > @@ -1,31 +0,0 @@
> > > -What: /sys/bus/iio/devices/iio:deviceX/fault_oc
> > > -KernelVersion: 5.1
> > > -Contact: linux-iio@vger.kernel.org
> > > -Description:
> > > - Open-circuit fault. The detection of open-circuit faults,
> > > - such as those caused by broken thermocouple wires.
> > > - Reading returns either '1' or '0'.
> > > -
> > > - === =======================================================
> > > - '1' An open circuit such as broken thermocouple wires
> > > - has been detected.
> > > - '0' No open circuit or broken thermocouple wires are detected
> > > - === =======================================================
> > > -
> > > -What: /sys/bus/iio/devices/iio:deviceX/fault_ovuv
> > > -KernelVersion: 5.1
> > > -Contact: linux-iio@vger.kernel.org
> > > -Description:
> > > - Overvoltage or Undervoltage Input Fault. The internal circuitry
> > > - is protected from excessive voltages applied to the thermocouple
> > > - cables by integrated MOSFETs at the T+ and T- inputs, and the
> > > - BIAS output. These MOSFETs turn off when the input voltage is
> > > - negative or greater than VDD.
> > > -
> > > - Reading returns either '1' or '0'.
> > > -
> > > - === =======================================================
> > > - '1' The input voltage is negative or greater than VDD.
> > > - '0' The input voltage is positive and less than VDD (normal
> > > - state).
> > > - === =======================================================
> > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31865 b/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31865
> > > index 4b072da92218..349089e4f2d6 100644
> > > --- a/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31865
> > > +++ b/Documentation/ABI/testing/sysfs-bus-iio-temperature-max31865
> > > @@ -1,15 +1,3 @@
> > > -What: /sys/bus/iio/devices/iio:deviceX/fault_ovuv
> > > -KernelVersion: 5.11
> > > -Contact: linux-iio@vger.kernel.org
> > > -Description:
> > > - Overvoltage or Undervoltage Input fault. The internal circuitry
> > > - is protected from excessive voltages applied to the thermocouple
> > > - cables at FORCE+, FORCE2, RTDIN+ & RTDIN-. This circuitry turn
> > > - off when the input voltage is negative or greater than VDD.
> > > -
> > > - Reading returns '1' if input voltage is negative or greater
> > > - than VDD, otherwise '0'.
> > > -
> > > What: /sys/bus/iio/devices/iio:deviceX/in_filter_notch_center_frequency
> > > KernelVersion: 5.11
> > > Contact: linux-iio@vger.kernel.org
> > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio-thermocouple b/Documentation/ABI/testing/sysfs-bus-iio-thermocouple
> > > new file mode 100644
> > > index 000000000000..01259df297ca
> > > --- /dev/null
> > > +++ b/Documentation/ABI/testing/sysfs-bus-iio-thermocouple
> > > @@ -0,0 +1,18 @@
> > > +What: /sys/bus/iio/devices/iio:deviceX/fault_ovuv
> > > +KernelVersion: 5.1
> > > +Contact: linux-iio@vger.kernel.org
> > > +Description:
> > > + Overvoltage or Undervoltage Input Fault. The internal circuitry
> > > + is protected from excessive voltages applied to the thermocouple
> > > + cables. The device can also detect if such a condition occurs.
> > > +
> > > + Reading returns '1' if input voltage is negative or greater
> > > + than VDD, otherwise '0'.
> > > +
> > > +What: /sys/bus/iio/devices/iio:deviceX/fault_oc
> > > +KernelVersion: 5.1
> > > +Contact: linux-iio@vger.kernel.org
> > > +Description:
> > > + Open-circuit fault. The detection of open-circuit faults,
> > > + such as those caused by broken thermocouple wires.
> > > + Reading returns '1' if fault, '0' otherwise.
>
next prev parent reply other threads:[~2022-06-28 6:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-26 16:55 [PATCH 0/4] IIO: Some documentation error and warning fixes Jonathan Cameron
2022-06-26 16:55 ` [PATCH 1/4] iio: ABI: temperature: Unify documentation for thermocouple fault detection Jonathan Cameron
2022-06-26 22:33 ` Mauro Carvalho Chehab
2022-06-27 14:18 ` Jonathan Cameron
2022-06-28 6:44 ` Mauro Carvalho Chehab [this message]
2022-07-18 17:36 ` Jonathan Cameron
2022-06-26 16:55 ` [PATCH 2/4] iio: ABI: max31865: Drop in_filter_notch_centre_frequency as in main docs Jonathan Cameron
2022-06-26 22:35 ` Mauro Carvalho Chehab
2022-06-26 16:55 ` [PATCH 3/4] iio: ABI: stm32-timer-trigger: Fuse unusual ABI into main doc Jonathan Cameron
2022-06-26 22:37 ` Mauro Carvalho Chehab
2022-06-27 14:09 ` Jonathan Cameron
2022-06-28 5:51 ` Mauro Carvalho Chehab
2022-07-18 17:39 ` Jonathan Cameron
2022-06-26 16:55 ` [PATCH 4/4] iio: ABI: sx9324: Squash some formatting to keep scripting happy Jonathan Cameron
2022-06-26 22:44 ` Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220628074409.42f0ecae@sal.lan \
--to=mchehab@kernel.org \
--cc=Jonathan.Cameron@Huawei.com \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=navin@linumiz.com \
--cc=paresh.chaudhary@rockwellcollins.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox