On Tue, Dec 08, 2020 at 11:45:33AM +0100, Geert Uytterhoeven wrote: > Hi Greg, > > On Wed, Nov 25, 2020 at 9:53 AM Greg Kroah-Hartman > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Nov 25, 2020 at 09:38:50AM +0100, Rafał Miłecki wrote: > > > On 25.11.2020 09:23, Greg Kroah-Hartman wrote: > > > > On Wed, Nov 25, 2020 at 09:13:52AM +0100, Rafał Miłecki wrote: > > > > > From: Rafał Miłecki <rafal@xxxxxxxxxx> > > > > > > > > > > Hardware supported by bcm63xx is also used by BCM4908 SoCs family that > > > > > is ARM64. > > > > > > > > > > Signed-off-by: Rafał Miłecki <rafal@xxxxxxxxxx> > > > > > --- > > > > > drivers/tty/serial/Kconfig | 3 ++- > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig > > > > > index 28f22e58639c..6907c5b17a0e 100644 > > > > > --- a/drivers/tty/serial/Kconfig > > > > > +++ b/drivers/tty/serial/Kconfig > > > > > @@ -1133,7 +1133,8 @@ config SERIAL_TIMBERDALE > > > > > config SERIAL_BCM63XX > > > > > tristate "Broadcom BCM63xx/BCM33xx UART support" > > > > > select SERIAL_CORE > > > > > - depends on MIPS || ARM || COMPILE_TEST > > > > > + depends on MIPS || ARM || ARM64 || COMPILE_TEST > > Why not s/ARM64/ARCH_BCM4908/? > > > > > > > > > Why do we have an arch dependancy at all now? > > > > > > From my experience "depends" is often used to limit symbol visibility to > > > applicable platforms only. I don't think Broadcom has any x86, risc, etc. > > > platforms so it's useless there. > > > > > > As for testing driver compilation on unused arch-s I thought that's what > > > COMPILE_TEST is for. > > > > > > Am I wrong there? I'm afraid we don't have clear Documentation on that. > > > Please kindly point me to some info if I'm wrong. > > > > If COMPILE_TEST is working for this driver, then trying to restrict it > > to a specific arch is usually pointless and the arch dependency can be > > removed, keeping patches like this from having to be made over time to > > add it to new arches :) > > > > > > > + default ARCH_BCM4908 > > > > > > > > Really? I thought we were getting rid of these "ARCH_platform_type" of > > No we are not. Ok, I keep getting mixed signals here. > > > > things. That's what a defconfig file is for, right? > > FWIW, the arm64 defconfig file enables about everything, for all arm64 > platforms. Then why are there ARCH_platforms for arm64 systems? > > > I had to miss something, last time I checked Linus called defconfigs a > > > garbage and wanted to get rid of them: > > > https://lwn.net/Articles/391372/ > > > > > > There are also no platform defconfigs in arch/arm64/ at all. Should I > > > handle it with arch/arm64/Kconfig.platforms and "select SERIAL_BCM63XX"? > > > > I thought we were trying to get rid of arm64 "platforms" as well. My > > point being, why is this needed at all? > > To prevent asking the user about a driver that is completely useless for > the system(s) the user is compiling a kernel for. How do you "know" that given the huge number of different ip blocks in SoC systems these days? > Do you want to let distros compile all arm/arm64-only SoC drivers for x86, too? Sure, many have crossed over over the years and shown up there. But distro config owners are smarter than that, give them some credit :) thanks, greg k-h
