Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp547016pxb; Thu, 5 Nov 2020 06:59:00 -0800 (PST) X-Google-Smtp-Source: ABdhPJwhk+JIEjEqsMSAzDQ050roYyenEDzXieh/PNdSSTYQa1c/yFnIyyRHfbr41exvODJOAiAB X-Received: by 2002:a50:9e05:: with SMTP id z5mr2827937ede.231.1604588340222; Thu, 05 Nov 2020 06:59:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604588340; cv=none; d=google.com; s=arc-20160816; b=spyuC9UPy8DEIZTrSzSYyqokhEzaBkxK4DAEBLc2EFtN6FZPinjjxXqPmCNAOs0k1/ AT2f+qrSlvmBTz84E06esuCxWFQLuOUdejZeaTr6UvglYAunvXWa/AE2ga01oHXL1pV4 RKlj3lB0SS6udLYoeqVDLeWQgYMeaddVtJAXHFSUeUJFG63a7ywrK8y8CIMI9hJiyNhE icNp24p5G8Sps2c6KZRhwm0U3NK+lxJ3D7foaBVOuqV4koBAJPYwVCS2ePnbojY8KKeQ fGXkEu8T3tYUloaV/WaIRu0mYhfoIXDmmLKalQTJ+4RwUYRZoKcu5XWKTCfMK8ERXWna 3mLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=AED3MBDefcnp0mCJXdrdtcxZnXgQF7QTFe0siuwy3Rc=; b=qi+LBDGnBxXgO0u+cGp5nLi432pv1Qku7pW4IVfFRlJR947vYfF9W9dMbFEcsMcqFq NgQCSpG9bqj6gZ5+YuMPAMjYm9BBkcwdheus2UAx8FEKCmce0F8k9SgK7vlkNlrh/uNP 5mhhE4O81zvZK566R7LorPyKbdYNaINX9dFb1MiMyt80/1eCWiLjgo9ZMgeoNdv+ahkO Nbm/cDLeeij/6P3lB+hGmtw7lZXfXM5M+nveIsx2FbuzjZq8nwUBRA+OfNaKvl+sKrh5 z8kJWciTRc47xs1V6M8p4uBuKGYHpLnQkSvP3qbR+0gIWf35gfhDnjyoB74exLagOeAz C+lw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id rn28si1261638ejb.585.2020.11.05.06.58.37; Thu, 05 Nov 2020 06:59:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731281AbgKEOyX (ORCPT + 99 others); Thu, 5 Nov 2020 09:54:23 -0500 Received: from foss.arm.com ([217.140.110.172]:34882 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730465AbgKEOyX (ORCPT ); Thu, 5 Nov 2020 09:54:23 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D7C8B14BF; Thu, 5 Nov 2020 06:54:22 -0800 (PST) Received: from [10.57.54.223] (unknown [10.57.54.223]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AFD583F718; Thu, 5 Nov 2020 06:54:21 -0800 (PST) Subject: Re: [PATCH] pinctrl: Remove hole in pinctrl_gpio_range To: Linus Walleij , Geert Uytterhoeven Cc: "open list:GPIO SUBSYSTEM" , Heiko Stuebner , "linux-kernel@vger.kernel.org" , "open list:ARM/Rockchip SoC..." References: <20201028145117.1731876-1-geert+renesas@glider.be> From: Robin Murphy Message-ID: <77bc14cd-7e47-6972-ee0b-fa72bb9e9fad@arm.com> Date: Thu, 5 Nov 2020 14:54:21 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-11-05 13:57, Linus Walleij wrote: > On Wed, Oct 28, 2020 at 3:51 PM Geert Uytterhoeven > wrote: > >> On 64-bit platforms, pointer size and alignment are 64-bit, hence two >> 4-byte holes are present before the pins and gc members of the >> pinctrl_gpio_range structure. Get rid of these holes by moving the >> pins pointer. >> >> This reduces kernel size of an arm64 Rockchip kernel by ca. 512 bytes. >> >> Signed-off-by: Geert Uytterhoeven >> --- >> Compile-tested only (arm/multi_v7_defconfig and arm64/defconfig). > > Patch applied. > > Do you think it'd be worth it to add a check to checkpatch to suggest > to move pointers toward the end of any struct? For a general rule, I thought that ordering struct members largest-first was the conventional wisdom, since that way no sensible compiler would add padding between any members, only at the end? That said, the trouble with any checkpatch rule is that people will inevitably try to apply it indiscriminately. With structure layout, that could often end up hurting readability and/or performance (via cache effects), while in many cases making no actual difference to the overall size anyway. Robin.