netdev - Re: [PATCH 1/3] can: rcar_canfd: Add support for r8a779a0 SoC

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:   Mon, 18 Oct 2021 14:50:35 +0200
From:   Marc Kleine-Budde <mkl@...gutronix.de>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Ulrich Hecht <uli+renesas@...nd.eu>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>, linux-can@...r.kernel.org,
        "Lad, Prabhakar" <prabhakar.mahadev-lad.rj@...renesas.com>,
        Biju Das <biju.das.jz@...renesas.com>,
        Wolfram Sang <wsa@...nel.org>,
        Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
        Wolfgang Grandegger <wg@...ndegger.com>,
        Jakub Kicinski <kuba@...nel.org>, mailhol.vincent@...adoo.fr,
        socketcan@...tkopp.net
Subject: Re: [PATCH 1/3] can: rcar_canfd: Add support for r8a779a0 SoC

On 05.10.2021 15:06:22, Geert Uytterhoeven wrote:
> Hi Uli,
> 
> On Fri, Sep 24, 2021 at 5:38 PM Ulrich Hecht <uli+renesas@...nd.eu> wrote:
> > Adds support for the CANFD IP variant in the V3U SoC.
> >
> > Differences to controllers in other SoCs are limited to an increase in
> > the number of channels from two to eight, an absence of dedicated
> > registers for "classic" CAN mode, and a number of differences in magic
> > numbers (register offsets and layouts).
> >
> > Inspired by BSP patch by Kazuya Mizuguchi.
> >
> > Signed-off-by: Ulrich Hecht <uli+renesas@...nd.eu>
> 
> Thanks for your patch!
> 
> > --- a/drivers/net/can/rcar/rcar_canfd.c
> > +++ b/drivers/net/can/rcar/rcar_canfd.c
[...]
> >  /* RSCFDnCFDGERFL / RSCFDnGERFL */
> > +#define RCANFD_GERFL_EEF0_7            GENMASK(23, 16)
> >  #define RCANFD_GERFL_EEF1              BIT(17)
> >  #define RCANFD_GERFL_EEF0              BIT(16)
> >  #define RCANFD_GERFL_CMPOF             BIT(3)  /* CAN FD only */
> > @@ -86,20 +90,24 @@ enum rcanfd_chip_id {
> >  #define RCANFD_GERFL_MES               BIT(1)
> >  #define RCANFD_GERFL_DEF               BIT(0)
> >
> > -#define RCANFD_GERFL_ERR(gpriv, x)     ((x) & (RCANFD_GERFL_EEF1 |\
> > -                                       RCANFD_GERFL_EEF0 | RCANFD_GERFL_MES |\
> > -                                       (gpriv->fdmode ?\
> > -                                        RCANFD_GERFL_CMPOF : 0)))
> > +#define RCANFD_GERFL_ERR(gpriv, x)     ((x) & ((IS_V3U ? RCANFD_GERFL_EEF0_7 : \
> > +                                       (RCANFD_GERFL_EEF0 | RCANFD_GERFL_EEF1)) | \
> > +                                       RCANFD_GERFL_MES | ((gpriv)->fdmode ? \
> > +                                       RCANFD_GERFL_CMPOF : 0)))
> 
> I'm wondering if some of these IS_V3U checks can be avoided, improving
> legibility, by storing a feature struct instead of a chip_id in
> rcar_canfd_of_table[].data?

+1

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)