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: <be751d7b-9216-4564-ad21-2df6a19477fa@quicinc.com>
Date: Mon, 30 Jun 2025 12:24:51 +0530
From: Mukesh Kumar Savaliya <quic_msavaliy@...cinc.com>
To: Haixu Cui <quic_haixcui@...cinc.com>, <broonie@...nel.org>,
        <virtio-dev@...ts.linux.dev>, <viresh.kumar@...aro.org>,
        <linux-spi@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <hdanton@...a.com>, <qiang4.zhang@...ux.intel.com>,
        <alex.bennee@...aro.org>
CC: <quic_ztu@...cinc.com>
Subject: Re: [RFC PATCH v5 3/3] SPI: Add virtio SPI driver.

Hi, Haixu, Thanks !

On 6/20/2025 9:42 AM, Haixu Cui wrote:
> This is the virtio SPI Linux kernel driver.
> 
> Signed-off-by: Haixu Cui <quic_haixcui@...cinc.com>
> ---
>   MAINTAINERS              |   6 +
>   drivers/spi/Kconfig      |  11 +
>   drivers/spi/Makefile     |   1 +
>   drivers/spi/spi-virtio.c | 444 +++++++++++++++++++++++++++++++++++++++
>   4 files changed, 462 insertions(+)
>   create mode 100644 drivers/spi/spi-virtio.c
> 

[...]

> + * So the corresponding relationship:
> + * A   <===> cs_setup_ns (after CS asserted)
And "before clock start" ? to be added in bracket as comment.
> + * B   <===> word_delay_ns (delay between adjacent words within a transfer)
> + * C+D <===> cs_delay_hold_ns (before CS deasserted)
> + * E+F <===> cs_change_delay_inactive_ns (after CS deasserted, these two
> + * values are also recommended in the Linux driver to be added up)
> + */

> +
> +static int virtio_spi_transfer_one(struct spi_controller *ctrl,
> +				   struct spi_device *spi,
> +				   struct spi_transfer *xfer)
> +{

[...]

> +	wait_for_completion(&priv->spi_req.completion);
> +
I see init_completion(spi_req.completion) is called during probe() but 
successive transfer doent have reinit_completion(spi_req.completion). 
wondering how is this working for back to back transfers.
> +	/* Read result from message and translate return code */
> +	switch (priv->spi_req.result.result) {
> +	case VIRTIO_SPI_TRANS_OK:
> +		/* ret is 0 */
> +		break;
> +	case VIRTIO_SPI_PARAM_ERR:
> +		ret = -EINVAL;
> +		break;
> +	case VIRTIO_SPI_TRANS_ERR:
> +		ret = -EIO;
> +		break;
> +	default: /* Protocol violation */
Comment in new line ? following same method across.
> +		ret = -EIO;
> +		break;
> +	}

[...]

> +static void virtio_spi_remove(struct virtio_device *vdev)
> +{
> +	struct spi_controller *ctrl = dev_get_drvdata(&vdev->dev);
> +
> +	/* Order: 1.) unregister controller, 2.) remove virtqueue */
Is this a specific flow for virtio OR generic ? if its generic, we can 
remove the comments.
> +	spi_unregister_controller(ctrl);
> +	virtio_spi_del_vq(vdev);
> +}
> +



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ