leds: turris-omnia: Fix brightness setting and trigger activating
authorMarek Behún <kabel@kernel.org>
Mon, 16 Oct 2023 14:15:38 +0000 (16:15 +0200)
committerLee Jones <lee@kernel.org>
Wed, 1 Nov 2023 11:29:16 +0000 (11:29 +0000)
commit78cbcfd8b13cefe089296d053f222934a53e153d
treee8a2eb64656f3b5958a04ed3f30daa7dfefe43f6
parent50be9e029b3ac72848685d7a74d1bd32b36309bf
leds: turris-omnia: Fix brightness setting and trigger activating

I have improperly refactored commits
  4d5ed2621c24 ("leds: turris-omnia: Make set_brightness() more efficient")
and
  aaf38273cf76 ("leds: turris-omnia: Support HW controlled mode via private trigger")
after Lee requested a change in API semantics of the new functions I
introduced in commit
  28350bc0ac77 ("leds: turris-omnia: Do not use SMBUS calls").

Before the change, the function omnia_cmd_write_u8() returned 0 on
success, and afterwards it returned a positive value (number of bytes
written). The latter version was applied, but the following commits did
not properly account for this change.

This results in non-functional LED's .brightness_set_blocking() and
trigger's .activate() methods.

The main reasoning behind the semantics change was that read/write
methods should return the number of read/written bytes on success.
It was pointed to me [1] that this is not always true (for example the
regmap API does not do so), and since the driver never uses this number
of read/written bytes information, I decided to fix this issue by
changing the functions to the original semantics (return 0 on success).

[1] https://lore.kernel.org/linux-gpio/ZQnn+Gi0xVlsGCYA@smile.fi.intel.com/

Fixes: 28350bc0ac77 ("leds: turris-omnia: Do not use SMBUS calls")
Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20231016141538.30037-1-kabel@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
drivers/leds/leds-turris-omnia.c