diff mbox series

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

Message ID 20220725131558.13219-1-peter.wang@mediatek.com
State New
Headers show
Series [v1] ufs: core: change comment message to popular format | expand

Commit Message

Peter Wang July 25, 2022, 1:15 p.m. UTC
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(-)

Comments

Peter Wang July 26, 2022, 8:40 a.m. UTC | #1
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
diff mbox series

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