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.
--
Lee Jones [李琼斯]
