All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: linux-fpga@vger.kernel.org, Xu Yilun <yilun.xu@intel.com>,
	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>,
	Russ Weight <russell.h.weight@intel.com>,
	Tianfei zhang <tianfei.zhang@intel.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Marco Pagani <marpagan@redhat.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 07/11] regmap: indirect: Add indirect regmap support
Date: Fri, 25 Nov 2022 18:53:37 +0000	[thread overview]
Message-ID: <Y4EPMbc+KCuDpuxJ@sirena.org.uk> (raw)
In-Reply-To: <a97ce076-4ca6-5f1b-eba4-4068dcb64b3d@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 3593 bytes --]

On Mon, Nov 21, 2022 at 03:37:40PM +0200, Ilpo Järvinen wrote:

> Previously you were against saying it clearly that it's Intel FPGA 
> specific when Matthew proposed changing the name to not sound something 
> too generic. If you're ok with that now, I'm happy to make such change.

Saying it's for some Intel FPGA just makes it sound like it should only
live within the driver for that FPGA.  The issue with there being only
one user:

> > Perhaps you have some name for this
> > interface?  You're only adding one user here which isn't helping
> > make the case that this is something generic.

is part of it, as is the fact that the naming is so very generic.  Even
"Intel FPGA" seems to be heading to the generic side, this is presumably
some specific thing rather than just something that everyone using a
FPGA from Intel is going to need.  The issue with this being overly
specific isn't just the name, it's the code as well.

> > I can't tell what you're trying to say here.  Are you saying that
> > this is somehow baked into some FPGA design so that it's memory
> > mapped with only a few registers showing to the rest of the
> > system rather than just having a substantial memory mapped
> > window like is typically used for FPGAs, but someohow this
> > register window stuff is implemented in the soft IP so people are
> > just throwng vaugely similar interfaces into a random host mapped
> > register layout?
> 
> What I tried to say the users are not expected to be nicely confined into 
> drivers/mfd/ (and a single driver in there).

So this interface is part of the physical IP surrounding the actual
programmable bit of a FPGA or something?  That doesn't seem entirely
right though given the fact that the registers are apparently one of the
things that gets moved around a lot.  I still have no idea what this
hardware actually looks like or what this code is trying to represent,
especially given the very few things that you are trying to
parameterise.  It's really not obvious there's even any point in trying
to share this code at the abstraction level you've gone for.

Do you have any examples of even a second user that isn't this one MFD
which you can share?

> You didn't answer at all my question about where to place the code?
> I'm repeating it with the context below since you cut it off:

I keep telling you to either make this so that it's actually generic or
just have register get/set operations in the regmap for the device using
it.  As things stand with the code you've sent there's a bunch of things
like the way it's doing direct MMIO (which means it only works on top of
memory mapped devices) and the absolute requirement for an idle command
and a wait for completion which clearly look like this is device specific.

> Whether that is "generic" enough to reside in drivers/base/regmap can
> of course be debated but lets say I put it into drivers/mfd/ along with 
> the code currently using it. By doing that, we'll postpone this discussion 
> to the point when the first driver using it outside of drivers/mfd/ comes 
> by. At that point, having the indirect code in drivers/mfd/ is shown to 
> be a wrong choice.

> It's of course nothing that couldn't be fixed by patches moving the code 
> around to some more preferred location. And that location likely turns out 
> to be drivers/base/regmap, no? Or do you have a better place for it in 
> that case?

If you think this should be shared via regmap then make it shareable.
That needs more work than just repainting the name.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2022-11-25 18:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-17 12:05 [PATCH v2 00/11] intel-m10-bmc: Split BMC to core and SPI parts & add PMCI+N6000 support Ilpo Järvinen
2022-11-17 12:05 ` [PATCH v2 01/11] mfd: intel-m10-bmc: Create m10bmc_platform_info for type specific info Ilpo Järvinen
2022-11-17 12:05 ` [PATCH v2 02/11] mfd: intel-m10-bmc: Rename the local variables Ilpo Järvinen
2022-11-17 12:05 ` [PATCH v2 03/11] mfd: intel-m10-bmc: Split into core and spi specific parts Ilpo Järvinen
2022-11-17 12:05 ` [PATCH v2 04/11] mfd: intel-m10-bmc: Support multiple CSR register layouts Ilpo Järvinen
2022-11-17 12:05 ` [PATCH v2 05/11] fpga: intel-m10-bmc: Add flash ops for sec update Ilpo Järvinen
2022-11-17 12:05 ` [PATCH v2 06/11] mfd: intel-m10-bmc: Downscope SPI defines & prefix with M10BMC_SPI Ilpo Järvinen
2022-11-17 12:05 ` [PATCH v2 07/11] regmap: indirect: Add indirect regmap support Ilpo Järvinen
2022-11-17 13:35   ` Mark Brown
2022-11-17 14:35     ` Ilpo Järvinen
2022-11-17 15:29       ` Mark Brown
2022-11-18 12:49         ` Ilpo Järvinen
2022-11-18 13:55           ` Mark Brown
2022-11-21 13:37             ` Ilpo Järvinen
2022-11-25 18:53               ` Mark Brown [this message]
2022-11-17 12:05 ` [PATCH v2 08/11] intel-m10-bmc: Add regmap_indirect_cfg for Intel FPGA IPs Ilpo Järvinen
2022-11-17 12:05 ` [PATCH v2 09/11] mfd: intel-m10-bmc: Add PMCI driver Ilpo Järvinen
2022-11-17 12:05 ` [PATCH v2 10/11] fpga: m10bmc-sec: Add support for N6000 Ilpo Järvinen
2022-11-17 12:05 ` [PATCH v2 11/11] mfd: intel-m10-bmc: Change MODULE_LICENSE() to GPL Ilpo Järvinen
2022-12-04  9:45   ` Greg KH
2022-11-22  2:43 ` [PATCH v2 00/11] intel-m10-bmc: Split BMC to core and SPI parts & add PMCI+N6000 support Xu Yilun

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=Y4EPMbc+KCuDpuxJ@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hao.wu@intel.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=lee@kernel.org \
    --cc=linux-fpga@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marpagan@redhat.com \
    --cc=matthew.gerlach@linux.intel.com \
    --cc=mdf@kernel.org \
    --cc=rafael@kernel.org \
    --cc=russell.h.weight@intel.com \
    --cc=tianfei.zhang@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.