Phil Elwell

In other words: ``` dtoverlay=i2c-mux,pca9548,addr=0x74,base=40,disconnect_on_idle dtoverlay=i2c-mux,pca9548,addr=0x70,base=30,disconnect_on_idle ```

If you can access either mux successfully after a reboot but not then use the other then the deselection is not working (unless the problem is power related). @6by9 has...

By the way, it may be possible (as a diagnostic test only) to force the muxes to report or disable the attached buses: ``` $ i2cget -f -y 1 0x70...

I think your troubleshooting is good, but the results are showing that the deselection/disconnection is not working. Try accessing both muxes, but with `i2cset -f -y 1 0x70 0` and/or...

Something strange is happening when the firmware is applying the overlay - the idle-state value is coming through as -1 instead of -2. For now, try applying the overlays at...

Alternatively, download a modified version of the i2c-mux overlay from here: https://drive.google.com/file/d/1L8eY0GQVYd6R4926R13td9rcz9igQOj6/view?usp=sharing It uses a different way of encoding the same changes that avoids the problem (which I think is...

You shouldn't need to install it any more - just install the latest stable firmware: `sudo rpi-update stable`

Why are you singling out 6.1 for the USB_DWCOTG dependency problem? For me, the 6.6 kernel is the same.

See #6112. Note that this fixes the rpi-6.6.y tree. rpi-6.1.y is not being developed on, but these patches could be back-ported as being low risk.

69 million is a lot of interrupts for an idle UART - something is not working as it should. Judging by the names assigned to the GPIOs ("PIN3", etc.), this...