netdev - Re: [PATCH v2 4/7] can: Add Nuvoton NCT6694 CAN support

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]

Message-ID: <CAOoeyxUaJwd5_tSLFxUJBB47G0y1p3dr4zeMx3Qkx3KVrQNa9A@mail.gmail.com>
Date: Fri, 22 Nov 2024 17:51:02 +0800
From: Ming Yu <a0282524688@...il.com>
To: Vincent Mailhol <mailhol.vincent@...adoo.fr>
Cc: tmyu0@...oton.com, lee@...nel.org, linus.walleij@...aro.org, brgl@...ev.pl, 
	andi.shyti@...nel.org, mkl@...gutronix.de, andrew+netdev@...n.ch, 
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, 
	wim@...ux-watchdog.org, linux@...ck-us.net, jdelvare@...e.com, 
	alexandre.belloni@...tlin.com, linux-kernel@...r.kernel.org, 
	linux-gpio@...r.kernel.org, linux-i2c@...r.kernel.org, 
	linux-can@...r.kernel.org, netdev@...r.kernel.org, 
	linux-watchdog@...r.kernel.org, linux-hwmon@...r.kernel.org, 
	linux-rtc@...r.kernel.org
Subject: Re: [PATCH v2 4/7] can: Add Nuvoton NCT6694 CAN support

Dear Vincent,

Vincent Mailhol <mailhol.vincent@...adoo.fr> 於 2024年11月22日 週五 下午4:25寫道：
> > > > +static int nct6694_canfd_start(struct net_device *ndev)
> > > > +{
> > > > +     struct nct6694_canfd_priv *priv = netdev_priv(ndev);
> > > > +     struct nct6694_can_cmd0 *buf = (struct nct6694_can_cmd0 *)priv->tx_buf;
> > >
> > > Give a more memorable name to buf, for example: bittiming_cmd.
> > >
> >
> > Got it. So, every buf that uses a command must be renamed similarly, right?
>
> Yes. Note that you can use different names if you have a better idea.
> It is just that generic names like "buf" or "cmd1" do not tell me what
> this variable actually is. On the contrary, bittiming_cmd tells me
> that this variable holds the payload for the command to set the device
> bittiming. This way, suddenly, the code becomes easier to read and
> understand. As long as your naming conveys this kind of information,
> then I am fine with whatever you choose, just avoid the "buf" or
> "cmd1" names.
>

Understood. I will make the modifications in v3.

> > > > +     const struct can_bittiming *n_bt = &priv->can.bittiming;
> > > > +     const struct can_bittiming *d_bt = &priv->can.data_bittiming;
...
> > > > +static netdev_tx_t nct6694_canfd_start_xmit(struct sk_buff *skb,
> > > > +                                         struct net_device *ndev)
> > > > +{
> > > > +     struct nct6694_canfd_priv *priv = netdev_priv(ndev);
> > > > +
> > > > +     if (priv->tx_skb || priv->tx_busy) {
> > > > +             netdev_err(ndev, "hard_xmit called while tx busy\n");
> > > > +             return NETDEV_TX_BUSY;
> > > > +     }
> > > > +
> > > > +     if (can_dev_dropped_skb(ndev, skb))
> > > > +             return NETDEV_TX_OK;
> > > > +
> > > > +     netif_stop_queue(ndev);
> > >
> > > Here, you are inconditionally stopping the queue. Does it mean that your
> > > device is only able to manage one CAN frame at the time?
> > >
> >
> > Yes, we designed it to manage a single CAN frame, so we stop the queue
> > here until a TX event is received to wake queue.
>
> Do you mean that the device is designed to manage only one single CAN
> frame or is the driver designed to only manage one single CAN frame?
> If the device is capable of handling several CAN frames, your driver
> should take advantage of this. Else the driver will slow down the
> communication a lot whenever packets start to accumulate in the TX
> queue.
>

I understand, but our device currently supports handling only one CAN frame.

Best regards,
Ming