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: > > 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@xxxxxxxxxxx> > > > > > > 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
