[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z7xluhcEA-VS22kK@smile.fi.intel.com>
Date: Mon, 24 Feb 2025 14:27:38 +0200
From: "andriy.shevchenko@...ux.intel.com" <andriy.shevchenko@...ux.intel.com>
To: Aditya Garg <gargaditya08@...e.com>
Cc: Thomas Zimmermann <tzimmermann@...e.de>,
"pmladek@...e.com" <pmladek@...e.com>,
Steven Rostedt <rostedt@...dmis.org>,
"linux@...musvillemoes.dk" <linux@...musvillemoes.dk>,
"senozhatsky@...omium.org" <senozhatsky@...omium.org>,
Jonathan Corbet <corbet@....net>,
"maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>,
"mripard@...nel.org" <mripard@...nel.org>,
"airlied@...il.com" <airlied@...il.com>,
"simona@...ll.ch" <simona@...ll.ch>,
Andrew Morton <akpm@...ux-foundation.org>,
"apw@...onical.com" <apw@...onical.com>,
"joe@...ches.com" <joe@...ches.com>,
"dwaipayanray1@...il.com" <dwaipayanray1@...il.com>,
"lukas.bulwahn@...il.com" <lukas.bulwahn@...il.com>,
"sumit.semwal@...aro.org" <sumit.semwal@...aro.org>,
"christian.koenig@....com" <christian.koenig@....com>,
Kerem Karabay <kekrby@...il.com>, Aun-Ali Zaidi <admin@...eit.net>,
Orlando Chamberlain <orlandoch.dev@...il.com>,
Atharva Tiwari <evepolonium@...il.com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
"linaro-mm-sig@...ts.linaro.org" <linaro-mm-sig@...ts.linaro.org>,
Hector Martin <marcan@...can.st>,
"linux@...linux.org.uk" <linux@...linux.org.uk>,
"asahi@...ts.linux.dev" <asahi@...ts.linux.dev>,
Sven Peter <sven@...npeter.dev>, Janne Grunau <j@...nau.net>
Subject: Re: [PATCH v3 3/3] drm/tiny: add driver for Apple Touch Bars in x86
Macs
On Mon, Feb 24, 2025 at 11:57:47AM +0000, Aditya Garg wrote:
> > On 24 Feb 2025, at 5:13 PM, andriy.shevchenko@...ux.intel.com wrote:
> > On Mon, Feb 24, 2025 at 11:20:12AM +0000, Aditya Garg wrote:
> >>
> >>> It would be nice to see the difference in the code generation for the all
> >>> __packed vs. only those that require it.
> >>>
> >>>> At least it's clear then
> >>>> what happens. And if your hardware requires this, you can't do much anyway.
> >>>
> >>> One aspect (member level alignment) is clear but the other is not
> >>> (object level alignment). I dunno if it makes sense to be pedantic about this,
> >>> but would like to see the binary outcome asked for.
> >>
> >> Hex dump of the compiled binary:
> >
> > Oh, sorry I wasn't clear. We have a script called bloat-o-meter for these
> > purposes. Please, run it with old and new binaries as parameters and share the
> > output.
> aditya@...Book:~/linux$ ./scripts/bloat-o-meter $PACKED $UNPACKED
> add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> Function old new delta
> Total: Before=13286, After=13286, chg +0.00%
Thanks! That shows that __packed can be used for all protocol related data
types. Just mention in the commit message that the __packed, even if not
needed, is: a) for the consistency, b) not affecting code generation in
accordance with bloat-o-meter.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists