[inventor7777]

I am not (purposefully) granting them the benefit of the doubt.

In my comment I simply noted that the comments there are extremely anti-Apple yet without any solid arguments behind them, and I also noted that the whole thing is just because of an APFS flag which could be fixed from Asahi's side. The main reason I made the comment is because I am shocked at how poorly backed the arguments are.

As for Apple not helping the Linux team, why would they, or any major OEM? Apple is perfectly happy with https://github.com/apple/container

[bigyabai]

When Microsoft futzes with the MBR and locks out Linux users, we complain. When Apple futzes with the APFS partition flags, we complain. It's not that hard to understand.

> why would they, or any major OEM?

Apple Silicon doesn't expose any obvious ACPI-equivalent power management interface. Apple could very easily document that hardware without exposing proprietary devicetree drivers, but someone internally must love watching Asahi users suffer through cpuidle. There isn't likely to be advanced power management drivers for Apple Silicon on Linux within this decade.

At the very least, I think it's fair to expect Apple to document breaking iBoot changes. They don't have to, but they feed a dog's dinner to their power users when they don't.

[AKSF_Ackermann]

> There isn't likely to be advanced power management drivers for Apple Silicon on Linux within this decade.

Amazing levels of confidence, when per Asahi's last progress report, one exists already.

[bigyabai]

You should read the report, it basically repeats what I just said:

> The power management architecture on this platform is incredibly complex, and there are a lot of moving parts involved in making it all work. There is Power Manager (PMGR), which is responsible for the SoC’s power domains, but there is also the Power Management Processor (PMP), which does… stuff?

> The actual low-level details of how power is managed across the SoC are quite opaque. [...] PMP will not read these reports if it is not booted, and certain power management functionality will not work. We are not sure exactly what it does with this information, but it likely involves controlling Apple Fabric power and clocking, among other things.

> There is obviously still work to be done to reach macOS levels of idle and suspend time

I still do not think that we will get advanced power management equivalent to ACPI within this decade, unless Apple starts documenting stuff. It took Asahi six years to replace cpuidle on M1, we're going to be here for a while.