linux-renesas-soc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ulrich Hecht <uli+renesas@fpond.eu>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	linux-can@vger.kernel.org, "Lad,
	Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	Biju Das <biju.das.jz@bp.renesas.com>,
	Wolfram Sang <wsa@kernel.org>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	Wolfgang Grandegger <wg@grandegger.com>,
	Jakub Kicinski <kuba@kernel.org>,
	mailhol.vincent@wanadoo.fr, socketcan@hartkopp.net
Subject: Re: [PATCH 1/3] can: rcar_canfd: Add support for r8a779a0 SoC
Date: Mon, 18 Oct 2021 14:50:35 +0200	[thread overview]
Message-ID: <20211018125035.mquerdthczmnazmg@pengutronix.de> (raw)
In-Reply-To: <CAMuHMdXk2mZntTBe3skSVkcNVjC-PzMwEv_MbH85Mvn1ZkFpHw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2021-10-18 12:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-24 15:31 [PATCH 0/3] can: rcar_canfd: Add support for V3U flavor Ulrich Hecht
2021-09-24 15:31 ` [PATCH 1/3] can: rcar_canfd: Add support for r8a779a0 SoC Ulrich Hecht
2021-09-24 16:34   ` Wolfram Sang
2021-09-28  8:47     ` Ulrich Hecht
2021-10-05 13:06   ` Geert Uytterhoeven
2021-10-18 12:50     ` Marc Kleine-Budde [this message]
2022-01-11 16:21     ` Ulrich Hecht
2021-09-24 15:31 ` [PATCH 2/3] dt-bindings: can: renesas,rcar-canfd: Document r8a779a0 support Ulrich Hecht
2021-10-05 13:15   ` Geert Uytterhoeven
2021-09-24 15:31 ` [PATCH 3/3] arm64: dts: r8a779a0: Add CANFD device node Ulrich Hecht
2021-10-05 13:20   ` Geert Uytterhoeven
2022-01-11 16:21     ` Ulrich Hecht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211018125035.mquerdthczmnazmg@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=davem@davemloft.net \
    --cc=geert@linux-m68k.org \
    --cc=kuba@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=mailhol.vincent@wanadoo.fr \
    --cc=netdev@vger.kernel.org \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
    --cc=socketcan@hartkopp.net \
    --cc=uli+renesas@fpond.eu \
    --cc=wg@grandegger.com \
    --cc=wsa@kernel.org \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).