| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAMuHMdWJx6Ahw6ASOn0bvg0gm6CBs2KnEsThJ8RSgdrHXqSVJA@mail.gmail.com>
Date: Fri, 10 Dec 2021 09:04:58 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: "Gabriel L. Somlo" <gsomlo@...il.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Rob Herring <robh+dt@...nel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>, Ulf Hansson <ulf.hansson@...aro.org>,
Linux MMC List <linux-mmc@...r.kernel.org>,
Karol Gugala <kgugala@...micro.com>,
Mateusz Holenko <mholenko@...micro.com>,
Kamil Rakoczy <krakoczy@...micro.com>,
mdudek@...ernships.antmicro.com,
Paul Mackerras <paulus@...abs.org>,
Joel Stanley <joel@....id.au>,
Stafford Horne <shorne@...il.com>,
david.abdurachmanov@...ive.com,
Florent Kermarrec <florent@...oy-digital.fr>,
Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH v2 3/3] mmc: Add driver for LiteX's LiteSDCard interface
Hi Gabriel,
On Thu, Dec 9, 2021 at 9:58 PM Gabriel L. Somlo <gsomlo@...il.com> wrote:
> On Thu, Dec 09, 2021 at 09:31:49AM +0100, Geert Uytterhoeven wrote:
> > On Wed, Dec 8, 2021 at 9:14 PM Gabriel L. Somlo <gsomlo@...il.com> wrote:
> > > I did *some* of this for v3, but since figured out how to use `pahole` :)
> >
> > Right, pahole.
> >
> > > On Mon, Dec 06, 2021 at 11:07:56AM +0100, Geert Uytterhoeven wrote:
> > > > > +struct litex_mmc_host {
> > > > > + struct mmc_host *mmc;
> > > > > + struct platform_device *dev;
> > > > > +
> > > > > + void __iomem *sdphy;
> > > > > + void __iomem *sdcore;
> > > > > + void __iomem *sdreader;
> > > > > + void __iomem *sdwriter;
> > > > > + void __iomem *sdirq;
> > > > > +
> > > > > + u32 resp[4];
> > > > > + u16 rca;
> > > > > +
> > > > > + void *buffer;
> > > > > + size_t buf_size;
> > > > > + dma_addr_t dma;
> > > > > +
> > > > > + unsigned int freq;
> > > > > + unsigned int clock;
> > > > > + bool is_bus_width_set;
> > > > > + bool app_cmd;
> > > > > +
> > > > > + int irq;
> > > > > + struct completion cmd_done;
> > > >
> > > > You may want to reorder the members to avoid implicit gaps
> > > > (i.e. structs first, followed by integral types in decreasing size).
> > >
> > > So, for v4, I'll have it looking like this, which `pahole` says is
> > > optimally packed:
> > >
> > > struct litex_mmc_host {
> > > struct mmc_host * mmc; /* 0 8 */
> > > struct platform_device * dev; /* 8 8 */
> > > void * sdphy; /* 16 8 */
> > > void * sdcore; /* 24 8 */
> > > void * sdreader; /* 32 8 */
> > > void * sdwriter; /* 40 8 */
> > > void * sdirq; /* 48 8 */
> > > void * buffer; /* 56 8 */
> > > /* --- cacheline 1 boundary (64 bytes) --- */
> > > size_t buf_size; /* 64 8 */
> >
> > size_t is 32-bit on RV32, so you may want to move it below cmd_done.
> >
> > > dma_addr_t dma; /* 72 8 */
> > > struct completion cmd_done; /* 80 32 */
> > > int irq; /* 112 4 */
> > > unsigned int ref_clk; /* 116 4 */
> > > unsigned int sd_clk; /* 120 4 */
> > > u32 resp[4]; /* 124 16 */
> > > /* --- cacheline 2 boundary (128 bytes) was 12 bytes ago --- */
> > > u16 rca; /* 140 2 */
> > > bool is_bus_width_set; /* 142 1 */
> > > bool app_cmd; /* 143 1 */
> > >
> > > /* size: 144, cachelines: 3, members: 18 */
> > > /* last cacheline: 16 bytes */
> > > };
>
> After a bit of a fight, I managed to wrestle `pahole` to display useful
> information for 32-bit (rv32imac) builds:
>
> struct litex_mmc_host {
> struct mmc_host * mmc; /* 0 4 */
> struct platform_device * dev; /* 4 4 */
> void * sdphy; /* 8 4 */
> void * sdcore; /* 12 4 */
> void * sdreader; /* 16 4 */
> void * sdwriter; /* 20 4 */
> void * sdirq; /* 24 4 */
> void * buffer; /* 28 4 */
> size_t buf_size; /* 32 4 */
> dma_addr_t dma; /* 36 4 */
> struct completion cmd_done; /* 40 16 */
> int irq; /* 56 4 */
> unsigned int ref_clk; /* 60 4 */
> /* --- cacheline 1 boundary (64 bytes) --- */
> unsigned int sd_clk; /* 64 4 */
> u32 resp[4]; /* 68 16 */
> u16 rca; /* 84 2 */
> bool is_bus_width_set; /* 86 1 */
> bool app_cmd; /* 87 1 */
>
> /* size: 88, cachelines: 2, members: 18 */
> /* last cacheline: 24 bytes */
> };
>
> Looks like even with `size_t buf_size` where it is right now, there
> still are no holes. I like it where it is, as it's related to the
Right, dma_addr_t is 32-bit, too. I'm just too used to LPAE on ARM ;-)
> field immediately preceding it (`buffer`). I'd rather not move it,
> particularly since we're not actually eliminating any additional
> holes.
Thanks, LGTM.
> What do you think (i.e., is there a configuration where there's still
> a chance we may run into trouble)?
ICONFIG_PHYS_ADDR_T_64BIT=y/CONFIG_ARCH_DMA_ADDR_T_64BIT=y
on 32-bit, but that doesn't seem to be supported under arch/risc/ yet.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists