On Thu, Jul 21, 2022 at 03:34:23PM +0300, Laurent Pinchart wrote: > Hi Marek, > > On Thu, Jul 21, 2022 at 02:24:57PM +0200, Marek Vasut wrote: > > On 7/21/22 07:41, Laurent Pinchart wrote: > > > On Thu, Jul 21, 2022 at 05:03:27AM +0200, Marek Vasut wrote: > > >> Densitron is a manufacturer of LCD panels. > > >> https://www.densitron.com > > >> > > >> Signed-off-by: Marek Vasut <ma...@denx.de> > > >> Cc: Guido Günther <a...@sigxcpu.org> > > >> Cc: Jagan Teki <ja...@amarulasolutions.com> > > >> Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com> > > >> Cc: Linus Walleij <linus.wall...@linaro.org> > > >> Cc: Rob Herring <robh...@kernel.org> > > >> Cc: Sam Ravnborg <s...@ravnborg.org> > > >> Cc: Thierry Reding <thierry.red...@gmail.com> > > >> --- > > >> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > > >> 1 file changed, 2 insertions(+) > > >> > > >> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml > > >> b/Documentation/devicetree/bindings/vendor-prefixes.yaml > > >> index 88859dd4040ee..6277240536b44 100644 > > >> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > > >> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > > >> @@ -312,6 +312,8 @@ patternProperties: > > >> description: Dell Inc. > > >> "^delta,.*": > > >> description: Delta Electronics, Inc. > > >> + "^densitron,.*": > > > > > > How about "dsn", to follow the practice of using stock names as vendor > > > prefixes ? > > > > Is there any benefit to that ? All I can see is that it's making DTS > > less clear and more difficult to read. It is easy to map "densitron" to > > "densitron" when it is spelled out like so in the DT, but it sure isn't > > immediately obvious that "dsn" means "densitron" without extra look up. > > And even that extra look up of "dsn" does not return densitron, but some > > woodworking company and other totally unrelated results. > > I don't know where that practice originates from, and if it's still the > recommended naming scheme these days. All I know is that it was the > recommended scheme at some point. I expect Rob will be able to tell > which name is best.
The other practice is using the website name minus .com or whatever. I would stick with that here. Rob