[PATCH v13 0/9] ACPI/IORT: Support for IORT RMR node

[Bjoern A. Zeeb]

On Fri, 24 Jun 2022, Shameerali Kolothum Thodi wrote:

Hi,

>> -----Original Message-----
>> From: Steven Price [mailto:steven.price at arm.com]
>> Sent: 17 June 2022 13:42
>> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi at huawei.com>;
>> linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org;
>> iommu at lists.linux-foundation.org
>> Cc: Linuxarm <linuxarm at huawei.com>; lorenzo.pieralisi at arm.com;
>> joro at 8bytes.org; robin.murphy at arm.com; will at kernel.org; wanghuiqiang
>> <wanghuiqiang at huawei.com>; Guohanjun (Hanjun Guo)
>> <guohanjun at huawei.com>; Sami.Mujawar at arm.com; jon at solid-run.com;
>> eric.auger at redhat.com; laurentiu.tudor at nxp.com; hch at infradead.org
>> Subject: Re: [PATCH v13 0/9] ACPI/IORT: Support for IORT RMR node
>>
>> On 15/06/2022 11:10, Shameer Kolothum wrote:
>>> Hi
>>>
>>> v12 --> v13
>>>   -No changes. Rebased to 5.19-rc1.
>>>   -Picked up tags received from Laurentiu, Hanjun and Will. Thanks!.
>>
>> You've already got my Tested-by tags, but just to confirm I gave this a
>> spin and it works fine.
>
> Thanks Steve.
>
> I think the series is now in a good shape to be merged.
>
> Hi Will/Robin,
>
> Appreciate, if you could please take a look at the remaining SMMU related
> patches(7-9) and provide your approval?
>
> Thanks,
> Shameer

First of all thanks to all of you for keeping this going.

I've read through most of this patch series and it doesn't read
like the best sunny days.

I do understand that there are incentives to get things right; sometimes
first make it work, then make it better? Running code often seems a
better alternative than wrong words on paper as users don't care about
the paper.  They only care if their hardware becomes a paperweight
because it's not working.

I was trying to find diplomatic words but the general problem has become
so much bigger than just this change as I am faced with the fact that
vendors are talking to give up maintaining Arm/ACPI and go back to FDT
exclusively, which I believe would be the wrong but an understandable
exit out of a roundabout.

For me this Arm/Linux/ACPI problem becomes double-impact, as I am not
even a Linux person.  And part of what Arm/ACPI was solving was the
any OS can just works on Arm hardware; for a while people were hoping
it could make FDT the next Flash; it just seems it'll not be because
people cannot get fixes or workarounds for real world problems into
Linux timely?

So a very polite but firm prod towards Cambridge from here as well in
the hope that you can make a big change to this world by helping not
to miss the next merge window/release leading to way bigger impact.
It would be rather sad to close the Arm/ACPI chapter for good but it
seems that we may be standing on the verge of it if things do not move
quick now and different in the future.  It'll certainly need change from
all sides but the good things is that at the end of the day we all want
to make the world a better place.

As I mentioned, I have no stakes in this Linux change.
I just care about Arm and ACPI because I saw light and a chance in it
and I would love to see it stay.
Let's all work together in one direction and make it a brighter future
for everyone.  Can we?  Are you in?


May God bless you and your work,
Bjoern