[PATCH 18/20] arch: dts: Fix EHCI/OHCI DT nodes name

[Florian Fainelli]

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 at baikalelectronics.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 at vger.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