From: Mario Limonciello <mario.limonciello@amd.com>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: "Hans de Goede" <hdegoede@redhat.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Armin Wolf" <W_Armin@gmx.de>,
platform-driver-x86@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Joshua Grisham" <josh@joshuagrisham.com>
Subject: Re: [PATCH 2/2] platform/x86: firmware_attributes_class: Add test driver
Date: Tue, 7 Jan 2025 16:20:14 -0600 [thread overview]
Message-ID: <94769c30-af14-4111-8234-abf7e7333def@amd.com> (raw)
In-Reply-To: <7f568cbd-b299-41c6-8786-25f225de8f4f@t-8ch.de>
On 1/7/2025 16:13, Thomas Weißschuh wrote:
> On 2025-01-07 15:18:21-0600, Mario Limonciello wrote:
>> On 1/7/2025 14:50, Thomas Weißschuh wrote:
>>> On 2025-01-07 13:29:08-0600, Mario Limonciello wrote:
>>>> On 1/7/2025 11:05, Thomas Weißschuh wrote:
>>>>> The driver showcases the use of the new subsystem API.
>>>>>
>>>>> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
>>>>> ---
>>>>> drivers/platform/x86/Kconfig | 12 ++++
>>>>> drivers/platform/x86/Makefile | 1 +
>>>>> drivers/platform/x86/firmware_attributes_test.c | 78 +++++++++++++++++++++++++
>>>>> 3 files changed, 91 insertions(+)
>>>>>
>>>>> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
>>>>> index 0258dd879d64be389f4dd9bc309fe089f23cc798..2a0e828657d2f07074944d6c42dc204fc8825a42 100644
>>>>> --- a/drivers/platform/x86/Kconfig
>>>>> +++ b/drivers/platform/x86/Kconfig
>>>>> @@ -1065,6 +1065,18 @@ source "drivers/platform/x86/x86-android-tablets/Kconfig"
>>>>> config FW_ATTR_CLASS
>>>>> tristate
>>>>> +config FW_ATTR_TEST
>>>>> + tristate "Firmware attribute test driver"
>>>>> + select FW_ATTR_CLASS
>>>>> + help
>>>>> + This driver provides a test user of the firmware attribute subsystem.
>>>>> +
>>>>> + An instance is created at /sys/class/firmware-attributes/test/
>>>>> + container various example attributes.
>>>>> +
>>>>> + To compile this driver as a module, choose M here: the module
>>>>> + will be called firmware_attributes_test.
>>>>> +
>>>>
>>>> I think if you're going to be introducing a test driver it should be
>>>> compliant to what's in sysfs-class-firmware-attributes so that when it's
>>>> inevitably copy/pasted we end up with higher quality drivers.
>>>>
>>>> That is you need at a minimum 'type', 'current_value', 'default_value',
>>>> 'display_name' and 'display_name_language_code'. Then individual types
>>>> employ additional requirements.
>>>>
>>>> I see 'type', 'current_value', and 'default_value, but I don't see
>>>> 'display_name' or 'display_name_language_code' here.
>>>>
>>>> Furthermore as this is a "string" attribute you're supposed to also have a
>>>> "max_length" and "min_length".
>>>
>>> Agreed that more examples are better.
>>>
>>> But are these attributes really mandatory?
>>> "This attribute is mandatory" is only specified for "type" and>
>> "current_value".
>>
>> Ah wow, I had thought they were, but you're right they're not!
>>
>>> While "possible_values" certainly looks necessary for "enumeration",
>>> "min_length" for "strings" does so much less.
>>
>> Even if they're not mandatory, I think it's better to include them for the
>> same copy/paste reason I mentioned though.
>
> Thinking about it some more, which attributes should all be included?
> Having all of them in there could motivate driver authors to implement
> them all even it would mean filling in random values.
> The provided examples can already be copied-and-pasted and slightly
> adapted to add more attributes.
>
> Also as for providing an even higher level interface. There exists a
> fairly big feature matrix. For example the display_name_language_code:
> * Is it used at all?
> * Is it the same for all attributes implemented by the driver and the
> sysfs attribute can be reused for them all.
> * Should the same handler logic be reused between different settings which
> only differ in their language code?
>
> The answers seem to differ between each driver and having a uniform
> high-level interface that can handle all cases would look horrible.
> So I'd like to stick with the API provided currently for now and we can
> revisit it if there are more drivers.
> As mentioned before, the current API should be a decent baseline to
> build on top of.
>
>
> Thomas
How about just adding min_length and max_length? Since you're adding a
string attribute then it makes a good example of a string attribute.
It should be pretty trivial; AFAICT it's 0 to PAGE_SIZE.
next prev parent reply other threads:[~2025-01-07 22:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-07 17:05 [PATCH 0/2] platform/x86: firmware_attributes_class: Provide a highlevel interface Thomas Weißschuh
2025-01-07 17:05 ` [PATCH 1/2] " Thomas Weißschuh
2025-04-23 8:05 ` Kurt Borja
2025-04-23 16:57 ` Thomas Weißschuh
2025-01-07 17:05 ` [PATCH 2/2] platform/x86: firmware_attributes_class: Add test driver Thomas Weißschuh
2025-01-07 19:29 ` Mario Limonciello
2025-01-07 20:50 ` Thomas Weißschuh
2025-01-07 21:18 ` Mario Limonciello
2025-01-07 22:13 ` Thomas Weißschuh
2025-01-07 22:20 ` Mario Limonciello [this message]
2025-01-07 22:47 ` Thomas Weißschuh
2025-01-08 9:30 ` Ilpo Järvinen
2025-01-09 15:17 ` Thomas Weißschuh
2025-01-09 15:37 ` Mario Limonciello
2025-01-09 16:19 ` Thomas Weißschuh
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=94769c30-af14-4111-8234-abf7e7333def@amd.com \
--to=mario.limonciello@amd.com \
--cc=W_Armin@gmx.de \
--cc=hdegoede@redhat.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=josh@joshuagrisham.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=platform-driver-x86@vger.kernel.org \
/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
all inboxes | Powered by JetHome®