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: Thu, 12 Mar 2020 18:19:59 -0700 From: Sowjanya Komatineni <skomatineni@...dia.com> To: Ulf Hansson <ulf.hansson@...aro.org> CC: Adrian Hunter <adrian.hunter@...el.com>, Bradley Bolen <bradleybolen@...il.com>, Thierry Reding <thierry.reding@...il.com>, "Jon Hunter" <jonathanh@...dia.com>, Aniruddha Tvs Rao <anrao@...dia.com>, linux-tegra <linux-tegra@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org> Subject: Re: [PATCH v2 1/2] sdhci: tegra: Implement Tegra specific set_timeout callback On 3/12/20 8:35 AM, Ulf Hansson wrote: > External email: Use caution opening links or attachments > > > On Thu, 12 Mar 2020 at 16:28, Sowjanya Komatineni > <skomatineni@...dia.com> wrote: >> >> On 3/12/20 6:08 AM, Ulf Hansson wrote: >>> External email: Use caution opening links or attachments >>> >>> >>> -trimmed cc list >>> >>> On Thu, 12 Mar 2020 at 00:51, Sowjanya Komatineni >>> <skomatineni@...dia.com> wrote: >>>> Tegra host supports HW busy detection and timeouts based on the >>>> count programmed in SDHCI_TIMEOUT_CONTROL register and max busy >>>> timeout it supports is 11s in finite busy wait mode. >>>> >>>> Some operations like SLEEP_AWAKE, ERASE and flush cache through >>>> SWITCH commands take longer than 11s and Tegra host supports >>>> infinite HW busy wait mode where HW waits forever till the card >>>> is busy without HW timeout. >>>> >>>> This patch implements Tegra specific set_timeout sdhci_ops to allow >>>> switching between finite and infinite HW busy detection wait modes >>>> based on the device command expected operation time. >>>> >>>> Signed-off-by: Sowjanya Komatineni <skomatineni@...dia.com> >>> Applied for next, thanks! >>> >>> We should probably tag this for stable as well, don't you think? >>> >>> Kind regards >>> Uffe >> Yes, we need this for stable as well. As this is applied for next, looks >> like can't re-send patch with tag. >> >> Can you please help to add tag if you don't mind? > Yes, I will amend the change to add the stable tag, no worries! > > Thanks for confirming! > > [...] > > Kind regards > Uffe Thanks Uffe. Somehow patches I sent without mail server configured on git 2 days back went out now. So, please kindly ignore v1 patches and also v2 patches that got resent which are actually the patches sent before configuring git mail server by mistake 2 days ago. Sorry about that. Thanks Sowjanya
Powered by blists - more mailing lists