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: <f9fa0232-3945-4e47-9238-0b51f6531199@codeaurora.org>
Date:   Thu, 7 May 2020 22:03:14 +0530
From:   Veerabhadrarao Badiganti <vbadigan@...eaurora.org>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     Chun-Hung Wu <chun-hung.wu@...iatek.com>,
        Michał Mirosław <mirq-linux@...e.qmqm.pl>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Al Cooper <alcooperx@...il.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        BCM Kernel Feedback <bcm-kernel-feedback-list@...adcom.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Michal Simek <michal.simek@...inx.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Chaotian Jing <chaotian.jing@...iatek.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Pavel Machek <pavel@....cz>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Pan Bian <bianpan2016@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Allison Randal <allison@...utok.net>,
        Mathieu Malaterre <malat@...ian.org>,
        Stanley Chu <stanley.chu@...iatek.com>,
        Kuohong Wang <kuohong.wang@...iatek.com>,
        Yong Mao <yong.mao@...iatek.com>,
        Android Kernel Team <kernel-team@...roid.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>,
        DTML <devicetree@...r.kernel.org>, wsd_upstream@...iatek.com,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        linux-tegra <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v5 1/5] mmc: core: Extend mmc_of_parse() to parse CQE
 bindings


On 5/6/2020 10:06 PM, Ulf Hansson wrote:
> On Wed, 6 May 2020 at 15:01, Veerabhadrarao Badiganti
> <vbadigan@...eaurora.org> wrote:
>>
>> On 4/28/2020 5:26 AM, Chun-Hung Wu wrote:
>>> Parse CQE bindings "supports-cqe" and "disable-cqe-dcmd"
>>> in mmc_of_parse().
>>>
>>> Signed-off-by: Chun-Hung Wu <chun-hung.wu@...iatek.com>
>>> ---
>>>    drivers/mmc/core/host.c | 5 +++++
>>>    1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
>>> index c876872..47521c6 100644
>>> --- a/drivers/mmc/core/host.c
>>> +++ b/drivers/mmc/core/host.c
>>> @@ -302,6 +302,11 @@ int mmc_of_parse(struct mmc_host *host)
>>>                host->caps2 |= MMC_CAP2_NO_SD;
>>>        if (device_property_read_bool(dev, "no-mmc"))
>>>                host->caps2 |= MMC_CAP2_NO_MMC;
>>> +     if (device_property_read_bool(dev, "supports-cqe"))
>>> +             host->caps2 |= MMC_CAP2_CQE;
>> This change is breaking emmc driver on qcom platforms where this dt
>> property is defined.
>>
>> [    1.543453]  cqhci_deactivate+0xc/0x38
>> [    1.545627]  sdhci_msm_reset+0x40/0x58
>> [    1.549447]  sdhci_do_reset+0x48/0x7c
>> [    1.553180]  __sdhci_read_caps+0x7c/0x214
>> [    1.556913]  sdhci_setup_host+0x58/0xce8
>> [    1.560905]  sdhci_msm_probe+0x588/0x8a4
>> [    1.564900]  platform_drv_probe+0x4c/0xb0
>>
>> So, we cant have this flag defined before sdhci_setup_host().
>>
>> I will have to clear this cap and re-enable it in our initialization.
> Thanks for reporting! I have dropped all the four patches from
> Chun-Hung, so we can figure out how to fix this.
>
> Please help to review the next version of the series.

Thanks Ulf.

Hi Chun-Hung,

On qcom controller CQE also gets reset when SDHC is reset. So we have to 
explicitly disable CQE
by invoking  cqhci_deactivate() during sdhc reset

SDHC gets reset in sdhci_setup_host() even before cqe is initialized.
With MMC_CAP2_CQE_DCMD cap set even before sdhci_set_host(), we are 
getting null pointer access with cqhci_deactivate().

If CQE getting reset with SDHC reset is generic (applicable to other 
controllers) then you have revisit your logic.
If its not the case then only qcom driver would get affected.

I see you are updating sdhci-msm.c file as-well. How about including 
below change besides your change?

@@ -1658,6 +1658,8 @@ static int sdhci_msm_cqe_add_host(struct 
sdhci_host *host,
         if (host->caps & SDHCI_CAN_64BIT)
                 host->alloc_desc_sz = 16;

+       /* Clear the CQE cap during setup host */
+       msm_host->mmc->caps2 &= ~MMC_CAP2_CQE;
+
         ret = sdhci_setup_host(host);

>>> +     if (!device_property_read_bool(dev, "disable-cqe-dcmd")) {
>>> +             host->caps2 |= MMC_CAP2_CQE_DCMD;
>>> +     }
>>>
>>>        /* Must be after "non-removable" check */
>>>        if (device_property_read_u32(dev, "fixed-emmc-driver-type", &drv_type) == 0) {
> Kind regards
> Uffe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ