[PATCH] tty: serial: bcm63xx: allow building on ARM64

[PATCH] tty: serial: bcm63xx: allow building on ARM64

[Rafał Miłecki]

From: Rafał Miłecki <rafal@milecki.pl>

Hardware supported by bcm63xx is also used by BCM4908 SoCs family that
is ARM64.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
 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
+	default ARCH_BCM4908
 	help
 	  This enables the driver for the onchip UART core found on
 	  the following chipsets:
-- 
2.26.2

Re: [PATCH] tty: serial: bcm63xx: allow building on ARM64

[Greg Kroah-Hartman]

On Wed, Nov 25, 2020 at 09:13:52AM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
> 
> Hardware supported by bcm63xx is also used by BCM4908 SoCs family that
> is ARM64.
> 
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
>  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?

> +	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?

thanks,

greg k-h

Re: [PATCH] tty: serial: bcm63xx: allow building on ARM64

[Rafał Miłecki]

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@milecki.pl>
>>
>> Hardware supported by bcm63xx is also used by BCM4908 SoCs family that
>> is ARM64.
>>
>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>> ---
>>   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.


>> +	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"?

Re: [PATCH] tty: serial: bcm63xx: allow building on ARM64

[Greg Kroah-Hartman]

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@milecki.pl>
> > > 
> > > Hardware supported by bcm63xx is also used by BCM4908 SoCs family that
> > > is ARM64.
> > > 
> > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> > > ---
> > >   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?

thanks,

greg k-h

Re: [PATCH] tty: serial: bcm63xx: allow building on ARM64

[Rafał Miłecki]

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@milecki.pl>
>>>>
>>>> Hardware supported by bcm63xx is also used by BCM4908 SoCs family that
>>>> is ARM64.
>>>>
>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>>> ---
>>>>    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

Re: [PATCH] tty: serial: bcm63xx: allow building on ARM64

[Geert Uytterhoeven]

Hi Greg,

On Wed, Nov 25, 2020 at 9:53 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> 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@milecki.pl>
> > > >
> > > > Hardware supported by bcm63xx is also used by BCM4908 SoCs family that
> > > > is ARM64.
> > > >
> > > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> > > > ---
> > > >   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.

> > > things.  That's what a defconfig file is for, right?

FWIW, the arm64 defconfig file enables about everything, for all arm64
platforms.

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

Do you want to let distros compile all arm/arm64-only SoC drivers for x86, too?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: [PATCH] tty: serial: bcm63xx: allow building on ARM64

[Rafał Miłecki]

[Scroll down]

On 08.12.2020 11:45, Geert Uytterhoeven wrote:
> On Wed, Nov 25, 2020 at 9:53 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> 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@milecki.pl>
>>>>>
>>>>> Hardware supported by bcm63xx is also used by BCM4908 SoCs family that
>>>>> is ARM64.
>>>>>
>>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>>>> ---
>>>>>    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.
> 
>>>> things.  That's what a defconfig file is for, right?
> 
> FWIW, the arm64 defconfig file enables about everything, for all arm64
> platforms.
> 
>>> 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.
> 
> Do you want to let distros compile all arm/arm64-only SoC drivers for x86, too?

Could you suggest & send some Documentation on that so we have a global rule
instead of per-tree / per-maintainer preferences, please? I'd really
appreciate that.

Re: [PATCH] tty: serial: bcm63xx: allow building on ARM64

[Geert Uytterhoeven]

Hi Rafał,

On Tue, Dec 8, 2020 at 11:59 AM Rafał Miłecki <zajec5@gmail.com> wrote:
> Could you suggest & send some Documentation on that so we have a global rule
> instead of per-tree / per-maintainer preferences, please? I'd really
> appreciate that.

Thanks, good idea!

[PATCH 0/2] Documentation/kbuild: Document COMPILE_TEST and platform
dependencies
https://lore.kernel.org/r/20201208152857.2162093-1-geert+renesas@glider.be

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: [PATCH] tty: serial: bcm63xx: allow building on ARM64

[Greg Kroah-Hartman]

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@linuxfoundation.org> 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@milecki.pl>
> > > > >
> > > > > Hardware supported by bcm63xx is also used by BCM4908 SoCs family that
> > > > > is ARM64.
> > > > >
> > > > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> > > > > ---
> > > > >   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

Re: [PATCH] tty: serial: bcm63xx: allow building on ARM64

[Geert Uytterhoeven]

Hi Greg,

On Tue, Dec 8, 2020 at 12:02 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> 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@linuxfoundation.org> 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@milecki.pl>
> > > > > >
> > > > > > Hardware supported by bcm63xx is also used by BCM4908 SoCs family that
> > > > > > is ARM64.
> > > > > >
> > > > > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl>

> > > > > > --- 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@linux-m68k.org

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

[PATCH V2] tty: serial: bcm63xx: lower driver dependencies

[Rafał Miłecki]

From: Rafał Miłecki <rafal@milecki.pl>

Hardware supported by bcm63xx is also used by BCM4908 SoCs family that
is ARM64. In future more architectures may need it as well. There is
nothing arch specific breaking compilation so just stick to requiring
COMMON_CLK.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
V2: Just drop all ARCH_* dependencies. Thanks Greg!
---
 drivers/tty/serial/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 28f22e58639c..cc67f02f5c32 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1133,7 +1133,7 @@ config SERIAL_TIMBERDALE
 config SERIAL_BCM63XX
 	tristate "Broadcom BCM63xx/BCM33xx UART support"
 	select SERIAL_CORE
-	depends on MIPS || ARM || COMPILE_TEST
+	depends on COMMON_CLK
 	help
 	  This enables the driver for the onchip UART core found on
 	  the following chipsets:
-- 
2.26.2

Re: [PATCH V2] tty: serial: bcm63xx: lower driver dependencies

[Florian Fainelli]

On 11/25/2020 1:06 AM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
> 
> Hardware supported by bcm63xx is also used by BCM4908 SoCs family that
> is ARM64. In future more architectures may need it as well. There is
> nothing arch specific breaking compilation so just stick to requiring
> COMMON_CLK.
> 
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>

Acked-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian

Re: [PATCH V2] tty: serial: bcm63xx: lower driver dependencies

[Geert Uytterhoeven]

On Wed, Nov 25, 2020 at 10:08 AM Rafał Miłecki <zajec5@gmail.com> wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Hardware supported by bcm63xx is also used by BCM4908 SoCs family that
> is ARM64. In future more architectures may need it as well. There is
> nothing arch specific breaking compilation so just stick to requiring
> COMMON_CLK.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>

NAKed-by: Geert Uytterhoeven <geert+renesas@glider.be>

> ---
> V2: Just drop all ARCH_* dependencies. Thanks Greg!

Greg, please stop suggesting to make the user's life harder.

> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1133,7 +1133,7 @@ config SERIAL_TIMBERDALE
>  config SERIAL_BCM63XX
>         tristate "Broadcom BCM63xx/BCM33xx UART support"
>         select SERIAL_CORE
> -       depends on MIPS || ARM || COMPILE_TEST
> +       depends on COMMON_CLK
>         help
>           This enables the driver for the onchip UART core found on
>           the following chipsets:

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: [PATCH V2] tty: serial: bcm63xx: lower driver dependencies

[Rafał Miłecki]

On 08.12.2020 11:47, Geert Uytterhoeven wrote:
> On Wed, Nov 25, 2020 at 10:08 AM Rafał Miłecki <zajec5@gmail.com> wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> Hardware supported by bcm63xx is also used by BCM4908 SoCs family that
>> is ARM64. In future more architectures may need it as well. There is
>> nothing arch specific breaking compilation so just stick to requiring
>> COMMON_CLK.
>>
>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> 
> NAKed-by: Geert Uytterhoeven <geert+renesas@glider.be>

I'm happy to fix that once maintainers agree on how to handle deps like
that and ideally we have if officially documented.

Re: [PATCH] tty: serial: bcm63xx: allow building on ARM64

[Florian Fainelli]

On 11/25/20 12:13 AM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
> 
> Hardware supported by bcm63xx is also used by BCM4908 SoCs family that
> is ARM64.
> 
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>

If this ends up being the approach chosen:

Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian