Presumably parts of upstream and downstream have been merged to get in this situation and there are several modules trying to do the same job. I want to raise a bug about this, but I have no idea what to write! Can somebody give me a brief guide as to why there are so many mmc modules, and which is the best and recommended to use? Thanks!

For general guidance, in the Raspberry Pi kernels we use the bcm2835-sdhost driver for the SD card or EMMC interface and bcm2835-mmc for SDIO to the WiFi chip. Upstream uses bcm2835 for SD and sdhci-iproc for SDIO. At some point we may replace the downstream drivers with patched versions of the upstream variants, but it hasn't happened yet.

Thanks for the DT dump - it confirms that you are using the downstream DTB which includes compatible strings for all four SD/MMC drivers, so configuring out or blacklisting is required to select the preferred drivers.

We are using more upstream drivers than we used to, but there are still a few differences. Aside from the SD drivers as discussed, the main difference is the USB driver - we use a heavily optimised dwc_otg driver that makes use of the ARM's FIQ to reduce the interrupt overhead - upstream is using the standard DWC2 driver. The remaining differences are confined to a few drivers that haven't been upstreamed yet - dpi, smi, etc. - and a few patches to otherwise upstreamed drivers, including add interrupt controller functionality to the AUX clock driver.

1. Is this normal behaviour? I didn't expect my kernel to load "thousands" of SD/MMC drivers which are causing trouble if i use default defconfig
2. do we need to edit dtb-files or use an overlay? In my dtb file i just found bcm2835-sdhost or bcm2835-sdhci is it neccessary to remove these definitions or mask them via overlay?

Device Tree is supposed to describe the hardware, not to tell the operating system which driver to use. This means that any (and all) drivers for a device must indicate that they support the standard "compatible" string. If there is more than one driver for a device (a slightly unusual situation), the only ways to select between them are by blacklisting or by not building the unwanted drivers. As has been noted, blacklisting only works for loadable modules, not built-in drivers, but building in multiple drivers for the same device is nonsensical.

Each of the two BCM2835 MMC/SD interfaces has two drivers in the downstream tree. For the Arasan MMC interface we have "sdhci-iproc" (upstream), and "bcm2835-mmc" (downstream), while for the Broadcom SDHOST interface there is "bcm2835" (upstream) and "bcm2835-sdhost" (downstream). These drivers could be consolidated so that, assuming we still want to keep the dowstream-specific features (mainly overclocking support and Device-Tree controlled debugging), the downstream drivers becomes patched versions of the standard upstream ones.

The standard Raspberry Pi defconfigs only enable the downstream drivers, so we see no clashes. You appear to have removed one of the spare MMC drivers and the non-FIQ-accelerated upstream USB driver with:

[ 3.781879] mmc-bcm2835 3f300000.mmc: could not get clk, deferring probe
[ 3.785342] sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe

I found a commit[2] from pelwell raising this def_info and dev_error if no clock is detected. the parent commit reverted early clock detection. I also found a lot of posts totaly unrealted with this issue, but with same clock messages. So maybe this is just normal...

The probe deferral mechanism is (in my opinion) an ugly workaround for the lack of a proper device dependency mechanism. The idea is that if a driver discovers that one of its required resources is not yet (*) available, it returns -517 (-EPROBE_DEFER) from its .probe function. When other devices are successfully probed, any devices in the deferred queue get retried.

Since there is no defined way to force a particular probe order, these deferrals are essentially impossible to avoid, so there is an argument for adding any message to the kernel log. However, the (*) above highlights an issue - it isn't possible to distinguish a device that hasn't yet been probed from one that has failed to probe or one that will never be probed, so the log message may be the only clue as to why the driver isn't starting as expected.

In other words, the "errors" or "warnings" are nothing to be concerned about.