[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d06d9625-8ef9-f385-a9c9-75c306a959ed@acm.org>
Date: Mon, 1 Aug 2022 21:02:31 -0700
From: Bart Van Assche <bvanassche@....org>
To: Daniil Lunev <dlunev@...omium.org>
Cc: Adrian Hunter <adrian.hunter@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Alim Akhtar <alim.akhtar@...sung.com>,
Avri Altman <avri.altman@....com>,
Bean Huo <beanhuo@...ron.com>,
"James E.J. Bottomley" <jejb@...ux.ibm.com>,
Keoseong Park <keosung.park@...sung.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
Sohaib Mohamed <sohaib.amhmd@...il.com>,
linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: [PATCH v5] ufs: core: print UFSHCD capabilities in controller's
sysfs node
On 8/1/22 20:20, Daniil Lunev wrote:
>> Is the "capabilities" directory a directory with capabilities of the
>> host, with capabilities of the UFS device or perhaps with capabilities
>> of both?
>
> I would say effective capabilities of the controller-device pair, from the
> semantic that hba->caps field presents. Do you want me to mention it
> anywhere?
Calling this the effective capabilities of the controller-device pair
sounds good to me. But please do not refer to hba->caps. I'd like to
rework hba->caps such that it only includes controller capabilities and
no information related to the WriteBooster. Additionally, several UFS
device capabilities that may be exported in the future are not
represented in hba->caps.
Thanks,
Bart.
Powered by blists - more mailing lists