linux-kernel - Re: [PATCH] usb: dwc3: make USB_DWC3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 3 Mar 2021 11:30:38 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Krzysztof Kozlowski <krzk@...nel.org>
Cc:     taehyun cho <taehyun.cho@...sung.com>, balbi@...nel.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: dwc3: make USB_DWC3_EXYNOS independent

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@...sung.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.

thanks,

greg k-h