Skip to content

Conversation

tuna-f1sh
Copy link
Contributor

@tuna-f1sh tuna-f1sh commented Sep 8, 2025

I also wanted access to card CID (#66460) so added a disk ioctl command to retrieve this - cached in sd_card struct rather than stack in card_read_cid.

Some option questions/opinions:

  • Should I re-order and re-number commands so it appears before INIT/DEINIT? Just tidier before CTRL commands I guess.
  • The struct sd_cid could be behind the CONFIG_SDMMC_STACK.. guard since it's only used in this case.
  • Even cleaner, could just return cid_raw since it's read in all configurations (or another command to get this)? I have to admit, I don't fully understand why the raw value is always read but only decoded with SDMMC and otherwise discarded.

@decsny
Copy link
Member

decsny commented Sep 8, 2025

what is the use case where you need the card ID?

@tuna-f1sh
Copy link
Contributor Author

tuna-f1sh commented Sep 8, 2025

Same as #66460: it's often useful in logging devices to capture the CID data for traceability. Serial number can be used to track the same card between devices/if it's swapped. Manufacturer ID, product ID, application ID and date can be used to identify bad cards or a failing batch.

decsny
decsny previously approved these changes Sep 15, 2025
Copy link
Contributor

@danieldegrasse danieldegrasse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't feel too strongly about this, but the CID was originally not placed in the SD card structure to reduce RAM utilization. I'd rather we didn't cache it, and instead read it from the card when an IOCTL was issued.

@decsny decsny dismissed their stale review September 18, 2025 16:25

agree with daniel

@tuna-f1sh
Copy link
Contributor Author

tuna-f1sh commented Sep 19, 2025

Thanks. I've pushed another commit considering this (can fixup once happy):

  • Removed the cached decoded CID struct.
  • Changed card_read_cid to take pointer to CID register to fill. Allows the IOCTL function to use it alongside the initialisation code.
  • To keep things simple, changed the IOCTL command so that it fills the raw CID register to the passed (void*) buf rather than doing the decode too. It prevents having to create a uint32_t cid[4] on stack in the IOCTL function and I figured a user reading this should probably know what the CID register contains and do their own decoding for the application's specific usage.

This means there should be no changes to RAM usage. Could expose the sdmmc_decode_cid rather than it being static inline but probably better to leave it to the user application.

@tuna-f1sh tuna-f1sh force-pushed the disk-io-get-cid branch 2 times, most recently from 81e838c to 12a0109 Compare September 19, 2025 08:58
CID (card id register) can be useful to application for traceability of SD
cards.

Adds disk ioctl command to get the CID data that is read at initialisation.
The struct sd_cid is moved to sd_card so that it can be read and retrieved
by card_ioctrl.

Signed-off-by: John Whittington <[email protected]>
CID (card id register) can be useful to application for traceability of SD
cards (zephyrproject-rtos#66460).

Adds disk ioctl command to get the CID data that is read at initialisation.

Changes the card_read_cid function to take pointer to cid register so that
the ioctl command can utilize with the passed user buf. Updated
calling functions to pass this pointer.

Signed-off-by: John Whittington <[email protected]>
@tuna-f1sh
Copy link
Contributor Author

Re-based to main

Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants