Entweder Method (_DSM) oder Method (XDSM) … aber wann welche?

XDSM ist ein dirty patch und macht nichts anderes als die Device Specific Method zu deaktivieren. Du könntest statt XDSM auch HEYY schreiben, würde das gleiche bewirken. Über _DSM Methoden kann man zB Properties einem Device mitgeben, die von Apples SW verarbeitet werden. Das geht aber nicht nur über _DSM Methoden sondern auch auf verschiedenen andere Wegen wie zB durch injection auf I/O Ebene, wie es zB WEG macht. Wenn du gerne DeviceProperties per _DSM injecten willst, dann kannst du das natürlich machen, ich würde dir aber dann stark davon abraten allgemeine Patches wie _DSM zu XDSM zu benutzen und stattdessen in allen Fällen in denen deine gewünschte DevProp-Injection aufgrund einer bereits vorhandenen _DSM nicht funktioniert, auf alternative Wege umzusteigen, wie zB auf die DeviceProperty Injection von OpenCore oder Clover. Viel Erfolg!

Mit dem Clover ACPI-Patch werden _ALLE_ _DSM-Methoden in deiner ACPI umbenannt. Das macht man üblicherweise dann, wenn man eigene _DSM-Methoden per SSDT bestimmten Devices zuordnen möchte, diese aber nicht geladen werden, wenn eben schon welche vorhanden sind. Die Umbenennung macht diese in der DSDT quasi "unbrauchbar", so das eigene per SSDT geladen werden können.

BTW, benötigst du den SBUS überhaupt? Wo kommen die Einträge her, aus einer SSDT?

Edit: der kuckuck war schneller …

Zitat von iPhoneTruth

Woran kann ich festmachen, ob ich den brauche? Online

Das weiß ich nicht. Ich sehe nur bei den Rechnern von Apple (ob MacMini, iMac(Pro), MacPro oder MacBook(Pro)) der letzten Jahre, dass Devices mit SMBS oder SBUS in der ACPI als Eintrag zwar vorhanden, aber nicht näher beschrieben sind und keine Treiber mehr dafür geladen werden – was man mit IORegistryExplorer sehen kann.

Auch bei dir lief der nun nicht mehr, kein Treiber geladen. Nur eben durch "Kosmetik" in der PCI-Liste sichtbar gemacht, was ebenfalls bei keinem Original der Fall ist. Und hatte es Auswirkungen auf dein System? Wenn nicht, kannst du auch den Inject per Kext entfernen. Natürlich lassen sich auch sinnvollere Eigenschaften als "AAPL,slot-name", "name" und "model" festlegen, dann wird das Device nicht so im Systembericht präsentiert, bekommt aber trotzdem seine weiteren Eigenschaften …

Das kommt auf das SMBios und die Hardware drauf an. Aber da müsste man mal tiefer graben und zB mit gezielten grep Befehlen Apples KernelExtensions durchforsten, um zu sehen welche Treiber von SBUS abhängig sind. Dann entweder die Treiber bereits so weit kennen, um zu wissen was sie in etwa tun (eindeutige Namen, bereits in der Community bekannt, etc) oder die Treiber soweit auseinander nehmen/reverse engineeren bis man weiß was der Treiber genau mit SBUS macht. Daraufhin dann sehen, ob man will, dass die abhängigen Treiber laden, ob die von ihnen ausgeführten Aktionen ausschlaggebend für Funktionen des gewählten SMBIOS sind, oder sinnvoll für die benutzte Hardware erscheinen, im letzteren Fall wieder SMBIOS Dependencies beachten (kann man einen Treiber eines vorhandenen SMBIOS laden, der auf die eigene HW passt? Lädt ein bestimmter Treiber nur bei Benutzung eines bestimmten SMBios?...) und dann gegebenfalls SBUS im ACPI so implementieren/faken, wie es beim passenden SMBios gemacht wird um die richtigen Treiber zu laden. Man sieht, das Ganze ist ziemlich kompliziert wenn man ins Detail geht und wir reden hier nur von einem einzigen, evtl sogar kosmetischen Treiber...