* [PATCH] PCI: xgene: Remove leftover pci_scan_child_bus() call
From: Lorenzo Pieralisi @ 2017-12-15 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAsHzqv_fYOZTHLWSTSXX=2YziMWcNg15qz1mGaRdyWMa7Hntg@mail.gmail.com>
On Fri, Dec 08, 2017 at 10:32:52AM -0800, Khuong Dinh wrote:
> Hi Lorenzo,
>
> On Tue, Nov 21, 2017 at 7:49 AM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > The changes in commit 9af275be15f7 ("PCI: xgene: Convert PCI scan API to
> > pci_scan_root_bus_bridge()") converted the xgene PCI host driver to
> > the new pci_scan_root_bus_bridge() bus scanning API but erroneously left
> > the existing pci_scan_child_bus() call in place which resulted in duplicate
> > PCI bus enumerations.
> >
> > Remove the leftover pci_scan_child_bus() call to properly complete the API
> > conversion.
> >
> > Fixes: 9af275be15f7 ("PCI: xgene: Convert PCI scan API to pci_scan_root_bus_bridge()")
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Tanmay Inamdar <tinamdar@apm.com>
> > ---
> > drivers/pci/host/pci-xgene.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
> > index 465aa2a..e60c457 100644
> > --- a/drivers/pci/host/pci-xgene.c
> > +++ b/drivers/pci/host/pci-xgene.c
> > @@ -668,7 +668,6 @@ static int xgene_pcie_probe(struct platform_device *pdev)
> >
> > bus = bridge->bus;
> >
> > - pci_scan_child_bus(bus);
> > pci_assign_unassigned_bus_resources(bus);
> > list_for_each_entry(child, &bus->children, node)
> > pcie_bus_configure_settings(child);
> > --
> > 2.9.5
> >
>
> It is good with X-Gene
>
> Tested-by: Khuong Dinh <kdinh@apm.com>
Thank you. Bjorn, I will queue this for v4.16 - I would add a stable tag
since we have v4.13+ kernels scanning the bus twice on xgene, I am not
too happy about this.
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH 07/25] arm: keystone: dts: Remove leading 0x and 0s from bindings notation
From: Nishanth Menon @ 2017-12-15 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215124638.30233-1-malat@debian.org>
On 12/15/2017 06:46 AM, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This will solve as a side effect warning:
>
> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
Acked-by: Nishanth Menon <nm@ti.com>
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 2/8] ARM: dts: keystone*: Use a single soc0 instance
From: Nishanth Menon @ 2017-12-15 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215132102.435-3-nm@ti.com>
Crap.. couple of typos crept in. Apologies - Santosh, if you dont want
to manualy change, I can rebase and repost if you like to any branch
of your choice.
On 12/15/2017 07:20 AM, Nishanth Menon wrote:
> Provide and soc0 node and reference the same to simplify dts. This also
^^ - should have been a
> resolves the following warnings when built with W=1:
> arch/arm/boot/dts/keystone-k2hk-evm.dtb: Warning (unit_address_vs_reg): Node /soc has a reg or ranges property, but no unit name
> arch/arm/boot/dts/keystone-k2l-evm.dtb: Warning (unit_address_vs_reg): Node /soc has a reg or ranges property, but no unit name
> arch/arm/boot/dts/keystone-k2e-evm.dtb: Warning (unit_address_vs_reg): Node /soc has a reg or ranges property, but no unit name
> arch/arm/boot/dts/keystone-k2g-evm.dtb: Warning (unit_address_vs_reg): Node /soc has a reg or ranges property, but no unit name
> arch/arm/boot/dts/keystone-k2g-ice.dtb: Warning (unit_address_vs_reg): Node /soc has a reg or ranges property, but no unit name
>
> NOTE: Though we can reformat files by reducing 1 level of indent due to
> the use of soc0 phandle, we ommit that change to prevent un-necessary
^^ -> omit
> churn in code base.
>
> Reported-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Nishanth Menon <nm@ti.com>
Apologies once again on my oversight.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v3] firmware: qcom: scm: Fix incorrect of_node_put calls in scm_init
From: Loys Ollivier @ 2017-12-15 13:40 UTC (permalink / raw)
To: linux-arm-kernel
When using other platform architectures, in the init of the qcom_scm
driver, of_node_put is called on /firmware if no qcom dt is found.
This results in a kernel error: Bad of_node_put() on /firmware.
These calls to of_node_put from the qcom_scm init are unnecessary as
of_find_matching_node and of_platform_populate are calling it
automatically.
Remove the calls to of_node_put() on fw_np.
Fixes: d0f6fa7ba2d6 ("firmware: qcom: scm: Convert SCM to platform driver")
Suggested-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Loys Ollivier <lollivier@baylibre.com>
---
drivers/firmware/qcom_scm.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index af4c75217ea6..f6d7b7cffe0c 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -632,17 +632,13 @@ static int __init qcom_scm_init(void)
np = of_find_matching_node(fw_np, qcom_scm_dt_match);
- if (!np) {
- of_node_put(fw_np);
+ if (!np)
return -ENODEV;
- }
of_node_put(np);
ret = of_platform_populate(fw_np, qcom_scm_dt_match, NULL, NULL);
- of_node_put(fw_np);
-
if (ret)
return ret;
--
2.7.4
^ permalink raw reply related
* [PATCH 14/25] arm: stm32: dts: Remove leading 0x and 0s from bindings notation
From: Alexandre Torgue @ 2017-12-15 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215124646.30591-1-malat@debian.org>
Hi Mathieu
On 12/15/2017 01:46 PM, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This will solve as a side effect warning:
>
> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
I will merge it in my next pull request for 4.16.
Thanks
Alex
> arch/arm/boot/dts/stm32h743.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/stm32h743.dtsi b/arch/arm/boot/dts/stm32h743.dtsi
> index bbfcbaca0b36..a559d8b6a4a3 100644
> --- a/arch/arm/boot/dts/stm32h743.dtsi
> +++ b/arch/arm/boot/dts/stm32h743.dtsi
> @@ -304,7 +304,7 @@
> };
> };
>
> - vrefbuf: regulator at 58003C00 {
> + vrefbuf: regulator at 58003c00 {
> compatible = "st,stm32-vrefbuf";
> reg = <0x58003C00 0x8>;
> clocks = <&rcc VREF_CK>;
>
^ permalink raw reply
* [PATCH 0/2] Use SPDX-License-Identifier for rockchip devicetree files
From: Philippe Ombredanne @ 2017-12-15 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215114427.32059-1-klaus.goger@theobroma-systems.com>
Klaus,
On Fri, Dec 15, 2017 at 12:44 PM, Klaus Goger
<klaus.goger@theobroma-systems.com> wrote:
> This patch series replaces all the license text in rockchip devicetree
> files text with a proper SPDX-License-Identifier.
> It follows the guidelines submitted[1] by Thomas Gleixner that are not
> yet merged.
>
> These series also fixes the issue with contradicting statements in most
> licenses. The introduction text claims to be GPL or X11[2] but the
> following verbatim copy of the license is actually a MIT[3] license.
> The X11 license includes a advertise clause and trademark information
> related to the X Consortium. As these X Consortium specfic points are
> irrelevant for us we stick with the actuall license text.
>
> [1] https://patchwork.kernel.org/patch/10091607/
> [2] https://spdx.org/licenses/X11.html
> [3] https://spdx.org/licenses/MIT.html
FWIW, the X11 license name was not always something clearly defined.
SPDX calls it clearly MIT which is the most widely accepted name for
the corresponding text. And this is also what we have in Thomas doc
patches that should be the kernel reference.
Also, as a general note, you want to make sure that such as patch set
is not merged by mistake until you have collected an explicit review
or ack from all the copyright holders involved.
May be calling it an "RFC" could be best until you have these acks?
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* [PATCH] perf probe arm64: Fix symbol fixup issues due to ELF type
From: Arnaldo Carvalho de Melo @ 2017-12-15 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214175242.e30450f17f93ad675d968fa3@arm.com>
Em Thu, Dec 14, 2017 at 05:52:42PM -0600, Kim Phillips escreveu:
> On an arm64 machine running a CONFIG_RANDOMIZE_BASE=y kernel, perf
> kernel symbol resolution fails. Debugging saw symsrc_init calling the
> default elf__needs_adjust_symbols() where checks for an ET_DYN (3)
> ehdr.e_type failed when they should have succeeded.
>
> Fix by adopting powerpc version of the weak elf__needs_adjust_symbols()
> function, as done in commit d2332098331f ("perf probe ppc: Fix symbol
> fixup issues due to ELF type").
>
> Prior to this patch, perf test 1 would fail:
Thanks, applied.
- Arnaldo
^ permalink raw reply
* [PATCH 0/2] KVM: arm/arm64: Fix two problems with the arch timer introduced in v4.15-rc1
From: Christoffer Dall @ 2017-12-15 14:16 UTC (permalink / raw)
To: linux-arm-kernel
The first patch solves the problem with the spurious IRQ (which is not a
problem at all and just an artifact of what Jia is writing about), and
it solves the issue of accidentally overwriting the in-memory copy of
the guest state with a disabled timer, leaving the VCPU in the weeds.
The second patch addresses addresses an issue identified when booting
with kvmtool The reason why we didn't see it with QEMU is that QEMU is
so happy to signal its threads in the initial setup phase, that it hides
the bug.
Jia, I'd appreciate your tested-by after having applied both patches on
your platform.
Thanks,
-Christoffer
Christoffer Dall (2):
KVM: arm/arm64: Properly handle arch-timer IRQs after
vtimer_save_state
KVM: arm/arm64: Fix timer enable flow
virt/kvm/arm/arch_timer.c | 27 ++++++++++++++++-----------
1 file changed, 16 insertions(+), 11 deletions(-)
--
2.14.2
^ permalink raw reply
* [PATCH 1/2] KVM: arm/arm64: Properly handle arch-timer IRQs after vtimer_save_state
From: Christoffer Dall @ 2017-12-15 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215141656.25815-1-christoffer.dall@linaro.org>
The recent timer rework was assuming that once the timer was disabled,
we should no longer see any interrupts from the timer. This assumption
turns out to not be true, and instead we have to handle the case when
the timer ISR runs even after the timer has been disabled.
This requires a couple of changes:
First, we should never overwrite the cached guest state of the timer
control register when the ISR runs, because KVM may have disabled its
timers when doing vcpu_put(), even though the guest still had the timer
enabled.
Second, we shouldn't assume that the timer is actually firing just
because we see an interrupt, but we should check the actual state of the
timer in the timer control register to understand if the hardware timer
is really firing or not.
We also add an ISB to vtimer_save_state() to ensure the timer is
actually disabled once we enable interrupts, which should clarify the
intention of the implementation, and reduce the risk of unwanted
interrupts.
Fixes: b103cc3f10c0 ("KVM: arm/arm64: Avoid timer save/restore in vcpu entry/exit")
Reported-by: Marc Zyngier <marc.zyngier@arm.com>
Reported-by: Jia He <hejianet@gmail.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
---
virt/kvm/arm/arch_timer.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index aa9adfafe12b..14c018f990a7 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -92,16 +92,23 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
{
struct kvm_vcpu *vcpu = *(struct kvm_vcpu **)dev_id;
struct arch_timer_context *vtimer;
+ u32 cnt_ctl;
- if (!vcpu) {
- pr_warn_once("Spurious arch timer IRQ on non-VCPU thread\n");
- return IRQ_NONE;
- }
- vtimer = vcpu_vtimer(vcpu);
+ /*
+ * We may see a timer interrupt after vcpu_put() has been called which
+ * sets the CPU's vcpu pointer to NULL, because even though the timer
+ * has been disabled in vtimer_save_state(), the hardware interrupt
+ * signal may not have been retired from the interrupt controller yet.
+ */
+ if (!vcpu)
+ return IRQ_HANDLED;
+ vtimer = vcpu_vtimer(vcpu);
if (!vtimer->irq.level) {
- vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
- if (kvm_timer_irq_can_fire(vtimer))
+ cnt_ctl = read_sysreg_el0(cntv_ctl);
+ cnt_ctl &= ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT |
+ ARCH_TIMER_CTRL_IT_MASK;
+ if (cnt_ctl == (ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT))
kvm_timer_update_irq(vcpu, true, vtimer);
}
@@ -355,6 +362,7 @@ static void vtimer_save_state(struct kvm_vcpu *vcpu)
/* Disable the virtual timer */
write_sysreg_el0(0, cntv_ctl);
+ isb();
vtimer->loaded = false;
out:
--
2.14.2
^ permalink raw reply related
* [PATCH 2/2] KVM: arm/arm64: Fix timer enable flow
From: Christoffer Dall @ 2017-12-15 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215141656.25815-1-christoffer.dall@linaro.org>
When enabling the timer on the first run, we fail to ever restore the
state and mark it as loaded. That means, that in the initial entry to
the VCPU ioctl, unless we exit to userspace for some reason such as a
pending signal, if the guest programs a timer and blocks, we will wait
forever, because we never read back the hardware state (the loaded flag
is not set), and so we think the timer is disabled, and we never
schedule a background soft timer.
The end result? The VCPU blocks forever, and the only solution is to
kill the thread.
Fixes: 4a2c4da1250d ("arm/arm64: KVM: Load the timer state when enabling the timer")
Reported-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
---
virt/kvm/arm/arch_timer.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 14c018f990a7..cc29a8148328 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -846,10 +846,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
no_vgic:
preempt_disable();
timer->enabled = 1;
- if (!irqchip_in_kernel(vcpu->kvm))
- kvm_timer_vcpu_load_user(vcpu);
- else
- kvm_timer_vcpu_load_vgic(vcpu);
+ kvm_timer_vcpu_load(vcpu);
preempt_enable();
return 0;
--
2.14.2
^ permalink raw reply related
* [PATCH v8] arm64: dts: meson-axg: switch uart_ao clock to CLK81
From: Yixun Lan @ 2017-12-15 14:17 UTC (permalink / raw)
To: linux-arm-kernel
Switch the uart_ao pclk to CLK81 since the clock driver is ready.
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
This is a fixup for the previous version
Changes in v8 since [1]
- move clock DT info into soc.dtsi
[1]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005741.html
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 01beb211f442..d1f8043be426 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/axg-clkc.h>
/ {
compatible = "amlogic,meson-axg";
@@ -200,7 +201,7 @@
compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
reg = <0x0 0x3000 0x0 0x18>;
interrupts = <GIC_SPI 193 IRQ_TYPE_EDGE_RISING>;
- clocks = <&xtal>, <&xtal>, <&xtal>;
+ clocks = <&xtal>, <&clkc CLKID_CLK81>, <&xtal>;
clock-names = "xtal", "pclk", "baud";
status = "disabled";
};
@@ -209,7 +210,7 @@
compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
reg = <0x0 0x4000 0x0 0x18>;
interrupts = <GIC_SPI 197 IRQ_TYPE_EDGE_RISING>;
- clocks = <&xtal>, <&xtal>, <&xtal>;
+ clocks = <&xtal>, <&clkc CLKID_CLK81>, <&xtal>;
clock-names = "xtal", "pclk", "baud";
status = "disabled";
};
--
2.15.1
^ permalink raw reply related
* [PATCH v8] arm64: dts: meson-axg: switch uart_ao clock to CLK81
From: Neil Armstrong @ 2017-12-15 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215141741.175985-1-yixun.lan@amlogic.com>
On 15/12/2017 15:17, Yixun Lan wrote:
> Switch the uart_ao pclk to CLK81 since the clock driver is ready.
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>
> ---
> This is a fixup for the previous version
>
> Changes in v8 since [1]
> - move clock DT info into soc.dtsi
>
> [1]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005741.html
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index 01beb211f442..d1f8043be426 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -7,6 +7,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/axg-clkc.h>
>
> / {
> compatible = "amlogic,meson-axg";
> @@ -200,7 +201,7 @@
> compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
> reg = <0x0 0x3000 0x0 0x18>;
> interrupts = <GIC_SPI 193 IRQ_TYPE_EDGE_RISING>;
> - clocks = <&xtal>, <&xtal>, <&xtal>;
> + clocks = <&xtal>, <&clkc CLKID_CLK81>, <&xtal>;
> clock-names = "xtal", "pclk", "baud";
> status = "disabled";
> };
> @@ -209,7 +210,7 @@
> compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
> reg = <0x0 0x4000 0x0 0x18>;
> interrupts = <GIC_SPI 197 IRQ_TYPE_EDGE_RISING>;
> - clocks = <&xtal>, <&xtal>, <&xtal>;
> + clocks = <&xtal>, <&clkc CLKID_CLK81>, <&xtal>;
> clock-names = "xtal", "pclk", "baud";
> status = "disabled";
> };
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* [PATCH] arch/arm64: elfcorehdr should be the first allocation
From: Poonam Aggrwal @ 2017-12-15 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213104640.GD28046@linaro.org>
Thanks Takahiro and Will,
Please find responses below.
Regards
Poonam
> -----Original Message-----
> From: AKASHI Takahiro [mailto:takahiro.akashi at linaro.org]
> Sent: Wednesday, December 13, 2017 4:17 PM
> To: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> Cc: Will Deacon <will.deacon@arm.com>; Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com>; linux-arm-kernel at lists.infradead.org;
> Poonam Aggrwal <poonam.aggrwal@nxp.com>; G.h. Gao
> <guanhua.gao@nxp.com>; james.morse at arm.com
> Subject: Re: [PATCH] arch/arm64: elfcorehdr should be the first allocation
>
> On Mon, Dec 11, 2017 at 02:07:14PM +0000, Will Deacon wrote:
> > On Mon, Dec 11, 2017 at 11:03:32AM +0530, Prabhakar Kushwaha wrote:
> > > From: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> > >
> > > elfcorehdr_addr is assigned by kexec-utils and device tree of dump
> > > kernel is fixed in chosen node with parameter "linux,elfcorehdr".
> > > So, memory should be first reserved for elfcorehdr, otherwise
> > > overlaps may happen with other memory allocations which were done
> > > before the allocation of elcorehdr in the crash kernel
> >
> > What happens in that case? Do you have a crash log we can include in
> > the commit message?
>
> In private discussions with Poonam, he said:
> | The overlap here I observed was for the reserved-mem areas in the dtb.
> | And they were specific to NXP device.
Thanks Takahiro for providing this information.
Yes the memory overlap happens because when the dump-capture kernel tries to reserve elfcoreheader at the specific address, it finds that the address has already been reserved for some other use by early_init_fdt_scan_reserved_mem().
Based on the "reserved-memory" node entries in the dts file , the overlap is seen to happen with one of the below alocations:
[ 0.000000] Reserved memory: created DMA memory pool at 0x00000000fb800000, size 4 MiB
[ 0.000000] Reserved memory: initialized node qman-fqd, compatible id shared-dma-pool
[ 0.000000] Reserved memory: created DMA memory pool at 0x00000000f8000000, size 32 MiB
[ 0.000000] Reserved memory: initialized node qman-pfdr, compatible id shared-dma-pool
>
> Since I have not got any details since then, I'm not sure whether your patch is
> the way to go.
> (I suspect that we might better fix the issue on kexec-tools side.)
>
I may not have full understanding of kexec-tools, but I am not sure how will kexec tools be able to know what addresses will get assigned for the reserved-memory regions in the device tree.
> Thanks,
> -Takahiro AKASHI
>
> > > Signed-off-by: Guanhua <guanhua.gao@nxp.com>
> > > Signed-off-by: Poonam Aggrwal <poonam.aggrwal@nxp.com>
> > > Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> > > ---
> >
> > Really? How on Earth did you get three people co-developing this patch?
: )Contribution was from all in terms of reproducing, testing on various platforms including the debug experiments. Just wanted to acknowledge the effort.
> >
> > > arch/arm64/mm/init.c | 6 ++++--
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index
> > > 5960bef0170d..551048cfcfff 100644
> > > --- a/arch/arm64/mm/init.c
> > > +++ b/arch/arm64/mm/init.c
> > > @@ -453,6 +453,10 @@ void __init arm64_memblock_init(void)
> > > * Register the kernel text, kernel data, initrd, and initial
> > > * pagetables with memblock.
> > > */
> > > +
> > > + /* make this the first reservation so that there are no chances of
> > > + * overlap */
> > > + reserve_elfcorehdr();
> > > memblock_reserve(__pa_symbol(_text), _end - _text); #ifdef
> > > CONFIG_BLK_DEV_INITRD
> > > if (initrd_start) {
> > > @@ -474,8 +478,6 @@ void __init arm64_memblock_init(void)
> > >
> > > reserve_crashkernel();
> > >
> > > - reserve_elfcorehdr();
> >
> > Why isn't this also a problem for reserve_crashkernel() or any other
> > static reservations?
Thanks, for raising this. Yes looking at the code flow this may also cause a problem, definitely when the start address of the crash kernel is specified in the bootargs. We mostly tested with just the size, so it was an allocation without a specific address.
> >
> > Will
^ permalink raw reply
* [PATCH 1/2] KVM: arm/arm64: Properly handle arch-timer IRQs after vtimer_save_state
From: Marc Zyngier @ 2017-12-15 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215141656.25815-2-christoffer.dall@linaro.org>
On Fri, 15 Dec 2017 14:16:55 +0000,
Christoffer Dall wrote:
>
> The recent timer rework was assuming that once the timer was disabled,
> we should no longer see any interrupts from the timer. This assumption
> turns out to not be true, and instead we have to handle the case when
> the timer ISR runs even after the timer has been disabled.
>
> This requires a couple of changes:
>
> First, we should never overwrite the cached guest state of the timer
> control register when the ISR runs, because KVM may have disabled its
> timers when doing vcpu_put(), even though the guest still had the timer
> enabled.
>
> Second, we shouldn't assume that the timer is actually firing just
> because we see an interrupt, but we should check the actual state of the
> timer in the timer control register to understand if the hardware timer
> is really firing or not.
>
> We also add an ISB to vtimer_save_state() to ensure the timer is
> actually disabled once we enable interrupts, which should clarify the
> intention of the implementation, and reduce the risk of unwanted
> interrupts.
>
> Fixes: b103cc3f10c0 ("KVM: arm/arm64: Avoid timer save/restore in vcpu entry/exit")
> Reported-by: Marc Zyngier <marc.zyngier@arm.com>
> Reported-by: Jia He <hejianet@gmail.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> virt/kvm/arm/arch_timer.c | 22 +++++++++++++++-------
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index aa9adfafe12b..14c018f990a7 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -92,16 +92,23 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
> {
> struct kvm_vcpu *vcpu = *(struct kvm_vcpu **)dev_id;
> struct arch_timer_context *vtimer;
> + u32 cnt_ctl;
>
> - if (!vcpu) {
> - pr_warn_once("Spurious arch timer IRQ on non-VCPU thread\n");
> - return IRQ_NONE;
> - }
> - vtimer = vcpu_vtimer(vcpu);
> + /*
> + * We may see a timer interrupt after vcpu_put() has been called which
> + * sets the CPU's vcpu pointer to NULL, because even though the timer
> + * has been disabled in vtimer_save_state(), the hardware interrupt
> + * signal may not have been retired from the interrupt controller yet.
> + */
> + if (!vcpu)
> + return IRQ_HANDLED;
>
> + vtimer = vcpu_vtimer(vcpu);
> if (!vtimer->irq.level) {
> - vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> - if (kvm_timer_irq_can_fire(vtimer))
> + cnt_ctl = read_sysreg_el0(cntv_ctl);
> + cnt_ctl &= ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT |
> + ARCH_TIMER_CTRL_IT_MASK;
> + if (cnt_ctl == (ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT))
> kvm_timer_update_irq(vcpu, true, vtimer);
> }
>
> @@ -355,6 +362,7 @@ static void vtimer_save_state(struct kvm_vcpu *vcpu)
>
> /* Disable the virtual timer */
> write_sysreg_el0(0, cntv_ctl);
> + isb();
>
> vtimer->loaded = false;
> out:
> --
> 2.14.2
>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
M.
^ permalink raw reply
* arm64: unhandled level 0 translation fault
From: Will Deacon @ 2017-12-15 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWio0KnJc3DQeQyf-MHpDC=tc3cJLNK7MmaL=MdDz45UQ@mail.gmail.com>
On Fri, Dec 15, 2017 at 02:30:00PM +0100, Geert Uytterhoeven wrote:
> On Fri, Dec 15, 2017 at 12:23 PM, Dave Martin <Dave.Martin@arm.com> wrote:
> > The two important differences here seem to be
> >
> > 1) Staging the state via current->thread.fpsimd_state instead of loading
> > directly:
> >
> > - fpsimd_load_state(state);
> > + current->thread.fpsimd_state = *state;
> > + fpsimd_load_state(¤t->thread.fpsimd_state);
>
> The change above introduces the breakage.
I finally managed to reproduce this, but only by using the exact same
compiler as Geert:
https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/x86_64-gcc-4.9.0-nolibc_aarch64-linux.tar.xz
I then reliably see the problem if I run:
# /usr/bin/update-ca-certificates
from Debian Jessie.
Note that my normal toolchain (Linaro 7.1.1 build) works fine and also
if I use the toolchain above but disable CONFIG_ARM64_CRYPTO then things
work too.
So there's some toolchain-specific interaction between this change and the
crypto code...
Will
^ permalink raw reply
* [PATCH 0/2] Use SPDX-License-Identifier for rockchip devicetree files
From: Heiko Stübner @ 2017-12-15 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOFm3uHba4kBD81thpxSpDBsDS4Y5m7cN2jfYt_uT5atdSDmqg@mail.gmail.com>
Am Freitag, 15. Dezember 2017, 14:45:34 CET schrieb Philippe Ombredanne:
> Klaus,
>
> On Fri, Dec 15, 2017 at 12:44 PM, Klaus Goger
>
> <klaus.goger@theobroma-systems.com> wrote:
> > This patch series replaces all the license text in rockchip devicetree
> > files text with a proper SPDX-License-Identifier.
> > It follows the guidelines submitted[1] by Thomas Gleixner that are not
> > yet merged.
> >
> > These series also fixes the issue with contradicting statements in most
> > licenses. The introduction text claims to be GPL or X11[2] but the
> > following verbatim copy of the license is actually a MIT[3] license.
> > The X11 license includes a advertise clause and trademark information
> > related to the X Consortium. As these X Consortium specfic points are
> > irrelevant for us we stick with the actuall license text.
> >
> > [1] https://patchwork.kernel.org/patch/10091607/
> > [2] https://spdx.org/licenses/X11.html
> > [3] https://spdx.org/licenses/MIT.html
>
> FWIW, the X11 license name was not always something clearly defined.
> SPDX calls it clearly MIT which is the most widely accepted name for
> the corresponding text. And this is also what we have in Thomas doc
> patches that should be the kernel reference.
>
> Also, as a general note, you want to make sure that such as patch set
> is not merged by mistake until you have collected an explicit review
> or ack from all the copyright holders involved.
Just for my understanding, is it really necessary to get Acks from _all_
previous contributors?
I see that Thomas patches moving license texts into the kernel itself do not
seem to have landed yet, but when the actual license text does _not_ change
and only its location to a common place inside the kernel sources, it feels
a bit overkill trying to get Acks from _everybody_ that contributed to
Rockchip devicetrees for the last 4 years.
If we would actually want to change the license I would definitly feel
differently, but the license text does not change.
Thanks
Heiko
^ permalink raw reply
* [PATCH 2/2] KVM: arm/arm64: Fix timer enable flow
From: Marc Zyngier @ 2017-12-15 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215141656.25815-3-christoffer.dall@linaro.org>
On Fri, 15 Dec 2017 14:16:56 +0000,
Christoffer Dall wrote:
>
> When enabling the timer on the first run, we fail to ever restore the
> state and mark it as loaded. That means, that in the initial entry to
> the VCPU ioctl, unless we exit to userspace for some reason such as a
> pending signal, if the guest programs a timer and blocks, we will wait
> forever, because we never read back the hardware state (the loaded flag
> is not set), and so we think the timer is disabled, and we never
> schedule a background soft timer.
>
> The end result? The VCPU blocks forever, and the only solution is to
> kill the thread.
>
> Fixes: 4a2c4da1250d ("arm/arm64: KVM: Load the timer state when enabling the timer")
> Reported-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> virt/kvm/arm/arch_timer.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 14c018f990a7..cc29a8148328 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -846,10 +846,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
> no_vgic:
> preempt_disable();
> timer->enabled = 1;
> - if (!irqchip_in_kernel(vcpu->kvm))
> - kvm_timer_vcpu_load_user(vcpu);
> - else
> - kvm_timer_vcpu_load_vgic(vcpu);
> + kvm_timer_vcpu_load(vcpu);
> preempt_enable();
>
> return 0;
> --
> 2.14.2
>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
M.
^ permalink raw reply
* [PATCH v2 3/4] dt-bindings: opp: Introduce ti-opp-supply bindings
From: Rafael J. Wysocki @ 2017-12-15 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215042528.28715-4-d-gerlach@ti.com>
On Fri, Dec 15, 2017 at 5:25 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
> Document the devicetree bindings that describe Texas Instruments
> opp-supply which allow a platform to describe multiple regulators and
> additional information, such as registers containing data needed to
> program aforementioned regulators.
>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
I need an ACK from Rob on this one.
> ---
> .../bindings/opp/ti-omap5-opp-supply.txt | 63 ++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
>
> diff --git a/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt b/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
> new file mode 100644
> index 000000000000..832346e489a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
> @@ -0,0 +1,63 @@
> +Texas Instruments OMAP compatible OPP supply description
> +
> +OMAP5, DRA7, and AM57 family of SoCs have Class0 AVS eFuse registers which
> +contain data that can be used to adjust voltages programmed for some of their
> +supplies for more efficient operation. This binding provides the information
> +needed to read these values and use them to program the main regulator during
> +an OPP transitions.
> +
> +Also, some supplies may have an associated vbb-supply which is an Adaptive Body
> +Bias regulator which much be transitioned in a specific sequence with regards
> +to the vdd-supply and clk when making an OPP transition. By supplying two
> +regulators to the device that will undergo OPP transitions we can make use
> +of the multi regulator binding that is part of the OPP core described here [1]
> +to describe both regulators needed by the platform.
> +
> +[1] Documentation/devicetree/bindings/opp/opp.txt
> +
> +Required Properties for Device Node:
> +- vdd-supply: phandle to regulator controlling VDD supply
> +- vbb-supply: phandle to regulator controlling Body Bias supply
> + (Usually Adaptive Body Bias regulator)
> +
> +Required Properties for opp-supply node:
> +- compatible: Should be one of:
> + "ti,omap-opp-supply" - basic OPP supply controlling VDD and VBB
> + "ti,omap5-opp-supply" - OMAP5+ optimized voltages in efuse(class0)VDD
> + along with VBB
> + "ti,omap5-core-opp-supply" - OMAP5+ optimized voltages in efuse(class0) VDD
> + but no VBB.
> +- reg: Address and length of the efuse register set for the device (mandatory
> + only for "ti,omap5-opp-supply")
> +- ti,efuse-settings: An array of u32 tuple items providing information about
> + optimized efuse configuration. Each item consists of the following:
> + volt: voltage in uV - reference voltage (OPP voltage)
> + efuse_offseet: efuse offset from reg where the optimized voltage is stored.
> +- ti,absolute-max-voltage-uv: absolute maximum voltage for the OPP supply.
> +
> +Example:
> +
> +/* Device Node (CPU) */
> +cpus {
> + cpu0: cpu at 0 {
> + device_type = "cpu";
> +
> + ...
> +
> + vdd-supply = <&vcc>;
> + vbb-supply = <&abb_mpu>;
> + };
> +};
> +
> +/* OMAP OPP Supply with Class0 registers */
> +opp_supply_mpu: opp_supply at 4a003b20 {
> + compatible = "ti,omap5-opp-supply";
> + reg = <0x4a003b20 0x8>;
> + ti,efuse-settings = <
> + /* uV offset */
> + 1060000 0x0
> + 1160000 0x4
> + 1210000 0x8
> + >;
> + ti,absolute-max-voltage-uv = <1500000>;
> +};
> --
> 2.15.1
>
^ permalink raw reply
* [PATCH v2 2/5] arm64: dts: rockchip: add extcon nodes and enable tcphy.
From: Heiko Stübner @ 2017-12-15 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213103219.1464-2-enric.balletbo@collabora.com>
Am Mittwoch, 13. Dezember 2017, 11:32:16 CET schrieb Enric Balletbo i Serra:
> Enable tcphy and create the cros-ec's extcon node for the USB Type-C port.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
Just for people reading along, with the extcon driver-patch applied,
Enric sent a slightly fixed devicetree series, so we're moving to the v3
patches and ignoring the v2 dts from this series.
Heiko
^ permalink raw reply
* [PATCH v2] ARM64: dts: meson-axg: add the SPICC controller
From: Yixun Lan @ 2017-12-15 14:42 UTC (permalink / raw)
To: linux-arm-kernel
From: Sunny Luo <sunny.luo@amlogic.com>
Add DT info for the SPICC controller which found in
the Amlogic's Meson-AXG SoC.
Signed-off-by: Sunny Luo <sunny.luo@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
Changes int v2 since [1]
- rebase to Kevin's tree, branch v4.16/dt64
- this patch depend on clock & pinctrl DT patch
[1]
http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005495.html
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 93 ++++++++++++++++++++++++++++++
1 file changed, 93 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index d356ce74ad89..d33721005748 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/axg-clkc.h>
/ {
compatible = "amlogic,meson-axg";
@@ -120,6 +121,28 @@
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xffd00000 0x0 0x25000>;
+ spicc0: spi at 13000 {
+ compatible = "amlogic,meson-axg-spicc";
+ reg = <0x0 0x13000 0x0 0x3c>;
+ interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc CLKID_SPICC0>;
+ clock-names = "core";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spicc1: spi at 15000 {
+ compatible = "amlogic,meson-axg-spicc";
+ reg = <0x0 0x15000 0x0 0x3c>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc CLKID_SPICC1>;
+ clock-names = "core";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
uart_A: serial at 24000 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
reg = <0x0 0x24000 0x0 0x14>;
@@ -194,6 +217,76 @@
#gpio-cells = <2>;
gpio-ranges = <&pinctrl_periphs 0 0 86>;
};
+
+ spi0_pins: spi0 {
+ mux {
+ groups = "spi0_miso",
+ "spi0_mosi",
+ "spi0_clk";
+ function = "spi0";
+ };
+ };
+
+ spi0_ss0_pins: spi0_ss0 {
+ mux {
+ groups = "spi0_ss0";
+ function = "spi0";
+ };
+ };
+
+ spi0_ss1_pins: spi0_ss1 {
+ mux {
+ groups = "spi0_ss1";
+ function = "spi0";
+ };
+ };
+
+ spi0_ss2_pins: spi0_ss2 {
+ mux {
+ groups = "spi0_ss2";
+ function = "spi0";
+ };
+ };
+
+
+ spi1_a_pins: spi1_a {
+ mux {
+ groups = "spi1_miso_a",
+ "spi1_mosi_a",
+ "spi1_clk_a";
+ function = "spi1";
+ };
+ };
+
+ spi1_ss0_a_pins: spi1_ss0_a {
+ mux {
+ groups = "spi1_ss0_a";
+ function = "spi1";
+ };
+ };
+
+ spi1_ss1_pins: spi1_ss1 {
+ mux {
+ groups = "spi1_ss1";
+ function = "spi1";
+ };
+ };
+
+ spi1_x_pins: spi1_x {
+ mux {
+ groups = "spi1_miso_x",
+ "spi1_mosi_x",
+ "spi1_clk_x";
+ function = "spi1";
+ };
+ };
+
+ spi1_ss0_x_pins: spi1_ss0_x {
+ mux {
+ groups = "spi1_ss0_x";
+ function = "spi1";
+ };
+ };
};
};
--
2.15.1
^ permalink raw reply related
* [PATCH 0/2] Use SPDX-License-Identifier for rockchip devicetree files
From: Philippe Ombredanne @ 2017-12-15 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21020918.S4038j3A1a@diego>
On Fri, Dec 15, 2017 at 3:28 PM, Heiko St?bner <heiko@sntech.de> wrote:
> Am Freitag, 15. Dezember 2017, 14:45:34 CET schrieb Philippe Ombredanne:
>> Klaus,
>>
>> On Fri, Dec 15, 2017 at 12:44 PM, Klaus Goger
>>
>> <klaus.goger@theobroma-systems.com> wrote:
>> > This patch series replaces all the license text in rockchip devicetree
>> > files text with a proper SPDX-License-Identifier.
>> > It follows the guidelines submitted[1] by Thomas Gleixner that are not
>> > yet merged.
>> >
>> > These series also fixes the issue with contradicting statements in most
>> > licenses. The introduction text claims to be GPL or X11[2] but the
>> > following verbatim copy of the license is actually a MIT[3] license.
>> > The X11 license includes a advertise clause and trademark information
>> > related to the X Consortium. As these X Consortium specfic points are
>> > irrelevant for us we stick with the actuall license text.
>> >
>> > [1] https://patchwork.kernel.org/patch/10091607/
>> > [2] https://spdx.org/licenses/X11.html
>> > [3] https://spdx.org/licenses/MIT.html
>>
>> FWIW, the X11 license name was not always something clearly defined.
>> SPDX calls it clearly MIT which is the most widely accepted name for
>> the corresponding text. And this is also what we have in Thomas doc
>> patches that should be the kernel reference.
>>
>> Also, as a general note, you want to make sure that such as patch set
>> is not merged by mistake until you have collected an explicit review
>> or ack from all the copyright holders involved.
>
> Just for my understanding, is it really necessary to get Acks from _all_
> previous contributors?
>
> I see that Thomas patches moving license texts into the kernel itself do not
> seem to have landed yet, but when the actual license text does _not_ change
> and only its location to a common place inside the kernel sources, it feels
> a bit overkill trying to get Acks from _everybody_ that contributed to
> Rockchip devicetrees for the last 4 years.
>
> If we would actually want to change the license I would definitly feel
> differently, but the license text does not change.
Well you are technically right. But there is a social and politeness
angle to this too. So may be getting the ack of all contributors is
not always needed, but getting it is best and the right to do and at
least getting for the named copyright holders should be there.
That's only only my take: leaving aside any technical legal issue, say
I would be on the receiving end as one of the holder or contributors:
I would find it really great and nice to have my ack requested. And I
would be a dork not to give it. So I like to do to others the same I
would appreciate done to me (within reason, as I sometimes shoot
myself in the foot ;) )
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* [PATCH v2 0/3] ARM: sun8i: a83t: Add support for I2S and I2C
From: Maxime Ripard @ 2017-12-15 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214042350.29469-1-wens@csie.org>
On Thu, Dec 14, 2017 at 12:23:47PM +0800, Chen-Yu Tsai wrote:
> Hi everyone,
>
> This is v2 of my A83T I2S and I2C support series.
>
> Changes since v1:
>
> - Dropped ASoC patch that was merged
> - Added SoC-specific compatible strings for I2C controllers
> - Added Maxime's Acked-by
>
> This series adds support for I2S and I2C on the Allwinner A83T SoC.
> The I2S controllers are similar to the ones found on the A31. However
> the TX FIFO and interrupt status registers were swapped around. This
> seems to be a recurring theme for the audio related hardware blocks.
>
> Patch 1 adds device nodes and default pinmux settings for the I2S
> controllers.
>
> Patch 2 adds device nodes and default pinmux settings for the I2C
> controllers.
Applied both, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171215/a8650e39/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: sun7i: Enable HDMI on pcDuino3 Nano
From: Maxime Ripard @ 2017-12-15 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215085243.17881-1-tuomas@tuxera.com>
On Fri, Dec 15, 2017 at 10:52:43AM +0200, Tuomas Tynkkynen wrote:
> The board has a regular-sized HDMI connector, so enable the display
> the pipeline and HDMI output for it.
>
> Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171215/f389b12e/attachment.sig>
^ permalink raw reply
* [PATCH v2] ARM64: dts: meson-axg: add the SPICC controller
From: Neil Armstrong @ 2017-12-15 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215144217.223593-1-yixun.lan@amlogic.com>
On 15/12/2017 15:42, Yixun Lan wrote:
> From: Sunny Luo <sunny.luo@amlogic.com>
>
> Add DT info for the SPICC controller which found in
> the Amlogic's Meson-AXG SoC.
>
> Signed-off-by: Sunny Luo <sunny.luo@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>
> ---
> Changes int v2 since [1]
> - rebase to Kevin's tree, branch v4.16/dt64
> - this patch depend on clock & pinctrl DT patch
>
> [1]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005495.html
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 93 ++++++++++++++++++++++++++++++
> 1 file changed, 93 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index d356ce74ad89..d33721005748 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -7,6 +7,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/axg-clkc.h>
>
> / {
> compatible = "amlogic,meson-axg";
> @@ -120,6 +121,28 @@
> #size-cells = <2>;
> ranges = <0x0 0x0 0x0 0xffd00000 0x0 0x25000>;
>
> + spicc0: spi at 13000 {
> + compatible = "amlogic,meson-axg-spicc";
> + reg = <0x0 0x13000 0x0 0x3c>;
> + interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clkc CLKID_SPICC0>;
> + clock-names = "core";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
[...]
> +
> + spi1_ss0_x_pins: spi1_ss0_x {
> + mux {
> + groups = "spi1_ss0_x";
> + function = "spi1";
> + };
> + };
> };
> };
>
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* [PATCH v12 1/3] ACPI/IORT: Add msi address regions reservation helper
From: Marc Zyngier @ 2017-12-15 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214160957.13716-2-shameerali.kolothum.thodi@huawei.com>
On Thu, 14 Dec 2017 16:09:55 +0000,
Shameer Kolothum wrote:
>
> On some platforms msi parent address regions have to be excluded from
> normal IOVA allocation in that they are detected and decoded in a HW
> specific way by system components and so they cannot be considered normal
> IOVA address space.
>
> Add a helper function that retrieves ITS address regions - the msi
> parent - through IORT device <-> ITS mappings and reserves it so that
> these regions will not be translated by IOMMU and will be excluded from
> IOVA allocations. The function checks for the smmu model number and
> only applies the msi reservation if the platform requires it.
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
> drivers/acpi/arm64/iort.c | 111 +++++++++++++++++++++++++++++++++++++--
> drivers/irqchip/irq-gic-v3-its.c | 3 +-
> include/linux/acpi_iort.h | 7 ++-
> 3 files changed, 116 insertions(+), 5 deletions(-)
For the ITS part:
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
^ 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