mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: "Sascha Hauer" <s.hauer@pengutronix.de>
To: "Luca Lauro" <famlauro93l@gmail.com>
Cc: "open list:BAREBOX" <barebox@lists.infradead.org>
Subject: Re: [PATCH v4 05/14] drivers: fan: add fan subsystem, core API and G76x fan controller driver
Date: Mon, 31 Aug 2026 13:08:23 +0000	[thread overview]
Message-ID: <6ec6ad6e-05d4-4d1b-b3ac-49a702ae6ab5@pengutronix.de> (raw)
In-Reply-To: <CANRe2WKLBADaD7z3HqmQ2LVEFa46VQrC=rYwcNdB1wmvxDN-QA@mail.gmail.com>

On 2026-08-31 13:53, Luca Lauro wrote:
> Il giorno lun 24 ago 2026 alle ore 10:11 Sascha Hauer
> <s.hauer@pengutronix.de> ha scritto:
> >
> > Hi Luca,
> >
> > On 2026-08-13 17:26, Luca Lauro via B4 Relay wrote:
> > > +
> > > +struct fan_ops {
> > > +     int (*get_fan_startv)(struct device *dev, char *buf);
> > > +     int (*set_fan_startv)(struct device *dev, unsigned long val);
> > > +
> > > +     int (*get_gear_multiplier)(struct device *dev, char *buf);
> > > +     int (*set_gear_multiplier)(struct device *dev, unsigned long val);
> > > +
> > > +     int (*get_fan_ppr)(struct device *dev, char *buf);
> > > +     int (*set_fan_ppr)(struct device *dev, unsigned long val);
> > > +
> > > +     int (*get_pwm_polarity)(struct device *dev, char *buf);
> > > +     int (*set_pwm_polarity)(struct device *dev, unsigned long val);
> > > +
> > > +     int (*get_clk_freq)(struct device *dev, char *buf);
> > > +     int (*set_clk_freq)(struct device *dev, unsigned long val);
> > > +
> > > +     int (*get_clk_div)(struct device *dev, char *buf);
> > > +     int (*set_clk_div)(struct device *dev, unsigned long val);
> > > +
> > > +     int (*get_control_mode)(struct device *dev, char *buf);
> > > +     int (*set_control_mode)(struct device *dev, unsigned long val);
> > > +
> > > +     int (*get_output_mode)(struct device *dev, char *buf);
> > > +     int (*set_output_mode)(struct device *dev, unsigned long val);
> > > +
> > > +     int (*get_ooc_detection)(struct device *dev, char *buf);
> > > +     int (*set_ooc_detection)(struct device *dev, unsigned long val);
> > > +
> > > +     int (*get_failure_detection)(struct device *dev, char *buf);
> > > +     int (*set_failure_detection)(struct device *dev, unsigned long val);
> > > +
> > > +     int (*get_failure_state)(struct device *dev, char *buf);
> > > +     int (*get_ooc_state)(struct device *dev, char *buf);
> > > +
> > > +     int (*get_fan_speed)(struct device *dev, char *buf);
> > > +     int (*set_fan_speed)(struct device *dev, unsigned long val);
> > > +
> > > +     int (*get_fan_rpm)(struct device *dev, char *buf);
> > > +     int (*set_fan_rpm)(struct device *dev, unsigned long val);
> > > +
> > > +     int (*get_fan_level)(struct device *dev, char *buf);
> > > +     int (*set_fan_level)(struct device *dev, unsigned long val);
> >
> > Converting the integer value to a string shouldn't be delegated to the
> > drivers. When the fan level can be expressed as unsigned long, then
> > get_fan_level() should take a unsigned long * as argument as well.
> >
> > Also the user facing interface you could use device parameters which
> > makes the fan command almost go away.
> >
> > Reworking the parameters above along the lines:
> >
> >         dev_add_param_uint32(&fan->dev, "rpm", fan_rpm_set, fan_rpm_get, &fan->rpm, "%u", fan);
> >
> > Will give you scriptable access to the parameters without an additional
> > command.
> 
> Thanks for the feedback.
> 
> Just to give some context:: the fan subsystem (fan.c / fan.h) is meant to
> be the hardware abstraction layer for the various fan controller
> hardware-specific
> drivers adapted from the Linux kernel.
> The “fan” command was only intended as a thin user-facing frontend on top
> of that HAL, similar in spirit to how barebox exposes unified interfaces
> for GPIO, LEDs, etc.
> 
> I agree that device parameters provide a more compact interface in barebox,
> and they already cover most of the use cases that the command was meant to
> address.
> 
> Before I rework the series, I would like to understand your preference for
> the user-facing layer: should the fan subsystem rely entirely on device
> parameters, or do you see value in keeping a small generic command on top
> of the HAL? I can follow either direction; just let me know which one fits
> better into barebox.

A command might be useful for more complex operations that can't be
expressed by device parameters, but for the bulk of the operations which
1:1 map onto a variable I would prefer device parameters over a command.

Note that using device parameters also allows you to provide defaults
via the environment.

But generally I question the ABI you have chosen. My first search didn't
reveal it because there is no g76x in the Kernel, but then I found the g762
driver which has a fairly complete device tree binding:

        g762@3e {
                compatible = "gmt,g762";
                reg = <0x3e>;
                clocks = <&g762_clk>;
                fan_gear_mode = <0>;
                fan_startv = <1>;
                pwm_polarity = <0>;
        };

The above things should just be configurable via device tree and not
even adjustable from the command line, as there's no point in doing so.

Also this fan subsytems looks as if it is written specifically for the
chip you are trying to handle, not as a generic subsystem.

I think you should have a closer look at how Linux does it, this might
give you some more guidance how this thing could be implemented.

Another thing: Please separate the subsystem patch from the driver(s),
it makes it easier to review the border between both.

I think you should send the fan stuff as an extra series, otherwise it
becomes the blocker for this series which as a whole already looks ok.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |




  reply	other threads:[~2026-08-31 13:46 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-13 15:26 [PATCH v4 00/14] (no cover subject) Luca Lauro via B4 Relay
2026-08-13 15:26 ` [PATCH v4 01/14] ARM: mvebu: add Netgear RN102 support Luca Lauro via B4 Relay
2026-08-17  7:51   ` Sascha Hauer
2026-08-18  8:44     ` Uwe Kleine-König
2026-08-19  7:16       ` Sascha Hauer
2026-08-19  7:39         ` Uwe Kleine-König
     [not found]       ` <6a85585d.5770c427.2e0747.7f3dSMTPIN_ADDED_MISSING@mx.google.com>
2026-08-20 17:59         ` Luca Lauro
2026-08-21 10:07           ` Sascha Hauer
2026-08-21 11:57             ` Luca Lauro
2026-08-20 14:35     ` Luca Lauro
     [not found]     ` <CANRe2W+Cp82qe+R_VNf_hXV+NRet+F63fq34pEw3FR-s4kw3zg@mail.gmail.com>
2026-08-21  9:17       ` Sascha Hauer
2026-08-21 11:23         ` Luca Lauro
2026-08-13 15:26 ` [PATCH v4 02/14] ARM: mvebu: enable RN102 in mvebu_defconfig Luca Lauro via B4 Relay
2026-08-13 15:26 ` [PATCH v4 03/14] ARM: mvebu: improve Netgear RN104 support Luca Lauro via B4 Relay
2026-08-13 15:26 ` [PATCH v4 04/14] ARM: mvebu: rename PUTC_LL to MVEBU_PUTC_LL Luca Lauro via B4 Relay
2026-08-21 10:38   ` Sascha Hauer
2026-08-21 12:26     ` Luca Lauro
2026-08-13 15:26 ` [PATCH v4 05/14] drivers: fan: add fan subsystem, core API and G76x fan controller driver Luca Lauro via B4 Relay
2026-08-24  8:11   ` Sascha Hauer
2026-08-31 11:53     ` Luca Lauro
2026-08-31 13:08       ` Sascha Hauer [this message]
2026-08-13 15:26 ` [PATCH v4 06/14] commands: add fan control command Luca Lauro via B4 Relay
2026-08-13 15:26 ` [PATCH v4 07/14] usb: ehci: add Marvell EHCI host controller driver Luca Lauro via B4 Relay
2026-08-13 15:26 ` [PATCH v4 08/14] usb: ehci: initialize periodic_queue_dma Luca Lauro via B4 Relay
2026-08-13 15:26 ` [PATCH v4 09/14] ata: ahci: add PCI AHCI and Marvell 9170 controller support Luca Lauro via B4 Relay
2026-08-13 15:26 ` [PATCH v4 10/14] ata: ahci: fix zero-length DMA handling Luca Lauro via B4 Relay
2026-08-13 15:26 ` [PATCH v4 11/14] ata: ahci: add helper for ATA commands without data Luca Lauro via B4 Relay
2026-08-13 15:26 ` [PATCH v4 12/14] ata: ahci: improve AHCI port bring-up sequence Luca Lauro via B4 Relay
2026-08-13 15:26 ` [PATCH v4 13/14] ata: ahci: add FLUSH EXT and STANDBY IMMEDIATE support during shutdown Luca Lauro via B4 Relay
2026-08-13 15:26 ` [PATCH v4 14/14] ata: ahci: cleanup legacy code and remove unused paths Luca Lauro via B4 Relay

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=6ec6ad6e-05d4-4d1b-b3ac-49a702ae6ab5@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=famlauro93l@gmail.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