Re: [PATCH v1] ufs: core: fix hwq_id type and value

[Bart Van Assche <bvanassche@acm.org>]

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.