From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 EB96A2459CF for ; Sun, 26 Apr 2026 10:49:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777200583; cv=none; b=f3O688oyQNKmvdMKJS90IAnhDGzPKL19pQj/lWkOnSTknraCJDcNrspGD//UsI3uQQ0etn4/nnw6LsqxK/nVc1SjSkT5vbz2J38yW7OoBM/QFKQxUYpJu4kPf89it1ml/IpPvfiZ6uyjOWhm1+UXnkUFo9OcHP0Ozvgo12I/J1s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777200583; c=relaxed/simple; bh=OHfzunV5PLXI0kIdwgVzMfC9eyzvktWHvlJSNRRWRWc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=H8WB0xW76gNDvMFCkEbAU1qBJhQcdkbyNH4Mo1NrhQ3BhKTPaKOQflVvKFbEDoSEwB/rATwo14GUrzpbJ435+ewMgt5htGFz546Pf2WBJmLD+YsXF6b2VVhvf34NZSAH8gFudLQlMIVtWvuCf8s71kcoX4rmN+s7YW6k9pm1Lno= 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=nNblob9d; arc=none smtp.client-ip=209.85.128.46 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="nNblob9d" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-48896199cbaso91282525e9.1 for ; Sun, 26 Apr 2026 03:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777200580; x=1777805380; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=ep7scWKVDqquDfjlRMHGlmqZl4NIrLMdEyZJu2mgSNY=; b=nNblob9dOhZzJemaGmZSGlOCvmbaaWH6clA+tn70ov/Jki9qFu/jVHqLIOLdF+Lh3O Fci7DqQ4AEcLqykBEJMQz2kKOIiwU82DlIedvidyGNNjk2MjCfrVHb9XKnZqvOtgUjau +fcrQ75sXsOvBmtZO8s8S5qQby0wpUmV4ViNatg1tkboXu/UZcYHhH8KHO0sa1z+/ZjO rfQKwS+LBGdKC8cOZGD4w8e0fBO7oetp0NSN/iZNyLsm0x0qbBohWL90uNjxp5ToeW7y r7WlUcBsNxkUIN+XdAg9USXLKonZHbYMEBK1Y0FA9swgzX1PbpDOVKP/xS/5EFrdq8Bn OSJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777200580; x=1777805380; h=content-transfer-encoding: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; bh=ep7scWKVDqquDfjlRMHGlmqZl4NIrLMdEyZJu2mgSNY=; b=dU876orEvtbzsUEqx6InWu7TeCE/PlG5u+P/J1nE7aqrFsjpUdptSR7ZVWUgrXAVvF ylsWzgl8CLnfaaSo5GdEWn8t/05Fr2BQJbslEnapF0xvzlg+q2A+qlr/r979NMxuxBCl MQ3DtYBUaDycUFt5nnst+D8PgY2XgoeWLNz3fMStZoglat6DKjHRapnBPR1vig2T9Box FfNuTjXhHxMMR6dGgT7CgZZXvtRHVVtyhFugJvG9ULcVbeIyP+CHfMXqwV1EOW0KnwCM QB0K+LN/jXC0K42tosXz50O6ml3sDJGdw1FFSHZQkXACosPe1zDtz53Y18ydiGd+fc/5 J7qA== X-Forwarded-Encrypted: i=1; AFNElJ+l+PE5+2umaf5Xb7LKx1yQoPw7+9Wg9Sz+kPwrPZQjqNt4X8BP/mytFEVWi/krQjiqvz4oaId6Zpf37q0=@vger.kernel.org X-Gm-Message-State: AOJu0YxqjRY6e252TR01Hitc2WC+RW5TIHmIMn8+v/H8/5KvFVtab4eC TRUxnWOGVPTYZW5P76N0ABzOPKo3ebzMgLB1y/qfaOZpJcUCzsenLCt9 X-Gm-Gg: AeBDieshHMj9ClawrVxW0RzCyaovuaOzcgNNeaCEqH2CcQWptnrn7jMEND2xFt2UKmo g0luYYtI8HubpTB5ykaPF6LpE1MzEXWv+AnRYtQ0qebHIajsQ3qGJ1qrlWsRKP3N5xdoRXqupWi b0mwSj7b/2Tu7XNNsulAN6vnsW2LrmXmmPZZETKeKqKJAPD0EDjQpAa2x4yQjJ8jOU8nAQ6XxDY UQvEMWmRtvlsOIHXHvp6hhLLJ2ImwECq6msBRCtNjBrNvey8x2nbIyvO/MU5CuG+Y/JipcbrDeN IQrol6/TNGoo9n347iiidzWYQSY7h2ME+hpfPHfrmep5txGjWPi6n4UuxTb220NT5+Z7BDJfiX8 fbnSJSELAXGcipCA6W4BXy3qT2dOBD6s3G9JOL+ZGAPHX47bbqdmKdp3C+CCEQop76DYctOBqN+ T7YB1uR21mGUW30YFepNnnLbeg+KHfGzbbXNmUyYAURrGgRqIUKu7tqE/BtmcbG4FGair7pwpmS dc= X-Received: by 2002:a05:600c:154e:b0:488:9ed3:1492 with SMTP id 5b1f17b1804b1-488fb74fc02mr518917135e9.10.1777200579989; Sun, 26 Apr 2026 03:49:39 -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 5b1f17b1804b1-488fc1393f5sm666871765e9.9.2026.04.26.03.49.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Apr 2026 03:49:39 -0700 (PDT) Date: Sun, 26 Apr 2026 11:49:38 +0100 From: David Laight To: Andrew Morton Cc: Min-Hsun Chang , arnd@arndb.de, msalter@redhat.com, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] asm-generic: replace ________addr with __UNIQUE_ID(addr) Message-ID: <20260426114938.4dff28c8@pumpkin> In-Reply-To: <20260425151240.2a46e3a8640fde3902461d41@linux-foundation.org> References: <20260307092119.20733-1-chmh0624@gmail.com> <20260322144032.7353997c@pumpkin> <20260425135737.e79c4b546d22b5ebfd96c0b5@linux-foundation.org> <20260425230134.5449498a@pumpkin> <20260425151240.2a46e3a8640fde3902461d41@linux-foundation.org> 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 Sat, 25 Apr 2026 15:12:40 -0700 Andrew Morton wrote: > On Sat, 25 Apr 2026 23:01:34 +0100 David Laight wrote: > > > > > The real problem with this define is that both idx and phys are > > > > expanded twice. > > > > > > The real problem with this define is that it's a define. Why oh why do > > > we keep doing this to ourselves? > > > > Sometimes #defines generate better code because they are expanded earlier, > > and sometimes you want type-agnostic 'functions'. > > But neither is true here. > > > > But I think I'd go for 'always_inline'. > > Sometimes the compilers make silly decisions. > > Gee, if `static inline' misbehaves then we have big problems! > > What's special about the fixmap code anyway? It's not exactly > fastpath. Perhaps this stuff can simply be uninlined. Some of the inlines are trivial - just adding an extra parameter. But this set would be simpler if the last function (__native_set_fixmap() for x86) returned (address & ~PAGE_MASK) > > Pet peeves: > > We use too many macros. Indeed, I get fed up of looking things up to find they are trivial. Some of the 'helpers' do nothing for core readability. Even things like BIT() can have unexpected consequences. Not to say I haven't got the pre-processor to do odd things in the past. But it is usually trying to avoid having to keep multiple definitions aligned with each other. > We inline too much stuff. True - don't look at what strlcpy() can generate. The inline code should just get the constants from the compiler and then call the appropriate function. As does the compiler. pixpaper_panel_hw_init() repeatedly calls two static functions that contain sleeps. They all get inlined bloating the code size and exploding the stack when clang separately allocates all the buffers in the called functions. David