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] [day] [month] [year] [list]
Date:   Mon, 30 Oct 2023 06:19:31 +0000
From:   Chun-Hung Wu (巫駿宏) 
        <Chun-hung.Wu@...iatek.com>
To:     "ebiggers@...gle.com" <ebiggers@...gle.com>,
        "quic_nguyenb@...cinc.com" <quic_nguyenb@...cinc.com>,
        "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "bvanassche@....org" <bvanassche@....org>,
        "quic_asutoshd@...cinc.com" <quic_asutoshd@...cinc.com>,
        "alim.akhtar@...sung.com" <alim.akhtar@...sung.com>,
        "avri.altman@....com" <avri.altman@....com>,
        "Arthur.Simchaev@....com" <Arthur.Simchaev@....com>,
        "keosung.park@...sung.com" <keosung.park@...sung.com>,
        "mani@...nel.org" <mani@...nel.org>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "quic_cang@...cinc.com" <quic_cang@...cinc.com>,
        "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>,
        "yang.lee@...ux.alibaba.com" <yang.lee@...ux.alibaba.com>
CC:     Peter Wang (王信友) 
        <peter.wang@...iatek.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Jiajie Hao (郝加节) 
        <jiajie.hao@...iatek.com>,
        CC Chou (周志杰) <cc.chou@...iatek.com>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        Alice Chao (趙珮均) 
        <Alice.Chao@...iatek.com>,
        Eddie Huang (黃智傑) 
        <eddie.huang@...iatek.com>,
        wsd_upstream <wsd_upstream@...iatek.com>,
        Casper Li (李中榮) <casper.li@...iatek.com>,
        Tun-yu Yu (游敦聿) <Tun-yu.Yu@...iatek.com>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        Lin Gui (桂林) <Lin.Gui@...iatek.com>,
        Chaotian Jing (井朝天) 
        <Chaotian.Jing@...iatek.com>,
        Powen Kao (高伯文) <Powen.Kao@...iatek.com>,
        Naomi Chu (朱詠田) <Naomi.Chu@...iatek.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Qilin Tan (谭麒麟) <Qilin.Tan@...iatek.com>,
        "kernel-team@...roid.com" <kernel-team@...roid.com>
Subject: Re: [PATCH v1 1/1] ufs: core: Add host quirk
 QUIRK_MCQ_EXPAND_QUEUE_SLOT

On Fri, 2023-10-27 at 13:55 -0700, Bart Van Assche wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On 10/26/23 20:27, Chun-Hung Wu (巫駿宏) wrote:
> > From UFSHCI 4.0 spec "When the head and tail doorbells are equal,
> the
> > queue is empty. *Nothe that this definition means there will always
> be
> > one empty queue entry"
> > One of our platform does not keep one empty queue
> > entry for CQ full
> > case, that's  why we need this patch to fix this corner case.
> 
> The UFSHCI driver should make sure that there is always one empty
> queue
> entry. Does "platform" in the above text refer to the SoC that
> includes
> the UFSHCI controller?
Yes here "platform" indicates SoC that includes the UFSHCI controller.
> 
> What is totally unclear to me is why the following code depends on
> the
> UFSHCI controller type:
> 
> +if (ufshcd_is_mcq_expand_queue_slot(hba))
> +hwq->max_entries = hba->nutrs + 1;
> +else
> +hwq->max_entries = hba->nutrs;
> 
> Shouldn't hwq->max_entries = hba->nutrs + 1 be used for all UFSHCI
> 4.0
> controllers?
> 
> Thanks,
> 
> Bart.
> 
I think UFSHCI 4.0 spec "When the head and tail doorbells are equal,the
queue is empty. *Nothe that this definition means there will alwaysbe
one empty queue entry" means that "UFSHCI controller" should always
keep one empty queue entry.
One of our host does not follow the spec, therefore, this host will
treat CQ full(head = tail) as CQ empty (head = tail). That's why we
propose this quirk to expand one queue slot for hosts have such issue.
It will make CQ full(head != tail)[keep one empty queue entry] not
equal to CQ empty(head = tail).
hwq->max_entries will be used to set SQ&CQ size in SQ&CQ Configuration
Registers, we think it should only apply to specific hosts need this
quirk not all.

Thanks,
Chun-Hung

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ