- Downgrade some CAM debug messages from _INFO to _DEBUG level;
- Add KASSERT for the case when we suspect incorrect CAM SIM initialization (using cam_sim_alloc() instead of cam_sim_alloc_dev());
- Use waiting version of xpt_alloc_ccb(), we are not in hurry;
- With the waiting version we cannot get NULL return, so remove the NULL check;
- In some csses, the name of mmcprobe_done has been written as mmc_probedone();
- Send AC_LOST_DEVICE if we, well, lost the device;
- Misc style(9) fixes.
Details
Details
- Reviewers
manu imp - Group Reviewers
cam - Commits
- rS363870: Minor cleanups in mmc_xpt.c
No functional changes apart from being a bit less chatty on boot now.
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 32596 Build 30052: arc lint + arc unit
Event Timeline
Comment Actions
I think this may be OK. The only real heart-burn I have is the xpt_async ...
| sys/cam/mmc/mmc_xpt.c | ||
|---|---|---|
| 408 | Since I'm in the area, I'd be tempted to fix this to match style(9) | |
| 412 | This races the timeout that's setup in at least dwmmc_attach. It's likely OK, though, then initialize things and then call this directly from the startup.... something to think about though... | |
| 415 | Are you allowed to block here? I didn't audit all the places this is called, but I think it's OK. | |
| 424 | I don't think this can actually ever fail. | |
| 1144 | Why do you need to do this here? Usually the SIM sends this when it detects that a periph that used to be there has departed. | |
| sys/cam/mmc/mmc_xpt.c | ||
|---|---|---|
| 412 | I don't see how this KASSERT races with anything -- it's here to prevent usage of cam_sim_alloc() (without _dev()) with MMCCAM drivers since it breaks SDIO bus. | |
| 415 | there are 4 call sites for this function and none happens in the interrupt context, so I guess it's fine. | |
| 424 | Well there are some calls to malloc(...,M_NOWAIT) deep inside the call stack, so I'd check the return code just in case, it's a good practice anyway. | |
| 1144 | Because we are doing this from the mmcprobe device code (which is effectively a SIM), and getting here means that the device has disappeared. | |
| sys/cam/mmc/mmc_xpt.c | ||
|---|---|---|
| 412 | It' is a good kassert, since it made me look and I found the races that I described which this KASSERT will detect on systems that are super-duper slow. Sorry if I wasn't clear about it... | |
| 424 | I agree with the check, but don't think we should report it here... | |
| 1144 | ah, so they do... I'd forgotten about that case... | |