linux-kernel - Re: [PATCH v2 00/10] Tegra SDHCI update the pad autocal procedure

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: <56e6c8c572a429a987dd7ef7bd898768@agner.ch>
Date:   Tue, 31 Jul 2018 11:33:20 +0200
From:   Stefan Agner <stefan@...er.ch>
To:     Aapo Vienamo <avienamo@...dia.com>
Cc:     Ulf Hansson <ulf.hansson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Mikko Perttunen <mperttunen@...dia.com>,
        linux-mmc@...r.kernel.org, devicetree@...r.kernel.org,
        linux-tegra@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-tegra-owner@...r.kernel.org
Subject: Re: [PATCH v2 00/10] Tegra SDHCI update the pad autocal procedure

On 30.07.2018 17:43, Aapo Vienamo wrote:
> On Mon, 30 Jul 2018 17:07:59 +0200
> Ulf Hansson <ulf.hansson@...aro.org> wrote:
> 
>> On 26 July 2018 at 14:26, Aapo Vienamo <avienamo@...dia.com> wrote:
>> > Hi all,
>> >
>> > Update the tegra_sdhci_pad_autocalib() pad drive strength calibration
>> > procedure to match the ones specified in the TRMs of the more recent
>> > SoCs. This was tested on Tegra186, Tegra210, and Tegra124, although it
>> > should not break things older generations either.

I can give this a try on Tegra 3 here.

>> >
>> > This series depends on the "Tegra SDHCI enable 1.8 V signaling on
>> > Tegar210 and Tegra186" series posted earlier.
>>
>> According to the cover letter of the above series, it states that it
>> depends on $subject series. A circular dependency. :-)
> 
> The dependency chain goes like this: "Tegra SDHCI update the pad
> autocal procedure" -> "Tegra SDHCI enable 1.8 V signaling on Tegar210
> and Tegra186" -> "Tegra PMC pinctrl pad configuration".
> 
>> In fact, there should be no dependency at all or else there seems to
>> be a DT compatibility problem here...
> 
> From a functionality perspective there's no strict dependency, however,
> I don't think "[PATCH v2 09/10] mmc: tegra: Perform pad calibration
> after voltage switch" can be applied cleanly without
> "[PATCH v2 03/10] mmc: tegra: Reconfigure pad voltages during voltage
> switching" from the "Tegra SDHCI enable 1.8 V signaling on Tegar210 and
> Tegra186" series.
> 
>> Anyway, I think it actually makes sense to fold in all changes into
>> one series. Make sure the dt-doc changes comes first, then the driver
>> changes and finally arm64/dts changes. This should make it easy to
>> follow the review and I can pick the mmc parts and the soc maintainer
>> can pick the arm64/dts changes.
> 
> I've sent the changes in multiple part because I've been working on
> further changes to the driver while the previous parts have been
> getting reviewed. This is still the case and there's still going to be
> at least one more series which adds support for HS200 tuning and some
> smaller changes after it. However, the HS200 work is probably going to
> be ready for review in a day or two. I can send these as a one series
> from now on, although at this point it would be 27 patches in total
> and even more with the HS200 patches.
> 
> I can do that if you prefer to do it that way. Makes my life somewhat
> easier too.

...that would make it easier for my testing too, so I wait for the next
revision and will give it a try on Tegra 3 then.

--
Stefan

> 
>  -Aapo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html