linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Arnd Bergmann <arnd@arndb.de>
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 17:43:23 +0100	[thread overview]
Message-ID: <YD+8q/hSWNKQS1tE@kroah.com> (raw)
In-Reply-To: <CAK8P3a2TAZELiqzy8Xv8hKvZwM6_+rF5OW9_AkP2TBoDRS3skQ@mail.gmail.com>

On Wed, Mar 03, 2021 at 05:33:46PM +0100, Arnd Bergmann wrote:
> On Wed, Mar 3, 2021 at 4:46 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On 03/03/2021 16:09, Greg Kroah-Hartman wrote:
> > > On Wed, Mar 03, 2021 at 06:56:38AM -0800, Guenter Roeck wrote:
> > >> On 3/3/21 6:05 AM, Greg Kroah-Hartman wrote:
> > >> [ ... ]
> > >>>> Anyway, that's the convention or consensus so far for entire SoC. If we
> > >>>> want to change it - sure, but let's make it for everyone, not for just
> > >>>> this one USB driver.
> > >>>
> > >>> Great, let's change it for everyone, I don't see a need for ARCH_*
> > >>> symbols except for people who want to make it simpler for their one
> > >>> board type.  And for that, use a defconfig.
> > >>>
> > >>
> > >> 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.
> > >
> > > Great, that's horrible to hear, so much for a "generic arm64 kernel
> > > binary" which I _thought_ was the goal.
> > >
> > > ugh, you would have thought we would have learned our lesson with
> > > arm32...
> 
> I have no idea what you are talking about here. arm64 kernels have
> always been generic, but you still need drivers for each piece of
> hardware, we unfortunately can't stop SoC vendors from reinventing
> the wheel with each new platform and then having to add yet another
> driver for each subsystems.

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 :)

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.

Anyway, this is just me as a driver subsystem maintainer being grumpy to
see ARCH_ dependancies on tiny little things like SoC-portions for
generic IP drivers.  Or on individual drivers (i.e. Samsung serial port
driver), where they don't belong at all.

So the overall goal of the original patch here is great, I want to see
that happen, as long as it's done in a way that does not ignore feedback
of arch maintainers...

thanks,

greg k-h

  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 [this message]
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
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=YD+8q/hSWNKQS1tE@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=arnd@arndb.de \
    --cc=balbi@kernel.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).