[PATCH] Documentation: dt: mtd: replace "nor-jedec" binding with "jedec,spi-nor"

[Brian Norris]

(trim CC a bit, as this is no longer a DT binding question)

On Thu, May 21, 2015 at 09:12:25AM +0200, Rafał Miłecki wrote:
> On 20 May 2015 at 23:35, Brian Norris <computersforpeace at gmail.com> wrote:
> > On Tue, May 19, 2015 at 09:27:50AM +0200, Rafał Miłecki wrote:
> >> On 19 May 2015 at 03:34, Brian Norris <computersforpeace at gmail.com> wrote:
> >> > So how about the following patch? It seems like we'll need to be able to
> >> > ignore useless 'modalias' values in cases like this:
> >> >
> >> >         // modalias = "shinynewdevice"
> >> >         compatible = "myvendor,shinynewdevice", "jedec,spi-nor";
> >> >
> >> > and also if somebody leaves off the entire shinynewdevice string:
> >> >
> >> >         // modalias = "spi-nor"
> >> >         compatible = "jedec,spi-nor";
> >> >
> >> > So we rework the spi-nor library to not reject "bad" names, and just
> >> > fall back to autodetection, and we add the .of_match_table to properly
> >> > catch all "jedec,spi-nor".
> >>
> >> That's nice but what about platforms using platform data instead of
> >> DT? I would like to use some kind of "spi-nor" (with some prefix
> >> *maybe*) for them too.
> >
> > For platform devices, you might as well just use the name of the driver,
> > which is 'm25p80'. Isn't that how most platform devices are matched with
> > drivers?
> 
> Yes and I think it's ugly because it keeps causing the warning about
> read flash model not matching specified one (m25p80).

Sure, I agree.

> Are you
> seriously not going to allow platform stuff *clearly* request flash
> model detection (JEDEC RDID OP)? Just because they don't use DT?

No, this isn't about "allowing" anything. It's just that my primary
concern was to get the DT binding straightened out properly. Linus'
current tree now has the proper binding, but the m25p80.c code doesn't
quite bind properly. It will work if "jedec,spi-nor" is the first
entry in the compatible property (and so it becomes the 'modalias', but
not second, third, etc. So my patch fixes that properly.

Now, the secondary concern is that you want platform devices to specify
something generic, and that doesn't yield a "found X, expected Y"
message. I'm perfectly fine with fixing that too, if you have a patch
for it. What do you propose?

Brian