linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

  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).