* [PATCH 1/5] net: phy: broadcom: Add BCM54810 phy entry
From: Andrew Lunn @ 2016-10-27 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510561-17035-2-git-send-email-jon.mason@broadcom.com>
On Wed, Oct 26, 2016 at 03:35:57PM -0400, Jon Mason wrote:
> From: Vikas Soni <vsoni@broadcom.com>
>
> Add BCM54810 phy entry
Hi Jon, Vikis
The subject line is a bit misleading. It does more than add a PHY ID
entry.
> Signed-off-by: Vikas Soni <vsoni@broadcom.com>
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> ---
> drivers/net/phy/Kconfig | 2 +-
> drivers/net/phy/broadcom.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/brcmphy.h | 7 +++++
> 3 files changed, 73 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 45f68ea..31967ca 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -217,7 +217,7 @@ config BROADCOM_PHY
> select BCM_NET_PHYLIB
> ---help---
> Currently supports the BCM5411, BCM5421, BCM5461, BCM54616S, BCM5464,
> - BCM5481 and BCM5482 PHYs.
> + BCM5481, BCM54810 and BCM5482 PHYs.
>
> config CICADA_PHY
> tristate "Cicada PHYs"
> diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
> index 870327e..cdce761 100644
> --- a/drivers/net/phy/broadcom.c
> +++ b/drivers/net/phy/broadcom.c
> @@ -35,6 +35,35 @@ static int bcm54xx_auxctl_write(struct phy_device *phydev, u16 regnum, u16 val)
> return phy_write(phydev, MII_BCM54XX_AUX_CTL, regnum | val);
> }
>
> +static int bcm54810_config(struct phy_device *phydev)
> +{
> + int rc;
> +
> + /* Disable BroadR-Reach */
> + rc = bcm_phy_write_exp(phydev, BCM54810_EXP_BROADREACH_LRE_MISC_CTL, 0);
> + if (rc < 0)
> + return rc;
> +
> + /* SKEW DISABLE */
> + rc = bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC,
> + 0xF0E0);
> + if (rc < 0)
> + return rc;
> +
> + /* DELAY DISABLE */
> + rc = bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC,
> + 0x7000);
This driver mostly uses symbolic names, not #defines. Please can you
use #defines here and else were in this patch.
> + if (rc < 0)
> + return rc;
> +
> + /* DELAY DISABLE */
> + rc = bcm_phy_write_shadow(phydev, BCM54810_SHD_CLK_CTL, 0);
> + if (rc < 0)
> + return rc;
Twice the same comment?
> +
> + return 0;
> +}
> +
> /* Needs SMDSP clock enabled via bcm54xx_phydsp_config() */
> static int bcm50610_a0_workaround(struct phy_device *phydev)
> {
> @@ -207,6 +236,20 @@ static int bcm54xx_config_init(struct phy_device *phydev)
> (phydev->dev_flags & PHY_BRCM_AUTO_PWRDWN_ENABLE))
> bcm54xx_adjust_rxrefclk(phydev);
>
> + if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810) {
> + err = bcm54810_config(phydev);
> + if (err)
> + return err;
> +
> + reg = phy_read(phydev, MII_BMCR);
> + if (reg < 0)
> + return reg;
> +
> + err = phy_write(phydev, MII_BMCR, reg & ~BMCR_PDOWN);
> + if (err)
> + return err;
This seems a bit odd. I would expect the PHY core correctly handles
the PHY being powered down. Can you explain this a bit more, why it is
needed.
Thanks
Andrew
^ permalink raw reply
* [PATCH 2/5] Documentation: devicetree: net: add NS2 bindings to amac
From: Andrew Lunn @ 2016-10-27 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510561-17035-3-git-send-email-jon.mason@broadcom.com>
On Wed, Oct 26, 2016 at 03:35:58PM -0400, Jon Mason wrote:
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> ---
> Documentation/devicetree/bindings/net/brcm,amac.txt | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt
> index ba5ecc1..f92caee 100644
> --- a/Documentation/devicetree/bindings/net/brcm,amac.txt
> +++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
> @@ -2,15 +2,18 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
> -------------------------------------------------------------
>
> Required properties:
> - - compatible: "brcm,amac" or "brcm,nsp-amac"
> + - compatible: "brcm,amac", "brcm,nsp-amac", or "brcm,ns2-amac"
> - reg: Address and length of the GMAC registers,
> Address and length of the GMAC IDM registers
> + Address and length of the NIC Port Manager registers (optional)
> - reg-names: Names of the registers. Must have both "amac_base" and
> - "idm_base"
> + "idm_base". "nicpm_base" is optional (required for NS2)
> - interrupts: Interrupt number
>
> Optional properties:
> - mac-address: See ethernet.txt file in the same directory
> +- brcm,enet-phy-lane-swap:
> + boolean; Swap the PHY lanes (needed on some SKUs of NS2)
Maybe i'm missing something here, but the patch to the PHY swapped the
lanes. This seems to be a PHY property, not a MAC property. And it
swapped them unconditionally....
Andrew
^ permalink raw reply
* [RFC PATCH 5/5] of: overlay-mgr: add a detector for headers stored on a ds2431 eeprom over w1
From: Matthias Brugger @ 2016-10-27 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026145756.21689-6-antoine.tenart@free-electrons.com>
On 10/26/2016 04:57 PM, Antoine Tenart wrote:
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> ---
Please provide a commit message.
> drivers/of/overlay-manager/Kconfig | 10 ++++++++++
> drivers/w1/slaves/w1_ds2431.c | 39 ++++++++++++++++++++++++++++++++++++++
> 2 files changed, 49 insertions(+)
>
> diff --git a/drivers/of/overlay-manager/Kconfig b/drivers/of/overlay-manager/Kconfig
> index 1a36613c0c53..ad0a5b8e9e5e 100644
> --- a/drivers/of/overlay-manager/Kconfig
> +++ b/drivers/of/overlay-manager/Kconfig
> @@ -16,4 +16,14 @@ config OF_OVERLAY_MGR_FORMAT_CHIP
>
> endmenu
>
> +menu "Overlay Manager detectors"
> +
> +config OF_OVERLAY_MGR_DETECTOR_DS2431
> + bool "Dip header on a DS2431 EEPROM"
> + depends on W1_SLAVE_DS2431
> + help
> + Enable dip header DS2431 EEPROM support.
> +
> +endmenu
> +
> endif
> diff --git a/drivers/w1/slaves/w1_ds2431.c b/drivers/w1/slaves/w1_ds2431.c
> index 80572cb63ba8..760325f9a2bd 100644
> --- a/drivers/w1/slaves/w1_ds2431.c
> +++ b/drivers/w1/slaves/w1_ds2431.c
> @@ -15,6 +15,9 @@
> #include <linux/device.h>
> #include <linux/types.h>
> #include <linux/delay.h>
> +#include <linux/slab.h>
> +
> +#include <linux/overlay-manager.h>
>
> #include "../w1.h"
> #include "../w1_int.h"
> @@ -280,7 +283,43 @@ static const struct attribute_group *w1_f2d_groups[] = {
> NULL,
> };
>
> +#if IS_ENABLED(CONFIG_OF_OVERLAY_MGR_DETECTOR_DS2431)
> +static int chip_dip_callback(struct w1_slave *sl)
> +{
> + char **candidates = NULL;
> + int i, n, err = 0;
> + u8 *data;
> +
> + data = kzalloc(OVERLAY_MGR_DIP_MAX_SZ, GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + /* sizeof(struct chip_header) is a mulitple of 8 */
> + for (i = 0; i < OVERLAY_MGR_DIP_MAX_SZ; i += 8) {
> + if (w1_f2d_readblock(sl, i, 8, &data[i])) {
> + err = -EIO;
> + goto end;
> + }
> + }
> +
> + overlay_mgr_parse(&sl->dev, data, &candidates, &n);
> + if (!n) {
> + err = -EINVAL;
> + goto end;
> + }
> +
> + err = overlay_mgr_apply(&sl->dev, candidates, n);
> +
> +end:
> + kfree(data);
> + return err;
> +}
> +#endif
> +
> static struct w1_family_ops w1_f2d_fops = {
> +#if IS_ENABLED(CONFIG_OF_OVERLAY_MGR_DETECTOR_DS2431)
> + .callback = chip_dip_callback,
> +#endif
> .groups = w1_f2d_groups,
> };
>
>
^ permalink raw reply
* [PATCH] arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
From: Christoffer Dall @ 2016-10-27 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477323088-18768-1-git-send-email-marc.zyngier@arm.com>
On Mon, Oct 24, 2016 at 04:31:28PM +0100, Marc Zyngier wrote:
> Architecturally, TLBs are private to the (physical) CPU they're
> associated with. But when multiple vcpus from the same VM are
> being multiplexed on the same CPU, the TLBs are not private
> to the vcpus (and are actually shared across the VMID).
>
> Let's consider the following scenario:
>
> - vcpu-0 maps PA to VA
> - vcpu-1 maps PA' to VA
>
> If run on the same physical CPU, vcpu-1 can hit TLB entries generated
> by vcpu-0 accesses, and access the wrong physical page.
>
> The solution to this is to keep a per-VM map of which vcpu ran last
> on each given physical CPU, and invalidate local TLBs when switching
> to a different vcpu from the same VM.
Just making sure I understand this: The reason you cannot rely on the
guest doing the necessary distinction with ASIDs or invalidating the TLB
is that a guest (which assumes it's running on hardware) can validly
defer any neccessary invalidation until it starts running on other
physical CPUs, but we do this transparently in KVM?
Thanks,
-Christoffer
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm/include/asm/kvm_host.h | 5 +++++
> arch/arm/include/asm/kvm_hyp.h | 1 +
> arch/arm/kvm/arm.c | 35 ++++++++++++++++++++++++++++++++++-
> arch/arm/kvm/hyp/switch.c | 9 +++++++++
> arch/arm64/include/asm/kvm_host.h | 6 +++++-
> arch/arm64/kvm/hyp/switch.c | 8 ++++++++
> 6 files changed, 62 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 2d19e02..035e744 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -57,6 +57,8 @@ struct kvm_arch {
> /* VTTBR value associated with below pgd and vmid */
> u64 vttbr;
>
> + int __percpu *last_vcpu_ran;
> +
> /* Timer */
> struct arch_timer_kvm timer;
>
> @@ -174,6 +176,9 @@ struct kvm_vcpu_arch {
> /* vcpu power-off state */
> bool power_off;
>
> + /* TLBI required */
> + bool requires_tlbi;
> +
> /* Don't run the guest (internal implementation need) */
> bool pause;
>
> diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
> index 343135e..5850890 100644
> --- a/arch/arm/include/asm/kvm_hyp.h
> +++ b/arch/arm/include/asm/kvm_hyp.h
> @@ -71,6 +71,7 @@
> #define ICIALLUIS __ACCESS_CP15(c7, 0, c1, 0)
> #define ATS1CPR __ACCESS_CP15(c7, 0, c8, 0)
> #define TLBIALLIS __ACCESS_CP15(c8, 0, c3, 0)
> +#define TLBIALL __ACCESS_CP15(c8, 0, c7, 0)
> #define TLBIALLNSNHIS __ACCESS_CP15(c8, 4, c3, 4)
> #define PRRR __ACCESS_CP15(c10, 0, c2, 0)
> #define NMRR __ACCESS_CP15(c10, 0, c2, 1)
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 03e9273..09942f0 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -114,11 +114,18 @@ void kvm_arch_check_processor_compat(void *rtn)
> */
> int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> {
> - int ret = 0;
> + int ret, cpu;
>
> if (type)
> return -EINVAL;
>
> + kvm->arch.last_vcpu_ran = alloc_percpu(typeof(*kvm->arch.last_vcpu_ran));
> + if (!kvm->arch.last_vcpu_ran)
> + return -ENOMEM;
> +
> + for_each_possible_cpu(cpu)
> + *per_cpu_ptr(kvm->arch.last_vcpu_ran, cpu) = -1;
> +
> ret = kvm_alloc_stage2_pgd(kvm);
> if (ret)
> goto out_fail_alloc;
> @@ -141,6 +148,8 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> out_free_stage2_pgd:
> kvm_free_stage2_pgd(kvm);
> out_fail_alloc:
> + free_percpu(kvm->arch.last_vcpu_ran);
> + kvm->arch.last_vcpu_ran = NULL;
> return ret;
> }
>
> @@ -168,6 +177,9 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
> {
> int i;
>
> + free_percpu(kvm->arch.last_vcpu_ran);
> + kvm->arch.last_vcpu_ran = NULL;
> +
> for (i = 0; i < KVM_MAX_VCPUS; ++i) {
> if (kvm->vcpus[i]) {
> kvm_arch_vcpu_free(kvm->vcpus[i]);
> @@ -310,6 +322,27 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
> return 0;
> }
>
> +void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu)
> +{
> + int *last_ran;
> +
> + last_ran = per_cpu_ptr(vcpu->kvm->arch.last_vcpu_ran, cpu);
> +
> + /*
> + * If we're very unlucky and get preempted before having ran
> + * this vcpu for real, we'll end-up in a situation where any
> + * vcpu that gets scheduled will perform an invalidation (this
> + * vcpu explicitely requires it, and all the others will have
> + * a different vcpu_id).
> + */
> + if (*last_ran != vcpu->vcpu_id) {
> + if (*last_ran != -1)
> + vcpu->arch.requires_tlbi = true;
> +
> + *last_ran = vcpu->vcpu_id;
> + }
> +}
> +
> void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> {
> vcpu->cpu = cpu;
> diff --git a/arch/arm/kvm/hyp/switch.c b/arch/arm/kvm/hyp/switch.c
> index 92678b7..ab8ee3b 100644
> --- a/arch/arm/kvm/hyp/switch.c
> +++ b/arch/arm/kvm/hyp/switch.c
> @@ -75,6 +75,15 @@ static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
> {
> struct kvm *kvm = kern_hyp_va(vcpu->kvm);
> write_sysreg(kvm->arch.vttbr, VTTBR);
> + if (vcpu->arch.requires_tlbi) {
> + /* Force vttbr to be written */
> + isb();
> + /* Local invalidate only for this VMID */
> + write_sysreg(0, TLBIALL);
> + dsb(nsh);
> + vcpu->arch.requires_tlbi = false;
> + }
> +
> write_sysreg(vcpu->arch.midr, VPIDR);
> }
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index bd94e67..5b42010 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -62,6 +62,8 @@ struct kvm_arch {
> /* VTTBR value associated with above pgd and vmid */
> u64 vttbr;
>
> + int __percpu *last_vcpu_ran;
> +
> /* The maximum number of vCPUs depends on the used GIC model */
> int max_vcpus;
>
> @@ -252,6 +254,9 @@ struct kvm_vcpu_arch {
> /* vcpu power-off state */
> bool power_off;
>
> + /* TLBI required */
> + bool requires_tlbi;
> +
> /* Don't run the guest (internal implementation need) */
> bool pause;
>
> @@ -368,7 +373,6 @@ static inline void __cpu_reset_hyp_mode(unsigned long vector_ptr,
> static inline void kvm_arch_hardware_unsetup(void) {}
> static inline void kvm_arch_sync_events(struct kvm *kvm) {}
> static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
> -static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
> static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
>
> void kvm_arm_init_debug(void);
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 83037cd..8d9c3eb 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -131,6 +131,14 @@ static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
> {
> struct kvm *kvm = kern_hyp_va(vcpu->kvm);
> write_sysreg(kvm->arch.vttbr, vttbr_el2);
> + if (vcpu->arch.requires_tlbi) {
> + /* Force vttbr_el2 to be written */
> + isb();
> + /* Local invalidate only for this VMID */
> + asm volatile("tlbi vmalle1" : : );
> + dsb(nsh);
> + vcpu->arch.requires_tlbi = false;
> + }
> }
>
> static void __hyp_text __deactivate_vm(struct kvm_vcpu *vcpu)
> --
> 2.1.4
>
^ permalink raw reply
* [RFC PATCH 5/5] of: overlay-mgr: add a detector for headers stored on a ds2431 eeprom over w1
From: Matthias Brugger @ 2016-10-27 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026145756.21689-6-antoine.tenart@free-electrons.com>
On 10/26/2016 04:57 PM, Antoine Tenart wrote:
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> ---
Please provide a commit message.
Thanks,
Matthias
^ permalink raw reply
* [PATCH 01/18] 32-bit ABI: introduce ARCH_32BIT_OFF_T config option
From: Yury Norov @ 2016-10-27 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22426495.JIjM4XpfGo@wuerfel>
On Tue, Oct 25, 2016 at 12:22:47AM +0200, Arnd Bergmann wrote:
> On Monday, October 24, 2016 12:30:47 PM CEST Chris Metcalf wrote:
> > On 10/21/2016 4:33 PM, Yury Norov wrote:
> > > All new 32-bit architectures should have 64-bit off_t type, but existing
> > > architectures has 32-bit ones.
> > >
> > > [...]
> > > For syscalls sys_openat() and sys_open_by_handle_at() force_o_largefile()
> > > is called, to set O_LARGEFILE flag, and this is the only difference
> > > comparing to compat versions. All compat ABIs are already turned to use
> > > 64-bit off_t, except tile. So, compat versions for this syscalls are not
> > > needed anymore. Tile is handled explicitly.
> > >
> > > [...]
> > > --- a/arch/tile/kernel/compat.c
> > > +++ b/arch/tile/kernel/compat.c
> > > @@ -103,6 +103,9 @@ COMPAT_SYSCALL_DEFINE5(llseek, unsigned int, fd, unsigned int, offset_high,
> > > #define compat_sys_readahead sys32_readahead
> > > #define sys_llseek compat_sys_llseek
> > >
> > > +#define sys_openat compat_sys_openat
> > > +#define sys_open_by_handle_at compat_sys_open_by_handle_at
> > > +
> > > /* Call the assembly trampolines where necessary. */
> > > #define compat_sys_rt_sigreturn _compat_sys_rt_sigreturn
> > > #define sys_clone _sys_clone
> >
> > This patch accomplishes two goals that could be completely separated.
> > It's confusing to have them mixed in the same patch without any
> > discussion of why they are in the same patch.
> >
> > First, you want to modify the default <asm/unistd.h> behavior for
> > compat syscalls so that the default is sys_openat (etc) rather than
> > the existing compat_sys_openat, and then use that new behavior for
> > arm64 ILP32. This lets you force O_LARGEFILE for arm64 ILP32 to
> > support having a 64-bit off_t at all times. To do that, you fix the
> > asm-generic header, and then make tile have a special override.
> > This seems reasonable enough.
> >
> > Second, you introduce ARCH_32BIT_OFF_T basically as a synonym for
> > "BITS_PER_WORD == 32", so that new 32-bit architectures can choose not
> > to enable it. This is fine in the abstract, but I'm a bit troubled by
> > the fact that you are not actually introducing a new 32-bit
> > architecture here (just a new 32-bit mode for the arm 64-bit kernel).
> > Shouldn't this part of the change wait until someone actually has a
> > new 32-bit kernel to drive this forward?
>
> I asked for this specifically because we identified the problem
> during the review of the aarch64 ilp32 code, and it might not
> be noticed in the next architecture submission.
>
> The most important aspect from my perspective is that the new
> ilp32 ABI on aarch64 behaves the same way that any native 32-bit
> architecture does, and when we change the default, it should
> be done for both compat mode and native mode at the same time.
>
> > If you want to push forward the ARCH_32BIT_OFF_T change in the absence
> > of an architecture that supports it, I would think it would be a lot
> > less confusing to have these two in separate patches, and make it
> > clear that the ARCH_32BIT_OFF_T change is just laying groundwork
> > for some hypothetical future architecture.
> >
> > The existing commit language itself is also confusing. You write "All
> > compat ABIs are already turned to use 64-bit off_t, except tile."
> > First, I'm not sure what you mean by "turned" here. And, tile is just
> > one of many compat ABIs that allow O_LARGEFILE not to be part of the
> > open call: see arm64's AArch32 ABI, MIPS o32, s390 31-bit emulation,
> > sparc64's 32-bit mode, and of course x86's 32-bit compat mode.
> > Presumably your point here is that tile is the only pre-existing
> > architecture that #includes <asm/unistd.h> to create its compat
> > syscall table, and so I think "all except tile" here is particularly
> > confusing, since there are no architectures except tile that use the
> > __SYSCALL_COMPAT functionality in the current tree.
>
> Agreed, this could be made clearer, and splitting the patch up
> in two also seems reasonable, though I didn't see it as important.
>
> Arnd
In the past it was a separated series of 2 patches, and it was even
acked by Arnd, but not submitted.
http://lists-archives.com/linux-kernel/28471253-32-bit-abi-introduce-arch_32bit_off_t-config-option.html
I can restore that small series in aarch64/ilp32 for next iteration, or resend
it separately if you think to submit it before aarch64/ilp32 (which is
better, for me).
Yury
^ permalink raw reply
* [GIT PULL] ARM: keystone: add TI SCI protocol support for v4.10
From: Tero Kristo @ 2016-10-27 9:30 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof, Kevin,
This pull introduces the TI SCI protocol support for keystone family of
devices, targeted for v4.10 merge window. We discussed with Santosh
(keystone maintainer) that it would probably be better that I'll be
sending the pull requests for this directly, avoiding one extra step of
merges.
-Tero
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://github.com/t-kristo/linux-pm.git for-4.10-ti-sci-base
for you to fetch changes up to 912cffb4ed8612dc99ee0251cc0c9785855162cd:
firmware: ti_sci: Add support for reboot core service (2016-10-27
12:09:12 +0300)
----------------------------------------------------------------
Nishanth Menon (5):
Documentation: Add support for TI System Control Interface
(TI-SCI) protocol
firmware: Add basic support for TI System Control Interface
(TI-SCI) protocol
firmware: ti_sci: Add support for Device control
firmware: ti_sci: Add support for Clock control
firmware: ti_sci: Add support for reboot core service
.../devicetree/bindings/arm/keystone/ti,sci.txt | 81 +
MAINTAINERS | 10 +
drivers/firmware/Kconfig | 15 +
drivers/firmware/Makefile | 1 +
drivers/firmware/ti_sci.c | 1991
++++++++++++++++++++
drivers/firmware/ti_sci.h | 492 +++++
include/linux/soc/ti/ti_sci_protocol.h | 249 +++
7 files changed, 2839 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
create mode 100644 drivers/firmware/ti_sci.c
create mode 100644 drivers/firmware/ti_sci.h
create mode 100644 include/linux/soc/ti/ti_sci_protocol.h
^ permalink raw reply
* [PATCH V4 2/3] ARM64 LPC: Add missing range exception for special ISA
From: zhichang.yuan @ 2016-10-27 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026222542.g4etrqesqb7febid@rob-hp-laptop>
Hi, Rob,
Thanks for your comments!
Please check the response blow.
BTW, Are there any comments from other maintainers/hackers??
Thanks in advance!
On 2016/10/27 6:25, Rob Herring wrote:
> On Thu, Oct 20, 2016 at 05:15:39PM +0800, zhichang.yuan wrote:
>> Currently if the range property is not specified of_translate_one
>> returns an error. There are some special devices that work on a
>> range of I/O ports where it's is not correct to specify a range
>> property as the cpu addresses are used by special accessors.
>> Here we add a new exception in of_translate_one to return
>> the cpu address if the range property is not there. The exception
>> checks if the parent bus is ISA and if the special accessors are
>> defined.
>>
>> Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
>> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
>> ---
>> arch/arm64/include/asm/io.h | 7 +++++++
>> arch/arm64/kernel/extio.c | 24 +++++++++++++++++++++++
>> drivers/of/address.c | 47 +++++++++++++++++++++++++++++++++++++++++++--
>> drivers/pci/pci.c | 6 +++---
>> include/linux/of_address.h | 17 ++++++++++++++++
>> 5 files changed, 96 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>> index 136735d..e480199 100644
>> --- a/arch/arm64/include/asm/io.h
>> +++ b/arch/arm64/include/asm/io.h
>> @@ -175,6 +175,13 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
>> #define outsl outsl
>>
>> DECLARE_EXTIO(l, u32)
>> +
>> +
>> +#define indirect_io_ison indirect_io_ison
>> +extern int indirect_io_ison(void);
>> +
>> +#define chk_indirect_range chk_indirect_range
>> +extern int chk_indirect_range(u64 taddr);
>> #endif
>>
>>
>> diff --git a/arch/arm64/kernel/extio.c b/arch/arm64/kernel/extio.c
>> index 80cafd5..55df8dc 100644
>> --- a/arch/arm64/kernel/extio.c
>> +++ b/arch/arm64/kernel/extio.c
>> @@ -19,6 +19,30 @@
>>
>> struct extio_ops *arm64_extio_ops;
>>
>> +/**
>> + * indirect_io_ison - check whether indirectIO can work well. This function only call
>> + * before the target I/O address was obtained.
>> + *
>> + * Returns 1 when indirectIO can work.
>> + */
>> +int indirect_io_ison()
>> +{
>> + return arm64_extio_ops ? 1 : 0;
>> +}
>> +
>> +/**
>> + * check_indirect_io - check whether the input taddr is for indirectIO.
>> + * @taddr: the io address to be checked.
>> + *
>> + * Returns 1 when taddr is in the range; otherwise return 0.
>> + */
>> +int chk_indirect_range(u64 taddr)
>> +{
>> + if (arm64_extio_ops->start > taddr || arm64_extio_ops->end < taddr)
>> + return 0;
>> +
>> + return 1;
>> +}
>>
>> BUILD_EXTIO(b, u8)
>>
>> diff --git a/drivers/of/address.c b/drivers/of/address.c
>> index 02b2903..0bee822 100644
>> --- a/drivers/of/address.c
>> +++ b/drivers/of/address.c
>> @@ -479,6 +479,39 @@ static int of_empty_ranges_quirk(struct device_node *np)
>> return false;
>> }
>>
>> +
>> +/*
>> + * Check whether the current device being translating use indirectIO.
>> + *
>> + * return 1 if the check is past, or 0 represents fail checking.
>> + */
>> +static int of_isa_indirect_io(struct device_node *parent,
>
> Make the return bool.
ok. will update it.
>
>> + struct of_bus *bus, __be32 *addr,
>> + int na, u64 *presult)
>> +{
>> + unsigned int flags;
>> + unsigned int rlen;
>> +
>> + /* whether support indirectIO */
>> + if (!indirect_io_ison())
>
> indirect_io_is_enabled() would be a bit more readable.
Ok.
>
>> + return 0;
>> +
>> + if (!of_bus_isa_match(parent))
>> + return 0;
>> +
>> + flags = bus->get_flags(addr);
>> + if (!(flags & IORESOURCE_IO))
>> + return 0;
>> +
>> + /* there is ranges property, apply the normal translation directly. */
>> + if (of_get_property(parent, "ranges", &rlen))
>> + return 0;
>> +
>> + *presult = of_read_number(addr + 1, na - 1);
>> +
>> + return chk_indirect_range(*presult);
>> +}
>> +
>> static int of_translate_one(struct device_node *parent, struct of_bus *bus,
>> struct of_bus *pbus, __be32 *addr,
>> int na, int ns, int pna, const char *rprop)
>> @@ -532,7 +565,7 @@ static int of_translate_one(struct device_node *parent, struct of_bus *bus,
>> }
>> memcpy(addr, ranges + na, 4 * pna);
>>
>> - finish:
>> +finish:
>
> This hunk is unrelated. Drop it.
Yes. Will drop this change.
>
>> of_dump_addr("parent translation for:", addr, pna);
>> pr_debug("with offset: %llx\n", (unsigned long long)offset);
>>
>> @@ -595,6 +628,15 @@ static u64 __of_translate_address(struct device_node *dev,
>> result = of_read_number(addr, na);
>> break;
>> }
>> + /*
>> + * For indirectIO device which has no ranges property, get
>> + * the address from reg directly.
>> + */
>> + if (of_isa_indirect_io(dev, bus, addr, na, &result)) {
>> + pr_info("isa indirectIO matched(%s)..addr = 0x%llx\n",
>> + of_node_full_name(dev), result);
>
> This should be debugging.
ok. will replace with pr_debug.
thanks!
Zhichang
>
>> + break;
>> + }
>>
>> /* Get new parent bus and counts */
>> pbus = of_match_bus(parent);
>> @@ -688,8 +730,9 @@ static int __of_address_to_resource(struct device_node *dev,
>> if (taddr == OF_BAD_ADDR)
>> return -EINVAL;
>> memset(r, 0, sizeof(struct resource));
>> - if (flags & IORESOURCE_IO) {
>> + if (flags & IORESOURCE_IO && taddr >= PCIBIOS_MIN_IO) {
>> unsigned long port;
>> +
>> port = pci_address_to_pio(taddr);
>> if (port == (unsigned long)-1)
>> return -EINVAL;
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index ba34907..1a08511 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -3263,7 +3263,7 @@ int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
>>
>> #ifdef PCI_IOBASE
>> struct io_range *range;
>> - resource_size_t allocated_size = 0;
>> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
>>
>> /* check if the range hasn't been previously recorded */
>> spin_lock(&io_range_lock);
>> @@ -3312,7 +3312,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
>>
>> #ifdef PCI_IOBASE
>> struct io_range *range;
>> - resource_size_t allocated_size = 0;
>> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
>>
>> if (pio > IO_SPACE_LIMIT)
>> return address;
>> @@ -3335,7 +3335,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t address)
>> {
>> #ifdef PCI_IOBASE
>> struct io_range *res;
>> - resource_size_t offset = 0;
>> + resource_size_t offset = PCIBIOS_MIN_IO;
>> unsigned long addr = -1;
>>
>> spin_lock(&io_range_lock);
>> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
>> index 3786473..0ba7e21 100644
>> --- a/include/linux/of_address.h
>> +++ b/include/linux/of_address.h
>> @@ -24,6 +24,23 @@ struct of_pci_range {
>> #define for_each_of_pci_range(parser, range) \
>> for (; of_pci_range_parser_one(parser, range);)
>>
>> +
>> +#ifndef indirect_io_ison
>> +#define indirect_io_ison indirect_io_ison
>> +static inline int indirect_io_ison(void)
>> +{
>> + return 0;
>> +}
>> +#endif
>> +
>> +#ifndef chk_indirect_range
>> +#define chk_indirect_range chk_indirect_range
>> +static inline int chk_indirect_range(u64 taddr)
>> +{
>> + return 0;
>> +}
>> +#endif
>> +
>> /* Translate a DMA address from device space to CPU space */
>> extern u64 of_translate_dma_address(struct device_node *dev,
>> const __be32 *in_addr);
>> --
>> 1.9.1
>>
>
> .
>
^ permalink raw reply
* [PATCH v2 2/9] dt-bindings: interrupt-controller: add DT binding for meson GPIO interrupt controller
From: Mark Rutland @ 2016-10-27 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026214234.4q6wmecehqh6q32o@rob-hp-laptop>
On Wed, Oct 26, 2016 at 04:42:35PM -0500, Rob Herring wrote:
> On Wed, Oct 19, 2016 at 05:21:13PM +0200, Jerome Brunet wrote:
> >
> > This commit adds the device tree bindings description for Amlogic's GPIO
> > interrupt controller available on the meson8, meson8b and gxbb SoC families
> >
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > ---
> > Rob, I did not include the Ack you gave for the RFC as bindings have slightly
> > changed. Only the interrupt property has be removed following a discussion I
> > had with Marc
>
> As Mark R already said, you should keep the interrupts property.
To be clear, the interrupt routing should be described *somehow*, though
I don't think the generic interrupts property is correct, as this is an
interrupt *router*, i.e. this device doesn't own the interrupt, it just
joins two parts of the line together (and so flags are meaningless).
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 0/4] Add DT support for DA8xx
From: Alexandre Bailon @ 2016-10-27 9:34 UTC (permalink / raw)
To: linux-arm-kernel
Changes in v2:
* Remove unrelated changes in patch 3
* Rename the device node in patch 4
Changes in v3:
* Fix few mistakes in DT binding sample
* Only build the device table if DT is enabled
Alexandre Bailon (1):
ARM: dts: da850: Add the usb otg device node
Petr Kulhavy (3):
dt/bindings: Add binding for the DA8xx MUSB driver
usb: musb: core: added helper function for parsing DT
usb: musb: da8xx: Add DT support for the DA8xx driver
.../devicetree/bindings/usb/da8xx-usb.txt | 43 ++++++++++++++++++++
arch/arm/boot/dts/da850-lcdk.dts | 8 ++++
arch/arm/boot/dts/da850.dtsi | 15 +++++++
drivers/usb/musb/da8xx.c | 46 ++++++++++++++++++++++
drivers/usb/musb/musb_core.c | 19 +++++++++
drivers/usb/musb/musb_core.h | 5 +++
6 files changed, 136 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt
--
2.7.3
^ permalink raw reply
* [PATCH v3 1/4] dt/bindings: Add binding for the DA8xx MUSB driver
From: Alexandre Bailon @ 2016-10-27 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477560847-8929-1-git-send-email-abailon@baylibre.com>
From: Petr Kulhavy <petr@barix.com>
DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
Signed-off-by: Petr Kulhavy <petr@barix.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
---
.../devicetree/bindings/usb/da8xx-usb.txt | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
new file mode 100644
index 0000000..ccb844a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
@@ -0,0 +1,43 @@
+TI DA8xx MUSB
+~~~~~~~~~~~~~
+For DA8xx/OMAP-L1x/AM17xx/AM18xx platforms.
+
+Required properties:
+~~~~~~~~~~~~~~~~~~~~
+ - compatible : Should be set to "ti,da830-musb".
+
+ - reg: Offset and length of the USB controller register set.
+
+ - interrupts: The USB interrupt number.
+
+ - interrupt-names: Should be set to "mc".
+
+ - dr_mode: The USB operation mode. Should be one of "host", "peripheral" or "otg".
+
+ - phys: Phandle for the PHY device
+
+ - phy-names: Should be "usb-phy"
+
+Optional properties:
+~~~~~~~~~~~~~~~~~~~~
+ - vbus-supply: Phandle to a regulator providing the USB bus power.
+
+Example:
+ usb_phy: usb-phy {
+ compatible = "ti,da830-usb-phy";
+ #phy-cells = <0>;
+ status = "okay";
+ };
+ usb0: usb at 200000 {
+ compatible = "ti,da830-musb";
+ reg = <0x00200000 0x10000>;
+ interrupts = <58>;
+ interrupt-names = "mc";
+
+ dr_mode = "host";
+ vbus-supply = <&usb_vbus>;
+ phys = <&usb_phy 0>;
+ phy-names = "usb-phy";
+
+ status = "okay";
+ };
--
2.7.3
^ permalink raw reply related
* [PATCH v3 2/4] usb: musb: core: added helper function for parsing DT
From: Alexandre Bailon @ 2016-10-27 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477560847-8929-1-git-send-email-abailon@baylibre.com>
From: Petr Kulhavy <petr@barix.com>
This adds the function musb_get_mode() to get the DT property "dr_mode"
Signed-off-by: Petr Kulhavy <petr@barix.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Tested-by: David Lechner <david@lechnology.com>
---
drivers/usb/musb/musb_core.c | 19 +++++++++++++++++++
drivers/usb/musb/musb_core.h | 5 +++++
2 files changed, 24 insertions(+)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 27dadc0..bba07e7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
#include <linux/io.h>
#include <linux/dma-mapping.h>
#include <linux/usb.h>
+#include <linux/usb/of.h>
#include "musb_core.h"
#include "musb_trace.h"
@@ -130,6 +131,24 @@ static inline struct musb *dev_to_musb(struct device *dev)
return dev_get_drvdata(dev);
}
+enum musb_mode musb_get_mode(struct device *dev)
+{
+ enum usb_dr_mode mode;
+
+ mode = usb_get_dr_mode(dev);
+ switch (mode) {
+ case USB_DR_MODE_HOST:
+ return MUSB_HOST;
+ case USB_DR_MODE_PERIPHERAL:
+ return MUSB_PERIPHERAL;
+ case USB_DR_MODE_OTG:
+ case USB_DR_MODE_UNKNOWN:
+ default:
+ return MUSB_OTG;
+ }
+}
+EXPORT_SYMBOL_GPL(musb_get_mode);
+
/*-------------------------------------------------------------------------*/
#ifndef CONFIG_BLACKFIN
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 2cb88a49..a406468 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -617,4 +617,9 @@ static inline void musb_platform_post_root_reset_end(struct musb *musb)
musb->ops->post_root_reset_end(musb);
}
+/* gets the "dr_mode" property from DT and converts it into musb_mode
+ * if the property is not found or not recognized returns MUSB_OTG
+ */
+extern enum musb_mode musb_get_mode(struct device *dev);
+
#endif /* __MUSB_CORE_H__ */
--
2.7.3
^ permalink raw reply related
* [PATCH v3 3/4] usb: musb: da8xx: Add DT support for the DA8xx driver
From: Alexandre Bailon @ 2016-10-27 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477560847-8929-1-git-send-email-abailon@baylibre.com>
From: Petr Kulhavy <petr@barix.com>
This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver
Signed-off-by: Petr Kulhavy <petr@barix.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Tested-by: David Lechner <david@lechnology.com>
---
drivers/usb/musb/da8xx.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 210b7e4..51ae3b6 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -6,6 +6,9 @@
* Based on the DaVinci "glue layer" code.
* Copyright (C) 2005-2006 by Texas Instruments
*
+ * DT support
+ * Copyright (c) 2016 Petr Kulhavy <petr@barix.com>
+ *
* This file is part of the Inventra Controller Driver for Linux.
*
* The Inventra Controller Driver for Linux is free software; you
@@ -433,6 +436,21 @@ static int da8xx_musb_exit(struct musb *musb)
return 0;
}
+static inline u8 get_vbus_power(struct device *dev)
+{
+ struct regulator *vbus_supply;
+ int current_uA;
+
+ vbus_supply = regulator_get_optional(dev, "vbus");
+ if (IS_ERR(vbus_supply))
+ return 255;
+ current_uA = regulator_get_current_limit(vbus_supply);
+ regulator_put(vbus_supply);
+ if (current_uA <= 0 || current_uA > 510000)
+ return 255;
+ return current_uA / 1000 / 2;
+}
+
static const struct musb_platform_ops da8xx_ops = {
.quirks = MUSB_DMA_CPPI | MUSB_INDEXED_EP,
.init = da8xx_musb_init,
@@ -458,6 +476,12 @@ static const struct platform_device_info da8xx_dev_info = {
.dma_mask = DMA_BIT_MASK(32),
};
+static const struct musb_hdrc_config da8xx_config = {
+ .ram_bits = 10,
+ .num_eps = 5,
+ .multipoint = 1,
+};
+
static int da8xx_probe(struct platform_device *pdev)
{
struct resource musb_resources[2];
@@ -465,6 +489,7 @@ static int da8xx_probe(struct platform_device *pdev)
struct da8xx_glue *glue;
struct platform_device_info pinfo;
struct clk *clk;
+ struct device_node *np = pdev->dev.of_node;
int ret;
glue = devm_kzalloc(&pdev->dev, sizeof(*glue), GFP_KERNEL);
@@ -486,6 +511,16 @@ static int da8xx_probe(struct platform_device *pdev)
glue->dev = &pdev->dev;
glue->clk = clk;
+ if (IS_ENABLED(CONFIG_OF) && np) {
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata->config = &da8xx_config;
+ pdata->mode = musb_get_mode(&pdev->dev);
+ pdata->power = get_vbus_power(&pdev->dev);
+ }
+
pdata->platform_ops = &da8xx_ops;
glue->usb_phy = usb_phy_generic_register();
@@ -536,11 +571,22 @@ static int da8xx_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id da8xx_id_table[] = {
+ {
+ .compatible = "ti,da830-musb",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, da8xx_id_table);
+#endif
+
static struct platform_driver da8xx_driver = {
.probe = da8xx_probe,
.remove = da8xx_remove,
.driver = {
.name = "musb-da8xx",
+ .of_match_table = of_match_ptr(da8xx_id_table),
},
};
--
2.7.3
^ permalink raw reply related
* [PATCH v3 4/4] ARM: dts: da850: Add the usb otg device node
From: Alexandre Bailon @ 2016-10-27 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477560847-8929-1-git-send-email-abailon@baylibre.com>
This adds the device tree node for the usb otg
controller present in the da850 family of SoC's.
This also enables the otg usb controller for the lcdk board.
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
arch/arm/boot/dts/da850.dtsi | 15 +++++++++++++++
2 files changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21..9f5040c 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -158,6 +158,14 @@
rx-num-evt = <32>;
};
+&usb_phy {
+ status = "okay";
+ };
+
+&usb0 {
+ status = "okay";
+};
+
&aemif {
pinctrl-names = "default";
pinctrl-0 = <&nand_pins>;
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f79e1b9..322a31a 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -372,6 +372,21 @@
>;
status = "disabled";
};
+ usb_phy: usb-phy {
+ compatible = "ti,da830-usb-phy";
+ #phy-cells = <1>;
+ status = "disabled";
+ };
+ usb0: usb at 200000 {
+ compatible = "ti,da830-musb";
+ reg = <0x200000 0x10000>;
+ interrupts = <58>;
+ interrupt-names = "mc";
+ dr_mode = "otg";
+ phys = <&usb_phy 0>;
+ phy-names = "usb-phy";
+ status = "disabled";
+ };
gpio: gpio at 226000 {
compatible = "ti,dm6441-gpio";
gpio-controller;
--
2.7.3
^ permalink raw reply related
* [PATCH 02/18] arm64: ilp32: add documentation on the ILP32 ABI for ARM64
From: Yury Norov @ 2016-10-27 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <352ff60e-3975-8421-3274-3a904c0ac642@mellanox.com>
Hi Chris,
Thank you for comments
On Mon, Oct 24, 2016 at 12:36:27PM -0400, Chris Metcalf wrote:
> On 10/21/2016 4:33 PM, Yury Norov wrote:
> >Based on Andrew Pinski's patch-series.
> >
> >Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
> >---
> > Documentation/arm64/ilp32.txt | 46 +++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 46 insertions(+)
> > create mode 100644 Documentation/arm64/ilp32.txt
> >
> >diff --git a/Documentation/arm64/ilp32.txt b/Documentation/arm64/ilp32.txt
> >new file mode 100644
> >index 0000000..b96c18f
> >--- /dev/null
> >+++ b/Documentation/arm64/ilp32.txt
> >@@ -0,0 +1,46 @@
> >+ILP32 AARCH64 SYSCALL ABI
> >+=========================
> >+
> >+This document describes the ILP32 syscall ABI and where it differs
> >+from the generic compat linux syscall interface.
> >+
> >+AARCH64/ILP32 userspace can potentially access top halves of registers that
> >+are passed as syscall arguments, so such registers (w0-w7) are deloused.
>
> I'm not sure what "potentially access" here means: I think what you want to say
> is that userspace can pass garbage in the top half, but you should be clearer about
> what you mean here.
Yes. Will change.
> Also, you shouldn't use "deloused" here, since it's not a term
> that's defined elsewhere in the kernel, even though it's been used colloquially on LKML.
> Provide an actual implementation definition, like "have their top 32 bits zeroed".
Agree.
In fact 'delouse' is used in the name of corresponding macro in
include/linux/compat.h:
29 #ifndef __SC_DELOUSE
30 #define __SC_DELOUSE(t,v) ((t)(unsigned long)(v))
31 #endif
But it's not for documentation.
>
> >+AARCH64/ILP32 provides next types turned to 64-bit (comparing to AARCH32):
>
> What does "turned" mean here? And I "next types" isn't standard English; you want
> to say something like "the following types". Likewise later with "next syscalls".
Thanks, will change.
Yury
^ permalink raw reply
* [PATCH v2 2/9] dt-bindings: interrupt-controller: add DT binding for meson GPIO interrupt controller
From: Jerome Brunet @ 2016-10-27 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027093205.GA27135@leverpostej>
On Thu, 2016-10-27 at 10:32 +0100, Mark Rutland wrote:
> On Wed, Oct 26, 2016 at 04:42:35PM -0500, Rob Herring wrote:
> >
> > On Wed, Oct 19, 2016 at 05:21:13PM +0200, Jerome Brunet wrote:
> > >
> > >
> > > This commit adds the device tree bindings description for
> > > Amlogic's GPIO
> > > interrupt controller available on the meson8, meson8b and gxbb
> > > SoC families
> > >
> > > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > > ---
> > > Rob, I did not include the Ack you gave for the RFC as bindings
> > > have slightly
> > > changed. Only the interrupt property has be removed following a
> > > discussion I
> > > had with Marc
> >
> > As Mark R already said, you should keep the interrupts property.
>
> To be clear, the interrupt routing should be described *somehow*,
> though
> I don't think the generic interrupts property is correct, as this is
> an
> interrupt *router*, i.e. this device doesn't own the interrupt, it
> just
> joins two parts of the line together (and so flags are meaningless).
>
> Thanks,
> Mark.
Indeed Mark,
I already rewritten the driver taking Marc's comment into account.
There will be 2 properties added to the DT:
?-?meson,upstream-interrupts : an array with the 8 gic interrupt used
as output of the controller
- ?meson,num-input-mux : the number of inputs (pads) available to the
muxes
I'm looking for solution to the "create mapping" issue we have in
pinctrl (patch 4) before posting a v3.
If you think these properties should be different, feel free to tell me
now.
Thx
Jerome
^ permalink raw reply
* [PATCH] arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
From: Marc Zyngier @ 2016-10-27 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027091906.GA14734@cbox>
Hi Christoffer,
On 27/10/16 10:19, Christoffer Dall wrote:
> On Mon, Oct 24, 2016 at 04:31:28PM +0100, Marc Zyngier wrote:
>> Architecturally, TLBs are private to the (physical) CPU they're
>> associated with. But when multiple vcpus from the same VM are
>> being multiplexed on the same CPU, the TLBs are not private
>> to the vcpus (and are actually shared across the VMID).
>>
>> Let's consider the following scenario:
>>
>> - vcpu-0 maps PA to VA
>> - vcpu-1 maps PA' to VA
>>
>> If run on the same physical CPU, vcpu-1 can hit TLB entries generated
>> by vcpu-0 accesses, and access the wrong physical page.
>>
>> The solution to this is to keep a per-VM map of which vcpu ran last
>> on each given physical CPU, and invalidate local TLBs when switching
>> to a different vcpu from the same VM.
>
> Just making sure I understand this: The reason you cannot rely on the
> guest doing the necessary distinction with ASIDs or invalidating the TLB
> is that a guest (which assumes it's running on hardware) can validly
> defer any neccessary invalidation until it starts running on other
> physical CPUs, but we do this transparently in KVM?
The guest wouldn't have to do any invalidation at all on real HW,
because the TLBs are strictly private to a physical CPU (only the
invalidation can be broadcast to the Inner Shareable domain). But when
we multiplex two vcpus on the same physical CPU, we break the private
semantics, and a vcpu could hit in the TLB entries populated by the
another one.
As we cannot segregate the TLB entries per vcpu (but only per VMID), the
workaround is to nuke all the TLBs for this VMID (locally only - no
broadcast) each time we find that two vcpus are sharing the same
physical CPU.
Is that clearer?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
From: Christoffer Dall @ 2016-10-27 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7541af85-05c4-25f9-2fa8-2eb7a0afbe84@arm.com>
On Thu, Oct 27, 2016 at 10:49:00AM +0100, Marc Zyngier wrote:
> Hi Christoffer,
>
> On 27/10/16 10:19, Christoffer Dall wrote:
> > On Mon, Oct 24, 2016 at 04:31:28PM +0100, Marc Zyngier wrote:
> >> Architecturally, TLBs are private to the (physical) CPU they're
> >> associated with. But when multiple vcpus from the same VM are
> >> being multiplexed on the same CPU, the TLBs are not private
> >> to the vcpus (and are actually shared across the VMID).
> >>
> >> Let's consider the following scenario:
> >>
> >> - vcpu-0 maps PA to VA
> >> - vcpu-1 maps PA' to VA
> >>
> >> If run on the same physical CPU, vcpu-1 can hit TLB entries generated
> >> by vcpu-0 accesses, and access the wrong physical page.
> >>
> >> The solution to this is to keep a per-VM map of which vcpu ran last
> >> on each given physical CPU, and invalidate local TLBs when switching
> >> to a different vcpu from the same VM.
> >
> > Just making sure I understand this: The reason you cannot rely on the
> > guest doing the necessary distinction with ASIDs or invalidating the TLB
> > is that a guest (which assumes it's running on hardware) can validly
> > defer any neccessary invalidation until it starts running on other
> > physical CPUs, but we do this transparently in KVM?
>
> The guest wouldn't have to do any invalidation at all on real HW,
> because the TLBs are strictly private to a physical CPU (only the
> invalidation can be broadcast to the Inner Shareable domain). But when
> we multiplex two vcpus on the same physical CPU, we break the private
> semantics, and a vcpu could hit in the TLB entries populated by the
> another one.
Such a guest would be using a mapping of the same VA with the same ASID
on two separate CPUs, each pointing to a separate PA. If it ever were
to, say, migrate a task, it would have to do invalidations then. Right?
Does Linux or other guests actually do this?
I would suspect Linux has to eventually invalidate those mappins if it
wants the scheduler to be allowed to freely move things around.
>
> As we cannot segregate the TLB entries per vcpu (but only per VMID), the
> workaround is to nuke all the TLBs for this VMID (locally only - no
> broadcast) each time we find that two vcpus are sharing the same
> physical CPU.
>
> Is that clearer?
Yes, the fix is clear, just want to make sure I understand that it's a
valid circumstance where this actually happens. But in either case, we
probably have to fix this to emulate the hardware correctly.
Another fix would be to allocate a VMID per VCPU I suppose, just to
introduce a terrible TLB hit ratio :)
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts
From: Sekhar Nori @ 2016-10-27 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1593441f-d147-4c91-8aab-8622dd8ced19@lechnology.com>
On Monday 24 October 2016 09:20 PM, David Lechner wrote:
> On 10/24/2016 06:58 AM, Sekhar Nori wrote:
>> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>>> This adds a device tree definition file for LEGO MINDSTORMS EV3.
>>
>> Thanks for the patch!
>>
>>>
>>> What is working:
>>>
>>> * Pin muxing
>>> * MicroSD card reader
>>> * UART on input port 1
>>>
>>> What is partially working:
>>>
>>> * Buttons - working after GPIO fix
>>> * LEDs - working after GPIO fix
>>> * Poweroff/reset - working after GPIO fix
>>
>> Is the GPIO fix something that will go in v4.9-rc cycle ?
>
> Not sure. This is still being discussed.
>
> http://www.gossamer-threads.com/lists/linux/kernel/2550178
>
>>
>>> * Flash memory - driver loads but can't read the block devices - this is
>>> probably due to the fact that we are not able to configure the SPI to
>>> use DMA via device tree
>>
>> Hmm, I would not have expected PIO mode to be so inefficient that you
>> are unable to even read the block device.
>
> I am getting a -EIO error. I haven't been able to trace down exactly
> what is causing it yet though.
Okay. Seems unrelated to DMA though. Will check the status of SPI on my
DA850 EVM once I get the chance.
>
>>
> ...
>>> +/ {
>>> + compatible = "lego,ev3", "ti,da850";
>>> + model = "LEGO MINDSTORMS EV3";
>>> +
>>> + soc at 1c00000 {
>>> + /*
>>> + * (ab)using pinctrl-single to disable all internal pullups/
>>> + * pulldowns on I/O.
>>> + */
>>> + pinmux at 22c00c {
>>> + compatible = "pinctrl-single";
>>> + reg = <0x22c00c 0x4>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + pinctrl-single,bit-per-mux;
>>> + pinctrl-single,register-width = <32>;
>>> + pinctrl-single,function-mask = <0xf>;
>>> + /*
>>> + * There is a bug in pinctrl-single that prevents us
>>> + * from setting function-mask to 1, so doing things
>>> + * in groups of 4. Doesn't really matter since we are
>>> + * disabling all at once anyway.
>>> + */
>>> +
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pupu_disable>;
>>> +
>>> + pupu_disable: pinmux_all_pins {
>>> + pinctrl-single,bits = <
>>> + 0x0 0x00000000 0xffffffff
>>> + >;
>>> + };
>>
>> Sigh. This is quite an abuse :)
>>
>> I know we don't have a good way to configure this in kernel today. And I
>> am surprised we never had to care about disabling pullups so far. Can
>> you clarify why you need it? I assume there is some contention you want
>> to avoid, but on which interface?
>
> The EV3 was designed with external pullup/pulldown everywhere. I know
> for certain that it breaks one of the buttons if you do not disable the
> internal ones. I imagine that it would have subtle effects elsewhere if
> they are not disabled.
>
> I have not gone through each pullup/pulldown bank individually, but it
> would not surprise me at all if there was at least one thing on most of
> them that would be adversely affected.
>
>>
>> I dont think this can be done this way using pinctrl-single. A small
>> driver to handle pullup/down control for da850 may have to be added to
>> drivers/pinctrl. It will be better to check with Linus Walleij on his
>> thoughts using a new thread ccing the pinctrl subsystem list as well.
>
> I will be glad to try to make a driver, but when I ran into this problem
> I could not find much information on how to handle banks of
> pullup/pulldown. Most of what I saw was for ones that can be
> individually controlled. If anyone knows something like this already
> that I could look at, it would be helpful to me.
pinctrl-single supports a different compatible "pinconf-single" which
supports the pinconf interface that can be used to set pullup and
pulldown bias.
Unfortunately, in case of AM18x, there are two registers to touch:
PUPD_ENA and PUPD_SEL. So I believe the pinctrl-single driver cannot be
used.
There are pinconf operations pin_config_group_{set|get}(). Based on
documentation these are meant to act on a group of pins. There are quite
a few drivers implementing this interface. Perhaps they can be used as
an example.
Also, this needs to be done in a way that can be used by other boards
too, so please move the common properties to da850.dtsi. Only the board
specific pullup/down configuration should be in this file.
>
>
>> [...]
>>
>>> + in1_pins: pinmux_in1_pins {
>>> + pinctrl-single,bits = <
>>> + /* GP0[15] */
>>> + 0x0 0x00000008 0x0000000f
>>> + /* GP0[2] */
>>> + 0x4 0x00800000 0x00f00000
>>> + /* GP2[2] */
>>> + 0x18 0x00800000 0x00f00000
>>> + /* GP8[10], GP8[11] */
>>> + 0x48 0x88000000 0xff000000
>>> + >;
>>> + };
>>
>> I see that this is not really used. Can you add these when you actually
>> use them. Looks like that applies to some other definitions like this
>> below.
>
> It will be possible to uses these gpios via sysfs (until a proper driver
> for input and output ports is merged). So how about I attach these to
> the gpio node for now?
pins are usually attached to the node that consumes the GPIO pins, not
to the gpio node itself.
If the pins are not connected to anything and can be used via gpio
sysfs, then "pinctrl hog" or "board level pinmux" is to be used.
Something like below:
+&pmx_core {
+ pinctrl-names = "default";
+ pinctrl-0 = <&in1_pins>;
+
+ in1_pins: pinmux_in1_pins {
+ pinctrl-single,bits = <
+ 0x0 0x00000008 0x0000000f
+ ...
+ >;
+ };
+};
That said, device tree is supposed to describe hardware and not change
depend on current driver support. So I would wait for the driver to get
merged before merging the pins that are used by it. It looks like you
wont be able to use the support in a meaningful way till then anyway.
>
>>
>>> +&ehrpwm1 {
>>> + status = "disabled";
>>
>> Hmm, disabled? Can you add this node when you actually use it?
>
> Not sure why I have this disabled. Like the gpios, the pwms can be used
> via sysfs, so I would like to leave them.
Okay, then please keep the node enabled.
>
>>
>>> + pinctrl-names = "default";
>>> + /* MBPWM, MAPWM */
>>> + pinctrl-0 = <&ehrpwm1a_pins>, <&ehrpwm1b_pins>;
>>> +};
>>> +
>>> +&ecap1 {
>>> + status = "disabled";
>>
>> same here and other places below.
>>
>>> + pinctrl-names = "default";
>>> + /* MDPWM */
>>> + pinctrl-0 = <&ecap1_pins>;
>>> +};
>>> +
>>> +&spi0 {
>>> + status = "okay";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
>>> + dmas = <&edma0 14 0>, <&edma0 15 0>;
>>> + dma-names = "rx", "tx";
>>> +
>>> + spi-flash at 0 {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + compatible = "n25q128a13", "jedec,spi-nor";
>>> + reg = <0>;
>>> + spi-max-frequency = <50000000>;
>>> + ti,spi-wdelay = <8>;
>>> +
>>> + partition at 0 {
>>> + label = "U-Boot";
>>> + reg = <0 0x40000>;
>>
>> Thats 256KB for U-Boot and MLO (I assume in concatenated AIS image). Is
>> that sufficient for future too? Moving partitions later is tough ask
>> because that means users will lose data when they upgrade the kernel
>> because of partitions moving around. Just a suggestion to keep future
>> U-Boot bloat in mind and not use a "just fits" number.
>
> The MLO is on an EEPROM in the EV3, so the U-Boot partition is just
> U-boot. The SoC boots from I2C, which then runs whatever is as 0x0 on
> the flash memory.
okay.
> This partition table matches the partition scheme used on the official
> LEGO firmware that ships with the devices. Most people running their own
> kernel will probably be loading it from a microSD card, leaving the
> official firmware intact and therefore will always have this partition
> table.
>
> My thinking is that if someone does want to use a different partitioning
> scheme, they can build their own U-Boot and configure it to modify the
> device tree with a new partition table.
>
> The way the LEGO firmware flashing utility works, it wipes out the
> entire flash memory each time you flash the firmware. So, data loss is
> not a concern - you will loose your data anyway.
Alright, thanks for the detailed explanation.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] arm64: defconfig: Enable DRM DU and V4L2 FCP + VSP modules
From: Simon Horman @ 2016-10-27 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANqRtoTizLGYSgY-EV_DwC+yeqeuAsuBKPwXXW6zqwqpHM3MfA@mail.gmail.com>
On Thu, Oct 27, 2016 at 04:37:53PM +0900, Magnus Damm wrote:
> Hi Simon,
>
> On Thu, Oct 27, 2016 at 4:15 PM, Simon Horman <horms@verge.net.au> wrote:
> > On Thu, Oct 27, 2016 at 09:08:01AM +0200, Simon Horman wrote:
> >> On Wed, Oct 26, 2016 at 02:24:22PM +0900, Magnus Damm wrote:
> >> > From: Magnus Damm <damm+renesas@opensource.se>
> >> >
> >> > Extend the ARM64 defconfig to enable the DU DRM device as module
> >> > together with required dependencies of V4L2 FCP and VSP modules.
> >> >
> >> > This enables VGA output on the r8a7795 Salvator-X board.
> >> >
> >> > Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> >>
> >> Thanks, I have queued this up.
> >
> > Given discussion elsewhere on enabling DU I am holding off on this for a
> > little; it is not queued up for now.
>
> Sure, thanks for holding off the DT integration patches for r8a7796.
> Please note that as of mainline v4.9-rc2 the r8a7795 Salvator-X board
> has thanks to DU, FCP and VSP a working VGA port. So enabling those
> devices in the defconfig from now on makes sense to me.
Understood, I will queue up this patch.
^ permalink raw reply
* [PATCH v6 00/16] ACPI IORT ARM SMMU support
From: Rafael J. Wysocki @ 2016-10-27 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026110459.GA15276@red-moon>
On Wed, Oct 26, 2016 at 1:04 PM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> Rafael, Joerg (and anyone else CC'ed),
>
> On Tue, Oct 18, 2016 at 05:03:58PM +0100, Lorenzo Pieralisi wrote:
>> This patch series is v6 of a previous posting:
>>
>> https://lkml.org/lkml/2016/9/9/418
>>
>> v5 -> v6
>> - Rebased against v4.9-rc1
>> - Changed FWNODE_IOMMU to FWNODE_ACPI_STATIC
>> - Moved platform devices creation into IORT code
>> - Updated fwnode handling
>> - Added default dma masks initialization
>
> Any comments on v6 ? Patches touching generic ACPI code
> are {1, 2, 7}, patch 4 updates the IOMMU of_iommu_{set/get}_ops()
> API to make it work on ACPI systems too, by replacing the
> device_node with a fwnode_handle pointer as look-up token;
> the remainder of patches are ARM specific and creates the
> infrastructure to probe ARM SMMU devices through ACPI,
> ARM IORT table in particular. Given the generic bits changes
> above I would not leave it to late -rc to reach an agreement
> please, thank you.
I'll do my best to look at these in the next few days, but please also
note what I wrote before:
http://marc.info/?l=linux-acpi&m=147744344531599&w=2
Thanks,
Rafael
^ permalink raw reply
* [PATCH v2 2/4] arm64: arch_timer: Introduce a generic erratum handing mechanism for fsl-a008585
From: Marc Zyngier @ 2016-10-27 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477553651-13428-2-git-send-email-dingtianhong@huawei.com>
On 27/10/16 08:34, Ding Tianhong wrote:
> The workaround for hisilicon,161601 will check the return value of the system counter
> by different way, in order to distinguish with the fsl-a008585 workaround, introduce
> a new generic erratum handing mechanism for fsl-a008585 and rename some functions.
>
> v2: Introducing a new generic erratum handling mechanism for fsl erratum a008585.
>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
> arch/arm64/include/asm/arch_timer.h | 20 +++++++++-----
> drivers/clocksource/arm_arch_timer.c | 51 +++++++++++++++++++++---------------
> 2 files changed, 43 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
> index eaa5bbe..118719d8 100644
> --- a/arch/arm64/include/asm/arch_timer.h
> +++ b/arch/arm64/include/asm/arch_timer.h
> @@ -31,15 +31,21 @@
>
> #if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585)
> extern struct static_key_false arch_timer_read_ool_enabled;
> -#define needs_fsl_a008585_workaround() \
> +#define needs_timer_erratum_workaround() \
> static_branch_unlikely(&arch_timer_read_ool_enabled)
This is too generic a name. Please make it more specific.
> #else
> -#define needs_fsl_a008585_workaround() false
> +#define needs_timer_erratum_workaround() false
> #endif
>
> -u32 __fsl_a008585_read_cntp_tval_el0(void);
> -u32 __fsl_a008585_read_cntv_tval_el0(void);
> -u64 __fsl_a008585_read_cntvct_el0(void);
> +
> +struct arch_timer_erratum_workaround {
> + int erratum;
What is the use of this field?
> + u32 (*read_cntp_tval_el0)(void);
> + u32 (*read_cntv_tval_el0)(void);
> + u64 (*read_cntvct_el0)(void);
> +};
> +
> +extern struct arch_timer_erratum_workaround *erratum_workaround;
This is a very generic name for something that has a global visibility.
Please choose a more specific variable name.
>
> /*
> * The number of retries is an arbitrary value well beyond the highest number
> @@ -62,8 +68,8 @@ u64 __fsl_a008585_read_cntvct_el0(void);
> #define arch_timer_reg_read_stable(reg) \
> ({ \
> u64 _val; \
> - if (needs_fsl_a008585_workaround()) \
> - _val = __fsl_a008585_read_##reg(); \
> + if (needs_timer_erratum_workaround()) \
> + _val = erratum_workaround->read_##reg(); \
As mentioned in my initial review, you've now broken modular access to
any of the registers. Please fix it.
> else \
> _val = read_sysreg(reg); \
> _val; \
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 73c487d..e4f7fa1 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -95,10 +95,32 @@ early_param("clocksource.arm_arch_timer.evtstrm", early_evtstrm_cfg);
> */
>
> #ifdef CONFIG_FSL_ERRATUM_A008585
> +struct arch_timer_erratum_workaround *erratum_workaround = NULL;
> +
> DEFINE_STATIC_KEY_FALSE(arch_timer_read_ool_enabled);
> EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled);
>
> -static int fsl_a008585_enable = -1;
> +
> +static u32 fsl_a008585_read_cntp_tval_el0(void)
> +{
> + return __fsl_a008585_read_reg(cntp_tval_el0);
> +}
> +
> +static u32 fsl_a008585_read_cntv_tval_el0(void)
> +{
> + return __fsl_a008585_read_reg(cntv_tval_el0);
> +}
> +
> +static u64 fsl_a008585_read_cntvct_el0(void)
> +{
> + return __fsl_a008585_read_reg(cntvct_el0);
> +}
So now that you've indirected all calls through a set of pointers, why
do you keep the __fsl_a008585_read_reg() macro inside the include file?
I don't think it has any purpose in being globally visible now.
> +
> +static struct arch_timer_erratum_workaround arch_timer_fsl_a008585 = {
And here's the proof that the erratum field is useless.
> + .read_cntp_tval_el0 = fsl_a008585_read_cntp_tval_el0,
> + .read_cntv_tval_el0 = fsl_a008585_read_cntv_tval_el0,
> + .read_cntvct_el0 = fsl_a008585_read_cntvct_el0,
> +};
>
> static int __init early_fsl_a008585_cfg(char *buf)
> {
> @@ -109,26 +131,12 @@ static int __init early_fsl_a008585_cfg(char *buf)
> if (ret)
> return ret;
>
> - fsl_a008585_enable = val;
> + if (val)
> + erratum_workaround = &arch_timer_fsl_a008585;
> +
> return 0;
> }
> early_param("clocksource.arm_arch_timer.fsl-a008585", early_fsl_a008585_cfg);
> -
> -u32 __fsl_a008585_read_cntp_tval_el0(void)
> -{
> - return __fsl_a008585_read_reg(cntp_tval_el0);
> -}
> -
> -u32 __fsl_a008585_read_cntv_tval_el0(void)
> -{
> - return __fsl_a008585_read_reg(cntv_tval_el0);
> -}
> -
> -u64 __fsl_a008585_read_cntvct_el0(void)
> -{
> - return __fsl_a008585_read_reg(cntvct_el0);
> -}
> -EXPORT_SYMBOL(__fsl_a008585_read_cntvct_el0);
> #endif /* CONFIG_FSL_ERRATUM_A008585 */
>
> static __always_inline
> @@ -891,9 +899,10 @@ static int __init arch_timer_of_init(struct device_node *np)
> arch_timer_c3stop = !of_property_read_bool(np, "always-on");
>
> #ifdef CONFIG_FSL_ERRATUM_A008585
> - if (fsl_a008585_enable < 0)
> - fsl_a008585_enable = of_property_read_bool(np, "fsl,erratum-a008585");
> - if (fsl_a008585_enable) {
> + if (!erratum_workaround && of_property_read_bool(np, "fsl,erratum-a008585"))
> + erratum_workaround = &arch_timer_fsl_a008585;
It used to be possible to disable the erratum workaround on the command
line, and you've just removed that feature. Please restore it.
> +
> + if (erratum_workaround) {
> static_branch_enable(&arch_timer_read_ool_enabled);
> pr_info("Enabling workaround for FSL erratum A-008585\n");
> }
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH V5 0/3] ACPI,PCI,IRQ: revert penalty calculation for ISA and SCI interrupts
From: Rafael J. Wysocki @ 2016-10-27 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477283492-26657-1-git-send-email-okaya@codeaurora.org>
On Mon, Oct 24, 2016 at 6:31 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
>
> By the time ACPI gets initialized, this code tries to determine an
> IRQ number based on penalty values in this array. It will try to locate
> the IRQ with the least penalty assignment so that interrupt sharing is
> avoided if possible.
>
> A couple of notes about the external APIs:
> 1. These API can be called before the ACPI is started. Therefore, one
> cannot assume that the PCI link objects are initialized for calculating
> penalties.
> 2. The polarity and trigger information passed via the
> acpi_penalize_sci_irq from the BIOS may not match what the IRQ subsystem
> is reporting as the call might have been placed before the IRQ is
> registered by the interrupt subsystem.
>
> The reverted changes were in the direction to remove these external API and
> try to calculate the penalties at runtime for the ISA, SCI as well as PCI
> IRQS.
> This didn't work out well with the existing platforms.
>
> V5:
> * clean up the commit message for 1/3 and 2/3
> * drop 3/3
> * bring back ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts as 3/3
>
> V4:
> https://www.spinics.net/lists/arm-kernel/msg537158.html
> * Drop ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
> * A new patch to isolate early boot ISA penalty calculations from dynamic
> penalty calculation by directly modifying the array members in
> ("ACPI, PCI, IRQ: assign ISA IRQ directly during early boot stages")
> * Now that we isolated both SCI and ISA interrupts, revert commit ("Revert
> "ACPI,PCI,IRQ: separate ISA penalty calculation"") and commit
> ("487cf917ed0d
> (Revert "ACPI, PCI, IRQ: remove redundant code in acpi_irq_penalty_init()")
> to share code between ISA and PCI penalties as originally intended.
>
> V3:
> http://www.spinics.net/lists/arm-kernel/msg536208.html
> * drop patch #1 as discussed with Bjorn
> * add patch #3 to track SCI irq and penalty separately
>
> V2: https://lkml.org/lkml/2016/10/1/106
> * Commit message updates
>
> V1:
> http://lists-archives.com/linux-kernel/28673954-revert-acpi-pci-irq-reduce-static-irq-array-size-to-16.html
> * initial implementation
>
> Sinan Kaya (3):
> ACPI, PCI, IRQ: assign ISA IRQ directly during early boot stages
> ACPI: pci_link: penalize SCI correctly
> ACPI: pci_link: Include PIRQ_PENALTY_PCI_USING for ISA IRQs
>
> arch/x86/kernel/acpi/boot.c | 1 +
> drivers/acpi/pci_link.c | 38 +++++++++++++++++++++-----------------
> include/linux/acpi.h | 1 +
> 3 files changed, 23 insertions(+), 17 deletions(-)
I've queued up this series for the next ACPI pull request with 4.9 fixes.
Thanks,
Rafael
^ permalink raw reply
* [PATCH] arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
From: Marc Zyngier @ 2016-10-27 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027100428.GA17829@cbox>
On 27/10/16 11:04, Christoffer Dall wrote:
> On Thu, Oct 27, 2016 at 10:49:00AM +0100, Marc Zyngier wrote:
>> Hi Christoffer,
>>
>> On 27/10/16 10:19, Christoffer Dall wrote:
>>> On Mon, Oct 24, 2016 at 04:31:28PM +0100, Marc Zyngier wrote:
>>>> Architecturally, TLBs are private to the (physical) CPU they're
>>>> associated with. But when multiple vcpus from the same VM are
>>>> being multiplexed on the same CPU, the TLBs are not private
>>>> to the vcpus (and are actually shared across the VMID).
>>>>
>>>> Let's consider the following scenario:
>>>>
>>>> - vcpu-0 maps PA to VA
>>>> - vcpu-1 maps PA' to VA
>>>>
>>>> If run on the same physical CPU, vcpu-1 can hit TLB entries generated
>>>> by vcpu-0 accesses, and access the wrong physical page.
>>>>
>>>> The solution to this is to keep a per-VM map of which vcpu ran last
>>>> on each given physical CPU, and invalidate local TLBs when switching
>>>> to a different vcpu from the same VM.
>>>
>>> Just making sure I understand this: The reason you cannot rely on the
>>> guest doing the necessary distinction with ASIDs or invalidating the TLB
>>> is that a guest (which assumes it's running on hardware) can validly
>>> defer any neccessary invalidation until it starts running on other
>>> physical CPUs, but we do this transparently in KVM?
>>
>> The guest wouldn't have to do any invalidation at all on real HW,
>> because the TLBs are strictly private to a physical CPU (only the
>> invalidation can be broadcast to the Inner Shareable domain). But when
>> we multiplex two vcpus on the same physical CPU, we break the private
>> semantics, and a vcpu could hit in the TLB entries populated by the
>> another one.
>
> Such a guest would be using a mapping of the same VA with the same ASID
> on two separate CPUs, each pointing to a separate PA. If it ever were
> to, say, migrate a task, it would have to do invalidations then. Right?
This doesn't have to be ASID tagged. Actually, it is more likely to
affect global mappings. Imagine for example that the kernel (which uses
global mappings for its own page tables) decides to create per-cpu
variable using this trick (all the CPUs have the same VA, but use
different PAs). No invalidation at all, everything looks perfectly fine,
until you start virtualizing it.
> Does Linux or other guests actually do this?
Linux may hit it with CPU hotplug, which uses global mappings (which a
vcpu using an ASID tagged mapping could then hit if the VAs overlap).
>
> I would suspect Linux has to eventually invalidate those mappins if it
> wants the scheduler to be allowed to freely move things around.
>
>>
>> As we cannot segregate the TLB entries per vcpu (but only per VMID), the
>> workaround is to nuke all the TLBs for this VMID (locally only - no
>> broadcast) each time we find that two vcpus are sharing the same
>> physical CPU.
>>
>> Is that clearer?
>
> Yes, the fix is clear, just want to make sure I understand that it's a
> valid circumstance where this actually happens. But in either case, we
> probably have to fix this to emulate the hardware correctly.
>
> Another fix would be to allocate a VMID per VCPU I suppose, just to
> introduce a terrible TLB hit ratio :)
But that would break TLB invalidations that are broadcast in the Inner
Shareable domain. To do so, you'd have to trap every TBLI, and issue
corresponding invalidations for all the vcpus. I'm not sure I want to
see the performance number of that solution... ;-)
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 4/9] pinctrl: meson: allow gpio to request irq
From: Jerome Brunet @ 2016-10-27 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZR8T8W5WMmEJVhPR0sUQyfPzgHpjhDiRsyXvybKDYJWQ@mail.gmail.com>
On Wed, 2016-10-26 at 16:44 +0200, Linus Walleij wrote:
> On Wed, Oct 26, 2016 at 4:23 PM, Jerome Brunet <jbrunet@baylibre.com>
> wrote:
> >
> > [Me]
> > >
> > > We usually refer to the local numberspace on the GPIO controller
> > > as "offsets", so line offsets 0...31 on a gpiochip with 31 lines.
> > >
> > > The ngpio in struct gpio_chip is the number of lines on that
> > > controller,
> > > and should nominally map 1:1 to hwirq sources.
> >
> > Indeed it should be the the case, and for meson, it is pretty
> > close.
> > The irqchip controller provide a number of hwirq. Each hwirq maps
> > to
> > one, and only one, pin. But since not every pins are connected to
> > the
> > irqchip controller, the opposite is not true.
> >
> > Taking an example with 16 gpios, here is what it could look like
> > with
> > the exception we have on meson :
> >
> > gpio offset [ 0??1??2??3??4??5??6??7??8??9??10 11 12 13 14 15 ]
> > hwirq num???[ 0??1??2??3] NC NC[4??5??6??7??8??9??10]NC NC NC
> >
> > Like gpio offset are used (internally) in the driver to find
> > appropriate gpio registers and bit, the hwirq has a meaning too.
> > It is the setting you put in the channel multiplexer of the
> > controller
> > to select the proper pin to spy on.
> >
> > In the end, these gpio offset and hwirq number are different. I
> > would
> > prefer to have hwirq == gpio and go your way, it would make my life
> > easier, but I don't see how it would work.
> >
> > The irqchip controller cares only about the hwirq number. You can
> > actually request an interrupt directly to the controller by asking
> > the
> > proper hwirq number (in DT for example), without involving the gpio
> > driver (tested).
> >
> > The relation between the pins and the interrupt number is provided
> > by
> > the manufacturer in the Datasheet [1], in the section GPIO
> > Interrupt.
>
> I think I kind of get it.
>
> This reminds me of recent patches to the generic GPIOLIB_IRQCHIP
> where we made it possible to "mask" set of IRQ lines, saying
> "these are in the irqdomain, but you cannot map them".
>
> See
> commit 79b804cb6af4f128b2c53f0887c02537a7eb5824
> "gpiolib: Make it possible to exclude GPIOs from IRQ domain"
> commit 96b2cca64fa3e1a31b573bb308b2944c802aacf3
> "gpio: stmpe: forbid unused lines to be mapped as IRQs"
>
> So what we do in the generic case is put a linear map over all
> the lines/offsets, then punch holes in that map and say
> "this and this and this can not be mapped as IRQ".
>
> As you can see in _gpiochip_irqchip_add() we pre-map all
> except those with irq_create_mapping().
>
> Does this scheme fit with your usecase? I would guess so,
> just that your domain is hierarchic, not simple/linear.
Thanks for pointing this out, however I don't think this solve my
issue. I'll try to be as clear as possible but feel free to ask me
question if needed:
Ressource issue : When you create an irq mapping, in case of hierarchic
domain, it calls the "alloc" function of the domain, which will
eventually call the "alloc" function of the parent domain ... until you
reach the "root" domain (here the gic).
The particular HW at hand (meson gpio interrupt controller) is a set of
8 muxes (or channels). Each channel output its signal on 1 specific GIC
input. Its the HW wiring, not programmable.
The inputs are the all pad that can be seen by the controller (*almost*
all the SoC gpio, but not all, as explain earlier). When you call
"alloc", the driver find an available channel, set the mux input to
forward the appropriate signal to the GIC.
As you may understand, the driver can accept only 8 mappings at a time
before being out of GIC irqs, and returning -ENOSPC.
If we were trying the use the punch hole method, we would have to know
at boot time the only eight pin we want, and this for every platform.
Also there not might be 8 available to the gpio subsys, since someone
could request an irq directly to controller, w/o going through the gpio
subsys. This would be putting restriction on the gpio because of an
issue in the controller. This looks very complicated to setup, static
and platform specific. That's not really what we were aiming for.
We are looking to create mapping "on-demand" to make the best use of
the little number of interrupts we have. To catch request of drivers,
like gpio-keys, which use gpio_to_irq, it looks the only viable place
is the to_irq callback (at the moment).
Drivers using gpio_to_irq in their probe function expect that this will
give them the corresponding virq, so create the mapping if need be.
However, I now get why you don't want that, it seems we have 2 types of
platforms in the kernel right now:?
1. The one creating the mapping in the to_irq callback. It might be
because they just copy/paste from another driver doing it, or they may
have a good reason for it (like I think we do)
2. the one which call gpio_to_irq in interrupt handlers. Honestly I did
not know that one could that, but they are in the mainline too, and
probably have a good reason for doing it.
irq_find_mapping looks safe in interrupt handler, I does not seem to
sleep (please correct me if I'm wrong).
irq_create_mapping definitely isn't, because of the irq_domain mutex.
We probably got into this situation because it wasn't clear enough
whether to_irq was fast or slow (at least it took me a few mails to
understand this ...)
The two platform groups are most likely exclusive so nobody is sleeping
in irq, everybody is happy. As a maintainer, I understand that you
can't allow a dangerous situation like this to continue.
To fix the situation we could add a few things in the gpio subsys:
- Make it clear that to_irq is fast (like you just did)
- add a new callback (to_irq_slow ? provide_irq ? something else) which
would be allowed to sleep and create mappings.
- in gpio_to_irq function keeps calling to_irq like it does but also
call to_irq_slow only if we are not in an interrupt context and a
mapping could not be found. We could maybe use "in_interrupt()" for
this ?
This way, we could keep the existing drivers working as they are (even
if they are wrong) and slowly fix things up.
What do you think about this ? Do you have something else in mind ?
I'd be happy to help on this.
Sorry, it was kind of long explanation but I hope things are more clear
now.
>
> Maybe the takeaway is that your map does not need to
> be "dense", i.e. every hwirq is in use. It can be sparse.
> It is stored in a radix tree anyways.
>
> >
> > Looking at other gpio drivers, it is not uncommon to have some
> > simple
> > calculation to get from gpio offset to the hwirq number. I don't
> > get
> > what is the specific problem here ?
>
> It's OK to use the offset vs hwirq.
>
> I just misunderstand it as the global GPIO number, that is
> not OK.
Ok. Just to be clear, you are ok with the function
"meson_gpio_to_hwirq" which just does this translation, right ?
>
> Yours,
> Linus Walleij
Cheers
Jerome
^ 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