[PATCH] mmc: Drop unused mmc_send_tuning() cmd_error parameter
Marek Vasut
marek.vasut at mailbox.org
Tue Feb 20 12:26:58 CET 2024
On 2/20/24 11:50, Paul Barker wrote:
> On 20/02/2024 08:36, Marek Vasut wrote:
>> The cmd_error parameter is not used, remove it.
>> [snip]
>>
>> diff --git a/drivers/mmc/mtk-sd.c b/drivers/mmc/mtk-sd.c
>> index 5a0c61daed5..296aaee7331 100644
>> --- a/drivers/mmc/mtk-sd.c
>> +++ b/drivers/mmc/mtk-sd.c
>> @@ -1131,7 +1131,7 @@ static int hs400_tune_response(struct udevice *dev, u32 opcode)
>> i << PAD_CMD_TUNE_RX_DLY3_S);
>>
>> for (j = 0; j < 3; j++) {
>> - mmc_send_tuning(mmc, opcode, &cmd_err);
>> + cmd_err = mmc_send_tuning(mmc, opcode);
>> if (!cmd_err) {
>> cmd_delay |= (1 << i);
>> } else {
>> @@ -1181,7 +1181,7 @@ static int msdc_tune_response(struct udevice *dev, u32 opcode)
>> i << MSDC_PAD_TUNE_CMDRDLY_S);
>>
>> for (j = 0; j < 3; j++) {
>> - mmc_send_tuning(mmc, opcode, &cmd_err);
>> + cmd_err = mmc_send_tuning(mmc, opcode);
>> if (!cmd_err) {
>> rise_delay |= (1 << i);
>> } else {
>> @@ -1203,7 +1203,7 @@ static int msdc_tune_response(struct udevice *dev, u32 opcode)
>> i << MSDC_PAD_TUNE_CMDRDLY_S);
>>
>> for (j = 0; j < 3; j++) {
>> - mmc_send_tuning(mmc, opcode, &cmd_err);
>> + cmd_err = mmc_send_tuning(mmc, opcode);
>> if (!cmd_err) {
>> fall_delay |= (1 << i);
>> } else {
>> @@ -1238,7 +1238,7 @@ skip_fall:
>> clrsetbits_le32(tune_reg, MSDC_PAD_TUNE_CMDRRDLY_M,
>> i << MSDC_PAD_TUNE_CMDRRDLY_S);
>>
>> - mmc_send_tuning(mmc, opcode, &cmd_err);
>> + cmd_err = mmc_send_tuning(mmc, opcode);
>> if (!cmd_err)
>> internal_delay |= (1 << i);
>> }
>> @@ -1264,7 +1264,6 @@ static int msdc_tune_data(struct udevice *dev, u32 opcode)
>> struct msdc_delay_phase final_rise_delay, final_fall_delay = { 0, };
>> u8 final_delay, final_maxlen;
>> void __iomem *tune_reg = &host->base->pad_tune;
>> - int cmd_err;
>> int i, ret;
>>
>> if (host->dev_comp->pad_tune0)
>> @@ -1277,10 +1276,10 @@ static int msdc_tune_data(struct udevice *dev, u32 opcode)
>> clrsetbits_le32(tune_reg, MSDC_PAD_TUNE_DATRRDLY_M,
>> i << MSDC_PAD_TUNE_DATRRDLY_S);
>>
>> - ret = mmc_send_tuning(mmc, opcode, &cmd_err);
>> + ret = mmc_send_tuning(mmc, opcode);
>> if (!ret) {
>> rise_delay |= (1 << i);
>> - } else if (cmd_err) {
>> + } else {
>> /* in this case, retune response is needed */
>> ret = msdc_tune_response(dev, opcode);
>> if (ret)
>> @@ -1300,10 +1299,10 @@ static int msdc_tune_data(struct udevice *dev, u32 opcode)
>> clrsetbits_le32(tune_reg, MSDC_PAD_TUNE_DATRRDLY_M,
>> i << MSDC_PAD_TUNE_DATRRDLY_S);
>>
>> - ret = mmc_send_tuning(mmc, opcode, &cmd_err);
>> + ret = mmc_send_tuning(mmc, opcode);
>> if (!ret) {
>> fall_delay |= (1 << i);
>> - } else if (cmd_err) {
>> + } else {
>> /* in this case, retune response is needed */
>> ret = msdc_tune_response(dev, opcode);
>> if (ret)
>
> This driver (mtk-sd.c) seems to be the only one that really uses the
> `cmd_error` parameter.
>
> Looking at the implementation of mmc_send_tuning() in Linux, this
> parameter is used so that a caller can differentiate between a command
> error and a data error. I don't know enough details about MMC to
> understand the distinction, but I assume there is some reason for this.
> So I wonder if the mtk-sd driver will still work if those error paths
> are taken for data errors and not just command errors. Has this change
> been tested on some board which uses this driver?
Not by me, so far this driver used uninitialized error value and assumed
it was initialized as far as I can tell, so it is likely already broken.
More information about the U-Boot
mailing list