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]
Date:   Wed, 15 Jun 2022 11:48:36 +0800
From:   Stanley Chu <stanley.chu@...iatek.com>
To:     Bart Van Assche <bvanassche@....org>, <linux-scsi@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <martin.petersen@...cle.com>,
        <avri.altman@....com>, <alim.akhtar@...sung.com>,
        <jejb@...ux.ibm.com>
CC:     <peter.wang@...iatek.com>, <chun-hung.wu@...iatek.com>,
        <alice.chao@...iatek.com>, <powen.kao@...iatek.com>,
        <mason.zhang@...iatek.com>, <qilin.tan@...iatek.com>,
        <lin.gui@...iatek.com>, <eddie.huang@...iatek.com>,
        <tun-yu.yu@...iatek.com>, <cc.chou@...iatek.com>,
        <chaotian.jing@...iatek.com>, <jiajie.hao@...iatek.com>
Subject: Re: [PATCH v3 07/10] scsi: ufs-mediatek: Support flexible
 parameters for smc calls

Hi Bart,

On Tue, 2022-06-14 at 09:28 -0700, Bart Van Assche wrote:
> On 6/14/22 07:16, Stanley Chu wrote:
> > From: Alice Chao <alice.chao@...iatek.com>
> > 
> > Provide flexible number of parameters for UFS SMC calls to be
> > easily used for future SMC usages.
> 
> How far in the future? Please only introduce what is needed for this 
> patch series.

Sure, I just rewrote and simplified SMC call macros according to your
good suggestions in v4.

> 
> > +/*
> > + * SMC call wapper function
> 
>                 ^^^^^^
> typo

Fixed in v4.
> 
> > + */
> > +#define _ufs_mtk_smc(cmd, res, v1, v2, v3, v4, v5, v6) \
> > +		arm_smccc_smc(MTK_SIP_UFS_CONTROL, \
> > +				  cmd, v1, v2, v3, v4, v5, v6, &(res))
> > +
> > +#define _ufs_mtk_smc_0(cmd, res) \
> > +	_ufs_mtk_smc(cmd, res, 0, 0, 0, 0, 0, 0)
> > +
> > +#define _ufs_mtk_smc_1(cmd, res, v1) \
> > +	_ufs_mtk_smc(cmd, res, v1, 0, 0, 0, 0, 0)
> > +
> > +#define _ufs_mtk_smc_2(cmd, res, v1, v2) \
> > +	_ufs_mtk_smc(cmd, res, v1, v2, 0, 0, 0, 0)
> > +
> > +#define _ufs_mtk_smc_3(cmd, res, v1, v2, v3) \
> > +	_ufs_mtk_smc(cmd, res, v1, v2, v3, 0, 0, 0)
> > +
> > +#define _ufs_mtk_smc_4(cmd, res, v1, v2, v3, v4) \
> > +	_ufs_mtk_smc(cmd, res, v1, v2, v3, v4, 0, 0)
> > +
> > +#define _ufs_mtk_smc_5(cmd, res, v1, v2, v3, v4, v5) \
> > +	_ufs_mtk_smc(cmd, res, v1, v2, v3, v4, v5, 0)
> > +
> > +#define _ufs_mtk_smc_6(cmd, res, v1, v2, v3, v4, v5, v6) \
> > +	_ufs_mtk_smc(cmd, res, v1, v2, v3, v4, v5, v6)
> > +
> > +#define _ufs_mtk_smc_selector(cmd, res, v1, v2, v3, v4, v5, v6,
> > FUNC, ...) FUNC
> > +
> > +#define ufs_mtk_smc(...) \
> > +	_ufs_mtk_smc_selector(__VA_ARGS__, \
> > +	_ufs_mtk_smc_6(__VA_ARGS__), \
> > +	_ufs_mtk_smc_5(__VA_ARGS__), \
> > +	_ufs_mtk_smc_4(__VA_ARGS__), \
> > +	_ufs_mtk_smc_3(__VA_ARGS__), \
> > +	_ufs_mtk_smc_2(__VA_ARGS__), \
> > +	_ufs_mtk_smc_1(__VA_ARGS__), \
> > +	_ufs_mtk_smc_0(__VA_ARGS__) \
> > +	)
> 
> If _ufs_mtk_smc() would be modified to accept an struct _ufs_mtk_args
> as 
> its only argument, would that allow to simplify the above into the 
> following?
> 
> #define ufs_mtk_smc(...) \
>    _ufs_mtk_smc((struct _ufs_mtk_args){__VA_ARGS__})
> 
> > +/*
> > + * Sip kernel interface
> > + */
> 
> What is "Sip"? Should it perhaps be spelled as "SIP"?
> 
> Thanks,
> 
> Bart.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ