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

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

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

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

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

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 t

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

show more ...

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 mut

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

show more ...

Revert "mmc_sim: fix setting of the mutex name"

This reverts commit df472af034e7726dea533ac7f44440dad4ba6a34.

The change hasn't been reviewed.

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 mut

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.

show more ...

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 sta

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

show more ...

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

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

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

show more ...

mmc_sim: Make XPT_MMC_GET_TRAN_SETTINGS fully async

Sponsored by: Diablotin Systems

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

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

show more ...

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 method

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

show more ...