Grundsatzfrage USB Mapping

Das grundsätzliche Konzept des USB Mappings besteht darin die Anzahl (und nur die) der nutzbaren USB Ports auf ein, für die Belange von macOS, verträgliches Maß zu reduzieren. Apple hat in seinem Betriebssystem ein Limit von 15 aktiven USB Ports pro USB Controller etabliert wobei es hierbei keine Rolle spielt ob der Port tatsächlich verbunden und somit nutzbar ist oder nicht. Ein USB Controller kann eine Vielzahl von Ports in sich vereinen von denen einige nach außen geführt sind, andere nur intern benutzt werden (onBoard Header, PCIe Steckplatz) und manche auch gar nicht. MacOS kümmert sich hierbei nicht darum ob der Port genutzt ist oder nicht sondern stellt einfach stumpf und stur die ersten 15 verfügbaren Ports pro Controller zur Verfügung...

Das Mapping als solches ist also kein Allheilmittel sondern dient dazu die USB Ports, die man in Hardware hat und nutzen möchte, auch nutzbar zu machen nicht mehr und nicht weniger. Was die Anzahl der Ports pro Controller angeht gilt das ein USB2 Port als ein Port zählt ein USB3 Port als zwei denn er vereint einen USB2 und einen USB3 Port in einer Buchse. Der Typ gibt an wie der Port behandelt werden soll (hat vor allem für das Powermanagement Relevanz). Alle Ports die verfügbar sind um von außen ein Gerät daran anzuschließen sind mit dem Typ USB2 oder USB3 oder im Falle von USB-C eben als USB-C zu deklarieren Ports die intern dauerhaft mit Systemgeräten verbunden sind (BT, WebCam beim Laptop) sind als Intern zu deklarieren. Die USBToolBox erkennt das aber in aller Regel sehr zuverlässig von allein.

Wie schon erwähnt ist das Mapping kein Allheilmittel schon grad gar nicht für Probleme die gar nichts mit dem USB Bus zu tun haben. Du schreibst von Problemen mit WIFI (PCIe) und deinem Touchpad (I2C) beides kümmert sich aber mal so ganz und gar nicht um den USB Bus sprich beide Problemfelder stehen in keinem Zusammenhang mit USB oder dessen, möglicherweise unsauberen, Portmappings. Gerade das Touchpadthema kann nervig werden weil I2C und in dem Zusammenhang das GPIO Pinning nicht unbedingt trivial ist. Für I2C sind oft gerne auch mal umfangreichere Eingriffe ins ACPI notwendig um eine Basis zu schaffen mit der VoodooI2C auf der einen und macOS auf der anderen Seite sauber zusammenarbeiten. Ein erster Schritt in diese Richtung wäre das einbinden der SSDT-GPIO.aml sofern nicht schon geschehen damit VoodooI2C etwas hat an das es sich binden kann...

Das liegt eher daran das der Treiber dann ein Reset bekommt...

Du musst Dir das so vorstellen der Treiber (VoodooI2C) kennt zwei Betriebsarten einmal das GPIO Pinning und einmal den Polling Mode. Der normale Modus ist das Pinning in dem Modus sitzt der Treiber auf dem I2C Bus und lauscht auf Nachrichten auf dem Bus für die er zuständig ist. Wenn Du zum Beispiel das Trackpad bedienst gibt das eine Meldung dazu auf den Bus und der Treiber reagiert entsprechend. Damit das Funktioniert muss der Treiber wissen auf welche Nachrichten er lauschen muss (Die Geschichte mit dem ACPI Krams). Weil das mit dem Pinning oft auf Hackintoshes eben nicht so richtig funktioniert gibt es das Polling hier sitzt der Treiber nicht passiv auf dem Bus und wartet sondern hier pingt er aktiv den Bus nach Änderungen (kannst Du Dir so vorstellen wie die Kinder auf dem Rücksitz bei einer langen Autofahrt getreu dem Motto "Wie lange noch, sind wir bald da, ich hab Hunger, ich muss mal..."), Der Polling Mode ist eher als eine Art Safe Mode gedacht und weniger für den Dauerbetrieb. Wenn Dein Trackpad nun den Dienst einstellt dann weil der Treiber sich verhaspelt hat. Durch das anstecken einer Maus (HID Device) an den USB Port wird der ganze Spaß einmal auf null gesetzt und es kann wieder von vorne losgehen.

Du müsstest perspektivisch halt dafür Sorge tragen das die ACPI Geschichten in Ordnung kommen. Einen Einsprung dazu hatte ich Dir ja schon gegeben mit der SSDT-GPIO.aml...