linux-kernel - Re: [PATCH] usb: dwc3: make USB_DWC3

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] [day] [month] [year] [list]

Date:   Wed, 3 Mar 2021 20:40:08 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Krzysztof Kozlowski <krzk@...nel.org>,
        Guenter Roeck <linux@...ck-us.net>,
        taehyun cho <taehyun.cho@...sung.com>,
        Felipe Balbi <balbi@...nel.org>,
        USB list <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: dwc3: make USB_DWC3_EXYNOS independent

On Wed, Mar 3, 2021 at 5:43 PM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> On Wed, Mar 03, 2021 at 05:33:46PM +0100, Arnd Bergmann wrote:
> > > > On Wed, Mar 03, 2021 at 06:56:38AM -0800, Guenter Roeck wrote:
> > > >
> > > >> I don't think that will work in practice. Many ARCH_ symbols for various
> > > >> architectures contradict with each other. Almost all watchdog drivers
> > > >> only _build_ for specific platforms/architectures.
>
> That's fine, drivers are easy, but when I see comments like "ARCH_
> symbols contradict" that means that we can not make a generic kernel
> image.  Otherwise there's no contradiction :)

I think the key part of Guenter's sentence above was 'for various
architectures', which does not include arm64 or modern arm32 (armv6
or higher). On arm64 specifically, there is no platform specific code at
all that is not "just a driver".

32-bit ARM was in that category, and is mostly converted now to allow
combining arbitrary platforms within each of the three sets of slightly
incompatible CPUs (armv4/v4t/v5 vs armv6/v6k/v7/v7ve/v8 vs nommu
armv7-m).

powerpc did this first, but still has at least five groups of incompatible
CPU cores (8xx, 6xx, 4xx, e500 and everything 64-bit) with one or
more platforms in each.

mips is mostly incompatible between platforms, though there has been
some progress in the past few years to make some of the common ones
coexist.

m68k can have all mmu-based platforms (mac, atari, amiga, ...) coexist,
but the nommu platforms are all mutually exclusive. This is probably
not a problem because they are also highly resource constrained.

> And "new drivers" are almost always not really "new" as everyone uses
> much the same IP blocks.  As proof of this patch where the DWC3 IP block
> is being used by multiple SoC vendors.  To handle that, you split out
> the SoC-specific portions into sub-drivers, so that you can build a
> single image of the driver that works on multiple platforms.  Nothing
> new, we've been doing this for years, it's just that out-of-mainline SoC
> trees that think they can touch "core IP block code" break this all the
> time, which is what I am pushing back on.

In those cases where more than one or two platforms share an identical
driver, I agree we should just remove those dependencies. Across
subsystems, I think those are a small minority, but they are more common
in certain areas (usb, pci, networking) than others (clk, pinctrl, gpio).

I did find it very helpful to have the dependencies when I removed a
number of ARM platforms for linux-5.12 that had no remaining users ,
and I could just remove all the drivers along with those platforms.

I found one networking driver in that set that was a generic licensed
IP block that was probably shared by other platforms, but none of
those had upstream Linux support, so I removed it as well.

     Arnd