public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eddie James <eajames@linux.ibm.com>
To: Mark Brown <broonie@kernel.org>
Cc: joel@jms.id.au, jk@ozlabs.org, alistair@popple.id.au,
	linux-kernel@vger.kernel.org, linux-fsi@lists.ozlabs.org
Subject: Re: [PATCH 0/5] fsi: Add regmap and refactor sbefifo
Date: Wed, 19 Oct 2022 13:59:23 -0500	[thread overview]
Message-ID: <ac1ffdbe-809b-698f-b8aa-b4d0955b1d1d@linux.ibm.com> (raw)
In-Reply-To: <Y07pqhpm/1hzx9LR@sirena.org.uk>


On 10/18/22 13:00, Mark Brown wrote:
> On Tue, Oct 18, 2022 at 09:02:33AM -0500, Eddie James wrote:
>> On 10/17/22 12:37, Mark Brown wrote:
>>> Is there any great reason to provide support in the regmap core for this
>>> rather than just implementing in drivers/fsi?  AFAICT this is just
>>> ending up as an implementation detail of shared code in drivers/fsi and
>>> won't have any external users?
>> One reason is to have a common interface with the new FSI regmap. That way
>> abstracting out the bus transfer is trivial in the new SBEFIFO driver,
>> assuming the SBEFIFO driver should switch to use the FSI regmap.
>> But you are correct, I doubt anyone else will use this. I suppose SBEFIFO
>> may as well not use the regmap and just use some callbacks for whichever bus
>> transfer...
> I'm not saying don't use regmap, I'm saying why not just do this in the
> driver - you can just as easily set the reg_read() and reg_write()
> callbacks in an individual driver without needing to create a new regmap
> bus type for just that one driver to use.


I understand. That sounds like a good approach then, I'll work on that 
for v2.

Thanks,

Eddie



      parent reply	other threads:[~2022-10-19 19:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-14 22:05 [PATCH 0/5] fsi: Add regmap and refactor sbefifo Eddie James
2022-10-14 22:05 ` [PATCH 1/5] regmap: Add FSI bus support Eddie James
2022-10-14 22:05 ` [PATCH 2/5] regmap: Add IBM I2CR support Eddie James
2022-10-14 22:05 ` [PATCH 3/5] drivers: fsi: Rename sbefifo and occ sources Eddie James
2022-10-14 22:05 ` [PATCH 4/5] drivers: fsi: separate char device code for occ and sbefifo Eddie James
2022-10-17 20:53   ` kernel test robot
2022-10-14 22:05 ` [PATCH 5/5] drivers: fsi: occ and sbefifo refactor Eddie James
2022-10-17 22:34   ` kernel test robot
2022-10-17 23:35   ` kernel test robot
2022-10-18 13:14   ` kernel test robot
2022-10-17 17:37 ` [PATCH 0/5] fsi: Add regmap and refactor sbefifo Mark Brown
2022-10-18 14:02   ` Eddie James
2022-10-18 18:00     ` Mark Brown
2022-10-18 22:03       ` Andrew Jeffery
2022-10-19 18:59       ` Eddie James [this message]

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=ac1ffdbe-809b-698f-b8aa-b4d0955b1d1d@linux.ibm.com \
    --to=eajames@linux.ibm.com \
    --cc=alistair@popple.id.au \
    --cc=broonie@kernel.org \
    --cc=jk@ozlabs.org \
    --cc=joel@jms.id.au \
    --cc=linux-fsi@lists.ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox