Re: [PATCH 17/17] staging: nuc-led: update the TODOs
From: Pavel Machek
Date: Mon May 17 2021 - 04:05:36 EST
> > > - Need to validate the uAPI and document it before moving
> > > this driver out of staging.
> > > - Stabilize and document its sysfs interface.
> > Would you mind starting with this one?
> Do you mean writing the ABI document for it? Surely I can do that,
> but I'm not sure where to put such document while it is on staging.
No need for formal ABI just yet, but it needs to be clear what the interface
> > We should have existing APIs
> > for most of functionality described...
> I tried to stay as close as possible to the existing API, but
> there are some things that required a different one.
I believe it should be possible to move _way_ closer to existing APIs.
> For instance, with WMI rev 0.64 and 1.0, any LED of the device
> can be programmed to be a power indicator.
> When a LED is programmed this way, there are up to 3 (on rev 1.0) or up
> to 4 (on rev 0.64) different brightness level of the LED, and those
> are associated with a power status (like S0, S3, S5, "ready mode").
I'll need a description how this works.
> ├── blink_behavior
> ├── blink_frequency
We have timer trigger for these.
> ├── ethernet_type
> ├── hdd_default
> ├── indicator
> ├── ready_mode_blink_behavior
> ├── ready_mode_blink_frequency
> ├── ready_mode_brightness
> ├── s0_blink_behavior
> ├── s0_blink_frequency
> ├── s0_brightness
> ├── s3_blink_behavior
> ├── s3_blink_frequency
> ├── s3_brightness
> ├── s5_blink_behavior
> ├── s5_blink_frequency
> ├── s5_brightness
No. Take a look at triggers; for example hdd monitor should look very
much like existing disk trigger.
> On other words, the "indicator" tells what type of hardware event
> the LED is currently measuring:
> $ cat /sys/class/leds/nuc\:\:front1/indicator
> Power State [HDD Activity] Ethernet WiFi Software Power Limit Disable
So this will use existing "trigger" infrastructure.
> That should likely be easier to discuss if any changes at the
> ABI would be needed. Before moving it out of staging, I would
> add another one under Documentation/ABI describing the meaning
> of each sysfs node.
Lets get reasonable ABI before moving it _into_ tree, staging or
Description: Digital signature