On Wed, 6 Mar 2024 at 15:38, Linus Walleij linus.walleij@linaro.org wrote:
On Wed, Mar 6, 2024 at 3:22 PM Jorge Ramirez-Ortiz, Foundries jorge@foundries.io wrote:
I still cant grasp how "target_part = idata->rpmb->part_index" is helping in the design.
What happens when:
- EXT_CSD_PART_CONFIG_ACC_MASK > part_index > EXT_CSD_PART_CONFIG_ACC_RPMB
target_part now could be indicating a GP instead of an RPMB leading to failures.
- part_index <= EXT_CSD_PART_CONFIG_ACC_RPMB
loses the part_index value .
So part_index should be larger than EXT_CSD_PART_CONFIG_ACC_MASK even though the comment indicates it starts at 0?
/**
- struct mmc_rpmb_data - special RPMB device type for these areas
- @dev: the device for the RPMB area
- @chrdev: character device for the RPMB area
- @id: unique device ID number
- @part_index: partition index (0 on first) <---------------------
- @md: parent MMC block device
- @node: list item, so we can put this device on a list
*/ struct mmc_rpmb_data { struct device dev; struct cdev chrdev; int id;
is it just possible that "target_part = idata->rpmb->part_index" just needs to be shifted to avoid issues?
I think the fix to the regression I introduced could perhaps address this as well.
I have no clue how the regression happened really ... heh.
We should probably rename it part_cfg because that is what we store in it, it's assigned from card->part[idx].part_cfg.
Then the id field in mmc_rpmb_data should be deleted along with all the IDA counter code etc and the partition name hardcoded to be "0" as there will never be anything else.
Seems reasonable to me. Are you thinking of sending a cleanup patch on top of $subject patch?
Kind regards Uffe