linux-kernel - Re: [PATCH v2 1/6] mfd: intel-m10-bmc: support for MAX10 BMC Security Engine

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: <20201008072357.GD1763265@dell>
Date:   Thu, 8 Oct 2020 08:23:57 +0100
From:   Lee Jones <lee.jones@...aro.org>
To:     Russ Weight <russell.h.weight@...el.com>
Cc:     mdf@...nel.org, linux-fpga@...r.kernel.org,
        linux-kernel@...r.kernel.org, trix@...hat.com, lgoncalv@...hat.com,
        yilun.xu@...el.com, hao.wu@...el.com, matthew.gerlach@...el.com
Subject: Re: [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@...el.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