linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>,
	Guenter Roeck <linux@roeck-us.net>,
	taehyun cho <taehyun.cho@samsung.com>,
	Felipe Balbi <balbi@kernel.org>,
	USB list <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] usb: dwc3: make USB_DWC3_EXYNOS independent
Date: Wed, 3 Mar 2021 20:40:08 +0100	[thread overview]
Message-ID: <CAK8P3a3_u-FdPKNtAZdZHKY2EAk+qhg1GQHV4dsnuGV4+LawgQ@mail.gmail.com> (raw)
In-Reply-To: <YD+8q/hSWNKQS1tE@kroah.com>

On Wed, Mar 3, 2021 at 5:43 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.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

  parent reply	other threads:[~2021-03-04  0:28 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20210303022537epcas2p1b85ab825ceca3a411a177cc1af8a2c7b@epcas2p1.samsung.com>
2021-03-03  2:26 ` [PATCH] usb: dwc3: make USB_DWC3_EXYNOS independent taehyun cho
2021-03-03 10:24   ` Krzysztof Kozlowski
2021-03-03 10:30     ` Greg Kroah-Hartman
2021-03-03 10:38       ` Krzysztof Kozlowski
2021-03-03 11:01         ` Krzysztof Kozlowski
2021-03-03 12:54         ` Arnd Bergmann
2021-03-03 14:05         ` Greg Kroah-Hartman
2021-03-03 14:56           ` Guenter Roeck
2021-03-03 15:09             ` Greg Kroah-Hartman
2021-03-03 15:46               ` Krzysztof Kozlowski
2021-03-03 16:33                 ` Arnd Bergmann
2021-03-03 16:43                   ` Greg Kroah-Hartman
2021-03-03 16:49                     ` Krzysztof Kozlowski
2021-03-03 16:50                       ` Krzysztof Kozlowski
2021-03-03 16:56                       ` Greg Kroah-Hartman
2021-03-03 19:40                     ` Arnd Bergmann [this message]
2021-03-03 15:44           ` Krzysztof Kozlowski
2021-03-03 17:51           ` Arnd Bergmann
2021-03-03 13:12     ` taehyun cho
2021-03-03 13:15       ` Krzysztof Kozlowski
     [not found] <taehyun cho>
     [not found] ` <CGME20210208112816epcas2p43777bb9740f7307e38cb534f01099126@epcas2p4.samsung.com>
2021-02-08 11:29   ` taehyun cho
2021-02-08 11:39     ` Greg Kroah-Hartman
     [not found] ` <CGME20210208114447epcas2p3507f22a555355ac7710c5ca220853e0e@epcas2p3.samsung.com>
2021-02-08 11:45   ` taehyun cho
2021-02-08 11:57     ` Greg Kroah-Hartman
2021-02-08 13:05     ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAK8P3a3_u-FdPKNtAZdZHKY2EAk+qhg1GQHV4dsnuGV4+LawgQ@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=balbi@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=taehyun.cho@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).