linux-spi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Jay Fang <f.fangjian@huawei.com>
Cc: linux-spi@vger.kernel.org, huangdaode@huawei.com
Subject: Re: [PATCH] spi: Add HiSilicon SPI controller driver support
Date: Mon, 1 Mar 2021 13:54:05 +0000	[thread overview]
Message-ID: <20210301135405.GC4628@sirena.org.uk> (raw)
In-Reply-To: <1614599771-33629-1-git-send-email-f.fangjian@huawei.com>

[-- Attachment #1: Type: text/plain, Size: 4984 bytes --]

On Mon, Mar 01, 2021 at 07:56:11PM +0800, Jay Fang wrote:

> This driver supports SPI Controller for HiSilicon Kunpeng SOCs. This
> driver supports SPI operations using FIFO mode of transfer.

> +HISILICON SPI Controller Driver
> +M:	Jay Fang <f.fangjian@huawei.com>
> +L:	linux-spi@vger.kernel.org
> +S:	Maintained
> +W:	http://www.hisilicon.com
> +F:	drivers/spi/spi-hisi.c

Please give this a more specific name, the commit message already says
this is for the Kunpeng SoCs but HiSilicon has other products, or may
choose to use a different IP in some future Kunpeng part for that
matter.

>  obj-$(CONFIG_SPI_GPIO)			+= spi-gpio.o
>  obj-$(CONFIG_SPI_HISI_SFC_V3XX)		+= spi-hisi-sfc-v3xx.o
> +obj-$(CONFIG_SPI_HISI)			+= spi-hisi.o

Please keep the Kconfig and Makefile sorted.

> +++ b/drivers/spi/spi-hisi.c
> @@ -0,0 +1,573 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*

Please make the entire comment a C++ one so things look more
intentional.

> + * HiSilicon SPI Controller Driver (refer spi-dw-core.c)

This comment suggests that this is a variation of the DesignWare
controller if that is the case please extend that driver rather than
adding a totally new one.

> +/* Disable IRQ bits */
> +static void hisi_spi_mask_intr(struct hisi_spi *hs, u32 mask)
> +{
> +	u32 new_mask;
> +
> +	new_mask = readl(hs->regs + HISI_SPI_IMR) | mask;
> +	writel(new_mask, hs->regs + HISI_SPI_IMR);
> +}

This is a read/modify/write cycle and appears to be called from at least
process and interrupt context but I'm not seeing anything that stops two
different callers of it or the matching unmask function from running at
the same time.

> +	while (hisi_spi_rx_not_empty(hs) && max--) {
> +		rxw = readl(hs->regs + HISI_SPI_DOUT);
> +		/* Check the transfer's original "rx" is not null */
> +		if (hs->rx) {
> +			switch (hs->n_bytes) {
> +			case HISI_SPI_N_BYTES_U8:
> +				*(u8 *)(hs->rx) = rxw;
> +				break;
> +			case HISI_SPI_N_BYTES_U16:
> +				*(u16 *)(hs->rx) = rxw;
> +				break;
> +			case HISI_SPI_N_BYTES_U32:
> +				*(u32 *)(hs->rx) = rxw;
> +				break;
> +			}
> +			hs->rx += hs->n_bytes;
> +		}
> +		--hs->rx_len;

You can probably get better performance by running some of the transfers
in 32 bit or 16 bit mode, no need to do that to merge the driver though.
Also are you sure that the length is tracked properly for things that
aren't bytes?

> +static irqreturn_t hisi_spi_handle_transfer(struct hisi_spi *hs,
> +			u32 irq_status)
> +{
> +	struct spi_controller *master = hs->master;
> +
> +	/* Error handling */
> +	if (irq_status & ISR_RXOF) {
> +		dev_err(&master->dev, "%s\n",
> +			"interrupt_transfer: fifo overflow");

There is no need to use the %s here, it just makes the display more
confusing.

> +static irqreturn_t hisi_spi_irq(int irq, void *dev_id)
> +{
> +	struct spi_controller *master = dev_id;
> +	struct hisi_spi *hs = spi_controller_get_devdata(master);
> +	u32 irq_status = readl(hs->regs + HISI_SPI_ISR) & ISR_MASK;
> +
> +	if (!irq_status)
> +		return IRQ_NONE;
> +
> +	if (!master->cur_msg) {
> +		hisi_spi_mask_intr(hs, IMR_MASK);
> +		return IRQ_HANDLED;
> +	}
> +
> +	return hisi_spi_handle_transfer(hs, irq_status);

It's probably clearer to just merge the two bits of this interrupt
handler here, it's a bit confusing that they're separate functions and
there's only the one caller of _handle_transfer().

> +static int hisi_spi_transfer_one(struct spi_controller *master,
> +		struct spi_device *spi, struct spi_transfer *transfer)
> +{
> +	struct hisi_spi *hs = spi_controller_get_devdata(master);
> +
> +	hs->n_bytes = hisi_spi_n_bytes(transfer);
> +	hs->tx = (void *)transfer->tx_buf;

If there's a need to cast to void * something is very wrong here.

> +	hs->tx_len = transfer->len / hs->n_bytes;
> +	hs->rx = transfer->rx_buf;
> +	hs->rx_len = hs->tx_len;
> +
> +	/* Ensure the data above is visible for all CPUs */
> +	smp_mb();

This memory barrier seems worrying...  are you *sure* this is the best
way to sync, and that the sync is best done here if it is needed rather
than after everything else is set up?

> +
> +	/* Disable is needed to deal with transfer timeout */
> +	hisi_spi_disable(hs);
> +
> +	hisi_spi_flush_fifo(hs);
> +	hisi_spi_update_cr(hs, spi, transfer);

Especially given this, if there may be some left over operations going
on elsewhere might there be races due to that?  I'm also wondering if
it's faster to just reset the controller as is done in some error
handling paths.

> +	ret = devm_request_irq(dev, hs->irq, hisi_spi_irq, IRQF_SHARED,
> +				dev_name(dev), master);
> +	if (ret < 0) {
> +		dev_err(dev, "failed to get IRQ=%d, ret=%d\n", hs->irq, ret);
> +		return ret;
> +	}

This will free the IRQ *after* the controller is unregistered, it's
better to manually free the interrupt

> +	ret = hisi_spi_add_host(&pdev->dev, hs);
> +	if (ret)
> +		return ret;

I don't see much value in splitting this out from the main probe
function, again it's just making the code a bit more complex.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2021-03-01 13:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-01 11:56 [PATCH] spi: Add HiSilicon SPI controller driver support Jay Fang
2021-03-01 13:54 ` Mark Brown [this message]
2021-03-04  6:54   ` Fangjian (Jay)
     [not found]   ` <79a0bb79-654b-8afc-f34a-c3a08bae275c@huawei.com>
2021-03-04 12:34     ` Mark Brown
2021-03-08 11:24       ` Jay Fang
2021-03-07 14:43   ` Lukas Wunner
2021-03-08 14:11     ` Mark Brown
2021-03-08 18:18       ` Lukas Wunner
2021-03-08 18:28         ` Mark Brown
2021-03-09  9:13     ` Jay Fang
2021-03-07 14:36 ` Lukas Wunner
2021-03-08  3:57   ` Jay Fang
2021-03-08  8:06     ` Lukas Wunner

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=20210301135405.GC4628@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=f.fangjian@huawei.com \
    --cc=huangdaode@huawei.com \
    --cc=linux-spi@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).