mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Harald Mommer <harald.mommer@opensynergy.com>
To: Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	Mikhail Golubev-Ciuchea <Mikhail.Golubev-Ciuchea@opensynergy.com>,
	Wolfgang Grandegger <wg@grandegger.com>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: Damir Shaikhutdinov <Damir.Shaikhutdinov@opensynergy.com>,
	linux-kernel@vger.kernel.org, linux-can@vger.kernel.org,
	netdev@vger.kernel.org, virtualization@lists.linux.dev
Subject: Re: [PATCH v5] can: virtio: Initial virtio CAN driver.
Date: Thu, 1 Feb 2024 19:57:45 +0100	[thread overview]
Message-ID: <0878aedf-35c2-4901-8662-2688574dd06f@opensynergy.com> (raw)
In-Reply-To: <a366f529-c901-4cd1-a1a6-c3958562cace@wanadoo.fr>

Hello,

I thought there would be some more comments coming and I could address 
everything in one chunk. Not the case, besides your comments silence.

On 08.01.24 20:34, Christophe JAILLET wrote:
>
> Hi,
> a few nits below, should there be a v6.
>

I'm sure there will be but not so soon. Probably after acceptance of the 
virtio CAN specification or after change requests to the specification 
are received and the driver has to be adapted to an updated draft.


>
>> +static int virtio_can_alloc_tx_idx(struct virtio_can_priv *priv)
>> +{
>> +    int tx_idx;
>> +
>> +    tx_idx = ida_alloc_range(&priv->tx_putidx_ida, 0,
>> +                 priv->can.echo_skb_max - 1, GFP_KERNEL);
>> +    if (tx_idx >= 0)
>> +        atomic_add(1, &priv->tx_inflight);
>
> atomic_inc() ?


Yes, will be done, already in my local code base.


>
>> +
>> +    return tx_idx;
>> +}
>> +
>> +static void virtio_can_free_tx_idx(struct virtio_can_priv *priv,
>> +                   unsigned int idx)
>> +{
>> +    ida_free(&priv->tx_putidx_ida, idx);
>> +    atomic_sub(1, &priv->tx_inflight);
>
> atomic_dec() ?


See above.


>
>> +}
>
> ...
>
>> +static int virtio_can_probe(struct virtio_device *vdev)
>> +{
>> +    struct virtio_can_priv *priv;
>> +    struct net_device *dev;
>> +    int err;
>> +
>> +    dev = alloc_candev(sizeof(struct virtio_can_priv),
>> +               VIRTIO_CAN_ECHO_SKB_MAX);
>> +    if (!dev)
>> +        return -ENOMEM;
>> +
>> +    priv = netdev_priv(dev);
>> +
>> +    ida_init(&priv->tx_putidx_ida);
>> +
>> +    netif_napi_add(dev, &priv->napi, virtio_can_rx_poll);
>> +    netif_napi_add(dev, &priv->napi_tx, virtio_can_tx_poll);
>> +
>> +    SET_NETDEV_DEV(dev, &vdev->dev);
>> +
>> +    priv->dev = dev;
>> +    priv->vdev = vdev;
>> +    vdev->priv = priv;
>> +
>> +    priv->can.do_set_mode = virtio_can_set_mode;
>> +    /* Set Virtio CAN supported operations */
>> +    priv->can.ctrlmode_supported = CAN_CTRLMODE_BERR_REPORTING;
>> +    if (virtio_has_feature(vdev, VIRTIO_CAN_F_CAN_FD)) {
>> +        err = can_set_static_ctrlmode(dev, CAN_CTRLMODE_FD);
>> +        if (err != 0)
>> +            goto on_failure;
>> +    }
>> +
>> +    /* Initialize virtqueues */
>> +    err = virtio_can_find_vqs(priv);
>> +    if (err != 0)
>> +        goto on_failure;
>> +
>> +    INIT_LIST_HEAD(&priv->tx_list);
>> +
>> +    spin_lock_init(&priv->tx_lock);
>> +    mutex_init(&priv->ctrl_lock);
>> +
>> +    init_completion(&priv->ctrl_done);
>> +
>> +    virtio_can_populate_vqs(vdev);
>> +
>> +    register_virtio_can_dev(dev);
>
> Check for error?


     err = register_virtio_can_dev(dev);
     if (err) {
         virtio_can_del_vq(vdev);
         dev_err(&vdev->dev, "Couldn't register candev (err=%d)\n", err);
         goto on_failure;
     }


>
> CJ
>
>> +
>> +    napi_enable(&priv->napi);
>> +    napi_enable(&priv->napi_tx);
>> +
>> +    /* Request device going live */
>> +    virtio_device_ready(vdev); /* Optionally done by 
>> virtio_dev_probe() */


The virtio_device_ready() will also be removed. The caller will make the 
device live anyway after return. There are no operations between the 
virtio_device_ready() and the return 0 which make it necessary to have 
the device live early before the return.


>> +
>> +    return 0;
>> +
>> +on_failure:
>> +    virtio_can_free_candev(dev);
>> +    return err;
>> +}
>
> ...
>


  reply	other threads:[~2024-02-01 18:57 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-08 13:10 Mikhail Golubev-Ciuchea
2024-01-08 19:34 ` Christophe JAILLET
2024-02-01 18:57   ` Harald Mommer [this message]
2025-03-12 10:31     ` Matias Ezequiel Vara Larsen
2025-03-12 10:41       ` Marc Kleine-Budde
2025-03-12 13:28         ` Matias Ezequiel Vara Larsen
2025-03-12 13:36           ` Marc Kleine-Budde
2025-03-12 15:11             ` Matias Ezequiel Vara Larsen
2025-03-13  0:26             ` Jason Wang
2025-03-13 18:48     ` Matias Ezequiel Vara Larsen
2025-09-11 20:59 ` Francesco Valla
2025-10-01 15:23   ` Matias Ezequiel Vara Larsen
2025-10-10 15:46   ` Matias Ezequiel Vara Larsen
2025-10-10 21:20     ` Francesco Valla
2025-10-13  9:52       ` Matias Ezequiel Vara Larsen
2025-10-13 16:29         ` Francesco Valla
2025-10-13 18:07           ` Matias Ezequiel Vara Larsen
2025-10-13 14:15       ` Matias Ezequiel Vara Larsen
2025-10-13 16:35   ` Matias Ezequiel Vara Larsen
2025-10-14  6:54     ` Francesco Valla
2025-10-14 10:42       ` Matias Ezequiel Vara Larsen
2025-10-14 10:15   ` Matias Ezequiel Vara Larsen
2025-10-14 16:01     ` Francesco Valla
2025-10-20 14:56       ` Matias Ezequiel Vara Larsen
2025-10-20 21:24         ` Francesco Valla
2025-10-21  9:40           ` Matias Ezequiel Vara Larsen
2025-10-21 12:08             ` Francesco Valla
2025-10-21 13:15               ` Matias Ezequiel Vara Larsen
2025-10-31 12:21                 ` Matias Ezequiel Vara Larsen
2025-10-14 10:25   ` Matias Ezequiel Vara Larsen

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=0878aedf-35c2-4901-8662-2688574dd06f@opensynergy.com \
    --to=harald.mommer@opensynergy.com \
    --cc=Damir.Shaikhutdinov@opensynergy.com \
    --cc=Mikhail.Golubev-Ciuchea@opensynergy.com \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jasowang@redhat.com \
    --cc=kuba@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=virtualization@lists.linux.dev \
    --cc=wg@grandegger.com \
    --cc=xuanzhuo@linux.alibaba.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

all inboxes | Powered by JetHome®