linux-kernel - Re: [PATCH] mmc: core: Mark mmc_host device with pm_runtime_no

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: <CAPDyKFoAQX3xe0=LYhbScx-bs97imGgnVJCpzvTirxszcUY03w@mail.gmail.com>
Date:   Fri, 7 May 2021 13:38:49 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     chgokhl@....com
Cc:     linux-mmc <linux-mmc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kehuanlin@...hsemi.com
Subject: Re: [PATCH] mmc: core: Mark mmc_host device with pm_runtime_no_callbacks

On Tue, 23 Mar 2021 at 15:00, Ulf Hansson <ulf.hansson@...aro.org> wrote:
>
> On Tue, 23 Mar 2021 at 11:49, hieagle <chgokhl@...il.com> wrote:
> >
> > We encounter a resume issue in our device sometimes. The mmc device's
> > parent list is
> > mmc0:0001->mmc_host mmc0->fa630000.mmc->soc in our soc. We found in the blow
> > case with mmc0->power.disable_depth=0 the mmc_runtime_resume will be skipped,
> > which cause subsequent mmc command fail.
> >
> > mmc_get_card(mmc0:0001)->pm_runtime_get_sync->rpm_resume(mmc0:0001)->rpm_resume(mmc0)
> > The rpm_resume(mmc0) return -ENOSYS due to no callback and
> > mmc0->power.runtime_status
> > keep RPM_SUSPENDED. This lead to rpm_resume(mmc0:0001) return -EBUSY and skip
> > rpm_callback which call mmc_runtime_resume, the mmc is still in
> > suspended and the
> > subsequent mmc command fail.
> >
> > [  198.856157] Call trace:
> > [  198.858917] [<ffffff800808bd9c>] dump_backtrace+0x0/0x1cc
> > [  198.864966] [<ffffff800808bf7c>] show_stack+0x14/0x1c
> > [  198.870627] [<ffffff8008400e88>] dump_stack+0xa8/0xe0
> > [  198.876288] [<ffffff800854d38c>] rpm_resume+0x850/0x938
> > [  198.882141] [<ffffff800854cd8c>] rpm_resume+0x250/0x938
> > [  198.887994] [<ffffff800854d4c4>] __pm_runtime_resume+0x50/0x74
> > [  198.894530] [<ffffff80087b9e64>] mmc_get_card+0x3c/0xb8
> > [  198.900388] [<ffffff80087cd2e0>] mmc_blk_issue_rq+0x2b0/0x4d8
> > [  198.906824] [<ffffff80087cd5e4>] mmc_queue_thread+0xdc/0x198
> > [  198.913165] [<ffffff80080d4b2c>] kthread+0xec/0x100
> > [  198.918632] [<ffffff8008083890>] ret_from_fork+0x10/0x40
> > [  198.924582] mmc0  callback           (null)
> > [  198.935837] mmcblk mmc0:0001: __pm_runtime_resume ret -16
> >
> > Mark mmc_host device with pm_runtime_no_callbacks will solve the issue.
> > Thanks.
> > Huanlin Ke
>
> Thanks for sharing more details! I have to admit, that this sounds
> quite weird to me. I wonder if this is a problem that deserves to be
> fixed in the runtime PM core....
>
> Let me have a closer look a get back to you again. Please be patient
> though, I have a busy week in front of me.

Just wanted to notify you that I haven't forgotten. I will look into
this beginning of the next week.

[...]

Kind regards
Uffe