netdev - Re: [PATCH 1/3] can: rcar_canfd: Simplify clock handling

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Fri, 21 Jun 2024 13:27:58 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Marc Kleine-Budde <mkl@...gutronix.de>
Cc: Vincent MAILHOL <mailhol.vincent@...adoo.fr>, 
	Wolfram Sang <wsa+renesas@...g-engineering.com>, linux-can@...r.kernel.org, 
	linux-renesas-soc@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 1/3] can: rcar_canfd: Simplify clock handling

Hi Marc,

On Fri, Jun 21, 2024 at 10:36 AM Marc Kleine-Budde <mkl@...gutronix.de> wrote:
> On 06.06.2024 13:38:24, Geert Uytterhoeven wrote:
> > > > > > @@ -545,8 +539,8 @@ struct rcar_canfd_global {
> > > > > >         struct platform_device *pdev;   /* Respective platform device */
> > > > > >         struct clk *clkp;               /* Peripheral clock */
> > > > > >         struct clk *can_clk;            /* fCAN clock */
> > > > > > -       enum rcar_canfd_fcanclk fcan;   /* CANFD or Ext clock */
> > > > > >         unsigned long channels_mask;    /* Enabled channels mask */
> > > > > > +       bool extclk;                    /* CANFD or Ext clock */
> > > > > >         bool fdmode;                    /* CAN FD or Classical CAN only mode */
> > > > >
> > > > > Notwithstanding comment: you may consider to replace those two booleans by a:
> > > > >
> > > > >           unsigned int flags;
> > > > >
> > > > > This way, no more fields would be needed in the future if more quirks are added.
> > > >
> > > > Using "unsigned int flags" and BIT(x) flags would increase code size
> > > > by 8 bytes (arm/arm64).
> > >
> > > I am not sure where you derive your figure from, but looking at the pahole:
> >
> > pahole shows the size of data structures.
> >
> > > > Using "unsigned int foo:1" bitfields would increase code size by 16
> > > > (arm) or 12 (arm64) bytes.
> > > > So as long as we can fit more bools inside the hole, it is more
> > > > efficient to do so...
> > >
> > > I do not get this either. Where did you get your 16 bytes from? If I do:
> >
> > I also looked at code size[*]: while storing bits takes less space than
> > storing bytes, processing bits may require more instructions than
> > processing bytes (depending on the architecture).
> >
> > [*] size drivers/net/can/rcar/rcar_canfd.o
>
> You have probably used "scripts/bloat-o-meter" from the kernel source
> for this, right?

Not this time; I used "size" from the binutils package instead.

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