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: <CAPDyKFqidGZ242P-9xnxokSCeGxk8uziqR=AteWt=iQFz5fA9g@mail.gmail.com>
Date:   Tue, 3 Oct 2023 14:22:02 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Adrian Hunter <adrian.hunter@...el.com>
Cc:     Victor Shih <victorshihgli@...il.com>, linux-mmc@...r.kernel.org,
        linux-kernel@...r.kernel.org, benchuanggli@...il.com,
        HL.Liu@...esyslogic.com.tw, Greg.tu@...esyslogic.com.tw,
        takahiro.akashi@...aro.org, dlunev@...omium.org,
        Ben Chuang <ben.chuang@...esyslogic.com.tw>,
        Victor Shih <victor.shih@...esyslogic.com.tw>
Subject: Re: [PATCH V12 10/23] mmc: sdhci-uhs2: add reset function and
 uhs2_mode function

On Tue, 3 Oct 2023 at 13:37, Adrian Hunter <adrian.hunter@...el.com> wrote:
>
> On 3/10/23 13:30, Ulf Hansson wrote:
> > On Fri, 15 Sept 2023 at 11:44, Victor Shih <victorshihgli@...il.com> wrote:
> >>
> >> From: Victor Shih <victor.shih@...esyslogic.com.tw>
> >>
> >> Sdhci_uhs2_reset() does a UHS-II specific reset operation.
> >>
> >> Signed-off-by: Ben Chuang <ben.chuang@...esyslogic.com.tw>
> >> Signed-off-by: AKASHI Takahiro <takahiro.akashi@...aro.org>
> >> Signed-off-by: Victor Shih <victor.shih@...esyslogic.com.tw>
> >> Acked-by: Adrian Hunter <adrian.hunter@...el.com>
> >> ---
> >>
> >> Updates in V8:
> >>  - Adjust the position of matching brackets.
> >>
> >> Updates in V6:
> >>  - Remove unnecessary functions and simplify code.
> >>
> >> ---
> >>
> >>  drivers/mmc/host/sdhci-uhs2.c | 45 +++++++++++++++++++++++++++++++++++
> >>  drivers/mmc/host/sdhci-uhs2.h |  2 ++
> >>  2 files changed, 47 insertions(+)
> >>
> >> diff --git a/drivers/mmc/host/sdhci-uhs2.c b/drivers/mmc/host/sdhci-uhs2.c
> >> index e339821d3504..dfc80a7f1bad 100644
> >> --- a/drivers/mmc/host/sdhci-uhs2.c
> >> +++ b/drivers/mmc/host/sdhci-uhs2.c
> >> @@ -10,7 +10,9 @@
> >>   *  Author: AKASHI Takahiro <takahiro.akashi@...aro.org>
> >>   */
> >>
> >> +#include <linux/delay.h>
> >>  #include <linux/module.h>
> >> +#include <linux/iopoll.h>
> >>
> >>  #include "sdhci.h"
> >>  #include "sdhci-uhs2.h"
> >> @@ -49,6 +51,49 @@ void sdhci_uhs2_dump_regs(struct sdhci_host *host)
> >>  }
> >>  EXPORT_SYMBOL_GPL(sdhci_uhs2_dump_regs);
> >>
> >> +/*****************************************************************************\
> >> + *                                                                           *
> >> + * Low level functions                                                       *
> >> + *                                                                           *
> >> +\*****************************************************************************/
> >> +
> >> +bool sdhci_uhs2_mode(struct sdhci_host *host)
> >> +{
> >> +       return host->mmc->flags & MMC_UHS2_SUPPORT;
> >
> > The MMC_UHS2_SUPPORT bit looks redundant to me. Instead, I think we
> > should be using mmc->ios.timings, which already indicates whether we
> > are using UHS2 (MMC_TIMING_UHS2_SPEED_*). See patch2 where we added
> > this.
> >
> > That said, I think we should drop the sdhci_uhs2_mode() function
> > altogether and instead use mmc_card_uhs2(), which means we should move
> > it to include/linux/mmc/host.h, so it becomes available for host
> > drivers.
> >
>
> UHS2 mode starts at UHS2 initialization and ends either when UHS2
> initialization fails, or the card is removed.
>
> So it includes re-initialization and reset when the transfer mode
> currently transitions through MMC_TIMING_LEGACY.
>
> So mmc_card_uhs2() won't work correctly for the host callbacks
> unless something is done about that.

Right, thanks for clarifying!

In that case I wonder if we couldn't change the way we update the
->ios.timing for UHS2. It seems silly to have two (similar) ways to
indicate that we have moved to UHS2.

Kind regards
Uffe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ