linux-kernel - Re: Possible regression with commit 52221610d

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]

Message-ID: <545AD9D9.1010105@nvidia.com>
Date:	Thu, 6 Nov 2014 11:15:53 +0900
From:	Alexandre Courbot <acourbot@...dia.com>
To:	Tim Kryger <tim.kryger@...il.com>
CC:	Sachin Kamat <spk.linux@...il.com>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	linux-mmc <linux-mmc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Alexandre Courbot <gnurou@...il.com>
Subject: Re: Possible regression with commit 52221610d

On 11/06/2014 12:27 AM, Tim Kryger wrote:
> On Wed, Nov 5, 2014 at 12:10 AM, Alexandre Courbot <acourbot@...dia.com> wrote:
>> On 11/05/2014 12:31 AM, Tim Kryger wrote:
>>>
>>> On Tue, Nov 4, 2014 at 1:00 AM, Alexandre Courbot <acourbot@...dia.com>
>>> wrote:
>>>>
>>>> Hi Tim, thanks for your reply!
>>>>
>>>> On 11/04/2014 02:28 PM, Tim Kryger wrote:
>>>>>
>>>>>
>>>>> On Mon, Nov 3, 2014 at 7:05 PM, Alexandre Courbot <acourbot@...dia.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> On the NVIDIA shield (tegra114-roth) platform, I have noticed that MMC
>>>>>> stopped working completely on recent kernels. MMC devices will not show
>>>>>> up
>>>>>> and the message "mmc1: Controller never released inhibit bit(s)." shows
>>>>>> up
>>>>>> repeatedly in the console.
>>>>>>
>>>>>> After bisecting I tracked commit
>>>>>> 52221610dd84dc3e9196554f0292ca9e8ab3541d
>>>>>> ("mmc: sdhci: Improve external VDD regulator support") as the one that
>>>>>> introduced this issue, which seems somehow surprising to me since it
>>>>>> has
>>>>>> been around for a while and nobody else complained about this AFAICT.
>>>>>
>>>>>
>>>>>
>>>>> I'm not too familiar with the Nvidia Shield so can you please confirm
>>>>> the following?
>>>>>
>>>>> The controller in the Tegra114 is SDHCI compliant and as such
>>>>> sdhci_tegra_probe calls sdhci_add_host.  External regulators are
>>>>> sought in sdhci_add_host with a call to mmc_regulator_get_supply.
>>>>
>>>>
>>>>
>>>> This is correct.
>>>>
>>>>> Since no external regulators are specified in tegra114.dtsi or
>>>>> tegra114-roth.dts, mmc->supply.vmmc and mmc->supply.vqmmc are set to
>>>>> -ENODEV.
>>>>
>>>>
>>>>
>>>> Actually 2 of the MMC nodes in tegra114-roth.dts (for SD card and eMMC)
>>>> have
>>>> a vmmc-supply property, so for two of them at least mmc->supply.vmmc is a
>>>> valid pointer.
>>>>
>>>
>>> I must have been looking at an old version of the file.  Thanks for
>>> clearing this up.
>>>
>>>> As explained above, vmmc is a valid pointer for 2 instances of the MMC
>>>> controller. Interestingly, if I just remove the "return" line in the
>>>> IS_ERR() block (without moving it around), the issue also seems to be
>>>> fixed.
>>>>
>>>>>
>>>>> Can you provide the relevant parts of the log before the problem occurs?
>>>>
>>>>
>>>>
>>>> There is not much unfortunately ; the only relevant log I have is this:
>>>>
>>>> [   12.246022] mmc2: Timeout waiting for hardware interrupt.
>>>> [   12.264990] mmc2: Controller never released inhibit bit(s).
>>>>
>>>> Some hardware interrupt timed out. I don't know much about the MMC
>>>> subsystem. but could it be because initially the controller is not in a
>>>> powered-on state, and that return statement causes the function to leave
>>>> it
>>>> unpowered?
>>>
>>>
>>> In a nutshell, the issue here is that the SDHCI spec demands that VMMC
>>> be supplied by the controller itself with the specific voltage
>>> configured using the SDHCI_POWER_CONTROL register but almost nobody
>>> does this.  Many SoCs omit this capability from their controllers and
>>> instead rely upon external regulators.  In such cases there isn't
>>> normally any need to update the voltage bits of the power control
>>> register.  It sounds like you are saying this isn't true for the
>>> Tegra114.
>>
>>
>> Thanks for your explanation, it makes sense now.
>>
>> Looking at other Tegra boards .dts I noticed that SHIELD is the only one
>> using a vmmc-supply. Maybe this is the part that is wrong? I wrote this DTS
>> and cannot exclude I misread the schematics. Maybe that regulator is used
>> for some other (still sdmmc-related) purpose but the actual power provider
>> is the controller itself.
>>
>> If you can confirm that the driver is performing as it should, I will look
>> in that direction and revise my DTS.
>
> I believe it is working as intended.  Is the schematic publicly available?

Sadly, no. But it is built similarly to other T114 boards, so I have to 
assume the error is mine here. I will come back to this thread if it 
turns out it is not.

Thanks for your help!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/