All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rix <trix@redhat.com>
To: Xu Yilun <yilun.xu@intel.com>
Cc: lee.jones@linaro.org, linux-kernel@vger.kernel.org,
	matthew.gerlach@linux.intel.com, russell.h.weight@intel.com,
	lgoncalv@redhat.com, hao.wu@intel.com
Subject: Re: [PATCH 2/2] mfd: intel-m10-bmc: add access table configuration to the regmap
Date: Thu, 21 Jan 2021 05:19:56 -0800	[thread overview]
Message-ID: <82884394-f8aa-4957-04c3-285381e13d57@redhat.com> (raw)
In-Reply-To: <20210121080554.GA1943@yilunxu-OptiPlex-7050>


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.gerlach@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.gerlach@linux.intel.com>
>>> Signed-off-by: Xu Yilun <yilun.xu@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.

Tom

>
> Thanks,
> Yilun
>


  reply	other threads:[~2021-01-21 15:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-20  2:34 [PATCH 1/2] mfd: intel-m10-bmc: fix the register access range Xu Yilun
2021-01-20  2:34 ` [PATCH 2/2] mfd: intel-m10-bmc: add access table configuration to the regmap Xu Yilun
2021-01-20 15:32   ` Tom Rix
2021-01-21  8:05     ` Xu Yilun
2021-01-21 13:19       ` Tom Rix [this message]
2021-01-22  3:23         ` Xu Yilun
2021-01-20 15:42 ` [PATCH 1/2] mfd: intel-m10-bmc: fix the register access range Tom Rix

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=82884394-f8aa-4957-04c3-285381e13d57@redhat.com \
    --to=trix@redhat.com \
    --cc=hao.wu@intel.com \
    --cc=lee.jones@linaro.org \
    --cc=lgoncalv@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew.gerlach@linux.intel.com \
    --cc=russell.h.weight@intel.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.