[v1] ufs: core: change comment message to popular format

Commit Message

Peter Wang (王信友) July 25, 2022, 1:15 p.m. UTC

From: Peter Wang <[e-mail]>

Some editor cannot display ‘0’ ‘1’ in correct format.
Change it to '0' '1' for most editor can display.

Signed-off-by: Peter Wang <[e-mail]>
---
 drivers/ufs/core/ufshcd.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Comments

Bart Van Assche July 25, 2022, 4:41 p.m. UTC | #1

On 7/25/22 06:15, [e-mail] wrote:
> From: Peter Wang <[e-mail]>
> 
> Some editor cannot display ‘0’ ‘1’ in correct format.
> Change it to '0' '1' for most editor can display.

As far as I know checkpatch accepts non-ASCII UTF-8 characters. Using 
this encoding is essential to spell non-English names correctly in 
source files. I don't think it's feasible nor desirable to eliminate all 
non-ASCII UTF-8 from kernel source code files. Maybe this means that 
it's time to switch to another editor?

Thanks,

Bart.

Finn Thain July 26, 2022, 12:50 a.m. UTC | #2

On Mon, 25 Jul 2022, Bart Van Assche wrote:

> On 7/25/22 06:15, [e-mail] wrote:
> > From: Peter Wang <[e-mail]>
> > 
> > Some editor cannot display ‘0’ ‘1’ in correct format.
> > Change it to '0' '1' for most editor can display.
> 
> As far as I know checkpatch accepts non-ASCII UTF-8 characters. Using 
> this encoding is essential to spell non-English names correctly in 
> source files. 

The only foreign language that's relevant in the context of this 
particular comment is C. Writing '0' to indicate a char value would be 
fine but this is not a char value.

Quoted and unquoted zeros are used inconsistently in this comment, though 
the patch does not address this unfortunately.

> I don't think it's feasible nor desirable to eliminate all non-ASCII 
> UTF-8 from kernel source code files.

That's neither here nor there -- I don't think it's feasible or desirable 
to eliminate all bugs from the kernel source code files. One man's bug is 
another man's feature e.g. bloat, choice of programming language, 
interpretation of license terms.

> Maybe this means that it's time to switch to another editor?
> 

It's not hard to find more tooling that is impacted by misplaced unicode. 
The security vulnerabilities stemming from the use of Unicode in source 
files are telling.

Unicode doesn't help here so it shouldn't have been used here IMO.

Peter Wang (王信友) July 26, 2022, 8:39 a.m. UTC | #3

On 7/26/22 12:41 AM, Bart Van Assche wrote:
> On 7/25/22 06:15, [e-mail] wrote:
>> From: Peter Wang <[e-mail]>
>>
>> Some editor cannot display ‘0’ ‘1’ in correct format.
>> Change it to '0' '1' for most editor can display.
>
> As far as I know checkpatch accepts non-ASCII UTF-8 characters. Using 
> this encoding is essential to spell non-English names correctly in 
> source files. I don't think it's feasible nor desirable to eliminate 
> all non-ASCII UTF-8 from kernel source code files. Maybe this means 
> that it's time to switch to another editor?
>
> Thanks,
>
> Bart.

Hi Bart,

Yes, I have switch another editor when I modify this file.
Non-ASCII UTF-8 characters is not forbidden to use, but in this case, 
'0' and '1' is not required for people to understand this comment.

Thanks.
Peter

Peter Wang (王信友) July 26, 2022, 8:40 a.m. UTC | #4

On 7/26/22 8:50 AM, Finn Thain wrote:
> On Mon, 25 Jul 2022, Bart Van Assche wrote:
>
>> On 7/25/22 06:15, [e-mail] wrote:
>>> From: Peter Wang <[e-mail]>
>>>
>>> Some editor cannot display ‘0’ ‘1’ in correct format.
>>> Change it to '0' '1' for most editor can display.
>> As far as I know checkpatch accepts non-ASCII UTF-8 characters. Using
>> this encoding is essential to spell non-English names correctly in
>> source files.
> The only foreign language that's relevant in the context of this
> particular comment is C. Writing '0' to indicate a char value would be
> fine but this is not a char value.
>
> Quoted and unquoted zeros are used inconsistently in this comment, though
> the patch does not address this unfortunately.
>
>> I don't think it's feasible nor desirable to eliminate all non-ASCII
>> UTF-8 from kernel source code files.
> That's neither here nor there -- I don't think it's feasible or desirable
> to eliminate all bugs from the kernel source code files. One man's bug is
> another man's feature e.g. bloat, choice of programming language,
> interpretation of license terms.
>
>> Maybe this means that it's time to switch to another editor?
>>
> It's not hard to find more tooling that is impacted by misplaced unicode.
> The security vulnerabilities stemming from the use of Unicode in source
> files are telling.
>
> Unicode doesn't help here so it shouldn't have been used here IMO.

Hi Finn,

Thank you for supplementary information.

Thanks.
Peter

Patch

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index c7b337480e3e..4ffb344bcb46 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -760,14 +760,14 @@  static inline void ufshcd_utrl_clear(struct ufs_hba *hba, u32 mask)
 	 * From the UFSHCI specification: "UTP Transfer Request List CLear
 	 * Register (UTRLCLR): This field is bit significant. Each bit
 	 * corresponds to a slot in the UTP Transfer Request List, where bit 0
-	 * corresponds to request slot 0. A bit in this field is set to ‘0’
+	 * corresponds to request slot 0. A bit in this field is set to '0'
 	 * by host software to indicate to the host controller that a transfer
 	 * request slot is cleared. The host controller
 	 * shall free up any resources associated to the request slot
-	 * immediately, and shall set the associated bit in UTRLDBR to ‘0’. The
+	 * immediately, and shall set the associated bit in UTRLDBR to '0'. The
 	 * host software indicates no change to request slots by setting the
-	 * associated bits in this field to ‘1’. Bits in this field shall only
-	 * be set ‘1’ or ‘0’ by host software when UTRLRSR is set to ‘1’."
+	 * associated bits in this field to '1'. Bits in this field shall only
+	 * be set '1' or '0' by host software when UTRLRSR is set to '1'."
 	 */
 	ufshcd_writel(hba, ~mask, REG_UTP_TRANSFER_REQ_LIST_CLEAR);
 }