[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdWdy2YVxmXT2vPj+3OEJpqj+miTVjhCVuEYpXC8iHXPXA@mail.gmail.com>
Date: Mon, 1 Sep 2025 15:37:51 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Biju <biju.das.au@...il.com>
Cc: Marc Kleine-Budde <mkl@...gutronix.de>, Vincent Mailhol <mailhol.vincent@...adoo.fr>,
Magnus Damm <magnus.damm@...il.com>, Biju Das <biju.das.jz@...renesas.com>,
linux-can@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
linux-kernel@...r.kernel.org,
Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH v2 3/4] can: rcar_canfd: Simplify nominal bit rate config
Hi Biju,
On Thu, 21 Aug 2025 at 16:14, Biju <biju.das.au@...il.com> wrote:
> From: Biju Das <biju.das.jz@...renesas.com>
>
> Introduce rcar_canfd_compute_nominal_bit_rate_cfg() for simplifying
> nominal bit rate configuration by replacing function-like macros.
>
> Signed-off-by: Biju Das <biju.das.jz@...renesas.com>
> ---
> v1->v2:
> * Split from patch#3 for computing nominal bit rate config separate.
> * Updated rcar_canfd_compute_nominal_bit_rate_cfg() to handle
> nominal bit rate configuration for both classical CAN and CANFD.
> * Replaced RCANFD_NCFG_NBRP->RCANFD_NCFG_NBRP_MASK and used FIELD_PREP to
> extract value.
Thanks for your patch!
Your patch is correct, so
Reviewed-by: Geert Uytterhoeven <geert+renesas@...der.be>
Still a few suggestions for improvement below...
> --- a/drivers/net/can/rcar/rcar_canfd.c
> +++ b/drivers/net/can/rcar/rcar_canfd.c
> @@ -109,16 +109,7 @@
> #define RCANFD_CFG_BRP_MASK GENMASK(9, 0)
>
> /* RSCFDnCFDCmNCFG - CAN FD only */
> -#define RCANFD_NCFG_NTSEG2(gpriv, x) \
> - (((x) & ((gpriv)->info->nom_bittiming->tseg2_max - 1)) << (gpriv)->info->sh->ntseg2)
> -
> -#define RCANFD_NCFG_NTSEG1(gpriv, x) \
> - (((x) & ((gpriv)->info->nom_bittiming->tseg1_max - 1)) << (gpriv)->info->sh->ntseg1)
> -
> -#define RCANFD_NCFG_NSJW(gpriv, x) \
> - (((x) & ((gpriv)->info->nom_bittiming->sjw_max - 1)) << (gpriv)->info->sh->nsjw)
> -
> -#define RCANFD_NCFG_NBRP(x) (((x) & 0x3ff) << 0)
> +#define RCANFD_NCFG_NBRP_MASK GENMASK(9, 0)
I would drop the "_MASK" suffix.
> @@ -1393,6 +1384,28 @@ static irqreturn_t rcar_canfd_channel_interrupt(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> +static inline u32 rcar_canfd_compute_nominal_bit_rate_cfg(struct rcar_canfd_channel *priv,
> + u16 tseg1, u16 brp, u16 sjw, u16 tseg2)
Perhaps follow the order as used in struct can_bittiming{_const}?
I.e. tseg1, tseg2, sjw, brp.
> +{
> + struct rcar_canfd_global *gpriv = priv->gpriv;
> + const struct rcar_canfd_hw_info *info = gpriv->info;
> + u32 ntseg2, ntseg1, nsjw, nbrp;
> +
> + if ((priv->can.ctrlmode & CAN_CTRLMODE_FD) || gpriv->info->shared_can_regs) {
> + ntseg2 = (tseg2 & (info->nom_bittiming->tseg2_max - 1)) << info->sh->ntseg2;
> + ntseg1 = (tseg1 & (info->nom_bittiming->tseg1_max - 1)) << info->sh->ntseg1;
> + nsjw = (sjw & (info->nom_bittiming->sjw_max - 1)) << info->sh->nsjw;
> + nbrp = FIELD_PREP(RCANFD_NCFG_NBRP_MASK, brp);
Perhaps use the order of the function parameters?
> + } else {
> + ntseg2 = FIELD_PREP(RCANFD_CFG_TSEG2_MASK, tseg2);
> + ntseg1 = FIELD_PREP(RCANFD_CFG_TSEG1_MASK, tseg1);
> + nsjw = FIELD_PREP(RCANFD_CFG_SJW_MASK, sjw);
> + nbrp = FIELD_PREP(RCANFD_CFG_BRP_MASK, brp);
Likewise.
> + }
> +
> + return (ntseg1 | nbrp | nsjw | ntseg2);
Likewise.
> +}
> +
> static void rcar_canfd_set_bittiming(struct net_device *ndev)
> {
> u32 mask = RCANFD_FDCFG_TDCO | RCANFD_FDCFG_TDCE | RCANFD_FDCFG_TDCOC;
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