[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDyKFpeifgeZcB45WE+nbRtOrGk+h0BqbNZgM2ivJiELkXJhQ@mail.gmail.com>
Date: Mon, 1 Oct 2018 15:43:07 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Ludovic BARRE <ludovic.barre@...com>
Cc: Rob Herring <robh+dt@...nel.org>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...com>,
Benjamin Gaignard <benjamin.gaignard@...aro.org>,
Gerald Baeza <gerald.baeza@...com>,
Loic Pallardy <loic.pallardy@...com>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
DTML <devicetree@...r.kernel.org>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
linux-stm32@...md-mailman.stormreply.com
Subject: Re: [PATCH V2 23/27] mmc: mmci: add variant property to request a reset
[...]
>>> @@ -1854,6 +1855,14 @@ static int mmci_probe(struct amba_device *dev,
>>>
>>> dev_dbg(mmc_dev(mmc), "clocking block at %u Hz\n", mmc->f_max);
>>>
>>> + if (variant->reset) {
>>> + host->rst = devm_reset_control_get_exclusive(&dev->dev,
>>> NULL);
>>
>>
>> As suggested, let's make this optional and not depending on the variant.
>
>
> I done like that because is required for my variant (if no reset, no power
> cycle for sdmmc).
The point is, I think don't think it's correct to ties this to the
variant, but rather I think it depends on the behavior of the SoC.
>
> If you prefer, I could move to optional with
> "devm_reset_control_get_optional_exclusive"
> And I add a comment in mmci dt binding to specify that not optional
> for sdmmc. (see above)
Alright, fair enough. Let' do that.
[...]
Kind regards
Uffe
Powered by blists - more mailing lists