From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753102AbdBJMbE (ORCPT ); Fri, 10 Feb 2017 07:31:04 -0500 Received: from mga03.intel.com ([134.134.136.65]:64726 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751577AbdBJMbD (ORCPT ); Fri, 10 Feb 2017 07:31:03 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,141,1484035200"; d="asc'?scan'208";a="819300747" From: Felipe Balbi To: Greg KH , Stefan Agner Cc: andrzej.p@samsung.com, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] fs: configfs: make qw_sign attribute symmetric In-Reply-To: <20170210111929.GA22347@kroah.com> References: <20170201021917.27398-1-stefan@agner.ch> <20170201080616.GA17968@kroah.com> <32e2fa73fdbd8b52abe442365fd1c514@agner.ch> <20170210111929.GA22347@kroah.com> Date: Fri, 10 Feb 2017 14:30:01 +0200 Message-ID: <87h942qldi.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Greg KH writes: > On Thu, Feb 09, 2017 at 10:04:43AM -0800, Stefan Agner wrote: >> On 2017-02-01 08:59, Stefan Agner wrote: >> > On 2017-02-01 00:06, Greg KH wrote: >> >> On Tue, Jan 31, 2017 at 06:19:16PM -0800, Stefan Agner wrote: >> >>> Currently qw_sign requires UTF-8 character to set, but returns UTF-16 >> >>> when read. This isn't obvious when simply using cat since the null >> >>> characters are not visible, but hexdump unveils the true string: >> >>> >> >>> # echo MSFT100 > os_desc/qw_sign >> >>> # hexdump -C os_desc/qw_sign >> >>> 00000000 4d 00 53 00 46 00 54 00 31 00 30 00 30 00 |M.S.F= .T.1.0.0.| >> >>> >> >>> Make qw_sign symmetric by returning an UTF-8 string too. Also follow >> >>> common convention and add a new line at the end. >> >> >> >> Doesn't USB require that strings be in UTF-16? So why have the kernel >> >> convert them? >> >=20 >> > That is a discussion we should have had when the write side of this has >> > been added: >> >=20 >> > static ssize_t os_desc_qw_sign_store(struct config_item *item, const >> > char *page, >> > size_t len) >> > { >> > struct gadget_info *gi =3D os_desc_item_to_gadget_info(item); >> > int res, l; >> >=20 >> > l =3D min((int)len, OS_STRING_QW_SIGN_LEN >> 1); >> > if (page[l - 1] =3D=3D '\n') >> > --l; >> >=20 >> > mutex_lock(&gi->lock); >> > res =3D utf8s_to_utf16s(page, l, >> > UTF16_LITTLE_ENDIAN, (wchar_t *) gi->qw_sign, >> > OS_STRING_QW_SIGN_LEN); >> > if (res > 0) >> > res =3D len; >> > mutex_unlock(&gi->lock); >> >=20 >> > return res; >> > } >> >=20 >> >=20 >> > The store function is definitely already in use today, e.g. this script >> > used for ev3dev: >> > https://github.com/ev3dev/ev3-systemd/blob/ev3dev-jessie/scripts/ev3-u= sb.sh >> >=20 >> > Changing it to UTF-16 would break that script... So changing the store >> > part is the lesser of two evils. >> >=20 >> > Regarding new line: Just following what other attributes are doing by >> > using the GS_STRINGS_R macro. >>=20 >> Any comment on this? In my opinion especially this first patch really >> fixes a bug and should get applied... I can remove the newline if >> preferred. > > It's up to Felipe, give him a chance to catch up on patches... I really don't know what to do here :-) Either way have the potential of breaking userspace. Maybe returning UTF8 as in write is the lesser of two evils. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAlidskkACgkQzL64meEa mQajYw//f4Ww5H4uwotZ9kWe3Tv3JovA3Grg9AYg7xPChDceVhjjTw50KZwLK8JF b81FlvhgF6w0qrxu+KHpWhdAzRvBYISAKUMk3R6NOOV5qqSylVRZ7Id6O/Mnn0bK JSsg4LrFmuksC3JMbJrhmB2qdeTpjNrEwRqLzNZA3l5ZgIFjUw6tgJLFaO/++NWn Dml559QJmdqymupzuJEqExoc4CVpW5ueC/mWAqolYEqWFvsldF5VEMdles7oqupS zanW4xeSbN8v/oONKq6QC7AymdTPtyuG9dpCaNAMi/gHIH00mRB0VflRG7ok3Wk/ EMKrUMQ8ADNtO3quMSVfSZYBVooA8iHhEg1bKJtZb9bp/l8FvA03qeNEdjy8jg8N ITWuvKD/f33YpVvErBcO00Ppbk074QrtX+VQ2qjiFZcywMR7i3JYDh6P6epzY06o hoscD5qXhXoO+RRdhVMlcw+BXfVtUrud/VeO1z0IfxucmWS/IENoIhAJKk1Bv40A Rj+MJ/0kl+03+gTg/ipY5+LrzCgIo7TR74lhBnYAYSmAKZuIZrE2YxTOcVVS/oD0 VBP4LTBcQExBwVZmTxYj/4QaswHAyGR/cJjSWUvwpLQy/ZZ26A5j/br6qWMxG5DB oNS1Bbzzp3Y9A6xlf1xJXyAEKpHb+pmTQYOqIlDAMcUmsjuSqFQ= =Fw0/ -----END PGP SIGNATURE----- --=-=-=--