* [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] 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 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 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 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: 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] 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 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 v2] ARM: shmobile: Consolidate R8A7743 and R8A779[234] machine definitions
From: Laurent Pinchart @ 2016-10-17 13:59 UTC (permalink / raw)
To: linux-arm-kernel
The four SoCs use identical machine operations, consolidate them into
two machine definitions in a single file.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes since v1:
- Rebased on top of Simon's latest devel branch, thus including R8A7743
consolidation
arch/arm/mach-shmobile/Makefile | 4 ----
arch/arm/mach-shmobile/setup-r8a7743.c | 34 -------------------------------
arch/arm/mach-shmobile/setup-r8a7792.c | 35 --------------------------------
arch/arm/mach-shmobile/setup-r8a7793.c | 33 ------------------------------
arch/arm/mach-shmobile/setup-r8a7794.c | 33 ------------------------------
arch/arm/mach-shmobile/setup-rcar-gen2.c | 33 ++++++++++++++++++++++++++++++
6 files changed, 33 insertions(+), 139 deletions(-)
delete mode 100644 arch/arm/mach-shmobile/setup-r8a7743.c
delete mode 100644 arch/arm/mach-shmobile/setup-r8a7792.c
delete mode 100644 arch/arm/mach-shmobile/setup-r8a7793.c
delete mode 100644 arch/arm/mach-shmobile/setup-r8a7794.c
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 332b84f8261f..64611a1b4276 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -9,14 +9,10 @@ obj-y := timer.o
obj-$(CONFIG_ARCH_SH73A0) += setup-sh73a0.o
obj-$(CONFIG_ARCH_R8A73A4) += setup-r8a73a4.o
obj-$(CONFIG_ARCH_R8A7740) += setup-r8a7740.o
-obj-$(CONFIG_ARCH_R8A7743) += setup-r8a7743.o
obj-$(CONFIG_ARCH_R8A7778) += setup-r8a7778.o
obj-$(CONFIG_ARCH_R8A7779) += setup-r8a7779.o pm-r8a7779.o
obj-$(CONFIG_ARCH_R8A7790) += setup-r8a7790.o
obj-$(CONFIG_ARCH_R8A7791) += setup-r8a7791.o
-obj-$(CONFIG_ARCH_R8A7792) += setup-r8a7792.o
-obj-$(CONFIG_ARCH_R8A7793) += setup-r8a7793.o
-obj-$(CONFIG_ARCH_R8A7794) += setup-r8a7794.o
obj-$(CONFIG_ARCH_EMEV2) += setup-emev2.o
obj-$(CONFIG_ARCH_R7S72100) += setup-r7s72100.o
diff --git a/arch/arm/mach-shmobile/setup-r8a7743.c b/arch/arm/mach-shmobile/setup-r8a7743.c
deleted file mode 100644
index a7ecb82d219f..000000000000
--- a/arch/arm/mach-shmobile/setup-r8a7743.c
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * r8a7743 processor support
- *
- * Copyright (C) 2016 Cogent Embedded, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation; of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#include <linux/init.h>
-
-#include <asm/mach/arch.h>
-
-#include "common.h"
-#include "rcar-gen2.h"
-
-static const char * const r8a7743_boards_compat_dt[] __initconst = {
- "renesas,r8a7743",
- NULL,
-};
-
-DT_MACHINE_START(R8A7743_DT, "Generic R8A7743 (Flattened Device Tree)")
- .init_early = shmobile_init_delay,
- .init_time = rcar_gen2_timer_init,
- .init_late = shmobile_init_late,
- .reserve = rcar_gen2_reserve,
- .dt_compat = r8a7743_boards_compat_dt,
-MACHINE_END
diff --git a/arch/arm/mach-shmobile/setup-r8a7792.c b/arch/arm/mach-shmobile/setup-r8a7792.c
deleted file mode 100644
index a0910395da09..000000000000
--- a/arch/arm/mach-shmobile/setup-r8a7792.c
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * r8a7792 processor support
- *
- * Copyright (C) 2014 Renesas Electronics Corporation
- * Copyright (C) 2016 Cogent Embedded, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#include <linux/of_platform.h>
-
-#include <asm/mach/arch.h>
-
-#include "common.h"
-#include "rcar-gen2.h"
-
-static const char * const r8a7792_boards_compat_dt[] __initconst = {
- "renesas,r8a7792",
- NULL,
-};
-
-DT_MACHINE_START(R8A7792_DT, "Generic R8A7792 (Flattened Device Tree)")
- .init_early = shmobile_init_delay,
- .init_late = shmobile_init_late,
- .init_time = rcar_gen2_timer_init,
- .reserve = rcar_gen2_reserve,
- .dt_compat = r8a7792_boards_compat_dt,
-MACHINE_END
diff --git a/arch/arm/mach-shmobile/setup-r8a7793.c b/arch/arm/mach-shmobile/setup-r8a7793.c
deleted file mode 100644
index 5fce87f7f254..000000000000
--- a/arch/arm/mach-shmobile/setup-r8a7793.c
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
- * r8a7793 processor support
- *
- * Copyright (C) 2015 Ulrich Hecht
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#include <linux/init.h>
-#include <asm/mach/arch.h>
-
-#include "common.h"
-#include "rcar-gen2.h"
-
-static const char * const r8a7793_boards_compat_dt[] __initconst = {
- "renesas,r8a7793",
- NULL,
-};
-
-DT_MACHINE_START(R8A7793_DT, "Generic R8A7793 (Flattened Device Tree)")
- .init_early = shmobile_init_delay,
- .init_time = rcar_gen2_timer_init,
- .init_late = shmobile_init_late,
- .reserve = rcar_gen2_reserve,
- .dt_compat = r8a7793_boards_compat_dt,
-MACHINE_END
diff --git a/arch/arm/mach-shmobile/setup-r8a7794.c b/arch/arm/mach-shmobile/setup-r8a7794.c
deleted file mode 100644
index d2b093033132..000000000000
--- a/arch/arm/mach-shmobile/setup-r8a7794.c
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
- * r8a7794 processor support
- *
- * Copyright (C) 2014 Renesas Electronics Corporation
- * Copyright (C) 2014 Ulrich Hecht
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#include <linux/of_platform.h>
-#include "common.h"
-#include "rcar-gen2.h"
-#include <asm/mach/arch.h>
-
-static const char * const r8a7794_boards_compat_dt[] __initconst = {
- "renesas,r8a7794",
- NULL,
-};
-
-DT_MACHINE_START(R8A7794_DT, "Generic R8A7794 (Flattened Device Tree)")
- .init_early = shmobile_init_delay,
- .init_late = shmobile_init_late,
- .init_time = rcar_gen2_timer_init,
- .reserve = rcar_gen2_reserve,
- .dt_compat = r8a7794_boards_compat_dt,
-MACHINE_END
diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c b/arch/arm/mach-shmobile/setup-rcar-gen2.c
index afb9fdcd3d90..875bcb8c1026 100644
--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
@@ -24,6 +24,7 @@
#include <linux/memblock.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
+#include <linux/of_platform.h>
#include <asm/mach/arch.h>
#include "common.h"
#include "rcar-gen2.h"
@@ -203,3 +204,35 @@ void __init rcar_gen2_reserve(void)
}
#endif
}
+
+static const char * const rcar_gen2_boards_compat_dt[] __initconst = {
+ /*
+ * R8A7790 and R8A7791 can't be handled here as long as they need SMP
+ * initialization fallback.
+ */
+ "renesas,r8a7792",
+ "renesas,r8a7793",
+ "renesas,r8a7794",
+ NULL,
+};
+
+DT_MACHINE_START(RCAR_GEN2_DT, "Generic R-Car Gen2 (Flattened Device Tree)")
+ .init_early = shmobile_init_delay,
+ .init_late = shmobile_init_late,
+ .init_time = rcar_gen2_timer_init,
+ .reserve = rcar_gen2_reserve,
+ .dt_compat = rcar_gen2_boards_compat_dt,
+MACHINE_END
+
+static const char * const rz_g1_boards_compat_dt[] __initconst = {
+ "renesas,r8a7743",
+ NULL,
+};
+
+DT_MACHINE_START(RZ_G1_DT, "Generic RZ/G1 (Flattened Device Tree)")
+ .init_early = shmobile_init_delay,
+ .init_late = shmobile_init_late,
+ .init_time = rcar_gen2_timer_init,
+ .reserve = rcar_gen2_reserve,
+ .dt_compat = rz_g1_boards_compat_dt,
+MACHINE_END
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* [PATCH 0/2] mmc: sdhci-iproc: Add byte register access support
From: Ulf Hansson @ 2016-10-17 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476297352-7812-1-git-send-email-scott.branden@broadcom.com>
On 12 October 2016 at 20:35, Scott Branden <scott.branden@broadcom.com> wrote:
> Add brcm,sdhci-iproc compat string and code for support of newer versions of
> sdhci-iproc controller that allow byte-wise register accesses.
>
> Scott Branden (2):
> mmc: sdhci-iproc: Add brcm,sdhci-iproc compat string in bindings
> document
> mmc: sdhci-iproc: support standard byte register accesses
>
> .../devicetree/bindings/mmc/brcm,sdhci-iproc.txt | 1 +
> drivers/mmc/host/sdhci-iproc.c | 35 ++++++++++++++++++++--
> 2 files changed, 34 insertions(+), 2 deletions(-)
>
> --
> 2.5.0
>
Thanks, applied for next!
Kind regards
Uffe
^ permalink raw reply
* [PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support
From: Arnd Bergmann @ 2016-10-17 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017120705.3726-2-wenpan@hisilicon.com>
On Monday, October 17, 2016 8:07:03 PM CEST Pan Wen wrote:
> Add support for some HiSilicon SoCs which depend on ARCH_MULTI_V5.
>
> Signed-off-by: Pan Wen <wenpan@hisilicon.com>
>
Looks ok. I've added Marty Plummer to Cc, he was recently proposing
patches for Hi3520, which I think is closely related to this one.
Please try to work together so the patches don't conflict. It should
be fairly straightforward since you are basically doing the same
change here.
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: fixes for v4.8 (#3)
From: Arnd Bergmann @ 2016-10-17 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87insrf8aw.fsf@free-electrons.com>
On Monday, October 17, 2016 2:51:03 PM CEST Gregory CLEMENT wrote:
> Hi Arnd,
>
> On mer., sept. 21 2016, Arnd Bergmann <arnd@arndb.de> wrote:
>
> > On Tuesday, September 20, 2016 6:14:47 PM CEST Gregory CLEMENT wrote:
> >> mvebu fixes for 4.8 (part 3)
> >>
> >> - Select corediv clk for all mvebu v7 SoC
> >> - Fix clocksource for CP110 master SPI0 for Armada 7K/8K
> >>
> >
> > Pulled into fixes, thanks!
>
> I don't see this patch in the v4.8 or the v4.9-rc1.
>
> I think it slipped through the cracks as there were the only one in the
> fixes branches.
>
> Do you think you could make them part of your next pull request for
> fixes for 4.9-rc2?
Indeed, I missed how this was still on the fixes branch during
the merge window. It is still on that branch (and nothing else
is so far), and it will be part of the next fixes pull request.
Thanks for the reminder.
Arnd
^ permalink raw reply
* [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
From: Lorenzo Pieralisi @ 2016-10-17 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5cf1acbf9c42cc99e5cc0dacb50b7a92c3bd0feb.1476702234.git.robin.murphy@arm.com>
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.
Anyway:
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> }
>
> static int arm_smmu_device_remove(struct platform_device *pdev)
> --
> 1.9.1
>
^ permalink raw reply
* ARM64-cpuinfo: Combine six calls for sequence output into one seq_printf() call in c_show()
From: Mark Rutland @ 2016-10-17 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d012ad47-9688-5c9c-6ffd-78300c7b21ae@users.sourceforge.net>
On Mon, Oct 17, 2016 at 02:50:57PM +0200, SF Markus Elfring wrote:
> > I prefer the code as-is. Unless there's a compelling reason to change it.
>
> Is the chance for faster log output interesting enough?
Is there a particular user that cares today, or are we trying to work
backwards to a rationale?
Thanks,
Mark.
^ permalink raw reply
* [PATCH v4 0/1] Armada 7k/8k CP110 system controller fixes
From: Marcin Wojtas @ 2016-10-17 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPv3WKf13FJxGkpt+OcNO--hRQoZr-TtuzCcAJrQwFXjqRgM2Q@mail.gmail.com>
Hi Stephen,
Since merge window is closed, I kindly remind about remaining patch.
Best regards,
Marcin
2016-10-06 21:24 GMT+02:00 Marcin Wojtas <mw@semihalf.com>:
> Hi Stephen,
>
> Do you have any further comments on the remaining patch?
>
> Best regards,
> Marcin
>
> 2016-09-25 9:47 GMT+02:00 Marcin Wojtas <mw@semihalf.com>:
>> Hi,
>>
>> Two patches from the third version of the patchset have already been
>> applied, so I re-send the last one with corrected allocation of
>> clock data, which was pointed in the review.
>>
>> Any feedback would be very welcome.
>>
>> Best regards,
>> Marcin
>>
>> Changelog:
>> v4 <- v3
>> * fix allocation of clock data
>>
>> v3 <- v2
>> * return -ENOMEM on alloc failures
>>
>> v1 <- v2
>> * replace setting CLK_IS_BASIC flag with clearing init structure fields
>> with memset
>> * minor improvements of allocation and error checking
>> * add migration to clk_hw
>>
>>
>> Marcin Wojtas (1):
>> clk: mvebu: migrate CP110 system controller to clk_hw API and
>> registration
>>
>> drivers/clk/mvebu/cp110-system-controller.c | 150 +++++++++++++---------------
>> 1 file changed, 72 insertions(+), 78 deletions(-)
>>
>> --
>> 1.8.3.1
>>
^ permalink raw reply
* [PATCH] usb: ehci-platform: increase EHCI_MAX_RSTS to 4
From: Masahiro Yamada @ 2016-10-17 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017123043.GA15142@kroah.com>
Hi Greg,
2016-10-17 21:30 GMT+09:00 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> On Mon, Oct 17, 2016 at 08:11:59PM +0900, Masahiro Yamada wrote:
>> Socionext LD11 SoC (arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi)
>> needs to handle 4 reset lines for EHCI.
>
> Why? What makes it different from other EHCI implementations?
>
> thanks,
>
> greg k-h
This is a generic EHCI driver, but the number of clocks/resets
are SoC-specific.
The following patch you picked up will remind you something?
commit 73577d61799e8d8bb7d69a9acdc54923e5998138
Author: Icenowy Zheng <icenowy@aosc.xyz>
Date: Fri Aug 12 11:06:22 2016 +0800
ehci-platform: add the max clock number to 4
Allwinner A64 EHCI requires 4 clocks to be enabled.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Regression: usb serial gadget on sama5d3 broken
From: Peter Rosin @ 2016-10-17 12:53 UTC (permalink / raw)
To: linux-arm-kernel
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.
Cheers,
Peter
^ permalink raw reply
* [GIT PULL] ARM: mvebu: fixes for v4.8 (#3)
From: Gregory CLEMENT @ 2016-10-17 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4853532.G9HOlQ47QA@wuerfel>
Hi Arnd,
On mer., sept. 21 2016, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday, September 20, 2016 6:14:47 PM CEST Gregory CLEMENT wrote:
>> mvebu fixes for 4.8 (part 3)
>>
>> - Select corediv clk for all mvebu v7 SoC
>> - Fix clocksource for CP110 master SPI0 for Armada 7K/8K
>>
>
> Pulled into fixes, thanks!
I don't see this patch in the v4.8 or the v4.9-rc1.
I think it slipped through the cracks as there were the only one in the
fixes branches.
Do you think you could make them part of your next pull request for
fixes for 4.9-rc2?
Thanks,
Gregory
>
> Arnd
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* ARM64-cpuinfo: Combine six calls for sequence output into one seq_printf() call in c_show()
From: SF Markus Elfring @ 2016-10-17 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017123726.GE29095@leverpostej>
> I prefer the code as-is. Unless there's a compelling reason to change it.
Is the chance for faster log output interesting enough?
Regards,
Markus
^ permalink raw reply
* [PATCHv2 4/4] arm64: dump: Add checking for writable and exectuable pages
From: Mark Rutland @ 2016-10-17 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476311522-15381-5-git-send-email-labbott@redhat.com>
On Wed, Oct 12, 2016 at 03:32:02PM -0700, Laura Abbott wrote:
> +config DEBUG_WX
> + bool "Warn on W+X mappings at boot"
> + select ARM64_PTDUMP_CORE
> + ---help---
> + Generate a warning if any W+X mappings are found at boot.
> +
> + This is useful for discovering cases where the kernel is leaving
> + W+X mappings after applying NX, as such mappings are a security risk.
> + This check also includes UXN, which should be set on all kernel
> + mappings.
> +
> + Look for a message in dmesg output like this:
> +
> + arm64/mm: Checked W+X mappings: passed, no W+X pages found.
> +
> + or like this, if the check failed:
> +
> + arm64/mm: Checked W+X mappings: FAILED, <N> W+X pages found.
> +
> + Note that even if the check fails, your kernel is possibly
> + still fine, as W+X mappings are not a security hole in
> + themselves, what they do is that they make the exploitation
> + of other unfixed kernel bugs easier.
> +
> + There is no runtime or memory usage effect of this option
> + once the kernel has booted up - it's a one time check.
> +
> + If in doubt, say "Y".
> +
> +
Trivial nit: for consistency with the rest of the file, there should
only be one line space between options.
> config DEBUG_SET_MODULE_RONX
> bool "Set loadable kernel module data as NX and text as RO"
> depends on MODULES
> diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
> index 8fc0957..6afd847 100644
> --- a/arch/arm64/include/asm/ptdump.h
> +++ b/arch/arm64/include/asm/ptdump.h
> @@ -42,5 +42,13 @@ static inline int ptdump_debugfs_register(struct ptdump_info *info,
> return 0;
> }
> #endif
> +void ptdump_check_wx(void);
> +#endif /* CONFIG_ARM64_PTDUMP_CORE */
... ah, here's the missing #endif from patch 1.
Assuming that gets sorted out, this looks good to me, and works on juno,
so FWIW:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
[...]
> +static void note_prot_uxn(struct pg_state *st, unsigned long addr)
> +{
> + if (!st->check_wx)
> + return;
> +
> + if ((st->current_prot & PTE_UXN) == PTE_UXN)
> + return;
> +
> + WARN_ONCE(1, "arm64/mm: Found non-UXN mapping at address %p/%pS\n",
> + (void *)st->start_address, (void *)st->start_address);
> +
> + st->wx_pages += (addr - st->start_address) / PAGE_SIZE;
> +}
As a future thought (I've scope-creeped this enough with the UXN check),
there are some other checks that we could add, like verifying the AP
bits don't allow user data access. That might be worth considering, with
DEBUG_WX becoming a more general kernel page table sanity check.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller
From: Laurent Pinchart @ 2016-10-17 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <daf49046-ad0a-d9e2-d744-1e06085c6585@ti.com>
Hi Tomi,
On Monday 17 Oct 2016 15:29:23 Tomi Valkeinen wrote:
> On 17/10/16 14:40, Laurent Pinchart wrote:
> > 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.
You obviously know more than I do on this topic so I'll trust your opinion. If
the version register isn't enough I'm fine with multiple compatible strings.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [RFC PATCH 3/3] MAINTAINERS: oxnas: Add new files definitions
From: Neil Armstrong @ 2016-10-17 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017124001.23820-1-narmstrong@baylibre.com>
Fix the dts files maintained by the OXNAS platform, add a new board.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 71aa5da..9f4bc60 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1444,8 +1444,9 @@ M: Neil Armstrong <narmstrong@baylibre.com>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-oxnas/
-F: arch/arm/boot/dts/oxnas*
+F: arch/arm/boot/dts/ox8*.dtsi
F: arch/arm/boot/dts/wd-mbwe.dts
+F: arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
N: oxnas
ARM/Mediatek RTC DRIVER
--
2.7.0
^ permalink raw reply related
* [RFC PATCH 2/3] ARM: dts: OX810: Update with dt-bindings includes
From: Neil Armstrong @ 2016-10-17 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017124001.23820-1-narmstrong@baylibre.com>
Add OX810SE dt-bindings includes files for clocks and resets, replace
resets numbers by human readable defines.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm/boot/dts/ox810se.dtsi | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/ox810se.dtsi b/arch/arm/boot/dts/ox810se.dtsi
index ce13705..46aa6db 100644
--- a/arch/arm/boot/dts/ox810se.dtsi
+++ b/arch/arm/boot/dts/ox810se.dtsi
@@ -7,6 +7,8 @@
*/
/include/ "skeleton.dtsi"
+#include <dt-bindings/clock/oxsemi,ox810se.h>
+#include <dt-bindings/reset/oxsemi,ox810se.h>
/ {
compatible = "oxsemi,ox810se";
@@ -242,7 +244,7 @@
current-speed = <115200>;
no-loopback-test;
status = "disabled";
- resets = <&reset 17>;
+ resets = <&reset RESET_UART1>;
};
uart1: serial at 300000 {
@@ -256,7 +258,7 @@
current-speed = <115200>;
no-loopback-test;
status = "disabled";
- resets = <&reset 18>;
+ resets = <&reset RESET_UART2>;
};
uart2: serial at 900000 {
@@ -270,7 +272,7 @@
current-speed = <115200>;
no-loopback-test;
status = "disabled";
- resets = <&reset 22>;
+ resets = <&reset RESET_UART3>;
};
uart3: serial at a00000 {
@@ -284,7 +286,7 @@
current-speed = <115200>;
no-loopback-test;
status = "disabled";
- resets = <&reset 23>;
+ resets = <&reset RESET_UART4>;
};
};
--
2.7.0
^ permalink raw reply related
* [RFC PATCH 1/3] ARM: dts: Add support for OX820 and Pogoplug V3
From: Neil Armstrong @ 2016-10-17 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017124001.23820-1-narmstrong@baylibre.com>
Add device tree for the Oxford Seminconductor OX820 SoC and the
Cloud Engines PogoPlug v3 board.
Add the SoC and board compatible strings to oxnas bindings.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/arm/oxnas.txt | 5 +
arch/arm/boot/dts/Makefile | 3 +-
.../boot/dts/cloudengines-pogoplug-series-3.dts | 60 +++++
arch/arm/boot/dts/ox820.dtsi | 259 +++++++++++++++++++++
4 files changed, 326 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
create mode 100644 arch/arm/boot/dts/ox820.dtsi
diff --git a/Documentation/devicetree/bindings/arm/oxnas.txt b/Documentation/devicetree/bindings/arm/oxnas.txt
index b9e4971..ac64e60 100644
--- a/Documentation/devicetree/bindings/arm/oxnas.txt
+++ b/Documentation/devicetree/bindings/arm/oxnas.txt
@@ -5,5 +5,10 @@ Boards with the OX810SE SoC shall have the following properties:
Required root node property:
compatible: "oxsemi,ox810se"
+Boards with the OX820 SoC shall have the following properties:
+ Required root node property:
+ compatible: "oxsemi,ox820"
+
Board compatible values:
- "wd,mbwe" (OX810SE)
+ - "cloudengines,pogoplugv3" (OX820)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index faacd52..5d9e8d5 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -588,7 +588,8 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
dtb-$(CONFIG_ARCH_PRIMA2) += \
prima2-evb.dtb
dtb-$(CONFIG_ARCH_OXNAS) += \
- wd-mbwe.dtb
+ wd-mbwe.dtb \
+ cloudengines-pogoplug-series-3.dtb
dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8060-dragonboard.dtb \
qcom-apq8064-arrow-sd-600eval.dtb \
diff --git a/arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts b/arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
new file mode 100644
index 0000000..78d9149
--- /dev/null
+++ b/arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
@@ -0,0 +1,60 @@
+/*
+ * cloudengines-pogoplug-series-3.dtsi - Device tree file for Cloud Engines PogoPlug Series 3
+ *
+ * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/dts-v1/;
+#include "ox820.dtsi"
+
+/ {
+ model = "Cloud Engines PogoPlug Series 3";
+
+ compatible = "cloudengines,pogoplugv3", "oxsemi,ox820";
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8 earlyprintk=serial";
+ };
+
+ memory {
+ /* 128Mbytes DDR */
+ reg = <0x60000000 0x8000000>;
+ };
+
+ aliases {
+ serial0 = &uart0;
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ blue {
+ label = "pogoplug:blue";
+ gpios = <&gpio0 2 0>;
+ default-state = "keep";
+ };
+
+ orange {
+ label = "pogoplug:orange";
+ gpios = <&gpio1 16 1>;
+ default-state = "keep";
+ };
+
+ green {
+ label = "pogoplug:green";
+ gpios = <&gpio1 17 1>;
+ default-state = "keep";
+ };
+ };
+};
+
+&uart0 {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart0>;
+};
diff --git a/arch/arm/boot/dts/ox820.dtsi b/arch/arm/boot/dts/ox820.dtsi
new file mode 100644
index 0000000..fe251f180
--- /dev/null
+++ b/arch/arm/boot/dts/ox820.dtsi
@@ -0,0 +1,259 @@
+/*
+ * ox820.dtsi - Device tree file for Oxford Semiconductor OX820 SoC
+ *
+ * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/include/ "skeleton.dtsi"
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/oxsemi,ox820.h>
+#include <dt-bindings/reset/oxsemi,ox820.h>
+
+/ {
+ compatible = "oxsemi,ox820";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ enable-method = "oxsemi,ox820-smp";
+
+ cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,arm11mpcore";
+ clocks = <&armclk>;
+ reg = <0>;
+ };
+
+ cpu at 1 {
+ device_type = "cpu";
+ compatible = "arm,arm11mpcore";
+ clocks = <&armclk>;
+ reg = <1>;
+ };
+ };
+
+ memory {
+ /* Max 512MB @ 0x60000000 */
+ reg = <0x60000000 0x20000000>;
+ };
+
+ clocks {
+ osc: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+
+ gmacclk: gmacclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <125000000>;
+ };
+
+ sysclk: sysclk {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-div = <4>;
+ clock-mult = <1>;
+ clocks = <&osc>;
+ };
+
+ plla: plla {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <850000000>;
+ };
+
+ armclk: armclk {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-div = <2>;
+ clock-mult = <1>;
+ clocks = <&plla>;
+ };
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges;
+ interrupt-parent = <&gic>;
+
+ apb-bridge at 44000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0x44000000 0x1000000>;
+
+ pinctrl: pinctrl {
+ compatible = "oxsemi,ox820-pinctrl";
+
+ /* Regmap for sys registers */
+ oxsemi,sys-ctrl = <&sys>;
+
+ pinctrl_uart0: uart0 {
+ uart0 {
+ pins = "gpio30", "gpio31";
+ function = "fct5";
+ };
+ };
+
+ pinctrl_uart0_modem: uart0_modem {
+ uart0_modem_a {
+ pins = "gpio24", "gpio24", "gpio26", "gpio27";
+ function = "fct4";
+ };
+ uart0_modem_b {
+ pins = "gpio28", "gpio29";
+ function = "fct5";
+ };
+ };
+
+ pinctrl_uart1: uart1 {
+ uart1 {
+ pins = "gpio7", "gpio8";
+ function = "fct4";
+ };
+ };
+
+ pinctrl_uart1_modem: uart1_modem {
+ uart1_modem {
+ pins = "gpio5", "gpio6", "gpio40", "gpio41", "gpio42", "gpio43";
+ function = "fct4";
+ };
+ };
+
+ pinctrl_etha_mdio: etha_mdio {
+ etha_mdio {
+ pins = "gpio3", "gpio4";
+ function = "fct1";
+ };
+ };
+ };
+
+ gpio0: gpio at 000000 {
+ compatible = "oxsemi,ox820-gpio";
+ reg = <0x000000 0x100000>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ngpios = <32>;
+ oxsemi,gpio-bank = <0>;
+ gpio-ranges = <&pinctrl 0 0 32>;
+ };
+
+ gpio1: gpio at 100000 {
+ compatible = "oxsemi,ox820-gpio";
+ reg = <0x100000 0x100000>;
+ interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ngpios = <18>;
+ oxsemi,gpio-bank = <1>;
+ gpio-ranges = <&pinctrl 0 32 18>;
+ };
+
+ uart0: serial at 200000 {
+ compatible = "ns16550a";
+ reg = <0x200000 0x100000>;
+ interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <0>;
+ fifo-size = <16>;
+ reg-io-width = <1>;
+ current-speed = <115200>;
+ no-loopback-test;
+ status = "disabled";
+ clocks = <&sysclk>;
+ resets = <&reset RESET_UART1>;
+ };
+
+ uart1: serial at 300000 {
+ compatible = "ns16550a";
+ reg = <0x200000 0x100000>;
+ interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <0>;
+ fifo-size = <16>;
+ reg-io-width = <1>;
+ current-speed = <115200>;
+ no-loopback-test;
+ status = "disabled";
+ clocks = <&sysclk>;
+ resets = <&reset RESET_UART2>;
+ };
+
+ rps at 400000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0x400000 0x100000>;
+
+ intc: interrupt-controller at 0 {
+ compatible = "oxsemi,ox820-rps-irq", "oxsemi,ox810se-rps-irq";
+ interrupt-controller;
+ reg = <0 0x200>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <1>;
+ valid-mask = <0xFFFFFFFF>;
+ clear-mask = <0>;
+ };
+
+ timer0: timer at 200 {
+ compatible = "oxsemi,ox820-rps-timer";
+ reg = <0x200 0x40>;
+ clocks = <&sysclk>;
+ interrupt-parent = <&intc>;
+ interrupts = <4>;
+ };
+ };
+
+ sys: sys-ctrl at e00000 {
+ compatible = "oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd";
+ reg = <0xe00000 0x200000>;
+
+ reset: reset-controller {
+ compatible = "oxsemi,ox820-reset", "oxsemi,ox810se-reset";
+ #reset-cells = <1>;
+ };
+
+ stdclk: stdclk {
+ compatible = "oxsemi,ox820-stdclk", "oxsemi,ox810se-stdclk";
+ #clock-cells = <1>;
+ };
+ };
+ };
+
+ apb-bridge at 47000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0x47000000 0x1000000>;
+
+ scu: scu at 0 {
+ compatible = "arm,arm11mp-scu";
+ reg = <0x0 0x100>;
+ };
+
+ local-timer at 600 {
+ compatible = "arm,arm11mp-twd-timer";
+ reg = <0x600 0x20>;
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_RAW(3)|IRQ_TYPE_LEVEL_HIGH)>;
+ clocks = <&armclk>;
+ };
+
+ gic: gic at 1000 {
+ compatible = "arm,arm11mp-gic";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x1000 0x1000>,
+ <0x100 0x500>;
+ };
+ };
+ };
+};
--
2.7.0
^ permalink raw reply related
* [RFC PATCH 0/3] ARM: dts: oxnas: Update support for OX820 and use dt-bindings
From: Neil Armstrong @ 2016-10-17 12:39 UTC (permalink / raw)
To: linux-arm-kernel
This patchset updates the ARM DTS for the Oxnas platform by :
- Add support for the Oxford Semicondutor OX820 and the PogoPlug V3
- Update the OX810SE to use the dt-bindings includes files introduced in [1] and [2]
- Fix the MAINTAINERS entry and add the PogoPlug V3 file maintainance
This patchset remains RFC until dependent patches [1] and [2] are merged.
[1] https://listengine.tuxfamily.org/lists.tuxfamily.org/linux-oxnas/2016/10/msg00008.html
[2] https://listengine.tuxfamily.org/lists.tuxfamily.org/linux-oxnas/2016/10/msg00007.html
Neil Armstrong (3):
ARM: dts: Add support for OX820 and Pogoplug V3
ARM: dts: OX810: Update with dt-bindings includes
MAINTAINERS: oxnas: Add new files definitions
Documentation/devicetree/bindings/arm/oxnas.txt | 5 +
MAINTAINERS | 3 +-
arch/arm/boot/dts/Makefile | 3 +-
.../boot/dts/cloudengines-pogoplug-series-3.dts | 60 +++++
arch/arm/boot/dts/ox810se.dtsi | 10 +-
arch/arm/boot/dts/ox820.dtsi | 259 +++++++++++++++++++++
6 files changed, 334 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
create mode 100644 arch/arm/boot/dts/ox820.dtsi
--
2.7.0
^ 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