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] [thread-next>] [day] [month] [year] [list]

Date: Thu, 6 Jun 2024 12:15:19 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Vincent MAILHOL <mailhol.vincent@...adoo.fr>
Cc: Marc Kleine-Budde <mkl@...gutronix.de>, 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 Vincent,

On Sun, Jun 2, 2024 at 10:03 AM Vincent MAILHOL
<mailhol.vincent@...adoo.fr> wrote:
> On Wed. 29 May 2024 at 18:12, Geert Uytterhoeven
> <geert+renesas@...der.be> wrote:
> > The main CAN clock is either the internal CANFD clock, or the external
> > CAN clock.  Hence replace the two-valued enum by a simple boolean flag.
> > Consolidate all CANFD clock handling inside a single branch.
>
> For what it is worth, your patch also saves up to 8 bytes in struct
> rcar_canfd_global (depends on the architecture).

True.

> > @@ -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).
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...

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