[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210309093226.GA6320@lst.de>
Date: Tue, 9 Mar 2021 10:32:26 +0100
From: Christoph Hellwig <hch@....de>
To: Caleb Connolly <caleb@...nolly.tech>
Cc: Christoph Hellwig <hch@....de>,
Alim Akhtar <alim.akhtar@...sung.com>,
Avri Altman <avri.altman@....com>,
"James E.J. Bottomley" <jejb@...ux.ibm.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
ejb@...ux.ibm.com, stanley.chu@...iatek.com, cang@...eaurora.org,
beanhuo@...ron.com, jaegeuk@...nel.org, asutoshd@...eaurora.org,
linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] scsi: ufshcd: switch to a version macro
On Mon, Mar 08, 2021 at 10:42:43AM +0000, Caleb Connolly wrote:
> >> +#define UFSHCI_VER(major, minor) \
> >> + ((major << 8) + (minor << 4))
> > This needs braces around major and minor. Or better just convert it
> > to an inline function (and use a lower case name).
>
> Other (similar) implementations, like NVME_VS() use a macro here, is an
> inline function just personal preference?
>
> I'm perfectly happy either way, so I'll switch to your suggestion.
In general inline functions are always preferred over non-trivial
macros. Macros are required for a few cases where e.g. otherwise the
include dependencies would turn into a nightmare.
Powered by blists - more mailing lists