From: computersforpeace@gmail.com (Brian Norris)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 5/5] m25p80,spi-nor: Share the list of supported chip type names again
Date: Thu, 9 Oct 2014 21:55:24 -0700 [thread overview]
Message-ID: <20141010045524.GD22169@norris-Latitude-E6410> (raw)
In-Reply-To: <1412076963.9388.96.camel@decadent.org.uk>
On Tue, Sep 30, 2014 at 12:36:03PM +0100, Ben Hutchings wrote:
> On Tue, 2014-09-30 at 10:02 +0200, Rafa? Mi?ecki wrote:
> > On 30 September 2014 04:15, Ben Hutchings <ben@decadent.org.uk> wrote:
> > > Move the list of chip type information to a macro in spi-nor.h, but
> > > leave the definitions of INFO and CAT25_INFO in spi-nor.
> > >
> > > In m25p80, define the INFO and CAT25_INFO macros to initialise a
> > > struct spi_device_id with the name, ignoring the remaining parameters.
> >
> > Anyone would consider my idea proposed in 1/5 thread?
> >
> > We could simply follow the way Linux-specific platform data works. We
> > could always use
> > compatible = "m25p80";
> > and then for some rare cases (where JEDEC fails) add something like
> > model = "at25df321a";
> >
> > Using above way we could use a one single "compatible" in m25p80.c and
> > avoid this messy share of id_table.
>
> You *cannot* define a DT compatible string by reference to out-of-band
> information about all the chips that has to be updated for each new
> chip.
>
> That is not 'compatible'.
Well, for the DT case at least, what is the problem with including two
(or more) compatible strings in the board DT, but the driver only
binding against the common one ("m25p80" or something like
"spi-nor,jedec-id") unless necessary? You can still follow best DT
practices formally without always binding to the most specific string
when that doesn't buy you anything.
The true board file / platform data cases are slightly different, but in
those cases, the board file can evolve in sync with drivers, I think.
Brian
prev parent reply other threads:[~2014-10-10 4:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-30 2:13 [PATCH v2 0/5] m25p80,spi-nor: Fix module aliases for m25p80; clean up chip identification Ben Hutchings
2014-09-30 2:14 ` [PATCH v2 1/5] m25p80,spi-nor: Fix module aliases for m25p80 Ben Hutchings
2014-10-10 4:51 ` Brian Norris
2014-10-17 16:23 ` Brian Norris
2014-10-17 16:35 ` Brian Norris
2014-10-17 16:41 ` Ben Hutchings
2014-09-30 2:15 ` [PATCH v2 2/5] spi-nor: Remove spi_nor::read_id operation Ben Hutchings
2014-10-22 8:30 ` Brian Norris
2014-09-30 2:15 ` [PATCH v2 3/5] spi-nor: Make spi_nor_scan() take a chip type name, not an spi_device_id Ben Hutchings
2014-09-30 5:14 ` Rafał Miłecki
2014-09-30 11:38 ` Ben Hutchings
2014-09-30 2:15 ` [PATCH v2 4/5] spi-nor: Replace struct spi_device_id with struct flash_info Ben Hutchings
2014-09-30 2:15 ` [PATCH v2 5/5] m25p80,spi-nor: Share the list of supported chip type names again Ben Hutchings
2014-09-30 7:22 ` Geert Uytterhoeven
2014-09-30 8:02 ` Rafał Miłecki
2014-09-30 11:36 ` Ben Hutchings
2014-10-10 4:55 ` Brian Norris [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141010045524.GD22169@norris-Latitude-E6410 \
--to=computersforpeace@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox