On Thu, Jan 21, 2021 at 05:19:56AM -0800, Tom Rix wrote:
>
> On 1/21/21 12:05 AM, Xu Yilun wrote:
> > On Wed, Jan 20, 2021 at 07:32:53AM -0800, Tom Rix wrote:
> >> On 1/19/21 6:34 PM, Xu Yilun wrote:
> >>> From: Matthew Gerlach <matthew.gerl...@linux.intel.com>
> >>>
> >>> This patch adds access tables to the MAX 10 BMC regmap. This prevents
> >>> the host from accessing the unwanted I/O space. It also filters out the
> >>> invalid outputs when reading the regmap debugfs interface.
> >>>
> >>> Signed-off-by: Matthew Gerlach <matthew.gerl...@linux.intel.com>
> >>> Signed-off-by: Xu Yilun <yilun...@intel.com>
> >>> ---
> >>> drivers/mfd/intel-m10-bmc.c | 14 ++++++++++++++
> >>> include/linux/mfd/intel-m10-bmc.h | 5 ++++-
> >>> 2 files changed, 18 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/mfd/intel-m10-bmc.c b/drivers/mfd/intel-m10-bmc.c
> >>> index b84579b..0ae3053 100644
> >>> --- a/drivers/mfd/intel-m10-bmc.c
> >>> +++ b/drivers/mfd/intel-m10-bmc.c
> >>> @@ -23,10 +23,24 @@ static struct mfd_cell m10bmc_pacn3000_subdevs[] = {
> >>> { .name = "n3000bmc-secure" },
> >>> };
> >>>
> >>> +static const struct regmap_range m10bmc_regmap_range[] = {
> >>> + regmap_reg_range(M10BMC_LEGACY_SYS_BASE + M10BMC_BUILD_VER,
> >>> + M10BMC_LEGACY_SYS_BASE + M10BMC_BUILD_VER),
> >> If this is the only value in the legacy map to be accessed, could it have
> >> its own #define ?
> >>
> >> Something like
> >>
> >> #define M10BMC_LEGACY_BUILD_VER ?
> > Yes, it could be more clear. I'll change it.
> >
> >>> + regmap_reg_range(M10BMC_SYS_BASE, M10BMC_SYS_END),
> >>> + regmap_reg_range(M10BMC_FLASH_BASE, M10BMC_FLASH_END),
> >>> +};
> >>> +
> >>> +static const struct regmap_access_table m10bmc_access_table = {
> >>> + .yes_ranges = m10bmc_regmap_range,
> >>> + .n_yes_ranges = ARRAY_SIZE(m10bmc_regmap_range),
> >>> +};
> >>> +
> >>> static struct regmap_config intel_m10bmc_regmap_config = {
> >>> .reg_bits = 32,
> >>> .val_bits = 32,
> >>> .reg_stride = 4,
> >>> + .wr_table = &m10bmc_access_table,
> >>> + .rd_table = &m10bmc_access_table,
> >> The legacy build ver should only be read, so shouldn't these tables be
> >> different ?
> > I'm not sure if a register could be regarded as writable if hardware
> > ensures writing it has no effect but makes no harm. Usually these
> > registers are marked as RO in spec.
> >
> > I think it could be quite common case in hardware design. But it could
> > be trivial if we pick every such register out of wr_table. I just want
> > to define the valid reg range.
> >
> > So could I keep the current implementation?
>
> I mean that the write table would not have first element the read table has
> because it has the single ro entry.
>
> The other ranges i am sure have ro's and are not worth breaking apart.
>
> If something like
>
> .wr_table = &m10bmc_access_table[1] doesn't work or looks to hacky, i don't
> mind leaving it as-is.
It looks hacky to me.
If the first one has to be marked RO, I think it could be like:
static const struct regmap_range m10bmc_regmap_ro_range[] = {
regmap_reg_range(M10BMC_LEGACY_BUILD_VER, M10BMC_LEGACY_BUILD_VER),
};
static const struct regmap_range m10bmc_regmap_range[] = {
regmap_reg_range(M10BMC_LEGACY_BUILD_VER, M10BMC_LEGACY_BUILD_VER),
regmap_reg_range(...),
...
};
static const struct regmap_access_table m10bmc_write_table = {
.yes_ranges = m10bmc_regmap_range,
.n_yes_ranges = ARRAY_SIZE(m10bmc_regmap_range),
.no_range = m10bmc_regmap_ro_range,
.n_no_range = ARRAY_SIZE(m10bmc_regmap_ro_range),
};
static const struct regmap_access_table m10bmc_read_table = {
.yes_ranges = m10bmc_regmap_range,
.n_yes_ranges = ARRAY_SIZE(m10bmc_regmap_range),
};
But I think this is unnecessary. I feel it is indicating all the other
registers are RW in spec, actually they are not. So I tend to keep
it simple, just tell the valid range.
Thanks,
Yilun
