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]
Date:	Thu, 17 Mar 2016 12:01:01 -0500
From:	Rob Herring <robh@...nel.org>
To:	Scott Wood <scott.wood@....com>
Cc:	Yangbo Lu <yangbo.lu@....com>, Arnd Bergmann <arnd@...db.de>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
	Zhao Qiang <qiang.zhao@...escale.com>,
	Russell King <linux@....linux.org.uk>,
	Bhupesh Sharma <bhupesh.sharma@...escale.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Joerg Roedel <joro@...tes.org>,
	Kumar Gala <galak@...eaurora.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Yang-Leo Li <leoyang.li@....com>,
	"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	Claudiu Manoil <claudiu.manoil@...escale.com>,
	Santosh Shilimkar <ssantosh@...nel.org>,
	Xiaobo Xie <xiaobo.xie@....com>,
	"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for
 T4240-R1.0-R2.0

On Mon, Mar 14, 2016 at 05:45:43PM +0000, Scott Wood wrote:
> On 03/14/2016 02:29 AM, Yangbo Lu wrote:
> >> -----Original Message-----
> >> From: Arnd Bergmann [mailto:arnd@...db.de]
> >> Sent: Monday, March 14, 2016 6:26 AM
> >> To: linuxppc-dev@...ts.ozlabs.org
> >> Cc: Yangbo Lu; devicetree@...r.kernel.org; linux-arm-
> >> kernel@...ts.infradead.org; linux-kernel@...r.kernel.org; linux-
> >> clk@...r.kernel.org; linux-i2c@...r.kernel.org; iommu@...ts.linux-
> >> foundation.org; netdev@...r.kernel.org; linux-mmc@...r.kernel.org;
> >> ulf.hansson@...aro.org; Zhao Qiang; Russell King; Bhupesh Sharma; Joerg
> >> Roedel; Santosh Shilimkar; Scott Wood; Rob Herring; Claudiu Manoil; Kumar
> >> Gala; Yang-Leo Li; Xiaobo Xie
> >> Subject: Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-
> >> R1.0-R2.0
> >>
> >> On Wednesday 09 March 2016 18:08:51 Yangbo Lu wrote:
> >>> @@ -567,10 +580,20 @@ static void esdhc_init(struct platform_device
> >> *pdev, struct sdhci_host *host)
> >>>         struct sdhci_pltfm_host *pltfm_host;
> >>>         struct sdhci_esdhc *esdhc;
> >>>         u16 host_ver;
> >>> +       u32 svr;
> >>>
> >>>         pltfm_host = sdhci_priv(host);
> >>>         esdhc = sdhci_pltfm_priv(pltfm_host);
> >>>
> >>> +       fsl_guts_init();
> >>> +       svr = fsl_guts_get_svr();
> >>> +       if (svr) {
> >>> +               esdhc->soc_ver = SVR_SOC_VER(svr);
> >>> +               esdhc->soc_rev = SVR_REV(svr);
> >>> +       } else {
> >>> +               dev_err(&pdev->dev, "Failed to get SVR value!\n");
> >>> +       }
> >>> +
> >>
> >> This makes the driver non-portable. Better identify the specific
> >> workarounds based on the compatible string for this device, or add a
> >> boolean DT property for the quirk.
> >>
> >> 	Arnd
> > 
> > [Lu Yangbo-B47093] Hi Arnd, we did have a discussion about using DTS in v1 before.
> > https://patchwork.kernel.org/patch/6834221/
> > 
> > We don’t have a separate DTS file for each revision of an SOC and if we did, we'd constantly have people using the wrong one.
> > In addition, the device tree is stable ABI and errata are often discovered after device tree are deployed.
> > See the link for details.
> > 
> > So we decide to read SVR from the device-config/guts MMIO block other than using DTS.
> > Thanks.
> 
> Also note that this driver is already only for fsl-specific hardware,
> and it will still work even if fsl_guts doesn't find anything to bind to
> -- it just wouldn't be able to detect errata based on SVR in that case.

IIRC, it is the same IP block as i.MX and Arnd's point is this won't 
even compile on !PPC. It is things like this that prevent sharing the 
driver. Dealing with Si revs is a common problem. We should have a 
common solution. There is soc_device for this purpose.

OTOH, the integration differences may be enough that trying to have a 
common driver with i.MX would not be worth it.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ