From: Lee Jones <lee.jones@linaro.org>
To: Russ Weight <russell.h.weight@intel.com>
Cc: mdf@kernel.org, linux-fpga@vger.kernel.org,
linux-kernel@vger.kernel.org, trix@redhat.com,
lgoncalv@redhat.com, yilun.xu@intel.com, hao.wu@intel.com,
matthew.gerlach@intel.com
Subject: Re: [PATCH v2 1/6] mfd: intel-m10-bmc: support for MAX10 BMC Security Engine
Date: Thu, 8 Oct 2020 08:23:57 +0100 [thread overview]
Message-ID: <20201008072357.GD1763265@dell> (raw)
In-Reply-To: <c50c30b7-0693-3ff1-8d79-5d311d3831bd@intel.com>
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
next prev parent reply other threads:[~2020-10-08 7:24 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-03 1:24 [PATCH v2 0/6] Intel MAX10 BMC Security Engine Driver Russ Weight
2020-10-03 1:24 ` [PATCH v2 1/6] mfd: intel-m10-bmc: support for MAX10 BMC Security Engine Russ Weight
2020-10-06 16:34 ` Tom Rix
2020-10-08 0:52 ` Russ Weight
2020-10-08 23:03 ` Russ Weight
2020-10-09 20:04 ` Tom Rix
2020-10-07 7:00 ` Lee Jones
2020-10-08 0:49 ` Russ Weight
2020-10-08 7:23 ` Lee Jones [this message]
2020-10-03 1:24 ` [PATCH v2 2/6] fpga: m10bmc-sec: create max10 bmc security engine Russ Weight
2020-10-03 3:15 ` Randy Dunlap
2020-10-04 18:01 ` Russ Weight
2020-10-04 18:07 ` Randy Dunlap
2020-10-06 17:31 ` Tom Rix
2020-10-08 21:12 ` Russ Weight
2020-10-03 1:24 ` [PATCH v2 3/6] fpga: m10bmc-sec: expose max10 flash update counts Russ Weight
2020-10-06 17:35 ` Tom Rix
2020-10-03 1:24 ` [PATCH v2 4/6] fpga: m10bmc-sec: expose max10 canceled keys in sysfs Russ Weight
2020-10-06 17:41 ` Tom Rix
2020-10-03 1:24 ` [PATCH v2 5/6] fpga: m10bmc-sec: add max10 secure update functions Russ Weight
2020-10-06 19:08 ` Tom Rix
2020-10-08 23:06 ` Russ Weight
2020-10-09 20:15 ` Tom Rix
2020-10-03 1:24 ` [PATCH v2 6/6] fpga: m10bmc-sec: add max10 get_hw_errinfo callback func Russ Weight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201008072357.GD1763265@dell \
--to=lee.jones@linaro.org \
--cc=hao.wu@intel.com \
--cc=lgoncalv@redhat.com \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.gerlach@intel.com \
--cc=mdf@kernel.org \
--cc=russell.h.weight@intel.com \
--cc=trix@redhat.com \
--cc=yilun.xu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).