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
| ||
|
Date: Wed, 19 Oct 2022 10:10:48 +0800 From: 黃懷厚 <tonyhuang.sunplus@...il.com> To: Arnd Bergmann <arnd@...db.de> Cc: Ulf Hansson <ulf.hansson@...aro.org>, Rob Herring <robh+dt@...nel.org>, krzk+dt@...nel.org, "linux-mmc @ vger . kernel . org" <linux-mmc@...r.kernel.org>, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, wells.lu@...plus.com, Tony Huang <tony.huang@...plus.com> Subject: Re: [PATCH v10 2/2] mmc: Add mmc driver for Sunplus SP7021 Dear Arnd, Ulf: Arnd Bergmann <arnd@...db.de> 於 2022年10月17日 週一 下午3:25寫道: > > On Sun, Oct 16, 2022, at 5:48 PM, Tony Huang wrote: > > This is a patch for mmc driver for Sunplus SP7021 SOC. > > Supports eMMC 4.41 DDR 104MB/s speed mode. > > > > Signed-off-by: Tony Huang <tonyhuang.sunplus@...il.com> > > Looks ok to me me overall. > > Acked-by: Arnd Bergmann <arnd@...db.de> > > Just one more thing I noticed: > > > +#define SPMMC_TIMEOUT 500000 > ... > > +static inline int spmmc_wait_finish(struct spmmc_host *host) > > +{ > > + u32 state; > > + > > + return readl_poll_timeout_atomic(host->base + SPMMC_SD_STATE_REG, > > state, > > + (state & SPMMC_SDSTATE_FINISH), 1, SPMMC_TIMEOUT); > > +} > > + > > +static inline int spmmc_wait_sdstatus(struct spmmc_host *host, > > unsigned int status_bit) > > +{ > > + u32 status; > > + > > + return readl_poll_timeout_atomic(host->base + SPMMC_SD_STATUS_REG, > > status, > > + (status & status_bit), 1, SPMMC_TIMEOUT); > > +} > > 500ms seems like an awfully long time for a busy-wait, I wonder if this > could be improved in some way. Is this always called from atomic context? > > If not, any callers from non-atomic context could use > readl_poll_timeout() instead, or maybe there could be a shorter > timeout in atomic context, with a fallback to a non-atomic > workqueue if that times out, so only the MMC access will stall but > not the entire system. OK, I would use real_poll_timeout() instead. Because I see "BUG: scheduling while atomic" issue before. I have solved this problem. > > The same problem does appear to be in dw_mmc.c and mtk-sd.c but not > in sdhci*.c, so I don't know if this is avoidable. > > Arnd
Powered by blists - more mailing lists