lkml.org 
[lkml]   [2019]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/7] al-msi: Rename driver and add support for ACPI
On Sun, 31 Mar 2019 13:34:08 +0100,
Hanna Hawa <hhhawa@amazon.com> wrote:
>
> This series includes three major changes:
> 1. IOMMU DMA mapping MSI message fix.
> 2. Re-name the AL-MSIx driver to new name convention.
> 3. Add ACPI support for the driver.
>
> Alpine is the name of the SoC family, while AL stands for Annapurna
> Labs. Rename to the latter since the driver will appear in other SoC
> families other than Alpine.
>
> The AL-MSIx controller is not standard, is not included in the UEFI
> specification, and will not be added. The driver ACPI binding is
> performed when the following conditions are true:
> - OEM ID is AMAZON
> - MADT table type is 0x80 (part of the OEM reserved range).

[+Lorenzo, as the arm64 ACPI maintainer]

So you're happy to explicitly violate the letter of the specification?
That's not really going to fly. We've pushed back on such things in
the past (MBIGEN, XGene MSI controller), and I don't see any
compelling reason to change our tune.

> GICv2m driver is called from context of parent interrupt controller,
> which ensures that the parent interrupt domain exists and holds valid
> information. As calling AL-MSIx driver from GICv3 driver would not make
> sense, a new API was added, to get the GSI IRQ domain that was registered
> by GICv3 driver in the ACPI framework.

What does this mean? Either your system has a GICv2m or it has a
GICv3. Please explain what this is all about.

Thanks,

M.

--
Jazz is not dead, it just smell funny.

\
 
 \ /
  Last update: 2019-04-01 04:02    [W:0.244 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site