All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee@kernel.org>
To: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Cc: Pavel Machek <pavel@kernel.org>,
	linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org,
	Mark Brown <broonie@kernel.org>,
	linux-spi@vger.kernel.org
Subject: Re: [PATCH v2 1/2] led: lp5860: expose fault state via sysfs
Date: Thu, 19 Mar 2026 17:34:14 +0000	[thread overview]
Message-ID: <20260319173414.GA2902881@google.com> (raw)
In-Reply-To: <20260311-v6-19-topic-ti-lp5860-fault-v2-1-f9454910f009@pengutronix.de>

On Wed, 11 Mar 2026, Steffen Trumtrar wrote:

> Return the fault state to the userspase via sysfs and allow to reset it.

"userspace" is misspelled here and in the subject line.

> 
> The LP5860 has a global fault state, that just indicates that a short or
> open fault was detected on any LED. This is exposed via 'fault_state'.
> 
> The 'fault_state_open' exposes the LED name and channel where an open
> condition was detected.
> 
> The 'fault_state_short' exposes the LED name and channel where a short
> condition was detected.
> 
> To: Mark Brown <broonie@kernel.org>
> Cc: linux-spi@vger.kernel.org

These should be below the --- marker.

> Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> ---
>  Documentation/ABI/testing/sysfs-class-spi-lp5860 | 49 ++++++++++++++++++++++++

You're the first write driver documentation like this.

That has to tell you something.

>  1 file changed, 49 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-spi-lp5860 b/Documentation/ABI/testing/sysfs-class-spi-lp5860
> new file mode 100644
> index 0000000000000..31082bd78f51e
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-spi-lp5860
> @@ -0,0 +1,49 @@
> +What:           /sys/class/spi_master/spi<bus>/spi<bus>.<dev>/fault_state

I believe this path is incorrect. Attributes for an SPI slave device should
be under `/sys/bus/spi/devices/spi<bus>.<dev>/`, not under the master
device's class directory.

> +Date:           March 2026
> +KernelVersion:  7.0
> +Contact:        Steffen Trumtrar <kernel@pengutronix.de>

This is different to your sign-off address.

> +Description:
> +	Contains and sets the global fault state:
> +
> +	* 3: Open and short detected
> +	* 2: Open detected
> +	* 1: Short detected

Exposing a raw bitmask like this is not a good ABI. The sysfs convention is
"one value per file". It would be better to have separate read-only files
like `fault_short` and `fault_open` which would contain "1" if a fault is
active and "0" otherwise.

> +
> +	Can be cleared by writing the corresponding value back to fault_state.

This "write back what you read" mechanism is non-standard and racy. A
better approach is to provide a separate write-only `fault_clear` file, or
allow writing '0' to the individual fault files to clear them.

> +
> +	Example usage::
> +
> +		## Read
> +		# cat /sys/class/spi_master/spi<bus>/spi<bus>.<dev>/fault_state
> +		2
> +
> +		## Write
> +		# echo 2 > /sys/class/spi_master/spi<bus>/spi<bus>.<dev>/fault_state
> +
> +What:           /sys/class/spi_master/spi<bus>/spi<bus>.<dev>/fault_state_open
> +Date:           March 2026
> +KernelVersion:  7.0
> +Contact:        Steffen Trumtrar <kernel@pengutronix.de>
> +Description:
> +	Contains all LEDs and channels where an open condition was detected.

I'm also really confused by the cross-over here.

Are we documenting SPI behaviour or LED?

> +	The format is ledname:channel.
> +
> +	Example usage::
> +
> +		## Read
> +		# cat /sys/class/spi_master/spi<bus>/spi<bus>.<dev>/fault_state_open
> +		rgb1:0 rgb2:4
> +
> +What:           /sys/class/spi_master/spi<bus>/spi<bus>.<dev>/fault_state_short
> +Date:           March 2026
> +KernelVersion:  7.0
> +Contact:        Steffen Trumtrar <kernel@pengutronix.de>
> +Description:
> +	Contains all LEDs and channels where a short condition was detected.
> +	The format is ledname:channel.
> +
> +	Example usage::
> +
> +		## Read
> +		# cat /sys/class/spi_master/spi<bus>/spi<bus>.<dev>/fault_state_short
> +		rgb1:0 rgb2:4
> 
> -- 
> 2.51.0
> 

-- 
Lee Jones [李琼斯]

  reply	other threads:[~2026-03-19 17:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-11 12:27 [PATCH v2 0/2] LED: Add fault state handling to LP5860 LED Steffen Trumtrar
2026-03-11 12:27 ` [PATCH v2 1/2] led: lp5860: expose fault state via sysfs Steffen Trumtrar
2026-03-19 17:34   ` Lee Jones [this message]
2026-03-11 12:27 ` [PATCH v2 2/2] leds: lp5860: detect and report fault state Steffen Trumtrar
2026-03-19 18:09   ` Lee Jones

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=20260319173414.GA2902881@google.com \
    --to=lee@kernel.org \
    --cc=broonie@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=pavel@kernel.org \
    --cc=s.trumtrar@pengutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.