Hi all,
On 23-11-29, Arnd Bergmann wrote:
> On Wed, Nov 29, 2023, at 17:47, Miquel Raynal wrote:
> > brgl@xxxxxxxx wrote on Wed, 29 Nov 2023 10:10:28 +0100:
> >> Though if I'm being honest - I would prefer a single driver with
> >> backwards compatibility. Have you estimated the effort it would take
> >> to abstract both nvmem and mtd?
> >
> > Also agreed :-)
>
> +1
Thank you very much for the input :) Of course having a single driver
would be better. Before spending to much effort for this I went the
simple way to gather some input in case of you don't like the approach
at all. I also hoped that we could deprecate the non MTD variant later
on. That beeinng said, MTD does not mean that we don't have access to
NVMEM since NVMEM is already supported by MTD as well. It's just not
under the same name and the backward/compatibility config is not set.
Therefore it's not a drop-in replacement right now.
> I think this particularly makes sense in the light the other
> at24 driver that was recently removed in commit 0113a99b8a75
> ("eeprom: Remove deprecated legacy eeprom driver").
>
> The other problem with having two drivers is the need to
> arbitrate between them, e.g. when you have a machine with
> two at24 devices but want to use one of each for the two
> subsystems. This does not really work with our DT probing
> logic at the moment.
Yes this is not possible, but I also can't imagine such use-case. You
can use the MTD version for both since NVMEM is supported for the MTD
version as well.
Let me check how I can keep the backward compatiblity e.g. by guessing
which in case can be error prone as well.
Regards,
Marco
