Nice! Seems it may solve the problem like we have in dwmmc where some generic methods get overridden with device-specific actions.

• Address reviewer comments

In D25963#602721, @bz wrote:

Thank you SOOOOOOOOOOO MUCH!!!!

If this builds, commit it! It'll help a lot!

Add actual content here.

At the first glance I don't see anything weird wrt MMCCAM intergration; I agree that MMCCAM-related problems should be fixed in the follow-up commits and not here.
Regarding the partitions: it would be interesting to see the output of ls /dev/sdda* on MMCCAM kernel, probably the partitions got detected but not printed on boot.

• Remove excessive printf

• Fix style(9)

The support for this has been merged in -HEAD through other commits.
Some last bits are coming in https://reviews.freebsd.org/D25843.

Updated to output an error message if various allocation functions failed. Also, revert to using alloc_ccb() from alloc_ccb_nowait() since it's pretty fine to wait in the contexts where start_discovery() is executed.

LGTM with a couple of tiny comments. Thanks!

Addressed reviewer's comment about magic constant, added more comments.

• Move new fields to the end

Updated to use MMC_DATA_BLOCK_SIZE.

• Implement CMD53 block mode support for SDHCI and AllWinner-based boards
• Use the new MMC_DATA_BLOCK_SIZE
• Put blank before colon when printing command args

Try again

Reupload the change.

Updated; please take a look.

Killed CMD53-related changes, leaving only field changes.

Addressed comments

In D19779#424273, @imp wrote:

In D19779#424228, @kibab wrote:

In D19779#424220, @bz wrote:

This is missing files I think. The mmcreg.h structure changes are missing from this one. This won't compile.

Sorry, something has gone wrong with my tree. I will reupload.

IF you jhust added the block count and block size to the end, there's no need to rebuild camcontrol...

Added (hopefully) missing files.

In D19779#424220, @bz wrote:

This is missing files I think. The mmcreg.h structure changes are missing from this one. This won't compile.

Generally LGTM with a few nits.

In D19674#421509, @bz wrote:

I haven't convinced myself yet that these two extra fields are actually needed but meanwhile this is needed (independently). I'll put it into a proper review later tonight.

    Properly zero mmc_data structures in mmc_da.c
    With upcoming MMCCAM changes extra fields will otherwise contain garbage
    and yield unexpected or unhelpful results (hanging controllers and the like).

diff --git a/sys/cam/mmc/mmc_da.c b/sys/cam/mmc/mmc_da.c
index a2dbf949b40..6ec73a46050 100644
--- a/sys/cam/mmc/mmc_da.c
+++ b/sys/cam/mmc/mmc_da.c
@@ -843,6 +843,7 @@ mmc_send_ext_csd(struct cam_periph *periph, union ccb *ccb,
        struct mmc_data d;

        KASSERT(buf_len == 512, ("Buffer for ext csd must be 512 bytes"));
+       memset(&d, 0, sizeof(d));
        d.data = rawextcsd;
        d.len = buf_len;
        d.flags = MMC_DATA_READ;
@@ -988,6 +989,7 @@ mmc_sd_switch(struct cam_periph *periph, union ccb *ccb,
        struct mmc_data mmc_d;
        uint32_t arg;

+       memset(&mmc_d, 0, sizeof(mmc_d));
        memset(res, 0, 64);
        mmc_d.len = 64;
        mmc_d.data = res;
'''

• Use SDHCI_MAKE_BLKSZ() for calculating block size
• Initialize new fields of mmc_data properly
• Make block mode work

In D15955#421067, @bz wrote:

In D15955#420988, @manu wrote:

In D15955#420643, @kibab wrote:

In D15955#357900, @manu wrote:

Quoting myself :

The correct solution is implementing proper card insertion detection. This is, however, out of scope for this change. I'm just replicating the way it's implemented for mmc(4) in this driver, for now.

Yes and that's what I don't like, this is not the correct solution for this problem.

Ok, stupid me, has two questions:

(a) what would be proper card insertion detection here for this one? (I am battling a similar issue elsewhere currently)

(b) if the API gets changed, so it works without the aw_mmc_softc, the function gets put into a central place outside this driver, and then gets called, is that what you are asking @manu ?

Address comments from bz@

• Fix spacing

addressed reviewer comments

Sync Arcanist

• Address comments in D15892 wrt max_data setting and MIN(MAX_PHYS,...)
• MIN(MAXPHYS) for D15892

• locking fix for D15955

In D15955#357900, @manu wrote:

Quoting myself :

20:51 < manu> I'm not sure this is the right solution
20:52 < manu> it seems that it's cam only code
20:52 < manu__> so I don't understand why it's not in a generic function

In D15891#336175, @manu wrote:

This looks okay for me except one comment.
But due to the fact that I/We had a lot of problems with different revision of the hardware IP let me test on different SoC before commiting.
Also I won't set this review as accepted as I don't know anything about CAM.