Re: [PATCH v1 01/16] arm/vpl011: rename virtual PL011 Kconfig option

[Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>]

On Thu Jul 17, 2025 at 9:58 PM CEST, dmkhn wrote:
> On Thu, Jul 17, 2025 at 05:43:22PM +0200, Alejandro Vallejo wrote:
>> On Tue Jun 24, 2025 at 9:24 AM CEST, dmkhn wrote:
>> > On Tue, Jun 24, 2025 at 08:13:08AM +0200, Orzel, Michal wrote:
>> >>
>> >>
>> >> On 24/06/2025 05:55, dmkhn@xxxxxxxxx wrote:
>> >> > From: Denis Mukhin <dmukhin@xxxxxxxx>
>> >> >
>> >> > Rename CONFIG_SBSA_VUART_CONSOLE to CONFIG_HAS_VUART_PL011.
>> >> Why? We emulate SBSA UART and not PL011. Despite the similarities (the 
>> >> former is
>> >> a subset of the latter) they are not the same. I find it confusing and 
>> >> drivers
>> >> for PL011 might not work with SBSA UART. Also, in the future we may want 
>> >> to
>> >> emulate full PL011 in which case it will be even more confusing.
>> >
>> > That's because the emulator is called vpl011, but yes, it is SBSA UART.
>> > I will adjust to SBSA, thanks!
>> >
>> >>
>> >> Also, why HAS_?
>> >
>> > My understanding is that HAS_ is the desired naming convention throughout 
>> > the
>> > code (not documented, though), e.g. all Arm UART drivers are gated by 
>> > HAS_XXX
>> > (e.g. arch/arm/platforms/Kconfig).
>> 
>> HAS_ is a non-selectable property dependent on the arch. Think HAS_PCI, or
>> HAS_EHCI, etc. IOW: HAS_X means "you may implement feature X on this arch",
>> which is why some options have X and HAS_X variants, where X is selectable
>> while HAS_X is not.
>
> Thanks; I will fix that.
>
> Jan explained the difference here [1] and [2]:
> [1] 
> https://lore.kernel.org/xen-devel/6d33355c-477f-4ef3-8f17-b7f1dd1164ce@xxxxxxxx/
> [2] 
> https://lore.kernel.org/xen-devel/a63ac9d5-152e-47b0-8169-bf470611c059@xxxxxxxx/
>
> It's just there's a lot of drivers (UARTs) which are selectable by the user 
> via
> HAS_ symbols (drivers/char/Kconfig)

IMO, HAS_IMX_LPUART should be selected by ARM_64, then IMX_LPUART would depend
on HAS_IMX_LPUART. I don't know how those (and you're right, there's lots) got
there. Same with NS16550, etc.

That allows to decouple the device from the architectures where it might be
found.

Cheers,
Alejandro