All of lore.kernel.org
 help / color / mirror / Atom feed
From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Lucas Tanure <tanureal@opensource.cirrus.com>
Cc: Mark Brown <broonie@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Sanjay R Mehta <sanju.mehta@amd.com>,
	Nehal Bakulchandra Shah <Nehal-Bakulchandra.shah@amd.com>,
	<linux-kernel@vger.kernel.org>, <linux-spi@vger.kernel.org>,
	<patches@opensource.cirrus.com>
Subject: Re: [PATCH 02/10] regmap: spi: Check raw_[read|write] against max message size
Date: Wed, 8 Sep 2021 13:17:45 +0000	[thread overview]
Message-ID: <20210908131745.GQ9223@ediswmail.ad.cirrus.com> (raw)
In-Reply-To: <20210908130929.GP9223@ediswmail.ad.cirrus.com>

On Wed, Sep 08, 2021 at 01:09:29PM +0000, Charles Keepax wrote:
> On Wed, Sep 08, 2021 at 12:34:43PM +0100, Lucas Tanure wrote:
> > regmap-spi will split data and address between two transfers
> > in the same message, so max_[read|write] must include space
> > for the address and padding
> > 
> > Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>
> > ---
> >  drivers/base/regmap/regmap-spi.c |  4 ++++
> >  drivers/base/regmap/regmap.c     | 15 +++++++++++++++
> >  include/linux/regmap.h           |  3 +++
> >  3 files changed, 22 insertions(+)
> > 
> > diff --git a/drivers/base/regmap/regmap-spi.c b/drivers/base/regmap/regmap-spi.c
> > index 0e6552e57ecf..1434c502e340 100644
> > --- a/drivers/base/regmap/regmap-spi.c
> > +++ b/drivers/base/regmap/regmap-spi.c
> > @@ -123,6 +123,10 @@ static const struct regmap_bus *regmap_get_spi_bus(struct spi_device *spi,
> >  		bus->free_on_exit = true;
> >  		bus->max_raw_read = max_size;
> >  		bus->max_raw_write = max_size;
> > +
> > +		if (spi_max_message_size(spi) != SIZE_MAX)
> > +			bus->max_combined_rw = spi_max_message_size(spi);
> 
> I am not sure max_combined_rw is the best name here, it makes
> sense in a SPI context where reads are a write followed by a
> read. But does it really make sense for all buses? Like an MMIO
> this no longer seems a very meaningful name.
> 
> Perhaps max_transaction? But I am often not the best at thinking
> of names myself.
> 

Although thinking about this more are we sure this wouldn't just
be better as a flag to include the address in the max_raw_read/write?
I am not sure what extra use-cases the extra max_combined_rw
opens up and it feels like the field is doing two things, 1)
saying that the address needs to be included in the max size and
2) specifying a new max size.

Thanks,
Charles

  reply	other threads:[~2021-09-08 13:18 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-08 11:34 [PATCH v2 00/10] Improve support for AMD SPI controllers Lucas Tanure
2021-09-08 11:34 ` [PATCH 01/10] regmap: spi: Set regmap max raw r/w from max_transfer_size Lucas Tanure
2021-09-08 11:34 ` [PATCH 02/10] regmap: spi: Check raw_[read|write] against max message size Lucas Tanure
2021-09-08 13:09   ` Charles Keepax
2021-09-08 13:17     ` Charles Keepax [this message]
2021-09-08 11:34 ` [PATCH 03/10] spi: Add flag for no TX after a RX in the same Chip Select Lucas Tanure
2021-09-08 12:37   ` Mark Brown
2021-09-09 10:51     ` Lucas tanure
2021-09-10 14:44       ` Mark Brown
2021-09-08 11:34 ` [PATCH 04/10] spi: amd: Refactor code to use less spi_master_get_devdata Lucas Tanure
2021-09-08 11:34 ` [PATCH 05/10] spi: amd: Refactor amd_spi_busy_wait Lucas Tanure
2021-09-08 11:34 ` [PATCH 06/10] spi: amd: Remove unneeded variable Lucas Tanure
2021-09-08 11:34 ` [PATCH 07/10] spi: amd: Check for idle bus before execute opcode Lucas Tanure
2021-09-08 11:34 ` [PATCH 08/10] spi: amd: Fill FIFO buffer with the whole message Lucas Tanure
2021-09-08 13:22   ` Charles Keepax
2021-09-08 11:34 ` [PATCH 09/10] spi: amd: Add support for latest platform Lucas Tanure
2021-09-12 21:53   ` Gabriel Krisman Bertazi
2021-09-08 12:28 ` [PATCH v2 00/10] Improve support for AMD SPI controllers Mark Brown

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=20210908131745.GQ9223@ediswmail.ad.cirrus.com \
    --to=ckeepax@opensource.cirrus.com \
    --cc=Nehal-Bakulchandra.shah@amd.com \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=patches@opensource.cirrus.com \
    --cc=rafael@kernel.org \
    --cc=sanju.mehta@amd.com \
    --cc=tanureal@opensource.cirrus.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.