On 25.11.2020 09:54, Greg Kroah-Hartman 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 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
things. That's what a defconfig file is for, right?
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?
I find it useful for getting working kernel config for buildoot. It's
simpler to look in arch/ than either:
1. Getting list of all required drivers manually (by looking at DT?)
2. Checking for config used by OpenWrt
3. Checking for config used by Linaro
4. Checking for config used by Foo
