From: matt.porter@linaro.org (Matt Porter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU
Date: Thu, 25 Jul 2013 20:04:13 -0400 [thread overview]
Message-ID: <20130726000412.GH5022@linaro.org> (raw)
In-Reply-To: <CAGVrzcYudfgqs_eafje4BT2z2qE0kSJPx1B-xrq0WxtUkGxSFw@mail.gmail.com>
On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote:
> 2013/7/25 Domenico Andreoli <cavokz@gmail.com>:
> > On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote:
> >> 2013/7/23 Matt Porter <matt.porter@linaro.org>:
> >> > On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote:
> >> >> On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote:
> >> >> > Hello,
> >> >> >
> >> >> > Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :
> >> >> > > > + compatible = "brcm,bcm5301x";
> >> >> > >
> >> >> > > Ok, this was nagging at me before I went on my very long
> vacation. I see
> >> >> > > the "brcm" vendor prefix as a real consistency problem. I noticed
> on the
> >> >> > > bcm281xx/kona family, we have been using "bcm" which is not
> logged in
> >> >> > > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had
> >> >> > > already established use of "brcm" before any of the bcm281xx
> support
> >> >> > > came in. Ideally, the vendor prefix should change to "bcm" since
> every
> >> >> > > reference in the family names is BCM. However, if others want the
> least
> >> >> > > amount of churn in making this consistent, we might have to go
> with
> >> >> > > "brcm" across the board.
> >> >> >
> >> >> > I would like to keep "brcm" here because that is what has been
> defined as a
> >> >> > vendor prefix, and is used beyond the scope of the ARM Linux kernel
> support
> >> >> > even within Broadcom. Maybe it was an oversight, or rather a
> mistake to let
> >> >>
> >> >> brcm is the stock ticker. As far as I can search, this is the
> convention
> >> >> for the vendor prefixes.
> >> >
> >> > No, correlation does not equal causation. The fact that some vendor
> >> > prefixes in DT match the stock symbol is by chance of 3-4 character
> name
> >> > being the same...nothing more.
> >>
> >> That was a bad argument as was later explained to me, I won't use that
> >> reason again.
> >
> > I cited the stock ticker only because IIRC it's the reason my initial
> > proposal for bcm has been ditched in favour of brcm when bcm2835 was
> > initially proposed.
> >
> >> > It's pretty easy to see that the "ti" vendor prefix has no relation at
> >> > all to their TXN symbol so that blows that convention out of the water.
> >> > Rather, the prefix is based on somebody's notion of how that vendor's
> >> > part are normally referred to. In TI-land, it's TI AM335x or TI OMAP,
> >> > never TXN OMAP. :)
> >> >
> >> > For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.
> >>
> >> It was appropriate before being the "wrong" vendor prefix was
> >> allocated, now that "brcm" has been allocated we should stick to it
> >> because otherwise we will break existing and on-going DT work.
> >
> > I still prefer bcm to brcm and I find enough evidence that bcm would be
> > better in the long term.
> >
> > So if Broadcomers can agree on bcm, now it's still the cheapest time to
> > fix in that direction, later will not be better.
>
> If we are to fix it in stone, once and for all, let's go for the full name
> which would avoid any kind of future confusion (this also seems to be the
> tendency with new vendor prefixes these days). That way we could make
> everyone happy with say: "broadcom,bcm2835". Would that work for everyone?
I really like that.
-Matt
next prev parent reply other threads:[~2013-07-26 0:04 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-16 13:52 [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU Hauke Mehrtens
2013-07-16 15:14 ` Matt Porter
2013-07-16 15:39 ` Hauke Mehrtens
2013-07-16 18:13 ` Hauke Mehrtens
2013-07-16 23:52 ` Matt Porter
2013-07-16 23:44 ` Matt Porter
2013-07-16 23:08 ` Florian Fainelli
2013-07-16 23:42 ` Matt Porter
2013-07-19 2:06 ` Domenico Andreoli
2013-07-23 18:57 ` Matt Porter
2013-07-23 19:05 ` Florian Fainelli
2013-07-24 23:11 ` Domenico Andreoli
[not found] ` <CAGVrzcYudfgqs_eafje4BT2z2qE0kSJPx1B-xrq0WxtUkGxSFw@mail.gmail.com>
2013-07-26 0:04 ` Matt Porter [this message]
2013-07-26 22:16 ` Christian Daudt
2013-07-26 22:29 ` Domenico Andreoli
2013-07-26 22:30 ` Stephen Warren
2013-07-29 9:30 ` Mark Rutland
2013-07-29 13:20 ` Matt Porter
2013-07-29 17:06 ` Stephen Warren
2013-07-30 23:08 ` Christian Daudt
2013-07-23 18:49 ` Matt Porter
2013-07-23 18:56 ` Florian Fainelli
2013-07-23 19:14 ` Arend van Spriel
2013-07-23 19:22 ` Matt Porter
2013-07-24 0:10 ` Christian Daudt
[not found] ` <CADjby3WGW6f=1Vdm2kx+Re0KrjFRaC3dQOumpnS6_sp2yb5NfQ@mail.gmail.com>
2013-07-24 19:21 ` Hauke Mehrtens
2013-07-24 22:54 ` Domenico Andreoli
2013-07-25 20:33 ` Hauke Mehrtens
2013-07-25 21:37 ` Christian Daudt
2013-07-25 21:58 ` Domenico Andreoli
2013-07-19 13:03 ` Arnd Bergmann
2013-07-16 15:20 ` Thomas Petazzoni
2013-07-16 15:35 ` Hauke Mehrtens
2013-07-19 1:36 ` Domenico Andreoli
2013-07-23 22:10 ` Hauke Mehrtens
2013-07-16 23:19 ` Russell King - ARM Linux
2013-07-19 2:23 ` Domenico Andreoli
2013-07-23 21:54 ` Hauke Mehrtens
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=20130726000412.GH5022@linaro.org \
--to=matt.porter@linaro.org \
--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;
as well as URLs for NNTP newsgroup(s).