linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Guenter Roeck <linux@roeck-us.net>, Arnd Bergmann <arnd@arndb.de>
Cc: taehyun cho <taehyun.cho@samsung.com>,
	balbi@kernel.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: dwc3: make USB_DWC3_EXYNOS independent
Date: Wed, 3 Mar 2021 11:38:39 +0100	[thread overview]
Message-ID: <20210303103839.it7grj3vtrdmngbd@kozik-lap> (raw)
In-Reply-To: <YD9lTjWc25Nn7jAR@kroah.com>

On Wed, Mar 03, 2021 at 11:30:38AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Mar 03, 2021 at 11:24:01AM +0100, Krzysztof Kozlowski wrote:
> > On 03/03/2021 03:26, taehyun cho wrote:
> > > 'ARCH_EXYNOS' is not suitable for DWC3_EXYNOS config.
> > > 'USB_DWC3_EXYNOS' is glue layer which can be used with
> > > Synopsys DWC3 controller on Exynos SoCs. USB_DWC3_EXYNOS'
> > > can be used from Exynos5 to Exynos9.
> > > 
> > > Signed-off-by: taehyun cho <taehyun.cho@samsung.com>
> > 
> > NACK because you ignored comments from March. Please respond to them instead
> > of resending the same patch.
> > 
> > Anyway, when resending you need to version your patches and explain the
> > differences. Please also Cc reviewers and other maintainers. I pointed out
> > this before:
> > scripts/get_maintainer.pl -f drivers/usb/dwc3/dwc3-exynos.c
> > 
> > The driver - in current form - should not be available for other
> > architectures. It would clutter other platforms and kernel config selection.
> > If you want to change this, you need to provide rationale (usually by adding
> > support to new non-Exynos platform).
> 
> No, these crazy "ARCH_FOO" things need to go away.  For systems that
> want to build "universal" kernels, why are they being forced to enable
> "ARCH_*" just so they can pick specific drivers?  That is not done on
> other architectures, why is ARM64 so "special" in this regard.
> 
> How do you "know" that these cores/devices are tied to specific ARCH_
> platforms?  We don't, so that dependency should not be there.
> 
> Just let any arch pick any driver if it can be built, you never know
> what it might be run on.  Removing ARCH_ dependencies in Kconfig files
> is a good thing, please do not discourage that from happening.

It's getting more generic topic, so let me Cc Arnd and Guenter (I think
once I discussed this with Guenter around watchdog).

This is so far component of a SoC, so it cannot be re-used outside of
SoC. Unless it appears in a new SoC (just like recent re-use of Samsung
serial driver for Apple M1). Because of the architecture, you cannot
build universal kernel without ARCH_EXYNOS. You need it. Otherwise the
kernel won't boot on hardware with DWC Exynos.

Since DWC Exynos won't work without ARCH_EXYNOS - the user will not get
any usable binary - I think all, or almost all, SoC specific drivers are
limited per ARCH. This limits the amount of choices for distro people
and other kernel configuring folks, so they won't have to consider
useless options.

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.

Best regards,
Krzysztof


  reply	other threads:[~2021-03-04  0:27 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 [this message]
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
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=20210303103839.it7grj3vtrdmngbd@kozik-lap \
    --to=krzk@kernel.org \
    --cc=arnd@arndb.de \
    --cc=balbi@kernel.org \
    --cc=gregkh@linuxfoundation.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).