[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f4692540-4be0-4140-0a9c-e38f2e9515ba@linaro.org>
Date: Thu, 30 Mar 2023 10:04:53 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Lee Jones <lee@...nel.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: "Sahin, Okan" <Okan.Sahin@...log.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Jonathan Cameron <jic23@...nel.org>,
Lars-Peter Clausen <lars@...afoo.de>,
Cosmin Tanislav <demonsingur@...il.com>,
Stephen Boyd <sboyd@...nel.org>,
Caleb Connolly <caleb.connolly@...aro.org>,
Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
"Bolboaca, Ramona" <Ramona.Bolboaca@...log.com>,
ChiYuan Huang <cy_huang@...htek.com>,
"Tilki, Ibrahim" <Ibrahim.Tilki@...log.com>,
William Breathitt Gray <william.gray@...aro.org>,
Arnd Bergmann <arnd@...db.de>,
ChiaEn Wu <chiaen_wu@...htek.com>,
Haibo Chen <haibo.chen@....com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>
Subject: Re: [PATCH v6 5/5] mfd: max77541: Add ADI MAX77541/MAX77540 PMIC
Support
On 29/03/2023 17:06, Lee Jones wrote:
> On Wed, 29 Mar 2023, Lee Jones wrote:
>
>> On Wed, 29 Mar 2023, Andy Shevchenko wrote:
>>
>>> On Wed, Mar 29, 2023 at 03:36:15PM +0100, Lee Jones wrote:
>>>> On Tue, 28 Mar 2023, Sahin, Okan wrote:
>>>>>> On Wed, 15 Mar 2023, Lee Jones wrote:
>>>>>>> On Tue, 07 Mar 2023, Okan Sahin wrote:
>>>
>>> ...
>>>
>>>>> +static const struct i2c_device_id max77541_i2c_id[] = {
>>>>> + { "max77540", (kernel_ulong_t)&chip[MAX77540] },
>>>>> + { "max77541", (kernel_ulong_t)&chip[MAX77541] },
>>>>
>>>> Just 'MAX77540' is fine.
>>>
>>> I tend to disagree.
>>>
>>> There is an error prone approach esp. when we talk with some functions
>>> that unifies OF/ACPI driver data retrieval with legacy ID tables.
>>> In such a case the 0 from enum is hard to distinguish from NULL when
>>> the driver data is not set or not found. On top of that the simple integer
>>> in the legacy driver data will require additional code to be added in
>>> the ->probe().
>>
>> Use a !0 enum?
>>
>> The extra handling is expected and normal.
>
> I've always disliked mixing platform initialisation strategies. Passing
> pointers to MFD structs through I2C/Device Tree registration opens the
> doors to all sorts of funky interlaced nonsense.
>
> Pass the device ID and then match in C-code please.
I agree. Especially that casting through ulong_t drops the const, so the
cast back needs const which can be forgotten. The patch already makes
here mistake!
Best regards,
Krzysztof
Powered by blists - more mailing lists