All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Arnd Bergmann" <arnd@arndb.de>
Cc: "Valentin Korenblit" <vkorenblit@sequans.com>,
	"kernel test robot" <lkp@intel.com>,
	llvm@lists.linux.dev, kbuild-all@lists.01.org,
	linux-kernel@vger.kernel.org
Subject: Re: [mtd:nand/next 11/31] drivers/mtd/nand/raw/cadence-nand-controller.c:1893:4: error: implicit declaration of function 'ioread64_rep' is invalid in C99
Date: Thu, 22 Sep 2022 11:38:09 +0200	[thread overview]
Message-ID: <20220922113809.0a4d3d35@xps-13> (raw)
In-Reply-To: <b7e5ebb4-0de8-4958-9bc4-fe06ec4c3635@www.fastmail.com>

Hi Arnd,

> > ioread64_rep is then only defined if CONFIG_64BIT. As it is based
> > on readsq/writesq() and those must be defined (as you said), I don't get
> > why the *64_rep() helpers are not defined in all cases. Maybe because no
> > 32-bit system _should_ need them? But then compile testing gets more
> > difficult.  
> 
> Both readsq/writesq and ioread64_rep/iowrite64_rep must be defined
> for 64-bit architectures and cannot be defined for 32-bit ones.

Yeah, ok.

> >> - For a FIFO, you cannot use readq() but have to use __raw_readq()
> >>   to get the correct endianness. You cannot use this for an
> >>   MMIO register with side-effects though, as this needs the byteswap
> >>   and the barrier in readsl().  
> >
> > I'm not sure about the true definition of "FIFO" as you say. I guess
> > you just mean reading from a BE device?
> >
> > In this case I guess we need the barrier+byteswap helpers.  
> 
> The difference is that a register has a fixed length, and gets
> accessed with a device specific endianness, which may have to
> be swapped if the device and the CPU disagree.
> 
> A FIFO register is what you use for transferring a stream of
> bytes, such as reading a file system block from disk. The
> first byte in the register corresponds to the first byte in
> memory later, so there must not be any byteswap while copying
> to/from memory. If the data itself is structured (i.e. an
> on-disk inode or a network packet), then the byteswap will
> happen if necessary while interpreting the data.

Ok, I fully get what you mean, I was just not used to the word FIFO for
this definition as I use it as a more generic term, but it completely
makes sense. Thanks for taking the time to explain.

Thanks,
Miquèl

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: kbuild-all@lists.01.org
Subject: Re: [mtd:nand/next 11/31] drivers/mtd/nand/raw/cadence-nand-controller.c:1893:4: error: implicit declaration of function 'ioread64_rep' is invalid in C99
Date: Thu, 22 Sep 2022 11:38:09 +0200	[thread overview]
Message-ID: <20220922113809.0a4d3d35@xps-13> (raw)
In-Reply-To: <b7e5ebb4-0de8-4958-9bc4-fe06ec4c3635@www.fastmail.com>

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

Hi Arnd,

> > ioread64_rep is then only defined if CONFIG_64BIT. As it is based
> > on readsq/writesq() and those must be defined (as you said), I don't get
> > why the *64_rep() helpers are not defined in all cases. Maybe because no
> > 32-bit system _should_ need them? But then compile testing gets more
> > difficult.  
> 
> Both readsq/writesq and ioread64_rep/iowrite64_rep must be defined
> for 64-bit architectures and cannot be defined for 32-bit ones.

Yeah, ok.

> >> - For a FIFO, you cannot use readq() but have to use __raw_readq()
> >>   to get the correct endianness. You cannot use this for an
> >>   MMIO register with side-effects though, as this needs the byteswap
> >>   and the barrier in readsl().  
> >
> > I'm not sure about the true definition of "FIFO" as you say. I guess
> > you just mean reading from a BE device?
> >
> > In this case I guess we need the barrier+byteswap helpers.  
> 
> The difference is that a register has a fixed length, and gets
> accessed with a device specific endianness, which may have to
> be swapped if the device and the CPU disagree.
> 
> A FIFO register is what you use for transferring a stream of
> bytes, such as reading a file system block from disk. The
> first byte in the register corresponds to the first byte in
> memory later, so there must not be any byteswap while copying
> to/from memory. If the data itself is structured (i.e. an
> on-disk inode or a network packet), then the byteswap will
> happen if necessary while interpreting the data.

Ok, I fully get what you mean, I was just not used to the word FIFO for
this definition as I use it as a more generic term, but it completely
makes sense. Thanks for taking the time to explain.

Thanks,
Miquèl

  parent reply	other threads:[~2022-09-22  9:43 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-20 22:31 [mtd:nand/next 11/31] drivers/mtd/nand/raw/cadence-nand-controller.c:1893:4: error: implicit declaration of function 'ioread64_rep' is invalid in C99 kernel test robot
2022-09-21  8:40 ` Miquel Raynal
2022-09-21  8:40   ` Miquel Raynal
2022-09-21  8:45   ` Valentin Korenblit
2022-09-21  8:45     ` Valentin Korenblit
2022-09-21 12:27     ` Valentin Korenblit
2022-09-21 14:47       ` Miquel Raynal
2022-09-21 14:47         ` Miquel Raynal
2022-09-21 15:49         ` Arnd Bergmann
2022-09-21 15:49           ` Arnd Bergmann
2022-09-21 16:38           ` Miquel Raynal
2022-09-21 16:38             ` Miquel Raynal
2022-09-21 20:01             ` Arnd Bergmann
2022-09-21 20:01               ` Arnd Bergmann
2022-09-22  8:18               ` Valentin Korenblit
2022-09-22  9:36                 ` Miquel Raynal
2022-09-22  9:36                   ` Miquel Raynal
2022-09-22 10:52                   ` Arnd Bergmann
2022-09-22 10:52                     ` Arnd Bergmann
2022-09-22 11:00                     ` Miquel Raynal
2022-09-22 11:00                       ` Miquel Raynal
2022-09-27 14:56                     ` Valentin Korenblit
2022-09-27 20:02                       ` Arnd Bergmann
2022-09-27 20:02                         ` Arnd Bergmann
2022-09-28  8:41                         ` Valentin Korenblit
2022-09-28  8:41                           ` Valentin Korenblit
2022-09-28  8:56                           ` Arnd Bergmann
2022-09-28  8:56                             ` Arnd Bergmann
2022-09-28 10:04                             ` Valentin Korenblit
2022-09-28 10:04                               ` Valentin Korenblit
2022-09-22  9:38               ` Miquel Raynal [this message]
2022-09-22  9:38                 ` Miquel Raynal

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=20220922113809.0a4d3d35@xps-13 \
    --to=miquel.raynal@bootlin.com \
    --cc=arnd@arndb.de \
    --cc=kbuild-all@lists.01.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=llvm@lists.linux.dev \
    --cc=vkorenblit@sequans.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.