All of lore.kernel.org
 help / color / mirror / Atom feed
From: cdaudt@gmail.com (Christian Daudt)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V3] Add support for generic BCM SoC chipsets
Date: Sat, 17 Nov 2012 09:53:45 -0800	[thread overview]
Message-ID: <CAA-5wcAqcjA7VNVXRZ8AE2r5EFQsFa68Rqi_ptYDDR9XXHsUMg@mail.gmail.com> (raw)
In-Reply-To: <201211171721.15021.arnd@arndb.de>

On Sat, Nov 17, 2012 at 9:21 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> On Saturday 17 November 2012, Christian Daudt wrote:
> > >> diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt
> b/Documentation/devicetree/bindings/arm/bcm/bcm281xx.txt
> > >
> > >> +Required root node property:
> > >> +
> > >> +compatible = "bcm,bcm281xx";
> > >
> > > Hmm. I still tend to think we should list the specific SoC rather than
> > > the family here, but I guess if you're sure there won't be any SW
> > > compatibility between the different SoCs in the series, this is fine.
> > >
> >
> > right now I expect to be able to use the family thoughout, so I'll stick
> to it.
> >
>
> But that's not how the compatible property is supposed to work: Each
> compatible
> value should refer to a specific property, and not include wildcards.
> If you have one driver (or platform file in this case) that can deal with
> a whole family of devices, the normal solution is to list the name of the
> oldest
> part in the compatible string as the most generic part, and then list the
> name of the new part as the specific one.
>
> At that point doesn't the 'oldest part' become the wildcard  ? I'm not
very attached to names, so I'm ok changing bcm281xx above to bcm11351,
which happens to be the first chip I'm submitting a board for. But then
bcm11351 will just become 'the chip name used to represent the family'
right ? I had followed the fact that omap does use omap5 in omap5.dtsi -
and afaik tegra2 and tegra3 are family names, not chip models, and are used
in dtsi. But then again a bunch of chip models are used to represent the
families too...
 Let me know if you want me to submit a modified patchset. Shouldn't take
me more than 5 minutes anyways :)

 Thanks,
   csd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121117/159b5b7f/attachment-0001.html>

  reply	other threads:[~2012-11-17 17:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-13 21:51 [PATCH V3] Add support for generic BCM SoC chipsets Christian Daudt
2012-11-17  4:10 ` Stephen Warren
2012-11-17 16:07   ` Christian Daudt
2012-11-17 17:21     ` Arnd Bergmann
2012-11-17 17:53       ` Christian Daudt [this message]
2012-11-17 18:04         ` Arnd Bergmann
2012-11-17 23:39           ` Christian Daudt
2012-11-18  0:02             ` Christian Daudt
2012-11-18 11:32               ` Arnd Bergmann
2012-11-18  5:50         ` Stephen Warren

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=CAA-5wcAqcjA7VNVXRZ8AE2r5EFQsFa68Rqi_ptYDDR9XXHsUMg@mail.gmail.com \
    --to=cdaudt@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.