Received: by 2002:a05:7412:8d08:b0:f9:2d0a:d759 with SMTP id bj8csp138558rdb; Sun, 17 Dec 2023 05:49:30 -0800 (PST) X-Google-Smtp-Source: AGHT+IEkwX7M7RM3Pj1pQ5qXfc5e+1DCIwnT+DlNWVAaGTttmj5QKoOjhsbNEGeDLYNnB7WMYqrZ X-Received: by 2002:a05:6a20:a483:b0:18f:9c4:d33e with SMTP id y3-20020a056a20a48300b0018f09c4d33emr14331412pzk.46.1702820970358; Sun, 17 Dec 2023 05:49:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702820970; cv=none; d=google.com; s=arc-20160816; b=wD+d0VnYcv1n76b3MMvwPFr0FL/UFVYdtU+bV3N81ZIRbk3azaVfp//zN/se/9nQVs 18MFlagut5xQ1+dVT8mLCXCRl3WTgNvHHJZzgwxKcvTXkLMVpnLeaCRxE90c+w5idWkC 08t7DVRi5lNCrWwwyGRHv2Qe+QMEcigHsOyCzdWUPpJqiyFCT7csM0hk/O6nztyTi+a7 OCPxMd5ol+l2zCKmVILyqTr0jKX8EW4DJlE8fd4xfu8Y/9OeoMlipDo1xusdglFCUtrG 3VokpBoXqtf/ImTYWitSYjmp7e4ASKymXkI/bwt3+HM2v831KkSOUY3HtLTmi2LfqCZd K/jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :user-agent:content-transfer-encoding:references:in-reply-to:date:cc :to:from:subject:message-id; bh=C/eN07RzDBBO11GH3G+1xltzprh3QsDqkR3X9mdbC9Y=; fh=N0IDfJRR/hj1lBL65/+5dueyZUXeMFTdkmqCR4NXzPs=; b=ELONyd8QrtXGU9mrSprbAr7Crex5m/ur6mgKk3ztB9SHCe5vk1tY71IBV5kOs3O6d+ QulnaN7Oqy5d+pkm4bCchlh/9XrzBBqsY6/vmU/R9YjhdMQ3Q4hpAHYZupCKGLgaR/Bq 4RVg3fzy4I6GZequhz07CejFv2pGH2vo0ce6eafR50oIB40iUuPueFX4mj9r5jhud2Yg EZwMAI8Vh4yF6nmX8hx2WuHolmhanv/6fxLSh9kv7lz87ELUAjVXdVv2k+wi5Hp3JbDj YH9Me8IKXjX+m8XtMnJgAWrO3UeFN1lA4t0Nh/ReDkTlTCzpEPIT9/u6FE6ENtss+SoA MQxw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-2614-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-2614-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id g184-20020a636bc1000000b005c668a5a906si16172288pgc.282.2023.12.17.05.49.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 17 Dec 2023 05:49:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-2614-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-2614-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-2614-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id ACCE32837F8 for ; Sun, 17 Dec 2023 13:41:40 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id ED3F144C72; Sun, 17 Dec 2023 13:41:19 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E498444390; Sun, 17 Dec 2023 13:41:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=perches.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=perches.com Received: from omf17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8AAC912093F; Sun, 17 Dec 2023 13:41:16 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: joe@perches.com) by omf17.hostedemail.com (Postfix) with ESMTPA id 0A79119; Sun, 17 Dec 2023 13:41:13 +0000 (UTC) Message-ID: <9a9e84bf64fc95840ff852aeb276ef8f724b60be.camel@perches.com> Subject: Re: [PATCH v3] iio: sx9324: avoid copying property strings From: Joe Perches To: Jonathan Cameron Cc: Justin Stitt , Lars-Peter Clausen , Stephen Boyd , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Date: Sun, 17 Dec 2023 05:41:12 -0800 In-Reply-To: <20231217132447.269072df@jic23-huawei> References: <20231212-strncpy-drivers-iio-proximity-sx9324-c-v3-1-b8ae12fc8a5d@google.com> <20231217132447.269072df@jic23-huawei> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Rspamd-Queue-Id: 0A79119 X-Rspamd-Server: rspamout02 X-Stat-Signature: 55tnysbjs4z59qdfgqwosyw5fpsji5rr X-Session-Marker: 6A6F6540706572636865732E636F6D X-Session-ID: U2FsdGVkX18MlYf/abwYr5NYDUmr9xoyL4oUIp2C6bk= X-HE-Tag: 1702820473-749084 X-HE-Meta: U2FsdGVkX1+WnYfaK4UJSBADr2dzH257oYCOZo1NLbbRbYYcM4iIJQPWtrMU2oAIhYVMaYlxk/Nj0EN783k1SW80vlTxDq2AyiK4wyVlt8bygUTvw5Q3BmgmAtF4/o85pkBijx2hb/d3RX6AUxCyMUCjaNIGbtam/IjL8yZS+teN+4B+ifjmZDFQBLlrMOuJB1itaX5mXG/62dNwn5oGi2DmceDzTHYRQgB9+fthoUes3Rl8+mEAYjC6Jx6Vog6B/xdgnUZhrjsQpabWXizpKCB4Pa8R7PrzjbFLVAcjJj1+o4VYH/YlQaTUVuVbERGbJ4gwH3RFnWhzUf/cLqs1JHzhTw/nu19HuCGw6imuHnPvMC0Y/eu6Lo4zSkkByMVZ On Sun, 2023-12-17 at 13:24 +0000, Jonathan Cameron wrote: > On Mon, 11 Dec 2023 22:30:12 -0800 > Joe Perches wrote: >=20 > > On Tue, 2023-12-12 at 00:42 +0000, Justin Stitt wrote: > > > We're doing some needless string copies when trying to assign the pro= per > > > `prop` string. We can make `prop` a const char* and simply assign to > > > string literals. =20 > >=20 > > trivia: > >=20 > > I would have updated it like this moving the > > various declarations into the case blocks > > where they are used and removing a few unused > > #defines >=20 > I'd definitely like to see those defines gone. > Arguably an unrelated change as I guess they are left from a previous ref= actor > of this code. >=20 > Why prop to type renaming? random, no specific need, though I prefer not reusing identifiers with different types in separate local scopes. > It's getting passed into calls where the parameter > is propname so I'd understand renaming to that, but type just seems a bit= random > to me. I do wonder if we are better off having some long lines and getti= ng rid > of the property naming local variables completely by just duplicating > the device_property_read_u32() call and passing them in directly. maybe, give it a try and see what you think.