All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nuno Sá" <noname.nuno@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>,
	Manikanta Guntupalli <manikanta.guntupalli@amd.com>,
	Jorge Marques <gastmaier@gmail.com>,
	Arnd Bergmann <arnd@kernel.org>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Jorge Marques	 <jorge.marques@analog.com>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	 Frank Li <Frank.Li@nxp.com>,
	"linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>,
	 "linux-kernel@vger.kernel.org"	 <linux-kernel@vger.kernel.org>,
	"git (AMD-Xilinx)" <git@amd.com>,
	Michal Simek	 <michal.simek@amd.com>
Subject: Re: [PATCH] [v2] i3c: fix big-endian FIFO transfers
Date: Thu, 25 Sep 2025 11:13:39 +0100	[thread overview]
Message-ID: <ab4b09ba3a332305f5e1e9d456acbecdb492bd85.camel@gmail.com> (raw)
In-Reply-To: <91e73a29-96e3-4a52-addb-0cb954f46c04@app.fastmail.com>

On Thu, 2025-09-25 at 11:35 +0200, Arnd Bergmann wrote:
> On Thu, Sep 25, 2025, at 10:58, Nuno Sá wrote:
> > On Thu, 2025-09-25 at 08:47 +0000, Guntupalli, Manikanta wrote:
> > > > (AMD-Xilinx) <git@amd.com>; Simek, Michal <michal.simek@amd.com>
> > > > Subject: Re: [PATCH] [v2] i3c: fix big-endian FIFO transfers
> > > > On Thu, 2025-09-25 at 07:37 +0000, Guntupalli, Manikanta wrote:
> > > > > > i3c@lists.infradead.org; linux-kernel@vger.kernel.org
> > > > > > Subject: Re: [PATCH] [v2] i3c: fix big-endian FIFO transfers
> > > > > > On Wed, Sep 24, 2025 at 10:18:33PM +0200, Arnd Bergmann wrote:
> > > > 
> > > > I would argue that's something for callers of these functions to care
> > > > about.
> > > If each I3C driver has to handle FIFO endianness individually, it
> > > introduces
> > > unnecessary duplication and overhead across drivers. Centralizing this in
> > > the
> > > FIFO access helpers keeps the logic consistent, avoids repeated
> > > boilerplate,
> > > and reduces the chance of subtle bugs.
> > 
> > I mean, that's what spi and i2c drivers do already. With enum
> > i3c_fifo_endian
> > you're already forcing users to care (or know) about endianism so they might
> > as
> > well just pass the data in the proper order already (not sure if it's such a
> > big
> > 'burden').
> 
> Can you give an example of an spi or i2c driver handles a similar
> situation to the new i3c driver? As far as I can tell, swapping
> the bytes in a FIFO register is very unusual for a hardware design
> and probably a mistake rather than an intentional decision.
> 

I meant that i2c and spi drivers (and I meant on the device side) already are
the ones having to care about putting the data in the proper endianism so that
controllers don't have to care (AFAIK).

But I so see now that the above is kind of unrelated.

> On the other hand, I can find drivers that are obviously wrong
> on big-endian kernels, such as Tegra's i2c_writesl_vi() function
> being unintentionally swapped from i2c_writesl() on big-endian.
> 
> For the i3c helper, I think Jorge's current version with my
> fix should work for every normal driver, and I would not
> want to make it more complicated for an obscure case. The
> version for the AMD driver can just be in that driver, or
> it could be a separate function name in the common header
> if there is a chance we'll need it again.
> 

I do agree with the above.

- Nuno Sá

>       Arnd

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

WARNING: multiple messages have this Message-ID (diff)
From: "Nuno Sá" <noname.nuno@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>,
	Manikanta Guntupalli <manikanta.guntupalli@amd.com>,
	Jorge Marques <gastmaier@gmail.com>,
	Arnd Bergmann <arnd@kernel.org>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Jorge Marques	 <jorge.marques@analog.com>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	 Frank Li <Frank.Li@nxp.com>,
	"linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>,
	 "linux-kernel@vger.kernel.org"	 <linux-kernel@vger.kernel.org>,
	"git (AMD-Xilinx)" <git@amd.com>,
	Michal Simek	 <michal.simek@amd.com>
Subject: Re: [PATCH] [v2] i3c: fix big-endian FIFO transfers
Date: Thu, 25 Sep 2025 11:13:39 +0100	[thread overview]
Message-ID: <ab4b09ba3a332305f5e1e9d456acbecdb492bd85.camel@gmail.com> (raw)
In-Reply-To: <91e73a29-96e3-4a52-addb-0cb954f46c04@app.fastmail.com>

On Thu, 2025-09-25 at 11:35 +0200, Arnd Bergmann wrote:
> On Thu, Sep 25, 2025, at 10:58, Nuno Sá wrote:
> > On Thu, 2025-09-25 at 08:47 +0000, Guntupalli, Manikanta wrote:
> > > > (AMD-Xilinx) <git@amd.com>; Simek, Michal <michal.simek@amd.com>
> > > > Subject: Re: [PATCH] [v2] i3c: fix big-endian FIFO transfers
> > > > On Thu, 2025-09-25 at 07:37 +0000, Guntupalli, Manikanta wrote:
> > > > > > i3c@lists.infradead.org; linux-kernel@vger.kernel.org
> > > > > > Subject: Re: [PATCH] [v2] i3c: fix big-endian FIFO transfers
> > > > > > On Wed, Sep 24, 2025 at 10:18:33PM +0200, Arnd Bergmann wrote:
> > > > 
> > > > I would argue that's something for callers of these functions to care
> > > > about.
> > > If each I3C driver has to handle FIFO endianness individually, it
> > > introduces
> > > unnecessary duplication and overhead across drivers. Centralizing this in
> > > the
> > > FIFO access helpers keeps the logic consistent, avoids repeated
> > > boilerplate,
> > > and reduces the chance of subtle bugs.
> > 
> > I mean, that's what spi and i2c drivers do already. With enum
> > i3c_fifo_endian
> > you're already forcing users to care (or know) about endianism so they might
> > as
> > well just pass the data in the proper order already (not sure if it's such a
> > big
> > 'burden').
> 
> Can you give an example of an spi or i2c driver handles a similar
> situation to the new i3c driver? As far as I can tell, swapping
> the bytes in a FIFO register is very unusual for a hardware design
> and probably a mistake rather than an intentional decision.
> 

I meant that i2c and spi drivers (and I meant on the device side) already are
the ones having to care about putting the data in the proper endianism so that
controllers don't have to care (AFAIK).

But I so see now that the above is kind of unrelated.

> On the other hand, I can find drivers that are obviously wrong
> on big-endian kernels, such as Tegra's i2c_writesl_vi() function
> being unintentionally swapped from i2c_writesl() on big-endian.
> 
> For the i3c helper, I think Jorge's current version with my
> fix should work for every normal driver, and I would not
> want to make it more complicated for an obscure case. The
> version for the AMD driver can just be in that driver, or
> it could be a separate function name in the common header
> if there is a chance we'll need it again.
> 

I do agree with the above.

- Nuno Sá

>       Arnd

  reply	other threads:[~2025-09-25 10:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-24 20:18 [PATCH] [v2] i3c: fix big-endian FIFO transfers Arnd Bergmann
2025-09-24 20:18 ` Arnd Bergmann
2025-09-25  7:16 ` Jorge Marques
2025-09-25  7:16   ` Jorge Marques
2025-09-25  7:37   ` Guntupalli, Manikanta
2025-09-25  7:37     ` Guntupalli, Manikanta
2025-09-25  7:51     ` Nuno Sá
2025-09-25  7:51       ` Nuno Sá
2025-09-25  8:47       ` Guntupalli, Manikanta
2025-09-25  8:47         ` Guntupalli, Manikanta
2025-09-25  8:58         ` Nuno Sá
2025-09-25  8:58           ` Nuno Sá
2025-09-25  9:35           ` Arnd Bergmann
2025-09-25  9:35             ` Arnd Bergmann
2025-09-25 10:13             ` Nuno Sá [this message]
2025-09-25 10:13               ` Nuno Sá
2025-09-25  8:55     ` Arnd Bergmann
2025-09-25  8:55       ` Arnd Bergmann
2025-09-25 15:09 ` Frank Li
2025-09-25 15:09   ` Frank Li
2025-09-26 10:38   ` Guntupalli, Manikanta
2025-09-26 10:38     ` Guntupalli, Manikanta
2025-09-28 22:19 ` Alexandre Belloni
2025-09-28 22:19   ` Alexandre Belloni

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=ab4b09ba3a332305f5e1e9d456acbecdb492bd85.camel@gmail.com \
    --to=noname.nuno@gmail.com \
    --cc=Frank.Li@nxp.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=gastmaier@gmail.com \
    --cc=git@amd.com \
    --cc=jorge.marques@analog.com \
    --cc=linux-i3c@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manikanta.guntupalli@amd.com \
    --cc=michal.simek@amd.com \
    --cc=wsa+renesas@sang-engineering.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.