Hi Greg, On Tue, Dec 8, 2020 at 12:02 PM Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Dec 08, 2020 at 11:45:33AM +0100, Geert Uytterhoeven wrote: > > 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> > > > > > > --- 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? To enable core infrastructure or quirks for a certain SoC or SoC family, and to have a symbol for individual drivers to depend on? To make it easier to configure a kernel suited for a specific system? Mostly, you can take arm64/defconfig, disable the ARCH_* guards for SoC families you're not interested in, and have a suitable kernel for your system. > > > > 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? E.g. by looking at which .dtsi files contain device nodes that have a compatible value that matches the list of compatible values in the driver. Most IP cores are only present on a fairly limited set of SoCs and SoC families. Designware IPs are the major exception. And I hope the driver author/maintainer has some knowledge here. > > 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 :) Let's repeat your question above: "How do they know that...?". I guess the driver developer knows better (read: needs much less investigation time) than the distro config owner. It's not just for distros. If we can make life easier for every single developer or user who configures a kernel, by just storing that information in the dependency system, I think that's a justification for doing that. And in fact we're already doing that in most subsystems. Serial seems to be the only one that wants to move in the other direction... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
