Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: f.fainelli@gmail.com, robh+dt@kernel.org, ardb@kernel.org,
	hch@infradead.org, narmstrong@baylibre.com, dwmw2@infradead.org,
	linux@armlinux.org.uk, catalin.marinas@arm.com, arnd@arndb.de,
	will@kernel.org
Subject: Re: [RFC 09/13] iommu/arm-smmu: Make use of dev_64bit_mmio_supported()
Date: Tue, 2 Mar 2021 11:07:19 +0000
Message-ID: <3a4cf13f-c098-9ff3-6c0e-2c94daae452b@arm.com> (raw)
In-Reply-To: <20210226140305.26356-10-nsaenzjulienne@suse.de>

On 2021-02-26 14:03, Nicolas Saenz Julienne wrote:
> Some arm SMMU implementations might sit on a bus that doesn't support
> 64bit memory accesses. In that case default to using hi_lo_{readq,
> writeq}() and BUG if such platform tries to use AArch64 formats as they
> rely on writeq()'s atomicity.
> 
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---
>   drivers/iommu/arm/arm-smmu/arm-smmu.c | 9 +++++++++
>   drivers/iommu/arm/arm-smmu/arm-smmu.h | 9 +++++++--
>   2 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index d8c6bfde6a61..239ff42b20c3 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -1889,6 +1889,15 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
>   			smmu->features |= ARM_SMMU_FEAT_FMT_AARCH64_64K;
>   	}
>   
> +	/*
> +	 * 64bit accesses not possible through the interconnect, AArch64
> +	 * formats depend on it.
> +	 */
> +	BUG_ON(!dev_64bit_mmio_supported(smmu->dev) &&
> +	       smmu->features & (ARM_SMMU_FEAT_FMT_AARCH64_4K |
> +				ARM_SMMU_FEAT_FMT_AARCH64_16K |
> +				ARM_SMMU_FEAT_FMT_AARCH64_64K));

No. Crashing the kernel in a probe routine which is free to fail is 
unacceptable either way, but guaranteeing failure in the case that the 
workaround *would* be required is doubly so.

Basically, this logic is backwards - if you really wanted to handle it 
generically, this would be the point at which you'd need to actively 
suppress all the detected hardware features which depend on 64-bit 
atomicity, not complain about them.

> +
>   	if (smmu->impl && smmu->impl->cfg_probe) {
>   		ret = smmu->impl->cfg_probe(smmu);
>   		if (ret)
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> index d2a2d1bc58ba..997d13a21717 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> @@ -477,15 +477,20 @@ static inline void arm_smmu_writel(struct arm_smmu_device *smmu, int page,
>   {
>   	if (smmu->impl && unlikely(smmu->impl->write_reg))
>   		smmu->impl->write_reg(smmu, page, offset, val);
> -	else
> +	else if (dev_64bit_mmio_supported(smmu->dev))
>   		writel_relaxed(val, arm_smmu_page(smmu, page) + offset);
> +	else
> +		hi_lo_writeq_relaxed(val, arm_smmu_page(smmu, page) + offset);

As Arnd pointed out, this is in completely the wrong place. Also, in 
general it doesn't work if the implementation already needs a hook to 
filter or override register accesses for any other reason. TBH I'm not 
convinced that this isn't *more* of a mess than handling it on a 
SoC-specific basis...

Robin.

>   }
>   
>   static inline u64 arm_smmu_readq(struct arm_smmu_device *smmu, int page, int offset)
>   {
>   	if (smmu->impl && unlikely(smmu->impl->read_reg64))
>   		return smmu->impl->read_reg64(smmu, page, offset);
> -	return readq_relaxed(arm_smmu_page(smmu, page) + offset);
> +	else if (dev_64bit_mmio_supported(smmu->dev))
> +		return readq_relaxed(arm_smmu_page(smmu, page) + offset);
> +	else
> +		return hi_lo_readq_relaxed(arm_smmu_page(smmu, page) + offset);
>   }
>   
>   static inline void arm_smmu_writeq(struct arm_smmu_device *smmu, int page,
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply index

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-26 14:02 [RFC 00/13] Generic way of dealing with broken 64-bit buses Nicolas Saenz Julienne
2021-02-26 14:02 ` [RFC 01/13] dt-bindings: Introduce 64bit-mmio-broken Nicolas Saenz Julienne
2021-02-26 14:02 ` [RFC 02/13] driver core: Introduce MMIO configuration Nicolas Saenz Julienne
2021-03-02 11:29   ` Robin Murphy
2021-03-02 14:09     ` Nicolas Saenz Julienne
2021-02-26 14:02 ` [RFC 03/13] of: device: Introduce of_mmio_configure() Nicolas Saenz Julienne
2021-02-26 14:02 ` [RFC 04/13] driver core: plafrom: Introduce platform_mmio_configure() Nicolas Saenz Julienne
2021-02-26 14:02 ` [RFC 05/13] pci: Introduce pci_mmio_configure() Nicolas Saenz Julienne
2021-02-26 14:02 ` [RFC 06/13] device core: Introduce dev_64bit_mmio_supported() Nicolas Saenz Julienne
2021-02-26 14:02 ` [RFC 07/13] arm64: Mark ARCH_MVEBU as needing broken 64bit MMIO support Nicolas Saenz Julienne
2021-02-26 14:03 ` [RFC 08/13] arm64: dts: marvell: armada-ap80x: Mark config-space bus as 64bit-mmio-broken Nicolas Saenz Julienne
2021-02-26 14:03 ` [RFC 09/13] iommu/arm-smmu: Make use of dev_64bit_mmio_supported() Nicolas Saenz Julienne
2021-03-02  9:32   ` Arnd Bergmann
2021-03-02 12:42     ` Nicolas Saenz Julienne
2021-03-02 11:07   ` Robin Murphy [this message]
2021-03-02 13:38     ` Nicolas Saenz Julienne
2021-03-03  8:44     ` Arnd Bergmann
2021-02-26 14:03 ` [RFC 10/13] iommu/arm-smmu-impl: Get rid of Marvell's implementation details Nicolas Saenz Julienne
2021-03-02 11:40   ` Robin Murphy
2021-03-02 14:06     ` Nicolas Saenz Julienne
2021-02-26 14:03 ` [RFC 11/13] arm64: Mark ARCH_BCM2835 as needing broken 64bit MMIO support Nicolas Saenz Julienne
2021-02-26 14:03 ` [RFC 12/13] ARM: dts: bcm2711: Mark PCIe bus as 64bit-mmio-broken Nicolas Saenz Julienne
2021-02-26 14:03 ` [RFC 13/13] scsi: megaraid: Make use of dev_64bit_mmio_supported() Nicolas Saenz Julienne
2021-02-26 14:30   ` Arnd Bergmann
2021-02-26 18:06     ` Arnd Bergmann

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=3a4cf13f-c098-9ff3-6c0e-2c94daae452b@arm.com \
    --to=robin.murphy@arm.com \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=f.fainelli@gmail.com \
    --cc=hch@infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=narmstrong@baylibre.com \
    --cc=nsaenzjulienne@suse.de \
    --cc=robh+dt@kernel.org \
    --cc=will@kernel.org \
    /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

Linux-ARM-Kernel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/0 linux-arm-kernel/git/0.git
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/1 linux-arm-kernel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ https://lore.kernel.org/linux-arm-kernel \
		linux-arm-kernel@lists.infradead.org
	public-inbox-index linux-arm-kernel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-arm-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git