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: <cc07ebd1-fa93-46be-991b-c14e4222750c@acm.org>
Date: Thu, 23 Jan 2025 09:49:07 -0800
From: Bart Van Assche <bvanassche@....org>
To: Ziqi Chen <quic_ziqichen@...cinc.com>, 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/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.