| Message ID | 20220725131558.13219-1-peter.wang@mediatek.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v1] ufs: core: change comment message to popular format | expand |
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.
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.
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); }