From: Lee Jones <lee.jones@linaro.org>
To: Xu Yilun <yilun.xu@intel.com>
Cc: broonie@kernel.org, linux-kernel@vger.kernel.org,
trix@redhat.com, matthew.gerlach@linux.intel.com,
russell.h.weight@intel.com, lgoncalv@redhat.com,
hao.wu@intel.com
Subject: Re: [PATCH v4 2/2] mfd: intel-m10-bmc: add Max10 BMC chip support for Intel FPGA PAC
Date: Wed, 9 Sep 2020 08:31:40 +0100 [thread overview]
Message-ID: <20200909073140.GC4400@dell> (raw)
In-Reply-To: <20200909060140.GB27300@yilunxu-OptiPlex-7050>
On Wed, 09 Sep 2020, Xu Yilun wrote:
> > > > > + * m10bmc_raw_read - read m10bmc register per addr
> > > > > + * m10bmc_sys_read - read m10bmc system register per offset
> > > > > + */
> > > > > +static inline int
> > > > > +m10bmc_raw_read(struct intel_m10bmc *m10bmc, unsigned int addr,
> > > > > + unsigned int *val)
> > > > > +{
> > > > > + int ret;
> > > > > +
> > > > > + ret = regmap_read(m10bmc->regmap, addr, val);
> > > > > + if (ret)
> > > > > + dev_err(m10bmc->dev, "fail to read raw reg %x: %d\n",
> > > > > + addr, ret);
> > > > > +
> > > > > + return ret;
> > > > > +}
> > > > > +
> > > > > +#define m10bmc_sys_read(m10bmc, offset, val) \
> > > > > + m10bmc_raw_read(m10bmc, M10BMC_SYS_BASE + (offset), val)
> > > >
> > > > No unnecessary abstractions.
> > > >
> > > > Just use the Regmap API directly please.
> > >
> > > Could we keep the 2 definition?
> > >
> > > For m10bmc_raw_read(), we make it to help print some error info if
> > > regmap RW fail. So we don't have to write "if (ret) dev_err" every time
> > > we use regmap.
> >
> > How many call sites are there?
>
> There are about 20 calls of the register read in m10bmc base driver and
> sub device drivers. Most of them calls m10bmc_sys_read().
> I prefer to keep the function for unified error log, but I'm also good
> to follow your opinion. How do you think?
Avoidable abstraction is one of my pet hates. However,
unified/centralised error handling is a valid(ish) reason for
abstraction to exist. Do you really need to know which read failed?
Is there a case where a read from only a particular register would
fail where others succeed?
> I also realize that it is not necessary that we define so many
> m10bmc_raw_bulk_read/bulk_write/update_bits ... which are not frequently
> used. We could change them.
Yes please.
> > > For m10bmc_sys_read(), the offset of BMC system registers could be
> > > configured by HW developers (The MAX 10 is an CPLD, it could be easily
> > > reprogrammed). And the HW SPEC will not add the offset when describing
> > > the addresses of system registers. So:
> > > 1. It makes the definition of system registers in code align with HW SPEC.
> > > 2. It makes developers easier to make changes when the offset is adjusted
> > > in HW (I've been told by HW guys, it is sometimes necessary to adjust
> > > the offset when changing RTL, required by Altera EDA tool - Quartus).
> >
> > Make sure you justify this for the function(s) you keep.
>
> Yes, I could add some comments.
>
> Thanks,
> Yilun
--
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-09-09 7:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-19 7:34 [PATCH v4 0/2] add regmap-spi-avmm & Intel Max10 BMC chip support Xu Yilun
2020-08-19 7:34 ` [PATCH v4 1/2] regmap: add Intel SPI Slave to AVMM Bus Bridge support Xu Yilun
2020-08-19 7:34 ` [PATCH v4 2/2] mfd: intel-m10-bmc: add Max10 BMC chip support for Intel FPGA PAC Xu Yilun
2020-08-28 10:02 ` Lee Jones
2020-08-28 13:50 ` Tom Rix
2020-09-08 11:56 ` Lee Jones
2020-08-29 18:24 ` Xu Yilun
2020-09-08 12:03 ` Lee Jones
2020-09-09 6:01 ` Xu Yilun
2020-09-09 7:31 ` Lee Jones [this message]
2020-09-09 8:29 ` Xu Yilun
2020-08-26 19:16 ` [PATCH v4 0/2] add regmap-spi-avmm & Intel Max10 BMC chip support Mark Brown
2020-08-27 6:56 ` Lee Jones
2020-08-27 12:20 ` Mark Brown
2020-08-27 12:27 ` Lee Jones
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=20200909073140.GC4400@dell \
--to=lee.jones@linaro.org \
--cc=broonie@kernel.org \
--cc=hao.wu@intel.com \
--cc=lgoncalv@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.gerlach@linux.intel.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.