Re: [PATCH v3 2/2] nvmem: lan9662-otp: add support.

[Horatiu Vultur]

The 08/31/2022 15:52, Krzysztof Kozlowski wrote:
> 
> On 31/08/2022 13:52, Horatiu Vultur wrote:
> > The 08/31/2022 10:29, Krzysztof Kozlowski wrote:
> >
> > Hi Krzysztof,
> >
> >>
> >> On 31/08/2022 09:42, Horatiu Vultur wrote:
> >>
> >>> +static const struct of_device_id lan9662_otp_match[] = {
> >>> +     { .compatible = "microchip,lan9662-otp", },
> >>> +     { .compatible = "microchip,lan9668-otp", },
> >>
> >> This is still wrong, does not match your bindings at all and still
> >> duplicates entries without driver data. One entry - 9662.
> >
> > I have look at some other drivers, where I can see they don't have any
> > driver data. For example [1] and the bindings are here [2].
> >
> > [1] https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/ti/cpsw_new.c#L1832
> > [2] https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml#L23
> 
> There are plenty of poor examples in Linux kernel code and it is not a
> reason to re-use their patterns...
> 
> > Is this also wrong, or I still can't understand how the bindings are
> > working?
> 
> The topic here is not that much related to the bindings, but device
> matching in Linux kernel.
> 
> >
> > If I put only one entry:
> > ---
> > static const struct of_device_id lan9662_otp_match[] = {
> >      { .compatible = "microchip,lan9662-otp", },
> > ---
> >
> > Wouldn't be a problem that the binding mentions also lan9668?
> 
> No. What could be the problem exactly, which you are afraid? Why
> implementation should be a problem for a binding (which we try to be
> mostly implementation independent)?

The implementation wouldn't be a problem for the binding.
The only thing was if the binding has more compatible strings than what
the driver supports. As an example, in the binding we mention about
lan9668 but nothing in the driver.

> 
> Best regards,
> Krzysztof

-- 
/Horatiu