linux-kernel - Re: [PATCH v2 1/3] scsi: ufs: core: Introduce mcq ops to config cqid

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]

Message-ID: <4ea8427d-8b09-d35f-0e2c-2df486b79692@acm.org>
Date:   Thu, 1 Jun 2023 07:23:41 -0700
From:   Bart Van Assche <bvanassche@....org>
To:     Powen Kao (高伯文) <Powen.Kao@...iatek.com>,
        "chu.stanley@...il.com" <chu.stanley@...il.com>
Cc:     Peter Wang (王信友) 
        <peter.wang@...iatek.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        CC Chou (周志杰) <cc.chou@...iatek.com>,
        Eddie Huang (黃智傑) 
        <eddie.huang@...iatek.com>,
        Alice Chao (趙珮均) 
        <Alice.Chao@...iatek.com>,
        "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
        wsd_upstream <wsd_upstream@...iatek.com>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "avri.altman@....com" <avri.altman@....com>,
        Chun-Hung Wu (巫駿宏) 
        <Chun-hung.Wu@...iatek.com>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "alim.akhtar@...sung.com" <alim.akhtar@...sung.com>,
        Naomi Chu (朱詠田) <Naomi.Chu@...iatek.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Stanley Chu (朱原陞) 
        <stanley.chu@...iatek.com>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH v2 1/3] scsi: ufs: core: Introduce mcq ops to config cqid

On 6/1/23 03:25, Powen Kao (高伯文) wrote:
> According to spec, driver is free to assign any SQ to CQ mapping. I am
> not sure if it's ideal to constrain mapping to specific kind.

As has been made clear several times recently during discussions around
LSF/MM topics, implementing all features of a standard is *not* one of the
goals of the Linux kernel. Whether a feature is defined in the NVMe, a SCSI
or the UFS standard, we (Linux kernel community) only support those features
that we consider useful and that can be implemented with a reasonable effort.
An example of a feature that probably will never be supported by the Linux
kernel is the "domains and realms" functionality from ZBC-2.

> Yes, please refer to
> "[PATCH v2 3/3] scsi: ufs: ufs-mediatek: Add MCQ support for MTK
> platform"
> 
> +static int ufs_mtk_config_cqid(struct ufs_hba *hba)
> +{
> +       struct ufs_hw_queue *hwq;
> +       int i;
> +
> +       for (i = 0; i < hba->nr_hw_queues; i++) {
> +               hwq = &hba->uhq[i];
> +               hwq->cqid = 3;
> +       }
> +
> +       return 0;
> +}

Thanks, I had overlooked this. Do you agree that the above shows that the
flag I proposed in my previous email (UFSHCD_CAP_SINGLE_CQ) is sufficient
to support the MediaTek use case? I want to keep the SQ-CQ association code
in the UFS driver core because the next step will probably to switch from
one CQ per SQ to one CQ per CPU core for UFS controllers that support
multiple completion interrupts.

Thanks,

Bart.