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, 21 May 2014 14:51:18 -0700
From:	Olof Johansson <olof@...om.net>
To:	Alexandre Belloni <alexandre.belloni@...e-electrons.com>
Cc:	Nicolas Ferre <nicolas.ferre@...el.com>,
	Boris BREZILLON <boris.brezillon@...e-electrons.com>,
	Arnd Bergmann <arnd@...db.de>,
	"arm@...nel.org" <arm@...nel.org>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	Wenyou Yang <wenyou.yang@...el.com>,
	Ludovic Desroches <ludovic.desroches@...el.com>
Subject: Re: [GIT PULL] at91: DT for 3.16 #2

On Wed, May 21, 2014 at 2:42 PM, Alexandre Belloni
<alexandre.belloni@...e-electrons.com> wrote:
> Hi,
>
> On 21/05/2014 at 14:11:05 -0700, Olof Johansson wrote :
>> > This directory is flat, the board names are chosen by companies and
>> > people that we do not control, a user tend to like finding his preferred
>> > board dtb file unchanged from a kernel revision to another...
>> > Well all this lead me to think that we don't have to loose too much time
>> > thinking about a new strict convention for this file naming or changing
>> > all this once again just for the sake of it.
>> >
>> > Other SoC maintainers beautifully designed from the beginning the naming
>> > scheme of their DT files, fine. AT91 did not and forgive me but when
>> > opening arch/arm/boot/dts/Makefile file and seeing some file names, I'm
>> > not ashamed. Moreover, now that I said to everybody since 3.10 to prefix
>> > their *board* name with "at91-", I have to say something else, I don't
>> > think it is worth it.
>>
>> I don't agree with everything above, but it's not worth arguing for the
>> sake of arguing. :) I think we can tweak what you're doing now and get
>> things to work well by merging new dts files with at91-<soc>-board.dts
>> as the name. As mentioned, don't worry about the existing files. This
>> shouldn't be a significiant change to what you've been telling people
>> since 3.10 to cause much confusion.
>>
>
> I'm not sure we should keep the at91 prefix. The sama5d3 series is not
> at91.

*headdesk* It's part of mach-at91. For all intents and purposes, the label fits.

> I would suggest using <soc>-<vendor>-<board> in the future, like what is
> done for mvebu, berlin and some omap3 and freescale boards. I would
> however make an exception for the evaluation kits and keep the current
> "<soc>ek" name (else we would get sama5d3-atmel-sama5d3ek).

Nack on this as a hard rule. As long as there's a vendor or (large
family) SoC prefix I don't care about the rest of the structure.
Really, let's not waste time on it at this time.

> I also got confused by the at91- prefix when looking for a few dts files
> but I think it is too late to rename now or maybe we could do it all at
> once for a long term release (provided we know which one it will be).
>
> For reference, the list of files that would need renaming:
> animeo_ip.dts
> at91-ariag25.dts
> at91-cosino.dtsi
> at91-cosino_mega2560.dts
> at91-foxg20.dts
> at91-qil_a9260.dts
> ethernut5.dts
> ge863-pro3.dtsi
> kizbox.dts
> mpa1600.dts
> pm9g45.dts
> tny_a9260.dts
> tny_a9263.dts
> tny_a9g20.dts
> usb_a9260.dts
> usb_a9263.dts
> usb_a9g20_common.dtsi
> aks-cdu.dts
> evk-pro3.dts
> at91-sama5d3_xplained.dts

The DTS name is somewhat irritating in that installers and other
environments (my own tester included) rely on file names. There's been
a bunch of discussion about this in the past, but at the end of the
day, you end up irritating people when you rename the resulting dtbs.

As long as we don't keep adding random names beyond those, we should be OK.


-Olof
--
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