2024-04-24 00:00:19

by Andy Shevchenko

[permalink] [raw]
Subject: Re: [PATCH 2/4] mfd: intel-lpss: Utilize i2c-designware.h

Tue, Apr 23, 2024 at 04:36:20PM -0700, Florian Fainelli kirjoitti:
> Rather than open code the i2c_designware string, utilize the newly
> defined constant in i2c-designware.h.

..

> static const struct mfd_cell intel_lpss_i2c_cell = {
> - .name = "i2c_designware",
> + .name = I2C_DESIGNWARE_NAME,
> .num_resources = ARRAY_SIZE(intel_lpss_dev_resources),
> .resources = intel_lpss_dev_resources,
> };

We have tons of drivers that are using explicit naming, why is this case
special?

--
With Best Regards,
Andy Shevchenko




2024-04-24 08:21:39

by Florian Fainelli

[permalink] [raw]
Subject: Re: [PATCH 2/4] mfd: intel-lpss: Utilize i2c-designware.h



On 4/23/2024 5:00 PM, Andy Shevchenko wrote:
> Tue, Apr 23, 2024 at 04:36:20PM -0700, Florian Fainelli kirjoitti:
>> Rather than open code the i2c_designware string, utilize the newly
>> defined constant in i2c-designware.h.
>
> ...
>
>> static const struct mfd_cell intel_lpss_i2c_cell = {
>> - .name = "i2c_designware",
>> + .name = I2C_DESIGNWARE_NAME,
>> .num_resources = ARRAY_SIZE(intel_lpss_dev_resources),
>> .resources = intel_lpss_dev_resources,
>> };
>
> We have tons of drivers that are using explicit naming, why is this case
> special?
>

It is not special, just one of the 3 cases outside of drivers/i2c/busses
that reference a driver living under drivers/i2c/busses, as I replied in
the cover letter, this is a contract between the various device drivers
and their users, so we should have a central place where it is defined,
not repeated.
--
Florian


Attachments:
smime.p7s (4.12 kB)
S/MIME Cryptographic Signature

2024-05-02 07:18:10

by Lee Jones

[permalink] [raw]
Subject: Re: [PATCH 2/4] mfd: intel-lpss: Utilize i2c-designware.h

On Tue, 23 Apr 2024, Florian Fainelli wrote:

>
>
> On 4/23/2024 5:00 PM, Andy Shevchenko wrote:
> > Tue, Apr 23, 2024 at 04:36:20PM -0700, Florian Fainelli kirjoitti:
> > > Rather than open code the i2c_designware string, utilize the newly
> > > defined constant in i2c-designware.h.
> >
> > ...
> >
> > > static const struct mfd_cell intel_lpss_i2c_cell = {
> > > - .name = "i2c_designware",
> > > + .name = I2C_DESIGNWARE_NAME,
> > > .num_resources = ARRAY_SIZE(intel_lpss_dev_resources),
> > > .resources = intel_lpss_dev_resources,
> > > };
> >
> > We have tons of drivers that are using explicit naming, why is this case
> > special?
> >
>
> It is not special, just one of the 3 cases outside of drivers/i2c/busses
> that reference a driver living under drivers/i2c/busses, as I replied in the
> cover letter, this is a contract between the various device drivers and
> their users, so we should have a central place where it is defined, not
> repeated.

I have always held the opinion that replacing user-facing strings with
defines harms debugability, since grepping becomes a multi-stage
process, often with ambiguous results (in the case of multiple
definitions with the same name. Please keep the string in-place.

--
Lee Jones [李琼斯]

2024-05-02 22:38:16

by Florian Fainelli

[permalink] [raw]
Subject: Re: [PATCH 2/4] mfd: intel-lpss: Utilize i2c-designware.h

On 5/2/24 00:17, Lee Jones wrote:
> On Tue, 23 Apr 2024, Florian Fainelli wrote:
>
>>
>>
>> On 4/23/2024 5:00 PM, Andy Shevchenko wrote:
>>> Tue, Apr 23, 2024 at 04:36:20PM -0700, Florian Fainelli kirjoitti:
>>>> Rather than open code the i2c_designware string, utilize the newly
>>>> defined constant in i2c-designware.h.
>>>
>>> ...
>>>
>>>> static const struct mfd_cell intel_lpss_i2c_cell = {
>>>> - .name = "i2c_designware",
>>>> + .name = I2C_DESIGNWARE_NAME,
>>>> .num_resources = ARRAY_SIZE(intel_lpss_dev_resources),
>>>> .resources = intel_lpss_dev_resources,
>>>> };
>>>
>>> We have tons of drivers that are using explicit naming, why is this case
>>> special?
>>>
>>
>> It is not special, just one of the 3 cases outside of drivers/i2c/busses
>> that reference a driver living under drivers/i2c/busses, as I replied in the
>> cover letter, this is a contract between the various device drivers and
>> their users, so we should have a central place where it is defined, not
>> repeated.
>
> I have always held the opinion that replacing user-facing strings with
> defines harms debugability, since grepping becomes a multi-stage
> process, often with ambiguous results (in the case of multiple
> definitions with the same name. Please keep the string in-place.

I am not buying into that argument and the fact that Duangiang was able
to trip over the lack of an explicit contract between drivers seems like
a bigger obstacle than doing a multi-stage grep. Anyway, I have no skin
in this game, I just don't like seeing repetition and not stating
contracts between drivers more explicitly.
--
Florian


Attachments:
smime.p7s (4.12 kB)
S/MIME Cryptographic Signature