On Wed, Mar 03, 2021 at 11:38:39AM +0100, Krzysztof Kozlowski wrote:

On Wed, Mar 03, 2021 at 11:30:38AM +0100, Greg Kroah-Hartman wrote:

quoted

On Wed, Mar 03, 2021 at 11:24:01AM +0100, Krzysztof Kozlowski wrote:

quoted

On 03/03/2021 03:26, taehyun cho wrote:

quoted

'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 <redacted>

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.

So, to create a "generic" arm64 kernel, I need to go enable all of the
ARCH_* variants as well?  I thought we were trying to NOT do the same
mess that arm32 had for this type of thing.

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.

Why do we have ARCH_EXYNOS at all?  x86-64 doesn't have this, why is
arm64 somehow special here?

That's my complaint, it feels wrong that I have to go and enable all
different ARCH_ symbols just to build these drivers.  If people want
'default' configurations, then provide an exynos default config file,
right?

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've complained about this before, from a driver subsystem maintainer
point of view, this is crazy, drivers should be building and working on
everything.  Worst case, it's a cpu-type issue, to build or not build a
driver (i.e. s390, i386), best case it's a feature-type issue to depend
on (i.e. USB, TTY, etc.).  But never a "this one sub-architecture of
this one cpu"-type issue.  That feels crazy to me...

thanks,

greg k-h