Re: [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures

2018-01-08 Thread Prarit Bhargava
[Sorry everyone for the late response, I went away on vacation and pushed this
off until I returned.]

On 12/13/2017 07:45 AM, Lorenzo Pieralisi wrote:
> [+Mark, Graeme]
> 
> In $SUBJECT, s/avialable/available
> 
> On Mon, Dec 11, 2017 at 10:50:58AM -0500, Prarit Bhargava wrote:
>> Other architectures can use SPCR to setup an early console or console
>> but the current code is ARM64 specific.
> 
> I see nothing ARM64 specific in current code (apart from some
> ACPICA macros with an ARM tag in them) please explain to me
> what's preventing you to reuse current code on x86.

Ah, I didn't notice that.  I thought the ACPICA macros were ARM specific.  I'll
rework this patchset with that in mind.

> 
>> Change the name of parse_spcr() to acpi_parse_spcr().  Add a weak
>> function acpi_arch_setup_console() that can be used for arch-specific
>> setup.  Move flags into ACPI code.  Update the Documention on the use of
>> the SPCR.
>>
>> [v2]: Don't return an error in the baud_rate check of acpi_parse_spcr().
>> Keep ACPI_SPCR_TABLE selected for ARM64.  Fix 8-bit port access width
>> mmio value.  Move baud rate check earlier.
> 
> This does not belong in the commit log.

Yes, but some maintainers like to see what changed between v1 & v2.

> 
>> Signed-off-by: Prarit Bhargava 
>> Cc: linux-doc@vger.kernel.org
>> Cc: linux-ker...@vger.kernel.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux...@vger.kernel.org
>> Cc: linux-a...@vger.kernel.org
>> Cc: linux-ser...@vger.kernel.org
>> Cc: Bhupesh Sharma 
>> Cc: Lv Zheng 
>> Cc: Thomas Gleixner 
>> Cc: Ingo Molnar 
>> Cc: "H. Peter Anvin" 
>> Cc: x...@kernel.org
>> Cc: Jonathan Corbet 
>> Cc: Catalin Marinas 
>> Cc: Will Deacon 
>> Cc: "Rafael J. Wysocki" 
>> Cc: Timur Tabi 
>> ---
>>  Documentation/admin-guide/kernel-parameters.txt |   6 +-
>>  arch/arm64/kernel/acpi.c| 128 -
>>  drivers/acpi/Kconfig|   7 +-
>>  drivers/acpi/spcr.c | 175 
>> ++--
>>  drivers/tty/serial/earlycon.c   |  15 +-
>>  include/linux/acpi.h|  11 +-
>>  include/linux/serial_core.h |   2 -
>>  7 files changed, 184 insertions(+), 160 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
>> b/Documentation/admin-guide/kernel-parameters.txt
>> index 6571fbfdb2a1..0d173289c67e 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -914,9 +914,9 @@
>>  
>>  earlycon=   [KNL] Output early console device and options.
>>  
>> -When used with no options, the early console is
>> -determined by the stdout-path property in device
>> -tree's chosen node.
>> +[ARM64] The early console is determined by the
>> +stdout-path property in device tree's chosen node,
>> +or determined by the ACPI SPCR table.
>>  
>>  cdns,[,options]
>>  Start an early, polled-mode console on a Cadence
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index b3162715ed78..b3e33bbdf3b7 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -25,7 +25,6 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  
>>  #include 
>>  #include 
>> @@ -177,6 +176,128 @@ static int __init acpi_fadt_sanity_check(void)
>>  return ret;
>>  }
>>  
>> +/*
>> + * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
>> + * occasionally getting stuck as 1. To avoid the potential for a hang, check
>> + * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
>> + * implementations, so only do so if an affected platform is detected in
>> + * acpi_parse_spcr().
>> + */
>> +bool qdf2400_e44_present;
>> +EXPORT_SYMBOL(qdf2400_e44_present);
> 
> My eyes, this is horrible but it is not introduced by this patch. It
> would have been much better if:
> 
> drivers/tty/serial/amba-pl011.c
> 
> parsed the SPCR table (again) to detect it instead of relying on this
> horrible exported flag.

It looks like Timur & you had a discussion and the current consensus is to keep
the code the same.

> 
>> +
>> +/*
>> + * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY 
>> bit.
>> + * Detect them by examining the OEM fields in the SPCR header, similar to 
>> PCI
>> + * quirk detection in pci_mcfg.c.
>> + */
>> +static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
>> +{
>> +if (memcmp(h->oem_id, "QCOM  ", ACPI_OEM_ID_SIZE))
>> +return false;
>> +
>> +if (!memcmp(h->oem_table_id, "QDF2432 

Re: [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures

2017-12-14 Thread Lorenzo Pieralisi
On Thu, Dec 14, 2017 at 08:08:08AM -0600, Timur Tabi wrote:
> On 12/14/17 4:30 AM, Lorenzo Pieralisi wrote:
> >>I didn't want to put any ACPI code in amba-pl011.c, so putting it in spcr.c
> >>made the most sense.  I agree the global variable is ugly.  If you have a
> >>better idea, I'm all ears.
> 
> >I told you my idea. It could have been made easier by reusing the
> >ACPI_DECLARE_PROBE_ENTRY() mechanism.
> 
> Sorry, I don't mean to be difficult, but when did you tell *me* this idea of
> yours?  I don't see any email from you to me that mentions

I said that IMO it would have been better if the quirk was managed in
amba-pl011.c - you had your reasons not to do it, end of the story.

> ACPI_DECLARE_PROBE_ENTRY().  I've never even heard of that macro before.
> Please note that I'm not the original author of this code.

It is what it is, let's move on, we will keep this in mind if a similar
quirk is required.

Thanks,
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures

2017-12-14 Thread Lorenzo Pieralisi
On Wed, Dec 13, 2017 at 03:11:33PM -0600, Timur Tabi wrote:
> On 12/13/2017 06:45 AM, Lorenzo Pieralisi wrote:
> >>+/*
> >>+ * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
> >>+ * occasionally getting stuck as 1. To avoid the potential for a hang, 
> >>check
> >>+ * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
> >>+ * implementations, so only do so if an affected platform is detected in
> >>+ * acpi_parse_spcr().
> >>+ */
> >>+bool qdf2400_e44_present;
> >>+EXPORT_SYMBOL(qdf2400_e44_present);
> >
> >My eyes, this is horrible but it is not introduced by this patch. It
> >would have been much better if:
> >
> >drivers/tty/serial/amba-pl011.c
> >
> >parsed the SPCR table (again) to detect it instead of relying on this
> >horrible exported flag.
> 
> I didn't want to put any ACPI code in amba-pl011.c, so putting it in spcr.c
> made the most sense.  I agree the global variable is ugly.  If you have a
> better idea, I'm all ears.

I told you my idea. It could have been made easier by reusing the
ACPI_DECLARE_PROBE_ENTRY() mechanism.

> If it's any consolation, this erratum affects only 1.x silicon, which is
> technically pre-production (although a lot of people have them).  This
> work-around will eventually be reverted.

The sooner the better.

Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures

2017-12-13 Thread Timur Tabi

On 12/13/2017 06:45 AM, Lorenzo Pieralisi wrote:

+/*
+ * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
+ * occasionally getting stuck as 1. To avoid the potential for a hang, check
+ * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
+ * implementations, so only do so if an affected platform is detected in
+ * acpi_parse_spcr().
+ */
+bool qdf2400_e44_present;
+EXPORT_SYMBOL(qdf2400_e44_present);


My eyes, this is horrible but it is not introduced by this patch. It
would have been much better if:

drivers/tty/serial/amba-pl011.c

parsed the SPCR table (again) to detect it instead of relying on this
horrible exported flag.


I didn't want to put any ACPI code in amba-pl011.c, so putting it in 
spcr.c made the most sense.  I agree the global variable is ugly.  If 
you have a better idea, I'm all ears.


If it's any consolation, this erratum affects only 1.x silicon, which is 
technically pre-production (although a lot of people have them).  This 
work-around will eventually be reverted.



diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 46505396869e..9ae98eeada76 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -79,7 +79,12 @@ config ACPI_DEBUGGER_USER
  endif
  
  config ACPI_SPCR_TABLE

-   bool
+   bool "ACPI Serial Port Console Redirection Support"
+   default y if ARM64


You need to remove the selection in arch/arm64 then. Also, moving away
from a non-visible config may have consequences on ARM64, Graeme and
Mark are more familiar with the SPCR dependencies so please chime in.


I did raise this as a concern in the previous version of the patch.  I 
also think it should not be a selectable option.


Keeping the "select" does force SPCR to be enabled on ARM64 ACPI 
platforms, but if it's an option for x86, it should be an option for ARM.


--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures

2017-12-13 Thread Lorenzo Pieralisi
[+Mark, Graeme]

In $SUBJECT, s/avialable/available

On Mon, Dec 11, 2017 at 10:50:58AM -0500, Prarit Bhargava wrote:
> Other architectures can use SPCR to setup an early console or console
> but the current code is ARM64 specific.

I see nothing ARM64 specific in current code (apart from some
ACPICA macros with an ARM tag in them) please explain to me
what's preventing you to reuse current code on x86.

> Change the name of parse_spcr() to acpi_parse_spcr().  Add a weak
> function acpi_arch_setup_console() that can be used for arch-specific
> setup.  Move flags into ACPI code.  Update the Documention on the use of
> the SPCR.
> 
> [v2]: Don't return an error in the baud_rate check of acpi_parse_spcr().
> Keep ACPI_SPCR_TABLE selected for ARM64.  Fix 8-bit port access width
> mmio value.  Move baud rate check earlier.

This does not belong in the commit log.

> Signed-off-by: Prarit Bhargava 
> Cc: linux-doc@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux...@vger.kernel.org
> Cc: linux-a...@vger.kernel.org
> Cc: linux-ser...@vger.kernel.org
> Cc: Bhupesh Sharma 
> Cc: Lv Zheng 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: x...@kernel.org
> Cc: Jonathan Corbet 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: "Rafael J. Wysocki" 
> Cc: Timur Tabi 
> ---
>  Documentation/admin-guide/kernel-parameters.txt |   6 +-
>  arch/arm64/kernel/acpi.c| 128 -
>  drivers/acpi/Kconfig|   7 +-
>  drivers/acpi/spcr.c | 175 
> ++--
>  drivers/tty/serial/earlycon.c   |  15 +-
>  include/linux/acpi.h|  11 +-
>  include/linux/serial_core.h |   2 -
>  7 files changed, 184 insertions(+), 160 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index 6571fbfdb2a1..0d173289c67e 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -914,9 +914,9 @@
>  
>   earlycon=   [KNL] Output early console device and options.
>  
> - When used with no options, the early console is
> - determined by the stdout-path property in device
> - tree's chosen node.
> + [ARM64] The early console is determined by the
> + stdout-path property in device tree's chosen node,
> + or determined by the ACPI SPCR table.
>  
>   cdns,[,options]
>   Start an early, polled-mode console on a Cadence
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index b3162715ed78..b3e33bbdf3b7 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -25,7 +25,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #include 
>  #include 
> @@ -177,6 +176,128 @@ static int __init acpi_fadt_sanity_check(void)
>   return ret;
>  }
>  
> +/*
> + * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
> + * occasionally getting stuck as 1. To avoid the potential for a hang, check
> + * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
> + * implementations, so only do so if an affected platform is detected in
> + * acpi_parse_spcr().
> + */
> +bool qdf2400_e44_present;
> +EXPORT_SYMBOL(qdf2400_e44_present);

My eyes, this is horrible but it is not introduced by this patch. It
would have been much better if:

drivers/tty/serial/amba-pl011.c

parsed the SPCR table (again) to detect it instead of relying on this
horrible exported flag.

> +
> +/*
> + * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY bit.
> + * Detect them by examining the OEM fields in the SPCR header, similar to PCI
> + * quirk detection in pci_mcfg.c.
> + */
> +static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
> +{
> + if (memcmp(h->oem_id, "QCOM  ", ACPI_OEM_ID_SIZE))
> + return false;
> +
> + if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
> + return true;
> +
> + if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
> + h->oem_revision == 1)
> + return true;
> +
> + return false;
> +}
> +
> +/*
> + * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
> + * register aligned to 32-bit. In addition, the BIOS also encoded the
> + * access width to be 8 bits. This function detects this errata condition.
> + */
> +static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
> +{
> + bool 

Re: [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures

2017-12-13 Thread Will Deacon
[adding Lorenzo, Sudeep and Hanjun -- see Rafael's comment below]

On Wed, Dec 13, 2017 at 01:22:59AM +0100, Rafael J. Wysocki wrote:
> On Monday, December 11, 2017 4:50:58 PM CET Prarit Bhargava wrote:
> > Other architectures can use SPCR to setup an early console or console
> > but the current code is ARM64 specific.
> > 
> > Change the name of parse_spcr() to acpi_parse_spcr().  Add a weak
> > function acpi_arch_setup_console() that can be used for arch-specific
> > setup.  Move flags into ACPI code.  Update the Documention on the use of
> > the SPCR.
> > 
> > [v2]: Don't return an error in the baud_rate check of acpi_parse_spcr().
> > Keep ACPI_SPCR_TABLE selected for ARM64.  Fix 8-bit port access width
> > mmio value.  Move baud rate check earlier.
> > 
> > Signed-off-by: Prarit Bhargava 
> 
> This mostly affects ARM64, so ACKs from that side are requisite for it.
> 
> > Cc: linux-doc@vger.kernel.org
> > Cc: linux-ker...@vger.kernel.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux...@vger.kernel.org
> > Cc: linux-a...@vger.kernel.org
> > Cc: linux-ser...@vger.kernel.org
> > Cc: Bhupesh Sharma 
> > Cc: Lv Zheng 
> > Cc: Thomas Gleixner 
> > Cc: Ingo Molnar 
> > Cc: "H. Peter Anvin" 
> > Cc: x...@kernel.org
> > Cc: Jonathan Corbet 
> > Cc: Catalin Marinas 
> > Cc: Will Deacon 
> > Cc: "Rafael J. Wysocki" 
> > Cc: Timur Tabi 
> > ---
> >  Documentation/admin-guide/kernel-parameters.txt |   6 +-
> >  arch/arm64/kernel/acpi.c| 128 -
> >  drivers/acpi/Kconfig|   7 +-
> >  drivers/acpi/spcr.c | 175 
> > ++--
> >  drivers/tty/serial/earlycon.c   |  15 +-
> >  include/linux/acpi.h|  11 +-
> >  include/linux/serial_core.h |   2 -
> >  7 files changed, 184 insertions(+), 160 deletions(-)
> > 
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> > b/Documentation/admin-guide/kernel-parameters.txt
> > index 6571fbfdb2a1..0d173289c67e 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -914,9 +914,9 @@
> >  
> > earlycon=   [KNL] Output early console device and options.
> >  
> > -   When used with no options, the early console is
> > -   determined by the stdout-path property in device
> > -   tree's chosen node.
> > +   [ARM64] The early console is determined by the
> > +   stdout-path property in device tree's chosen node,
> > +   or determined by the ACPI SPCR table.
> >  
> > cdns,[,options]
> > Start an early, polled-mode console on a Cadence
> > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > index b3162715ed78..b3e33bbdf3b7 100644
> > --- a/arch/arm64/kernel/acpi.c
> > +++ b/arch/arm64/kernel/acpi.c
> > @@ -25,7 +25,6 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> >  
> >  #include 
> >  #include 
> > @@ -177,6 +176,128 @@ static int __init acpi_fadt_sanity_check(void)
> > return ret;
> >  }
> >  
> > +/*
> > + * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
> > + * occasionally getting stuck as 1. To avoid the potential for a hang, 
> > check
> > + * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
> > + * implementations, so only do so if an affected platform is detected in
> > + * acpi_parse_spcr().
> > + */
> > +bool qdf2400_e44_present;
> > +EXPORT_SYMBOL(qdf2400_e44_present);
> > +
> > +/*
> > + * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY 
> > bit.
> > + * Detect them by examining the OEM fields in the SPCR header, similar to 
> > PCI
> > + * quirk detection in pci_mcfg.c.
> > + */
> > +static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
> > +{
> > +   if (memcmp(h->oem_id, "QCOM  ", ACPI_OEM_ID_SIZE))
> > +   return false;
> > +
> > +   if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
> > +   return true;
> > +
> > +   if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
> > +   h->oem_revision == 1)
> > +   return true;
> > +
> > +   return false;
> > +}
> > +
> > +/*
> > + * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
> > + * register aligned to 32-bit. In addition, the BIOS also encoded the
> > + * access width to be 8 bits. This function detects this errata condition.
> > + */
> > +static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
> > +{
> > +   bool xgene_8250 = false;
> > +
> > +   if (tb->interface_type != 

[PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures

2017-12-11 Thread Prarit Bhargava
Other architectures can use SPCR to setup an early console or console
but the current code is ARM64 specific.

Change the name of parse_spcr() to acpi_parse_spcr().  Add a weak
function acpi_arch_setup_console() that can be used for arch-specific
setup.  Move flags into ACPI code.  Update the Documention on the use of
the SPCR.

[v2]: Don't return an error in the baud_rate check of acpi_parse_spcr().
Keep ACPI_SPCR_TABLE selected for ARM64.  Fix 8-bit port access width
mmio value.  Move baud rate check earlier.

Signed-off-by: Prarit Bhargava 
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-ser...@vger.kernel.org
Cc: Bhupesh Sharma 
Cc: Lv Zheng 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Jonathan Corbet 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: "Rafael J. Wysocki" 
Cc: Timur Tabi 
---
 Documentation/admin-guide/kernel-parameters.txt |   6 +-
 arch/arm64/kernel/acpi.c| 128 -
 drivers/acpi/Kconfig|   7 +-
 drivers/acpi/spcr.c | 175 ++--
 drivers/tty/serial/earlycon.c   |  15 +-
 include/linux/acpi.h|  11 +-
 include/linux/serial_core.h |   2 -
 7 files changed, 184 insertions(+), 160 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 6571fbfdb2a1..0d173289c67e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -914,9 +914,9 @@
 
earlycon=   [KNL] Output early console device and options.
 
-   When used with no options, the early console is
-   determined by the stdout-path property in device
-   tree's chosen node.
+   [ARM64] The early console is determined by the
+   stdout-path property in device tree's chosen node,
+   or determined by the ACPI SPCR table.
 
cdns,[,options]
Start an early, polled-mode console on a Cadence
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index b3162715ed78..b3e33bbdf3b7 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -177,6 +176,128 @@ static int __init acpi_fadt_sanity_check(void)
return ret;
 }
 
+/*
+ * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
+ * occasionally getting stuck as 1. To avoid the potential for a hang, check
+ * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
+ * implementations, so only do so if an affected platform is detected in
+ * acpi_parse_spcr().
+ */
+bool qdf2400_e44_present;
+EXPORT_SYMBOL(qdf2400_e44_present);
+
+/*
+ * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY bit.
+ * Detect them by examining the OEM fields in the SPCR header, similar to PCI
+ * quirk detection in pci_mcfg.c.
+ */
+static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
+{
+   if (memcmp(h->oem_id, "QCOM  ", ACPI_OEM_ID_SIZE))
+   return false;
+
+   if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
+   return true;
+
+   if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
+   h->oem_revision == 1)
+   return true;
+
+   return false;
+}
+
+/*
+ * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
+ * register aligned to 32-bit. In addition, the BIOS also encoded the
+ * access width to be 8 bits. This function detects this errata condition.
+ */
+static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
+{
+   bool xgene_8250 = false;
+
+   if (tb->interface_type != ACPI_DBG2_16550_COMPATIBLE)
+   return false;
+
+   if (memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
+   memcmp(tb->header.oem_id, "HPE   ", ACPI_OEM_ID_SIZE))
+   return false;
+
+   if (!memcmp(tb->header.oem_table_id, "XGENESPC",
+   ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 0)
+   xgene_8250 = true;
+
+   if (!memcmp(tb->header.oem_table_id, "ProLiant",
+   ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 1)
+   xgene_8250 = true;
+
+   return xgene_8250;
+}
+
+int acpi_arch_setup_console(struct acpi_table_spcr *table,
+   char *opts, char