* [PATCH 13/14] ARM: dts: armada-375: Fixup memory DT warning
From: Gregory CLEMENT @ 2016-11-10 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
memory has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375-db.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375-db.dts b/arch/arm/boot/dts/armada-375-db.dts
index 2da6300d184d..2018ccbfd058 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -58,7 +58,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory at 0 {
device_type = "memory";
reg = <0x00000000 0x40000000>; /* 1 GB */
};
--
2.10.1
^ permalink raw reply related
* [PATCH 14/14] ARM: dts: armada-375: Fixup ethernet child DT warning
From: Gregory CLEMENT @ 2016-11-10 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-1-gregory.clement@free-electrons.com>
Child of mvpp2 ethernet do not have a reg property so the unit name
should not contain an address: remove them.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 74824a1817b4..d0ea8afa15d0 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -224,13 +224,13 @@
clock-names = "pp_clk", "gop_clk";
status = "disabled";
- eth0: eth0 at c4000 {
+ eth0: eth0 {
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
port-id = <0>;
status = "disabled";
};
- eth1: eth1 at c5000 {
+ eth1: eth1 {
interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
port-id = <1>;
status = "disabled";
--
2.10.1
^ permalink raw reply related
* Summary of LPC guest MSI discussion in Santa Fe
From: Auger Eric @ 2016-11-10 0:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109165957.62c1eb61@t450s.home>
Hi,
On 10/11/2016 00:59, Alex Williamson wrote:
> On Wed, 9 Nov 2016 23:38:50 +0000
> Will Deacon <will.deacon@arm.com> wrote:
>
>> On Wed, Nov 09, 2016 at 04:24:58PM -0700, Alex Williamson wrote:
>>> On Wed, 9 Nov 2016 22:25:22 +0000
>>> Will Deacon <will.deacon@arm.com> wrote:
>>>
>>>> On Wed, Nov 09, 2016 at 03:17:09PM -0700, Alex Williamson wrote:
>>>>> On Wed, 9 Nov 2016 20:31:45 +0000
>>>>> Will Deacon <will.deacon@arm.com> wrote:
>>>>>> On Wed, Nov 09, 2016 at 08:23:03PM +0100, Christoffer Dall wrote:
>>>>>>>
>>>>>>> (I suppose it's technically possible to get around this issue by letting
>>>>>>> QEMU place RAM wherever it wants but tell the guest to never use a
>>>>>>> particular subset of its RAM for DMA, because that would conflict with
>>>>>>> the doorbell IOVA or be seen as p2p transactions. But I think we all
>>>>>>> probably agree that it's a disgusting idea.)
>>>>>>
>>>>>> Disgusting, yes, but Ben's idea of hotplugging on the host controller with
>>>>>> firmware tables describing the reserved regions is something that we could
>>>>>> do in the distant future. In the meantime, I don't think that VFIO should
>>>>>> explicitly reject overlapping mappings if userspace asks for them.
>>>>>
>>>>> I'm confused by the last sentence here, rejecting user mappings that
>>>>> overlap reserved ranges, such as MSI doorbell pages, is exactly how
>>>>> we'd reject hot-adding a device when we meet such a conflict. If we
>>>>> don't reject such a mapping, we're knowingly creating a situation that
>>>>> potentially leads to data loss. Minimally, QEMU would need to know
>>>>> about the reserved region, map around it through VFIO, and take
>>>>> responsibility (somehow) for making sure that region is never used for
>>>>> DMA. Thanks,
>>>>
>>>> Yes, but my point is that it should be up to QEMU to abort the hotplug, not
>>>> the host kernel, since there may be ways in which a guest can tolerate the
>>>> overlapping region (e.g. by avoiding that range of memory for DMA).
>>>
>>> The VFIO_IOMMU_MAP_DMA ioctl is a contract, the user ask to map a range
>>> of IOVAs to a range of virtual addresses for a given device. If VFIO
>>> cannot reasonably fulfill that contract, it must fail. It's up to QEMU
>>> how to manage the hotplug and what memory regions it asks VFIO to map
>>> for a device, but VFIO must reject mappings that it (or the SMMU by
>>> virtue of using the IOMMU API) know to overlap reserved ranges. So I
>>> still disagree with the referenced statement. Thanks,
>>
>> I think that's a pity. Not only does it mean that both QEMU and the kernel
>> have more work to do (the former has to carve up its mapping requests,
>> whilst the latter has to check that it is indeed doing this), but it also
>> precludes the use of hugepage mappings on the IOMMU because of reserved
>> regions. For example, a 4k hole someplace may mean we can't put down 1GB
>> table entries for the guest memory in the SMMU.
>>
>> All this seems to do is add complexity and decrease performance. For what?
>> QEMU has to go read the reserved regions from someplace anyway. It's also
>> the way that VFIO works *today* on arm64 wrt reserved regions, it just has
>> no way to identify those holes at present.
>
> Sure, that sucks, but how is the alternative even an option? The user
> asked to map something, we can't, if we allow that to happen now it's a
> bug. Put the MSI doorbells somewhere that this won't be an issue. If
> the platform has it fixed somewhere that this is an issue, don't use
> that platform. The correctness of the interface is more important than
> catering to a poorly designed system layout IMO. Thanks,
Besides above problematic, I started to prototype the sysfs API. A first
issue I face is the reserved regions become global to the iommu instead
of characterizing the iommu_domain, ie. the "reserved_regions" attribute
file sits below an iommu instance (~
/sys/class/iommu/dmar0/intel-iommu/reserved_regions ||
/sys/class/iommu/arm-smmu0/arm-smmu/reserved_regions).
MSI reserved window can be considered global to the IOMMU. However PCIe
host bridge P2P regions rather are per iommu-domain.
Do you confirm the attribute file should contain both global reserved
regions and all per iommu_domain reserved regions?
Thoughts?
Thanks
Eric
>
> Alex
>
> _______________________________________________
> 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 08/14] ARM: dts: armada-375: Fixup pcie DT warnings
From: Gregory CLEMENT @ 2016-11-10 0:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-9-gregory.clement@free-electrons.com>
Hi
On jeu., nov. 10 2016, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> PCIe has a ranges property, so the unit name should contain an address.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> arch/arm/boot/dts/armada-375.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
> index 700d80fe0d85..a157b62e810e 100644
> --- a/arch/arm/boot/dts/armada-375.dtsi
> +++ b/arch/arm/boot/dts/armada-375.dtsi
> @@ -580,7 +580,7 @@
> };
> };
>
> - pciec: pcie-controller at 82000000@ {
> + pciec: pcie-controller at 82000000 {
I don't know what happened but this patch should have been squashed in
the previous one.
I will fix it before applying on the mvebu tree of course.
Gregory
> compatible = "marvell,armada-370-pcie";
> status = "disabled";
> device_type = "pci";
> --
> 2.10.1
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Alex Williamson @ 2016-11-10 0:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <83b6440a-31eb-c1b4-642c-a4c311f37ef2@redhat.com>
On Thu, 10 Nov 2016 01:14:42 +0100
Auger Eric <eric.auger@redhat.com> wrote:
> Hi,
>
> On 10/11/2016 00:59, Alex Williamson wrote:
> > On Wed, 9 Nov 2016 23:38:50 +0000
> > Will Deacon <will.deacon@arm.com> wrote:
> >
> >> On Wed, Nov 09, 2016 at 04:24:58PM -0700, Alex Williamson wrote:
> >>> On Wed, 9 Nov 2016 22:25:22 +0000
> >>> Will Deacon <will.deacon@arm.com> wrote:
> >>>
> >>>> On Wed, Nov 09, 2016 at 03:17:09PM -0700, Alex Williamson wrote:
> >>>>> On Wed, 9 Nov 2016 20:31:45 +0000
> >>>>> Will Deacon <will.deacon@arm.com> wrote:
> >>>>>> On Wed, Nov 09, 2016 at 08:23:03PM +0100, Christoffer Dall wrote:
> >>>>>>>
> >>>>>>> (I suppose it's technically possible to get around this issue by letting
> >>>>>>> QEMU place RAM wherever it wants but tell the guest to never use a
> >>>>>>> particular subset of its RAM for DMA, because that would conflict with
> >>>>>>> the doorbell IOVA or be seen as p2p transactions. But I think we all
> >>>>>>> probably agree that it's a disgusting idea.)
> >>>>>>
> >>>>>> Disgusting, yes, but Ben's idea of hotplugging on the host controller with
> >>>>>> firmware tables describing the reserved regions is something that we could
> >>>>>> do in the distant future. In the meantime, I don't think that VFIO should
> >>>>>> explicitly reject overlapping mappings if userspace asks for them.
> >>>>>
> >>>>> I'm confused by the last sentence here, rejecting user mappings that
> >>>>> overlap reserved ranges, such as MSI doorbell pages, is exactly how
> >>>>> we'd reject hot-adding a device when we meet such a conflict. If we
> >>>>> don't reject such a mapping, we're knowingly creating a situation that
> >>>>> potentially leads to data loss. Minimally, QEMU would need to know
> >>>>> about the reserved region, map around it through VFIO, and take
> >>>>> responsibility (somehow) for making sure that region is never used for
> >>>>> DMA. Thanks,
> >>>>
> >>>> Yes, but my point is that it should be up to QEMU to abort the hotplug, not
> >>>> the host kernel, since there may be ways in which a guest can tolerate the
> >>>> overlapping region (e.g. by avoiding that range of memory for DMA).
> >>>
> >>> The VFIO_IOMMU_MAP_DMA ioctl is a contract, the user ask to map a range
> >>> of IOVAs to a range of virtual addresses for a given device. If VFIO
> >>> cannot reasonably fulfill that contract, it must fail. It's up to QEMU
> >>> how to manage the hotplug and what memory regions it asks VFIO to map
> >>> for a device, but VFIO must reject mappings that it (or the SMMU by
> >>> virtue of using the IOMMU API) know to overlap reserved ranges. So I
> >>> still disagree with the referenced statement. Thanks,
> >>
> >> I think that's a pity. Not only does it mean that both QEMU and the kernel
> >> have more work to do (the former has to carve up its mapping requests,
> >> whilst the latter has to check that it is indeed doing this), but it also
> >> precludes the use of hugepage mappings on the IOMMU because of reserved
> >> regions. For example, a 4k hole someplace may mean we can't put down 1GB
> >> table entries for the guest memory in the SMMU.
> >>
> >> All this seems to do is add complexity and decrease performance. For what?
> >> QEMU has to go read the reserved regions from someplace anyway. It's also
> >> the way that VFIO works *today* on arm64 wrt reserved regions, it just has
> >> no way to identify those holes at present.
> >
> > Sure, that sucks, but how is the alternative even an option? The user
> > asked to map something, we can't, if we allow that to happen now it's a
> > bug. Put the MSI doorbells somewhere that this won't be an issue. If
> > the platform has it fixed somewhere that this is an issue, don't use
> > that platform. The correctness of the interface is more important than
> > catering to a poorly designed system layout IMO. Thanks,
>
> Besides above problematic, I started to prototype the sysfs API. A first
> issue I face is the reserved regions become global to the iommu instead
> of characterizing the iommu_domain, ie. the "reserved_regions" attribute
> file sits below an iommu instance (~
> /sys/class/iommu/dmar0/intel-iommu/reserved_regions ||
> /sys/class/iommu/arm-smmu0/arm-smmu/reserved_regions).
>
> MSI reserved window can be considered global to the IOMMU. However PCIe
> host bridge P2P regions rather are per iommu-domain.
>
> Do you confirm the attribute file should contain both global reserved
> regions and all per iommu_domain reserved regions?
>
> Thoughts?
I don't think we have any business describing IOVA addresses consumed
by peer devices in an IOMMU sysfs file. If it's a separate device it
should be exposed by examining the rest of the topology. Regions
consumed by PCI endpoints and interconnects are already exposed in
sysfs. In fact, is this perhaps a more accurate model for these MSI
controllers too? Perhaps they should be exposed in the bus topology
somewhere as consuming the IOVA range. If DMA to an IOVA is consumed
by an intermediate device before it hits the IOMMU vs not being
translated as specified by the user at the IOMMU, I'm less inclined to
call that something VFIO should reject. However, instantiating a VM
with holes to account for every potential peer device seems like it
borders on insanity. Thanks,
Alex
^ permalink raw reply
* [PATCH 1/2] arm64: perf: Move ARMv8 PMU perf event definitions to asm/perf_event.h
From: kbuild test robot @ 2016-11-10 1:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478721480-24852-1-git-send-email-wei@redhat.com>
Hi Wei,
[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.9-rc4 next-20161109]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Wei-Huang/arm64-perf-Move-ARMv8-PMU-perf-event-definitions-to-asm-perf_event-h/20161110-040107
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
Note: the linux-review/Wei-Huang/arm64-perf-Move-ARMv8-PMU-perf-event-definitions-to-asm-perf_event-h/20161110-040107 HEAD 72ad64c0d8d13a655312ace104d723c9dd7dc5b0 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
arch/arm64/kvm/../../../virt/kvm/arm/pmu.c: In function 'kvm_pmu_software_increment':
>> arch/arm64/kvm/../../../virt/kvm/arm/pmu.c:308:16: error: 'ARMV8_PMU_EVTYPE_EVENT_SW_INCR' undeclared (first use in this function)
if ((type == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/arm64/kvm/../../../virt/kvm/arm/pmu.c:308:16: note: each undeclared identifier is reported only once for each function it appears in
arch/arm64/kvm/../../../virt/kvm/arm/pmu.c: In function 'kvm_pmu_set_counter_event_type':
arch/arm64/kvm/../../../virt/kvm/arm/pmu.c:382:18: error: 'ARMV8_PMU_EVTYPE_EVENT_SW_INCR' undeclared (first use in this function)
if (eventsel == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vim +/ARMV8_PMU_EVTYPE_EVENT_SW_INCR +308 arch/arm64/kvm/../../../virt/kvm/arm/pmu.c
7a0adc70 Shannon Zhao 2015-09-08 302 enable = vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
7a0adc70 Shannon Zhao 2015-09-08 303 for (i = 0; i < ARMV8_PMU_CYCLE_IDX; i++) {
7a0adc70 Shannon Zhao 2015-09-08 304 if (!(val & BIT(i)))
7a0adc70 Shannon Zhao 2015-09-08 305 continue;
7a0adc70 Shannon Zhao 2015-09-08 306 type = vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i)
7a0adc70 Shannon Zhao 2015-09-08 307 & ARMV8_PMU_EVTYPE_EVENT;
7a0adc70 Shannon Zhao 2015-09-08 @308 if ((type == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
7a0adc70 Shannon Zhao 2015-09-08 309 && (enable & BIT(i))) {
7a0adc70 Shannon Zhao 2015-09-08 310 reg = vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) + 1;
7a0adc70 Shannon Zhao 2015-09-08 311 reg = lower_32_bits(reg);
:::::: The code at line 308 was first introduced by commit
:::::: 7a0adc7064b88609e2917446af8789fac1d4fdd1 arm64: KVM: Add access handler for PMSWINC register
:::::: TO: Shannon Zhao <shannon.zhao@linaro.org>
:::::: CC: Marc Zyngier <marc.zyngier@arm.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 32739 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161110/5b2a68e8/attachment-0001.gz>
^ permalink raw reply
* [PATCH] arm: dts: qcom: Fix ipq board clock rates
From: Stephen Boyd @ 2016-11-10 1:13 UTC (permalink / raw)
To: linux-arm-kernel
The ipq board has these rates as 25MHz, and not 19.2 and 27. I
copy/pasted from other boards that have those rates but forgot
to fix the rates here.
Fixes: 30fc4212d541 ("arm: dts: qcom: Add more board clocks")
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/boot/dts/qcom-ipq8064.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index 2e375576ffd0..76f4e8921d58 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -65,13 +65,13 @@
cxo_board {
compatible = "fixed-clock";
#clock-cells = <0>;
- clock-frequency = <19200000>;
+ clock-frequency = <25000000>;
};
pxo_board {
compatible = "fixed-clock";
#clock-cells = <0>;
- clock-frequency = <27000000>;
+ clock-frequency = <25000000>;
};
sleep_clk: sleep_clk {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v5 5/8] Documentation: bindings: decouple juno specific details from generic binding
From: Rob Herring @ 2016-11-10 1:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478148731-11712-6-git-send-email-sudeep.holla@arm.com>
On Wed, Nov 02, 2016 at 10:52:08PM -0600, Sudeep Holla wrote:
> Since SCPI is a generic protocol and the bindings are intended to be
> generic, we need to decouple all the platform specific binding details
> out of the generic bindings.
>
> This patch moves are the Juno platform specific details into a separate
> binding document.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> Documentation/devicetree/bindings/arm/arm,scpi.txt | 20 ++++++-----------
> .../devicetree/bindings/arm/juno,scpi.txt | 26 ++++++++++++++++++++++
> 2 files changed, 33 insertions(+), 13 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
From: Rob Herring @ 2016-11-10 1:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478148731-11712-7-git-send-email-sudeep.holla@arm.com>
On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
> This patch adds specific compatible to support legacy SCPI protocol.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> index d1882c4540d0..ebd03fc93135 100644
> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
>
> Required properties:
>
> -- compatible : should be "arm,scpi"
> +- compatible : should be
> + * "arm,scpi" : For implementations complying to SCPI v1.0 or above
> + * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
I'd prefer that we explicitly enumerate the old versions. Are there
many?
Rob
^ permalink raw reply
* [PATCH v5 7/8] Documentation: bindings: Add support for Amlogic GXBB SCPI protocol
From: Rob Herring @ 2016-11-10 1:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478148731-11712-8-git-send-email-sudeep.holla@arm.com>
On Wed, Nov 02, 2016 at 10:52:10PM -0600, Sudeep Holla wrote:
> From: Neil Armstrong <narmstrong@baylibre.com>
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> (decoupled from the generic scpi binding)
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> .../devicetree/bindings/arm/amlogic,scpi.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 1/3] dt-bindings: firmware: scm: Add MSM8996 DT bindings
From: Stephen Boyd @ 2016-11-10 1:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478218237-1737-2-git-send-email-spjoshi@codeaurora.org>
On 11/03, Sarangdhar Joshi wrote:
> Add SCM DT bindings for Qualcomm's MSM8996 platform.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
> ---
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 1/1] arm64: dts: msm8996: Add SCM DT node
From: Stephen Boyd @ 2016-11-10 1:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477700063-18641-1-git-send-email-spjoshi@codeaurora.org>
On 10/28, Sarangdhar Joshi wrote:
> Add SCM DT node to enable SCM functionality on MSM8996.
>
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
> ---
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Will Deacon @ 2016-11-10 2:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109175517.174e7803@t450s.home>
On Wed, Nov 09, 2016 at 05:55:17PM -0700, Alex Williamson wrote:
> On Thu, 10 Nov 2016 01:14:42 +0100
> Auger Eric <eric.auger@redhat.com> wrote:
> > On 10/11/2016 00:59, Alex Williamson wrote:
> > > On Wed, 9 Nov 2016 23:38:50 +0000
> > > Will Deacon <will.deacon@arm.com> wrote:
> > >> On Wed, Nov 09, 2016 at 04:24:58PM -0700, Alex Williamson wrote:
> > >>> The VFIO_IOMMU_MAP_DMA ioctl is a contract, the user ask to map a range
> > >>> of IOVAs to a range of virtual addresses for a given device. If VFIO
> > >>> cannot reasonably fulfill that contract, it must fail. It's up to QEMU
> > >>> how to manage the hotplug and what memory regions it asks VFIO to map
> > >>> for a device, but VFIO must reject mappings that it (or the SMMU by
> > >>> virtue of using the IOMMU API) know to overlap reserved ranges. So I
> > >>> still disagree with the referenced statement. Thanks,
> > >>
> > >> I think that's a pity. Not only does it mean that both QEMU and the kernel
> > >> have more work to do (the former has to carve up its mapping requests,
> > >> whilst the latter has to check that it is indeed doing this), but it also
> > >> precludes the use of hugepage mappings on the IOMMU because of reserved
> > >> regions. For example, a 4k hole someplace may mean we can't put down 1GB
> > >> table entries for the guest memory in the SMMU.
> > >>
> > >> All this seems to do is add complexity and decrease performance. For what?
> > >> QEMU has to go read the reserved regions from someplace anyway. It's also
> > >> the way that VFIO works *today* on arm64 wrt reserved regions, it just has
> > >> no way to identify those holes at present.
> > >
> > > Sure, that sucks, but how is the alternative even an option? The user
> > > asked to map something, we can't, if we allow that to happen now it's a
> > > bug. Put the MSI doorbells somewhere that this won't be an issue. If
> > > the platform has it fixed somewhere that this is an issue, don't use
> > > that platform. The correctness of the interface is more important than
> > > catering to a poorly designed system layout IMO. Thanks,
> >
> > Besides above problematic, I started to prototype the sysfs API. A first
> > issue I face is the reserved regions become global to the iommu instead
> > of characterizing the iommu_domain, ie. the "reserved_regions" attribute
> > file sits below an iommu instance (~
> > /sys/class/iommu/dmar0/intel-iommu/reserved_regions ||
> > /sys/class/iommu/arm-smmu0/arm-smmu/reserved_regions).
> >
> > MSI reserved window can be considered global to the IOMMU. However PCIe
> > host bridge P2P regions rather are per iommu-domain.
I don't think we can treat them as per-domain, given that we want to
enumerate this stuff before we've decided to do a hotplug (and therefore
don't have a domain).
> >
> > Do you confirm the attribute file should contain both global reserved
> > regions and all per iommu_domain reserved regions?
> >
> > Thoughts?
>
> I don't think we have any business describing IOVA addresses consumed
> by peer devices in an IOMMU sysfs file. If it's a separate device it
> should be exposed by examining the rest of the topology. Regions
> consumed by PCI endpoints and interconnects are already exposed in
> sysfs. In fact, is this perhaps a more accurate model for these MSI
> controllers too? Perhaps they should be exposed in the bus topology
> somewhere as consuming the IOVA range. If DMA to an IOVA is consumed
> by an intermediate device before it hits the IOMMU vs not being
> translated as specified by the user at the IOMMU, I'm less inclined to
> call that something VFIO should reject.
Oh, so perhaps we've been talking past each other. In all of these cases,
the SMMU can translate the access if it makes it that far. The issue is
that not all accesses do make it that far, because they may be "consumed"
by another device, such as an MSI doorbell or another endpoint. In other
words, I don't envisage a scenario where e.g. some address range just
bypasses the SMMU straight to memory. I realise now that that's not clear
from the slides I presented.
> However, instantiating a VM
> with holes to account for every potential peer device seems like it
> borders on insanity. Thanks,
Ok, so rather than having a list of reserved regions under the iommu node,
you're proposing that each region is attributed to the device that "owns"
(consumes) it? I think that can work, but we need to make sure that:
(a) The topology is walkable from userspace (where do you start?)
(b) It also works for platform (non-PCI) devices, that lack much in the
way of bus hierarchy
(c) It doesn't require Linux to have a driver bound to a device in order
for the ranges consumed by that device to be advertised (again,
more of an issue for non-PCI).
How is this currently advertised for PCI? I'd really like to use the same
scheme irrespective of the bus type.
Will
^ permalink raw reply
* [PATCH 4/4] dts: arm64: enable mmc3 for supporting sdio feature
From: Yingjoe Chen @ 2016-11-10 2:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478585341-6749-5-git-send-email-yong.mao@mediatek.com>
On Tue, 2016-11-08 at 14:09 +0800, Yong Mao wrote:
> From: yong mao <yong.mao@mediatek.com>
>
> Add description of mmc3 for supporting sdio feature
>
> Signed-off-by: Yong Mao <yong.mao@mediatek.com>
> Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
> ---
> arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 82 +++++++++++++++++++++++++++
> 1 file changed, 82 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> index 2a7f731..4dbd299 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> @@ -43,6 +43,14 @@
> enable-active-high;
> };
>
> + sdio_fixed_3v3: fixedregulator at 0 {
This should be regulator at 1 instead of fixedregulator.
> + compatible = "regulator-fixed";
> + regulator-name = "3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&pio 85 GPIO_ACTIVE_HIGH>;
> + };
> +
> connector {
> compatible = "hdmi-connector";
> label = "hdmi";
> @@ -139,6 +147,25 @@
> vqmmc-supply = <&mt6397_vmc_reg>;
> };
>
> +&mmc3 {
> + status = "okay";
> + pinctrl-names = "default", "state_uhs";
> + pinctrl-0 = <&mmc3_pins_default>;
> + pinctrl-1 = <&mmc3_pins_uhs>;
> + bus-width = <4>;
> + max-frequency = <200000000>;
> + cap-sd-highspeed;
> + sd-uhs-sdr50;
> + sd-uhs-sdr104;
> + sdr104-clk-delay = <5>;
> + keep-power-in-suspend;
> + enable-sdio-wakeup;
> + cap-sdio-irq;
> + vmmc-supply = <&sdio_fixed_3v3>;
> + vqmmc-supply = <&mt6397_vgp3_reg>;
> + non-removable;
> +};
> +
> &pio {
> disp_pwm0_pins: disp_pwm0_pins {
> pins1 {
> @@ -197,6 +224,36 @@
> };
> };
>
> + mmc3_pins_default: mmc3default {
Please keep nodes in &pio sorted, move this one after mmc1_pins_uhs.
> + pins_dat {
> + pinmux = <MT8173_PIN_22_MSDC3_DAT0__FUNC_MSDC3_DAT0>,
> + <MT8173_PIN_23_MSDC3_DAT1__FUNC_MSDC3_DAT1>,
> + <MT8173_PIN_24_MSDC3_DAT2__FUNC_MSDC3_DAT2>,
> + <MT8173_PIN_25_MSDC3_DAT3__FUNC_MSDC3_DAT3>;
> + input-enable;
> + drive-strength = <MTK_DRIVE_8mA>;
> + bias-pull-up = <MTK_PUPD_SET_R1R0_10>;
> + };
> +
> + pins_cmd {
> + pinmux = <MT8173_PIN_27_MSDC3_CMD__FUNC_MSDC3_CMD>;
> + input-enable;
> + drive-strength = <MTK_DRIVE_8mA>;
> + bias-pull-up = <MTK_PUPD_SET_R1R0_10>;
> + };
> +
> + pins_clk {
> + pinmux = <MT8173_PIN_26_MSDC3_CLK__FUNC_MSDC3_CLK>;
> + bias-pull-down;
> + drive-strength = <MTK_DRIVE_8mA>;
> + };
> +
> + pins_pdn {
> + pinmux = <MT8173_PIN_85_AUD_DAT_MOSI__FUNC_GPIO85>;
> + output-low;
> + };
This one is used in regulator, not really an mmc pin.
Also, you don't need to add node for gpio usage, request_gpio will set
mode for you.
So please remove pins_pdn node.
> + };
> +
> mmc0_pins_uhs: mmc0 {
> pins_cmd_dat {
> pinmux = <MT8173_PIN_57_MSDC0_DAT0__FUNC_MSDC0_DAT0>,
> @@ -243,6 +300,31 @@
> bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
> };
> };
> +
> + mmc3_pins_uhs: mmc3 {
Please keep nodes in &pio sorted, move this one after mmc1_pins_uhs.
Joe.C
> + pins_dat {
> + pinmux = <MT8173_PIN_22_MSDC3_DAT0__FUNC_MSDC3_DAT0>,
> + <MT8173_PIN_23_MSDC3_DAT1__FUNC_MSDC3_DAT1>,
> + <MT8173_PIN_24_MSDC3_DAT2__FUNC_MSDC3_DAT2>,
> + <MT8173_PIN_25_MSDC3_DAT3__FUNC_MSDC3_DAT3>;
> + input-enable;
> + drive-strength = <MTK_DRIVE_8mA>;
> + bias-pull-up = <MTK_PUPD_SET_R1R0_10>;
> + };
> +
> + pins_cmd {
> + pinmux = <MT8173_PIN_27_MSDC3_CMD__FUNC_MSDC3_CMD>;
> + input-enable;
> + drive-strength = <MTK_DRIVE_8mA>;
> + bias-pull-up = <MTK_PUPD_SET_R1R0_10>;
> + };
> +
> + pins_clk {
> + pinmux = <MT8173_PIN_26_MSDC3_CLK__FUNC_MSDC3_CLK>;
> + drive-strength = <MTK_DRIVE_8mA>;
> + bias-pull-down = <MTK_PUPD_SET_R1R0_10>;
> + };
> + };
> };
>
> &pwm0 {
^ permalink raw reply
* [PATCH V6 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping
From: Hanjun Guo @ 2016-11-10 2:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477687696-1509-3-git-send-email-agustinv@codeaurora.org>
Hi Marc, Rafael, Lorenzo,
Since we agreed to add a probe deferral if we failed to get irq
resources which mirroring the DT does (patch 1 in this patch set),
I think the last blocker to make things work both for Agustin and
me [1] is this patch, which makes the interrupt producer and consumer
work in ACPI, we have two different solution for one thing, we'd happy
to work together for one solution, could you give some suggestions
please?
[1]: https://mail-archive.com/linux-kernel at vger.kernel.org/msg1257419.html
Agustin, I have some comments below.
On 2016/10/29 4:48, Agustin Vega-Frias wrote:
> This allows irqchip drivers to associate an ACPI DSDT device to
> an IRQ domain and provides support for using the ResourceSource
> in Extended IRQ Resources to find the domain and map the IRQs
> specified on that domain.
>
> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
> ---
> drivers/acpi/Makefile | 1 +
> drivers/acpi/irqdomain.c | 119 +++++++++++++++++++++++++++++++++++++++++++++++
Could we just reuse the gsi.c and not introduce a new
file, probably we can change the gsi.c to irqdomain.c
or something similar, then reuse the code in gsi.c.
Thanks
Hanjun
> drivers/acpi/resource.c | 21 +++++----
> include/linux/acpi.h | 25 ++++++++++
> 4 files changed, 157 insertions(+), 9 deletions(-)
> create mode 100644 drivers/acpi/irqdomain.c
>
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 9ed0878..880401b 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
> acpi-y += acpi_lpat.o
> acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
> acpi-$(CONFIG_ACPI_WATCHDOG) += acpi_watchdog.o
> +acpi-$(CONFIG_IRQ_DOMAIN) += irqdomain.o
>
> # These are (potentially) separate modules
>
> diff --git a/drivers/acpi/irqdomain.c b/drivers/acpi/irqdomain.c
> new file mode 100644
> index 0000000..11d3658
> --- /dev/null
> +++ b/drivers/acpi/irqdomain.c
> @@ -0,0 +1,119 @@
> +/*
> + * ACPI ResourceSource/IRQ domain mapping support
> + *
> + * Copyright (c) 2016, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * 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/acpi.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> +
> +/**
> + * acpi_irq_domain_register_irq() - Register the mapping for an IRQ produced
> + * by the given acpi_resource_source to a
> + * Linux IRQ number
> + * @source: IRQ source
> + * @hwirq: Hardware IRQ number
> + * @trigger: trigger type of the IRQ number to be mapped
> + * @polarity: polarity of the IRQ to be mapped
> + *
> + * Returns: a valid linux IRQ number on success
> + * -ENODEV if the given acpi_resource_source cannot be found
> + * -EPROBE_DEFER if the IRQ domain has not been registered
> + * -EINVAL for all other errors
> + */
> +int acpi_irq_domain_register_irq(const struct acpi_resource_source *source,
> + u32 hwirq, int trigger, int polarity)
> +{
> + struct irq_fwspec fwspec;
> + struct acpi_device *device;
> + acpi_handle handle;
> + acpi_status status;
> + int ret;
> +
> + /* An empty acpi_resource_source means it is a GSI */
> + if (!source->string_length)
> + return acpi_register_gsi(NULL, hwirq, trigger, polarity);
> +
> + status = acpi_get_handle(NULL, source->string_ptr, &handle);
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> +
> + device = acpi_bus_get_acpi_device(handle);
> + if (!device)
> + return -ENODEV;
> +
> + if (irq_find_matching_fwnode(&device->fwnode, DOMAIN_BUS_ANY) == NULL) {
> + ret = -EPROBE_DEFER;
> + goto out_put_device;
> + }
> +
> + fwspec.fwnode = &device->fwnode;
> + fwspec.param[0] = hwirq;
> + fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
> + fwspec.param_count = 2;
> +
> + ret = irq_create_fwspec_mapping(&fwspec);
> +
> +out_put_device:
> + acpi_bus_put_acpi_device(device);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(acpi_irq_domain_register_irq);
> +
> +/**
> + * acpi_irq_domain_unregister_irq() - Delete the mapping for an IRQ produced
> + * by the given acpi_resource_source to a
> + * Linux IRQ number
> + * @source: IRQ source
> + * @hwirq: Hardware IRQ number
> + *
> + * Returns: 0 on success
> + * -ENODEV if the given acpi_resource_source cannot be found
> + * -EINVAL for all other errors
> + */
> +int acpi_irq_domain_unregister_irq(const struct acpi_resource_source *source,
> + u32 hwirq)
> +{
> + struct irq_domain *domain;
> + struct acpi_device *device;
> + acpi_handle handle;
> + acpi_status status;
> + int ret = 0;
> +
> + if (!source->string_length) {
> + acpi_unregister_gsi(hwirq);
> + return 0;
> + }
> +
> + status = acpi_get_handle(NULL, source->string_ptr, &handle);
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> +
> + device = acpi_bus_get_acpi_device(handle);
> + if (!device)
> + return -ENODEV;
> +
> + domain = irq_find_matching_fwnode(&device->fwnode, DOMAIN_BUS_ANY);
> + if (!domain) {
> + ret = -EINVAL;
> + goto out_put_device;
> + }
> +
> + irq_dispose_mapping(irq_find_mapping(domain, hwirq));
> +
> +out_put_device:
> + acpi_bus_put_acpi_device(device);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(acpi_irq_domain_unregister_irq);
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 4beda15..ccb6f4f 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -381,14 +381,15 @@ static void acpi_dev_irqresource_disabled(struct resource *res, u32 gsi)
> res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
> }
>
> -static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
> +static void acpi_dev_get_irqresource(struct resource *res, u32 hwirq,
> + const struct acpi_resource_source *source,
> u8 triggering, u8 polarity, u8 shareable,
> bool legacy)
> {
> int irq, p, t;
>
> - if (!valid_IRQ(gsi)) {
> - acpi_dev_irqresource_disabled(res, gsi);
> + if ((source->string_length == 0) && !valid_IRQ(hwirq)) {
> + acpi_dev_irqresource_disabled(res, hwirq);
> return;
> }
>
> @@ -402,25 +403,25 @@ static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
> * using extended IRQ descriptors we take the IRQ configuration
> * from _CRS directly.
> */
> - if (legacy && !acpi_get_override_irq(gsi, &t, &p)) {
> + if (legacy && !acpi_get_override_irq(hwirq, &t, &p)) {
> u8 trig = t ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
> u8 pol = p ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
>
> if (triggering != trig || polarity != pol) {
> - pr_warning("ACPI: IRQ %d override to %s, %s\n", gsi,
> - t ? "level" : "edge", p ? "low" : "high");
> + pr_warn("ACPI: IRQ %d override to %s, %s\n", hwirq,
> + t ? "level" : "edge", p ? "low" : "high");
> triggering = trig;
> polarity = pol;
> }
> }
>
> res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
> - irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
> + irq = acpi_irq_domain_register_irq(source, hwirq, triggering, polarity);
> if (irq >= 0) {
> res->start = irq;
> res->end = irq;
> } else {
> - acpi_dev_irqresource_disabled(res, gsi);
> + acpi_dev_irqresource_disabled(res, hwirq);
> }
> }
>
> @@ -446,6 +447,7 @@ static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
> bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> struct resource *res)
> {
> + const struct acpi_resource_source dummy = { 0, 0, NULL };
> struct acpi_resource_irq *irq;
> struct acpi_resource_extended_irq *ext_irq;
>
> @@ -460,7 +462,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> acpi_dev_irqresource_disabled(res, 0);
> return false;
> }
> - acpi_dev_get_irqresource(res, irq->interrupts[index],
> + acpi_dev_get_irqresource(res, irq->interrupts[index], &dummy,
> irq->triggering, irq->polarity,
> irq->sharable, true);
> break;
> @@ -471,6 +473,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> return false;
> }
> acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
> + &ext_irq->resource_source,
> ext_irq->triggering, ext_irq->polarity,
> ext_irq->sharable, false);
> break;
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 40213c4..ce30a12 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -321,6 +321,31 @@ void acpi_set_irq_model(enum acpi_irq_model_id model,
> */
> void acpi_unregister_gsi (u32 gsi);
>
> +#ifdef CONFIG_IRQ_DOMAIN
> +
> +int acpi_irq_domain_register_irq(const struct acpi_resource_source *source,
> + u32 hwirq, int trigger, int polarity);
> +int acpi_irq_domain_unregister_irq(const struct acpi_resource_source *source,
> + u32 hwirq);
> +
> +#else
> +
> +static inline int acpi_irq_domain_register_irq(
> + const struct acpi_resource_source *source, u32 hwirq, int trigger,
> + int polarity)
> +{
> + return acpi_register_gsi(NULL, hwirq, trigger, polarity);
> +}
> +
> +static inline int acpi_irq_domain_unregister_irq(
> + const struct acpi_resource_source *source, u32 hwirq)
> +{
> + acpi_unregister_gsi(hwirq);
> + return 0;
> +}
> +
> +#endif /* CONFIG_IRQ_DOMAIN */
> +
> struct pci_dev;
>
> int acpi_pci_irq_enable (struct pci_dev *dev);
>
^ permalink raw reply
* [arm-soc:to-build 12/13] drivers/block/rbd.c:3690:5: warning: 'struct_v' may be used uninitialized in this function
From: kbuild test robot @ 2016-11-10 2:44 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git to-build
head: 694200c14d09069de036d1b4269b582b3118f575
commit: 3becf66c6faa12e51bd6d97df3706c8bef1b65d6 [12/13] Kbuild: enable -Wmaybe-uninitialized warnings by default
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 3becf66c6faa12e51bd6d97df3706c8bef1b65d6
# save the attached .config to linux build tree
make.cross ARCH=xtensa
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/block/rbd.c: In function 'rbd_watch_cb':
>> drivers/block/rbd.c:3690:5: warning: 'struct_v' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (struct_v >= 2) {
^
drivers/block/rbd.c:3759:5: note: 'struct_v' was declared here
u8 struct_v;
^
vim +/struct_v +3690 drivers/block/rbd.c
ed95b21a Ilya Dryomov 2016-08-12 3674 } else {
ed95b21a Ilya Dryomov 2016-08-12 3675 down_read(&rbd_dev->lock_rwsem);
ed95b21a Ilya Dryomov 2016-08-12 3676 }
ed95b21a Ilya Dryomov 2016-08-12 3677
ed95b21a Ilya Dryomov 2016-08-12 3678 if (!__rbd_is_lock_owner(rbd_dev))
ed95b21a Ilya Dryomov 2016-08-12 3679 wake_requests(rbd_dev, false);
ed95b21a Ilya Dryomov 2016-08-12 3680 up_read(&rbd_dev->lock_rwsem);
ed95b21a Ilya Dryomov 2016-08-12 3681 }
ed95b21a Ilya Dryomov 2016-08-12 3682
ed95b21a Ilya Dryomov 2016-08-12 3683 static bool rbd_handle_request_lock(struct rbd_device *rbd_dev, u8 struct_v,
ed95b21a Ilya Dryomov 2016-08-12 3684 void **p)
ed95b21a Ilya Dryomov 2016-08-12 3685 {
ed95b21a Ilya Dryomov 2016-08-12 3686 struct rbd_client_id my_cid = rbd_get_cid(rbd_dev);
ed95b21a Ilya Dryomov 2016-08-12 3687 struct rbd_client_id cid = { 0 };
ed95b21a Ilya Dryomov 2016-08-12 3688 bool need_to_send;
ed95b21a Ilya Dryomov 2016-08-12 3689
ed95b21a Ilya Dryomov 2016-08-12 @3690 if (struct_v >= 2) {
ed95b21a Ilya Dryomov 2016-08-12 3691 cid.gid = ceph_decode_64(p);
ed95b21a Ilya Dryomov 2016-08-12 3692 cid.handle = ceph_decode_64(p);
ed95b21a Ilya Dryomov 2016-08-12 3693 }
ed95b21a Ilya Dryomov 2016-08-12 3694
ed95b21a Ilya Dryomov 2016-08-12 3695 dout("%s rbd_dev %p cid %llu-%llu\n", __func__, rbd_dev, cid.gid,
ed95b21a Ilya Dryomov 2016-08-12 3696 cid.handle);
ed95b21a Ilya Dryomov 2016-08-12 3697 if (rbd_cid_equal(&cid, &my_cid))
ed95b21a Ilya Dryomov 2016-08-12 3698 return false;
:::::: The code at line 3690 was first introduced by commit
:::::: ed95b21a4b0a71ef89306cdeb427d53cc9cb343f rbd: support for exclusive-lock feature
:::::: TO: Ilya Dryomov <idryomov@gmail.com>
:::::: CC: Ilya Dryomov <idryomov@gmail.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 47027 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161110/0247dbdf/attachment-0001.gz>
^ permalink raw reply
* [PATCH 3/3] ipmi/bt-bmc: add a sysfs file to configure a maximum response time
From: Joel Stanley @ 2016-11-10 2:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7e7e5cde-341a-ecca-9c9c-b41695703b08@acm.org>
On Thu, Nov 10, 2016 at 2:34 AM, Corey Minyard <minyard@acm.org> wrote:
> On 11/09/2016 08:42 AM, C?dric Le Goater wrote:
>> The patch raises a few questions on the "BT Interface Capabilities" :
>>
>> - should we use sysfs or a specific ioctl to configure the driver ?
>
>
> I should probably say sysfs, but really I don't care. The hard part about
> ioctls is the compat, and there shouldn't be any compat issues with this
> interface. An ioctl is probably easier, especially if you add an ioctl for
> the header size thing I talked about in the previous email.
>
> The only thing that matters to the driver is the timeout. If you want to
> make the timeout per fd, then it will have to be an ioctl.
I vote for an ioctl as it's simpler for userspace.
In another driver we use on the BMCs we have a character device and a
few sysfs files for configuration. This means userspace needs to
discover and open > 1 fd, which is annoying.
Cheers,
Joel
>> - should the driver handle directly the response to the "Get BT
>> Interface Capabilities" command ?
>
>
> That probably belongs in userspace. The only reason I can think of
> to have it in the driver would be so the host driver can fetch it if the
> BMC userspace is down, but I can't see how that's a good idea.
>
> Hope my wishy-washy answer helps :-).
^ permalink raw reply
* [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed, ast2400-ibt-bmc'
From: Joel Stanley @ 2016-11-10 2:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2278270.0oJqDfoDd9@wuerfel>
On Thu, Nov 10, 2016 at 2:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday, November 8, 2016 12:15:57 PM CET Corey Minyard wrote:
>> On 11/08/2016 09:52 AM, C?dric Le Goater wrote:
>> > O
>> snip
>>
>> >>>> While we're modifying the binding, should we add a compat string for
>> >>>> the ast2500?
>> >>> Well, if the change in this patch is fine for all, may be we can add
>> >>> the ast2500 compat string in a followup patch ?
>> >> Sounds good to me.
>> > OK. So, how do we proceed with this patch ? Who would include it in its
>> > tree ?
>>
>> I don't have anything for 4.9 at the moment. Arnd, if you have
>> something, can
>> you take this? Otherwise I will.
>>
>> And I guess I should add:
>>
>> Acked-by: Corey Minyard <cminyard@mvista.com>
>
> Thanks, I've added it to my todo folder.
>
> Olof, if you do fixes before I do, please pick up this patch with
> Corey's Ack.
Thank you!
Acked-by: Joel Stanley <joel@jms.id.au>
Cheers,
Joel
^ permalink raw reply
* [PATCH] phy: rockchip-inno-usb2: correct 480MHz output clock stable time
From: wlf @ 2016-11-10 2:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=VC15_QAs7+DOoqCeWrU6-qqnUku2SSPFLOvLanu8xL3g@mail.gmail.com>
Hi Doug,
? 2016?11?10? 04:54, Doug Anderson ??:
> Hi,
>
> On Mon, Nov 7, 2016 at 5:00 AM, William Wu <wulf@rock-chips.com> wrote:
>> We found that the system crashed due to 480MHz output clock of
>> USB2 PHY was unstable after clock had been enabled by gpu module.
>>
>> Theoretically, 1 millisecond is a critical value for 480MHz
>> output clock stable time, so we try to change the delay time
>> to 1.2 millisecond to avoid this issue.
>>
>> Signed-off-by: William Wu <wulf@rock-chips.com>
>> ---
>> drivers/phy/phy-rockchip-inno-usb2.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/phy/phy-rockchip-inno-usb2.c b/drivers/phy/phy-rockchip-inno-usb2.c
>> index ecfd7d1..8f2d2b6 100644
>> --- a/drivers/phy/phy-rockchip-inno-usb2.c
>> +++ b/drivers/phy/phy-rockchip-inno-usb2.c
>> @@ -267,7 +267,7 @@ static int rockchip_usb2phy_clk480m_enable(struct clk_hw *hw)
>> return ret;
>>
>> /* waitting for the clk become stable */
>> - mdelay(1);
>> + udelay(1200);
> Several people who have seen this patch have expressed concern that a
> 1.2 ms delay is pretty long for something that's supposed to be
> "atomic" like a clk_enable(). Consider that someone might call
> clk_enable() while interrupts are disabled and that a 1.2 ms interrupt
> latency is not so great.
>
> It seems like this clock should be moved to be enabled in "prepare"
> and the "enable" should be a no-op. This is a functionality change,
> but I don't think there are any real users for this clock at the
> moment so it should be fine.
>
> (of course, the 1 ms latency that existed before this patch was still
> pretty bad, but ...)
Thanks a lot for your suggestion.
I agree with you. clk_enable() will call spin_lock_irqsave() to disable
interrupt, and we add
more than 1ms in clk_enable may cause big latency.
And according to clk_prepare() description:
In a simple case, clk_prepare can be used instead of clk_enable to
ungate a clk if the
operation may sleep. One example is a clk which is accessed over I2c.
So maybe we can remove the clock to clk_prepare.
Hi Heiko, Frank,
What do you think of it?
Best regards,
wulf
>
> -Doug
>
>
>
^ permalink raw reply
* [PATCH v2 2/6] mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)
From: Joel Stanley @ 2016-11-10 3:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109182630.tg3puvwurgx6iinw@rob-hp-laptop>
On Thu, Nov 10, 2016 at 4:56 AM, Rob Herring <robh@kernel.org> wrote:
> On Thu, Nov 03, 2016 at 01:07:57AM +1030, Andrew Jeffery wrote:
>> The Aspeed SoC Display Controller is presented as a syscon device to
>> arbitrate access by display and pinmux drivers. Video pinmux
>> configuration on fifth generation SoCs depends on bits in both the
>> System Control Unit and the Display Controller.
>>
>> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
>> ---
>> Documentation/devicetree/bindings/mfd/aspeed-gfx.txt | 17 +++++++++++++++++
>
> The register space can't be split to 2 nodes?
Do you mean splitting the GFX IP and enable register into two nodes?
We can't. Pinmux needs to check bit 6 and 7 in GFX064, which is in the
middle the IP block:
GFX060: CRT Control Register I
GFX064: CRT Control Register II
GFX068: CRT Status Register
GFX06C: CRT Misc Setting Register
>> +The Aspeed SoC Display Controller primarily does as its name suggests, but also
>> +participates in pinmux requests on the g5 SoCs. It is therefore considered a
>> +syscon device.
>> +
>> +Required properties:
>> +- compatible: "aspeed,ast2500-gfx", "syscon"
>
> I think perhaps we should drop the syscon here and the driver should
> just register as a syscon.
We want the regmap to be present whenever the GFX driver or pinmux is
loaded. If we register it in pinmux but chose to not build in that
driver, we lack the regmap. Same for the case where a user builds in
the GFX driver and not pinmux. I think this means we want the syscon
compatible string, unless my understanding is wrong?
Cheers,
Joel
^ permalink raw reply
* [PATCH v2 00/30] usb: dwc2: Gadget descriptor DMA and IOT
From: John Youn @ 2016-11-10 3:27 UTC (permalink / raw)
To: linux-arm-kernel
This series implements gadget-side descriptor DMA for the DWC_hsotg
controller.
It also includes support for DWC USB IOT controllers which use the
descriptor DMA mode of operation exclusively. These are two new
device-only USB controller IPs based on DWC_hsotg.
Tested on HAPS platform with:
* HSOTG IP version 3.30a
* FS/LS IOT IP version 1.00a
* HS IOT IP version 1.00a
v2:
* Remove the DMA 'enable' bindings and make them autodetected.
* Add DMA 'disable' bindings to override.
* Separate out commit to add '__packed' attribute.
* Don't print errors on -ENOMEM.
* Remove unnecessary GFP_ATOMIC flags.
* Remove unnecessary patch removing a WARN_ON.
* Reorganize and clarify BNA interrupt.
* Fix issue with enabling STSPHSERCVD interrupt.
Regards,
John
John Youn (4):
usb: dwc2: Deprecate g-use-dma binding
usb: dwc2: Update DMA descriptor structure
usb: dwc2: Make the DMA descriptor structure packed
usb: dwc2: Add bindings to disable gadget DMA modes
Vahram Aharonyan (23):
usb: dwc2: gadget: Add descriptor DMA parameter
usb: dwc2: gadget: Add DMA descriptor status quadlet fields
usb: dwc2: gadget: Add DMA descriptor chains for EP 0
usb: dwc2: host: Rename MAX_DMA_DESC_SIZE to HOST_DMA_NBYTES_LIMIT
usb: dwc2: gadget: Transfer length limit checking for DDMA
usb: dwc2: gadget: Add DDMA chain pointers to dwc2_hsotg_ep structure
usb: dwc2: gadget: Add DDMA chain fill and parse functions
usb: dwc2: gadget: EP 0 specific DDMA programming
usb: dwc2: gadget: DDMA transfer start and complete
usb: dwc2: gadget: Fixes for StsPhseRcvd interrupt
usb: dwc2: gadget: Start DDMA IN status phase in StsPhseRcvd handler
usb: dwc2: gadget: Enable descriptor DMA mode
usb: dwc2: gadget: Add DDMA isoc related fields to dwc2_hsotg_ep
usb: dwc2: gadget: Fill isoc descriptor and start transfer in DDMA
usb: dwc2: gadget: Add completions for DDMA isoc transfers
usb: dwc2: gadget: In DDMA keep incompISOOUT and incompISOIN masked
usb: dwc2: gadget: Add start and complete calls for DDMA ISOC
usb: dwc2: gadget: Enable the BNA interrupt
usb: dwc2: gadget: Adjust ISOC OUT request's actual len for DDMA
usb: dwc2: gadget: For DDMA parse setup only after SetUp interrupt
usb: dwc2: gadget: Correct dwc2_hsotg_ep_stop_xfr() function
usb: dwc2: gadget: Disable enabled HW endpoint in
dwc2_hsotg_ep_disable
usb: dwc2: Add support of dedicated full-speed PHY interface
Vardan Mikayelyan (3):
usb: dwc2: gadget: Add IOT device IDs, configure core accordingly
usb: dwc2: gadget: Program ep0_mps for LS
usb: dwc2: gadget: Add new core parameter for low speed
Documentation/devicetree/bindings/usb/dwc2.txt | 6 +-
arch/arm/boot/dts/rk3036.dtsi | 1 -
arch/arm/boot/dts/rk3288.dtsi | 1 -
arch/arm/boot/dts/rk3xxx.dtsi | 1 -
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 1 -
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 1 -
drivers/usb/dwc2/core.h | 50 +-
drivers/usb/dwc2/gadget.c | 968 ++++++++++++++++++++++---
drivers/usb/dwc2/hcd.c | 12 +-
drivers/usb/dwc2/hcd.h | 2 +-
drivers/usb/dwc2/hcd_ddma.c | 52 +-
drivers/usb/dwc2/hw.h | 48 +-
drivers/usb/dwc2/params.c | 45 +-
drivers/usb/dwc2/pci.c | 1 -
14 files changed, 1023 insertions(+), 166 deletions(-)
--
2.10.0
^ permalink raw reply
* [PATCH v2 01/30] usb: dwc2: Deprecate g-use-dma binding
From: John Youn @ 2016-11-10 3:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1478748145.git.johnyoun@synopsys.com>
This is not needed as the gadget now fully supports DMA and it can
autodetect it. This was initially added because gadget DMA mode was only
partially implemented so could not be automatically enabled.
Signed-off-by: John Youn <johnyoun@synopsys.com>
---
Documentation/devicetree/bindings/usb/dwc2.txt | 4 +++-
arch/arm/boot/dts/rk3036.dtsi | 1 -
arch/arm/boot/dts/rk3288.dtsi | 1 -
arch/arm/boot/dts/rk3xxx.dtsi | 1 -
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 1 -
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 1 -
drivers/usb/dwc2/core.h | 4 +---
drivers/usb/dwc2/params.c | 17 ++++++++++++++---
drivers/usb/dwc2/pci.c | 1 -
9 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
index 9472111..389bb13 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -26,11 +26,13 @@ Refer to phy/phy-bindings.txt for generic phy consumer properties
- dr_mode: shall be one of "host", "peripheral" and "otg"
Refer to usb/generic.txt
- snps,host-dma-disable: disable host DMA mode.
-- g-use-dma: enable dma usage in gadget driver.
- g-rx-fifo-size: size of rx fifo size in gadget mode.
- g-np-tx-fifo-size: size of non-periodic tx fifo size in gadget mode.
- g-tx-fifo-size: size of periodic tx fifo per endpoint (except ep0) in gadget mode.
+Deprecated properties:
+- g-use-dma: gadget DMA mode is automatically detected
+
Example:
usb at 101c0000 {
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index a935523..7c2dc19 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -204,7 +204,6 @@
g-np-tx-fifo-size = <16>;
g-rx-fifo-size = <275>;
g-tx-fifo-size = <256 128 128 64 64 32>;
- g-use-dma;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 17ec2e2..74a749c 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -596,7 +596,6 @@
g-np-tx-fifo-size = <16>;
g-rx-fifo-size = <275>;
g-tx-fifo-size = <256 128 128 64 64 32>;
- g-use-dma;
phys = <&usbphy0>;
phy-names = "usb2-phy";
status = "disabled";
diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
index e15beb3..8fbd3c8 100644
--- a/arch/arm/boot/dts/rk3xxx.dtsi
+++ b/arch/arm/boot/dts/rk3xxx.dtsi
@@ -181,7 +181,6 @@
g-np-tx-fifo-size = <16>;
g-rx-fifo-size = <275>;
g-tx-fifo-size = <256 128 128 64 64 32>;
- g-use-dma;
phys = <&usbphy0>;
phy-names = "usb2-phy";
status = "disabled";
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 17839db..e0ea603 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -747,7 +747,6 @@
clocks = <&sys_ctrl HI6220_USBOTG_HCLK>;
clock-names = "otg";
dr_mode = "otg";
- g-use-dma;
g-rx-fifo-size = <512>;
g-np-tx-fifo-size = <128>;
g-tx-fifo-size = <128 128 128 128 128 128>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 0fcb214..df231c4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -537,7 +537,6 @@
g-np-tx-fifo-size = <16>;
g-rx-fifo-size = <275>;
g-tx-fifo-size = <256 128 128 64 64 32>;
- g-use-dma;
status = "disabled";
};
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index a1075ad..f8c97f5 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -418,9 +418,7 @@ enum dwc2_ep0_state {
* needed.
* 0 - No (default)
* 1 - Yes
- * @g_dma: If true, enables dma usage on the device. This
- * setting is not auto-detected. It must be
- * explicitly enabled (default: false).
+ * @g_dma: Enables gadget dma usage (default: autodetect).
* @g_rx_fifo_size: The periodic rx fifo size for the device, in
* DWORDS from 16-32768 (default: 2048 if
* possible, otherwise autodetect).
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 2eb79e8..74c3728 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -1086,6 +1086,19 @@ static void dwc2_set_param_tx_fifo_sizes(struct dwc2_hsotg *hsotg)
}
}
+static void dwc2_set_gadget_dma(struct dwc2_hsotg *hsotg)
+{
+ struct dwc2_hw_params *hw = &hsotg->hw_params;
+ struct dwc2_core_params *p = &hsotg->params;
+ bool dma_capable = !(hw->arch == GHWCFG2_SLAVE_ONLY_ARCH);
+
+ /* Buffer DMA */
+ dwc2_set_param_bool(hsotg, &p->g_dma,
+ false, "gadget-dma",
+ true, false,
+ dma_capable);
+}
+
/**
* dwc2_set_parameters() - Set all core parameters.
*
@@ -1161,9 +1174,7 @@ static void dwc2_set_parameters(struct dwc2_hsotg *hsotg,
(hsotg->dr_mode == USB_DR_MODE_OTG)) {
dev_dbg(hsotg->dev, "Setting peripheral device properties\n");
- dwc2_set_param_bool(hsotg, &p->g_dma, true, "g-use-dma",
- false, false,
- dma_capable);
+ dwc2_set_gadget_dma(hsotg);
/*
* The values for g_rx_fifo_size (2048) and
diff --git a/drivers/usb/dwc2/pci.c b/drivers/usb/dwc2/pci.c
index b3f3b58..a23329e 100644
--- a/drivers/usb/dwc2/pci.c
+++ b/drivers/usb/dwc2/pci.c
@@ -67,7 +67,6 @@ static int dwc2_pci_quirks(struct pci_dev *pdev, struct platform_device *dwc2)
if (pdev->vendor == PCI_VENDOR_ID_SYNOPSYS &&
pdev->device == PCI_PRODUCT_ID_HAPS_HSOTG) {
struct property_entry properties[] = {
- PROPERTY_ENTRY_BOOL("g-use-dma"),
{ },
};
--
2.10.0
^ permalink raw reply related
* [PATCH] arm64: dts: Add ARM PMU node for exynos7
From: Alim Akhtar @ 2016-11-10 3:30 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds ARM Performance Monitor Unit dt node for exynos7.
PMU provides various statistics on the operation of the CPU and
memory system at runtime, which are very useful when debugging or
profiling code. This enables the same.
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
arch/arm64/boot/dts/exynos/exynos7.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index e0d0d01..53ce4be 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -472,6 +472,14 @@
status = "disabled";
};
+ arm-pmu {
+ compatible = "arm,cortex-a57-pmu", "arm,armv8-pmuv3";
+ interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <GIC_PPI 13
--
1.7.10.4
^ permalink raw reply related
* [v16, 0/7] Fix eSDHC host version register bug
From: Scott Wood @ 2016-11-10 3:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFrcAN_pqgtGaUanfB2zh97zGcL23m5VDtJ3g==NJeRrfA@mail.gmail.com>
On Wed, 2016-11-09 at 19:27 +0100, Ulf Hansson wrote:
> - i2c-list
>
> On 9 November 2016 at 04:14, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> >
> > This patchset is used to fix a host version register bug in the T4240-
> > R1.0-R2.0
> > eSDHC controller. To match the SoC version and revision, 15 previous
> > version
> > patchsets had tried many methods but all of them were rejected by
> > reviewers.
> > Such as
> > ????????- dts compatible method
> > ????????- syscon method
> > ????????- ifdef PPC method
> > ????????- GUTS driver getting SVR method
> > Anrd suggested a soc_device_match method in v10, and this is the only
> > available
> > method left now. This v11 patchset introduces the soc_device_match
> > interface in
> > soc driver.
> >
> > The first four patches of Yangbo are to add the GUTS driver. This is used
> > to
> > register a soc device which contain soc version and revision information.
> > The other three patches introduce the soc_device_match method in soc
> > driver
> > and apply it on esdhc driver to fix this bug.
> >
> > ---
> > Changes for v15:
> > ????????- Dropped patch 'dt: bindings: update Freescale DCFG compatible'
> > ??????????since the work had been done by below patch on ShawnGuo's linux
> > tree.
> > ??????????'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A compatible for
> > SCFG
> > ???????????and DCFG'
> > ????????- Fixed error code issue in guts driver
> > Changes for v16:
> > ????????- Dropped patch 'powerpc/fsl: move mpc85xx.h to include/linux/fsl'
> > ????????- Added a bug-fix patch from Geert
> > ---
> >
> > Arnd Bergmann (1):
> > ? base: soc: introduce soc_device_match() interface
> >
> > Geert Uytterhoeven (1):
> > ? base: soc: Check for NULL SoC device attributes
> >
> > Yangbo Lu (5):
> > ? ARM64: dts: ls2080a: add device configuration node
> > ? dt: bindings: move guts devicetree doc out of powerpc directory
> > ? soc: fsl: add GUTS driver for QorIQ platforms
> > ? MAINTAINERS: add entry for Freescale SoC drivers
> > ? mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> >
> > ?.../bindings/{powerpc => soc}/fsl/guts.txt?????????|???3 +
> > ?MAINTAINERS????????????????????????????????????????|??11 +-
> > ?arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi?????|???6 +
> > ?drivers/base/Kconfig???????????????????????????????|???1 +
> > ?drivers/base/soc.c?????????????????????????????????|??70 ++++++
> > ?drivers/mmc/host/Kconfig???????????????????????????|???1 +
> > ?drivers/mmc/host/sdhci-of-esdhc.c??????????????????|??20 ++
> > ?drivers/soc/Kconfig????????????????????????????????|???3 +-
> > ?drivers/soc/fsl/Kconfig????????????????????????????|??18 ++
> > ?drivers/soc/fsl/Makefile???????????????????????????|???1 +
> > ?drivers/soc/fsl/guts.c?????????????????????????????| 236
> > +++++++++++++++++++++
> > ?include/linux/fsl/guts.h???????????????????????????| 125 ++++++-----
> > ?include/linux/sys_soc.h????????????????????????????|???3 +
> > ?13 files changed, 447 insertions(+), 51 deletions(-)
> > ?rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt
> > (91%)
> > ?create mode 100644 drivers/soc/fsl/Kconfig
> > ?create mode 100644 drivers/soc/fsl/guts.c
> >
> > --
> > 2.1.0.27.g96db324
> >
> Thanks, applied on my mmc tree for next!
>
> I noticed that some DT compatibles weren't documented, according to
> checkpatch. Please fix that asap!
They are documented, in fsl/guts.txt (the file moved in patch 2/7):
> ?- compatible : Should define the compatible device type for
> ???global-utilities.
> ???Possible compatibles:
> ????????"fsl,qoriq-device-config-1.0"
> ????????"fsl,qoriq-device-config-2.0"
> ????????"fsl,<chip>-device-config"
> ????????"fsl,<chip>-guts"
Checkpatch doesn't understand compatibles defined in such a way.
-Scott
^ permalink raw reply
* [v16, 0/7] Fix eSDHC host version register bug
From: Y.B. Lu @ 2016-11-10 4:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478750114.21746.4.camel@buserror.net>
> -----Original Message-----
> From: linux-mmc-owner at vger.kernel.org [mailto:linux-mmc-
> owner at vger.kernel.org] On Behalf Of Scott Wood
> Sent: Thursday, November 10, 2016 11:55 AM
> To: Ulf Hansson; Y.B. Lu
> Cc: linux-mmc; Arnd Bergmann; linuxppc-dev at lists.ozlabs.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; linux-clk; iommu at lists.linux-foundation.org;
> netdev at vger.kernel.org; Greg Kroah-Hartman; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> Subject: Re: [v16, 0/7] Fix eSDHC host version register bug
>
> On Wed, 2016-11-09 at 19:27 +0100, Ulf Hansson wrote:
> > - i2c-list
> >
> > On 9 November 2016 at 04:14, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> > >
> > > This patchset is used to fix a host version register bug in the
> > > T4240-
> > > R1.0-R2.0
> > > eSDHC controller. To match the SoC version and revision, 15 previous
> > > version patchsets had tried many methods but all of them were
> > > rejected by reviewers.
> > > Such as
> > > ????????- dts compatible method
> > > ????????- syscon method
> > > ????????- ifdef PPC method
> > > ????????- GUTS driver getting SVR method Anrd suggested a
> > > soc_device_match method in v10, and this is the only available
> > > method left now. This v11 patchset introduces the soc_device_match
> > > interface in soc driver.
> > >
> > > The first four patches of Yangbo are to add the GUTS driver. This is
> > > used to register a soc device which contain soc version and revision
> > > information.
> > > The other three patches introduce the soc_device_match method in soc
> > > driver and apply it on esdhc driver to fix this bug.
> > >
> > > ---
> > > Changes for v15:
> > > ????????- Dropped patch 'dt: bindings: update Freescale DCFG
> compatible'
> > > ??????????since the work had been done by below patch on ShawnGuo's
> > > linux tree.
> > > ??????????'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A compatible
> > > for SCFG
> > > ???????????and DCFG'
> > > ????????- Fixed error code issue in guts driver Changes for v16:
> > > ????????- Dropped patch 'powerpc/fsl: move mpc85xx.h to
> include/linux/fsl'
> > > ????????- Added a bug-fix patch from Geert
> > > ---
> > >
> > > Arnd Bergmann (1):
> > > ? base: soc: introduce soc_device_match() interface
> > >
> > > Geert Uytterhoeven (1):
> > > ? base: soc: Check for NULL SoC device attributes
> > >
> > > Yangbo Lu (5):
> > > ? ARM64: dts: ls2080a: add device configuration node
> > > ? dt: bindings: move guts devicetree doc out of powerpc directory
> > > ? soc: fsl: add GUTS driver for QorIQ platforms
> > > ? MAINTAINERS: add entry for Freescale SoC drivers
> > > ? mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> > >
> > > ?.../bindings/{powerpc => soc}/fsl/guts.txt?????????|???3 +
> > > ?MAINTAINERS????????????????????????????????????????|??11 +-
> > > ?arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi?????|???6 +
> > > ?drivers/base/Kconfig???????????????????????????????|???1 +
> > > ?drivers/base/soc.c?????????????????????????????????|??70 ++++++
> > > ?drivers/mmc/host/Kconfig???????????????????????????|???1 +
> > > ?drivers/mmc/host/sdhci-of-esdhc.c??????????????????|??20 ++
> > > ?drivers/soc/Kconfig????????????????????????????????|???3 +-
> > > ?drivers/soc/fsl/Kconfig????????????????????????????|??18 ++
> > > ?drivers/soc/fsl/Makefile???????????????????????????|???1 +
> > > ?drivers/soc/fsl/guts.c?????????????????????????????| 236
> > > +++++++++++++++++++++
> > > ?include/linux/fsl/guts.h???????????????????????????| 125
> > > ++++++-----
> > > ?include/linux/sys_soc.h????????????????????????????|???3 +
> > > ?13 files changed, 447 insertions(+), 51 deletions(-)
> > > ?rename Documentation/devicetree/bindings/{powerpc =>
> > > soc}/fsl/guts.txt
> > > (91%)
> > > ?create mode 100644 drivers/soc/fsl/Kconfig
> > > ?create mode 100644 drivers/soc/fsl/guts.c
> > >
> > > --
> > > 2.1.0.27.g96db324
> > >
> > Thanks, applied on my mmc tree for next!
> >
> > I noticed that some DT compatibles weren't documented, according to
> > checkpatch. Please fix that asap!
>
> They are documented, in fsl/guts.txt (the file moved in patch 2/7):
> > ?- compatible : Should define the compatible device type for
> > ???global-utilities.
> > ???Possible compatibles:
> > ????????"fsl,qoriq-device-config-1.0"
> > ????????"fsl,qoriq-device-config-2.0"
> > ????????"fsl,<chip>-device-config"
> > ????????"fsl,<chip>-guts"
>
> Checkpatch doesn't understand compatibles defined in such a way.
[Lu Yangbo-B47093] You're right, Scott. I dropped DT patch 'dt: bindings: update Freescale DCFG compatible '
which fixed un-doc issue since Shaohui had done this on Shawn Guo's tree.
https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h=imx/dt64&id=981034a2bfcaff5c95dafde24d7abfe7f9025c19
Thanks.
>
> -Scott
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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