* [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller
From: Bartosz Golaszewski @ 2016-10-17 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <daf49046-ad0a-d9e2-d744-1e06085c6585@ti.com>
2016-10-17 14:29 GMT+02:00 Tomi Valkeinen <tomi.valkeinen@ti.com>:
> On 17/10/16 14:40, Laurent Pinchart wrote:
>> Hello,
>>
>> On Monday 17 Oct 2016 10:33:58 Tomi Valkeinen wrote:
>>> On 17/10/16 10:12, Sekhar Nori wrote:
>>>> On Monday 17 October 2016 11:26 AM, Tomi Valkeinen wrote:
>>>>> On 15/10/16 20:42, Sekhar Nori wrote:
>>>>>>> diff --git a/arch/arm/boot/dts/da850.dtsi
>>>>>>> b/arch/arm/boot/dts/da850.dtsi
>>>>>>> index f79e1b9..32908ae 100644
>>>>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>>>>> @@ -399,6 +420,14 @@
>>>>>>> <&edma0 0 1>;
>>>>>>> dma-names = "tx", "rx";
>>>>>>> };
>>>>>>> +
>>>>>>> + display: display at 213000 {
>>>>>>> + compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
>>>>>>
>>>>>> This should instead be:
>>>>>>
>>>>>> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
>>>>>>
>>>>>> as the closest match should appear first in the list.
>>>>>
>>>>> Actually I don't think that's correct. The LCDC on da850 is not
>>>>> compatible with the LCDC on AM335x. I think it should be just
>>>>> "ti,da850-tilcdc".
>>>>
>>>> So if "ti,am33xx-tilcdc" is used, the display wont work at all? If thats
>>>> the case, I wonder how the patch passed testing. Bartosz?
>>>
>>> AM3 has "version 2" of LCDC, whereas DA850 is v1. They are quite
>>> similar, but different.
>>>
>>> The driver gets the version number from LCDC's register, and acts based
>>> on that, so afaik the compatible string doesn't really affect the
>>> functionality (as long as it matches).
>>>
>>> But even if it works with the current driver, I don't think
>>> "ti,am33xx-tilcdc" and "ti,da850-tilcdc" are compatible in the HW level.
>>
>> If the hardware provides IP revision information, how about just "ti,lcdc" ?
>
> Maybe, and I agree that's the "correct" way, but looking at the history,
> it's not just once or twice when we've suddenly found out some
> difference or bug or such in an IP revision, or the integration to a
> SoC, that can't be found based on the IP revision.
>
> That's why I feel it's usually safer to have the SoC revision there in
> the compatible string.
>
> That said, we have only a few different old SoCs with LCDC (compared to,
> say, OMAP DSS) so in this case perhaps just "ti,lcdc" would be fine.
>
> Tomi
>
I Sekhar is ok with this, I'll send a follow-up patch for that.
Thanks,
Bartosz
^ permalink raw reply
* [PATCH] arm64: kernel: numa: fix ACPI boot cpu numa node mapping
From: Lorenzo Pieralisi @ 2016-10-17 14:18 UTC (permalink / raw)
To: linux-arm-kernel
Commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must
bind to node0") removed the numa cpu<->node mapping restriction whereby
logical cpu 0 always corresponds to numa node 0; removing the
restriction was correct, in that it does not really exist in practice
but the commit only updated the early mapping of logical cpu 0 to its
real numa node for the DT boot path, missing the ACPI one, leading to
boot failures on ACPI systems with numa enabled owing to missing
node<->cpu map for logical cpu 0.
Fix the issue by updating the ACPI boot path with code that carries out
the early cpu<->node mapping also for the boot cpu (ie cpu 0), mirroring
what is currently done in the DT boot path.
Fixes: 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reported-by: Laszlo Ersek <lersek@redhat.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Andrew Jones <drjones@redhat.com>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/kernel/smp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index d3f151c..8507703 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -544,6 +544,7 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
return;
}
bootcpu_valid = true;
+ early_map_cpu_to_node(0, acpi_numa_get_nid(0, hwid));
return;
}
--
2.10.0
^ permalink raw reply related
* [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
From: Sricharan @ 2016-10-17 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5cf1acbf9c42cc99e5cc0dacb50b7a92c3bd0feb.1476702234.git.robin.murphy@arm.com>
Hi,
>-----Original Message-----
>From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of Robin Murphy
>Sent: Monday, October 17, 2016 4:36 PM
>To: will.deacon at arm.com; joro at 8bytes.org
>Cc: iommu at lists.linux-foundation.org; Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>; linux-arm-kernel at lists.infradead.org
>Subject: [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
>
>We now delay installing our per-bus iommu_ops until we know an SMMU has
>successfully probed, as they don't serve much purpose beforehand, and
>doing so also avoids fights between multiple IOMMU drivers in a single
>kernel. However, the upshot of passing the return value of bus_set_iommu()
>back from our probe function is that if there happens to be more than
>one SMMUv3 device in a system, the second and subsequent probes will
>wind up returning -EBUSY to the driver core and getting torn down again.
>
>There are essentially 3 cases in which bus_set_iommu() returns nonzero:
>1. The bus already has iommu_ops installed
>2. One of the add_device callbacks from the initial notifier failed
>3. Allocating or installing the notifier itself failed
>
>The first two are down to devices other than the SMMU in question, so
>shouldn't abort an otherwise-successful SMMU probe, whilst the third is
>indicative of the kind of catastrophic system failure which isn't going
>to get much further anyway. Consequently, there is little harm in
>ignoring the return value either way.
>
>CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>---
> drivers/iommu/arm-smmu-v3.c | 11 ++++-------
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>index 15c01c3cd540..74fbef384deb 100644
>--- a/drivers/iommu/arm-smmu-v3.c
>+++ b/drivers/iommu/arm-smmu-v3.c
>@@ -2637,16 +2637,13 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> #ifdef CONFIG_PCI
> pci_request_acs();
>- ret = bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
>- if (ret)
>- return ret;
>+ bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
> #endif
> #ifdef CONFIG_ARM_AMBA
>- ret = bus_set_iommu(&amba_bustype, &arm_smmu_ops);
>- if (ret)
>- return ret;
>+ bus_set_iommu(&amba_bustype, &arm_smmu_ops);
> #endif
>- return bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
>+ bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
>+ return 0;
reviewed-by: sricharan at codeaurora.org
Regards,
Sricharan
^ permalink raw reply
* [PATCH v14 00/16] KVM PCIe/MSI passthrough on ARM/ARM64
From: Auger Eric @ 2016-10-17 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87mvi7qikn.fsf@e105922-lin.cambridge.arm.com>
Hi Punit,
On 14/10/2016 13:24, Punit Agrawal wrote:
> Hi Eric,
>
> I am a bit late in joining, but I've tried to familiarise
> myself with earlier discussions on the series.
>
> Eric Auger <eric.auger@redhat.com> writes:
>
>> This is the second respin on top of Robin's series [1], addressing Alex' comments.
>>
>> Major changes are:
>> - MSI-doorbell API now is moved to DMA IOMMU API following Alex suggestion
>> to put all API pieces at the same place (so eventually in the IOMMU
>> subsystem)
>
> IMHO, this is headed in the opposite direction, i.e., away from the
> owner of the information - the doorbells are the property of the MSI
> controller. The MSI controllers know the location, size and interrupt
> remapping capability as well. On the consumer side, VFIO needs access to
> the doorbells to allow userspace to carve out a region in the IOVA.
>
> I quite liked what you had in v13, though I think you can go further
> though. Instead of adding new doorbell API [un]registration calls, how
> about adding a callback to the irq_domain_ops? The callback will be
> populated for irqdomains registered by MSI controllers.
Thank you for jumping into that thread. Any help/feedback is greatly
appreciated.
Regarding your suggestion, the irq_domain looks dedicated to the
translation between linux irq and HW irq. I tend to think adding an ops
to retrieve the MSI doorbell info at that level looks far from the
original goal of the infrastructure. Obviously the fact there is a list
of such domain is tempting but I preferred to add a separate struct and
separate list.
In the v14 release I moved the "doorbell API" in the dma-iommu API since
Alex recommended to offer a unified API where all pieces would be at the
same place.
Anyway I will follow the guidance of maintainers.
>
> From VFIO, we can calculate the required aperture reservation by
> iterating over the irqdomains (something like irq_domain_for_each). The
> same callback can also provide information about support for interrupt
> remapping.
>
> For systems where there are no separate MSI controllers, i.e., the IOMMU
> has a fixed reservation, no MSI callbacks will be populated - which
> tells userspace that no separate MSI reservation is required. IIUC, this
> was one of Alex' concerns on the prior version.
I'am working on a separate series to report to the user-space the usable
IOVA range(s).
Thanks
Eric
>
> Thoughts, opinions?
>
> Punit
>
>> - new iommu_domain_msi_resv struct and accessor through DOMAIN_ATTR_MSI_RESV
>> domain with mirror VFIO capability
>> - more robustness I think in the VFIO layer
>> - added "iommu/iova: fix __alloc_and_insert_iova_range" since with the current
>> code I failed allocating an IOVA page in a single page domain with upper part
>> reserved
>>
>> IOVA range exclusion will be handled in a separate series
>>
>> The priority really is to discuss and freeze the API and especially the MSI
>> doorbell's handling. Do we agree to put that in DMA IOMMU?
>>
>> Note: the size computation does not take into account possible page overlaps
>> between doorbells but it would add quite a lot of complexity i think.
>>
>> Tested on AMD Overdrive (single GICv2m frame) with I350 VF assignment.
>>
>> dependency:
>> the series depends on Robin's generic-v7 branch:
>> [1] [PATCH v7 00/22] Generic DT bindings for PCI IOMMUs and ARM SMMU
>> http://www.spinics.net/lists/arm-kernel/msg531110.html
>>
>> Best Regards
>>
>> Eric
>>
>> Git: complete series available at
>> https://github.com/eauger/linux/tree/generic-v7-pcie-passthru-v14
>>
>> the above branch includes a temporary patch to work around a ThunderX pci
>> bus reset crash (which I think unrelated to this series):
>> "vfio: pci: HACK! workaround thunderx pci_try_reset_bus crash"
>> Do not take this one for other platforms.
>>
>>
>> Eric Auger (15):
>> iommu/iova: fix __alloc_and_insert_iova_range
>> iommu: Introduce DOMAIN_ATTR_MSI_RESV
>> iommu/dma: MSI doorbell alloc/free
>> iommu/dma: Introduce iommu_calc_msi_resv
>> iommu/arm-smmu: Implement domain_get_attr for DOMAIN_ATTR_MSI_RESV
>> irqchip/gic-v2m: Register the MSI doorbell
>> irqchip/gicv3-its: Register the MSI doorbell
>> vfio: Introduce a vfio_dma type field
>> vfio/type1: vfio_find_dma accepting a type argument
>> vfio/type1: Implement recursive vfio_find_dma_from_node
>> vfio/type1: Handle unmap/unpin and replay for VFIO_IOVA_RESERVED slots
>> vfio: Allow reserved msi iova registration
>> vfio/type1: Check doorbell safety
>> iommu/arm-smmu: Do not advertise IOMMU_CAP_INTR_REMAP
>> vfio/type1: Introduce MSI_RESV capability
>>
>> Robin Murphy (1):
>> iommu/dma: Allow MSI-only cookies
>>
>> drivers/iommu/Kconfig | 4 +-
>> drivers/iommu/arm-smmu-v3.c | 10 +-
>> drivers/iommu/arm-smmu.c | 10 +-
>> drivers/iommu/dma-iommu.c | 184 ++++++++++++++++++++++++++
>> drivers/iommu/iova.c | 2 +-
>> drivers/irqchip/irq-gic-v2m.c | 10 +-
>> drivers/irqchip/irq-gic-v3-its.c | 13 ++
>> drivers/vfio/vfio_iommu_type1.c | 279 +++++++++++++++++++++++++++++++++++++--
>> include/linux/dma-iommu.h | 59 +++++++++
>> include/linux/iommu.h | 8 ++
>> include/uapi/linux/vfio.h | 30 ++++-
>> 11 files changed, 587 insertions(+), 22 deletions(-)
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
From: Robin Murphy @ 2016-10-17 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017132146.GA26341@red-moon>
Hi Lorenzo,
On 17/10/16 14:21, Lorenzo Pieralisi wrote:
> On Mon, Oct 17, 2016 at 12:06:20PM +0100, Robin Murphy wrote:
>> We now delay installing our per-bus iommu_ops until we know an SMMU has
>> successfully probed, as they don't serve much purpose beforehand, and
>> doing so also avoids fights between multiple IOMMU drivers in a single
>> kernel. However, the upshot of passing the return value of bus_set_iommu()
>> back from our probe function is that if there happens to be more than
>> one SMMUv3 device in a system, the second and subsequent probes will
>> wind up returning -EBUSY to the driver core and getting torn down again.
>>
>> There are essentially 3 cases in which bus_set_iommu() returns nonzero:
>> 1. The bus already has iommu_ops installed
>> 2. One of the add_device callbacks from the initial notifier failed
>> 3. Allocating or installing the notifier itself failed
>>
>> The first two are down to devices other than the SMMU in question, so
>> shouldn't abort an otherwise-successful SMMU probe, whilst the third is
>> indicative of the kind of catastrophic system failure which isn't going
>> to get much further anyway. Consequently, there is little harm in
>> ignoring the return value either way.
>>
>> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/arm-smmu-v3.c | 11 ++++-------
>> 1 file changed, 4 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>> index 15c01c3cd540..74fbef384deb 100644
>> --- a/drivers/iommu/arm-smmu-v3.c
>> +++ b/drivers/iommu/arm-smmu-v3.c
>> @@ -2637,16 +2637,13 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
>> of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
>> #ifdef CONFIG_PCI
>> pci_request_acs();
>> - ret = bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
>> - if (ret)
>> - return ret;
>> + bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
>> #endif
>> #ifdef CONFIG_ARM_AMBA
>> - ret = bus_set_iommu(&amba_bustype, &arm_smmu_ops);
>> - if (ret)
>> - return ret;
>> + bus_set_iommu(&amba_bustype, &arm_smmu_ops);
>> #endif
>> - return bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
>> + bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
>> + return 0;
>
> Nit: I do not see why you would not take the same approach as
> the ARM SMMUv1/v2, namely checking if ops are already set and
> skip the call if that's the case.
Well, I'd say it really goes the other way around - since the very first
thing bus_set_iommu() does is check if ops are present, and return if
so, and the v2 driver already doesn't care about that return value,
there's not really any need for it to duplicate the check either. I
didn't change it at the time to avoid cluttering the gigantic rework any
further, but I could spin a cleanup patch if you like.
> Anyway:
>
> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Thanks!
Robin.
^ permalink raw reply
* [PATCH v14 04/16] iommu/dma: MSI doorbell alloc/free
From: Auger Eric @ 2016-10-17 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87lgxrqijs.fsf@e105922-lin.cambridge.arm.com>
Hi Punit,
On 14/10/2016 13:25, Punit Agrawal wrote:
> Hi Eric,
>
> One query and a comment below.
>
> Eric Auger <eric.auger@redhat.com> writes:
>
>> We introduce the capability to (un)register MSI doorbells.
>>
>> A doorbell region is characterized by its physical address base, size,
>> and whether it its safe (ie. it implements IRQ remapping). A doorbell
>> can be per-cpu or global. We currently only care about global doorbells.
>>
>> A function returns whether all registered doorbells are safe.
>>
>> MSI controllers likely to work along with IOMMU that translate MSI
>> transaction must register their doorbells to allow device assignment
>> with MSI support. Otherwise the MSI transactions will cause IOMMU faults.
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>>
>> v13 -> v14:
>> - previously in msi-doorbell.h/c
>> ---
>> drivers/iommu/dma-iommu.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++
>> include/linux/dma-iommu.h | 41 ++++++++++++++++++++++++++
>> 2 files changed, 116 insertions(+)
>>
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index d45f9a0..d8a7d86 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -43,6 +43,38 @@ struct iommu_dma_cookie {
>> spinlock_t msi_lock;
>> };
>>
>> +/**
>> + * struct iommu_msi_doorbell_info - MSI doorbell region descriptor
>> + * @percpu_doorbells: per cpu doorbell base address
>> + * @global_doorbell: base address of the doorbell
>> + * @doorbell_is_percpu: is the doorbell per cpu or global?
>> + * @safe: true if irq remapping is implemented
>> + * @size: size of the doorbell
>> + */
>> +struct iommu_msi_doorbell_info {
>> + union {
>> + phys_addr_t __percpu *percpu_doorbells;
>
> Out of curiosity, have you come across systems that have per-cpu
> doorbells? I couldn't find a system that'd help solidify my
> understanding on it's usage.
This came out after a discussion With Marc. However at the moment I am
not aware of any MSI controller featuring per-cpu doorbell. Not sure
whether it stays relevant to keep this notion at that stage.
>
>> + phys_addr_t global_doorbell;
>> + };
>> + bool doorbell_is_percpu;
>> + bool safe;
>
> Although you've got the comment above, 'safe' doesn't quite convey it's
> purpose. Can this be renamed to something more descriptive -
> 'intr_remapping' or 'intr_isolation' perhaps?
Yes definitively
Thanks
Eric
>
> Thanks,
> Punit
>
>
> [...]
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH] arm64: kernel: numa: fix ACPI boot cpu numa node mapping
From: Laszlo Ersek @ 2016-10-17 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017141848.5274-1-lorenzo.pieralisi@arm.com>
On 10/17/16 16:18, Lorenzo Pieralisi wrote:
> Commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must
> bind to node0") removed the numa cpu<->node mapping restriction whereby
> logical cpu 0 always corresponds to numa node 0; removing the
> restriction was correct, in that it does not really exist in practice
> but the commit only updated the early mapping of logical cpu 0 to its
> real numa node for the DT boot path, missing the ACPI one, leading to
> boot failures on ACPI systems with numa enabled owing to missing
> node<->cpu map for logical cpu 0.
Small correction request: please drop the "with numa enabled"
qualification. The bug breaks ACPI boot on numa-disabled systems as well
(i.e., where there's only one node, and there are no NUMA-related ACPI
tables (like SRAT) and objects (like _PXM in the DSDT)).
Many thanks!
Laszlo
>
> Fix the issue by updating the ACPI boot path with code that carries out
> the early cpu<->node mapping also for the boot cpu (ie cpu 0), mirroring
> what is currently done in the DT boot path.
>
> Fixes: 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Tested-by: Laszlo Ersek <lersek@redhat.com>
> Reported-by: Laszlo Ersek <lersek@redhat.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Andrew Jones <drjones@redhat.com>
> Cc: Zhen Lei <thunder.leizhen@huawei.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> ---
> arch/arm64/kernel/smp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index d3f151c..8507703 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -544,6 +544,7 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
> return;
> }
> bootcpu_valid = true;
> + early_map_cpu_to_node(0, acpi_numa_get_nid(0, hwid));
> return;
> }
>
>
^ permalink raw reply
* [PATCH v3 08/11] ARM: dts: r8a7743: add IRQC support
From: Geert Uytterhoeven @ 2016-10-17 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1550113.UvRQMtlFiI@wasted.cogentembedded.com>
On Wed, Oct 5, 2016 at 11:43 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Describe the IRQC interrupt controller in the R8A7743 device tree.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v3 07/11] ARM: dts: r8a7743: add Ether support
From: Geert Uytterhoeven @ 2016-10-17 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1823688.my1YjA2iHn@wasted.cogentembedded.com>
On Wed, Oct 5, 2016 at 11:42 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Define the generic R8A7743 part of the Ether device node.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] arm64: kaslr: fix breakage with CONFIG_MODVERSIONS=y
From: Will Deacon @ 2016-10-17 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9X3-mMk7_2R=LZ6V38f-dPYrcZkROrkQBde5H-kFcYbw@mail.gmail.com>
On Fri, Oct 14, 2016 at 08:53:02PM +0100, Ard Biesheuvel wrote:
> On 14 October 2016 at 19:26, Will Deacon <will.deacon@arm.com> wrote:
> > On Fri, Oct 14, 2016 at 07:23:15PM +0100, Ard Biesheuvel wrote:
> >> On 13 October 2016 at 20:59, Timur Tabi <timur@codeaurora.org> wrote:
> >> > Ard Biesheuvel wrote:
> >> >>
> >> >> As it turns out, the KASLR code breaks CONFIG_MODVERSIONS, since the
> >> >> kcrctab has an absolute address field that is relocated at runtime
> >> >> when the kernel offset is randomized.
> >> >>
> >> >> This has been fixed already for PowerPC in the past, so simply wire up
> >> >> the existing code dealing with this issue.
> >> >>
> >> >> Signed-off-by: Ard Biesheuvel<ard.biesheuvel@linaro.org>
> >> >
> >> >
> >> > Tested-by: Timur Tabi <timur@codeaurora.org>
> >> >
> >>
> >> Thanks. I will resend this with a fixes: tag and a better description
> >
> > Feel free, but I already queued it locally and added the Fixes tag myself.
> > I'm just waiting for Lorenzo to post a fix to the ACPI NUMA stuff, then
> > I'll send these two up together next week.
>
> It's no big deal. The description is not entirely accurate in the
> sense that the kcrctab does not contain an absolute address field, but
> it masquerades as an absolute address so that the build system can
> populate the kcrctab entries using a linker script include containing
> name=value pairs. This does not only result in 4 wasted bytes per CRC,
> but on PPC64 and arm64 with CONFIG_RELOCATABLE=y, it also results in
> the breakage this patch addresses, and more importantly, results in a
> 24 byte RELA entry per CRC in the __init section. So I intend to
> propose a patch to change this in the generic code, after which this
> patch could be reverted.
>
> BTW, I spotted another KASLR issue, with ftrace this time, where it
> attempts to poke relative branches into modules targeting the core
> kernel, which is likely to fail when
> CONFIG_RANDOMIZE_MODULE_REGION_FULL=y. Should we address this at the
> Kconfig level? Or should we try to fix ftrace to support long
> branches?
I guess we could fix it at the kconfig level in the short term, then it
makes it clear that some ftrace work needs doing to fix it properly.
Will
^ permalink raw reply
* Regression: usb serial gadget on sama5d3 broken
From: Nicolas Ferre @ 2016-10-17 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <569c65cd-4e2e-4455-c24c-074f8c5fd315@axentia.se>
Le 17/10/2016 ? 14:53, Peter Rosin a ?crit :
> Hi!
>
> I'm suffering from a regression while using the usb gadget port on the
> sama5d3 to get terminal access to the device in question (CONFIG_USB_G_SERIAL).
>
> I get this message when I try to connect:
> udc: ep: Invalid setup request: 02.01 v0000 i0081 l0, halting endpoint...
>
> A bisect blames commit v4.7-rc1-21-gc32b5bcfa3c4 "ARM: dts: at91: Fix
> USB endpoint nodes".
>
> And indeed, reverting that commit on top of v4.9-rc1 fixes things,
> although that doesn't look like the best of fixes...
>
> BTW, the bisect was extremely painful since v4.7-rc1 seemed broken
> somewhere in the overlayfs area. I hope I will never ever need to bisect
> in the v4.6..v4.7 area again. This was the second time, the first time
> I was chasing a gpio interrupt bug, but I never found out what was wrong
> and stopped looking when v4.9-rc1 turned out to be ok even though v4.8
> was bad, it was just too painful to look for things that already seemed
> fixed.
I guess that you are referring to the regression listed here:
https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1239220.html
The patch is available and will hopefully land in an official kernel
soon (4.8.1) as said by Felipe and Greg.
Sorry for the inconvenience. Best regards,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH -next] PCI: layerscape: Remove redundant dev_err call in ls_pcie_probe()
From: Wei Yongjun @ 2016-10-17 14:55 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/pci/host/pci-layerscape.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/host/pci-layerscape.c b/drivers/pci/host/pci-layerscape.c
index 2cb7315..bbd3d23 100644
--- a/drivers/pci/host/pci-layerscape.c
+++ b/drivers/pci/host/pci-layerscape.c
@@ -251,10 +251,8 @@ static int __init ls_pcie_probe(struct platform_device *pdev)
dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
pcie->pp.dbi_base = devm_ioremap_resource(dev, dbi_base);
- if (IS_ERR(pcie->pp.dbi_base)) {
- dev_err(dev, "missing *regs* space\n");
+ if (IS_ERR(pcie->pp.dbi_base))
return PTR_ERR(pcie->pp.dbi_base);
- }
pcie->drvdata = match->data;
pcie->lut = pcie->pp.dbi_base + pcie->drvdata->lut_offset;
^ permalink raw reply related
* [PATCH v2] arm64: kernel: numa: fix ACPI boot cpu numa node mapping
From: Lorenzo Pieralisi @ 2016-10-17 14:56 UTC (permalink / raw)
To: linux-arm-kernel
Commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must
bind to node0") removed the numa cpu<->node mapping restriction whereby
logical cpu 0 always corresponds to numa node 0; removing the
restriction was correct, in that it does not really exist in practice
but the commit only updated the early mapping of logical cpu 0 to its
real numa node for the DT boot path, missing the ACPI one, leading to
boot failures on ACPI systems owing to missing cpu<->node map for
logical cpu 0.
Fix the issue by updating the ACPI boot path with code that carries out
the early cpu<->node mapping also for the boot cpu (ie cpu 0), mirroring
what is currently done in the DT boot path.
Fixes: 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reported-by: Laszlo Ersek <lersek@redhat.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Andrew Jones <drjones@redhat.com>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
v1 -> v2
- Updated commit log to reflect boot failures set-ups
arch/arm64/kernel/smp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index d3f151c..8507703 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -544,6 +544,7 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
return;
}
bootcpu_valid = true;
+ early_map_cpu_to_node(0, acpi_numa_get_nid(0, hwid));
return;
}
--
2.10.0
^ permalink raw reply related
* [PATCH -next] PCI: rockchip: Add missing of_node_put() in rockchip_pcie_init_irq_domain()
From: Wei Yongjun @ 2016-10-17 14:57 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
This node pointer is returned by of_get_next_child() with refcount
incremented in this function. of_node_put() on it before exitting
this function on error.
This is detected by Coccinelle semantic patch.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/pci/host/pcie-rockchip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index e0b22da..ab88859 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -949,6 +949,7 @@ static int rockchip_pcie_init_irq_domain(struct rockchip_pcie *rockchip)
&intx_domain_ops, rockchip);
if (!rockchip->irq_domain) {
dev_err(dev, "failed to get a INTx IRQ domain\n");
+ of_node_put(intc);
return -EINVAL;
}
^ permalink raw reply related
* [PATCH -next] PCI: xilinx-nwl: Add missing of_node_put() in nwl_pcie_init_irq_domain()
From: Wei Yongjun @ 2016-10-17 14:58 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
This node pointer is returned by of_get_next_child() with refcount
incremented in this function. of_node_put() on it before exitting
this function on error.
This is detected by Coccinelle semantic patch.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/pci/host/pcie-xilinx-nwl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/host/pcie-xilinx-nwl.c b/drivers/pci/host/pcie-xilinx-nwl.c
index 43eaa4a..c16b26c 100644
--- a/drivers/pci/host/pcie-xilinx-nwl.c
+++ b/drivers/pci/host/pcie-xilinx-nwl.c
@@ -535,6 +535,7 @@ static int nwl_pcie_init_irq_domain(struct nwl_pcie *pcie)
if (!pcie->legacy_irq_domain) {
dev_err(dev, "failed to create IRQ domain\n");
+ of_node_put(legacy_intc_node);
return -ENOMEM;
}
^ permalink raw reply related
* [PATCH -next] PCI: xilinx: Add missing of_node_put() in xilinx_pcie_init_irq_domain()
From: Wei Yongjun @ 2016-10-17 14:59 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
This node pointer is returned by of_get_next_child() with refcount
incremented in this function. of_node_put() on it before exitting
this function on error.
This is detected by Coccinelle semantic patch.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/pci/host/pcie-xilinx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index c8616fa..7100ee5 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -529,6 +529,7 @@ static int xilinx_pcie_init_irq_domain(struct xilinx_pcie_port *port)
port);
if (!port->leg_domain) {
dev_err(dev, "Failed to get a INTx IRQ domain\n");
+ of_node_put(pcie_intc_node);
return -ENODEV;
}
@@ -540,6 +541,7 @@ static int xilinx_pcie_init_irq_domain(struct xilinx_pcie_port *port)
&xilinx_pcie_msi_chip);
if (!port->msi_domain) {
dev_err(dev, "Failed to get a MSI IRQ domain\n");
+ of_node_put(pcie_intc_node);
return -ENODEV;
}
^ permalink raw reply related
* [PATCH] irqchip: gic-v3-its: fix entry size mask for GITS_BASER
From: Vladimir Murzin @ 2016-10-17 15:00 UTC (permalink / raw)
To: linux-arm-kernel
Entry Size in GITS_BASER<n> occupies 5 bits [52:48], but we mask out 8
bits.
Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue")
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
include/linux/irqchip/arm-gic-v3.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
index 7dec96f..5118d3a 100644
--- a/include/linux/irqchip/arm-gic-v3.h
+++ b/include/linux/irqchip/arm-gic-v3.h
@@ -290,7 +290,7 @@
#define GITS_BASER_TYPE_SHIFT (56)
#define GITS_BASER_TYPE(r) (((r) >> GITS_BASER_TYPE_SHIFT) & 7)
#define GITS_BASER_ENTRY_SIZE_SHIFT (48)
-#define GITS_BASER_ENTRY_SIZE(r) ((((r) >> GITS_BASER_ENTRY_SIZE_SHIFT) & 0xff) + 1)
+#define GITS_BASER_ENTRY_SIZE(r) ((((r) >> GITS_BASER_ENTRY_SIZE_SHIFT) & 0x1f) + 1)
#define GITS_BASER_SHAREABILITY_SHIFT (10)
#define GITS_BASER_InnerShareable \
GIC_BASER_SHAREABILITY(GITS_BASER, InnerShareable)
--
1.7.9.5
^ permalink raw reply related
* [PATCH] irqchip: gic-v3-its: fix entry size mask for GITS_BASER
From: Marc Zyngier @ 2016-10-17 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476716446-28646-1-git-send-email-vladimir.murzin@arm.com>
On 17/10/16 16:00, Vladimir Murzin wrote:
> Entry Size in GITS_BASER<n> occupies 5 bits [52:48], but we mask out 8
> bits.
>
> Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue")
>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> ---
> include/linux/irqchip/arm-gic-v3.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
> index 7dec96f..5118d3a 100644
> --- a/include/linux/irqchip/arm-gic-v3.h
> +++ b/include/linux/irqchip/arm-gic-v3.h
> @@ -290,7 +290,7 @@
> #define GITS_BASER_TYPE_SHIFT (56)
> #define GITS_BASER_TYPE(r) (((r) >> GITS_BASER_TYPE_SHIFT) & 7)
> #define GITS_BASER_ENTRY_SIZE_SHIFT (48)
> -#define GITS_BASER_ENTRY_SIZE(r) ((((r) >> GITS_BASER_ENTRY_SIZE_SHIFT) & 0xff) + 1)
> +#define GITS_BASER_ENTRY_SIZE(r) ((((r) >> GITS_BASER_ENTRY_SIZE_SHIFT) & 0x1f) + 1)
> #define GITS_BASER_SHAREABILITY_SHIFT (10)
> #define GITS_BASER_InnerShareable \
> GIC_BASER_SHAREABILITY(GITS_BASER, InnerShareable)
>
Nice catch. I'll queue that in my fix branch (and add a Cc to stable,
since this is a 2 year old bug...).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v14 00/16] KVM PCIe/MSI passthrough on ARM/ARM64
From: Punit Agrawal @ 2016-10-17 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2f919654-f16d-513e-8535-3230db0ad861@redhat.com>
Auger Eric <eric.auger@redhat.com> writes:
> Hi Punit,
>
> On 14/10/2016 13:24, Punit Agrawal wrote:
>> Hi Eric,
>>
>> I am a bit late in joining, but I've tried to familiarise
>> myself with earlier discussions on the series.
>>
>> Eric Auger <eric.auger@redhat.com> writes:
>>
>>> This is the second respin on top of Robin's series [1], addressing Alex' comments.
>>>
>>> Major changes are:
>>> - MSI-doorbell API now is moved to DMA IOMMU API following Alex suggestion
>>> to put all API pieces at the same place (so eventually in the IOMMU
>>> subsystem)
>>
>> IMHO, this is headed in the opposite direction, i.e., away from the
>> owner of the information - the doorbells are the property of the MSI
>> controller. The MSI controllers know the location, size and interrupt
>> remapping capability as well. On the consumer side, VFIO needs access to
>> the doorbells to allow userspace to carve out a region in the IOVA.
>>
>> I quite liked what you had in v13, though I think you can go further
>> though. Instead of adding new doorbell API [un]registration calls, how
>> about adding a callback to the irq_domain_ops? The callback will be
>> populated for irqdomains registered by MSI controllers.
>
> Thank you for jumping into that thread. Any help/feedback is greatly
> appreciated.
>
> Regarding your suggestion, the irq_domain looks dedicated to the
> translation between linux irq and HW irq. I tend to think adding an ops
> to retrieve the MSI doorbell info at that level looks far from the
> original goal of the infrastructure. Obviously the fact there is a list
> of such domain is tempting but I preferred to add a separate struct and
> separate list.
Guilty as charged - the suggestion was definitely borne out of
convenience. I originally looked at adding this functionality to the MSI
domains but couldn't find an obvious way to enumerate all of them.
Also, the way the domain hierarchy is setup for MSI controllers, the
actual doorbell is not available to the MSI domains.
>
> In the v14 release I moved the "doorbell API" in the dma-iommu API since
> Alex recommended to offer a unified API where all pieces would be at the
> same place.
>
> Anyway I will follow the guidance of maintainers.
Ok, makes sense.
>
>
>>
>> From VFIO, we can calculate the required aperture reservation by
>> iterating over the irqdomains (something like irq_domain_for_each). The
>> same callback can also provide information about support for interrupt
>> remapping.
>>
>> For systems where there are no separate MSI controllers, i.e., the IOMMU
>> has a fixed reservation, no MSI callbacks will be populated - which
>> tells userspace that no separate MSI reservation is required. IIUC, this
>> was one of Alex' concerns on the prior version.
>
> I'am working on a separate series to report to the user-space the usable
> IOVA range(s).
Is that the alternative to reporting the aperture size that needs to be
reserved?
>
> Thanks
>
> Eric
>>
>> Thoughts, opinions?
>>
>> Punit
>>
>>> - new iommu_domain_msi_resv struct and accessor through DOMAIN_ATTR_MSI_RESV
>>> domain with mirror VFIO capability
>>> - more robustness I think in the VFIO layer
>>> - added "iommu/iova: fix __alloc_and_insert_iova_range" since with the current
>>> code I failed allocating an IOVA page in a single page domain with upper part
>>> reserved
>>>
>>> IOVA range exclusion will be handled in a separate series
>>>
>>> The priority really is to discuss and freeze the API and especially the MSI
>>> doorbell's handling. Do we agree to put that in DMA IOMMU?
>>>
>>> Note: the size computation does not take into account possible page overlaps
>>> between doorbells but it would add quite a lot of complexity i think.
>>>
>>> Tested on AMD Overdrive (single GICv2m frame) with I350 VF assignment.
>>>
>>> dependency:
>>> the series depends on Robin's generic-v7 branch:
>>> [1] [PATCH v7 00/22] Generic DT bindings for PCI IOMMUs and ARM SMMU
>>> http://www.spinics.net/lists/arm-kernel/msg531110.html
>>>
>>> Best Regards
>>>
>>> Eric
>>>
>>> Git: complete series available at
>>> https://github.com/eauger/linux/tree/generic-v7-pcie-passthru-v14
>>>
>>> the above branch includes a temporary patch to work around a ThunderX pci
>>> bus reset crash (which I think unrelated to this series):
>>> "vfio: pci: HACK! workaround thunderx pci_try_reset_bus crash"
>>> Do not take this one for other platforms.
>>>
>>>
>>> Eric Auger (15):
>>> iommu/iova: fix __alloc_and_insert_iova_range
>>> iommu: Introduce DOMAIN_ATTR_MSI_RESV
>>> iommu/dma: MSI doorbell alloc/free
>>> iommu/dma: Introduce iommu_calc_msi_resv
>>> iommu/arm-smmu: Implement domain_get_attr for DOMAIN_ATTR_MSI_RESV
>>> irqchip/gic-v2m: Register the MSI doorbell
>>> irqchip/gicv3-its: Register the MSI doorbell
>>> vfio: Introduce a vfio_dma type field
>>> vfio/type1: vfio_find_dma accepting a type argument
>>> vfio/type1: Implement recursive vfio_find_dma_from_node
>>> vfio/type1: Handle unmap/unpin and replay for VFIO_IOVA_RESERVED slots
>>> vfio: Allow reserved msi iova registration
>>> vfio/type1: Check doorbell safety
>>> iommu/arm-smmu: Do not advertise IOMMU_CAP_INTR_REMAP
>>> vfio/type1: Introduce MSI_RESV capability
>>>
>>> Robin Murphy (1):
>>> iommu/dma: Allow MSI-only cookies
>>>
>>> drivers/iommu/Kconfig | 4 +-
>>> drivers/iommu/arm-smmu-v3.c | 10 +-
>>> drivers/iommu/arm-smmu.c | 10 +-
>>> drivers/iommu/dma-iommu.c | 184 ++++++++++++++++++++++++++
>>> drivers/iommu/iova.c | 2 +-
>>> drivers/irqchip/irq-gic-v2m.c | 10 +-
>>> drivers/irqchip/irq-gic-v3-its.c | 13 ++
>>> drivers/vfio/vfio_iommu_type1.c | 279 +++++++++++++++++++++++++++++++++++++--
>>> include/linux/dma-iommu.h | 59 +++++++++
>>> include/linux/iommu.h | 8 ++
>>> include/uapi/linux/vfio.h | 30 ++++-
>>> 11 files changed, 587 insertions(+), 22 deletions(-)
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
> _______________________________________________
> iommu mailing list
> iommu at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* [PATCH] irqchip: gic-v3-its: fix entry size mask for GITS_BASER
From: Fabio Estevam @ 2016-10-17 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476716446-28646-1-git-send-email-vladimir.murzin@arm.com>
On Mon, Oct 17, 2016 at 1:00 PM, Vladimir Murzin
<vladimir.murzin@arm.com> wrote:
> Entry Size in GITS_BASER<n> occupies 5 bits [52:48], but we mask out 8
> bits.
>
> Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue")
Looks like it needs the following tag then:
Cc: <stable@vger.kernel.org> # 3.19+
^ permalink raw reply
* [PATCH -next] ASoC: rk3399_gru_sound: Fix non static symbol warning
From: Wei Yongjun @ 2016-10-17 15:15 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
Fixes the following sparse warning:
sound/soc/rockchip/rk3399_gru_sound.c:41:14: warning:
symbol 'rt5514_dmic_delay' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
sound/soc/rockchip/rk3399_gru_sound.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c b/sound/soc/rockchip/rk3399_gru_sound.c
index 9ed735a..0cbd235 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -38,7 +38,7 @@
#define SOUND_FS 256
-unsigned int rt5514_dmic_delay;
+static unsigned int rt5514_dmic_delay;
static struct snd_soc_jack rockchip_sound_jack;
^ permalink raw reply related
* [PATCH] arm64: kaslr: keep modules close to the kernel when DYNAMIC_FTRACE=y
From: Ard Biesheuvel @ 2016-10-17 15:18 UTC (permalink / raw)
To: linux-arm-kernel
The RANDOMIZE_MODULE_REGION_FULL Kconfig option allows KASLR to be
configured in such a way that kernel modules and the core kernel are
allocated completely independently, which implies that modules are likely
to require branches via PLT entries to reach the core kernel. The dynamic
ftrace code does not expect that, and assumes that it can patch module
code to perform a relative branch to anywhere in the core kernel. This
may result in errors such as
branch_imm_common: offset out of range
------------[ cut here ]------------
WARNING: CPU: 3 PID: 196 at kernel/trace/ftrace.c:1995 ftrace_bug+0x220/0x2e8
Modules linked in:
CPU: 3 PID: 196 Comm: systemd-udevd Not tainted 4.8.0-22-generic #24
Hardware name: AMD Seattle/Seattle, BIOS 10:34:40 Oct 6 2016
task: ffff8d1bef7dde80 task.stack: ffff8d1bef6b0000
PC is at ftrace_bug+0x220/0x2e8
LR is at ftrace_process_locs+0x330/0x430
So make RANDOMIZE_MODULE_REGION_FULL mutually exclusive with DYNAMIC_FTRACE
at the Kconfig level.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 30398dbc940a..969ef880d234 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -915,7 +915,7 @@ config RANDOMIZE_BASE
config RANDOMIZE_MODULE_REGION_FULL
bool "Randomize the module region independently from the core kernel"
- depends on RANDOMIZE_BASE
+ depends on RANDOMIZE_BASE && !DYNAMIC_FTRACE
default y
help
Randomizes the location of the module region without considering the
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: imx: gpc: Initialize all power domains
From: Lucas Stach @ 2016-10-17 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476208413-11286-1-git-send-email-fabio.estevam@nxp.com>
Am Dienstag, den 11.10.2016, 14:53 -0300 schrieb Fabio Estevam:
> When booting a kernel built with multi_v7_defconfig the following
> probe error is seen:
>
> imx-gpc: probe of 20dc000.gpc failed with error -22
>
> Later on the kernel crashes like this:
>
> [ 1.723358] Unable to handle kernel NULL pointer dereference at virtual address 00000040
> [ 1.731500] pgd = c0204000
> [ 1.731863] hctosys: unable to open rtc device (rtc0)
> [ 1.739301] [00000040] *pgd=00000000
> [ 1.739310] Internal error: Oops: 5 [#1] SMP ARM
> [ 1.739319] Modules linked in:
> [ 1.739328] CPU: 1 PID: 95 Comm: kworker/1:4 Not tainted 4.8.0-11897-g6b5e09a #1
> [ 1.739331] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [ 1.739352] Workqueue: pm genpd_power_off_work_fn
> [ 1.739356] task: ee63d400 task.stack: ee70a000
> [ 1.739365] PC is at mutex_lock+0xc/0x4c
> [ 1.739374] LR is at regulator_disable+0x2c/0x60
> [ 1.739379] pc : [<c0bc0da0>] lr : [<c06e4b10>] psr: 60000013
> [ 1.739379] sp : ee70beb0 ip : 10624dd3 fp : ee6e6280
> [ 1.739382] r10: eefb0900 r9 : 00000000 r8 : c1309918
> [ 1.739385] r7 : 00000000 r6 : 00000040 r5 : 00000000 r4 : 00000040
> [ 1.739390] r3 : 0000004c r2 : 7fffd540 r1 : 000001e4 r0 : 00000040
>
> The gpc probe fails because of_genpd_add_provider_onecell() checks
> if all the domains are initialized via pm_genpd_present() function
> and it returns an error on the multi_v7_defconfig case.
>
> In order to fix this error, initialize all the imx_gpc_domains, not
> only the imx6q_pu_domain.base one.
>
> Reported-by: Olof's autobooter <build@lixom.net>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> arch/arm/mach-imx/gpc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
> index 0df062d..d0463e9 100644
> --- a/arch/arm/mach-imx/gpc.c
> +++ b/arch/arm/mach-imx/gpc.c
> @@ -430,7 +430,8 @@ static int imx_gpc_genpd_init(struct device *dev, struct regulator *pu_reg)
> if (!IS_ENABLED(CONFIG_PM_GENERIC_DOMAINS))
> return 0;
>
> - pm_genpd_init(&imx6q_pu_domain.base, NULL, false);
> + for (i = 0; i < ARRAY_SIZE(imx_gpc_domains); i++)
> + pm_genpd_init(imx_gpc_domains[i], NULL, false);
> return of_genpd_add_provider_onecell(dev->of_node,
> &imx_gpc_onecell_data);
>
^ permalink raw reply
* [PATCH] Documentation: DMA-API: Clarify semantics of dma_set_mask_and_coherent
From: Punit Agrawal @ 2016-10-17 15:26 UTC (permalink / raw)
To: linux-arm-kernel
The dma mapping api howto gives the impression that using the
dma_set_mask_and_coherent (and related DMA APIs) will cause the kernel
to check all the components in the path from the device to memory for
addressing restrictions. In systems with address translations between
the device and memory (e.g., when using IOMMU), this implies that a
successful call to set set dma mask has checked the addressing
constraints of the intermediaries as well.
For the IOMMU drivers in the tree, the check is actually performed while
allocating the DMA buffer rather than when the DMA mask is
configured. For MMUs that do not support the full device addressing
capability, the allocations are made from a reduced address space.
Update the documentation to clarify that even though the call to
dma_set_mask_and_coherent succeeds, it may not be possible to use the
full addressing capability of the device.
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Jonathan Corbet <corbet@lwn.net>
---
Documentation/DMA-API-HOWTO.txt | 39 +++++++++++++++++++++++----------------
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index 979228b..240d1ee 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -159,39 +159,46 @@ support 64-bit addressing (DAC) for all transactions. And at least
one platform (SGI SN2) requires 64-bit consistent allocations to
operate correctly when the IO bus is in PCI-X mode.
-For correct operation, you must interrogate the kernel in your device
-probe routine to see if the DMA controller on the machine can properly
-support the DMA addressing limitation your device has. It is good
+For correct operation, you must inform the kernel in your device probe
+routine to see if the DMA controller on the machine can properly
+support the DMA addressing capabilities your device has. It is good
style to do this even if your device holds the default setting,
because this shows that you did think about these issues wrt. your
device.
-The query is performed via a call to dma_set_mask_and_coherent():
+The call to inform the kernel is performed via a call to
+dma_set_mask_and_coherent():
int dma_set_mask_and_coherent(struct device *dev, u64 mask);
-which will query the mask for both streaming and coherent APIs together.
-If you have some special requirements, then the following two separate
-queries can be used instead:
+which will set the mask for both streaming and coherent APIs together.
+If there are some special requirements, then the following two
+separate functions can be used instead:
- The query for streaming mappings is performed via a call to
- dma_set_mask():
+ The configuration for streaming mappings is performed via a
+ call to dma_set_mask():
int dma_set_mask(struct device *dev, u64 mask);
- The query for consistent allocations is performed via a call
- to dma_set_coherent_mask():
+ The configuration for consistent allocations is performed via
+ a call to dma_set_coherent_mask():
int dma_set_coherent_mask(struct device *dev, u64 mask);
Here, dev is a pointer to the device struct of your device, and mask
is a bit mask describing which bits of an address your device
supports. It returns zero if your card can perform DMA properly on
-the machine given the address mask you provided. In general, the
-device struct of your device is embedded in the bus-specific device
-struct of your device. For example, &pdev->dev is a pointer to the
-device struct of a PCI device (pdev is a pointer to the PCI device
-struct of your device).
+the machine given the address mask you provided. Subsequent to
+calling the above apis, DMA allocations will be made from address
+space that conforms to the mask. The DMA allocation space maybe
+further restricted if devices along the patch to memory have stricter
+addressing requirements than the device performing the DMA, e.g.,
+IOMMU.
+
+In general, the device struct of your device is embedded in the
+bus-specific device struct of your device. For example, &pdev->dev is
+a pointer to the device struct of a PCI device (pdev is a pointer to
+the PCI device struct of your device).
If it returns non-zero, your device cannot perform DMA properly on
this platform, and attempting to do so will result in undefined
--
2.9.3
^ permalink raw reply related
* [PATCH v26 0/7] arm64: add kdump support
From: Ruslan Bilovol @ 2016-10-17 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160907042908.6232-1-takahiro.akashi@linaro.org>
Hi,
On 09/07/2016 07:29 AM, AKASHI Takahiro wrote:
> v26-specific note: After a comment from Rob[0], an idea of adding
> "linux,usable-memory-range" was dropped. Instead, an existing
> "reserved-memory" node will be used to limit usable memory ranges
> on crash dump kernel.
> This works not only on UEFI/ACPI systems but also on DT-only systems,
> but if he really insists on using DT-specific "usable-memory" property,
> I will post additional patches for kexec-tools. Those would be
> redundant, though.
> Even in that case, the kernel will not have to be changed.
>
> This patch series adds kdump support on arm64.
> There are some prerequisite patches [1],[2].
>
> To load a crash-dump kernel to the systems, a series of patches to
> kexec-tools, which have not yet been merged upstream, are needed.
> Please always use my latest kdump patches, v3 [3].
>
> To examine vmcore (/proc/vmcore) on a crash-dump kernel, you can use
> - crash utility (coming v7.1.6 or later) [4]
> (Necessary patches have already been queued in the master.)
>
>
> [0] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/452582.html
> [1] "arm64: mark reserved memblock regions explicitly in iomem"
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/450433.html
> [2] "efi: arm64: treat regions with WT/WC set but WB cleared as memory"
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/451491.html
> [3] T.B.D.
> [4] https://github.com/crash-utility/crash.git
Are you going to rebase your patch series onto v4.9-rc1 tag soon? I see
that patches [1] and [2] are already in v4.9-rc1, but when tried to apply
this series, I've got conflict on first patch of the series ("arm64: kdump:
reserve memory for crash dump kernel"). I want to try arm64 kdump
patches again on my board, so I'm interested in this. The question is
whether I need to rebase it myself or you will do the same (and address
comments) soon.
Also I see Geoff published v6 of arm64 kexec-tools patches, so same
question is applicable to "(kexec-tools) arm64: add kdump support"
patch series.
Thanks,
Ruslan
^ 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