From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AE66B43B6D0 for ; Wed, 15 Jul 2026 10:07:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784110035; cv=none; b=FC4dIFB+WHosSYfetIlEhMHyIpXh8C100XvsCmJXFPrLqNyeBvT9YXSoXbQ7XYmOAXy/r06+WaKG6N5AGpzXNvYFw4q5ly4WYlunH/pAyUAZqnUs1spFhK0Dfx9OZkjKvRVH5f3O7C8fwbc5sHzvL5FCDwf3KCbVpGsO1hRWdjo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784110035; c=relaxed/simple; bh=y0GciO2PptY+uLJh2hE0gUz/QaDDOUqegX2K+jVz2EE=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=CQBR2t8AoDtUFF6VLHmXa7Af6hrMTHLSiWNyeZfixxMVHYdudV5TpXQJ0dWEckvGlyphAZbRgeEcZbVgJqrK+9QFXmAP5zedeO7GAgwo14z+mZjtNg8evNokeEJGvcG1J5wpJpSqTGbvZP7nZMm3qmMvahikMYhacEMmEGxxNNc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=AvQWJz0U; arc=none smtp.client-ip=209.85.221.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="AvQWJz0U" Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-47db714766aso262021f8f.0 for ; Wed, 15 Jul 2026 03:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784110032; x=1784714832; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=i3m9zsFrAgWzgJX2cCHjiYa0wXHpJDDJln72RbZhmYs=; b=AvQWJz0ULKUc7OWuHhozvdU6KFap2rr0WGWVWhFfuOtUS5OwnLKm1r55IJX1Bdel+H Ym0xZyfofDkWsjUDblEucfGXSRw9WXMzly5HCTUFsmbGINiQoc6y70SrtwjPyAmbIKv8 jqQ+p63/i1Y0RHwRIzlB0pemEJC4zYZiV7BwpbrDZZhPIi90LVw7DgJ3pTqBJBgRkeRJ r8ySQWtMGd8OqJ/eObI2uyNMtDo1IcmxJgYgLq7AT2mvmgT76hpnGuQFD3qGy1b4FHGw C6lLYXxBLej1qh30LrlpzC4KAYcUDv2J/OmMIAF4kaFV5t6kLPZfzdcDweR8KlbQVhfJ Dk+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784110032; x=1784714832; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=i3m9zsFrAgWzgJX2cCHjiYa0wXHpJDDJln72RbZhmYs=; b=YimfycHwEmlY+aXEXqKl3DC7xu0E8wN/sh/a8eUWtNMP23KsQHZ/pWfquE+DvWnvXE mw/V334TTO2ACANLKy0kSM7gCcO/tCHx21nOivc8qt6ctn4/+ldXWnx9vk3GCI02YuxR eBXYu+zZXG5mIcklA/iw8P/llBS/apIdZUbt54c+hUh2a+o9TD5ZtfML5ktnt6H8bHwG uK+J4QKjJxY97ovFjudtpwLk0s6SN0ygov8HtJ+Fdk4yIEQfh+/DWlfzlSZoGiE0zCkS 5bxrCn/8KHK4vpIOyq6A+2pYBeQi3muSM2dkDcayOG6nHejVABWSDRE1VbvZGd5foBJx xEjg== X-Forwarded-Encrypted: i=1; AHgh+RoU+xtVquZU/F/peDvAKowu8jU2Qxjt5WkTRa2YV/ieI+pVf/uWZVn75eVC0vExd2ZeByN3OZW5G3eEc8I=@vger.kernel.org X-Gm-Message-State: AOJu0YwtiFaO29RtphDMTjtKFnMRST2T2x2YYh3zPdgtnGe0G1ZIpG1b 4e88xps5vYU6GTtXqgnVV9rwqqObuoy0BQuKMzA6VNYDVEIsRrNVquZj X-Gm-Gg: AfdE7cnAeiYVab9qhutvtBGx2By0/z5nze52qkjmzXXG6Tf5WUOycHqldxNFO2ZX+/8 LrOAh6KJB7i8WWCgkJLCg7w1SH6t1kazIUISftHUEhpQbaLxW2I5KjKRaoFTMdN7o1T2pYvJNx1 SAO0hYmvqYNwaWDWQ0eJgf3dyNDEXwglB4hjPTRMtWmgDJSlXPGnk9Ii9LfQ28VS+PaFlGSLJE8 62b10pk5HdsZ1p7llmS4xMYxS1hFLOrbqc0AvYVrQYG9Ivpjlhptse+E6na5ez3R0+PuHxQM1IR 32dMoZ54uf47TdDA6WZNGlwFOCPC4BhZ65eGcyUZqk5kwZvod3Zx3JJXd7b84bS4zYjJIcCbhxq GUnTwCz+HKiONQkvF6l85475itDYf/EBRiKBVpr3X6p8bnNiKpJYWpB55Ij2XpQ0aSEv/6loYyA LhXfJwkkA/fFxm1NLyxQMGiyT51wQxO0F3HggGC8ldyypJN7/NsA== X-Received: by 2002:a05:6000:2305:b0:475:f0c2:75b0 with SMTP id ffacd0b85a97d-47f2dcd7854mr20150852f8f.27.1784110031605; Wed, 15 Jul 2026 03:07:11 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f4635a935sm14962845f8f.11.2026.07.15.03.07.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jul 2026 03:07:11 -0700 (PDT) Date: Wed, 15 Jul 2026 11:07:09 +0100 From: David Laight To: Andy Shevchenko Cc: Colin Ian King , Duje =?UTF-8?B?TWloYW5vdmk=?= =?UTF-8?B?xIc=?= , Jonathan Cameron , David Lechner , Nuno =?UTF-8?B?U8Oh?= , Andy Shevchenko , linux-iio@vger.kernel.org, kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH][next] iio: adc: make read-only const array config static Message-ID: <20260715110709.74f556f4@pumpkin> In-Reply-To: References: <20260714165012.184651-1-colin.i.king@gmail.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 14 Jul 2026 20:08:10 +0300 Andy Shevchenko wrote: > On Tue, Jul 14, 2026 at 05:50:12PM +0100, Colin Ian King wrote: > > Don't populate the read-only const array config on the stack at run > > time, instead make it static. > > Reviewed-by: Andy Shevchenko > > ... > > In all patches like this it's always a bikeshedding possible of moving static > data outside of a function. I have no strong opinion in these cases (when the > data solely used by a single function), but in general it might give different > readability experience (it's harder to notice static data in the local function > definition block). So I leave this exercise to the maintainers of the respective > pieces of the code. > If global you start wondering where it is used.... There is also the fact that run-time initialisation of a 3 byte array on stack is very likely to generate faster code than using static data. Mostly because the access to the static data is likely to be a cache miss. Then there are the architectures where just generating the address of the static data takes multiple instructions. In that case the on-stack version may even be smaller. David