History log of /freebsd-current/sys/cam/mmc/mmc_sim.c
Revision Date Author Comments
# 2ffd30f7 06-Nov-2023 Warner Losh <imp@FreeBSD.org>

cam: Remove left-over sys/cdefs.h in sys/cam

These weren't removed when $FreeBSD$ was removed. They aren't needed and
now are a style(9) nonconformity.

Sponsored by: Netflix


# 685dc743 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/


# 95ee2897 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/


# 44682688 12-Jan-2022 Andriy Gapon <avg@FreeBSD.org>

mmc_da: implement d_dump method, sddadump

sddadump has been derived from sddastart.

mmc_sim interface has grown a new method, cam_poll, to support polled
operation.

mmc_sim code has been changed to provide a sim_poll hook only if the
controller implements the new method. The hooks is implemented in terms
of the new mmc_sim_cam_poll method.
Additionally, in-progress CCB-s now have CAM_REQ_INPROG status to
satisfy xpt_pollwait().

mmc_sim_cam_poll method has been implemented in dwmmc host controller.

Reviewed by: manu, mav, imp
MFC after: 2 weeks
Relnotes: perhaps
Differential Revision: https://reviews.freebsd.org/D33843


# 18679ab1 15-Dec-2021 Andriy Gapon <avg@FreeBSD.org>

mmc_sim: fix setting of the mutex name

To quote the manual:
The pointer passed in as name and type is saved rather than the data
it points to. The data pointed to must remain stable until the mutex
is destroyed.

It seems that the type is actually copied, but the name is stored as
a pointer indeed.
mmc_cam_sim_alloc used a name stored on stack.
So, a corrupt mutex name would be reported.
For example:
lock order reversal: (sleepable after non-sleepable)
1st 0xd7285b20 <8A><C0><C0>P@<C1><D0>P@<C1>^D^A (aw_mmc_sim, sleep mutex) @ sys/cam/cam_xpt.c:2804

This change moves the name to struct mmc_sim.
Also, that name is used as the sim name as well.
Unused mtx_name variable is removed too.
The name buffer is reduced to 16 characters.

Reviewed by: manu, bz
MFC after: 10 days
Differential Revision: https://reviews.freebsd.org/D33412


# 8b37048b 13-Dec-2021 Andriy Gapon <avg@FreeBSD.org>

Revert "mmc_sim: fix setting of the mutex name"

This reverts commit df472af034e7726dea533ac7f44440dad4ba6a34.

The change hasn't been reviewed.


# df472af0 26-Nov-2021 Andriy Gapon <avg@FreeBSD.org>

mmc_sim: fix setting of the mutex name

To quote the manual:
The pointer passed in as name and type is saved rather than the data
it points to. The data pointed to must remain stable until the mutex
is destroyed.

It seems that the type is actually copied, but the name is stored as
a pointer indeed.
mmc_cam_sim_alloc used a name stored on stack.
So, a corrupt mutex name would be reported.
For example:
lock order reversal: (sleepable after non-sleepable)
1st 0xd7285b20 <8A><C0><C0>P@<C1><D0>P@<C1>^D^A (aw_mmc_sim, sleep mutex) @ /usr/devel/git/orange/sys/cam/cam_xpt.c:2804

This change moves the name to struct mmc_sim.
Also, that name is used as the sim name as well.
Unused mtx_name variable is removed too.


# 66c183f4 09-Jul-2021 Andriy Gapon <avg@FreeBSD.org>

mmc_cam_sim_default_action: do not touch the ccb after dispatching it

If MMC_SIM_CAM_REQUEST() is successful the ccb could be running or being
completed as the method returns. Modifying the ccb status could override
whatever status was already set by a MMC driver.

I am not sure what was the purpose of setting the status to CAM_REQ_INVALID
in the success path. I assume that it was to catch a possibility that the
ccb could be completed without its status explicitly set. So, I am keeping
the code, it's just moved to before the MMC_SIM_CAM_REQUEST call.

Without this change I was getting random and phantom EIO errors on Rock64
running off an SD card (dwmmc driver) plus occasional panics like:
Memory modified after free 0xffffa00003985800(2040) val=6 @ 0xffffa00003985854
panic: Most recently used by CAM CCB

MFC after: 1 week


# a72af82e 28-Jun-2021 Warner Losh <imp@FreeBSD.org>

cam: Fix GENERIC-MMCCAM build

Fix forgotten argument and type error. MMCCAM isn't enabled by default,
and I'd mistakenly thought it was, so these went undetected precommit.

Sponsored by: Netflix


# bd69852b 28-Jun-2021 Warner Losh <imp@FreeBSD.org>

mmc_sim: stop using cam_sim_alloc_dev

Use the vanilla flavor of cam_sim_alloc. Now that sdiob has been
converted to get the device_t from the cam_path, this data is no longer
necessary.

Reviewed by: scottl@
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D30856


# 3386347f 17-Jun-2021 Emmanuel Vadot <manu@FreeBSD.org>

mmc_sim: Make XPT_MMC_GET_TRAN_SETTINGS fully async

Sponsored by: Diablotin Systems


# af2253f6 29-Apr-2021 Emmanuel Vadot <manu@FreeBSD.org>

mmccam: Add two new XPT for MMC and use them in mmc_sim and sdhci

For the discovery phase of SD/eMMC we need to do some transaction in a async
way.
The classic CAM XPT_{GET,SET}_TRAN_SETTING cannot be used in a async way.
This also allow us to split the discovery phase into a more complete state
machine and we don't mtx_sleep with a random number to wait for completion
of the tasks.
For mmc_sim we now do the SET_TRAN_SETTING in a taskqueue so we can call
the needed function for regulators/clocks without the cam lock(s). This part is
still needed to be done for sdhci.
We also now save the host OCR in the discovery phase as it wasn't done before and
only worked because the same ccb was reused.

Reviewed by: imp, kibab, bz
Differential Revision: https://reviews.freebsd.org/D30038


# 47bde792 21-Apr-2021 Emmanuel Vadot <manu@FreeBSD.org>

mmccam: Add mmc_sim, a generic sim for mmc driver to use

This adds a generic sim that abstract a lot of what needs to be implemented
in a driver for mmccam support.
A new interface with three methods is added :

- mmc_sim_get_tran_settings: Use to get what the controller supports in term
of capabilities, freq etc ...
- mmc_sim_set_tran_settings: Use to change the speed/freq/etc of the
sdcard host controller
- mmc_sim_cam_request: Used for MMCIO requests

Differential Revision: https://reviews.freebsd.org/D27485
Reviewed by: kibab