linux-kernel - Re: [PATCH v2 3/8] scsi: ufs: core: Add a vops to map clock frequency to gear speed

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <f09421c8-e6db-4189-9c1a-6ae0a863ae40@quicinc.com>
Date: Fri, 24 Jan 2025 10:38:57 +0800
From: Ziqi Chen <quic_ziqichen@...cinc.com>
To: Bart Van Assche <bvanassche@....org>, <quic_cang@...cinc.com>,
        <mani@...nel.org>, <beanhuo@...ron.com>, <avri.altman@....com>,
        <junwoo80.lee@...sung.com>, <martin.petersen@...cle.com>,
        <quic_nguyenb@...cinc.com>, <quic_nitirawa@...cinc.com>,
        <quic_rampraka@...cinc.com>
CC: <linux-arm-msm@...r.kernel.org>, <linux-scsi@...r.kernel.org>,
        Alim Akhtar
	<alim.akhtar@...sung.com>,
        "James E.J. Bottomley"
	<James.Bottomley@...senPartnership.com>,
        Peter Wang
	<peter.wang@...iatek.com>,
        Manivannan Sadhasivam
	<manivannan.sadhasivam@...aro.org>,
        Eric Biggers <ebiggers@...gle.com>, Minwoo Im <minwoo.im@...sung.com>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/8] scsi: ufs: core: Add a vops to map clock frequency
 to gear speed



On 1/24/2025 1:49 AM, Bart Van Assche wrote:
> On 1/22/25 11:40 PM, Ziqi Chen wrote:
>> In ufshcd-priv.h , the function name of all vop wrapping APIs have the 
>> same prefix "ufshcd_vops", I need to use the same format as them.
> 
> That sounds fair to me.
> 
>> As for return the gear value as the function result. In our original 
>> design, we also return gear result for this function, but finally we 
>> want to use return value to indicate the status , e.g,, if vendor 
>> doesn't implement this vop, we return -EOPNOTSUPP , if there is no 
>> matched gear to the freq , we return -EINVAL. Although we didn't check 
>> the return value in this series, we still want to preserve this 
>> extensibility in case this function be used to other where in the future.
> 
> There are many functions in the Linux kernel that either return a
> negative error code or a positive value in case of success. Regarding
> future extensibility, we can't know how this function will evolve in the
> future. This is not an argument to keep the approach of separate error
> codes (return value) and gear values (gear argument).
> 
> Thanks,
> 
> Bart.
> 
OK , Bart, let me improve it and please review again in my next version.

-Ziqi