[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180919174612.GG2471@sirena.org.uk>
Date: Wed, 19 Sep 2018 10:46:12 -0700
From: Mark Brown <broonie@...nel.org>
To: masonccyang@...c.com.tw
Cc: tpiepho@...inj.com, linux-kernel@...r.kernel.org,
linux-spi@...r.kernel.org, boris.brezillon@...tlin.com,
juliensu@...c.com.tw, zhengxunli@...c.com.tw
Subject: Re: [PATCH 1/2] spi: Add MXIC controller driver
On Mon, Sep 17, 2018 at 03:16:18PM +0800, masonccyang@...c.com.tw wrote:
> +static void mxic_spi_set_cs(struct spi_device *spi, bool lvl)
> +{
> + struct mxic_spi *mxic = spi_master_get_devdata(spi->master);
> +
> + if (!lvl) {
> + if (mxic_spi_clk_setup(spi))
> + return;
> + if (mxic_spi_clk_enable(mxic))
> + return;
> + writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_EN,
> + mxic->regs + HC_CFG);
> + writel(HC_EN_BIT, mxic->regs + HC_EN);
> + writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_ASSERT,
> + mxic->regs + HC_CFG);
Like Boris says having the clock management in the chip select
operations is not good - it's not just redundant with runtime PM, it's
potentially broken if a device does something like using an inverted
chip select. The chip select operation should just be managing the chip
select, nothing else. If it does other things it's going to end up
being broken for some cases.
Otherwise this looks good.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists