#
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
|