linux-kernel - Re: [PATCH 03/11] Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs

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]

Date:	Mon, 13 Jun 2016 11:32:18 +0200
From:	Heiko Stübner <heiko@...ech.de>
To:	Shawn Lin <shawn.lin@...k-chips.com>
Cc:	Douglas Anderson <dianders@...omium.org>, ulf.hansson@...aro.org,
	kishon@...com, robh+dt@...nel.org, xzy.xu@...k-chips.com,
	briannorris@...omium.org, adrian.hunter@...el.com,
	linux-rockchip@...ts.infradead.org, linux-mmc@...r.kernel.org,
	devicetree@...r.kernel.org, pawel.moll@....com,
	mark.rutland@....com, ijc+devicetree@...lion.org.uk,
	galak@...eaurora.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 03/11] Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs

Am Montag, 13. Juni 2016, 16:18:24 schrieb Shawn Lin:
> On 2016/6/8 6:44, Douglas Anderson wrote:
> > As can be seen in Arasan's datasheet [1] there are several "corecfg"
> > settings in their SDHCI IP Block that are supposed to be controlled by
> > software.  Although the datasheet referenced is a bit vague about how to
> > access corecfg, in Figure 5 you can see that for Arasan's PHY (a
> > separate component than their SDHCI component) they describe the
> > "phyctrl" registers as being "FROM SOC CTL REG", implying that it's up
> > to the licensee of the Arasan IP block to implement these registers.  It
> > seems sane to assume that the "corecfg" registers in their SDHCI IP
> > block works in a similar way for all licensees of the IP Block.
> > 
> > Device tree has a model that allows a device to get a reference to
> > random registers located elsewhere in the SoC: sysctl.  Let's leverage
> > this model and allow adding a sysctl reference to access the control
> > registers for the Arasan SDHCI PHYs.
> > 
> > Having a reference to the control registers doesn't do much for us on
> > its own since the Arasan spec doesn't specify how these corecfg values
> > are laid out in memory.  In the SDHCI driver we'll need a map detailing
> > where each corecfg can be found in each implementation.  This map can be
> > found using the primary compatible string of the SDHCI device.  In that
> > spirit, document that existing rk3399 device trees already have a
> > specific compatible string, though up to now they've always been relying
> > on the driver supporting the generic.
> > 
> > Note that since existing devices seem to work fairly well as-is, we'll
> > list the syscon reference as "optional", but it's likely that we'll run
> > into much fewer problems if we can actually set the proper values in the
> > syscon, so it is strongly suggested that any SoCs where we have a map to
> > set the corecfg also include a reference to the syscon.
> 
> yes, the interaction of phy and controller should be more explicitly
> now. Why not make it mandatory for arasan,sdhci-5.1.

The omnipresent backwards-compatiblity :-) .

The binding did not require any of this in the past, so the driver should 
always also work with devicetrees created according to this old binding.

And obviously it was working without that before as well, as Doug stated.


Heiko