* [RFC PATCH 1/2] ARM: vfp - allow kernel mode NEON in softirq context
From: Ard Biesheuvel @ 2017-01-11 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111175649.GK14217@n2100.armlinux.org.uk>
On 11 January 2017 at 17:56, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Mon, Jan 09, 2017 at 07:57:28PM +0000, Ard Biesheuvel wrote:
>> This updates the kernel mode NEON handling to allow the NEON to be used
>> in softirq context as well as process context. This involves disabling
>> softirq processing when the NEON is used in kernel mode in process context,
>> and dealing with the situation where 'current' is not the owner of the
>> userland context that is present in the NEON register file when the NEON
>> is enabled in kernel mode.
>
> I really don't like this idea as-is.
>
> We have cases where kernel code accesses VFP to (eg) save or restore
> register state, such as during signal handling. We assume that this
> will not be interrupted by another user, and that if we enable access
> to the VFP, it will stay enabled. If it gets disabled beneath us, then
> things won't go well.
>
> For example, consider vfp_sync_hwstate():
>
> vfp_sync_hwstate()
> vfp_state_in_hw() => true
> fpexc read
> softirq happens
> kernel_neon_begin()
> kernel_neon_end()
> fpexc re-enabled
> current register state saved out (corrupting what was there)
> fpexc restored, possible in an enabled state
>
> Or we could have:
>
> vfp_sync_hwstate()
> vfp_state_in_hw() => true
> softirq happens
> kernel_neon_begin()
> kernel_neon_end()
> fpexc read
> fpexc re-enabled
> current register state saved out (corrupting what was there)
> fpexc disabled
>
> Or worse:
>
> vfp_sync_hwstate()
> vfp_state_in_hw() => true
> fpexc read
> fpexc re-enabled
> softirq happens
> kernel_neon_begin()
> kernel_neon_end()
> current register state saved out, blowing up because VFP is
> unexpectedly disabled
>
> So we would need to disable softirqs around every sensitive point in the
> VFP support code, and over all VFP instruction emulations for those VFPs
> which bounce "difficult" operations to the kernel support code.
>
Ah yes, I should have known it couldn't be that simple.
Thanks for the critique: i will look into the impact of making these changes.
>> The rationale for this change is that the NEON is shared with the ARMv8
>> Crypto Extensions (which are also defined for the AArch32 execution state),
>> which can give a huge performance boost (15x) to use cases like mac80211
>> CCMP processing, which executes in softirq context.
>
> I think, once the implementation is more correct, this would need to
> be re-evaluated, and I'd also like other more general performance
> measurements as well (eg, latency.)
>
Re latency, I thought about adding a kernel_neon_yield(), which does a
kernel_neon_end()/do_softirq()/kernel_neon_begin() sequence if any
softirqs are pending, to be invoked by kernel mode NEON users at times
when there are no live NEON registers. But in-kernel users of the
crypto API are naturally quantised into disk sectors, pages or network
packets, so I would not expect any noticeable starvation to occur. But
that does mean such algorithms should not be exposed to userland
(which sounds like a bad idea in any case, given that userland can
simply execute the same instructions)
^ permalink raw reply
* [PATCH v2] arm64: do not set dma masks that device connection can't handle
From: Robin Murphy @ 2017-01-11 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7c6a1523-e41b-ad83-501a-27c260b9f9ee@cogentembedded.com>
On 11/01/17 12:37, Nikita Yushchenko wrote:
>> I actually have a third variation of this problem involving a PCI root
>> complex which *could* drive full-width (40-bit) addresses, but won't,
>> due to the way its PCI<->AXI interface is programmed. That would require
>> even more complicated dma-ranges handling to describe the windows of
>> valid physical addresses which it *will* pass, so I'm not pressing the
>> issue - let's just get the basic DMA mask case fixed first.
>
> R-Car + NVMe is actually not "basic case".
I meant "basic" in terms of what needs to be done in Linux - simply
preventing device drivers from overwriting the DT-configured DMA mask
will make everything work as well as well as it possibly can on R-Car,
both with or without the IOMMU, since apparently all you need is to
ensure a PCI device never gets given a DMA address above 4GB. The
situation where PCI devices *can* DMA to all of physical memory, but
can't use arbitrary addresses *outside* it - which only becomes a
problem with an IOMMU - is considerably trickier.
> It has PCI<->AXI interface involved.
> PCI addresses are 64-bit and controller does handle 64-bit addresses
> there. Mapping between PCI addresses and AXI addresses is defined. But
> AXI is 32-bit.
>
> SoC has iommu that probably could be used between PCIe module and RAM.
> Although AFAIK nobody made that working yet.
>
> Board I work with has 4G of RAM, in 4 banks, located at different parts
> of wide address space, and only one of them is below 4G. But if iommu is
> capable of translating addresses such that 4 gigabyte banks map to first
> 4 gigabytes of address space, then all memory will become available for
> DMA from PCIe device.
The aforementioned situation on Juno is similar yet different - the PLDA
XR3 root complex uses an address-based lookup table to translate
outgoing PCI memory space transactions to AXI bus addresses with the
appropriate attributes, in power-of-two-sized regions. The firmware
configures 3 LUT entries - 2GB at 0x8000_0000 and 8GB at 0x8_8000_0000
with cache-coherent attributes to cover the DRAM areas, plus a small one
with device attributes covering the GICv2m MSI frame. The issue is that
there is no "no match" translation, so any transaction not within one of
those regions never makes it out of the root complex at all.
That's fine in normal operation, as there's nothing outside those
regions in the physical memory map a PCI device should be accessing
anyway, but turning on the SMMU is another matter - since the IOVA
allocator runs top-down, a PCI device with a 64-bit DMA mask will do a
dma_map or dma_alloc, get the physical page mapped to an IOVA up around
FF_FFFF_F000 (the SMMU will constrain things to the system bus width of
40 bits), then try to access that address and get a termination straight
back from the RC. Similarly, A KVM guest which wants to place its memory
at arbitrary locations and expect device passthrough to work is going to
have a bad time.
I don't know if it's feasible to have the firmware set the LUT up
differently, as that might lead to other problems when not using the
SMMU, and/or just require far more than the 8 available LUT entries
(assuming they have to be non-overlapping - I'm not 100% sure and
documentation is sparse). Thus it seems appropriate to describe the
currently valid PCI-AXI translations with dma-ranges, but then we'd have
multiple entries - last time I looked Linux simply ignores all but the
last one in that case - which can't be combined into a simple bitmask,
so I'm not entirely sure where to go from there. Especially as so far it
seems to be a problem exclusive to one not-widely-available ageing
early-access development platform...
It happens that limiting all PCI DMA masks to 32 bits would bodge around
this problem thanks to the current IOVA allocator behaviour, but that's
pretty yuck, and would force unnecessary bouncing for the non-SMMU case.
My other hack to carve up IOVA domains to reserve all addresses not
matching memblocks is hardly any more realistic, hence why the SMMU is
in the Juno DT in a change-it-at-your-own-peril "disabled" state ;)
Robin.
^ permalink raw reply
* [PATCH] PCI: mvebu: Handle changes to the bridge windows while enabled
From: Bjorn Helgaas @ 2017-01-11 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212183020.GA30274@obsidianresearch.com>
On Mon, Dec 12, 2016 at 11:30:20AM -0700, Jason Gunthorpe wrote:
> The PCI core will write to the bridge window config multiple times
> while they are enabled. This can lead to mbus failures like:
>
> mvebu_mbus: cannot add window '4:e8', conflicts with another window
> mvebu-pcie mbus:pex at e0000000: Could not create MBus window at [mem 0xe0000000-0xe00fffff]: -22
>
> For me this is happening during a hotplug cycle. The PCI core is
> not changing the values, just writing them twice while active.
>
> The patch addresses the general case of any change to an active window,
> but not atomically. The code is slightly refactored so io and mem
> can share more of the window logic.
Looks good to me, but I'm waiting for an ack from Thomas or Jason (listed
as maintainers and already cc'd).
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> ---
> drivers/pci/host/pci-mvebu.c | 101 +++++++++++++++++++++++++------------------
> 1 file changed, 60 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> index 307f81d6b479af..af724731b22f53 100644
> --- a/drivers/pci/host/pci-mvebu.c
> +++ b/drivers/pci/host/pci-mvebu.c
> @@ -133,6 +133,12 @@ struct mvebu_pcie {
> int nports;
> };
>
> +struct mvebu_pcie_window {
> + phys_addr_t base;
> + phys_addr_t remap;
> + size_t size;
> +};
> +
> /* Structure representing one PCIe interface */
> struct mvebu_pcie_port {
> char *name;
> @@ -150,10 +156,8 @@ struct mvebu_pcie_port {
> struct mvebu_sw_pci_bridge bridge;
> struct device_node *dn;
> struct mvebu_pcie *pcie;
> - phys_addr_t memwin_base;
> - size_t memwin_size;
> - phys_addr_t iowin_base;
> - size_t iowin_size;
> + struct mvebu_pcie_window memwin;
> + struct mvebu_pcie_window iowin;
> u32 saved_pcie_stat;
> };
>
> @@ -379,23 +383,45 @@ static void mvebu_pcie_add_windows(struct mvebu_pcie_port *port,
> }
> }
>
> +static void mvebu_pcie_set_window(struct mvebu_pcie_port *port,
> + unsigned int target, unsigned int attribute,
> + const struct mvebu_pcie_window *desired,
> + struct mvebu_pcie_window *cur)
> +{
> + if (desired->base == cur->base && desired->remap == cur->remap &&
> + desired->size == cur->size)
> + return;
> +
> + if (cur->size != 0) {
> + mvebu_pcie_del_windows(port, cur->base, cur->size);
> + cur->size = 0;
> + cur->base = 0;
> +
> + /*
> + * If something tries to change the window while it is enabled
> + * the change will not be done atomically. That would be
> + * difficult to do in the general case.
> + */
> + }
> +
> + if (desired->size == 0)
> + return;
> +
> + mvebu_pcie_add_windows(port, target, attribute, desired->base,
> + desired->size, desired->remap);
> + *cur = *desired;
> +}
> +
> static void mvebu_pcie_handle_iobase_change(struct mvebu_pcie_port *port)
> {
> - phys_addr_t iobase;
> + struct mvebu_pcie_window desired = {};
>
> /* Are the new iobase/iolimit values invalid? */
> if (port->bridge.iolimit < port->bridge.iobase ||
> port->bridge.iolimitupper < port->bridge.iobaseupper ||
> !(port->bridge.command & PCI_COMMAND_IO)) {
> -
> - /* If a window was configured, remove it */
> - if (port->iowin_base) {
> - mvebu_pcie_del_windows(port, port->iowin_base,
> - port->iowin_size);
> - port->iowin_base = 0;
> - port->iowin_size = 0;
> - }
> -
> + mvebu_pcie_set_window(port, port->io_target, port->io_attr,
> + &desired, &port->iowin);
> return;
> }
>
> @@ -412,32 +438,27 @@ static void mvebu_pcie_handle_iobase_change(struct mvebu_pcie_port *port)
> * specifications. iobase is the bus address, port->iowin_base
> * is the CPU address.
> */
> - iobase = ((port->bridge.iobase & 0xF0) << 8) |
> - (port->bridge.iobaseupper << 16);
> - port->iowin_base = port->pcie->io.start + iobase;
> - port->iowin_size = ((0xFFF | ((port->bridge.iolimit & 0xF0) << 8) |
> - (port->bridge.iolimitupper << 16)) -
> - iobase) + 1;
> -
> - mvebu_pcie_add_windows(port, port->io_target, port->io_attr,
> - port->iowin_base, port->iowin_size,
> - iobase);
> + desired.remap = ((port->bridge.iobase & 0xF0) << 8) |
> + (port->bridge.iobaseupper << 16);
> + desired.base = port->pcie->io.start + desired.remap;
> + desired.size = ((0xFFF | ((port->bridge.iolimit & 0xF0) << 8) |
> + (port->bridge.iolimitupper << 16)) -
> + desired.remap) +
> + 1;
> +
> + mvebu_pcie_set_window(port, port->io_target, port->io_attr, &desired,
> + &port->iowin);
> }
>
> static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
> {
> + struct mvebu_pcie_window desired = {.remap = MVEBU_MBUS_NO_REMAP};
> +
> /* Are the new membase/memlimit values invalid? */
> if (port->bridge.memlimit < port->bridge.membase ||
> !(port->bridge.command & PCI_COMMAND_MEMORY)) {
> -
> - /* If a window was configured, remove it */
> - if (port->memwin_base) {
> - mvebu_pcie_del_windows(port, port->memwin_base,
> - port->memwin_size);
> - port->memwin_base = 0;
> - port->memwin_size = 0;
> - }
> -
> + mvebu_pcie_set_window(port, port->mem_target, port->mem_attr,
> + &desired, &port->memwin);
> return;
> }
>
> @@ -447,14 +468,12 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
> * window to setup, according to the PCI-to-PCI bridge
> * specifications.
> */
> - port->memwin_base = ((port->bridge.membase & 0xFFF0) << 16);
> - port->memwin_size =
> - (((port->bridge.memlimit & 0xFFF0) << 16) | 0xFFFFF) -
> - port->memwin_base + 1;
> -
> - mvebu_pcie_add_windows(port, port->mem_target, port->mem_attr,
> - port->memwin_base, port->memwin_size,
> - MVEBU_MBUS_NO_REMAP);
> + desired.base = ((port->bridge.membase & 0xFFF0) << 16);
> + desired.size = (((port->bridge.memlimit & 0xFFF0) << 16) | 0xFFFFF) -
> + desired.base + 1;
> +
> + mvebu_pcie_set_window(port, port->mem_target, port->mem_attr, &desired,
> + &port->memwin);
> }
>
> /*
> --
> 2.7.4
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC PATCH 1/2] ARM: vfp - allow kernel mode NEON in softirq context
From: Russell King - ARM Linux @ 2017-01-11 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9S66y0QuOcJdwrT-WoQOCJged-MzfXqdm20RYVGg9w8w@mail.gmail.com>
On Wed, Jan 11, 2017 at 06:23:10PM +0000, Ard Biesheuvel wrote:
> Re latency, I thought about adding a kernel_neon_yield(), which does a
> kernel_neon_end()/do_softirq()/kernel_neon_begin() sequence if any
> softirqs are pending, to be invoked by kernel mode NEON users at times
> when there are no live NEON registers. But in-kernel users of the
> crypto API are naturally quantised into disk sectors, pages or network
> packets, so I would not expect any noticeable starvation to occur. But
> that does mean such algorithms should not be exposed to userland
> (which sounds like a bad idea in any case, given that userland can
> simply execute the same instructions)
I was actually thinking about the impact of adding softirq disabling
over much of the VFP code necessary to make this safe, rather than the
softirq disable coming from the kernel mode neon itself.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 0/2] arm64: fix handling of DMA masks wider than bus supports
From: Nikita Yushchenko @ 2017-01-11 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dca35acf-1adf-aa85-7a0b-d0c6ec702fa1@arm.com>
> I reckon the easiest way forward would be to pass in some flag to
> arch_setup_dma_ops to indicate whether it's an explicitly-configured
> range or not - then simply initialising parent_dma_mask to ~0 for the
> default case *should* keep things working as before.
Tried to do that.
---
Nikita Yushchenko (2):
dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
arm64: avoid increasing DMA masks above what hardware supports
arch/arm/include/asm/dma-mapping.h | 1 +
arch/arm/mm/dma-mapping.c | 3 +-
arch/arm64/Kconfig | 3 ++
arch/arm64/include/asm/device.h | 1 +
arch/arm64/include/asm/dma-mapping.h | 6 +++-
arch/arm64/mm/dma-mapping.c | 43 +++++++++++++++++++++++++-
arch/mips/include/asm/dma-mapping.h | 3 +-
drivers/acpi/scan.c | 2 +-
drivers/iommu/rockchip-iommu.c | 2 +-
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
drivers/of/device.c | 5 ++-
drivers/staging/fsl-mc/bus/fsl-mc-bus.c | 2 +-
12 files changed, 64 insertions(+), 9 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Nikita Yushchenko @ 2017-01-11 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484159512-28515-1-git-send-email-nikita.yoush@cogentembedded.com>
There are cases when device is capable of wide DMA mask (and driver
issues corresponding dma_set_mask() call), but bus device sits on can't
support wide address. Example: NVMe device behind PCIe controller
sitting on 32-bit SoC bus.
To support such case, architecture needs information about such
limitations. Such information can originate from dma-ranges property
in device tree, and is passed to architecture via arch_setup_dma_ops()
call.
Problem is that in wide majority of cases, no dma range is defined.
E.g. ACPI has no means to define it. Thus default range (usually
full 32-bit range, i.e. 4G starting at zero address) is passed instead.
If architecture enforce this range, all setups currently using
wide DMA addresses without explicitly defining support for that via
device tree will break. This is bad, especially for ACPI based
platforms.
To avoid that, this patch adds additional boolean argument to
arch_setup_dma_ops() to show if range originates from authorative source
and thus should be enforced, or is just a guess and should be handled as
such.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
---
arch/arm/include/asm/dma-mapping.h | 1 +
arch/arm/mm/dma-mapping.c | 3 ++-
arch/arm64/include/asm/dma-mapping.h | 3 ++-
arch/arm64/mm/dma-mapping.c | 3 ++-
arch/mips/include/asm/dma-mapping.h | 3 ++-
drivers/acpi/scan.c | 2 +-
drivers/iommu/rockchip-iommu.c | 2 +-
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
drivers/of/device.c | 5 ++++-
drivers/staging/fsl-mc/bus/fsl-mc-bus.c | 2 +-
10 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index bf02dbd..2a3863e 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -117,6 +117,7 @@ static inline unsigned long dma_max_pfn(struct device *dev)
#define arch_setup_dma_ops arch_setup_dma_ops
extern void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
+ bool enforce_range,
const struct iommu_ops *iommu, bool coherent);
#define arch_teardown_dma_ops arch_teardown_dma_ops
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ab77100..b8b11f8 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2380,7 +2380,8 @@ static struct dma_map_ops *arm_get_dma_map_ops(bool coherent)
}
void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
- const struct iommu_ops *iommu, bool coherent)
+ bool enforce_range, const struct iommu_ops *iommu,
+ bool coherent)
{
struct dma_map_ops *dma_ops;
diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
index ccea82c..ae1c23f 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -48,7 +48,8 @@ static inline struct dma_map_ops *get_dma_ops(struct device *dev)
}
void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
- const struct iommu_ops *iommu, bool coherent);
+ bool enforce_range, const struct iommu_ops *iommu,
+ bool coherent);
#define arch_setup_dma_ops arch_setup_dma_ops
#ifdef CONFIG_IOMMU_DMA
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index e040827..ea295f1 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -953,7 +953,8 @@ static void __iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
#endif /* CONFIG_IOMMU_DMA */
void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
- const struct iommu_ops *iommu, bool coherent)
+ bool enforce_range, const struct iommu_ops *iommu,
+ bool coherent)
{
if (!dev->archdata.dma_ops)
dev->archdata.dma_ops = &swiotlb_dma_ops;
diff --git a/arch/mips/include/asm/dma-mapping.h b/arch/mips/include/asm/dma-mapping.h
index 7aa71b9..6af4d87 100644
--- a/arch/mips/include/asm/dma-mapping.h
+++ b/arch/mips/include/asm/dma-mapping.h
@@ -34,7 +34,8 @@ extern void dma_cache_sync(struct device *dev, void *vaddr, size_t size,
#define arch_setup_dma_ops arch_setup_dma_ops
static inline void arch_setup_dma_ops(struct device *dev, u64 dma_base,
- u64 size, const struct iommu_ops *iommu,
+ u64 size, bool enforce_range,
+ const struct iommu_ops *iommu,
bool coherent)
{
#ifdef CONFIG_DMA_PERDEV_COHERENT
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 1926918..dea17a5 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1385,7 +1385,7 @@ void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
* Assume dma valid range starts at 0 and covers the whole
* coherent_dma_mask.
*/
- arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, iommu,
+ arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, false, iommu,
attr == DEV_DMA_COHERENT);
}
EXPORT_SYMBOL_GPL(acpi_dma_configure);
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 9afcbf7..0995ab3 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -1096,7 +1096,7 @@ static int rk_iommu_domain_probe(struct platform_device *pdev)
return -ENOMEM;
/* Set dma_ops for dev, otherwise it would be dummy_dma_ops */
- arch_setup_dma_ops(dev, 0, DMA_BIT_MASK(32), NULL, false);
+ arch_setup_dma_ops(dev, 0, DMA_BIT_MASK(32), false, NULL, false);
dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index c9b7ad6..19f70d8 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2533,7 +2533,7 @@ static int dpaa_eth_probe(struct platform_device *pdev)
priv->buf_layout[TX].priv_data_size = DPAA_TX_PRIV_DATA_SIZE; /* Tx */
/* device used for DMA mapping */
- arch_setup_dma_ops(dev, 0, 0, NULL, false);
+ arch_setup_dma_ops(dev, 0, 0, false, NULL, false);
err = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(40));
if (err) {
dev_err(dev, "dma_coerce_mask_and_coherent() failed\n");
diff --git a/drivers/of/device.c b/drivers/of/device.c
index fd5cfad..1cc2115 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -89,6 +89,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
bool coherent;
unsigned long offset;
const struct iommu_ops *iommu;
+ bool enforce_range = false;
/*
* Set default coherent_dma_mask to 32 bit. Drivers are expected to
@@ -126,6 +127,8 @@ void of_dma_configure(struct device *dev, struct device_node *np)
return;
}
dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
+
+ enforce_range = true;
}
dev->dma_pfn_offset = offset;
@@ -147,7 +150,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
dev_dbg(dev, "device is%sbehind an iommu\n",
iommu ? " " : " not ");
- arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent);
+ arch_setup_dma_ops(dev, dma_addr, size, enforce_range, iommu, coherent);
}
EXPORT_SYMBOL_GPL(of_dma_configure);
diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
index 5ac373c..480b644 100644
--- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
+++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
@@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
/* Objects are coherent, unless 'no shareability' flag set. */
if (!(obj_desc->flags & DPRC_OBJ_FLAG_NO_MEM_SHAREABILITY))
- arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
+ arch_setup_dma_ops(&mc_dev->dev, 0, 0, false, NULL, true);
/*
* The device-specific probe callback will get invoked by device_add()
--
2.1.4
^ permalink raw reply related
* [PATCH 2/2] arm64: avoid increasing DMA masks above what hardware supports
From: Nikita Yushchenko @ 2017-01-11 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484159512-28515-1-git-send-email-nikita.yoush@cogentembedded.com>
There are cases when device supports wide DMA addresses wider than
device's connection supports.
In this case driver sets DMA mask based on knowledge of device
capabilities. That must succeed to allow drivers to initialize.
However, swiotlb or iommu still need knowledge about actual device
capabilities. To avoid breakage, actual mask must not be set wider than
device connection allows.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Robin Murphy <robin.murphy@arm.com>
CC: Will Deacon <will.deacon@arm.com>
---
arch/arm64/Kconfig | 3 +++
arch/arm64/include/asm/device.h | 1 +
arch/arm64/include/asm/dma-mapping.h | 3 +++
arch/arm64/mm/dma-mapping.c | 40 ++++++++++++++++++++++++++++++++++++
4 files changed, 47 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1117421..afb2c08 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -216,6 +216,9 @@ config NEED_DMA_MAP_STATE
config NEED_SG_DMA_LENGTH
def_bool y
+config ARCH_HAS_DMA_SET_COHERENT_MASK
+ def_bool y
+
config SMP
def_bool y
diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index 243ef25..a57e7bb 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -22,6 +22,7 @@ struct dev_archdata {
void *iommu; /* private IOMMU data */
#endif
bool dma_coherent;
+ u64 parent_dma_mask;
};
struct pdev_archdata {
diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
index ae1c23f..46b53e6 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -52,6 +52,9 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
bool coherent);
#define arch_setup_dma_ops arch_setup_dma_ops
+#define HAVE_ARCH_DMA_SET_MASK 1
+extern int dma_set_mask(struct device *dev, u64 dma_mask);
+
#ifdef CONFIG_IOMMU_DMA
void arch_teardown_dma_ops(struct device *dev);
#define arch_teardown_dma_ops arch_teardown_dma_ops
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index ea295f1..31b96fd 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -203,6 +203,37 @@ static void __dma_free(struct device *dev, size_t size,
__dma_free_coherent(dev, size, swiotlb_addr, dma_handle, attrs);
}
+int dma_set_mask(struct device *dev, u64 dma_mask)
+{
+ const struct dma_map_ops *ops = get_dma_ops(dev);
+
+ if (mask > dev->archdata.parent_dma_mask)
+ mask = dev->archdata.parent_dma_mask;
+
+ if (ops->set_dma_mask)
+ return ops->set_dma_mask(dev, mask);
+
+ if (!dev->dma_mask || !dma_supported(dev, mask))
+ return -EIO;
+
+ *dev->dma_mask = mask;
+ return 0;
+}
+EXPORT_SYMBOL(dma_set_mask);
+
+int dma_set_coherent_mask(struct device *dev, u64 mask)
+{
+ if (mask > dev->archdata.parent_dma_mask)
+ mask = dev->archdata.parent_dma_mask;
+
+ if (!dma_supported(dev, mask))
+ return -EIO;
+
+ dev->coherent_dma_mask = mask;
+ return 0;
+}
+EXPORT_SYMBOL(dma_set_coherent_mask);
+
static dma_addr_t __swiotlb_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,
enum dma_data_direction dir,
@@ -959,6 +990,15 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
if (!dev->archdata.dma_ops)
dev->archdata.dma_ops = &swiotlb_dma_ops;
+ /*
+ * Whatever the parent bus can set. A device must not set
+ * a DMA mask larger than this.
+ */
+ if (enforce_range)
+ dev->archdata.parent_dma_mask = size - 1;
+ else
+ dev->archdata.parent_dma_mask = DMA_BIT_MASK(64);
+
dev->archdata.dma_coherent = coherent;
__iommu_setup_dma_ops(dev, dma_base, size, iommu);
}
--
2.1.4
^ permalink raw reply related
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Mark Rutland @ 2017-01-11 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111180627.GG20288@e104818-lin.cambridge.arm.com>
On Wed, Jan 11, 2017 at 06:06:27PM +0000, Catalin Marinas wrote:
> On Wed, Jan 11, 2017 at 09:41:15AM -0500, Christopher Covington wrote:
> > -| Implementor | Component | Erratum ID | Kconfig |
> > +| Implementor | Component | Erratum ID | Kconfig |
> > +| Qualcomm | Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
>
> Please don't change the "Implementor" column width, there is no point
> and it makes the patch harder to read (i.e. this hunk should only have
> one line).
It'll need to affect all lines since the kconfig column needs to expand
by at least one character to fit QCOM_FALKOR_ERRATUM_1003.
I beleive the intent here was to keep the table fitting into a width of
80 characters.
IMO we should allow the table to expand past 80 chars (everyone reading
this file should be able to resize tehir terminal), and only expand the
kconfig column.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Timur Tabi @ 2017-01-11 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111183339.GC29247@leverpostej>
On 01/11/2017 12:33 PM, Mark Rutland wrote:
> It'll need to affect all lines since the kconfig column needs to expand
> by at least one character to fit QCOM_FALKOR_ERRATUM_1003.
Or we can make the macro shorter.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Mark Rutland @ 2017-01-11 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5da456f8-fcc5-b6e2-d58b-01a671da595b@codeaurora.org>
On Wed, Jan 11, 2017 at 12:35:55PM -0600, Timur Tabi wrote:
> On 01/11/2017 12:33 PM, Mark Rutland wrote:
> >It'll need to affect all lines since the kconfig column needs to expand
> >by at least one character to fit QCOM_FALKOR_ERRATUM_1003.
>
> Or we can make the macro shorter.
The name, as it is, is perfectly descriptive.
Let's not sacrifice legibility over a non-issue.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Timur Tabi @ 2017-01-11 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111183738.GD29247@leverpostej>
On 01/11/2017 12:37 PM, Mark Rutland wrote:
> The name, as it is, is perfectly descriptive.
>
> Let's not sacrifice legibility over a non-issue.
I don't want to kick a dead horse or anything, but changing it to
QCOM_FLKR_ERRATUM_1003 would eliminate all the spacing problems without
sacrificing anything.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Mark Rutland @ 2017-01-11 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <278a45c0-bd49-b8a2-63ae-80ad851bab9b@arm.com>
On Wed, Jan 11, 2017 at 06:22:08PM +0000, Marc Zyngier wrote:
> On 11/01/17 18:06, Catalin Marinas wrote:
> > On Wed, Jan 11, 2017 at 09:41:15AM -0500, Christopher Covington wrote:
> >> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> >> index 32682be..9ee46df 100644
> >> --- a/arch/arm64/mm/proc.S
> >> +++ b/arch/arm64/mm/proc.S
> >> @@ -23,6 +23,7 @@
> >> #include <asm/assembler.h>
> >> #include <asm/asm-offsets.h>
> >> #include <asm/hwcap.h>
> >> +#include <asm/mmu_context.h>
> >> #include <asm/pgtable.h>
> >> #include <asm/pgtable-hwdef.h>
> >> #include <asm/cpufeature.h>
> >> @@ -140,6 +141,18 @@ ENDPROC(cpu_do_resume)
> >> ENTRY(cpu_do_switch_mm)
> >> mmid x1, x1 // get mm->context.id
> >> bfi x0, x1, #48, #16 // set the ASID
> >> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
> >> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1003
> >> + mrs x2, ttbr0_el1
> >> + mov x3, #FALKOR_RESERVED_ASID
> >> + bfi x2, x3, #48, #16 // reserved ASID + old BADDR
> >> + msr ttbr0_el1, x2
> >> + isb
> >> + bfi x2, x0, #0, #48 // reserved ASID + new BADDR
> >> + msr ttbr0_el1, x2
> >> + isb
> >> +alternative_else_nop_endif
> >> +#endif
> >> msr ttbr0_el1, x0 // set TTBR0
> >> isb
> >> post_ttbr0_update_workaround
> >
> > Please move the above hunk to a pre_ttbr0_update_workaround macro for
> > consistency with post_ttbr0_update_workaround.
>
> In which case (and also for consistency), should we add that pre_ttbr0
> macro to entry.S, just before __uaccess_ttbr0_enable? It may not be
> needed in the SW pan case, but it is probably worth entertaining the
> idea that there may be something to do there...
Likewise, I beleive we may need to modify cpu_set_reserved_ttbr0().
Thanks,
Mark.
^ permalink raw reply
* [PATCH 32/62] watchdog: meson_gxbb_wdt: Convert to use device managed functions and other improvements
From: Kevin Hilman @ 2017-01-11 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484095516-12720-2-git-send-email-linux@roeck-us.net>
Guenter Roeck <linux@roeck-us.net> writes:
> Use device managed functions to simplify error handling, reduce
> source code size, improve readability, and reduce the likelyhood of bugs.
> Other improvements as listed below.
>
> The conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts used
> to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> - Use devm_add_action_or_reset() for calls to clk_disable_unprepare
> - Check return value from clk_prepare_enable()
> - Replace 'val = e; return val;' with 'return e;'
> - Replace 'if (e) return e; return 0;' with 'return e;'
> - Drop assignments to otherwise unused variables
> - Replace 'if (e) { return expr; }' with 'if (e) return expr;'
> - Drop remove function
> - Use devm_watchdog_register_driver() to register watchdog device
> - Replace shutdown function with call to watchdog_stop_on_reboot()
>
> Cc: Carlo Caione <carlo@caione.org>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Nice, thanks for the cleanup!
Acked-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* [PATCH 33/62] watchdog: meson_wdt: Convert to use device managed functions and other improvements
From: Kevin Hilman @ 2017-01-11 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484095516-12720-3-git-send-email-linux@roeck-us.net>
Guenter Roeck <linux@roeck-us.net> writes:
> Use device managed functions to simplify error handling, reduce
> source code size, improve readability, and reduce the likelyhood of bugs.
> Other improvements as listed below.
>
> The conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts used
> to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> - Drop assignments to otherwise unused variables
> - Drop remove function
> - Drop platform_set_drvdata()
> - Use devm_watchdog_register_driver() to register watchdog device
> - Replace shutdown function with call to watchdog_stop_on_reboot()
>
> Cc: Carlo Caione <carlo@caione.org>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Mark Rutland @ 2017-01-11 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2069d58c-0b81-dad4-511f-05e7d002eb34@codeaurora.org>
On Wed, Jan 11, 2017 at 12:40:42PM -0600, Timur Tabi wrote:
> On 01/11/2017 12:37 PM, Mark Rutland wrote:
> >The name, as it is, is perfectly descriptive.
> >
> >Let's not sacrifice legibility over a non-issue.
>
> I don't want to kick a dead horse or anything, but changing it to
> QCOM_FLKR_ERRATUM_1003 would eliminate all the spacing problems
> without sacrificing anything.
The CPU is called "Falkor", not "FLKR", and we're not coming up with an
ACPI table name...
The ARM Ltd. erratum numbers are global to all parts, so we don't
include the part name. Is the 1003 erratum number specific to Falkor?
If it's global, you could use QCOM_ERRATUM_1003 instead.
Otherwise, QCOM_FALKOR_ERRATUM_1003 is preferable.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Marc Zyngier @ 2017-01-11 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2069d58c-0b81-dad4-511f-05e7d002eb34@codeaurora.org>
[finally, some proper bikeshedding]
On 11/01/17 18:40, Timur Tabi wrote:
> On 01/11/2017 12:37 PM, Mark Rutland wrote:
>> The name, as it is, is perfectly descriptive.
>>
>> Let's not sacrifice legibility over a non-issue.
>
> I don't want to kick a dead horse or anything, but changing it to
> QCOM_FLKR_ERRATUM_1003 would eliminate all the spacing problems without
> sacrificing anything.
Other than not being able to grep for the core name in the source tree,
how do you suggest we pronounce FLKR? Because so far, it rolls off the
tongue in an interesting way...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* kvm: deadlock in kvm_vgic_map_resources
From: Dmitry Vyukov @ 2017-01-11 19:01 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
While running syzkaller fuzzer I've got the following deadlock.
On commit 9c763584b7c8911106bb77af7e648bef09af9d80.
=============================================
[ INFO: possible recursive locking detected ]
4.9.0-rc6-xc2-00056-g08372dd4b91d-dirty #50 Not tainted
---------------------------------------------
syz-executor/20805 is trying to acquire lock:
(
&kvm->lock
){+.+.+.}
, at:
[< inline >] kvm_vgic_dist_destroy
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:271
[<ffff2000080ea4bc>] kvm_vgic_destroy+0x34/0x250
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:294
but task is already holding lock:
(&kvm->lock){+.+.+.}, at:
[<ffff2000080ea7e4>] kvm_vgic_map_resources+0x2c/0x108
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:343
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&kvm->lock);
lock(&kvm->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by syz-executor/20805:
#0:(&vcpu->mutex){+.+.+.}, at:
[<ffff2000080bcc30>] vcpu_load+0x28/0x1d0
arch/arm64/kvm/../../../virt/kvm/kvm_main.c:143
#1:(&kvm->lock){+.+.+.}, at:
[<ffff2000080ea7e4>] kvm_vgic_map_resources+0x2c/0x108
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:343
stack backtrace:
CPU: 2 PID: 20805 Comm: syz-executor Not tainted
4.9.0-rc6-xc2-00056-g08372dd4b91d-dirty #50
Hardware name: Hardkernel ODROID-C2 (DT)
Call trace:
[<ffff200008090560>] dump_backtrace+0x0/0x3c8 arch/arm64/kernel/traps.c:69
[<ffff200008090948>] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:219
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffff200008895840>] dump_stack+0x100/0x150 lib/dump_stack.c:51
[< inline >] print_deadlock_bug kernel/locking/lockdep.c:1728
[< inline >] check_deadlock kernel/locking/lockdep.c:1772
[< inline >] validate_chain kernel/locking/lockdep.c:2250
[<ffff2000081c8718>] __lock_acquire+0x1938/0x3440 kernel/locking/lockdep.c:3335
[<ffff2000081caa84>] lock_acquire+0xdc/0x1d8 kernel/locking/lockdep.c:3746
[< inline >] __mutex_lock_common kernel/locking/mutex.c:521
[<ffff200009700004>] mutex_lock_nested+0xdc/0x7b8 kernel/locking/mutex.c:621
[< inline >] kvm_vgic_dist_destroy
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:271
[<ffff2000080ea4bc>] kvm_vgic_destroy+0x34/0x250
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:294
[<ffff2000080ec290>] vgic_v2_map_resources+0x218/0x430
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c:295
[<ffff2000080ea884>] kvm_vgic_map_resources+0xcc/0x108
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:348
[< inline >] kvm_vcpu_first_run_init
arch/arm64/kvm/../../../arch/arm/kvm/arm.c:505
[<ffff2000080d2768>] kvm_arch_vcpu_ioctl_run+0xab8/0xce0
arch/arm64/kvm/../../../arch/arm/kvm/arm.c:591
[<ffff2000080c1fec>] kvm_vcpu_ioctl+0x434/0xc08
arch/arm64/kvm/../../../virt/kvm/kvm_main.c:2557
[< inline >] vfs_ioctl fs/ioctl.c:43
[<ffff200008450c38>] do_vfs_ioctl+0x128/0xfc0 fs/ioctl.c:679
[< inline >] SYSC_ioctl fs/ioctl.c:694
[<ffff200008451b78>] SyS_ioctl+0xa8/0xb8 fs/ioctl.c:685
[<ffff200008083ef0>] el0_svc_naked+0x24/0x28 arch/arm64/kernel/entry.S:755
INFO: task syz-executor:20805 blocked for more than 120 seconds.
Not tainted 4.9.0-rc6-xc2-00056-g08372dd4b91d-dirty #50
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor D 0 20805 1 0x00000001
Call trace:
[<ffff2000080894f4>] __switch_to+0x184/0x258 arch/arm64/kernel/process.c:345
[< inline >] context_switch kernel/sched/core.c:2899
[<ffff2000096fcc64>] __schedule+0x42c/0x1298 kernel/sched/core.c:3402
[<ffff2000096fdb98>] schedule+0xc8/0x260 kernel/sched/core.c:3457
[<ffff2000096fe654>] schedule_preempt_disabled+0x74/0x110
kernel/sched/core.c:3490
[< inline >] __mutex_lock_common kernel/locking/mutex.c:582
[<ffff200009700240>] mutex_lock_nested+0x318/0x7b8 kernel/locking/mutex.c:621
[< inline >] kvm_vgic_dist_destroy
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:271
[<ffff2000080ea4bc>] kvm_vgic_destroy+0x34/0x250
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:294
[<ffff2000080ec290>] vgic_v2_map_resources+0x218/0x430
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c:295
[<ffff2000080ea884>] kvm_vgic_map_resources+0xcc/0x108
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:348
[< inline >] kvm_vcpu_first_run_init
arch/arm64/kvm/../../../arch/arm/kvm/arm.c:505
[<ffff2000080d2768>] kvm_arch_vcpu_ioctl_run+0xab8/0xce0
arch/arm64/kvm/../../../arch/arm/kvm/arm.c:591
[<ffff2000080c1fec>] kvm_vcpu_ioctl+0x434/0xc08
arch/arm64/kvm/../../../virt/kvm/kvm_main.c:2557
[< inline >] vfs_ioctl fs/ioctl.c:43
[<ffff200008450c38>] do_vfs_ioctl+0x128/0xfc0 fs/ioctl.c:679
[< inline >] SYSC_ioctl fs/ioctl.c:694
[<ffff200008451b78>] SyS_ioctl+0xa8/0xb8 fs/ioctl.c:685
[<ffff200008083ef0>] el0_svc_naked+0x24/0x28 arch/arm64/kernel/entry.S:755
^ permalink raw reply
* [PATCH] PCI: thunder-pem: Add support for cn81xx and cn83xx SoCs.
From: David Daney @ 2017-01-11 19:11 UTC (permalink / raw)
To: linux-arm-kernel
From: David Daney <david.daney@cavium.com>
The pci-thunder-pem driver was initially developed for cn88xx SoCs.
The cn81xx and cn83xx members of the same family of SoCs has a
slightly different configuration of interrupt resources in the PEM
hardware, which prevents the INTA legacy interrupt source from
functioning with the current driver.
There are two fixes required:
1) Don't fixup the PME interrupt on the newer SoCs as it already has
the proper value.
2) Report MSI-X Capability Table Size of 2 for the newer SoCs, so the
core MSI-X code doesn't inadvertently clobber the INTA machinery that
happens to reside immediately following the table.
Signed-off-by: David Daney <david.daney@cavium.com>
---
drivers/pci/host/pci-thunder-pem.c | 25 ++++++++++++++++++++-----
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
index af722eb..eea466f 100644
--- a/drivers/pci/host/pci-thunder-pem.c
+++ b/drivers/pci/host/pci-thunder-pem.c
@@ -36,7 +36,7 @@ struct thunder_pem_pci {
static int thunder_pem_bridge_read(struct pci_bus *bus, unsigned int devfn,
int where, int size, u32 *val)
{
- u64 read_val;
+ u64 read_val, tmp_val;
struct pci_config_window *cfg = bus->sysdata;
struct thunder_pem_pci *pem_pci = (struct thunder_pem_pci *)cfg->priv;
@@ -65,13 +65,28 @@ static int thunder_pem_bridge_read(struct pci_bus *bus, unsigned int devfn,
read_val |= 0x00007000; /* Skip MSI CAP */
break;
case 0x70: /* Express Cap */
- /* PME interrupt on vector 2*/
- read_val |= (2u << 25);
+ /*
+ * Change PME interrupt to vector 2 on T88 where it
+ * reads as 0, else leave it alone.
+ */
+ if (!(read_val & (0x1f << 25)))
+ read_val |= (2u << 25);
break;
case 0xb0: /* MSI-X Cap */
- /* TableSize=4, Next Cap is EA */
+ /* TableSize=2 or 4, Next Cap is EA */
read_val &= 0xc00000ff;
- read_val |= 0x0003bc00;
+ /*
+ * If Express Cap(0x70) raw PME vector reads as 2 we are on
+ * T88 and TableSize is reported as 4, else TableSize
+ * is 2.
+ */
+ writeq(0x70, pem_pci->pem_reg_base + PEM_CFG_RD);
+ tmp_val = readq(pem_pci->pem_reg_base + PEM_CFG_RD);
+ tmp_val >>= 32;
+ if (!(tmp_val & (0x1f << 25)))
+ read_val |= 0x0003bc00;
+ else
+ read_val |= 0x0001bc00;
break;
case 0xb4:
/* Table offset=0, BIR=0 */
--
2.9.3
^ permalink raw reply related
* [PATCH] PCI/MSI: pci-xgene-msi: Fix CPU hotplug registration handling
From: Duc Dang @ 2017-01-11 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484130407-24707-1-git-send-email-marc.zyngier@arm.com>
On Wed, Jan 11, 2017 at 2:26 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> The conversion to the new hotplug state machine introduced a regression
> where a successful hotplug registration would be treated as an error,
> effectively disabling the MSI driver forever.
>
> Fix it by doing the proper check on the return value.
Thanks, Marc.
Tested-by: Duc Dang <dhdang@apm.com>
>
> Fixes: 9c248f8896e6 ("PCI/xgene-msi: Convert to hotplug state machine")
> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Cc: Duc Dang <dhdang@apm.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: stable at vger.kernel.org
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> drivers/pci/host/pci-xgene-msi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pci-xgene-msi.c b/drivers/pci/host/pci-xgene-msi.c
> index 1f38d08..f1b633b 100644
> --- a/drivers/pci/host/pci-xgene-msi.c
> +++ b/drivers/pci/host/pci-xgene-msi.c
> @@ -517,7 +517,7 @@ static int xgene_msi_probe(struct platform_device *pdev)
>
> rc = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "pci/xgene:online",
> xgene_msi_hwirq_alloc, NULL);
> - if (rc)
> + if (rc < 0)
> goto err_cpuhp;
> pci_xgene_online = rc;
> rc = cpuhp_setup_state(CPUHP_PCI_XGENE_DEAD, "pci/xgene:dead", NULL,
> --
> 2.1.4
>
Regards,
Duc Dang.
^ permalink raw reply
* [PATCH] PCI: thunder-pem: Add support for cn81xx and cn83xx SoCs.
From: David Daney @ 2017-01-11 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111191141.28747-1-ddaney.cavm@gmail.com>
On 01/11/2017 11:11 AM, David Daney wrote:
> From: David Daney <david.daney@cavium.com>
>
> The pci-thunder-pem driver was initially developed for cn88xx SoCs.
> The cn81xx and cn83xx members of the same family of SoCs has a
> slightly different configuration of interrupt resources in the PEM
> hardware, which prevents the INTA legacy interrupt source from
> functioning with the current driver.
>
> There are two fixes required:
>
> 1) Don't fixup the PME interrupt on the newer SoCs as it already has
> the proper value.
>
> 2) Report MSI-X Capability Table Size of 2 for the newer SoCs, so the
> core MSI-X code doesn't inadvertently clobber the INTA machinery that
> happens to reside immediately following the table.
>
> Signed-off-by: David Daney <david.daney@cavium.com>
> ---
> drivers/pci/host/pci-thunder-pem.c | 25 ++++++++++++++++++++-----
> 1 file changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
> index af722eb..eea466f 100644
> --- a/drivers/pci/host/pci-thunder-pem.c
> +++ b/drivers/pci/host/pci-thunder-pem.c
> @@ -36,7 +36,7 @@ struct thunder_pem_pci {
> static int thunder_pem_bridge_read(struct pci_bus *bus, unsigned int devfn,
> int where, int size, u32 *val)
> {
> - u64 read_val;
> + u64 read_val, tmp_val;
> struct pci_config_window *cfg = bus->sysdata;
> struct thunder_pem_pci *pem_pci = (struct thunder_pem_pci *)cfg->priv;
>
> @@ -65,13 +65,28 @@ static int thunder_pem_bridge_read(struct pci_bus *bus, unsigned int devfn,
> read_val |= 0x00007000; /* Skip MSI CAP */
> break;
> case 0x70: /* Express Cap */
> - /* PME interrupt on vector 2*/
> - read_val |= (2u << 25);
> + /*
> + * Change PME interrupt to vector 2 on T88 where it
> + * reads as 0, else leave it alone.
> + */
> + if (!(read_val & (0x1f << 25)))
> + read_val |= (2u << 25);
> break;
> case 0xb0: /* MSI-X Cap */
> - /* TableSize=4, Next Cap is EA */
> + /* TableSize=2 or 4, Next Cap is EA */
> read_val &= 0xc00000ff;
> - read_val |= 0x0003bc00;
> + /*
> + * If Express Cap(0x70) raw PME vector reads as 2 we are on
Crap! The comment is incorrect s/2/0/, I guess I will send a corrected
patch. The code is correct though.
> + * T88 and TableSize is reported as 4, else TableSize
> + * is 2.
> + */
> + writeq(0x70, pem_pci->pem_reg_base + PEM_CFG_RD);
> + tmp_val = readq(pem_pci->pem_reg_base + PEM_CFG_RD);
> + tmp_val >>= 32;
> + if (!(tmp_val & (0x1f << 25)))
> + read_val |= 0x0003bc00;
> + else
> + read_val |= 0x0001bc00;
> break;
> case 0xb4:
> /* Table offset=0, BIR=0 */
>
^ permalink raw reply
* [PATCH v2] PCI: thunder-pem: Add support for cn81xx and cn83xx SoCs.
From: David Daney @ 2017-01-11 19:22 UTC (permalink / raw)
To: linux-arm-kernel
From: David Daney <david.daney@cavium.com>
The pci-thunder-pem driver was initially developed for cn88xx SoCs.
The cn81xx and cn83xx members of the same family of SoCs has a
slightly different configuration of interrupt resources in the PEM
hardware, which prevents the INTA legacy interrupt source from
functioning with the current driver.
There are two fixes required:
1) Don't fixup the PME interrupt on the newer SoCs as it already has
the proper value.
2) Report MSI-X Capability Table Size of 2 for the newer SoCs, so the
core MSI-X code doesn't inadvertently clobber the INTA machinery that
happens to reside immediately following the table.
Signed-off-by: David Daney <david.daney@cavium.com>
---
Changes from v1: Fixed comment typo.
drivers/pci/host/pci-thunder-pem.c | 25 ++++++++++++++++++++-----
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
index af722eb..52b5bdc 100644
--- a/drivers/pci/host/pci-thunder-pem.c
+++ b/drivers/pci/host/pci-thunder-pem.c
@@ -36,7 +36,7 @@ struct thunder_pem_pci {
static int thunder_pem_bridge_read(struct pci_bus *bus, unsigned int devfn,
int where, int size, u32 *val)
{
- u64 read_val;
+ u64 read_val, tmp_val;
struct pci_config_window *cfg = bus->sysdata;
struct thunder_pem_pci *pem_pci = (struct thunder_pem_pci *)cfg->priv;
@@ -65,13 +65,28 @@ static int thunder_pem_bridge_read(struct pci_bus *bus, unsigned int devfn,
read_val |= 0x00007000; /* Skip MSI CAP */
break;
case 0x70: /* Express Cap */
- /* PME interrupt on vector 2*/
- read_val |= (2u << 25);
+ /*
+ * Change PME interrupt to vector 2 on T88 where it
+ * reads as 0, else leave it alone.
+ */
+ if (!(read_val & (0x1f << 25)))
+ read_val |= (2u << 25);
break;
case 0xb0: /* MSI-X Cap */
- /* TableSize=4, Next Cap is EA */
+ /* TableSize=2 or 4, Next Cap is EA */
read_val &= 0xc00000ff;
- read_val |= 0x0003bc00;
+ /*
+ * If Express Cap(0x70) raw PME vector reads as 0 we are on
+ * T88 and TableSize is reported as 4, else TableSize
+ * is 2.
+ */
+ writeq(0x70, pem_pci->pem_reg_base + PEM_CFG_RD);
+ tmp_val = readq(pem_pci->pem_reg_base + PEM_CFG_RD);
+ tmp_val >>= 32;
+ if (!(tmp_val & (0x1f << 25)))
+ read_val |= 0x0003bc00;
+ else
+ read_val |= 0x0001bc00;
break;
case 0xb4:
/* Table offset=0, BIR=0 */
--
2.9.3
^ permalink raw reply related
* [PATCH 2/5] clk: sunxi-ng: add support for V3s CCU
From: Icenowy Zheng @ 2017-01-11 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110181006.yrd6moy2mctzoc4c@lukather>
11.01.2017, 02:10, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Tue, Jan 03, 2017 at 11:16:26PM +0800, Icenowy Zheng wrote:
>> ?V3s has a similar but cut-down CCU to H3.
>>
>> ?Add support for it.
>>
>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>
> It looks like there's nothing different but the clocks that you
> register with the H3, please just use the H3 driver.
Nope.
It has a different PLL (PLL_ISP) at different address, and some
different muxes.
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH 1/5] arm: sunxi: add support for V3s SoC
From: Icenowy Zheng @ 2017-01-11 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110180926.ilqtygttpfgbetvu@lukather>
11.01.2017, 02:09, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Tue, Jan 03, 2017 at 11:16:25PM +0800, Icenowy Zheng wrote:
>> ?Allwinner V3s is a low-end single-core Cortex-A7 SoC, with 64MB
>> ?integrated DRAM, and several peripherals.
>>
>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ?---
>> ??Documentation/arm/sunxi/README | 4 ++++
>> ??arch/arm/mach-sunxi/sunxi.c | 1 +
>> ??2 files changed, 5 insertions(+)
>>
>> ?diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
>> ?index cd0243302bc1..91ec8f2055be 100644
>> ?--- a/Documentation/arm/sunxi/README
>> ?+++ b/Documentation/arm/sunxi/README
>> ?@@ -67,6 +67,10 @@ SunXi family
>> ??????????+ Datasheet
>> ????????????http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
>>
>> ?+ - Allwinner V3s (sun8i)
>> ?+ + Datasheet
>> ?+ https://www.goprawn.com/forum/allwinner-cams/783-allwinner-v3s-soc-datasheet
>> ?+
>
> Please don't put random links in there, but at least something that we
> know will be there in a couple of weeks/monthes/years
Is http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf acceptable?
>
> Thanks,
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH 2/5] clk: sunxi-ng: add support for V3s CCU
From: Icenowy Zheng @ 2017-01-11 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2705031484163593@web1g.yandex.ru>
12.01.2017, 03:40, "Icenowy Zheng" <icenowy@aosc.xyz>:
> 11.01.2017, 02:10, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>> ?On Tue, Jan 03, 2017 at 11:16:26PM +0800, Icenowy Zheng wrote:
>>> ??V3s has a similar but cut-down CCU to H3.
>>>
>>> ??Add support for it.
>>>
>>> ??Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>>
>> ?It looks like there's nothing different but the clocks that you
>> ?register with the H3, please just use the H3 driver.
>
> Nope.
>
> It has a different PLL (PLL_ISP) at different address, and some
> different muxes.
Forgot to mention the missing of PLL_DE and related misses.
>
>> ?Thanks!
>> ?Maxime
>>
>> ?--
>> ?Maxime Ripard, Free Electrons
>> ?Embedded Linux and Kernel engineering
>> ?http://free-electrons.com
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* CONFIG_PCIEASPM breaks PCIe on Marvell Armada 385 machine
From: Uwe Kleine-König @ 2017-01-11 19:49 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
on an Marvell Armada 385 based machine (Turris Omnia) with 4.9 the
ath10k driver fails to bind to the matching hardware if CONFIG_PCIEASPM
is enabled:
# dmesg | grep ath
[ 7.207770] ath10k_pci 0000:02:00.0: Refused to change power state, currently in D3
[ 7.237955] ath10k_pci 0000:02:00.0: failed to wake up device : -110
[ 7.238146] ath10k_pci: probe of 0000:02:00.0 failed with error -110
if however PCIEASPM is off, the driver probes correctly and the ath10k
adapter works fine.
I wonder if someone has an idea what needs to be done to fix this
problem. (OK, I could disable PCIEASPM, but I'd like to have a solution
for a distribution kernel where I think PCIEASPM=y is sensible in
general.)
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170111/91e57d62/attachment.sig>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox