linux-kernel - Re: [RFC PATCH 1/2] spi: Add support for Zynq QSPI 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAFcVEC+fO9e6d0HXC0UsY3ptNhXhD0TVFuuw3HdS5RpAUmtR8Q@mail.gmail.com>
Date:	Mon, 14 Jul 2014 12:57:07 +0530
From:	Harini Katakam <harinikatakamlinux@...il.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	linux-spi <linux-spi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Brian Norris <computersforpeace@...il.com>,
	Marek Vašut <marex@...x.de>,
	Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>,
	Geert Uytterhoeven <geert+renesas@...ux-m68k.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Jingoo Han <jg1.han@...sung.com>,
	Sourav Poddar <sourav.poddar@...com>,
	"michals@...inx.com" <michals@...inx.com>,
	Punnaiah Choudary Kalluri <punnaia@...inx.com>
Subject: Re: [RFC PATCH 1/2] spi: Add support for Zynq QSPI controller

Hi Mark,

On Fri, Jul 11, 2014 at 7:08 PM, Mark Brown <broonie@...nel.org> wrote:
> On Thu, Jul 10, 2014 at 02:20:06PM +0530, Harini Katakam wrote:
>
>> This patch adds support for QSPI controller used by Zynq.
>
> The driver looks pretty clean but there are a couple of issues below,
> including a little bit more of the flash specifics.
>
>> +static void zynq_qspi_chipselect(struct spi_device *qspi, bool is_high)
>> +{
>> +     struct zynq_qspi *xqspi = spi_master_get_devdata(qspi->master);
>> +     u32 config_reg;
>> +
>> +     config_reg = zynq_qspi_read(xqspi, ZYNQ_QSPI_CONFIG_OFFSET);
>> +
>> +     /* Select upper/lower page before asserting CS */
>> +     if (xqspi->is_stacked) {
>> +             u32 lqspi_cfg_reg;
>
> Like with the dual and quad mode stuff this looks very much like it's
> specific to flash rather than something that applies to a generic SPI
> driver.  However it does look like it's a generic SPI device which could
> be used in other applications which makes things a bit tricky.  We don't
> have a really good answer for this right now unfortunately, probably we
> need some sort of special interface between the SPI and flash subsystems
> to allow flash to use the flash specific stuff.
>
> For use as a generic SPI device what I'd suggest is stripping out the
> flash specifics, merging the rest of the support and then considering
> the flash specifics separately.

Reply in the other thread.

>
>> +/**
>> + * zynq_prepare_transfer_hardware - Prepares hardware for transfer.
>> + * @master:  Pointer to the spi_master structure which provides
>> + *           information about the controller.
>> + *
>> + * This function enables SPI master controller.
>> + *
>> + * Return:   Always 0
>> + */
>> +static int zynq_prepare_transfer_hardware(struct spi_master *master)
>> +{
>> +     struct zynq_qspi *xqspi = spi_master_get_devdata(master);
>> +
>> +     zynq_qspi_config_clock_mode(master->cur_msg->spi);
>
> The clock mode needs to be (and is) configured per transfer so I'd
> expect it's possible to remove this call.
>

Yeah I understand. It can go away from here and there should be a
prepare_message as per Lars-Peter's patches on spi-cadence.
I'll reflect the same in this driver.

Regards,
Harini
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/