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.

In D13063#308254, @marius wrote:

In any case, I think support for busses is a must for MMCCAM due to eSD. Judging Linux code and commit messages I've read, designs with multiple eSDIO devices on a bus are real.

In D13064#307569, @markj wrote:

In D13064#307542, @kibab wrote:

In D13064#299460, @markj wrote:

In D13064#299426, @benno wrote:

Have you looked at markj's netdump branch? Would his lower-level UDP send routines be a better transport for the console messages?

That code is specifically designed to run after a panic, while this is not. Ideally netcons would be usable in either context, but I wouldn't consider that to be a gating feature.

Actually I need precisely that! Running UDP send after panic would help to see a panic message. What is the purpose of netdump branch, what are you developing there?

The aim is to make it possible to transmit kernel dumps after a panic. See the netdump.4 and dumpon.8 man pages in that branch. I've been meaning to get it into FreeBSD for a long time and would rather not hold it up to add new features now, as I'm basically ready to get it reviewed and merged, but I'd be happy to work on refactoring it for use by other subsystems afterwards.

Marius,
thanks for your review.
I have created separate issues for each of the point you've mentioned: https://github.com/kibab/freebsd/projects/1
Seems none of those are directly related to the scope of this particular change. Do you think it's fine to commit this code so that partition functionality is in -HEAD?

So, as I wrote in reply to the inline comment, supporting multiple MMC cards on the same bus is not something I would try to implement in the new stack, given that I have never seen any hardware with such setup and that the old stack AFAIK doesn't properly support this.
Apart from that, any comments?

In D13063#276864, @marius wrote:

In D13063#271753, @kibab wrote:

RCA = 2 is just because I need to send _some_ RCA to the card. So I chose to send 2, could also choose any other number :-)

Unlike SD prior to eSD, MMC is a bus which may have multiple children that in case of MMC require unique RCAs to be assigned. So while you may start with 2 for the first child, you need code which increments the RCA for additional children on the same bus.

In D13064#303809, @cem wrote:

Haven't done a thorough review, but will take another look when some of the outstanding issues are cleaned up.

In D13064#299460, @markj wrote:

In D13064#299426, @benno wrote:

Have you looked at markj's netdump branch? Would his lower-level UDP send routines be a better transport for the console messages?

That code is specifically designed to run after a panic, while this is not. Ideally netcons would be usable in either context, but I wouldn't consider that to be a gating feature.

This was added in r330674 by manu@