From nobody Tue Feb 10 12:40:36 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4EB65C74A5B for ; Fri, 17 Mar 2023 05:49:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229658AbjCQFtq (ORCPT ); Fri, 17 Mar 2023 01:49:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47380 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229488AbjCQFtn (ORCPT ); Fri, 17 Mar 2023 01:49:43 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 091F91ADE1; Thu, 16 Mar 2023 22:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1679032181; x=1710568181; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sEUixxQh5M7FllqkaXFOz7oYhzzN7EJGtXFSyM2e75c=; b=JvrBMClujrujeAlI28y0EWMskSTL94GE+HtmG/eJr+J0Xj6qd882Q9fG rjQl72AaNrXKrFu9USq3q/XcKnU8swVYPpMGsPyh5wo+l/m3PBbJtqve6 LCCOoMkdYotgnmrVvagMrinbllN7pMKxiCpPQsOPhO+waFvCdiW7dYkbn MirqwYyxpfuXbpyBbqMLGC8G0W4xyfBqmjJLO1dPcsNI0moknPQdiDzMP nAj39vFMM5HkS3v1NRCcIRrZkcsYquX6aqAS0iL5KQ5KxO4wughYYeNnT B1mVdTGPNibOs0mCTLM+VtOLvkw3cDQ8+2ZdYa6tJMA7XLcchebYnJ7+9 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10651"; a="317843552" X-IronPort-AV: E=Sophos;i="5.98,268,1673942400"; d="scan'208";a="317843552" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Mar 2023 22:49:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10651"; a="1009514419" X-IronPort-AV: E=Sophos;i="5.98,268,1673942400"; d="scan'208";a="1009514419" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by fmsmga005.fm.intel.com with ESMTP; 16 Mar 2023 22:49:39 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Thu, 16 Mar 2023 22:49:39 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Thu, 16 Mar 2023 22:49:38 -0700 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21 via Frontend Transport; Thu, 16 Mar 2023 22:49:38 -0700 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.108) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.21; Thu, 16 Mar 2023 22:49:38 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dw4C1gh4h2IRBGJVh1q1rCzXRjyxazCswhqMe0ThlQIcUEREoGxeuAO+TMJTngY+IY2S57XF4zxgrhqFlCPgcJNubZnPasbCqmXE4IUzsTJn5KQRDMPvJy4sNM6WHSxl9kOTw7nlnvSzMrdfG+qh6vn+wLFKZccfiWqR35W47D2c9R1N8uHMZ1FrbP0F3bLRAOyAeJlEjiA+unQmhvrW5FAnTl7Qnl97LUf6hka3sRlIfuAICbyNU4qziK0+1rnCSovtnxMtOPW8qW/II5Mk0LNyQVQVXOD5SdbbDxm8wM9kyesz22ovHQ9OigiHZLFp8lAM6vkhEgXdjb5fc4JLnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sEUixxQh5M7FllqkaXFOz7oYhzzN7EJGtXFSyM2e75c=; b=GFTcpsyXlXA6JUnqv/yp+IMpgcZSqw9CnZ5Mng90WqDwhW8/ri/qgEOHWkvlurOGyBveMUsm3muIgkcdbb8MlcVlR+kygvL6pyzFO+z/n8olikz94b+6z+vQOzdfshC8yvCoKv+vskhAf292f4Z2VXMot9jgAXSMc1NyqhBo4zstwTtDRM3Djh+xv+IHolwlS78Y05vc1sNw7ey4I6lLPZnAxXZdnNCcvHVld1VuaOQlluOYuq4iP89wJz+8DXVfYv4WgcjO0aRm2baPx4DhnyXfbxToBRxrRJ6uPy6MIxrmq4yke4Z8rgvZtMR2tgJAydT7k4++JClWeFsogFa8Xw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from DM6PR11MB2618.namprd11.prod.outlook.com (2603:10b6:5:c0::30) by PH8PR11MB6658.namprd11.prod.outlook.com (2603:10b6:510:1c1::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.35; Fri, 17 Mar 2023 05:49:35 +0000 Received: from DM6PR11MB2618.namprd11.prod.outlook.com ([fe80::85cc:49ad:f49d:ea7c]) by DM6PR11MB2618.namprd11.prod.outlook.com ([fe80::85cc:49ad:f49d:ea7c%5]) with mapi id 15.20.6178.024; Fri, 17 Mar 2023 05:49:35 +0000 From: "Xu, Even" To: "todd.e.brandt@linux.intel.com" , "Philipp Jungkamp" , srinivas pandruvada , "linux-input@vger.kernel.org" , "linux-kernel@vger.kernel.org" CC: "Jonathan.Cameron@huawei.com" , "jkosina@suse.cz" , "Brandt, Todd E" Subject: RE: BUG: hid-sensor-ids code includes binary data in device name Thread-Topic: BUG: hid-sensor-ids code includes binary data in device name Thread-Index: AQHZUzXwgfGO1WCFDU+JrWsC/WBLDa70FL4AgACW9ICACdTz8A== Date: Fri, 17 Mar 2023 05:49:34 +0000 Message-ID: References: <592bcdcbb3603cf5dfefd09abdd6916db4efc691.camel@linux.intel.com> <317ce138f63b9317ac7be1949a68db5117c19b92.camel@linux.intel.com> <424882ed2a79a641f88b5f2d1ed5a5d3d4fe98d9.camel@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM6PR11MB2618:EE_|PH8PR11MB6658:EE_ x-ms-office365-filtering-correlation-id: 003a6b55-537b-4f26-966f-08db26ab6330 x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fTCGYJSumWFPzF93tf0sXAudb6sTQzTYt24dGgRzAoeRzrUgEvsjwvnRNaNRb3sG5HxGb7GB5sqi0GfjvcyZUn6LolVfHSmpgSWMVGpJYaWLjSy2BB3TngZ1eLI/MnqDDBCdZ+h8jxqh4imyFXQXg35MSoTuduWkKRBqwXgOamLwKssFTT4HvsvccziuFoUwEJh5Z1gW9vtgR5oM0VEQl0+HeMMswRGEFuCsv8/cqL+0dTnoSGsfTRnZEisaS1hCNHqH+A04REE2rRFkhXjEMq+Nyjn2EUOSaSPsT951e0iIZix7g0Xf6hVjAooJhQ/yf3tmyv/NGLUG0TpKAgtKERF616/FZ2fMKLFkNN4tzXyHltn7srixroCGDfDWxsv32Pg4weOyDnLoDTlT5aDuaxCVAK1vrUY9CbKk+bngTT8khfpdWXqaLrwlswiEFgMIx1mVET4kAgqPeCYtI0LoTuc9TaAy1LqZmcLhTjyhyKPOo3+/wbMhbFBvMZLT5T8alEEolsJ65+yxvll3/KX3QLb6ugmmoehhku36oKMOOy5OZsCSUPo30ZEdemoiOqTpRTiYJLu0s//3PYcbMiSrO9PzdOiYKlOXRWICc7dmpL7b84WXt67jlG6s67WoLpoE7SHoPGUFjMwxpXg/emBllrrYqSNFRpZfjKryTFHDa3TlAavDJGAtT2grZhtW6ekY3cE5ka6XZMrne3KHLa4XaQ== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR11MB2618.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230025)(396003)(136003)(39860400002)(346002)(376002)(366004)(451199018)(7696005)(55016003)(82960400001)(71200400001)(9686003)(53546011)(6506007)(186003)(26005)(83380400001)(5660300002)(86362001)(8936002)(41300700001)(52536014)(33656002)(2906002)(122000001)(110136005)(54906003)(478600001)(38100700002)(4326008)(8676002)(64756008)(66446008)(66476007)(66556008)(66946007)(76116006)(316002)(38070700005);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dVZSem02azZpU29ZOU1ZOEUxWlZKZlBoWlVKcEMyOG4yMG1HRU42OGNJQ3pK?= =?utf-8?B?Z3ZPTDdKNTVQYzJPY0w4V0x1ZGp3OU15ak1qYS9sRVR4eUg1QUllZ1c4cytQ?= =?utf-8?B?SGJBTG41R2ZTT1cxZ2t5WkN4KzdpWXZoSVFxcldqb29PbFFCdjJ0Y2VJa3Qr?= =?utf-8?B?c3pPMXg5UWNUZzZ5U1FIWU1WdGc2clNoWFlnL2RzNGpIZ1ZYeS9rZWhEMzZv?= =?utf-8?B?WDErNFp4ck9MaTVVR1p6OW90bmUwakw1WFBBS3VEbHFwdzVsL0JqOU02Wlpu?= =?utf-8?B?OXNGNm1CYmM0dklaWjZSRHpoMURObThGcUtISDJrUFBqOUhtMVZZM0dEUG1C?= =?utf-8?B?UXdXQW1Yc2k3c2I5dzlha2ZZNUx3NFJ1em1rNGtDY2tGNmZEczhhRHFONDdv?= =?utf-8?B?L2M1NkJpZVVzR1RGZ05SUjYzTDg5UHJXVWphbVBmY2FjT0RBTElIaWxIODBw?= =?utf-8?B?MzFJaXZJK1FmcHFvOXp2Mnpsa0Z5TU94a2gxaDViZnEzWUZnYkZDbFJYWFJM?= =?utf-8?B?MVp3MUhYNlJsaHd6WEtLNTNSUDNOck13MERuOEVKMXNaNHgyeVQzb2RaMGVF?= =?utf-8?B?OUxjYURDSFJwakJyZW45MmU2YWtMbHliNW1td0pOdFpMZzU0TFdoT1RhcURv?= =?utf-8?B?MTZIZ2U5UzBkRXBxWmJpc2s3bFBhTnE4T1hCTUIyNUx0T1g3UGczZjNhcEFY?= =?utf-8?B?aTdPelFPK1N1RkJZN2M3UzIwbWNYQXBWc0V2UzRqM2d5bXVKdk0zWEZYRXNX?= =?utf-8?B?RzgwMlpycmNRbHM0Y3RrV3FlVTVEblpyWVpjb29rRi8waXQrdjZwM2NIbjlq?= =?utf-8?B?SDZwQzVvbUtVbnEzR0Jwa05EZFlTdmVqZG5EeFgwS0pZNStBQ0tSRytJYndm?= =?utf-8?B?TDZ6L1pFL1RTaEozakJCekMrRzVVRW5VV29wRUFJcksyRXdXRlNFc2JEMmdS?= =?utf-8?B?SllDeGZKaFpla2NVR0JhY3E1Qit3Tkg4WlVEdVdHbXFFM2c0Qnk3eUYwUGFn?= =?utf-8?B?UmJBam1HUk5EUmdVdDBaVzNSMUNXSlUwYjFwejFwaVZFWEFBNmQ1bmtDblpy?= =?utf-8?B?d3Z3SFFaL0ZYK1FhR0xFLy9XWGk3dEtIaDN4N2F2TksxUEhNSU52OVR5VU84?= =?utf-8?B?V2F3T0ppdFEralNYWjV6VmhyUk12UG1la0NoZm4xWUU1d0FuOVhGSHkxcUpN?= =?utf-8?B?VUJOMzNPbE9lelVyVEQ3WUhhVU1zYis5S3BVNmN4SXRHRS9pVXhVaUZCVVRy?= =?utf-8?B?STduaThETnorQUtoeFlwQnNwSHVWZ2g2bDZyTWMzeGExZUFpQ3hDSTFDNHND?= =?utf-8?B?QkgyM3M0SzNmeTcrRHBub0ZpSXk2UlA1ZTNqc2F2T0N6UGlqVHZrbGVaSmlG?= =?utf-8?B?VTVnaFBWM3R4a003Ti9CZTRxVE0zU0ZDUDl2cEhseEp3N0dqMUxUMFFDWW85?= =?utf-8?B?RHhZMVZDLzVwOU1NV3llTVJHNkttWmZzV1Ezc1pOUDl4bzROZGVOS0lDUnlh?= =?utf-8?B?aDk1U3VCMVc0NTVpM0F6WDc1UlI4c3lLYXF3Uyt4VFhEbldNZXVKVkIvdFMr?= =?utf-8?B?NEFEOWFFN1U4Z1djSlRPVjAvS3FHamo3Tm1UUjEwbWtBK05vUEhYaTdBR3dO?= =?utf-8?B?YW5aZXhTREJRZXZjN0kxcHBjMlNRVHZEc3lzZVJZTm02YzRJT0JwTEwxVGNu?= =?utf-8?B?NUJjclU4VkJzTlFueTBUMWRLRGNrL2ZqVk1HVGFaaGlEcjZmRzJqRUJnOXVy?= =?utf-8?B?VXZQOVdPSjNBemUzSDhLaEg0amRoK0tPbHNWQmN5VGR3YWRLSVpGcEtIeXB2?= =?utf-8?B?VW8rUXVsVGo3amFMOW9KenF0L0FCUjFHUXc0SnQ0bUYybTl5ZTk0MFFLRVZV?= =?utf-8?B?Y0ZPNnl2VHVSc29LbzkwbTBDMDZGcjZ4TDFGckRKSGRFbWFtb1BCOWNMRmNk?= =?utf-8?B?NEFiSGdDdng4RWJYUGtlK0xJZ3dUV0VtbzIralBKM0J0Z3Y5Y3NPVzFTeFY4?= =?utf-8?B?MTBhTUErL2Q5bmxIOUJTNGxVV2svWmgwWFlYejlNUEVoR2txUGRQbXQ1Sm04?= =?utf-8?B?NmhSNnd2Q0d6dVlBSGplYlFneFBnL2o5S3BvYU14WVlxTVBiaGpoL1ZvRHBj?= =?utf-8?Q?kAAA=3D?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB2618.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 003a6b55-537b-4f26-966f-08db26ab6330 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2023 05:49:34.8292 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8HXf3UMr16dtntXNXsZNwOV9wwbZu7vGSjiyT1QCZdayVBlAmS9Suoz46BfZdKx15BzBW5LajIm3WN1eMaN8nA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR11MB6658 X-OriginatorOrg: intel.com Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, All, Sorry for response later. From below description, it seems not a buffer overrun issue, it's just caus= ed by NULL terminated string, right? Best Regards, Even Xu -----Original Message----- From: Todd Brandt =20 Sent: Saturday, March 11, 2023 7:36 AM To: Philipp Jungkamp ; srinivas pandruvada ; linux-input@vger.kernel.org; linux-kernel@vger.k= ernel.org; Xu, Even Cc: Jonathan.Cameron@huawei.com; jkosina@suse.cz; Brandt, Todd E Subject: Re: BUG: hid-sensor-ids code includes binary data in device name On Fri, 2023-03-10 at 15:35 +0100, Philipp Jungkamp wrote: > Hello, >=20 > on v3 of the patchset I had this comment on the 'real_usage' > initialization: >=20 > > > - char real_usage[HID_SENSOR_USAGE_LENGTH] =3D { 0 }; > > > + char real_usage[HID_SENSOR_USAGE_LENGTH]; > > > struct platform_device *custom_pdev; > > > const char *dev_name; > > > char *c; > > >=20 > > > - /* copy real usage id */ > > > - memcpy(real_usage, known_sensor_luid[index], 4); > > > + memcpy(real_usage, match->luid, 4); > > > + real_usage[4] =3D '\0'; > >=20 > > Why the change in approach for setting the NULL character? > > Doesn't seem relevant to main purpose of this patch. >=20 > Based on the comment, I changed that in the final v4 revision to: >=20 > > - char real_usage[HID_SENSOR_USAGE_LENGTH] =3D { 0 }; > > + char real_usage[HID_SENSOR_USAGE_LENGTH]; > > struct platform_device *custom_pdev; > > const char *dev_name; > > char *c; > > =20 > > - /* copy real usage id */ > > - memcpy(real_usage, known_sensor_luid[index], 4); > > + memcpy(real_usage, match->luid, 4); >=20 > I ommitted the line adding the null terminator to the string but kept=20 > that I didn't initialize the 'real_usage' as { 0 } anymore. The string=20 > now misses the null terminator which leads to the broken utf-8. >=20 > The simple fix is to reintroduce the 0 initialization in=20 > hid_sensor_register_platform_device. E.g. >=20 > - char real_usage[HID_SENSOR_USAGE_LENGTH]; > + char real_usage[HID_SENSOR_USAGE_LENGTH] =3D { 0 }; >=20 I didn't realize that the issue was a buffer overrun. I tested the kernel b= uilt with this simple fix and it works ok now. i.e. this patch is is all th= at's needed: diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-sensor- cust= om.c index 3e3f89e01d81..d85398721659 100644 --- a/drivers/hid/hid-sensor-custom.c +++ b/drivers/hid/hid-sensor-custom.c @@ -940,7 +940,7 @@ hid_sensor_register_platform_device(struct platform_device *pdev, struct hid_sensor_hub_device *hsdev, const struct hid_sensor_custom_match *m= atch) { - char real_usage[HID_SENSOR_USAGE_LENGTH]; + char real_usage[HID_SENSOR_USAGE_LENGTH] =3D { 0 }; struct platform_device *custom_pdev; const char *dev_name; char *c; > Where do I need to submit a patch for this? And on which tree should I=20 > base the patch? >=20 The change is so small it shouldn't require any rebasing. Just send the patch to these emails (from MAINTAINERS): HID SENSOR HUB DRIVERS M: Jiri Kosina M: Jonathan Cameron M: Srinivas Pandruvada L: linux-input@vger.kernel.org L: linux-iio@vger.kernel.org > I'm sorry for the problems my patch caused. >=20 No problem. It actually made sleepgraph better because it exposed a bug in the ftrace processing code. I wasn't properly handling the corner case where ftrace had binary data in it. > Regards, > Philipp Jungkamp >=20 > On Fri, 2023-03-10 at 01:51 -0800, srinivas pandruvada wrote: > > +Even > >=20 > > On Thu, 2023-03-09 at 15:33 -0800, Todd Brandt wrote: > > > Hi all, I've run into an issue in 6.3.0-rc1 that causes problems > > > with > > > ftrace and I've bisected it to this commit: > > >=20 > > > commit 98c062e8245199fa9121141a0bf1035dc45ae90e (HEAD, > > > refs/bisect/bad) > > > Author: Philipp Jungkamp p.jungkamp@gmx.net > > > Date: Fri Nov 25 00:38:38 2022 +0100 > > >=20 > > > HID: hid-sensor-custom: Allow more custom iio sensors > > >=20 > > > The known LUID table for established/known custom HID sensors > > > was > > > limited to sensors with "INTEL" as manufacturer. But some > > > vendors > > > such > > > as Lenovo also include fairly standard iio sensors (e.g. > > > ambient > > > light) > > > in their custom sensors. > > >=20 > > > Expand the known custom sensors table by a tag used for the > > > platform > > > device name and match sensors based on the LUID as well as > > > optionally > > > on model and manufacturer properties. > > >=20 > > > Signed-off-by: Philipp Jungkamp p.jungkamp@gmx.net > > > Reviewed-by: Jonathan Cameron Jonathan.Cameron@huawei.com > > > Acked-by: Srinivas Pandruvada > > > srinivas.pandruvada@linux.intel.com > > > Signed-off-by: Jiri Kosina jkosina@suse.cz > > >=20 > > > You're using raw data as part of the devname in the "real_usage" > > > string, but it includes chars other than ASCII, and those chars > > > end > > > up being printed out in the ftrace log which is meant to be ASCII > > > only. > > >=20 > > > - /* HID-SENSOR-INT-REAL_USAGE_ID */ > > > - dev_name =3D kasprintf(GFP_KERNEL, "HID-SENSOR-INT-%s", > > > real_usage); > > > + /* HID-SENSOR-TAG-REAL_USAGE_ID */ > > > + dev_name =3D kasprintf(GFP_KERNEL, "HID-SENSOR-%s-%s", > > > + match->tag, real_usage); > > >=20 > > > My sleepgraph tool started to crash because it read these lines > > > from > > > ftrace: > > >=20 > > > device_pm_callback_start: platform HID-SENSOR-INT-020b?.39.auto, > > > parent: 001F:8087:0AC2.0003, [suspend] > > > device_pm_callback_end: platform HID-SENSOR-INT-020b?.39.auto, > > > err=3D0 > > >=20 > >=20 > > Here tag is: > > .tag =3D "INT", > > .luid =3D "020B000000000000", > >=20 > >=20 > > The LUID is still a string. Probably too long for a dev_name. > >=20 > > Even, > >=20 > > Please check. > >=20 > > Thanks. > > Srinivas > >=20 > >=20 > > > The "HID-SENSOR-INT-020b?.39.auto" string includes a binary char > > > that > > > kills > > > python3 code that loops through an ascii file as such: > > >=20 > > > File "/usr/bin/sleepgraph", line 5579, in executeSuspend > > > for line in fp: > > > File "/usr/lib/python3.10/codecs.py", line 322, in decode > > > (result, consumed) =3D self._buffer_decode(data, self.errors, > > > final) > > > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in > > > position > > > 1568: invalid start byte > > >=20 > > > I've updated sleepgraph to handle random non-ascii chars, but > > > other > > > tools > > > may suffer the same fate. Can you rewrite this to ensure that no > > > binary > > > chars make it into the devname? > > >=20 >=20 >=20