lkml.org 
[lkml]   [2020]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 1/6] mfd: intel-m10-bmc: support for MAX10 BMC Security Engine
On Wed, 07 Oct 2020, Russ Weight wrote:
> On 10/7/20 12:00 AM, Lee Jones wrote:
> > On Fri, 02 Oct 2020, Russ Weight wrote:
> >
> >> Add macros and definitions required by the MAX10 BMC
> >> Security Engine driver.
> >>
> >> Signed-off-by: Russ Weight <russell.h.weight@intel.com>
> >> ---
> >> v2:
> >> - These functions and macros were previously distributed among
> >> the patches that needed them. They are now grouped together
> >> in a single patch containing changes to the Intel MAX10 BMC
> >> driver.
> >> - Added DRBL_ prefix to some definitions
> >> - Some address definitions were moved here from the .c files that
> >> use them.
> >> ---
> >> include/linux/mfd/intel-m10-bmc.h | 134 ++++++++++++++++++++++++++++++
> >> 1 file changed, 134 insertions(+)
> >>
> >> diff --git a/include/linux/mfd/intel-m10-bmc.h b/include/linux/mfd/intel-m10-bmc.h
> >> index c8ef2f1654a4..880f907302eb 100644
> >> --- a/include/linux/mfd/intel-m10-bmc.h
> >> +++ b/include/linux/mfd/intel-m10-bmc.h
> >> @@ -13,6 +13,9 @@
> >> * m10bmc_raw_read - read m10bmc register per addr
> >> + * m10bmc_raw_bulk_read - bulk read max10 registers per addr
> >> + * m10bmc_raw_bulk_write - bulk write max10 registers per addr
> >> + * m10bmc_raw_update_bits - update max10 register per addr
> >> * m10bmc_sys_read - read m10bmc system register per offset
> >> + * m10bmc_sys_update_bits - update max10 system register per offset
> >> */
> > FWIW, I *hate* abstraction for the sake of abstraction.
> >
> > Please just use the Regmap API in-place instead.
> >
> I was following the discussion on the Max10 BMC driver to determine which way to go:
>
> https://marc.info/?l=linux-kernel&m=159964043207829&w=2
>
> My understanding was that the existing function wrappers were accepted because:
>
> (1) The functions are adding dev_err() calls that would have to be replicated
> for each call if we don't create a new function.
> (2) The _sys_ macros are adding a base address offset, which facilitates
> sharing code between multiple devices (although only the n3000 is supported with
> the current patches).
>
> Would you prefer that we handle these on a case by case basis? And only provide
> wrappers for the ones that have high usage?

Yes please. As I said in the link above, avoid them it at all
possible. If you and every other user needs to place an error message
after every single call, consider moving the error message into the
API itself.

There are 10's if not 100's of different API calls where users
normally place error messages following them. To abstract them all
for each platform would be insane.

--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

\
 
 \ /
  Last update: 2020-10-08 09:25    [W:0.066 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site