linux-kernel - Re: [PATCH v2 0/3] Introduce the request

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:   Tue, 17 Mar 2020 21:49:17 +0800
From:   Baolin Wang <baolin.wang7@...il.com>
To:     Adrian Hunter <adrian.hunter@...el.com>
Cc:     Ulf Hansson <ulf.hansson@...aro.org>,
        Orson Zhai <orsonzhai@...il.com>,
        Chunyan Zhang <zhang.lyra@...il.com>,
        Arnd Bergmann <arnd@...db.de>,
        linux-mmc <linux-mmc@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/3] Introduce the request_atomic() for the host

On Tue, Mar 17, 2020 at 9:25 PM Adrian Hunter <adrian.hunter@...el.com> wrote:
>
> On 17/03/20 12:14 pm, Baolin Wang wrote:
> > This patch set introduces a new request_atomic() interface for the
> > MMC host controller, which is used to submit a request to host in
> > the atomic context, such as in the irq hard handler, to reduce the
> > request latency.
> >
> > Any comments are welcome. Thanks.
> >
> > Note: Adrian pointed out that it is not good if moving the polling of
> > inhibit bits in sdhci_send_command() into the interrupt context, but
> > now I have not found a better way to address Adrian's concern. Moveover
> > this is an unusual abnormal case and the original code has the same
> > problem, so I plan to create another patch set to talk about and fix
> > this issue.
>
> I tend to think the API requires the possibility for host controllers to
> return "busy", so that should be sorted out first.

If request_atomic() can return 'busy', the HSQ need queue a work to
dispatch this request to host again?

I am thinking if I can introduce a new flag to avoid polling the
status before sending commands, cause from the datasheet, I did not
see we should need do this if the command complete and transfer
complete interrupts are processed normally. At least on my platfrom, I
did not see the inhibit bits are set. If we meet this issue, I think
some abormal things are happened, we should give out errors. How do
you think?

> >
> > Changes from v1:
> >  - Re-split the changes to make them more clear suggested by Ulf.
> >  - Factor out the auto CMD23 checking into a separate function.
> >
> > Baolin Wang (3):
> >   mmc: host: Introduce the request_atomic() for the host
> >   mmc: host: sdhci: Implement the request_atomic() API
> >   mmc: host: sdhci-sprd: Implement the request_atomic() API
> >
> >  drivers/mmc/host/mmc_hsq.c    |  5 ++++-
> >  drivers/mmc/host/sdhci-sprd.c | 23 ++++++++++++++++++++---
> >  drivers/mmc/host/sdhci.c      | 27 +++++++++++++++++++--------
> >  drivers/mmc/host/sdhci.h      |  1 +
> >  include/linux/mmc/host.h      |  3 +++
> >  5 files changed, 47 insertions(+), 12 deletions(-)
> >
>


-- 
Baolin Wang