netdev - Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

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: <DB5PR0401MB19286B2D23D07F5C60DB799D91880@DB5PR0401MB1928.eurprd04.prod.outlook.com>
Date:	Mon, 14 Mar 2016 17:45:43 +0000
From:	Scott Wood <scott.wood@....com>
To:	Yangbo Lu <yangbo.lu@....com>, Arnd Bergmann <arnd@...db.de>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
CC:	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...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>,
	Joerg Roedel <joro@...tes.org>,
	Santosh Shilimkar <ssantosh@...nel.org>,
	"Rob Herring" <robh+dt@...nel.org>,
	Claudiu Manoil <claudiu.manoil@...escale.com>,
	Kumar Gala <galak@...eaurora.org>,
	Yang-Leo Li <leoyang.li@....com>,
	"Xiaobo Xie" <xiaobo.xie@....com>
Subject: Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for
 T4240-R1.0-R2.0

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.

-Scott