On 5/6/25 9:03 PM, Peter Wang (王信友) wrote:
Whether it is necessary or not depends on how we define 'necessary.' If the criterion is simply to avoid errors, then indeed, this patch is not necessary. However, if we are addressing the warning caused by incorrect behavior (assigning int to u32), then it is necessary to fix it. After all, we shouldn't just be satisfied with avoiding errors, we should strive to make the Linux kernel as perfect as possible, shouldn't we?
Errors? Which errors? Using -1 instead of UINT_MAX is common in C code. Assigning variables of signed integer type to unsigned variables is also widespread. Using %d to format a negative number, although dubious, is also common in C code. Several years ago gcc warned about using %d to format unsigned integers. That warning was disabled again because there is too much existing code that follows this practice.
Additionally, there are many ways to determine whether MCQ is enabled, including reading the host capability or checking hba->mcq_enabled, etc. Moreover, MCQ is not a feature that trun on and off at runtime. It is at the end of the UFS initialization that the status of MCQ is determined, so it shouldn't be necessary to rely on this to determine whether MCQ is enabled, right?
If you want to proceed with this patch, please make it clear in the patch description that this patch is a behavior change and not a bug fix.
Thanks,
Bart.