linux-kernel - Re: [PATCH 18/20] arch: dts: Fix EHCI/OHCI DT nodes name

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, 14 Oct 2020 11:41:17 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Serge Semin <Sergey.Semin@...kalelectronics.ru>
Cc:     Serge Semin <fancer.lancer@...il.com>,
        Mathias Nyman <mathias.nyman@...el.com>,
        Felipe Balbi <balbi@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh+dt@...nel.org>,
        Alexey Brodkin <abrodkin@...opsys.com>,
        Vineet Gupta <vgupta@...opsys.com>,
        Hauke Mehrtens <hauke@...ke-m.de>,
        Rafał Miłecki <zajec5@...il.com>,
        bcm-kernel-feedback-list@...adcom.com,
        Wei Xu <xuwei5@...ilicon.com>,
        Vladimir Zapolskiy <vz@...ia.com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        Paul Cercueil <paul@...pouillou.net>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Manu Gautam <mgautam@...eaurora.org>,
        Roger Quadros <rogerq@...com>,
        Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
        Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
        Neil Armstrong <narmstrong@...libre.com>,
        Kevin Hilman <khilman@...libre.com>,
        linux-arm-kernel@...ts.infradead.org,
        linux-snps-arc@...ts.infradead.org, linux-mips@...r.kernel.org,
        linuxppc-dev@...ts.ozlabs.org, linux-usb@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-stm32@...md-mailman.stormreply.com,
        linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH 18/20] arch: dts: Fix EHCI/OHCI DT nodes name

On 10/14/20 11:11 AM, Serge Semin wrote:
> On Wed, Oct 14, 2020 at 11:00:45AM -0700, Florian Fainelli wrote:
>> On 10/14/20 3:14 AM, Serge Semin wrote:
>>> In accordance with the Generic EHCI/OHCI bindings the corresponding node
>>> name is suppose to comply with the Generic USB HCD DT schema, which
>>> requires the USB nodes to have the name acceptable by the regexp:
>>> "^usb(@.*)?" . Let's fix the DTS files, which have the nodes defined with
>>> incompatible names.
>>>
>>> Signed-off-by: Serge Semin <Sergey.Semin@...kalelectronics.ru>
>>>
>>> ---
>>>
>>> Please, test the patch out to make sure it doesn't brake the dependent DTS
>>> files. I did only a manual grepping of the possible nodes dependencies.
>>
> 
>> Not sure how you envisioned these change to be picked up, but you may
>> need to split these changes between ARM/ARM64, MIPS and PowerPC at
>> least. And within ARM/ARM64 you will most likely have to split according
>> to the various SoC maintainers.
> 
> Hmm, I don't really know how it's going to be done in this case, but there must
> be a way to get the cross-platform patches picked up in general. For
> instance, see the patches like:
> 714acdbd1c94 arch: rename copy_thread_tls() back to copy_thread()
> 140c8180eb7c arch: remove HAVE_COPY_THREAD_TLS
> They touched the files from different files, but still have been merged in.

That situation is different, when a new facility is added and someone
has gone through the work of adding support for all architectures (or
nearly all of them), you want them to be merged in a way that limits
merge conflicts with other architecture changes.

Here you are fixing warnings, and each file you touch can clearly be
independently change from other files in the series without causing
merge conflicts. You are however creating the potential for merge
conflicts with other changes that the various SoC maintainers have
queued up.

> Maybe I should have copied these three patches to the "linux-arch@...r.kernel.org"
> list or some other mailing list...

Maybe Rob can queue them through his device tree repository, with the
ack of the various SoC maintainers...
-- 
Florian