[U-Boot] [RFC PATCH 00/20] SPI-NAND support

[Jagan Teki]

On Tue, Jun 26, 2018 at 1:28 AM, Boris Brezillon
<boris.brezillon at bootlin.com> wrote:
> On Tue, 26 Jun 2018 00:07:10 +0530
> Jagan Teki <jagan at amarulasolutions.com> wrote:
>
>> >> I think I have to repeat my previous statement here. It would be very
>> >> unfortunate if u-boot decides to take this direction (see Richard's
>> >> reply), especially since I see absolutely no benefit in doing what you
>> >> suggest. Having MTD devices registered to the uboot DM is something I
>> >> can understand, deciding to no longer support the standard MTD API is
>> >> something I don't.
>>
>> > I agree.  We want U-Boot to be able to leverage as much as possible from
>> > the Linux kernel with as little re-working as possible.
>>
>> I'm not denying that, but the basic design flow must follow u-boot
>> driver model. this is what everyone told from the beginning when I
>> started spi-nor work. Initially I did the design like this and
>> leverage with existing MTD, everyone NAK and suggested to use
>> driver-model on each stage with MTD dm abstraction.
>> So
>> - After 2 years of work
>> - With nearly 10 versions [4]
>> - Adding MIGRATION expire date for spi drivers dm conversion
>> - Simon Reviewed-by and
>> - Planning to apply after v2018.09.
>>
>> but now all want the existing MTD, I don't understand what I can do
>> further on this?
>
> I didn't follow the initial discussion, but I can understand your
> frustration. Still, I think there's a misunderstanding here. I recommend
> that you have a second look at the different patches in this series.
> You'll see that everything Miquel did complies with the DM, and that
> the thing you're complaining about (MTD API not using udevice and not
> prefixed with dm_) is just a tiny detail compared to the rest.
>
> Keeping the MTD API is not incompatible with the conversion of
> all MTD provider drivers to the DM. I think we all agree on that MTD
> providers should be converted to the DM progressively, and the work
> Miquel did allows such a smooth transition because both non-DM drivers
> and DM-compliant drivers can co-exist without impacting MTD users.
>
> Sorry to say that, but your approach based on full-conversion is just an
> utopia. There's no way we can do that in a single step.
>
> So the question here is more, should we block all developments until we
> have a perfect solution (I don't think perfection can be achieved
> without trying things and making mistake), or should we move forward,
> one step after the other and keep the "conversion of all MTD
> drivers to the DM" as a long term goal?

Thanks for explaining all these Boris.

I agree on the context of "not to block the development" for the sake
of new improvement solution. Yes I will start reviewing these stuff,
even thought these are not compatible with MTD DM providers. Mean
while I will keep moving spi-nor development with MTD DM providers
along with Linux changes and it should be a starting point for full DM
conversion for MTD layer.

Jagan.

-- 
Jagan Teki
Senior Linux Kernel Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.