sdhci_set_clock() compared the requested clock with slot->clock, which holds
the rate that the host driver actually applied. Some drivers do not apply
the requested rate: the RK3568 one maps the 400kHz identification frequency
to 375kHz. The two values then never match and every update_ios call goes
through SDHCI_SET_CLOCK() again, even when the clock did not change.
That ends in clk_set_freq(), which takes a sleepable lock, from the done
context of the mmc probe with the CAM locks held. With another thread
holding the clock topology lock this panics with "sleeping thread holds CAM
device lock".
Remember the last requested clock in a new field and compare against it.
Clear it wherever slot->clock is cleared so that a reset still forces an
update.
Tested on a Quartz64 Model A with an NVMe drive on the PCIe slot, where the
panic was seen: 5 cold boots out of 5 attached everything.