Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 3 May 2023 16:37:44 +0200
From:   Marc Kleine-Budde <mkl@pengutronix.de>
To:     Peter Hong <peter_hong@fintek.com.tw>
Cc:     Vincent MAILHOL <mailhol.vincent@wanadoo.fr>,
        Michal Swiatkowski <michal.swiatkowski@linux.intel.com>,
        wg@grandegger.com, Steen.Hegelund@microchip.com,
        davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
        pabeni@redhat.com, frank.jungclaus@esd.eu,
        linux-kernel@vger.kernel.org, linux-can@vger.kernel.org,
        netdev@vger.kernel.org, hpeter+linux_kernel@gmail.com
Subject: Re: [PATCH V5] can: usb: f81604: add Fintek F81604 support
Message-ID: <20230503-companion-sincere-573fc8d234d8-mkl@pengutronix.de>
References: <20230420024403.13830-1-peter_hong@fintek.com.tw>
 <CAMZ6RqKWrtBMFSD=BzGuCbvj=+3X-A-oW9haJ7=4kyL2AbEuHQ@mail.gmail.com>
 <51991fc1-0746-608f-b3bb-78b64e6d1a3e@fintek.com.tw>
 <CAMZ6Rq+zsC4F-mNhjKvqgPQuLhnnX1y79J=qOT8szPvkHY86VQ@mail.gmail.com>
 <f9c007ae-fcfb-4091-c202-2c27e3ba1151@fintek.com.tw>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="2zdnzbummcllnzbh"
Content-Disposition: inline
In-Reply-To: <f9c007ae-fcfb-4091-c202-2c27e3ba1151@fintek.com.tw>
Precedence: bulk


--2zdnzbummcllnzbh
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 02.05.2023 10:53:43, Peter Hong wrote:
> Hi Vincent, Michal and Marc,
>=20
> Vincent MAILHOL =E6=96=BC 2023/4/21 =E4=B8=8B=E5=8D=88 03:30 =E5=AF=AB=E9=
=81=93:
> > Hi Peter and Michal,
> >=20
> > On Fry. 21 Apr. 2023 at 12:14, Peter Hong <peter_hong@fintek.com.tw> wr=
ote:
> > > Hi Vincent,
> > >=20
> > > Vincent MAILHOL =E6=96=BC 2023/4/20 =E4=B8=8B=E5=8D=88 08:02 =E5=AF=
=AB=E9=81=93:
> > > > Hi Peter,
> > > >=20
> > > > Here are my comments. Now, it is mostly nitpicks. I guess that this=
 is
> > > > the final round.
> > > >=20
> > > > On Thu. 20 avr. 2023 at 11:44, Ji-Ze Hong (Peter Hong)
> > > > <peter_hong@fintek.com.tw> wrote:
> > > > > +static void f81604_handle_tx(struct f81604_port_priv *priv,
> > > > > +                            struct f81604_int_data *data)
> > > > > +{
> > > > > +       struct net_device *netdev =3D priv->netdev;
> > > > > +       struct net_device_stats *stats;
> > > > > +
> > > > > +       stats =3D &netdev->stats;
> > > > Merge the declaration with the initialization.
> > > If I merge initialization into declaration, it's may violation RCT?
> > > How could I change about this ?
> > @Michal: You requested RTC in:
> >=20
> > https://lore.kernel.org/linux-can/ZBgKSqaFiImtTThv@localhost.localdomai=
n/
> >=20
> > I looked at the kernel documentation but I could not find "Reverse
> > Chistmas Tree". Can you point me to where this is defined?
> >=20
> > In the above case, I do not think RCT should apply.
> >=20
> > I think that this:
> >=20
> >          struct net_device *netdev =3D priv->netdev;
> >          struct net_device_stats *stats =3D &netdev->stats;
> >=20
> > Is better than that:
> >=20
> >          struct net_device *netdev =3D priv->netdev;
> >          struct net_device_stats *stats;
> >=20
> >          stats =3D &netdev->stats;
> >=20
> > Arbitrarily splitting the definition and assignment does not make sense=
 to me.
> >=20
> > Thank you for your comments.
>=20
> The RCT coding style seems a bit confuse. How about refactoring of next
> step? @Marc ?

I don't are that much about RCT (so far my upstream has not complained).
Either of the above is fine with me.

regards,
Marc

--=20
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung N=C3=BCrnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

--2zdnzbummcllnzbh
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEDs2BvajyNKlf9TJQvlAcSiqKBOgFAmRScbUACgkQvlAcSiqK
BOg7fgf/Rcocbit+eYsSyvu1J/b+f2NEUYAwjDYH8JKZ3qY1jHq4uPsd81dYGTJA
MqBRikUZ9+9uIBf7oZPCapOYuVbSn8oRjphmRogLpJhos3xFOj9YyvK/ghypUbce
5Ywi7RI5VFeoSuxBYh/7uCyWB5dpGi59SUNXACijeBVva1cFluCvBeNVOJ98mAjV
oJp00jvJOtnsr8ARwxUWcM/y4N7N3276FQInKisfPCiiVPoec8xhplJRkr8kLcMB
aBsL29t4yy+5LTZJ4cE8GPS9sn1buJqnmKjKrLc1IWTsaWabv1QrKRKPx1SLK3ro
DeWlwoup2kKYXnccclJTGR6hmIlrhg==
=SrP+
-----END PGP SIGNATURE-----

--2zdnzbummcllnzbh--