linux-kernel - Re: [RFC PATCH 0/1] Categorize ARM dts directory

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:   Tue, 29 Mar 2022 10:53:40 +1030
From:   "Andrew Jeffery" <andrew@...id.au>
To:     "H. Nikolaus Schaller" <hns@...delico.com>,
        Jonathan Neuschäfer <j.neuschaefer@....net>,
        "Ansuel Smith" <ansuelsmth@...il.com>
Cc:     "Rob Herring" <robh+dt@...nel.org>,
        "Krzysztof Kozlowski" <krzk+dt@...nel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        "OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-actions@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
        Linux-OMAP <linux-omap@...r.kernel.org>,
        linux-amlogic@...ts.infradead.org, linux-arm-kernel@...s.com,
        linux-aspeed@...ts.ozlabs.org,
        linux-rpi-kernel@...ts.infradead.org,
        chrome-platform@...ts.linux.dev, linux-renesas-soc@...r.kernel.org,
        linux-samsung-soc@...r.kernel.org,
        linux-stm32@...md-mailman.stormreply.com,
        kernel@...electronics.com, linux-mediatek@...ts.infradead.org,
        openbmc@...ts.ozlabs.org, linux-tegra@...r.kernel.org,
        linux-oxnas@...ups.io, linux-arm-msm@...r.kernel.org,
        linux-unisoc@...ts.infradead.org,
        linux-rockchip@...ts.infradead.org,
        linux-realtek-soc@...ts.infradead.org
Subject: Re: [RFC PATCH 0/1] Categorize ARM dts directory



On Tue, 29 Mar 2022, at 00:20, H. Nikolaus Schaller wrote:
>> Am 28.03.2022 um 15:21 schrieb Jonathan Neuschäfer <j.neuschaefer@....net>:
>> 
>> Or maybe bcm instead of broadcom. Not sure which is preferred by
>> Broadcom people.
>
> Maybe it should always follow the list of vendor prefixes as we are 
> talking about DTS?

+1 (if we're actually going to do this). That would neuter most the 
mistakes and discussion and can be extracted from the dts files 
themselves.

Andrew