Hi Vincent, > -----Original Message----- > From: Vincent Mailhol <mailhol.vincent@xxxxxxxxxx> > Sent: 28 March 2025 12:41 > Subject: Re: [PATCH v7 09/18] can: rcar_canfd: Add max_aflpn variable to struct rcar_canfd_hw_info > > On 28/03/2025 at 20:17, Biju Das wrote: > > Hi Vincent, > > > >> -----Original Message----- > >> From: Vincent Mailhol <mailhol.vincent@xxxxxxxxxx> > >> Sent: 28 March 2025 11:06 > >> Subject: Re: [PATCH v7 09/18] can: rcar_canfd: Add max_aflpn variable > >> to struct rcar_canfd_hw_info > >> > >> On 26/03/2025 at 21:19, Biju Das wrote: > >>> R-Car Gen3 has maximum acceptance filter list page number of 31 > >>> whereas on R-Car Gen4 it is 127. Add max_aflpn variable to struct > >>> rcar_canfd_hw_info in order to support RZ/G3E that has max AFLPN of 63. > >>> > >>> Reviewed-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx> > >>> Signed-off-by: Biju Das <biju.das.jz@xxxxxxxxxxxxxx> > >> > >> With below nitpick addressed, you can add my: > >> > >> Reviewed-by: Vincent Mailhol <mailhol.vincent@xxxxxxxxxx> > >> > >>> --- > >>> v6->v7: > >>> * Collected tag. > >>> v6: > >>> * New patch. > >>> --- > >>> drivers/net/can/rcar/rcar_canfd.c | 6 +++++- > >>> 1 file changed, 5 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/drivers/net/can/rcar/rcar_canfd.c > >>> b/drivers/net/can/rcar/rcar_canfd.c > >>> index 62cde1efa0c0..7cef0673fbc8 100644 > >>> --- a/drivers/net/can/rcar/rcar_canfd.c > >>> +++ b/drivers/net/can/rcar/rcar_canfd.c > >>> @@ -93,7 +93,7 @@ > >>> > >>> /* RSCFDnCFDGAFLECTR / RSCFDnGAFLECTR */ > >>> #define RCANFD_GAFLECTR_AFLDAE BIT(8) > >>> -#define RCANFD_GAFLECTR_AFLPN(gpriv, x) ((x) & reg_gen4(gpriv, 0x7f, 0x1f)) > >>> +#define RCANFD_GAFLECTR_AFLPN(gpriv, x) ((x) & (gpriv)->info->max_aflpn) > >> ^ While at it, can you rename > >> that x to page_num in the next version? I don't mind if you do it in the same patch. > >> > >> I understand it was here before, but that's will be a nice quality of life improvement. > >> > >> Please do the same for the other macro which you are modifying in > >> this series (I am not asking you to rewrite the full driver, so only do local improvement on the > parts you are touching). > > > > Is it ok, if I send a separate patch for that conversion for all > > macros which will avoid inconsistency in the driver as some macros > > will have x and some macros with meaning full name? > > This also works! Also OK if you prefer to send this in a separate series together with the removal of > the unused macros. Thanks. Biju
