There also may be an issue if the default card used for detection goes through the full probe procedure and is registered on the root host AND the new host.  However, since the driver even being probed in the first place relies on the default state of the GPIO set by the bootloader, this implementation seems shaky to me.

Maybe there must be a new flag to prevent the code to go this way. I.e. if the mmc2 host is flagged as "mux-host-port" it should not do all the steps mentioned above but initialize the mux driver. And the mux driver must ensure that both ports being probed.

Another option is to register the tx02612 driver as a platform driver and link in the device_node in the dts in a method similar to the one below.  This way we can be sure the driver is always probed, regardless of the mmc handshake.

txs02612 {
     compatible = "ti,txs02612";
     select-gpio = <&gpio3 18 0>;    /* gpio3_82 soft-select */

     host = <&mmc2>;

     status = "disabled";
 };

Well, this is not the design patterns DT maintainers want to see. I had similar discussions with them e.g. for SGX or GPS. For GPS on the GTA04 we simply had a driver that referenced the UART where the GPS chip was connected to. Was working fine for 5 years - outside of mainline. But DTS maintainers demanded that the idea is that the processor is sitting like a spider in the net (or like an octopus)and going outwards is represented by child nodes. I.e. each interface is a "bus". Even an UART is a "bus", although you can only connect one client. And if a device is indirectly connected through some subsystem, the subsystem has to be a child node of the processor and the device a child of the subsystem.

Therefore I am quite sure that your proposal will never be accepted mainline (but we should ask Rob Herring).

Generally I have seen the tendency that drivers for new devices are first discussed from DTS perspective. So the first thing which is needed is a .yaml bindings document, then some DTS. And finally the driver code has to be adapted to make use of what it gets. It is no longer possible to fit the DTS to a quick and simple driver implementation.

With this sort of link, the mmc device_node can be grabbed using of_parse_phandle.  However, getting the device and then mmc_host from this device_node is not easy since the mmc subsystem doesn't currently provide a method of accessing host nodes from their of_node by iterating through the class devices like some other subsystems provide (ie gpio, fpga-mgr).  So far, I have not found a viable method to access the linked node as we don't have access to the correct resources within the mmc subsystem.  This method also poses the same issue exhibted by the first method, where the card may be registered on both the root host and the newly registered host.

It is possible by adding some list and registration code. There is a similar mechanism for referencing PHY devices.

Until I or someone else can find a safe and (hopefully) graceful solution to this issue,

IMHO it is complex and goes deeper into the MMC code. A big task for a small function and device...

I am proposing to simply disable the tx02612 driver and hardcode the mux to the eMMC for now with the following patch.

Hm. Why do you want to disable it completely? For me the switching script works as it should. It may be possible to have it part of the initrd so that a boot choice screen can allow the user to select to boot from eMMC or µSD. If we ever have a better txs02612 driver we can replace this.