* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Duc Dang @ 2016-12-01 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f4b949c0-f992-b0fb-5f23-f71cb1f9713e@redhat.com>
On Thu, Dec 1, 2016 at 11:17 AM, Jon Masters <jcm@redhat.com> wrote:
> On 12/01/2016 10:08 AM, Mark Salter wrote:
>> On Wed, 2016-11-30 at 15:42 -0800, Duc Dang wrote:
>
>>> +static int xgene_v1_pcie_ecam_init(struct pci_config_window *cfg)
>>> +{
>>> + struct acpi_device *adev = to_acpi_device(cfg->parent);
>>> + struct acpi_pci_root *root = acpi_driver_data(adev);
>>> + struct device *dev = cfg->parent;
>>> + struct xgene_pcie_port *port;
>>> + struct resource *csr;
>>> +
>>> + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
>>> + if (!port)
>>> + return -ENOMEM;
>>> +
>>> + csr = &xgene_v1_csr_res[root->segment];
>>
>> This hard-coded assumption that segment N uses controller N breaks
>> for m400 where segment 0 is using controller 3.
I think the latest firmware released from us a few months back use
segment 3 for PCIe controller 3 in MCFG table.
>
> This seems very fragile. So in addition to Bjorn's comment about not
> trusting firmware provided data for the segment offset in the CSR list,
> you will want to also determine the controller from the ACPI tree. The
> existing code walks the ACPI hierarchy and finds the CSR that way.
> Obviously, the goal is to avoid that in the latest incarnation, but you
> could still determine which controller matches a given device.
Yes, I will look into that more.
>
> Jon.
>
> --
> Computer Architect | Sent from my Fedora powered laptop
>
Regards,
Duc Dang.
^ permalink raw reply
* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Bjorn Helgaas @ 2016-12-01 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480620053.4751.30.camel@redhat.com>
On Thu, Dec 01, 2016 at 02:20:53PM -0500, Mark Salter wrote:
> On Thu, 2016-12-01 at 12:33 -0600, Bjorn Helgaas wrote:
> > On Wed, Nov 30, 2016 at 03:42:53PM -0800, Duc Dang wrote:
> > > +static struct resource xgene_v1_csr_res[] = {
> > > + [0] = DEFINE_RES_MEM_NAMED(0x1f2b0000UL, SZ_64K, "PCIe CSR"),
> > > + [1] = DEFINE_RES_MEM_NAMED(0x1f2c0000UL, SZ_64K, "PCIe CSR"),
> > > + [2] = DEFINE_RES_MEM_NAMED(0x1f2d0000UL, SZ_64K, "PCIe CSR"),
> > > + [3] = DEFINE_RES_MEM_NAMED(0x1f500000UL, SZ_64K, "PCIe CSR"),
> > > + [4] = DEFINE_RES_MEM_NAMED(0x1f510000UL, SZ_64K, "PCIe CSR"),
> > I assume these ranges are not the actual ECAM space, right?
> > If they *were* ECAM, I assume you would have included them in the
> > quirk itself in the mcfg_quirks[] table.
>
> These are base addresses for some RC mmio registers.
> >
> > >
> > > +static int xgene_v1_pcie_ecam_init(struct pci_config_window *cfg)
> > > +{
> > > + struct acpi_device *adev = to_acpi_device(cfg->parent);
> > > + struct acpi_pci_root *root = acpi_driver_data(adev);
> > > + struct device *dev = cfg->parent;
> > > + struct xgene_pcie_port *port;
> > > + struct resource *csr;
> > > +
> > > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > > + if (!port)
> > > + return -ENOMEM;
> > > +
> > > + csr = &xgene_v1_csr_res[root->segment];
> > This makes me nervous because root->segment comes from the ACPI _SEG,
> > and if firmware gives us junk in _SEG, we will reference something in
> > the weeds.
>
> The SoC provide some number of RC bridges, each with a different base
> for some mmio registers. Even if segment is legitimate in MCFG, there
> is still a problem if a platform doesn't use the segment ordering
> implied by the code. But the PNP0A03 _CRS does have this base address
> as the first memory resource, so we could get it from there and not
> have hard-coded addresses and implied ording in the quirk code.
I'm confused. Doesn't the current code treat every item in PNP0A03
_CRS as a window? Do you mean the first resource is handled
differently somehow? The Consumer/Producer bit could allow us to do
this by marking the RC MMIO space as "Consumer", but I didn't think
that strategy was quite working yet.
> I have tested a modified version of these quirks using this to
> get the CSR base and it works on the 3 different platforms I have
> access to.
>
> static int xgene_pcie_get_csr(struct device *dev, struct resource *r)
> {
> struct acpi_device *adev = to_acpi_device(dev);
> unsigned long flags;
> struct list_head list;
> struct resource_entry *entry;
> int ret;
>
> INIT_LIST_HEAD(&list);
> flags = IORESOURCE_MEM;
> ret = acpi_dev_get_resources(adev, &list,
> ?????acpi_dev_filter_resource_type_cb,
> ?????(void *)flags);
> if (ret < 0) {
> dev_err(dev, "failed to parse _CRS, error: %d\n", ret);
> return ret;
> } else if (ret == 0) {
> dev_err(dev, "no memory resources present in _CRS\n");
> return -EINVAL;
> }
>
> entry = list_first_entry(&list, struct resource_entry, node);
> *r = *entry->res;
> acpi_dev_free_resource_list(&list);
> return 0;
> }
The code above is identical to acpi_get_rc_addr(), which is used in
the acpi_get_rc_resources() path by the other quirks. Can you use
that path, too, instead of reimplementing it here?
^ permalink raw reply
* [PATCH v3] KVM: arm/arm64: Access CNTHCTL_EL2 bit fields correctly
From: Jintack Lim @ 2016-12-01 19:32 UTC (permalink / raw)
To: linux-arm-kernel
Current KVM world switch code is unintentionally setting wrong bits to
CNTHCTL_EL2 when E2H == 1, which may allow guest OS to access physical
timer. Bit positions of CNTHCTL_EL2 are changing depending on
HCR_EL2.E2H bit. EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H is
not set, but they are 11th and 10th bits respectively when E2H is set.
In fact, on VHE we only need to set those bits once, not for every world
switch. This is because the host kernel runs in EL2 with HCR_EL2.TGE ==
1, which makes those bits have no effect for the host kernel execution.
So we just set those bits once for guests, and that's it.
Signed-off-by: Jintack Lim <jintack@cs.columbia.edu>
---
v2->v3:
- Perform the initialization including CPU hotplug case.
- Move has_vhe() to asm/virt.h
v1->v2:
- Skip configuring cnthctl_el2 in world switch path on VHE system.
- Write patch based on linux-next.
---
arch/arm/include/asm/virt.h | 5 +++++
arch/arm/kvm/arm.c | 3 +++
arch/arm64/include/asm/virt.h | 10 ++++++++++
include/kvm/arm_arch_timer.h | 1 +
virt/kvm/arm/arch_timer.c | 23 +++++++++++++++++++++++
virt/kvm/arm/hyp/timer-sr.c | 33 +++++++++++++++++++++------------
6 files changed, 63 insertions(+), 12 deletions(-)
diff --git a/arch/arm/include/asm/virt.h b/arch/arm/include/asm/virt.h
index a2e75b8..6dae195 100644
--- a/arch/arm/include/asm/virt.h
+++ b/arch/arm/include/asm/virt.h
@@ -80,6 +80,11 @@ static inline bool is_kernel_in_hyp_mode(void)
return false;
}
+static inline bool has_vhe(void)
+{
+ return false;
+}
+
/* The section containing the hypervisor idmap text */
extern char __hyp_idmap_text_start[];
extern char __hyp_idmap_text_end[];
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 8f92efa..13e54e8 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -1099,6 +1099,9 @@ static void cpu_init_hyp_mode(void *dummy)
__cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
__cpu_init_stage2();
+ if (is_kernel_in_hyp_mode())
+ kvm_timer_init_vhe();
+
kvm_arm_init_debug();
}
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index fea1073..b043cfd 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -47,6 +47,7 @@
#include <asm/ptrace.h>
#include <asm/sections.h>
#include <asm/sysreg.h>
+#include <asm/cpufeature.h>
/*
* __boot_cpu_mode records what mode CPUs were booted in.
@@ -80,6 +81,15 @@ static inline bool is_kernel_in_hyp_mode(void)
return read_sysreg(CurrentEL) == CurrentEL_EL2;
}
+static inline bool has_vhe(void)
+{
+#ifdef CONFIG_ARM64_VHE
+ if (cpus_have_const_cap(ARM64_HAS_VIRT_HOST_EXTN))
+ return true;
+#endif
+ return false;
+}
+
#ifdef CONFIG_ARM64_VHE
extern void verify_cpu_run_el(void);
#else
diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
index dda39d8..2d54903 100644
--- a/include/kvm/arm_arch_timer.h
+++ b/include/kvm/arm_arch_timer.h
@@ -76,4 +76,5 @@ int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu);
+void kvm_timer_init_vhe(void);
#endif
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 17b8fa5..c7c3bfd 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -24,6 +24,7 @@
#include <clocksource/arm_arch_timer.h>
#include <asm/arch_timer.h>
+#include <asm/kvm_hyp.h>
#include <kvm/arm_vgic.h>
#include <kvm/arm_arch_timer.h>
@@ -507,3 +508,25 @@ void kvm_timer_init(struct kvm *kvm)
{
kvm->arch.timer.cntvoff = kvm_phys_timer_read();
}
+
+/*
+ * On VHE system, we only need to configure trap on physical timer and counter
+ * accesses in EL0 and EL1 once, not for every world switch.
+ * The host kernel runs at EL2 with HCR_EL2.TGE == 1,
+ * and this makes those bits have no effect for the host kernel execution.
+ */
+void kvm_timer_init_vhe(void)
+{
+ /* When HCR_EL2.E2H ==1, EL1PCEN and EL1PCTEN are shifted by 10 */
+ u32 cnthctl_shift = 10;
+ u64 val;
+
+ /*
+ * Disallow physical timer access for the guest.
+ * Physical counter access is allowed.
+ */
+ val = read_sysreg(cnthctl_el2);
+ val &= ~(CNTHCTL_EL1PCEN << cnthctl_shift);
+ val |= (CNTHCTL_EL1PCTEN << cnthctl_shift);
+ write_sysreg(val, cnthctl_el2);
+}
diff --git a/virt/kvm/arm/hyp/timer-sr.c b/virt/kvm/arm/hyp/timer-sr.c
index 798866a..63e28dd 100644
--- a/virt/kvm/arm/hyp/timer-sr.c
+++ b/virt/kvm/arm/hyp/timer-sr.c
@@ -35,10 +35,16 @@ void __hyp_text __timer_save_state(struct kvm_vcpu *vcpu)
/* Disable the virtual timer */
write_sysreg_el0(0, cntv_ctl);
- /* Allow physical timer/counter access for the host */
- val = read_sysreg(cnthctl_el2);
- val |= CNTHCTL_EL1PCTEN | CNTHCTL_EL1PCEN;
- write_sysreg(val, cnthctl_el2);
+ /*
+ * We don't need to do this for VHE since the host kernel runs in EL2
+ * with HCR_EL2.TGE ==1, which makes those bits have no impact.
+ */
+ if (!has_vhe()) {
+ /* Allow physical timer/counter access for the host */
+ val = read_sysreg(cnthctl_el2);
+ val |= CNTHCTL_EL1PCTEN | CNTHCTL_EL1PCEN;
+ write_sysreg(val, cnthctl_el2);
+ }
/* Clear cntvoff for the host */
write_sysreg(0, cntvoff_el2);
@@ -50,14 +56,17 @@ void __hyp_text __timer_restore_state(struct kvm_vcpu *vcpu)
struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
u64 val;
- /*
- * Disallow physical timer access for the guest
- * Physical counter access is allowed
- */
- val = read_sysreg(cnthctl_el2);
- val &= ~CNTHCTL_EL1PCEN;
- val |= CNTHCTL_EL1PCTEN;
- write_sysreg(val, cnthctl_el2);
+ /* Those bits are already configured at boot on VHE-system */
+ if (!has_vhe()) {
+ /*
+ * Disallow physical timer access for the guest
+ * Physical counter access is allowed
+ */
+ val = read_sysreg(cnthctl_el2);
+ val &= ~CNTHCTL_EL1PCEN;
+ val |= CNTHCTL_EL1PCTEN;
+ write_sysreg(val, cnthctl_el2);
+ }
if (timer->enabled) {
write_sysreg(kvm->arch.timer.cntvoff, cntvoff_el2);
--
1.9.1
^ permalink raw reply related
* [PATCH v2] KVM: arm/arm64: Access CNTHCTL_EL2 bit fields correctly
From: Jintack Lim @ 2016-12-01 19:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f77698be-d30d-53af-0782-3ef6bea3ba4a@arm.com>
Hi Marc,
On Thu, Dec 1, 2016 at 8:30 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> Hi Jintack,
>
> On 01/12/16 11:38, Jintack Lim wrote:
>> Current KVM world switch code is unintentionally setting wrong bits to
>> CNTHCTL_EL2 when E2H == 1, which may allow guest OS to access physical
>> timer. Bit positions of CNTHCTL_EL2 are changing depending on
>> HCR_EL2.E2H bit. EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H is
>> not set, but they are 11th and 10th bits respectively when E2H is set.
>>
>> In fact, on VHE we only need to set those bits once, not for every world
>> switch. This is because the host kernel runs in EL2 with HCR_EL2.TGE ==
>> 1, which makes those bits have no effect for the host kernel execution.
>> So we just set those bits once for guests, and that's it.
>>
>> Signed-off-by: Jintack Lim <jintack@cs.columbia.edu>
>> ---
>> v2: Skip configuring cnthctl_el2 in world switch path on VHE system.
>> This patch is based on linux-next.
>>
>> ---
>> arch/arm/kvm/arm.c | 1 +
>> include/kvm/arm_arch_timer.h | 1 +
>> virt/kvm/arm/arch_timer.c | 23 ++++++++++++++++++++++
>> virt/kvm/arm/hyp/timer-sr.c | 45 ++++++++++++++++++++++++++++++++------------
>> 4 files changed, 58 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index 8f92efa..38c0645 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -1286,6 +1286,7 @@ static void teardown_hyp_mode(void)
>>
>> static int init_vhe_mode(void)
>> {
>> + on_each_cpu(kvm_timer_init_vhe, NULL, 1);
>
> I'm pretty sure this is not going to work with CPU hotplug, as you only
> perform this once and for all at boot time.
>
> I think it would be better if you called this init function as part of
> cpu_init_hyp_mode().
All right. I'll do that.
>
>> kvm_info("VHE mode initialized successfully\n");
>> return 0;
>> }
>> diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
>> index dda39d8..5853399 100644
>> --- a/include/kvm/arm_arch_timer.h
>> +++ b/include/kvm/arm_arch_timer.h
>> @@ -76,4 +76,5 @@ int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>>
>> void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu);
>>
>> +void kvm_timer_init_vhe(void *dummy);
>> #endif
>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>> index 17b8fa5..7a0d85d7 100644
>> --- a/virt/kvm/arm/arch_timer.c
>> +++ b/virt/kvm/arm/arch_timer.c
>> @@ -24,6 +24,7 @@
>>
>> #include <clocksource/arm_arch_timer.h>
>> #include <asm/arch_timer.h>
>> +#include <asm/kvm_hyp.h>
>>
>> #include <kvm/arm_vgic.h>
>> #include <kvm/arm_arch_timer.h>
>> @@ -507,3 +508,25 @@ void kvm_timer_init(struct kvm *kvm)
>> {
>> kvm->arch.timer.cntvoff = kvm_phys_timer_read();
>> }
>> +
>> +/*
>> + * On VHE system, we only need to configure trap on physical timer and counter
>> + * accesses in EL0 and EL1 once, not for every world switch.
>> + * The host kernel runs at EL2 with HCR_EL2.TGE == 1,
>> + * and this makes those bits have no effect for the host kernel execution.
>> + */
>> +void kvm_timer_init_vhe(void *dummy)
>> +{
>> + /* When HCR_EL2.E2H ==1, EL1PCEN and EL1PCTEN are shifted by 10 */
>> + u32 cnthctl_shift = 10;
>> + u64 val;
>> +
>> + /*
>> + * Disallow physical timer access for the guest.
>> + * Physical counter access is allowed.
>> + */
>> + val = read_sysreg(cnthctl_el2);
>> + val &= ~(CNTHCTL_EL1PCEN << cnthctl_shift);
>> + val |= (CNTHCTL_EL1PCTEN << cnthctl_shift);
>> + write_sysreg(val, cnthctl_el2);
>> +}
>
> If you make this called from cpu_init_hyp_mode(), it will have to be
> guarded with is_kernel_in_hyp_mode().
>
>> diff --git a/virt/kvm/arm/hyp/timer-sr.c b/virt/kvm/arm/hyp/timer-sr.c
>> index 798866a..f7fc957 100644
>> --- a/virt/kvm/arm/hyp/timer-sr.c
>> +++ b/virt/kvm/arm/hyp/timer-sr.c
>> @@ -21,6 +21,18 @@
>>
>> #include <asm/kvm_hyp.h>
>>
>> +#ifdef CONFIG_ARM64
>> +static inline bool has_vhe(void)
>> +{
>> + if (cpus_have_const_cap(ARM64_HAS_VIRT_HOST_EXTN))
>> + return true;
>> +
>> + return false;
>> +}
>> +#else
>> +#define has_vhe() false
>
> Could this now be moved to asm/virt.h, and maybe replace the current
> implementation of is_kernel_in_hyp_mode? The latter may require some
> more hacking around, so I'm not sure this is worth it.
I can move that to asm/virt.h, but I'll leave is_kernel_in_hyp_mode()
as it is because, as you pointed out in another e-mail,
is_kernel_in_hyp_mode() can be used before setting up the CPU
capabilities (e.g. runs_at_el2()). I'll send out v3 soon.
Thanks,
Jintack
>
>> +#endif
>> +
>> /* vcpu is already in the HYP VA space */
>> void __hyp_text __timer_save_state(struct kvm_vcpu *vcpu)
>> {
>> @@ -35,10 +47,16 @@ void __hyp_text __timer_save_state(struct kvm_vcpu *vcpu)
>> /* Disable the virtual timer */
>> write_sysreg_el0(0, cntv_ctl);
>>
>> - /* Allow physical timer/counter access for the host */
>> - val = read_sysreg(cnthctl_el2);
>> - val |= CNTHCTL_EL1PCTEN | CNTHCTL_EL1PCEN;
>> - write_sysreg(val, cnthctl_el2);
>> + /*
>> + * We don't need to do this for VHE since the host kernel runs in EL2
>> + * with HCR_EL2.TGE ==1, which makes those bits have no impact.
>> + */
>> + if (!has_vhe()) {
>> + /* Allow physical timer/counter access for the host */
>> + val = read_sysreg(cnthctl_el2);
>> + val |= CNTHCTL_EL1PCTEN | CNTHCTL_EL1PCEN;
>> + write_sysreg(val, cnthctl_el2);
>> + }
>>
>> /* Clear cntvoff for the host */
>> write_sysreg(0, cntvoff_el2);
>> @@ -50,14 +68,17 @@ void __hyp_text __timer_restore_state(struct kvm_vcpu *vcpu)
>> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> u64 val;
>>
>> - /*
>> - * Disallow physical timer access for the guest
>> - * Physical counter access is allowed
>> - */
>> - val = read_sysreg(cnthctl_el2);
>> - val &= ~CNTHCTL_EL1PCEN;
>> - val |= CNTHCTL_EL1PCTEN;
>> - write_sysreg(val, cnthctl_el2);
>> + /* Those bits are already configured at boot on VHE-system */
>> + if (!has_vhe()) {
>> + /*
>> + * Disallow physical timer access for the guest
>> + * Physical counter access is allowed
>> + */
>> + val = read_sysreg(cnthctl_el2);
>> + val &= ~CNTHCTL_EL1PCEN;
>> + val |= CNTHCTL_EL1PCTEN;
>> + write_sysreg(val, cnthctl_el2);
>> + }
>>
>> if (timer->enabled) {
>> write_sysreg(kvm->arch.timer.cntvoff, cntvoff_el2);
>>
>
> Otherwise, this looks good, and the generated code is quite nice.
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
>
^ permalink raw reply
* [PATCH] clk: bcm2835: Avoid overwriting the div info when disabling a pll_div clk
From: Boris Brezillon @ 2016-12-01 19:27 UTC (permalink / raw)
To: linux-arm-kernel
bcm2835_pll_divider_off() is resetting the divider field in the A2W reg
to zero when disabling the clock.
Make sure we preserve this value by reading the previous a2w_reg value
first and ORing the result with A2W_PLL_CHANNEL_DISABLE.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")
Cc: <stable@vger.kernel.org>
---
drivers/clk/bcm/clk-bcm2835.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 836d07550be3..2acaa77ad482 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -751,7 +751,9 @@ static void bcm2835_pll_divider_off(struct clk_hw *hw)
cprman_write(cprman, data->cm_reg,
(cprman_read(cprman, data->cm_reg) &
~data->load_mask) | data->hold_mask);
- cprman_write(cprman, data->a2w_reg, A2W_PLL_CHANNEL_DISABLE);
+ cprman_write(cprman, data->a2w_reg,
+ cprman_read(cprman, data->a2w_reg) |
+ A2W_PLL_CHANNEL_DISABLE);
spin_unlock(&cprman->regs_lock);
}
--
2.7.4
^ permalink raw reply related
* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Jon Masters @ 2016-12-01 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480620053.4751.30.camel@redhat.com>
On 12/01/2016 02:20 PM, Mark Salter wrote:
> On Thu, 2016-12-01 at 12:33 -0600, Bjorn Helgaas wrote:
>>> + csr = &xgene_v1_csr_res[root->segment];
>> This makes me nervous because root->segment comes from the ACPI _SEG,
>> and if firmware gives us junk in _SEG, we will reference something in
>> the weeds.
>
> The SoC provide some number of RC bridges, each with a different base
> for some mmio registers. Even if segment is legitimate in MCFG, there
> is still a problem if a platform doesn't use the segment ordering
> implied by the code. But the PNP0A03 _CRS does have this base address
> as the first memory resource, so we could get it from there and not
> have hard-coded addresses and implied ording in the quirk code.
>
> I have tested a modified version of these quirks using this to
> get the CSR base and it works on the 3 different platforms I have
> access to.
>
> static int xgene_pcie_get_csr(struct device *dev, struct resource *r)
> {
> struct acpi_device *adev = to_acpi_device(dev);
> unsigned long flags;
> struct list_head list;
> struct resource_entry *entry;
> int ret;
>
> INIT_LIST_HEAD(&list);
> flags = IORESOURCE_MEM;
> ret = acpi_dev_get_resources(adev, &list,
> acpi_dev_filter_resource_type_cb,
> (void *)flags);
> if (ret < 0) {
> dev_err(dev, "failed to parse _CRS, error: %d\n", ret);
> return ret;
> } else if (ret == 0) {
> dev_err(dev, "no memory resources present in _CRS\n");
> return -EINVAL;
> }
>
> entry = list_first_entry(&list, struct resource_entry, node);
> *r = *entry->res;
> acpi_dev_free_resource_list(&list);
> return 0;
> }
This seems a lot safer. At some point trusting firmware to provide the
correct _CRS for the RC in use is better than hard coding for every
possible implementation configuration of an X-Gene SoC.
Jon.
--
Computer Architect | Sent from my Fedora powered laptop
^ permalink raw reply
* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Mark Salter @ 2016-12-01 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201183350.GF30746@bhelgaas-glaptop.roam.corp.google.com>
On Thu, 2016-12-01 at 12:33 -0600, Bjorn Helgaas wrote:
> Hi Duc,
>
> On Wed, Nov 30, 2016 at 03:42:53PM -0800, Duc Dang wrote:
> >
> > PCIe controllers in X-Gene SoCs is not ECAM compliant: software
> > needs to configure additional controller's register to address
> > device at bus:dev:function.
> >
> > The quirk will only be applied for X-Gene PCIe MCFG table with
> > OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).
> >
> > The quirk declares the X-Gene PCIe controller register space as 64KB
> > fixed memory resource with name "PCIe CSR". This name will be showed
> > next to the resource range in the output of "cat /proc/iomem".
> >
> > Signed-off-by: Duc Dang <dhdang@apm.com>
> > ---
> > v3:
> > ? - Rebase on top of pci/ecam-v6 tree.
> > ? - Use DEFINE_RES_MEM_NAMED to declare controller register space
> > ? with name "PCIe CSR"
> > v2:
> > ? RFC v2: https://patchwork.ozlabs.org/patch/686846/
> > v1:
> > ? RFC v1: https://patchwork.kernel.org/patch/9337115/
> >
> > ?drivers/acpi/pci_mcfg.c??????|??31 ++++++++
> > ?drivers/pci/host/pci-xgene.c | 165 ++++++++++++++++++++++++++++++++++++++++++-
> > ?include/linux/pci-ecam.h?????|???7 ++
> > ?3 files changed, 200 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> > index ac21db3..eb6125b 100644
> > --- a/drivers/acpi/pci_mcfg.c
> > +++ b/drivers/acpi/pci_mcfg.c
> > @@ -57,6 +57,37 @@ struct mcfg_fixup {
> > ? { "QCOM??", "QDF2432 ", 1, 5, MCFG_BUS_ANY, &pci_32b_ops },
> > ? { "QCOM??", "QDF2432 ", 1, 6, MCFG_BUS_ANY, &pci_32b_ops },
> > ? { "QCOM??", "QDF2432 ", 1, 7, MCFG_BUS_ANY, &pci_32b_ops },
> > +
> > +#ifdef CONFIG_PCI_XGENE
> As you've no doubt noticed, I'm proposing to add these quirks without
> CONFIG_PCI_XGENE, so we don't have to select each device when building
> a generic ACPI kernel.
>
> I'm also proposing some Kconfig and Makefile changes so we don't build
> the platform driver part in a generic ACPI kernel (unless we *also*
> explicitly select the platform driver).
>
> Here's an example:
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=f80edf4d6c05
>
> >
> > +#define XGENE_V1_ECAM_MCFG(rev, seg) \
> > + {"APM???", "XGENE???", rev, seg, MCFG_BUS_ANY, \
> > + &xgene_v1_pcie_ecam_ops }
> > +#define XGENE_V2_1_ECAM_MCFG(rev, seg) \
> > + {"APM???", "XGENE???", rev, seg, MCFG_BUS_ANY, \
> > + &xgene_v2_1_pcie_ecam_ops }
> > +#define XGENE_V2_2_ECAM_MCFG(rev, seg) \
> > + {"APM???", "XGENE???", rev, seg, MCFG_BUS_ANY, \
> > + &xgene_v2_2_pcie_ecam_ops }
> > +
> > + /* X-Gene SoC with v1 PCIe controller */
> > + XGENE_V1_ECAM_MCFG(1, 0),
> > + XGENE_V1_ECAM_MCFG(1, 1),
> >
> > @@ -64,6 +66,7 @@
> > ?/* PCIe IP version */
> > ?#define XGENE_PCIE_IP_VER_UNKN 0
> > ?#define XGENE_PCIE_IP_VER_1 1
> > +#define XGENE_PCIE_IP_VER_2 2
> This isn't used anywhere, which makes me wonder whether it's worth
> keeping it.
>
> >
> > ?static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
> > ?{
> > - struct xgene_pcie_port *port = bus->sysdata;
> > + struct pci_config_window *cfg;
> > + struct xgene_pcie_port *port;
> > +
> > + if (acpi_disabled)
> > + port = bus->sysdata;
> > + else {
> > + cfg = bus->sysdata;
> > + port = cfg->priv;
> > + }
> I would really, really like to figure out a way to get rid of these
> "if (acpi_disabled)" checks sprinkled through here.??Is there any way
> we can set up bus->sysdata to be the same, regardless of whether we're
> using this as a platform driver or an ACPI quirk?
>
> >
> > +#ifdef CONFIG_ACPI
> You've probably noticed that I've been using
>
> ? #if defined(CONFIG_ACPI) && defined(CONFIG_PCI_QUIRKS)
>
> in this situation, mostly to make it clear that this is part of a
> workaround.??I don't want people to blindly copy this stuff without
> realizing that it's a workaround for a hardware issue.
>
> >
> > +static struct resource xgene_v1_csr_res[] = {
> > + [0] = DEFINE_RES_MEM_NAMED(0x1f2b0000UL, SZ_64K, "PCIe CSR"),
> > + [1] = DEFINE_RES_MEM_NAMED(0x1f2c0000UL, SZ_64K, "PCIe CSR"),
> > + [2] = DEFINE_RES_MEM_NAMED(0x1f2d0000UL, SZ_64K, "PCIe CSR"),
> > + [3] = DEFINE_RES_MEM_NAMED(0x1f500000UL, SZ_64K, "PCIe CSR"),
> > + [4] = DEFINE_RES_MEM_NAMED(0x1f510000UL, SZ_64K, "PCIe CSR"),
> I assume these ranges are not the actual ECAM space, right?
> If they *were* ECAM, I assume you would have included them in the
> quirk itself in the mcfg_quirks[] table.
These are base addresses for some RC mmio registers.
>
> >
> > +static int xgene_v1_pcie_ecam_init(struct pci_config_window *cfg)
> > +{
> > + struct acpi_device *adev = to_acpi_device(cfg->parent);
> > + struct acpi_pci_root *root = acpi_driver_data(adev);
> > + struct device *dev = cfg->parent;
> > + struct xgene_pcie_port *port;
> > + struct resource *csr;
> > +
> > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > + if (!port)
> > + return -ENOMEM;
> > +
> > + csr = &xgene_v1_csr_res[root->segment];
> This makes me nervous because root->segment comes from the ACPI _SEG,
> and if firmware gives us junk in _SEG, we will reference something in
> the weeds.
The SoC provide some number of RC bridges, each with a different base
for some mmio registers. Even if segment is legitimate in MCFG, there
is still a problem if a platform doesn't use the segment ordering
implied by the code. But the PNP0A03 _CRS does have this base address
as the first memory resource, so we could get it from there and not
have hard-coded addresses and implied ording in the quirk code.
I have tested a modified version of these quirks using this to
get the CSR base and it works on the 3 different platforms I have
access to.
static int xgene_pcie_get_csr(struct device *dev, struct resource *r)
{
struct acpi_device *adev = to_acpi_device(dev);
unsigned long flags;
struct list_head list;
struct resource_entry *entry;
int ret;
INIT_LIST_HEAD(&list);
flags = IORESOURCE_MEM;
ret = acpi_dev_get_resources(adev, &list,
?????acpi_dev_filter_resource_type_cb,
?????(void *)flags);
if (ret < 0) {
dev_err(dev, "failed to parse _CRS, error: %d\n", ret);
return ret;
} else if (ret == 0) {
dev_err(dev, "no memory resources present in _CRS\n");
return -EINVAL;
}
entry = list_first_entry(&list, struct resource_entry, node);
*r = *entry->res;
acpi_dev_free_resource_list(&list);
return 0;
}
>
> >
> > + port->csr_base = devm_ioremap_resource(dev, csr);
> > + if (IS_ERR(port->csr_base)) {
> > + kfree(port);
> > + return -ENOMEM;
> > + }
> > +
> > + port->cfg_base = cfg->win;
> > + port->version = XGENE_PCIE_IP_VER_1;
> > +
> > + cfg->priv = port;
> All these init functions are almost identical.??Can we factor this out
> by having wrappers that do nothing more than pass in the table and
> version, and put the kzalloc and ioremap in a shared back-end?
>
> We're so close I can taste it!??I can't wait to see all this work come
> to fruition.
>
> Bjorn
^ permalink raw reply
* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Jon Masters @ 2016-12-01 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480604901.4751.17.camel@redhat.com>
On 12/01/2016 10:08 AM, Mark Salter wrote:
> On Wed, 2016-11-30 at 15:42 -0800, Duc Dang wrote:
>> +static int xgene_v1_pcie_ecam_init(struct pci_config_window *cfg)
>> +{
>> + struct acpi_device *adev = to_acpi_device(cfg->parent);
>> + struct acpi_pci_root *root = acpi_driver_data(adev);
>> + struct device *dev = cfg->parent;
>> + struct xgene_pcie_port *port;
>> + struct resource *csr;
>> +
>> + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
>> + if (!port)
>> + return -ENOMEM;
>> +
>> + csr = &xgene_v1_csr_res[root->segment];
>
> This hard-coded assumption that segment N uses controller N breaks
> for m400 where segment 0 is using controller 3.
This seems very fragile. So in addition to Bjorn's comment about not
trusting firmware provided data for the segment offset in the CSR list,
you will want to also determine the controller from the ACPI tree. The
existing code walks the ACPI hierarchy and finds the CSR that way.
Obviously, the goal is to avoid that in the latest incarnation, but you
could still determine which controller matches a given device.
Jon.
--
Computer Architect | Sent from my Fedora powered laptop
^ permalink raw reply
* [PATCHv4 08/10] mm/kasan: Switch to using __pa_symbol and lm_alias
From: Laura Abbott @ 2016-12-01 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2f3ac043-c4cc-5c5a-8ac7-1396b6bb193f@virtuozzo.com>
On 12/01/2016 03:36 AM, Andrey Ryabinin wrote:
> On 11/29/2016 09:55 PM, Laura Abbott wrote:
>> __pa_symbol is the correct API to find the physical address of symbols.
>> Switch to it to allow for debugging APIs to work correctly.
>
> But __pa() is correct for symbols. I see how __pa_symbol() might be a little
> faster than __pa(), but there is nothing wrong in using __pa() on symbols.
>
>> Other
>> functions such as p*d_populate may call __pa internally. Ensure that the
>> address passed is in the linear region by calling lm_alias.
>
> Why it should be linear mapping address? __pa() translates kernel image address just fine.
> This lm_alias() only obfuscates source code. Generated code is probably worse too.
>
>
This is part of adding CONFIG_DEBUG_VIRTUAL for arm64. We want to
differentiate between __pa and __pa_symbol to enforce stronger
virtual checks and have __pa only be for linear map addresses.
Thanks,
Laura
^ permalink raw reply
* [PATCH v3 3/3] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: kbuild test robot @ 2016-12-01 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e193572d7746e6f6b8666da7ac0f54031fed5214.1480467185.git.stillcompiling@gmail.com>
Hi Joshua,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.9-rc7]
[cannot apply to next-20161201]
[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/Joshua-Clayton/lib-add-bitrev8x4/20161202-013521
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': unknown attribute
>> drivers/fpga/cyclone-ps-spi.c:93:33: sparse: incompatible types in comparison expression (different type sizes)
In file included from include/linux/delay.h:10:0,
from drivers/fpga/cyclone-ps-spi.c:14:
drivers/fpga/cyclone-ps-spi.c: In function 'cyclonespi_write':
include/linux/kernel.h:739:16: warning: comparison of distinct pointer types lacks a cast
(void) (&min1 == &min2); \
^
include/linux/kernel.h:742:2: note: in expansion of macro '__min'
__min(typeof(x), typeof(y), \
^~~~~
drivers/fpga/cyclone-ps-spi.c:93:19: note: in expansion of macro 'min'
size_t stride = min(fw_data_end - fw_data, SZ_4K);
^~~
vim +93 drivers/fpga/cyclone-ps-spi.c
77 /* set buffer to lsb first */
78 while (fw32 < fw_end) {
79 *fw32 = bitrev8x4(*fw32);
80 fw32++;
81 }
82 }
83
84 static int cyclonespi_write(struct fpga_manager *mgr, const char *buf,
85 size_t count)
86 {
87 struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
88 const char *fw_data = buf;
89 const char *fw_data_end = fw_data + count;
90
91 while (fw_data < fw_data_end) {
92 int ret;
> 93 size_t stride = min(fw_data_end - fw_data, SZ_4K);
94
95 rev_buf((void *)fw_data, stride);
96 ret = spi_write(conf->spi, fw_data, stride);
97 if (ret) {
98 dev_err(&mgr->dev, "spi error in firmware write: %d\n",
99 ret);
100 return ret;
101 }
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH dt V2] ARM: BCM5301X: Enable UART by default for BCM4708(1), BCM4709(4) & BCM53012
From: Jon Mason @ 2016-12-01 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201174051.4965-1-zajec5@gmail.com>
On Thu, Dec 01, 2016 at 06:40:51PM +0100, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal@milecki.pl>
>
> Every device tested so far got UART0 (at 0x18000300) working as serial
> console. It's most likely part of reference design and all vendors use
> it that way.
>
> It seems to be easier to enable it by default and just disable it if we
> ever see a device with different hardware design.
>
> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
Looks good to me!
Acked-by: Jon Mason <jon.mason@broadcom.com>
> ---
> V2: Update bcm94708.dts bcm94709.dts bcm953012er.dts & bcm953012k.dts
> ---
> arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts | 4 ----
> arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts | 4 ----
> arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts | 4 ----
> arch/arm/boot/dts/bcm4708-netgear-r6250.dts | 4 ----
> arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts | 4 ----
> arch/arm/boot/dts/bcm4708.dtsi | 4 ++++
> arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 4 ----
> arch/arm/boot/dts/bcm47081.dtsi | 4 ++++
> arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 4 ----
> arch/arm/boot/dts/bcm4709-netgear-r8000.dts | 4 ----
> arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts | 4 ----
> arch/arm/boot/dts/bcm4709.dtsi | 1 +
> arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 4 ----
> arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts | 4 ----
> arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 4 ----
> arch/arm/boot/dts/bcm47094.dtsi | 1 +
> arch/arm/boot/dts/bcm94708.dts | 4 ----
> arch/arm/boot/dts/bcm94709.dts | 4 ----
> arch/arm/boot/dts/bcm953012er.dts | 4 ----
> arch/arm/boot/dts/bcm953012k.dts | 1 -
> 20 files changed, 10 insertions(+), 61 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> index 9cb186e..d49afec0 100644
> --- a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> +++ b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> @@ -136,10 +136,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &usb2 {
> vcc-gpio = <&chipcommon 9 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts b/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
> index 35e6ed6..f591b0f 100644
> --- a/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
> +++ b/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
> @@ -55,10 +55,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &spi_nor {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts b/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
> index 1c7e53d..50d65d8 100644
> --- a/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
> +++ b/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
> @@ -56,10 +56,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &spi_nor {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> index 8ce39d5..8519548 100644
> --- a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> +++ b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> @@ -83,10 +83,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &usb3 {
> vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> index 70f4bb9..74cfcd3 100644
> --- a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> +++ b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> @@ -119,10 +119,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &spi_nor {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/bcm4708.dtsi b/arch/arm/boot/dts/bcm4708.dtsi
> index eed4dd1..d0eec09 100644
> --- a/arch/arm/boot/dts/bcm4708.dtsi
> +++ b/arch/arm/boot/dts/bcm4708.dtsi
> @@ -34,3 +34,7 @@
> };
>
> };
> +
> +&uart0 {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> index a9c8def..2922536 100644
> --- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> +++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> @@ -122,7 +122,3 @@
> };
> };
> };
> -
> -&uart0 {
> - status = "okay";
> -};
> diff --git a/arch/arm/boot/dts/bcm47081.dtsi b/arch/arm/boot/dts/bcm47081.dtsi
> index f720012..c5f7619 100644
> --- a/arch/arm/boot/dts/bcm47081.dtsi
> +++ b/arch/arm/boot/dts/bcm47081.dtsi
> @@ -24,3 +24,7 @@
> };
> };
> };
> +
> +&uart0 {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> index fd38d2a..0225d82 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> @@ -100,7 +100,3 @@
> };
> };
> };
> -
> -&uart0 {
> - status = "okay";
> -};
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> index 92f8a72..56d38a3 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> @@ -107,10 +107,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &usb2 {
> vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts b/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
> index 9a92c24..c67bfaa 100644
> --- a/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
> +++ b/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
> @@ -97,10 +97,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &usb2 {
> vcc-gpio = <&chipcommon 13 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/arch/arm/boot/dts/bcm4709.dtsi b/arch/arm/boot/dts/bcm4709.dtsi
> index f039765..c645fea 100644
> --- a/arch/arm/boot/dts/bcm4709.dtsi
> +++ b/arch/arm/boot/dts/bcm4709.dtsi
> @@ -8,4 +8,5 @@
>
> &uart0 {
> clock-frequency = <125000000>;
> + status = "okay";
> };
> diff --git a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> index 661348d..7fb9270 100644
> --- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> +++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> @@ -105,10 +105,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &usb3 {
> vcc-gpio = <&chipcommon 18 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
> index 169b35f..2f4a651 100644
> --- a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
> +++ b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
> @@ -98,10 +98,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &usb3 {
> vcc-gpio = <&chipcommon 18 GPIO_ACTIVE_HIGH>;
> };
> diff --git a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> index 521b415..7ecd57c 100644
> --- a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> +++ b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> @@ -97,7 +97,3 @@
> };
> };
> };
> -
> -&uart0 {
> - status = "okay";
> -};
> diff --git a/arch/arm/boot/dts/bcm47094.dtsi b/arch/arm/boot/dts/bcm47094.dtsi
> index 4f09aa0..4840a78 100644
> --- a/arch/arm/boot/dts/bcm47094.dtsi
> +++ b/arch/arm/boot/dts/bcm47094.dtsi
> @@ -14,4 +14,5 @@
>
> &uart0 {
> clock-frequency = <125000000>;
> + status = "okay";
> };
> diff --git a/arch/arm/boot/dts/bcm94708.dts b/arch/arm/boot/dts/bcm94708.dts
> index 251a486..42855a7 100644
> --- a/arch/arm/boot/dts/bcm94708.dts
> +++ b/arch/arm/boot/dts/bcm94708.dts
> @@ -50,7 +50,3 @@
> reg = <0x00000000 0x08000000>;
> };
> };
> -
> -&uart0 {
> - status = "okay";
> -};
> diff --git a/arch/arm/boot/dts/bcm94709.dts b/arch/arm/boot/dts/bcm94709.dts
> index b16cac9..95e8be6 100644
> --- a/arch/arm/boot/dts/bcm94709.dts
> +++ b/arch/arm/boot/dts/bcm94709.dts
> @@ -50,7 +50,3 @@
> reg = <0x00000000 0x08000000>;
> };
> };
> -
> -&uart0 {
> - status = "okay";
> -};
> diff --git a/arch/arm/boot/dts/bcm953012er.dts b/arch/arm/boot/dts/bcm953012er.dts
> index 0a9abec..decd86b 100644
> --- a/arch/arm/boot/dts/bcm953012er.dts
> +++ b/arch/arm/boot/dts/bcm953012er.dts
> @@ -70,10 +70,6 @@
> };
> };
>
> -&uart0 {
> - status = "okay";
> -};
> -
> &spi_nor {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/bcm953012k.dts b/arch/arm/boot/dts/bcm953012k.dts
> index 05a985a..bfd9230 100644
> --- a/arch/arm/boot/dts/bcm953012k.dts
> +++ b/arch/arm/boot/dts/bcm953012k.dts
> @@ -54,7 +54,6 @@
>
> &uart0 {
> clock-frequency = <62499840>;
> - status = "okay";
> };
>
> &uart1 {
> --
> 2.10.1
>
^ permalink raw reply
* [GIT PULL 1/3] ARM: exynos: Soc/mach for v4.10
From: Krzysztof Kozlowski @ 2016-12-01 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479967709-6619-2-git-send-email-krzk@kernel.org>
On Thu, Nov 24, 2016 at 08:08:27AM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
> This contains previous dts branch because SCU node in dts is needed
> prior to removing it from mach code.
>
> Below you will find full pull request and one stripped from dependency.
>
Hi Arnd, Kevin and Olof,
What about this pull from the set?
Best regards,
Krzysztof
> Best regards,
> Krzysztof
>
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-4.10
>
> for you to fetch changes up to c689de56c0a7c8387ea00509f94fa483ae61d979:
>
> ARM: Drop fixed 200 Hz timer requirement from Samsung platforms (2016-11-23 19:34:55 +0200)
>
> ----------------------------------------------------------------
> Samsung mach/soc update for v4.10:
> 1. Use SCU mapping from Device Tree instead of statically mapped one.
> 2. Drop fixed requirement for HZ=200 on Samsung platforms.
>
> ----------------------------------------------------------------
> Javier Martinez Canillas (1):
> ARM: dts: exynos: Document eMMC/SD/SDIO devices in Snow and Peach boards
>
> Krzysztof Kozlowski (3):
> ARM: dts: exynos: Remove exynos4415.dtsi
> Merge tag 'samsung-dt-4.10' into next/soc
> ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
>
> Pankaj Dubey (4):
> ARM: EXYNOS: Remove smp_init_cpus hook from platsmp.c
> ARM: dts: exynos: Add SCU device node to exynos4.dtsi
> ARM: EXYNOS: Remove static mapping of SCU SFR
> ARM: EXYNOS: Remove unused soc_is_exynos{4,5}
>
> Randy Li (2):
> ARM: dts: exynos: Add TOPEET itop core board SCP package version
> ARM: dts: exynos: Add TOPEET itop elite based board
>
> Sylwester Nawrocki (3):
> ARM: dts: exynos: Remove "simple-bus" compatible from fimc-is node
> ARM: dts: exynos: Add entries for sound support on Odroid-XU board
> ARM: S3C24XX: Add DMA slave maps for remaining s3c24xx SoCs
>
> .../bindings/arm/samsung/samsung-boards.txt | 3 +
> arch/arm/Kconfig | 3 +-
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/exynos4.dtsi | 5 +
> arch/arm/boot/dts/exynos4412-itop-elite.dts | 240 ++++++++
> arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 501 ++++++++++++++++
> arch/arm/boot/dts/exynos4415-pinctrl.dtsi | 575 ------------------
> arch/arm/boot/dts/exynos4415.dtsi | 650 ---------------------
> arch/arm/boot/dts/exynos4x12.dtsi | 2 +-
> arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +
> arch/arm/boot/dts/exynos5410-odroidxu.dts | 69 +++
> arch/arm/boot/dts/exynos5410-pinctrl.dtsi | 9 +
> arch/arm/boot/dts/exynos5410.dtsi | 59 ++
> arch/arm/boot/dts/exynos5420-peach-pit.dts | 3 +
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 3 +
> arch/arm/mach-exynos/common.h | 6 +-
> arch/arm/mach-exynos/exynos.c | 22 -
> arch/arm/mach-exynos/include/mach/map.h | 2 -
> arch/arm/mach-exynos/platsmp.c | 65 +--
> arch/arm/mach-exynos/pm.c | 4 +-
> arch/arm/mach-exynos/suspend.c | 4 +-
> arch/arm/mach-s3c24xx/common.c | 76 +++
> arch/arm/plat-samsung/include/plat/map-s5p.h | 4 -
> 23 files changed, 1004 insertions(+), 1306 deletions(-)
> create mode 100644 arch/arm/boot/dts/exynos4412-itop-elite.dts
> create mode 100644 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
> delete mode 100644 arch/arm/boot/dts/exynos4415-pinctrl.dtsi
> delete mode 100644 arch/arm/boot/dts/exynos4415.dtsi
>
>
> Pull request details for Soc only:
> ##################################
> ----------------------------------------------------------------
> Samsung mach/soc update for v4.10:
> 1. Use SCU mapping from Device Tree instead of statically mapped one.
> 2. Drop fixed requirement for HZ=200 on Samsung platforms.
>
> ----------------------------------------------------------------
> Krzysztof Kozlowski (1):
> ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
>
> Pankaj Dubey (3):
> ARM: EXYNOS: Remove static mapping of SCU SFR
> ARM: EXYNOS: Remove unused soc_is_exynos{4,5}
> ARM: EXYNOS: Remove smp_init_cpus hook from platsmp.c
>
> Sylwester Nawrocki (1):
> ARM: S3C24XX: Add DMA slave maps for remaining s3c24xx SoCs
>
^ permalink raw reply
* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Bjorn Helgaas @ 2016-12-01 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480549373-2123-1-git-send-email-dhdang@apm.com>
Hi Duc,
On Wed, Nov 30, 2016 at 03:42:53PM -0800, Duc Dang wrote:
> PCIe controllers in X-Gene SoCs is not ECAM compliant: software
> needs to configure additional controller's register to address
> device at bus:dev:function.
>
> The quirk will only be applied for X-Gene PCIe MCFG table with
> OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).
>
> The quirk declares the X-Gene PCIe controller register space as 64KB
> fixed memory resource with name "PCIe CSR". This name will be showed
> next to the resource range in the output of "cat /proc/iomem".
>
> Signed-off-by: Duc Dang <dhdang@apm.com>
> ---
> v3:
> - Rebase on top of pci/ecam-v6 tree.
> - Use DEFINE_RES_MEM_NAMED to declare controller register space
> with name "PCIe CSR"
> v2:
> RFC v2: https://patchwork.ozlabs.org/patch/686846/
> v1:
> RFC v1: https://patchwork.kernel.org/patch/9337115/
>
> drivers/acpi/pci_mcfg.c | 31 ++++++++
> drivers/pci/host/pci-xgene.c | 165 ++++++++++++++++++++++++++++++++++++++++++-
> include/linux/pci-ecam.h | 7 ++
> 3 files changed, 200 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index ac21db3..eb6125b 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -57,6 +57,37 @@ struct mcfg_fixup {
> { "QCOM ", "QDF2432 ", 1, 5, MCFG_BUS_ANY, &pci_32b_ops },
> { "QCOM ", "QDF2432 ", 1, 6, MCFG_BUS_ANY, &pci_32b_ops },
> { "QCOM ", "QDF2432 ", 1, 7, MCFG_BUS_ANY, &pci_32b_ops },
> +
> +#ifdef CONFIG_PCI_XGENE
As you've no doubt noticed, I'm proposing to add these quirks without
CONFIG_PCI_XGENE, so we don't have to select each device when building
a generic ACPI kernel.
I'm also proposing some Kconfig and Makefile changes so we don't build
the platform driver part in a generic ACPI kernel (unless we *also*
explicitly select the platform driver).
Here's an example:
https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=f80edf4d6c05
> +#define XGENE_V1_ECAM_MCFG(rev, seg) \
> + {"APM ", "XGENE ", rev, seg, MCFG_BUS_ANY, \
> + &xgene_v1_pcie_ecam_ops }
> +#define XGENE_V2_1_ECAM_MCFG(rev, seg) \
> + {"APM ", "XGENE ", rev, seg, MCFG_BUS_ANY, \
> + &xgene_v2_1_pcie_ecam_ops }
> +#define XGENE_V2_2_ECAM_MCFG(rev, seg) \
> + {"APM ", "XGENE ", rev, seg, MCFG_BUS_ANY, \
> + &xgene_v2_2_pcie_ecam_ops }
> +
> + /* X-Gene SoC with v1 PCIe controller */
> + XGENE_V1_ECAM_MCFG(1, 0),
> + XGENE_V1_ECAM_MCFG(1, 1),
> @@ -64,6 +66,7 @@
> /* PCIe IP version */
> #define XGENE_PCIE_IP_VER_UNKN 0
> #define XGENE_PCIE_IP_VER_1 1
> +#define XGENE_PCIE_IP_VER_2 2
This isn't used anywhere, which makes me wonder whether it's worth
keeping it.
> static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
> {
> - struct xgene_pcie_port *port = bus->sysdata;
> + struct pci_config_window *cfg;
> + struct xgene_pcie_port *port;
> +
> + if (acpi_disabled)
> + port = bus->sysdata;
> + else {
> + cfg = bus->sysdata;
> + port = cfg->priv;
> + }
I would really, really like to figure out a way to get rid of these
"if (acpi_disabled)" checks sprinkled through here. Is there any way
we can set up bus->sysdata to be the same, regardless of whether we're
using this as a platform driver or an ACPI quirk?
> +#ifdef CONFIG_ACPI
You've probably noticed that I've been using
#if defined(CONFIG_ACPI) && defined(CONFIG_PCI_QUIRKS)
in this situation, mostly to make it clear that this is part of a
workaround. I don't want people to blindly copy this stuff without
realizing that it's a workaround for a hardware issue.
> +static struct resource xgene_v1_csr_res[] = {
> + [0] = DEFINE_RES_MEM_NAMED(0x1f2b0000UL, SZ_64K, "PCIe CSR"),
> + [1] = DEFINE_RES_MEM_NAMED(0x1f2c0000UL, SZ_64K, "PCIe CSR"),
> + [2] = DEFINE_RES_MEM_NAMED(0x1f2d0000UL, SZ_64K, "PCIe CSR"),
> + [3] = DEFINE_RES_MEM_NAMED(0x1f500000UL, SZ_64K, "PCIe CSR"),
> + [4] = DEFINE_RES_MEM_NAMED(0x1f510000UL, SZ_64K, "PCIe CSR"),
I assume these ranges are not the actual ECAM space, right?
If they *were* ECAM, I assume you would have included them in the
quirk itself in the mcfg_quirks[] table.
> +static int xgene_v1_pcie_ecam_init(struct pci_config_window *cfg)
> +{
> + struct acpi_device *adev = to_acpi_device(cfg->parent);
> + struct acpi_pci_root *root = acpi_driver_data(adev);
> + struct device *dev = cfg->parent;
> + struct xgene_pcie_port *port;
> + struct resource *csr;
> +
> + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> + if (!port)
> + return -ENOMEM;
> +
> + csr = &xgene_v1_csr_res[root->segment];
This makes me nervous because root->segment comes from the ACPI _SEG,
and if firmware gives us junk in _SEG, we will reference something in
the weeds.
> + port->csr_base = devm_ioremap_resource(dev, csr);
> + if (IS_ERR(port->csr_base)) {
> + kfree(port);
> + return -ENOMEM;
> + }
> +
> + port->cfg_base = cfg->win;
> + port->version = XGENE_PCIE_IP_VER_1;
> +
> + cfg->priv = port;
All these init functions are almost identical. Can we factor this out
by having wrappers that do nothing more than pass in the table and
version, and put the kzalloc and ioremap in a shared back-end?
We're so close I can taste it! I can't wait to see all this work come
to fruition.
Bjorn
^ permalink raw reply
* [PATCH V1 1/2] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version
From: Bjorn Helgaas @ 2016-12-01 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201145450.GA10353@red-moon>
On Thu, Dec 01, 2016 at 02:54:50PM +0000, Lorenzo Pieralisi wrote:
> On Thu, Dec 01, 2016 at 02:55:49PM +0100, Robert Richter wrote:
> > Tomasz, Bjorn,
> >
> > On 01.12.16 09:49:51, Tomasz Nowicki wrote:
> > > I put the picture together here (on top of your pci/ecam branch):
> > > [1] https://github.com/semihalf-nowicki-tomasz/linux/commits/pci-quirks-thunderx-v2
> >
> > please note that acpi_* functions must be protected with acpi_disabled
> > or something else to make sure an acpi enabled kernel does not break
> > dt. See the crash below with above branch.
>
> You could use struct device.of_node, or just move the MCFG check to ACPI
> code that probes the root bus in arm64 before calling pci_ecam_create()
> which will save you some ifdeffery too while at it.
Oh, I like that idea even better! I took the acpi_disabled check back out
of acpi_resource_consumer() and moved the call to
pci_acpi_setup_ecam_mapping(). Thanks!
> > [ 12.493028] Unable to handle kernel NULL pointer dereference at virtual address 00000018
> > [ 12.501113] pgd = ffff0000090a0000
> > [ 12.504511] [00000018] *pgd=0000010fffef0003[ 12.508602] , *pud=0000010fffef0003
> > , *pmd=0000010fffee0003[ 12.514093] , *pte=0000000000000000
> > [ 12.517575]
> > [ 12.519064] Internal error: Oops: 96000005 [#1] SMP
> > [ 12.523933] Modules linked in:
> > [ 12.526987] CPU: 73 PID: 1 Comm: swapper/0 Tainted: G W 4.9.0-rc6.0.vanilla10-00019-g09abd2b6bbeb #135
> > [ 12.537409] Hardware name: Cavium ThunderX CRB/To be filled by O.E.M., BIOS 5.11 12/12/2012
> > [ 12.545748] task: ffff800fe85b8000 task.stack: ffff800ff4288000
> > [ 12.551674] PC is at acpi_ns_walk_namespace+0x68/0x1d4
> > [ 12.556803] LR is at acpi_get_devices+0x6c/0x94
> > ...
> > [ 13.124920] [<ffff0000084dc5a0>] acpi_ns_walk_namespace+0x68/0x1d4
> > [ 13.131090] [<ffff0000084dcadc>] acpi_get_devices+0x6c/0x94
> > [ 13.136663] [<ffff0000084c0aec>] acpi_resource_consumer+0x34/0x44
> > [ 13.142752] [<ffff000008496bc0>] pci_ecam_create+0x80/0x228
> > [ 13.148314] [<ffff000008498e64>] pci_host_common_probe+0x294/0x348
> > [ 13.154486] [<ffff00000849bf3c>] thunder_ecam_probe+0x2c/0x38
> > [ 13.160226] [<ffff0000085880b8>] platform_drv_probe+0x60/0xc8
> > [ 13.165970] [<ffff000008585a04>] driver_probe_device+0x26c/0x420
> > [ 13.171966] [<ffff000008585cdc>] __driver_attach+0x124/0x128
> > [ 13.177615] [<ffff000008583238>] bus_for_each_dev+0x70/0xb0
> > [ 13.183177] [<ffff000008585060>] driver_attach+0x30/0x40
> > [ 13.188478] [<ffff000008584a98>] bus_add_driver+0x200/0x2b8
> > [ 13.194041] [<ffff000008586860>] driver_register+0x68/0x100
> > [ 13.199602] [<ffff000008587fdc>] __platform_driver_register+0x54/0x60
> > [ 13.206038] [<ffff000008c39b98>] thunder_ecam_driver_init+0x18/0x20
> > [ 13.212296] [<ffff000008082d94>] do_one_initcall+0x44/0x138
> > [ 13.217862] [<ffff000008c00d0c>] kernel_init_freeable+0x1ac/0x24c
> > [ 13.223950] [<ffff0000088605f0>] kernel_init+0x18/0x110
> > [ 13.229165] [<ffff000008082b30>] ret_from_fork+0x10/0x20
^ permalink raw reply
* [PATCH v3] ARM: davinci: da8xx: Fix sleeping function called from invalid context
From: David Lechner @ 2016-12-01 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480612342-23614-1-git-send-email-abailon@baylibre.com>
On 12/01/2016 11:12 AM, Alexandre Bailon wrote:
> Everytime the usb20 phy is enabled, there is a
Every time is two words
> "sleeping function called from invalid context" BUG.
>
> clk_enable() from arch/arm/mach-davinci/clock.c uses spin_lock_irqsave()
> before to invoke the callback usb20_phy_clk_enable().
> usb20_phy_clk_enable() uses clk_get() and clk_enable_prepapre()
> which may sleep.
> Move clk_get() to da8xx_register_usb20_phy_clk() and
> replace clk_prepare_enable() by clk_enable().
>
> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
> ---
> arch/arm/mach-davinci/usb-da8xx.c | 23 ++++++++++++-----------
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/usb-da8xx.c b/arch/arm/mach-davinci/usb-da8xx.c
> index b010e5f..bfb55b9 100644
> --- a/arch/arm/mach-davinci/usb-da8xx.c
> +++ b/arch/arm/mach-davinci/usb-da8xx.c
> @@ -156,23 +156,18 @@ int __init da8xx_register_usb_refclkin(int rate)
> return 0;
> }
>
> +static struct clk *usb20_clk;
Not a serious issue, but I would rather have the global variable
declared at the beginning of the file to make it more obvious there is a
global variable.
> +
> static void usb20_phy_clk_enable(struct clk *clk)
> {
> - struct clk *usb20_clk;
> int err;
> u32 val;
> u32 timeout = 500000; /* 500 msec */
>
> val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
>
> - usb20_clk = clk_get(&da8xx_usb20_dev.dev, "usb20");
> - if (IS_ERR(usb20_clk)) {
> - pr_err("could not get usb20 clk: %ld\n", PTR_ERR(usb20_clk));
> - return;
> - }
> -
> /* The USB 2.O PLL requires that the USB 2.O PSC is enabled as well. */
> - err = clk_prepare_enable(usb20_clk);
> + err = clk_enable(usb20_clk);
> if (err) {
> pr_err("failed to enable usb20 clk: %d\n", err);
> clk_put(usb20_clk);
> @@ -197,8 +192,7 @@ static void usb20_phy_clk_enable(struct clk *clk)
>
> pr_err("Timeout waiting for USB 2.0 PHY clock good\n");
> done:
> - clk_disable_unprepare(usb20_clk);
> - clk_put(usb20_clk);
> + clk_disable(usb20_clk);
> }
>
> static void usb20_phy_clk_disable(struct clk *clk)
> @@ -287,9 +281,16 @@ int __init da8xx_register_usb20_phy_clk(bool use_usb_refclkin)
> struct clk *parent;
> int ret = 0;
No longer need to initialize ret here.
>
> + usb20_clk = clk_get(&da8xx_usb20_dev.dev, "usb20");
> + ret = PTR_ERR_OR_ZERO(usb20_clk);
> + if (ret)
> + return ret;
> +
> parent = clk_get(NULL, use_usb_refclkin ? "usb_refclkin" : "pll0_aux");
> - if (IS_ERR(parent))
> + if (IS_ERR(parent)) {
why not use ret = PTR_ERR_OR_ZERO(parent) pattern here too?
> + clk_put(usb20_clk);
The global usb20_clk is no longer valid after this. Should we set it to
NULL here?
> return PTR_ERR(parent);
> + }
>
> usb20_phy_clk.parent = parent;
> ret = clk_register(&usb20_phy_clk);
>
^ permalink raw reply
* [PATCH v4 2/3] doc: dt: add cyclone-spi binding document
From: Moritz Fischer @ 2016-12-01 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <137f03de76e5f865430b17ca247e8f73e3315c8d.1480551148.git.stillcompiling@gmail.com>
On Thu, Dec 1, 2016 at 9:04 AM, Joshua Clayton <stillcompiling@gmail.com> wrote:
> Describe a cyclonei-ps-spi devicetree entry, required features
>
> Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
Acked-by: Moritz Fischer <moritz.fischer@ettus.com>
> ---
>
> .../bindings/fpga/cyclone-ps-spi-fpga-mgr.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
>
> diff --git a/Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
> new file mode 100644
> index 0000000..3f515c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
> @@ -0,0 +1,25 @@
> +Altera Cyclone Passive Serial SPI FPGA Manager
> +
> +Altera Cyclone FPGAs support a method of loading the bitstream over what is
> +referred to as "passive serial".
> +The passive serial link is not technically spi, and might require extra
> +circuits in order to play nicely with other spi slaves on the same bus.
> +
> +See https://www.altera.com/literature/hb/cyc/cyc_c51013.pdf
> +
> +Required properties:
> +- compatible : should contain "altr,cyclone-ps-spi-fpga-mgr"
> +- reg : spi slave id of the fpga
> +- config-gpios : config pin (referred to as nCONFIG in the cyclone manual)
> +- status-gpios : status pin (referred to as nSTATUS in the cyclone manual)
> +
> +both gpio pins are normally active low open drain.
> +
> +Example:
> + fpga_spi: evi-fpga-spi at 0 {
> + compatible = "altr,cyclone-ps-spi-fpga-mgr";
> + spi-max-frequency = <20000000>;
> + reg = <0>;
> + config-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
> + status-gpios = <&gpio4 11 GPIO_ACTIVE_LOW>;
> + };
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH dt V2] ARM: BCM5301X: Enable UART by default for BCM4708(1), BCM4709(4) & BCM53012
From: Rafał Miłecki @ 2016-12-01 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128140134.25128-1-zajec5@gmail.com>
From: Rafa? Mi?ecki <rafal@milecki.pl>
Every device tested so far got UART0 (at 0x18000300) working as serial
console. It's most likely part of reference design and all vendors use
it that way.
It seems to be easier to enable it by default and just disable it if we
ever see a device with different hardware design.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
V2: Update bcm94708.dts bcm94709.dts bcm953012er.dts & bcm953012k.dts
---
arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts | 4 ----
arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts | 4 ----
arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts | 4 ----
arch/arm/boot/dts/bcm4708-netgear-r6250.dts | 4 ----
arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts | 4 ----
arch/arm/boot/dts/bcm4708.dtsi | 4 ++++
arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 4 ----
arch/arm/boot/dts/bcm47081.dtsi | 4 ++++
arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 4 ----
arch/arm/boot/dts/bcm4709-netgear-r8000.dts | 4 ----
arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts | 4 ----
arch/arm/boot/dts/bcm4709.dtsi | 1 +
arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 4 ----
arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts | 4 ----
arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 4 ----
arch/arm/boot/dts/bcm47094.dtsi | 1 +
arch/arm/boot/dts/bcm94708.dts | 4 ----
arch/arm/boot/dts/bcm94709.dts | 4 ----
arch/arm/boot/dts/bcm953012er.dts | 4 ----
arch/arm/boot/dts/bcm953012k.dts | 1 -
20 files changed, 10 insertions(+), 61 deletions(-)
diff --git a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
index 9cb186e..d49afec0 100644
--- a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
+++ b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
@@ -136,10 +136,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&usb2 {
vcc-gpio = <&chipcommon 9 GPIO_ACTIVE_HIGH>;
};
diff --git a/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts b/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
index 35e6ed6..f591b0f 100644
--- a/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
+++ b/arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts
@@ -55,10 +55,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&spi_nor {
status = "okay";
};
diff --git a/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts b/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
index 1c7e53d..50d65d8 100644
--- a/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
+++ b/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
@@ -56,10 +56,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&spi_nor {
status = "okay";
};
diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
index 8ce39d5..8519548 100644
--- a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
+++ b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
@@ -83,10 +83,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&usb3 {
vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
};
diff --git a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
index 70f4bb9..74cfcd3 100644
--- a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
+++ b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
@@ -119,10 +119,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&spi_nor {
status = "okay";
};
diff --git a/arch/arm/boot/dts/bcm4708.dtsi b/arch/arm/boot/dts/bcm4708.dtsi
index eed4dd1..d0eec09 100644
--- a/arch/arm/boot/dts/bcm4708.dtsi
+++ b/arch/arm/boot/dts/bcm4708.dtsi
@@ -34,3 +34,7 @@
};
};
+
+&uart0 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
index a9c8def..2922536 100644
--- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
+++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
@@ -122,7 +122,3 @@
};
};
};
-
-&uart0 {
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/bcm47081.dtsi b/arch/arm/boot/dts/bcm47081.dtsi
index f720012..c5f7619 100644
--- a/arch/arm/boot/dts/bcm47081.dtsi
+++ b/arch/arm/boot/dts/bcm47081.dtsi
@@ -24,3 +24,7 @@
};
};
};
+
+&uart0 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
index fd38d2a..0225d82 100644
--- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
+++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
@@ -100,7 +100,3 @@
};
};
};
-
-&uart0 {
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
index 92f8a72..56d38a3 100644
--- a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
+++ b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
@@ -107,10 +107,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&usb2 {
vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
};
diff --git a/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts b/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
index 9a92c24..c67bfaa 100644
--- a/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
+++ b/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
@@ -97,10 +97,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&usb2 {
vcc-gpio = <&chipcommon 13 GPIO_ACTIVE_HIGH>;
};
diff --git a/arch/arm/boot/dts/bcm4709.dtsi b/arch/arm/boot/dts/bcm4709.dtsi
index f039765..c645fea 100644
--- a/arch/arm/boot/dts/bcm4709.dtsi
+++ b/arch/arm/boot/dts/bcm4709.dtsi
@@ -8,4 +8,5 @@
&uart0 {
clock-frequency = <125000000>;
+ status = "okay";
};
diff --git a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
index 661348d..7fb9270 100644
--- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
+++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
@@ -105,10 +105,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&usb3 {
vcc-gpio = <&chipcommon 18 GPIO_ACTIVE_HIGH>;
};
diff --git a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
index 169b35f..2f4a651 100644
--- a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
+++ b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
@@ -98,10 +98,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&usb3 {
vcc-gpio = <&chipcommon 18 GPIO_ACTIVE_HIGH>;
};
diff --git a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
index 521b415..7ecd57c 100644
--- a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
+++ b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
@@ -97,7 +97,3 @@
};
};
};
-
-&uart0 {
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/bcm47094.dtsi b/arch/arm/boot/dts/bcm47094.dtsi
index 4f09aa0..4840a78 100644
--- a/arch/arm/boot/dts/bcm47094.dtsi
+++ b/arch/arm/boot/dts/bcm47094.dtsi
@@ -14,4 +14,5 @@
&uart0 {
clock-frequency = <125000000>;
+ status = "okay";
};
diff --git a/arch/arm/boot/dts/bcm94708.dts b/arch/arm/boot/dts/bcm94708.dts
index 251a486..42855a7 100644
--- a/arch/arm/boot/dts/bcm94708.dts
+++ b/arch/arm/boot/dts/bcm94708.dts
@@ -50,7 +50,3 @@
reg = <0x00000000 0x08000000>;
};
};
-
-&uart0 {
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/bcm94709.dts b/arch/arm/boot/dts/bcm94709.dts
index b16cac9..95e8be6 100644
--- a/arch/arm/boot/dts/bcm94709.dts
+++ b/arch/arm/boot/dts/bcm94709.dts
@@ -50,7 +50,3 @@
reg = <0x00000000 0x08000000>;
};
};
-
-&uart0 {
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/bcm953012er.dts b/arch/arm/boot/dts/bcm953012er.dts
index 0a9abec..decd86b 100644
--- a/arch/arm/boot/dts/bcm953012er.dts
+++ b/arch/arm/boot/dts/bcm953012er.dts
@@ -70,10 +70,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
&spi_nor {
status = "okay";
};
diff --git a/arch/arm/boot/dts/bcm953012k.dts b/arch/arm/boot/dts/bcm953012k.dts
index 05a985a..bfd9230 100644
--- a/arch/arm/boot/dts/bcm953012k.dts
+++ b/arch/arm/boot/dts/bcm953012k.dts
@@ -54,7 +54,6 @@
&uart0 {
clock-frequency = <62499840>;
- status = "okay";
};
&uart1 {
--
2.10.1
^ permalink raw reply related
* [PATCH] arm64: smp: Prevent raw_smp_processor_id() recursion
From: Catalin Marinas @ 2016-12-01 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2bd54897-df2e-a20e-d748-07966642b850@arm.com>
On Thu, Dec 01, 2016 at 05:16:50PM +0000, Robin Murphy wrote:
> On 01/12/16 15:55, Robin Murphy wrote:
> > Under CONFIG_DEBUG_PREEMPT=y, this_cpu_ptr() ends up calling back into
> > raw_smp_processor_id(), resulting in some hilariously catastrophic
> > infinite recursion. In the normal case, we have:
> >
> > #define this_cpu_ptr(ptr) raw_cpu_ptr(ptr)
> >
> > and everything is dandy. However for CONFIG_DEBUG_PREEMPT, this_cpu_ptr()
> > is defined in terms of my_cpu_offset, wherein the fun begins:
> >
> > #define my_cpu_offset per_cpu_offset(smp_processor_id())
> > ...
> > #define smp_processor_id() debug_smp_processor_id()
> > ...
> > notrace unsigned int debug_smp_processor_id(void)
> > {
> > return check_preemption_disabled("smp_processor_id", "");
> > ...
> > notrace static unsigned int check_preemption_disabled(const char *what1,
> > const char *what2)
> > {
> > int this_cpu = raw_smp_processor_id();
> >
> > and bang. Use raw_cpu_ptr() directly to avoid that.
> >
> > Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > Acked-by: Will Deacon <will.deacon@arm.com>
> > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>
> I wasn't sure whether commit IDs on for-next/core are stable, but if
> they are, this could also have:
>
> Fixes: 57c82954e77f ("arm64: make cpu number a percpu variable")
It depends on which branch is pulled into next. I keep the for-next/core
stable at this stage, so I'll include the Fixes like as well. Thanks.
--
Catalin
^ permalink raw reply
* [PATCH v2] arm64: mm: Fix memmap to be initialized for the entire section
From: James Morse @ 2016-12-01 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201164538.GB1236@arm.com>
Hi Robert, Will,
On 01/12/16 16:45, Will Deacon wrote:
> On Wed, Nov 30, 2016 at 07:21:31PM +0100, Robert Richter wrote:
>> On ThunderX systems with certain memory configurations we see the
>> following BUG_ON():
>>
>> kernel BUG at mm/page_alloc.c:1848!
>>
>> This happens for some configs with 64k page size enabled. The BUG_ON()
>> checks if start and end page of a memmap range belongs to the same
>> zone.
>>
>> The BUG_ON() check fails if a memory zone contains NOMAP regions. In
>> this case the node information of those pages is not initialized. This
>> causes an inconsistency of the page links with wrong zone and node
>> information for that pages. NOMAP pages from node 1 still point to the
>> mem zone from node 0 and have the wrong nid assigned.
>>
>> The reason for the mis-configuration is a change in pfn_valid() which
>> reports pages marked NOMAP as invalid:
>>
>> 68709f45385a arm64: only consider memblocks with NOMAP cleared for linear mapping
>>
>> This causes pages marked as nomap being no long reassigned to the new
>> zone in memmap_init_zone() by calling __init_single_pfn().
>>
>> Fixing this by restoring the old behavior of pfn_valid() to use
>> memblock_is_memory(). Also changing users of pfn_valid() in arm64 code
>> to use memblock_is_map_memory() where necessary. This only affects
>> code in ioremap.c. The code in mmu.c still can use the new version of
>> pfn_valid().
>>
>> As a consequence, pfn_valid() can not be used to check if a physical
>> page is RAM. It just checks if there is an underlying memmap with a
>> valid struct page. Moreover, for performance reasons the whole memmap
>> (with pageblock_nr_pages number of pages) has valid pfns (SPARSEMEM
>> config). The memory range is extended to fit the alignment of the
>> memmap. Thus, pfn_valid() may return true for pfns that do not map to
>> physical memory. Those pages are simply not reported to the mm, they
>> are not marked reserved nor added to the list of free pages. Other
>> functions such a page_is_ram() or memblock_is_map_ memory() must be
>> used to check for memory and if the page can be mapped with the linear
>> mapping.
[...]
> Thanks for sending out the new patch. Whilst I'm still a bit worried about
> changing pfn_valid like this, I guess we'll just have to fix up any callers
> which suffer from this change.
Hibernate's core code falls foul of this. This patch causes a panic when copying
memory to build the 'image'[0].
saveable_page() in kernel/power/snapshot.c broadly assumes that pfn_valid()
pages can be accessed.
Fortunately the core code exposes pfn_is_nosave() which we can extend to catch
'nomap' pages, but only if they are also marked as PageReserved().
Are there any side-effects of marking all the nomap regions with
mark_page_reserved()? (it doesn't appear to be the case today).
Patches incoming...
Thanks,
James
[0] panic trace
root at juno-r1:~# echo disk > /sys/power/state
[ 56.914184] PM: Syncing filesystems ... [ 56.918853] done.
[ 56.920826] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 56.930383] PM: Preallocating image memory... done (allocated 97481 pages)
[ 60.566084] PM: Allocated 389924 kbytes in 3.62 seconds (107.71 MB/s)
[ 60.572576] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 60.604877] PM: freeze of devices complete after 23.146 msecs
[ 60.611230] PM: late freeze of devices complete after 0.578 msecs
[ 60.618609] PM: noirq freeze of devices complete after 1.247 msecs
[ 60.624833] Disabling non-boot CPUs ...
[ 60.649112] CPU1: shutdown
[ 60.651823] psci: CPU1 killed.
[ 60.701055] CPU2: shutdown
[ 60.703766] psci: CPU2 killed.
[ 60.745002] IRQ11 no longer affine to CPU3
[ 60.745043] CPU3: shutdown
[ 60.751890] psci: CPU3 killed.
[ 60.784966] CPU4: shutdown
[ 60.787676] psci: CPU4 killed.
[ 60.824916] IRQ8 no longer affine to CPU5
[ 60.824920] IRQ9 no longer affine to CPU5
[ 60.824927] IRQ18 no longer affine to CPU5
[ 60.824931] IRQ20 no longer affine to CPU5
[ 60.824951] CPU5: shutdown
[ 60.843975] psci: CPU5 killed.
[ 60.857989] PM: Creating hibernation image:
[ 60.857989] PM: Need to copy 96285 pages
[ 60.857989] Unable to handle kernel paging request at virtual address
ffff8000794a0000
[ 60.857989] pgd = ffff800975190000
[ 60.857989] [ffff8000794a0000] *pgd=0000000000000000[ 60.857989]
[ 60.857989] Internal error: Oops: 96000007 [#1] PREEMPT SMP
[ 60.857989] Modules linked in:
[ 60.857989] CPU: 0 PID: 2366 Comm: bash Not tainted
4.9.0-rc7-00001-gecf7c47af54d #6346
[ 60.857989] Hardware name: ARM Juno development board (r1) (DT)
[ 60.857989] task: ffff8009766d3200 task.stack: ffff800975fec000
[ 60.857989] PC is at swsusp_save+0x250/0x2c8
[ 60.857989] LR is at swsusp_save+0x214/0x2c8
[ 60.857989] pc : [<ffff000008100bd0>] lr : [<ffff000008100b94>] pstate: 200003c5
[ 60.857989] sp : ffff800975fefb50
[ 60.857989] x29: ffff800975fefb50 x28: ffff800975fec000
[ 60.857989] x27: ffff0000088c2000 x26: 0000000000000040
[ 60.857989] x25: 00000000000f94a0 x24: ffff000008e437e8
[ 60.857989] x23: 000000000001781d x22: ffff000008bee000
[ 60.857989] x21: ffff000008e437f8 x20: ffff000008e43878
[ 60.857989] x19: ffff7e0000000000 x18: 0000000000000006
[ 60.857989] x17: 0000000000000000 x16: 00000000000005d0
[ 60.857989] x15: ffff000008e43e95 x14: 00000000000001d9
[ 60.857989] x13: 0000000000000001 x12: ffff7e0000000000
[ 60.857989] x11: ffff7e0025ffffc0 x10: 0000000025ffffc0
[ 60.857989] x9 : 000000000000012f x8 : ffff80096cd04ce0
[ 60.857989] x7 : 0000000000978000 x6 : 0000000000000076
[ 60.857989] x5 : fffffffffffffff8 x4 : 0000000000080000
[ 60.857989] x3 : ffff8000794a0000 x2 : ffff800959d83000
[ 60.857989] x1 : 0000000000000000 x0 : ffff7e0001e52800
[ 60.857989] Process bash (pid: 2366, stack limit = 0xffff800975fec020)
[ 60.857989] Stack: (0xffff800975fefb50 to 0xffff800975ff0000)
[ 60.857989] Call trace:
[ 60.857989] [<ffff000008100bd0>] swsusp_save+0x250/0x2c8
[ 60.857989] [<ffff0000080936ec>] swsusp_arch_suspend+0xb4/0x100
[ 60.857989] [<ffff0000080fe670>] hibernation_snapshot+0x278/0x318
[ 60.857989] [<ffff0000080fef10>] hibernate+0x1d0/0x268
[ 60.857989] [<ffff0000080fc954>] state_store+0xdc/0x100
[ 60.857989] [<ffff00000838419c>] kobj_attr_store+0x14/0x28
[ 60.857989] [<ffff00000825be68>] sysfs_kf_write+0x48/0x58
[ 60.857989] [<ffff00000825b1f8>] kernfs_fop_write+0xb0/0x1d8
[ 60.857989] [<ffff0000081e2ddc>] __vfs_write+0x1c/0x110
[ 60.857989] [<ffff0000081e3bd8>] vfs_write+0xa0/0x1b8
[ 60.857989] [<ffff0000081e4f44>] SyS_write+0x44/0xa0
[ 60.857989] [<ffff000008082ef0>] el0_svc_naked+0x24/0x28
[ 60.857989] Code: d37ae442 d37ae463 b2514042 b2514063 (f8636820)
[ 60.857989] ---[ end trace d0265b757c9dd571 ]---
[ 60.857989] ------------[ cut here ]------------
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Enable UART by default for BCM4708(1) and BCM4709(4)
From: Rafał Miłecki @ 2016-12-01 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAC3K-4o3-eSDU5JvjkgohtWLUmZqQViHvX1h2zfdPAGe+qbCOg@mail.gmail.com>
On 1 December 2016 at 18:14, Jon Mason <jon.mason@broadcom.com> wrote:
> On Mon, Nov 28, 2016 at 9:01 AM, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
>>
>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>
>> Every device tested so far got UART0 (at 0x18000300) working as serial
>> console. It's most likely part of reference design and all vendors use
>> it that way.
>>
>> It seems to be easier to enable it by default and just disable it if we
>> ever see a device with different hardware design.
>>
>> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
>> ---
>> arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts | 4 ----
>> arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts | 4 ----
>> arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts | 4 ----
>> arch/arm/boot/dts/bcm4708-netgear-r6250.dts | 4 ----
>> arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts | 4 ----
>> arch/arm/boot/dts/bcm4708.dtsi | 4 ++++
>> arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 4 ----
>> arch/arm/boot/dts/bcm47081.dtsi | 4 ++++
>> arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 4 ----
>> arch/arm/boot/dts/bcm4709-netgear-r8000.dts | 4 ----
>> arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts | 4 ----
>> arch/arm/boot/dts/bcm4709.dtsi | 1 +
>> arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 4 ----
>> arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts | 4 ----
>> arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 4 ----
>> arch/arm/boot/dts/bcm47094.dtsi | 1 +
>
>
> I think there are a few missing here. A quick grep shows
>
> $ grep -rI '#include "bcm470[89].dtsi"' arch/arm/boot/dts/*.dts
> arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm4708-luxul-xap-1510.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm4708-netgear-r6250.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts:#include "bcm4709.dtsi"
> arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts:#include "bcm4709.dtsi"
> arch/arm/boot/dts/bcm4709-netgear-r7000.dts:#include "bcm4709.dtsi"
> arch/arm/boot/dts/bcm4709-netgear-r8000.dts:#include "bcm4709.dtsi"
> arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts:#include "bcm4709.dtsi"
> arch/arm/boot/dts/bcm94708.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm94709.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm953012er.dts:#include "bcm4708.dtsi"
> arch/arm/boot/dts/bcm953012k.dts:#include "bcm4708.dtsi"
>
> I specifically care about the last 4 :)
Actually the only missing ones are the last 4. Other ones (e.g.
bcm4709-buffalo-wxr-1900dhp.dts) never got uart0 enabled so I just
didn't need to modify these files.
I'll send V2 updating last 4 ones as well. Thanks for catching this.
^ permalink raw reply
* [PATCH] arm64: smp: Prevent raw_smp_processor_id() recursion
From: Robin Murphy @ 2016-12-01 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bb132e9abf4d256e40ad311b106b05d724b290fb.1480607460.git.robin.murphy@arm.com>
On 01/12/16 15:55, Robin Murphy wrote:
> Under CONFIG_DEBUG_PREEMPT=y, this_cpu_ptr() ends up calling back into
> raw_smp_processor_id(), resulting in some hilariously catastrophic
> infinite recursion. In the normal case, we have:
>
> #define this_cpu_ptr(ptr) raw_cpu_ptr(ptr)
>
> and everything is dandy. However for CONFIG_DEBUG_PREEMPT, this_cpu_ptr()
> is defined in terms of my_cpu_offset, wherein the fun begins:
>
> #define my_cpu_offset per_cpu_offset(smp_processor_id())
> ...
> #define smp_processor_id() debug_smp_processor_id()
> ...
> notrace unsigned int debug_smp_processor_id(void)
> {
> return check_preemption_disabled("smp_processor_id", "");
> ...
> notrace static unsigned int check_preemption_disabled(const char *what1,
> const char *what2)
> {
> int this_cpu = raw_smp_processor_id();
>
> and bang. Use raw_cpu_ptr() directly to avoid that.
>
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Acked-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
I wasn't sure whether commit IDs on for-next/core are stable, but if
they are, this could also have:
Fixes: 57c82954e77f ("arm64: make cpu number a percpu variable")
Robin.
> ---
>
> Since I just reproduced this locally to verify Will's suggestion, it
> seemed I might as well just write it up as a patch :)
>
> arch/arm64/include/asm/smp.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
> index a62db952ffcb..d050d720a1b4 100644
> --- a/arch/arm64/include/asm/smp.h
> +++ b/arch/arm64/include/asm/smp.h
> @@ -41,8 +41,10 @@ DECLARE_PER_CPU_READ_MOSTLY(int, cpu_number);
> * We don't use this_cpu_read(cpu_number) as that has implicit writes to
> * preempt_count, and associated (compiler) barriers, that we'd like to avoid
> * the expense of. If we're preemptible, the value can be stale at use anyway.
> + * And we can't use this_cpu_ptr() either, as that winds up recursing back
> + * here under CONFIG_DEBUG_PREEMPT=y.
> */
> -#define raw_smp_processor_id() (*this_cpu_ptr(&cpu_number))
> +#define raw_smp_processor_id() (*raw_cpu_ptr(&cpu_number))
>
> struct seq_file;
>
>
^ permalink raw reply
* [PATCH 3/3] ARM: da850: fix da850_set_pll0rate()
From: Bartosz Golaszewski @ 2016-12-01 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480612516-18853-1-git-send-email-bgolaszewski@baylibre.com>
This function is broken - its second argument is an index to the freq
table, not the requested clock rate in Hz. It leads to an oops when
called from clk_set_rate() since this argument isn't bounds checked
either.
Fix it by iterating over the array of supported frequencies and
selecting a one that matches or returning -EINVAL for unsupported
rates.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/da850.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 855b720..1c0f296 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1173,14 +1173,28 @@ static int da850_set_armrate(struct clk *clk, unsigned long index)
return clk_set_rate(pllclk, index);
}
-static int da850_set_pll0rate(struct clk *clk, unsigned long index)
+static int da850_set_pll0rate(struct clk *clk, unsigned long requested_rate)
{
- unsigned int prediv, mult, postdiv;
- struct da850_opp *opp;
struct pll_data *pll = clk->pll_data;
+ struct cpufreq_frequency_table *freq;
+ unsigned int prediv, mult, postdiv;
+ struct da850_opp *opp = NULL;
int ret;
- opp = (struct da850_opp *) cpufreq_info.freq_table[index].driver_data;
+ for (freq = da850_freq_table;
+ freq->frequency != CPUFREQ_TABLE_END; freq++) {
+ /* requested_rate is in Hz, freq->frequency is in KHz */
+ unsigned long freq_rate = freq->frequency * 1000;
+
+ if (freq_rate == requested_rate) {
+ opp = (struct da850_opp *)freq->driver_data;
+ break;
+ }
+ }
+
+ if (opp == NULL)
+ return -EINVAL;
+
prediv = opp->prediv;
mult = opp->mult;
postdiv = opp->postdiv;
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] ARM: da850: coding style fix
From: Bartosz Golaszewski @ 2016-12-01 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480612516-18853-1-git-send-email-bgolaszewski@baylibre.com>
Fix alignment of the clock lookup table entries.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/da850.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 1e11ce8..855b720 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -542,7 +542,7 @@ static struct clk_lookup da850_clks[] = {
CLK("spi_davinci.0", NULL, &spi0_clk),
CLK("spi_davinci.1", NULL, &spi1_clk),
CLK("vpif", NULL, &vpif_clk),
- CLK("ahci_da850", NULL, &sata_clk),
+ CLK("ahci_da850", NULL, &sata_clk),
CLK("davinci-rproc.0", NULL, &dsp_clk),
CLK(NULL, NULL, &ehrpwm_clk),
CLK("ehrpwm.0", "fck", &ehrpwm0_clk),
--
2.9.3
^ permalink raw reply related
* [PATCH 1/3] ARM: da850: fix infinite loop in clk_set_rate()
From: Bartosz Golaszewski @ 2016-12-01 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480612516-18853-1-git-send-email-bgolaszewski@baylibre.com>
The aemif clock is added twice to the lookup table in da850.c. This
breaks the children list of pll0_sysclk3 as we're using the same list
links in struct clk. When calling clk_set_rate(), we get stuck in
propagate_rate().
Simply add the clock once, but specify both the con_id and dev_id in
the lookup entry.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/da850.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index e770c97..1e11ce8 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -536,8 +536,7 @@ static struct clk_lookup da850_clks[] = {
CLK("da8xx_lcdc.0", "fck", &lcdc_clk),
CLK("da830-mmc.0", NULL, &mmcsd0_clk),
CLK("da830-mmc.1", NULL, &mmcsd1_clk),
- CLK("ti-aemif", NULL, &aemif_clk),
- CLK(NULL, "aemif", &aemif_clk),
+ CLK("ti-aemif", "aemif", &aemif_clk),
CLK("ohci-da8xx", "usb11", &usb11_clk),
CLK("musb-da8xx", "usb20", &usb20_clk),
CLK("spi_davinci.0", NULL, &spi0_clk),
--
2.9.3
^ permalink raw reply related
* [PATCH 0/3] ARM: da850: fix pll0 rate setting
From: Bartosz Golaszewski @ 2016-12-01 17:15 UTC (permalink / raw)
To: linux-arm-kernel
While trying to set the pll0 rate from the kernel I noticed there are
two issues with da850 clocks. The first patch fixes an infinite loop
in propagate_rate(). The third fixes an oops in da850_set_pll0rate().
The second patch is just a coding style fix, while we're at it.
Bartosz Golaszewski (3):
ARM: da850: fix infinite loop in clk_set_rate()
ARM: da850: coding style fix
ARM: da850: fix da850_set_pll0rate()
arch/arm/mach-davinci/da850.c | 27 ++++++++++++++++++++-------
1 file changed, 20 insertions(+), 7 deletions(-)
--
2.9.3
^ 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