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

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

[peter.wang]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="N", Size: 1708 bytes --]

From: Peter Wang <peter.wang@mediatek.com>

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

Signed-off-by: Peter Wang <peter.wang@mediatek.com>
---
 drivers/ufs/core/ufshcd.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

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);
 }
-- 
2.18.0

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

[Bart Van Assche]

On 7/25/22 06:15, peter.wang@mediatek.com wrote:
> From: Peter Wang <peter.wang@mediatek.com>
> 
> 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.

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

[Finn Thain]

[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]

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

> On 7/25/22 06:15, peter.wang@mediatek.com wrote:
> > From: Peter Wang <peter.wang@mediatek.com>
> > 
> > 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.

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

[Peter Wang]

On 7/26/22 12:41 AM, Bart Van Assche wrote:
> On 7/25/22 06:15, peter.wang@mediatek.com wrote:
>> From: Peter Wang <peter.wang@mediatek.com>
>>
>> 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

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

[Peter Wang]

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, peter.wang@mediatek.com wrote:
>>> From: Peter Wang <peter.wang@mediatek.com>
>>>
>>> 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