Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 15 Nov 2022 10:56:43 +0200 (EET)
From:   =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= <ilpo.jarvinen@linux.intel.com>
To:     Xu Yilun <yilun.xu@intel.com>
cc:     Russ Weight <russell.h.weight@intel.com>,
        linux-fpga@vger.kernel.org, Wu Hao <hao.wu@intel.com>,
        Tom Rix <trix@redhat.com>, Moritz Fischer <mdf@kernel.org>,
        Lee Jones <lee@kernel.org>,
        Matthew Gerlach <matthew.gerlach@linux.intel.com>,
        Tianfei zhang <tianfei.zhang@intel.com>,
        Mark Brown <broonie@kernel.org>,
        Greg KH <gregkh@linuxfoundation.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 02/12] mfd: intel-m10-bmc: Create m10bmc_platform_info
 for type specific info
In-Reply-To: <Y3LxmUpqycBoZctF@yilunxu-OptiPlex-7050>
Message-ID: <391c37d8-a9b6-e0cf-5bdc-2182826a33e0@linux.intel.com>
References: <20221108144305.45424-1-ilpo.jarvinen@linux.intel.com> <20221108144305.45424-3-ilpo.jarvinen@linux.intel.com> <Y24gJ7fIsUPmhzY2@yilunxu-OptiPlex-7050> <752a1dc-fae6-4431-41cf-a6deaf157ad3@linux.intel.com> <Y3Gg29pGm4DwjOgI@yilunxu-OptiPlex-7050>
 <30c62175-e96f-3911-8176-cac3d4928eb5@intel.com> <Y3LxmUpqycBoZctF@yilunxu-OptiPlex-7050>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1382684573-1668502609=:2268"
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1382684573-1668502609=:2268
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT

On Tue, 15 Nov 2022, Xu Yilun wrote:

> On 2022-11-14 at 17:17:06 -0800, Russ Weight wrote:
> > 
> > 
> > On 11/13/22 17:58, Xu Yilun wrote:
> > > On 2022-11-11 at 13:49:38 +0200, Ilpo J?rvinen wrote:
> > >> On Fri, 11 Nov 2022, Xu Yilun wrote:
> > >>
> > >>> On 2022-11-08 at 16:42:55 +0200, Ilpo J?rvinen wrote:
> > >>>> BMC type specific info is currently set by a switch/case block. The
> > >>>> size of this info is expected to grow as more dev types and features
> > >>>> are added which would have made the switch block bloaty.
> > >>>>
> > >>>> Store type specific info into struct and place them into .driver_data
> > >>>> instead because it makes things a bit cleaner.
> > >>>>
> > >>>> Reviewed-by: Russ Weight <russell.h.weight@intel.com>
> > >>>> Signed-off-by: Ilpo J?rvinen <ilpo.jarvinen@linux.intel.com>
> > >>>> ---
> > >>>>  drivers/mfd/intel-m10-bmc.c       | 50 +++++++++++++++++--------------
> > >>>>  include/linux/mfd/intel-m10-bmc.h | 14 +++++++++
> > >>>>  2 files changed, 41 insertions(+), 23 deletions(-)
> > >>>>
> > >>>> diff --git a/drivers/mfd/intel-m10-bmc.c b/drivers/mfd/intel-m10-bmc.c
> > >>>> index ee167c5dcd29..762808906380 100644
> > >>>> --- a/drivers/mfd/intel-m10-bmc.c
> > >>>> +++ b/drivers/mfd/intel-m10-bmc.c
> > >>>> @@ -208,10 +194,28 @@ static int intel_m10_bmc_spi_probe(struct spi_device *spi)
> > >>>>  	return ret;
> > >>>>  }
> > >>>>  
> > >>>> +static const struct intel_m10bmc_platform_info m10bmc_m10_n3000 = {
> > >>>> +	.type = M10_N3000,
> > >>> Is the type enum still useful? Found no usage.
> > >> There's no use within context of this patch series. However, I think there 
> > >> might have been something depending on it in the changes that are not part 
> > >> of this series so I left it in place for now.
> > > I'm not sure how it would be used later. This patch is to eliminate the
> > > "switch (board type) case" block, but similar code is still to be added
> > > later?
> > 
> > Unfortunately, these will be needed later. Consider the following (future)
> > function that has to account for a field that was moved from one register
> > to another:
> > 
> >     static int
> >     m10bmc_sec_status(struct m10bmc_sec *sec, u32 *status)
> >     {
> >     ??????? u32 reg_offset, reg_value;
> >     ??????? int ret;
> > 
> >     ??????? reg_offset = (sec->type == N6000BMC_SEC) ?
> >     ??????????????? auth_result_reg(sec->m10bmc) : doorbell_reg(sec->m10bmc);
> > 
> >     ??????? ret = m10bmc_sys_read(sec->m10bmc, reg_offset, &reg_value);
> >     ??????? if (ret)
> >     ??????????????? return ret;
> > 
> >     ??????? *status = rsu_stat(reg_value);
> > 
> >     ??????? return 0;
> >     }
> > 
> > With this patch-set, most conditionals are removed, but there will still
> > be some cases where it is needed. If you prefer, we could wait and add
> 
> Why this condition can't be handled in the same manner? I actually hope
> all board type difference been handled in the same way, either by the
> core mfd driver or each subdev driver, but not a mix of the two.

I agree. It is already a TODO item on my list to make that oddity part of 
CSR map.

Also, this is anyway not the same type (mfd and sec have their own set of 
types). I'll just drop the mfd type field for now and might end up doing 
the same for the sec one too.


-- 
 i.

--8323329-1382684573-1668502609=:2268--