On Tue, 13 Oct 2020 at 15:13, Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> wrote: > > On Tue, Oct 13, 2020 at 01:22:32PM +0200, Ard Biesheuvel wrote: > > [...] > > > > > diff --git a/Documentation/arm64/arm-acpi.rst b/Documentation/arm64/arm-acpi.rst > > > > index 47ecb9930dde..947f5b5c45ef 100644 > > > > --- a/Documentation/arm64/arm-acpi.rst > > > > +++ b/Documentation/arm64/arm-acpi.rst > > > > @@ -205,6 +205,13 @@ devices available. This list of tables is not meant to be all inclusive; > > > > in some environments other tables may be needed (e.g., any of the APEI > > > > tables from section 18) to support specific functionality. > > > > > > > > +It is assumed that all DMA capable devices in the system are able to > > > > +access the lowest 4 GB of system memory. If this is not the case, an > > > > +IORT describing those limitations is mandatory, even if an IORT is not > > > > +otherwise necessary to describe the I/O topology, and regardless of > > > > +whether _DMA methods are used to describe the DMA limitations more > > > > +precisely. Once the system has booted, _DMA methods will take precedence > > > > +over DMA addressing limits described in the IORT. > > > > > > If this is a boot requirement it must be in ARM's official documentation, > > > first, not the kernel one. > > > > > > I understand this is an urgent (well - no comments on why bootstrapping > > > ACPI on Raspberry PI4 is causing all this fuss, honestly) fix but that's > > > not a reason to rush through these guidelines. > > > > > > I would not add this paragraph to arm-acpi.rst, yet. > > > > > > > Which documentation? ACPI compliance by itself is not sufficient for a > > system to be able to boot Linux/arm64, which is why we documented the > > requirements for ACPI boot on Linux/arm64 in this file. I don't think > > we need endorsement from ARM to decide that odd platforms like this > > need to abide by some additional rules if they want to boot in ACPI > > mode. > > I think we do - if we don't we should not add this documentation either. > > ACPI on ARM64 software stack is based on standardized HW requirements. > The sheer fact that we need to work around a HW deficiency shows that > either this platform should have never been booted with ACPI or the _HW_ > design guidelines (BSA) are not tight enough. > > Please note that as you may have understood I asked if we can implement > a workaround in IORT because that's information that must be there > regardless (and an OEM ID match in arch code - though pragmatic - > defeats the whole purpose), I don't think we should tell Linux kernel > developers how firmware must be written to work around blatantly > non-compliant systems. > This is not about systems being compliant or not, unless there is a requirement somewhere that I missed that all masters in the system must be able to access at least 32 bits of DMA. The problem here is that Linux/arm64 cannot deal with fully compliant systems that communicate their [permitted] DMA limitations via a _DMA method if this limitation happens to be that the address limit < 32 bits. The DMA subsystem can deal with this fine, only the default DMA zone sizing policy creates an internal issue where the DMA subsystem is not able to allocate memory that matches the DMA constraints. So the 'correct' fix here would be to rework the memory allocator so it can deal with arbitrary DMA limits at allocation time, so that any limit returned by a _DMA method can be adhered to on the fly. However, we all agree that the Raspberry Pi4 is not worth that effort, and that in the general case, SoCs with such limitations, even if they are compliant per the spec, are not worth the trouble of complicating this even more. So as a compromise, I think it is perfectly reasonable to require that systems that have such limitations communicate them via the IORT, which we can parse early, regardless of whether _DMA methods exist as well, and whether they return the same information. So this is not a requirement on arm64 ACPI systems in general. It is a requirement that expresses that we, as arm64 contributors/[co-]maintainers, are willing to cater for such systems if they implement their firmware in a particular way.
