On 7/23/26 9:38 AM, Jorge Ramirez-Ortiz wrote: > UFS string descriptors are UTF-16 big-endian (JESD220), but > ufshcd_read_string_desc() fed the raw bytes to utf16_to_utf8(), which reads > host-endian code units, leaving dev_desc->model blank. Byte-swap to host > order before decoding, matching the kernel. > > Signed-off-by: Jorge Ramirez-Ortiz <[email protected]> > --- > drivers/ufs/ufs-uclass.c | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/drivers/ufs/ufs-uclass.c b/drivers/ufs/ufs-uclass.c > index 6a51f337e47..8f120fbbee8 100644 > --- a/drivers/ufs/ufs-uclass.c > +++ b/drivers/ufs/ufs-uclass.c > @@ -1533,6 +1533,19 @@ static inline void ufshcd_remove_non_printable(uint8_t > *val) > *val = ' '; > } > > +static inline void ufshcd_str_desc_to_cpu(u8 *desc, u32 size) > +{ > + u16 *p = (u16 *)&desc[QUERY_DESC_HDR_SIZE]; > + u32 len = desc[QUERY_DESC_LENGTH_OFFSET]; > + u32 i; > + > + if (len > size) > + len = size; > + > + for (i = QUERY_DESC_HDR_SIZE; i + 1 < len; i += 2, p++) > + *p = be16_to_cpu(*p);
I'm not a huge fan of modifying data in place like this. What do people think about adding an endian parameter to utf16_to_utf8() instead? > +} > + > /** > * ufshcd_uic_pwr_ctrl - executes UIC commands (which affects the link power > * state) and waits for it to take effect. > @@ -1765,6 +1778,8 @@ static int ufshcd_read_string_desc(struct ufs_hba *hba, > int desc_index, > goto out; > } > > + ufshcd_str_desc_to_cpu(buf, size); > + > /* > * the descriptor contains string in UTF16 format > * we need to convert to utf-8 so it can be displayed
