lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 10 Jul 2013 17:49:22 -0400
From:	Jason Cooper <jason@...edaemon.net>
To:	Matt Sealey <neko@...uhatsu.net>
Cc:	Neil Zhang <zhangwm@...vell.com>, grant.likely@...aro.org,
	haojian.zhuang@...il.com, arnd@...db.de,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'

On Wed, Jul 10, 2013 at 03:50:10PM -0500, Matt Sealey wrote:
> On Tue, Jul 9, 2013 at 7:49 AM, Jason Cooper <jason@...edaemon.net> wrote:
> > Neil,
> >
> > I agree with the need to change, however, this has been in the binding
> > documentation since v3.5.  I wish we had caught this when we decided
> > against using stock ticker symbols (not all stock markets use
> > alphabetical abbreviated names, not all companies are listed on any
> > stock exchange).
> 
> Who decided that?

Now you're going to make me dig ;-)  iirc, we were going the stock
ticker route, but then noticed that powerpc dts files had been using
"marvell,..." for a _long_ time.  How long?  I'll leave that as an
exercise for the reader. :-P  Because we shared at least the ethernet
driver with them, we decided to conform with what was already present in
the kernel and use "marvell,..." for all of the dt bindings we were
creating for kirkwood/dove/mvebu (and eventually orion5x, mv78xx0).

As for who is 'we'?

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/101337.html

> You can't just "stop using stock ticker symbols" - FDT is inherently
> based on the original OpenFirmware device tree and therefore any
> existing bindings which are done on real OpenFirmware solutions where
> using stock ticker symbols is entirely appropriate (although, these
> days, not useful) is counter-productive.
> 
> If Marvell had originally had mrvl as their ticker, and used this in
> OF DTs (and it is..), then mrvl it stays. In the case where new
> devices are added with marvell, this is in this case wrong. You should
> keep using the old one. A good example of this; Freescale. Nobody is
> saying everyone should move to "freescale,imx-this" or
> "freescale,vybrid-that" - it's fsl and it stays fsl for
> backwards/forwards compatibility because things exist already.

I agree, that's why I'm arguing for *maintaining* backwards
compatibility.

> Any new companies can have a long, descriptive name; a privilege of
> being late to the party, you might say :)
> 
> Having an odd mix of mrvl and marvell or moving to marvell is just
> completely obtuse, whether they had that stock ticker, will have it in
> the future, it is how they're defined and you can't in good conscience
> change the binding after devices ship with it.

See above regarding the marvell ethernet driver and powerpc...

> > To do this properly, the drivers are going to have to be compatible with
> > the old and the new names, and the binding docs updated to reflect the
> > legacy name and the preferred name.
> 
> Properly would be as above. You can stop using stock tickers for new
> company names, but anything that has been defined in a device tree
> before has to stay that way, and all the manufacturer prefixes to
> device names should be the same. What you're proposing is purely
> driver bloat and increasing the size of kernel.

*I'm* not proposing to change the name, Neil is.  I'm proposing that
*iff* they chose to do that, don't break sh*t along the way.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ