I managed to figure out that the card I was using had a hard pull-up on its RESET# line and required a fundamental reset. Simply driving it low then high again before loading the driver resolved my SDIO issues. The way the driver is written the reset-gpios dt prop doesn’t help here as the morse_hw_reset function isn’t called on an sdio_probe.
The device is working fine on an IMX8MP board as long as I use MORSE_SDIO_RW_ADDR_BOUNDARY_MASK=0xffff0004
Yes, this is frustrating, but I believe it’s not actually straightforward for the driver itself to do the reset cleanly as it won’t be loaded until it’s detected, and it won’t be detected until the reset has happened. Some options we’ve used in the past are to work around this in user space (as I imagine you’ve done - see our morsechipreset.sh script for an example), or modify your SDIO/MMC driver to toggle any necessary GPIOs before the probe (ideally by specifying them in device tree).
Glad to hear you resolved your issues @tharvey. And thanks again for your earlier contributions to this thread!
As @james.haggerty mentions, performing the reset in the driver probe can upset some mmc host controllers configured with a non-removable device property. We do have a patch floating around to add a reset to the driver if you’re happy to use something like broken-cd to poll for device presence.
There was some internal discussion around using an mmc-pwrseq-simple node to handle this reset instead. There were some quirks with the initial attempts, but I might revisit this again to be certain.