From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: "Yuxi (Yuxi) Wang" <Yuxi.Wang@monolithicpower.com>,
"pavel@ucw.cz" <pavel@ucw.cz>, "lee@kernel.org" <lee@kernel.org>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"krzysztof.kozlowski+dt@linaro.org"
<krzysztof.kozlowski+dt@linaro.org>,
"conor+dt@kernel.org" <conor+dt@kernel.org>,
"wyx137120466@gmail.com" <wyx137120466@gmail.com>
Cc: "linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V2 2/2] leds: add mp3326 driver
Date: Wed, 12 Jun 2024 08:12:44 +0200 [thread overview]
Message-ID: <c99d8df2-84ce-4b26-941e-b8a1413b8156@linaro.org> (raw)
In-Reply-To: <SN4PR13MB53103D139D9F816E5F4930EAF6C02@SN4PR13MB5310.namprd13.prod.outlook.com>
On 12/06/2024 04:23, Yuxi (Yuxi) Wang wrote:
>>
>>> +/*
>>> + * PWM in the range of [0 255]
>>> + */
>>> +static int led_pwm_store(struct device *dev, struct device_attribute *attr,
>>> + const char *buf, size_t count)
>>
>> Nope.
> Hi Krzysztof,
>
> What do you mean this Nope?
> Is it format or function?
As sorry, you are reimplementing kernel interfaces, so that's a no.
>
>>
>> ...
>>
>>> + }
>>> + r_val = r_val * 255 / 4095 + (r_val * 255 % 4095) / (4095 / 2);
>>> + g_val = g_val * 255 / 4095 + (g_val * 255 % 4095) / (4095 / 2);
>>> + b_val = b_val * 255 / 4095 + (b_val * 255 % 4095) / (4095 / 2);
>>> + if (led->num_colors == 1)
>>> + return sysfs_emit(buf, "0x%x\n", r_val);
>>> + else
>>> + return sysfs_emit(buf, "0x%x 0x%x 0x%x\n", r_val, g_val, b_val);
>>> +}
>>> +
>>> +static int led_enable_store(struct device *dev,
>>> + struct device_attribute *attr, const char *buf,
>>> + size_t count)
>>
>> Eeeee? store to enable LED? Really?
> Yes. The users need this function and we provide it.
NAK, I don't care about your users. You re-implemented existing ABI.
Without any ABI docs that's just pure duplication.
>
>
>>
>> ...
>>
>>> +{
>>> + struct led_classdev *lcdev = dev_get_drvdata(dev);
>>> + struct mp3326_led *led = container_of(lcdev, struct mp3326_led, cdev);
>>> + struct mp3326 *chip = led->private_data;
>>> + int ret;
>>> + uint val, i;
>>
>>
>>> +
>>> +static DEVICE_ATTR_RW(led_pwm);
>>> +static DEVICE_ATTR_RW(led_enable);
>>> +static DEVICE_ATTR_RO(led_short_fault);
>>> +static DEVICE_ATTR_RO(led_open_fault);
>>
>> No, for multiple reasons:
>> 1. Where ABI documentation?
>> 2. There is a standard sysfs interface. No need for most of that. Please
>> explain why standard interface does not fit your needs - for each new
>> interface.
> Hi krzysztof,
>
> 1. Where ABI documentation?
> A:
> Sorry, the abi is insufficient.
Which one is insufficient?
>
> Can I add it as comment above the function?
>
> 2. There is a standard sysfs interface. No need for most of that. Please
> explain why standard interface does not fit your needs - for each new
> interface.
> A:
> Leds has two ways to light dim. One is analog dimming, another pwm dimming.
> They are different in practice.
>
> In RGB module, pwm dimming can control color and analog dimming can control intensity.
>
> Mp3326 supports the two ways which can operate contemporary.
>
> In practice, I have needs below.
> 1. Operate rgb color and intensity.
> 2. enable/disable some channel
> 3. short/open fault notice.
>
> However, The standard interface only has three functions below, they are not fit my needs.
> 1. multi_index
> 2. multi_intensity(only can dim using one way, so I use it as analog dimming)
> 3. led_mc_calc_color
>
Please point to which ABI is not sufficient.
>
> In order to fit my needs, I add the interface below.
> led_pwm
> led_enable
Because especially this one sounds like you are mocking us.
> led_short_fault
> led_open_fault
>
Best regards,
Krzysztof
next prev parent reply other threads:[~2024-06-12 6:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-11 8:32 [PATCH V2 0/2] leds: Add a driver for MP3326 Yuxi Wang
2024-06-11 8:32 ` [PATCH V2 1/2] dt-bindings: leds: add mps mp3326 LED Yuxi Wang
2024-06-11 8:32 ` [PATCH V2 2/2] leds: add mp3326 driver Yuxi Wang
2024-06-11 9:21 ` Krzysztof Kozlowski
2024-06-12 2:23 ` Yuxi (Yuxi) Wang
2024-06-12 6:12 ` Krzysztof Kozlowski [this message]
2024-06-11 23:28 ` kernel test robot
2024-06-11 9:14 ` [PATCH V2 0/2] leds: Add a driver for MP3326 Krzysztof Kozlowski
2024-06-12 2:26 ` Yuxi (Yuxi) Wang
2024-06-12 6:13 ` Krzysztof Kozlowski
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=c99d8df2-84ce-4b26-941e-b8a1413b8156@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=Yuxi.Wang@monolithicpower.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=robh+dt@kernel.org \
--cc=wyx137120466@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;
as well as URLs for NNTP newsgroup(s).