> On Jun 9, 2023, at 7:31 AM, Andrew Jones <andrew.jones@xxxxxxxxx> wrote:
>
> On Fri, Jun 09, 2023 at 03:06:36PM +0100, Nikos Nikoleris wrote:
>> On 09/06/2023 08:21, Andrew Jones wrote:
>>> On Thu, Jun 08, 2023 at 10:24:11AM -0700, Nadav Amit wrote:
>>>>
>>>>
>>>>> On Jun 8, 2023, at 10:18 AM, Nadav Amit <nadav.amit@xxxxxxxxx> wrote:
>>>>>
>>>>>
>>>>> On May 30, 2023, at 9:09 AM, Nikos Nikoleris <nikos.nikoleris@xxxxxxx> wrote:
>>>>>
>>>>>>
>>>>>> +static void uart0_init_acpi(void)
>>>>>> +{
>>>>>> + struct spcr_descriptor *spcr = find_acpi_table_addr(SPCR_SIGNATURE);
>>>>>> +
>>>>>> + assert_msg(spcr, "Unable to find ACPI SPCR");
>>>>>> + uart0_base = ioremap(spcr->serial_port.address, spcr->serial_port.bit_width);
>>>>>> +}
>>>>>
>>>>> Is it possible as a fallback, is SPCR is not available, to UART_EARLY_BASE as
>>>>> address and bit_width as bit-width?
>>>>>
>>>>> I would appreciate it, since it would help my setup.
>>>>>
>>>>
>>>> Ugh - typo, 8 as bit-width for the fallback (ioremap with these parameters to
>>>> make my request clear).
>>>>
>>>
>>> That sounds reasonable to me. Nikos, can you send a fixup! patch? I'll
>>> squash it in.
>>>
>>
>> I am not against this idea, but it's not something that we do when we setup
>> the uart through FDT. Should ACPI behave differently? Is this really a
>> fixup? Either ACPI will setup things differently or we'll change the FDT and
>> ACPI path.
>
> Yeah, you're right. It's not really a fixup and I forgot that we abort
> when the DT doesn't have a uart node too. Let's leave this as is for now.
> We can do a follow patch which adds a config that says "use the early
> uart and don't bother looking for another" which we'd apply to both ACPI
> and DT.
Ok. I’ll add some option later to force it, perhaps if UART_EARLY_BASE is
different than the default.
