linux-kernel - Re: [PATCH v4 2/2] spi: add driver for J-Core SPI 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160802014531.GS15995@brightrain.aerifal.cx>
Date:	Mon, 1 Aug 2016 21:45:32 -0400
From:	Rich Felker <dalias@...c.org>
To:	Mark Brown <broonie@...nel.org>
Cc:	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-spi@...r.kernel.org, linux-sh@...r.kernel.org,
	Rob Herring <robh+dt@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Yoshinori Sato <ysato@...rs.sourceforge.jp>
Subject: Re: [PATCH v4 2/2] spi: add driver for J-Core SPI controller

On Mon, Aug 01, 2016 at 07:12:45PM +0100, Mark Brown wrote:
> On Fri, Jul 29, 2016 at 11:34:41PM -0400, Rich Felker wrote:
> 
> > I was able to get it working via the clk api and I'll include support
> > for this in the next version of the patch, but to actually use it
> > depends on changing arch/sh to use the common clk framework; otherwise
> > there's no way to provide a suitable clk in the DT and have
> > [devm_]clk_get actually pick it up. Should I keep around the option of
> > using clock-frequency too? That would be most convenient.
> 
> It sounds like at the minute the devices all have one frequency anyway
> in which case just having a default frequency in there that you fall
> back to if you get -ENOENT from a failed clock lookup might be enough?

Yes. 50 MHz is the natural default frequency, but I found out at the
last minute from the hardware engineers that clocking the current SoC
up to 62.5 MHz (for faster cpu) will require the SPI timing to be
programmed based on the faster reference clock. This messes up the
ability to get optimal SD card transfer rates, so we'll probably end
up having a real 50 MHz clock for the SPI anyway, but I thought it was
important to be able to handle this issue in the DT binding anyway.

Since it's not an immediate need right now anyway I'll drop the
clock-frequency property proposal and just use the more general clocks
approach you suggested.

Rich