All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: "Bjorn Helgaas" <helgaas@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	linux-pci@vger.kernel.org,
	"Antoine Tenart" <antoine.tenart@bootlin.com>,
	"Gregory Clement" <gregory.clement@bootlin.com>,
	"Maxime Chevallier" <maxime.chevallier@bootlin.com>,
	"Nadav Haklai" <nadavh@marvell.com>,
	"Victor Gu" <xigu@marvell.com>,
	"Miquèl Raynal" <miquel.raynal@bootlin.com>,
	"Zachary Zhang" <zhangzg@marvell.com>,
	"Wilson Ding" <dingwei@marvell.com>,
	linux-arm-kernel@lists.infradead.org,
	"Ray Jui" <ray.jui@broadcom.com>,
	"Ley Foon Tan" <lftan@altera.com>,
	"Simon Horman" <horms@verge.net.au>
Subject: Re: [PATCH 1/3] PCI: Introduce PCI software bridge common logic
Date: Wed, 1 Aug 2018 11:54:30 +0200	[thread overview]
Message-ID: <20180801115430.388c62ae@windsurf> (raw)
In-Reply-To: <20180801092119.GB30658@n2100.armlinux.org.uk>

Hello Russell,

On Wed, 1 Aug 2018 10:21:19 +0100, Russell King - ARM Linux wrote:


>    All PCI devices must treat Configuration Space write operations
>    to reserved registers as no-ops; that is, the access must be
>    completed normally on the bus and the data discarded. Read
>    accesses to reserved or unimplemented registers must be completed
>    normally and a data value of 0 returned.
> 
> (eg) PCI status:
>    Reserved bits should be read-only and return zero when read.
>    A one bit is reset (if it is not read-only) whenever the register
>    is written, and the write data in the corresponding bit location
>    is a 1.
> 
> [which is why doing the read-modify-write action that some host
>  bridges that only support 32-bit accesses is dangerous - it leads
>  to various status bits being inadvertently reset.]

Speaking of this, the generic pci_generic_config_write32() function
indeed does this incorrectly, and prints a warning.

However, I just looked at the pci-thunder-pem code, and it seems to
correctly account for those W1C bits, by having an explicit list of
registers and their W1C bits (see thunder_pem_bridge_w1c_bits). This
isn't specific to the Thunder PCIe controller at all, and would benefit
from being made generic, no ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

WARNING: multiple messages have this Message-ID (diff)
From: thomas.petazzoni@bootlin.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] PCI: Introduce PCI software bridge common logic
Date: Wed, 1 Aug 2018 11:54:30 +0200	[thread overview]
Message-ID: <20180801115430.388c62ae@windsurf> (raw)
In-Reply-To: <20180801092119.GB30658@n2100.armlinux.org.uk>

Hello Russell,

On Wed, 1 Aug 2018 10:21:19 +0100, Russell King - ARM Linux wrote:


>    All PCI devices must treat Configuration Space write operations
>    to reserved registers as no-ops; that is, the access must be
>    completed normally on the bus and the data discarded. Read
>    accesses to reserved or unimplemented registers must be completed
>    normally and a data value of 0 returned.
> 
> (eg) PCI status:
>    Reserved bits should be read-only and return zero when read.
>    A one bit is reset (if it is not read-only) whenever the register
>    is written, and the write data in the corresponding bit location
>    is a 1.
> 
> [which is why doing the read-modify-write action that some host
>  bridges that only support 32-bit accesses is dangerous - it leads
>  to various status bits being inadvertently reset.]

Speaking of this, the generic pci_generic_config_write32() function
indeed does this incorrectly, and prints a warning.

However, I just looked at the pci-thunder-pem code, and it seems to
correctly account for those W1C bits, by having an explicit list of
registers and their W1C bits (see thunder_pem_bridge_w1c_bits). This
isn't specific to the Thunder PCIe controller at all, and would benefit
from being made generic, no ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

  parent reply	other threads:[~2018-08-01  9:54 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-29  9:22 [PATCH 0/3] PCI: emulated PCI bridge common logic Thomas Petazzoni
2018-06-29  9:22 ` Thomas Petazzoni
2018-06-29  9:22 ` [PATCH 1/3] PCI: Introduce PCI software " Thomas Petazzoni
2018-06-29  9:22   ` Thomas Petazzoni
2018-07-12 19:58   ` Bjorn Helgaas
2018-07-12 19:58     ` Bjorn Helgaas
2018-08-01  8:49     ` Thomas Petazzoni
2018-08-01  8:49       ` Thomas Petazzoni
2018-08-01  9:21       ` Russell King - ARM Linux
2018-08-01  9:21         ` Russell King - ARM Linux
2018-08-01  9:37         ` Thomas Petazzoni
2018-08-01  9:37           ` Thomas Petazzoni
2018-08-01  9:54         ` Thomas Petazzoni [this message]
2018-08-01  9:54           ` Thomas Petazzoni
2018-08-01 11:13       ` Thomas Petazzoni
2018-08-01 11:13         ` Thomas Petazzoni
2018-06-29  9:22 ` [PATCH 2/3] PCI: mvebu: Convert to PCI software bridge Thomas Petazzoni
2018-06-29  9:22   ` Thomas Petazzoni
2018-06-29  9:22 ` [PATCH 3/3] PCI: aardvark: Implement emulated root PCI bridge Thomas Petazzoni
2018-06-29  9:22   ` Thomas Petazzoni
2022-01-07 21:27   ` Bjorn Helgaas
2022-01-07 21:27     ` Bjorn Helgaas
2022-01-07 23:17     ` Bjorn Helgaas
2022-01-07 23:17       ` Bjorn Helgaas
2022-01-10  9:17       ` Pali Rohár
2022-01-10  9:17         ` Pali Rohár
2022-01-10  2:21     ` Marek Behún
2022-01-10  2:21       ` Marek Behún
2018-07-12  9:24 ` [PATCH 0/3] PCI: emulated PCI bridge common logic Thomas Petazzoni
2018-07-12  9:24   ` Thomas Petazzoni

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=20180801115430.388c62ae@windsurf \
    --to=thomas.petazzoni@bootlin.com \
    --cc=antoine.tenart@bootlin.com \
    --cc=bhelgaas@google.com \
    --cc=dingwei@marvell.com \
    --cc=gregory.clement@bootlin.com \
    --cc=helgaas@kernel.org \
    --cc=horms@verge.net.au \
    --cc=lftan@altera.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=maxime.chevallier@bootlin.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=nadavh@marvell.com \
    --cc=ray.jui@broadcom.com \
    --cc=xigu@marvell.com \
    --cc=zhangzg@marvell.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.