netdev - Re: [PATCH 10/13] ARM: dts: vt8500: Use generic compatibles for EHCI

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABjd4YxrqxAx9RpMcEtxoJm17BHMNUjD90EA9oHdGF8OoYTHiw@mail.gmail.com>
Date: Thu, 17 Apr 2025 09:54:15 +0400
From: Alexey Charkov <alchark@...il.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Andi Shyti <andi.shyti@...nel.org>, Rob Herring <robh@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Ulf Hansson <ulf.hansson@...aro.org>, 
	Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Uwe Kleine-König <ukleinek@...nel.org>, 
	Daniel Lezcano <daniel.lezcano@...aro.org>, linux-arm-kernel@...ts.infradead.org, 
	linux-i2c@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org, 
	netdev@...r.kernel.org, linux-pwm@...r.kernel.org
Subject: Re: [PATCH 10/13] ARM: dts: vt8500: Use generic compatibles for EHCI

On Thu, Apr 17, 2025 at 9:34 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>
> On 16/04/2025 10:21, Alexey Charkov wrote:
> > VIA/WonderMedia SoCs don't have anything special about their EHCI
> > controllers: in fact, vendor provided kernels just use the
>
> It does not have to do anything special - dedicated compatible properly
> describes the hardware.

My thinking was along the lines of "if the IP block is generic without
vendor-specific changes, then I'd rather describe it using the generic
compatible". But point taken, will drop this patch and extend the EHCI
binding instead.

> > generic PCI driver by emulating a virtual PCI bus with fixed MMIO
>
> PCI? But this is USB.

Yes, it is a pure platform USB EHCI controller. But the way the vendor
approached its enablement in their kernels was to code up a virtual
PCI bus with statically defined BARs which the common kernel code then
picked up and enumerated this platform EHCI controller as a PCI device
using the generic PCI EHCI controller driver. That was before the
mainline EHCI driver got support for platform devices, so apparently
they thought it's easier to do the virtual-PCI hack instead of
properly binding a platform device.

My point was that the hardware block has only ever been enabled with
generic EHCI code, so it must be indeed generic. There are no docs
available on this part, so various vendor code dumps and manual poking
are the only sources of information about the hardware.

> > mappings just to bind the existing driver as-is. So switch to the
> > generic compatible to save further additions to bindings.
> >
> > Note that these devices have only ever supported appended-DTB boot,
> > so changing the compatible should not affect any existing users.
>
> And other users of the DTS?
>
> I don't see benefits in this patch.

No problem, I will drop it and update the binding schema to include
the vendor-specific compatible instead.

Best regards,
Alexey