From: Russ Weight <russell.h.weight@intel.com>
To: Lee Jones <lee.jones@linaro.org>
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: Wed, 7 Oct 2020 17:49:56 -0700 [thread overview]
Message-ID: <c50c30b7-0693-3ff1-8d79-5d311d3831bd@intel.com> (raw)
In-Reply-To: <20201007070059.GB1763265@dell>
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?
- Russ
next prev parent reply other threads:[~2020-10-08 0:50 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 [this message]
2020-10-08 7:23 ` Lee Jones
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=c50c30b7-0693-3ff1-8d79-5d311d3831bd@intel.com \
--to=russell.h.weight@intel.com \
--cc=hao.wu@intel.com \
--cc=lee.jones@linaro.org \
--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=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).