linux-kernel - Re: [RFC PATCH v11 02/10] spi: rockchip-sfc: add rockchip serial flash controller

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210707174735.GL4394@sirena.org.uk>
Date:   Wed, 7 Jul 2021 18:47:35 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Jon Lin <jon.lin@...k-chips.com>
Cc:     linux-spi@...r.kernel.org, robh+dt@...nel.org, heiko@...ech.de,
        jbx6244@...il.com, hjc@...k-chips.com, yifeng.zhao@...k-chips.com,
        sugar.zhang@...k-chips.com, linux-rockchip@...ts.infradead.org,
        linux-mtd@...ts.infradead.org, p.yadav@...com,
        macroalpha82@...il.com, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        mturquette@...libre.com, sboyd@...nel.org,
        linux-clk@...r.kernel.org, Chris Morgan <macromorgan@...mail.com>
Subject: Re: [RFC PATCH v11 02/10] spi: rockchip-sfc: add rockchip serial
 flash controller

On Wed, Jul 07, 2021 at 05:08:02PM +0800, Jon Lin wrote:

This looks pretty nice, a few small issues below but nothing major:

> +/* Maximum clock values from datasheet suggest keeping clock value under
> + * 150MHz. No minimum or average value is suggested, but the U-boot BSP driver
> + * has a minimum of 10MHz and a default of 80MHz which seems reasonable.
> + */

It's OK to just not specify a minimum if the hardware doesn't have one,
and AFAICT the driver doesn't actually use the default speed (the SPI
stack will generally try to go as fast as possible by default, the board
can configure the maximum speed and should be doing that if there's
issues).

> +static irqreturn_t rockchip_sfc_irq_handler(int irq, void *dev_id)
> +{
> +	struct rockchip_sfc *sfc = dev_id;
> +	u32 reg;
> +
> +	reg = readl(sfc->regbase + SFC_RISR);
> +
> +	/* Clear interrupt */
> +	writel_relaxed(reg, sfc->regbase + SFC_ICLR);
> +
> +	if (reg & SFC_RISR_DMA)
> +		complete(&sfc->cp);
> +
> +	return IRQ_HANDLED;
> +}

This will unconditionally ack any interrupt that is flagged, and doesn't
verify that there were any at all.  This won't work if the interrupt
ever gets shared and will mean that if something goes wrong and an
unexpected interrupt happens we'll at best just ignore it, at worst
we'll end up with a screaming interrupt constantly firing.  It'd be
better to at least return IRQ_NONE if we got anything unexpected (I
guess just if SFC_RISR_DMA isn't set, assuming there's nothing else
we're intentionally ignoring).

> +	master->mode_bits = SPI_TX_QUAD | SPI_TX_DUAL | SPI_RX_QUAD | SPI_RX_DUAL;

Should it also do SPI_HALF_DUPLEX?

> +	ret = devm_request_irq(dev, ret, rockchip_sfc_irq_handler,
> +			       0, pdev->name, sfc);
> +	if (ret) {
> +		dev_err(dev, "Failed to request irq\n");
> +
> +		return ret;
> +	}

Should we have a call to _irq_mask() before this to make sure that the
mask is set up correctly in the hardware, just in case?

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)