linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	linux-pci@vger.kernel.org,
	Gregory Price <gregory.price@memverge.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Alison Schofield <alison.schofield@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Dave Jiang <dave.jiang@intel.com>,
	"Li, Ming" <ming4.li@intel.com>, Hillf Danton <hdanton@sina.com>,
	Ben Widawsky <bwidawsk@kernel.org>,
	linuxarm@huawei.com, linux-cxl@vger.kernel.org
Subject: Re: [PATCH v3 01/16] cxl/pci: Fix CDAT retrieval on big endian
Date: Sun, 19 Feb 2023 14:03:32 +0100	[thread overview]
Message-ID: <20230219130332.GA20728@wunner.de> (raw)
In-Reply-To: <63e6dfd7cc162_1e4943294e9@dwillia2-xfh.jf.intel.com.notmuch>

On Fri, Feb 10, 2023 at 04:22:47PM -0800, Dan Williams wrote:
> Lukas Wunner wrote:
> > PCI Configuration Space is little endian (PCI r3.0 sec 6.1).  Accessors
> > such as pci_read_config_dword() implicitly swap bytes on big endian.
> > That way, the macros in include/uapi/linux/pci_regs.h work regardless of
> > the arch's endianness.  For an example of implicit byte-swapping, see
> > ppc4xx_pciex_read_config(), which calls in_le32(), which uses lwbrx
> > (Load Word Byte-Reverse Indexed).
> > 
> > DOE Read/Write Data Mailbox Registers are unlike other registers in
> > Configuration Space in that they contain or receive a 4 byte portion of
> > an opaque byte stream (a "Data Object" per PCIe r6.0 sec 7.9.24.5f).
> > They need to be copied to or from the request/response buffer verbatim.
> > So amend pci_doe_send_req() and pci_doe_recv_resp() to undo the implicit
> > byte-swapping.
[...]
> > --- a/drivers/pci/doe.c
> > +++ b/drivers/pci/doe.c
> > @@ -143,7 +143,7 @@ static int pci_doe_send_req(struct pci_doe_mb *doe_mb,
> >  					  length));
> >  	for (i = 0; i < task->request_pl_sz / sizeof(u32); i++)
> >  		pci_write_config_dword(pdev, offset + PCI_DOE_WRITE,
> > -				       task->request_pl[i]);
> > +				       le32_to_cpu(task->request_pl[i]));
> 
> What do you think about defining:
> 
> int pci_doe_write(const struct pci_dev *dev, int where, __le32 val);
> int pci_doe_read(const struct pci_dev *dev, int where, __le32 *val);
> 
> ...local to this file to make it extra clear that DOE transfers are
> passing raw byte-streams and not register values as
> pci_{write,read}_config_dword() expect.

I've done a prototype (see below), but it doesn't strike me as an
improvement:

There are only two occurrences for each of those read and write accessors,
so the diffstat isn't pretty (27 insertions, 12 deletions).

Moreover, the request header constructed in pci_doe_send_req() is
constructed in native endianness and written using the standard
pci_write_config_dword() accessor.  Same for the response header
parsed in pci_doe_recv_resp().  Thus, the functions do not
consistently use the new custom accessors, but rather use a mix
of the standard accessors and custom accessors.  So clarity may
not improve all that much.

Let me know if you feel otherwise!

The patch below goes on top of the series.  I'm using a variation
of your suggested approach in that I've named the custom accessors
pci_doe_{write,read}_data() (for consistency with the existing
pci_doe_write_ctrl()).

Thanks,

Lukas

-- >8 --

diff --git a/drivers/pci/doe.c b/drivers/pci/doe.c
index 8499cf9..6b0148e 100644
--- a/drivers/pci/doe.c
+++ b/drivers/pci/doe.c
@@ -106,6 +106,24 @@ static void pci_doe_write_ctrl(struct pci_doe_mb *doe_mb, u32 val)
 	pci_write_config_dword(pdev, offset + PCI_DOE_CTRL, val);
 }
 
+static void pci_doe_write_data(struct pci_doe_mb *doe_mb, __le32 lav)
+{
+	struct pci_dev *pdev = doe_mb->pdev;
+	int offset = doe_mb->cap_offset;
+
+	pci_write_config_dword(pdev, offset + PCI_DOE_WRITE, le32_to_cpu(lav));
+}
+
+static void pci_doe_read_data(struct pci_doe_mb *doe_mb, __le32 *lav)
+{
+	struct pci_dev *pdev = doe_mb->pdev;
+	int offset = doe_mb->cap_offset;
+	u32 val;
+
+	pci_read_config_dword(pdev, offset + PCI_DOE_READ, &val);
+	*lav = cpu_to_le32(val);
+}
+
 static int pci_doe_abort(struct pci_doe_mb *doe_mb)
 {
 	struct pci_dev *pdev = doe_mb->pdev;
@@ -144,6 +162,7 @@ static int pci_doe_send_req(struct pci_doe_mb *doe_mb,
 	struct pci_dev *pdev = doe_mb->pdev;
 	int offset = doe_mb->cap_offset;
 	size_t length, remainder;
+	__le32 lav;
 	u32 val;
 	int i;
 
@@ -177,16 +196,14 @@ static int pci_doe_send_req(struct pci_doe_mb *doe_mb,
 
 	/* Write payload */
 	for (i = 0; i < task->request_pl_sz / sizeof(__le32); i++)
-		pci_write_config_dword(pdev, offset + PCI_DOE_WRITE,
-				       le32_to_cpu(task->request_pl[i]));
+		pci_doe_write_data(doe_mb, task->request_pl[i]);
 
 	/* Write last payload dword */
 	remainder = task->request_pl_sz % sizeof(__le32);
 	if (remainder) {
-		val = 0;
-		memcpy(&val, &task->request_pl[i], remainder);
-		le32_to_cpus(&val);
-		pci_write_config_dword(pdev, offset + PCI_DOE_WRITE, val);
+		lav = 0;
+		memcpy(&lav, &task->request_pl[i], remainder);
+		pci_doe_write_data(doe_mb, lav);
 	}
 
 	pci_doe_write_ctrl(doe_mb, PCI_DOE_CTRL_GO);
@@ -211,6 +228,7 @@ static int pci_doe_recv_resp(struct pci_doe_mb *doe_mb, struct pci_doe_task *tas
 	size_t length, payload_length, remainder, received;
 	struct pci_dev *pdev = doe_mb->pdev;
 	int offset = doe_mb->cap_offset;
+	__le32 lav;
 	int i = 0;
 	u32 val;
 
@@ -256,16 +274,13 @@ static int pci_doe_recv_resp(struct pci_doe_mb *doe_mb, struct pci_doe_task *tas
 	if (payload_length) {
 		/* Read all payload dwords except the last */
 		for (; i < payload_length - 1; i++) {
-			pci_read_config_dword(pdev, offset + PCI_DOE_READ,
-					      &val);
-			task->response_pl[i] = cpu_to_le32(val);
+			pci_doe_read_data(doe_mb, &task->response_pl[i]);
 			pci_write_config_dword(pdev, offset + PCI_DOE_READ, 0);
 		}
 
 		/* Read last payload dword */
-		pci_read_config_dword(pdev, offset + PCI_DOE_READ, &val);
-		cpu_to_le32s(&val);
-		memcpy(&task->response_pl[i], &val, remainder);
+		pci_doe_read_data(doe_mb, &lav);
+		memcpy(&task->response_pl[i], &lav, remainder);
 		/* Prior to the last ack, ensure Data Object Ready */
 		if (!pci_doe_data_obj_ready(doe_mb))
 			return -EIO;

  reply	other threads:[~2023-02-19 13:03 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-10 20:25 [PATCH v3 00/16] Collection of DOE material Lukas Wunner
2023-02-10 20:25 ` [PATCH v3 01/16] cxl/pci: Fix CDAT retrieval on big endian Lukas Wunner
2023-02-11  0:22   ` Dan Williams
2023-02-19 13:03     ` Lukas Wunner [this message]
2023-02-14 11:15   ` Jonathan Cameron
2023-02-14 13:51     ` Lukas Wunner
2023-02-14 15:45       ` Jonathan Cameron
2023-02-28  2:53   ` Alexey Kardashevskiy
2023-02-28  8:24     ` Lukas Wunner
2023-02-28 12:08       ` Alexey Kardashevskiy
2023-02-10 20:25 ` [PATCH v3 02/16] cxl/pci: Handle truncated CDAT header Lukas Wunner
2023-02-11  0:40   ` Dan Williams
2023-02-11  9:34     ` Lukas Wunner
2023-02-14 11:16   ` Jonathan Cameron
2023-02-15  1:41   ` Li, Ming
2023-02-10 20:25 ` [PATCH v3 03/16] cxl/pci: Handle truncated CDAT entries Lukas Wunner
2023-02-11  0:50   ` Dan Williams
2023-02-11 10:56     ` Lukas Wunner
2023-02-14 11:30   ` Jonathan Cameron
2023-02-10 20:25 ` [PATCH v3 04/16] cxl/pci: Handle excessive CDAT length Lukas Wunner
2023-02-11  1:04   ` Dan Williams
2023-02-14 11:33   ` Jonathan Cameron
2023-02-16 10:26     ` Lukas Wunner
2023-02-17 10:01       ` Jonathan Cameron
2023-02-10 20:25 ` [PATCH v3 05/16] PCI/DOE: Silence WARN splat with CONFIG_DEBUG_OBJECTS=y Lukas Wunner
2023-02-10 20:25 ` [PATCH v3 06/16] PCI/DOE: Fix memory leak " Lukas Wunner
2023-02-11  1:06   ` Dan Williams
2023-03-01  1:51   ` Davidlohr Bueso
2023-02-10 20:25 ` [PATCH v3 07/16] PCI/DOE: Provide synchronous API and use it internally Lukas Wunner
2023-02-15  1:45   ` Li, Ming
2023-02-28 18:58   ` Davidlohr Bueso
2023-02-10 20:25 ` [PATCH v3 08/16] cxl/pci: Use synchronous API for DOE Lukas Wunner
2023-02-10 20:25 ` [PATCH v3 09/16] PCI/DOE: Make asynchronous API private Lukas Wunner
2023-02-15  1:48   ` Li, Ming
2023-02-10 20:25 ` [PATCH v3 10/16] PCI/DOE: Deduplicate mailbox flushing Lukas Wunner
2023-02-14 11:36   ` Jonathan Cameron
2023-02-15  5:07   ` Li, Ming
2023-02-10 20:25 ` [PATCH v3 11/16] PCI/DOE: Allow mailbox creation without devres management Lukas Wunner
2023-02-14 11:51   ` Jonathan Cameron
2023-02-15  5:17   ` Li, Ming
2023-02-10 20:25 ` [PATCH v3 12/16] PCI/DOE: Create mailboxes on device enumeration Lukas Wunner
2023-02-15  2:07   ` Li, Ming
2023-02-28  1:18   ` Alexey Kardashevskiy
2023-02-28  1:39     ` Dan Williams
2023-02-28  5:43     ` Lukas Wunner
2023-02-28  7:24       ` Alexey Kardashevskiy
2023-02-28 10:42         ` Jonathan Cameron
2023-03-02 20:22         ` Lukas Wunner
2023-03-07  1:55           ` Alexey Kardashevskiy
2023-04-03  0:55           ` Alexey Kardashevskiy
2023-02-10 20:25 ` [PATCH v3 13/16] cxl/pci: Use CDAT DOE mailbox created by PCI core Lukas Wunner
2023-02-10 20:25 ` [PATCH v3 14/16] PCI/DOE: Make mailbox creation API private Lukas Wunner
2023-02-15  2:13   ` Li, Ming
2023-02-10 20:25 ` [PATCH v3 15/16] PCI/DOE: Relax restrictions on request and response size Lukas Wunner
2023-02-15  5:05   ` Li, Ming
2023-02-15 11:49     ` Lukas Wunner
2023-02-10 20:25 ` [PATCH v3 16/16] cxl/pci: Rightsize CDAT response allocation Lukas Wunner
2023-02-14 13:05   ` Jonathan Cameron
2023-02-16  0:56   ` Ira Weiny
2023-02-16  8:03     ` Lukas Wunner
2023-02-28  1:45   ` Alexey Kardashevskiy
2023-02-28  5:55     ` Lukas Wunner

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=20230219130332.GA20728@wunner.de \
    --to=lukas@wunner.de \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=alison.schofield@intel.com \
    --cc=bwidawsk@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=gregory.price@memverge.com \
    --cc=hdanton@sina.com \
    --cc=helgaas@kernel.org \
    --cc=ira.weiny@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=ming4.li@intel.com \
    --cc=vishal.l.verma@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).