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:   Thu, 8 Oct 2020 14:06:33 +0300
From:   Tero Kristo <t-kristo@...com>
To:     Faiz Abbas <faiz_abbas@...com>, <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>
CC:     <will@...nel.org>, <catalin.marinas@....com>, <nm@...com>
Subject: Re: [PATCH 0/2] Enable GPIO and I2C configs for TI's J721e platform

On 08/10/2020 12:40, Faiz Abbas wrote:
> Tero,
> 
> On 08/10/20 2:49 pm, Tero Kristo wrote:
>> On 08/10/2020 11:59, Faiz Abbas wrote:
>>> Tero,
>>>
>>> On 06/10/20 6:40 pm, Tero Kristo wrote:
>>>> On 06/10/2020 16:03, Faiz Abbas wrote:
>>>>> Hi Tero,
>>>>>
>>>>> On 06/10/20 5:21 pm, Tero Kristo wrote:
>>>>>> On 02/10/2020 19:45, Faiz Abbas wrote:
>>>>>>> The following patches enable configs in the arm64 defconfig to support
>>>>>>> GPIO and I2C support on TI's J721e platform.
>>>>>>>
>>>>>>> Faiz Abbas (2):
>>>>>>>       arm64: defconfig: Enable OMAP I2C driver
>>>>>>>       arm64: defconfig: Enable DAVINCI_GPIO driver
>>>>>>>
>>>>>>>      arch/arm64/configs/defconfig | 2 ++
>>>>>>>      1 file changed, 2 insertions(+)
>>>>>>>
>>>>>>
>>>>>> Why are you enabling these?
>>>>>>
>>>>>> Are they required for booting the board?
>>>>>>
>>>>>> If not, they shall not be enabled, as it just clutters the arm64 defconfig unnecessarily.
>>>>>>
>>>>>
>>>>> They are required because the SD card regulators need gpio over i2c expander and also
>>>>> soc gpio support to come up in UHS modes.
>>>>
>>>> Is that needed for boot support? If it is only needed with UHS cards, that does not seem important enough for me. We can already boot the board via other means.
>>>
>>> Without these configs, the regulator drivers keep EPROBE_DEFERing waiting for their gpio drivers
>>> to probe and SD card never comes up. This configuration happens before any UHS capabilities are detected.
>>>
>>> [    1.326654] sdhci-am654 4fb0000.sdhci: _devm_regulator_get id:vmmc ret:-517
>>> [    1.333651] sdhci-am654 4fb0000.sdhci: _devm_regulator_get id:vqmmc ret:-517
>>> [    1.340693] sdhci-am654 4fb0000.sdhci: sdhci_am654_probe ret:-517
>>> [    1.489088] sdhci-am654 4fb0000.sdhci: _devm_regulator_get id:vmmc ret:-517
>>> [    1.496067] sdhci-am654 4fb0000.sdhci: _devm_regulator_get id:vqmmc ret:-517
>>> [    1.510392] sdhci-am654 4fb0000.sdhci: sdhci_am654_probe ret:-517
>>> [    1.543210] sdhci-am654 4fb0000.sdhci: _devm_regulator_get id:vmmc ret:-517
>>> [    1.550186] sdhci-am654 4fb0000.sdhci: _devm_regulator_get id:vqmmc ret:-517
>>> [    1.568134] sdhci-am654 4fb0000.sdhci: sdhci_am654_probe ret:-517
>>
>> This happens because you have merged/enabled UHS support or? This sounds like a regression as I haven't seen this happen before.
>>
> 
> Thats right. The EPROBE_DEFERs will happen if my patches enabling UHS modes here are merged. I need to repost them for v5.11-rc1:
> https://lore.kernel.org/linux-arm-kernel/20201001190541.6364-1-faiz_abbas@ti.com/

Ok I think that would be good enough reason to enable these by default 
as the MMC as boot media won't work anymore without them, and carrying 
the DTS patches would be just silly.

Acked-by: Tero Kristo <t-kristo@...com>

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ