From: Benedikt Spranger <b.spranger@linutronix.de>
To: Maxime Ripard <maxime@cerno.tech>
Cc: bage@linutronix.de, devicetree@vger.kernel.org,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH 1/5] dt-bindings: Add vendor prefix lx for Linutronix
Date: Wed, 12 Feb 2020 10:39:42 +0100 [thread overview]
Message-ID: <20200212103942.6f2dc5ec@mitra> (raw)
In-Reply-To: <20200210074310.c6adwjegqouzs6uc@gilmour.lan>
[-- Attachment #1: Type: text/plain, Size: 964 bytes --]
On Mon, 10 Feb 2020 08:43:10 +0100
Maxime Ripard <maxime@cerno.tech> wrote:
> Vendor names are usually either the vendor name itself or the stock
> name, so you should really use linutronix here
May you kindly enlighten me why?
"lx" is used internaly and externaly in projects, publications,
contracts, etc. as common abbreviation by the Linutronix GmbH.
Therefore it was self-evident to use this abbreviation in the device
tree.
As I did not found any documented rule in the kernel documentation,
which denote a restriction for the vendor abbreviation in the device
tree bindings the decision for "lx" was clear.
A quick look into
"Documentation/devicetree/bindings/vendor-prefixes.yaml"
assured me in the decision to use "lx".
Here some example not fitting your rule:
"^ad,.*":
"^adi,.*":
"^al,.*":
"^anvo,.*":
...
In summary I would be encouraged if "lx" gets in, as it is *our*
abbreviation.
Regards
Benedikt Spranger
[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-02-12 9:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 11:33 [PATCH 0/5] dts: Add Linutronix Testbox bage
2020-02-06 11:33 ` [PATCH 1/5] dt-bindings: Add vendor prefix lx for Linutronix bage
2020-02-06 21:55 ` Rob Herring
2020-02-10 7:43 ` Maxime Ripard
2020-02-11 17:15 ` Rob Herring
2020-02-12 9:39 ` Benedikt Spranger [this message]
2020-02-12 11:56 ` Maxime Ripard
2020-02-06 11:33 ` [PATCH 2/5] dt-bindings: arm: sunxi: Add Linutronix Testbox bage
2020-02-06 21:58 ` Rob Herring
2020-02-06 11:33 ` [PATCH 3/5] ARM: dts: sun7i: lamobo-r1: Use SPDX identifier bage
2020-02-06 12:54 ` Thomas Gleixner
2020-02-06 11:33 ` [PATCH 4/5] ARM: dts: sun7i: lamobo-r1: Split out commons bage
2020-02-10 7:45 ` Maxime Ripard
2020-02-12 10:01 ` Benedikt Spranger
2020-02-12 12:26 ` Maxime Ripard
2020-02-06 11:33 ` [PATCH 5/5] ARM: dts: sun7i: Add Linutronix Testbox v2 board bage
2020-02-10 7:56 ` Maxime Ripard
2020-02-12 11:20 ` Benedikt Spranger
2020-02-12 12:33 ` Maxime Ripard
2020-02-14 11:10 ` [PATCH v2 0/3] dts: Add Linutronix Testbox bage
2020-02-14 11:10 ` [PATCH v2 1/3] dt-bindings: Add vendor prefix for Linutronix bage
2020-02-14 13:21 ` Maxime Ripard
2020-02-19 20:06 ` Rob Herring
2020-02-14 11:10 ` [PATCH v2 2/3] dt-bindings: arm: sunxi: Add Linutronix Testbox bage
2020-02-14 11:10 ` [PATCH v2 3/3] ARM: dts: sun7i: Add Linutronix Testbox v2 board bage
2020-02-14 13:26 ` Maxime Ripard
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=20200212103942.6f2dc5ec@mitra \
--to=b.spranger@linutronix.de \
--cc=bage@linutronix.de \
--cc=devicetree@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maxime@cerno.tech \
--cc=robh+dt@kernel.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).