* [PATCH 08/11] arm64: KVM: Use per-CPU vector when BP hardening is enabled
From: Ard Biesheuvel @ 2018-01-04 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-9-git-send-email-will.deacon@arm.com>
On 4 January 2018 at 15:08, Will Deacon <will.deacon@arm.com> wrote:
> From: Marc Zyngier <marc.zyngier@arm.com>
>
> Now that we have per-CPU vectors, let's plug then in the KVM/arm64 code.
>
Why does bp hardening require per-cpu vectors?
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/include/asm/kvm_mmu.h | 10 ++++++++++
> arch/arm64/include/asm/kvm_mmu.h | 38 ++++++++++++++++++++++++++++++++++++++
> arch/arm64/kvm/hyp/switch.c | 2 +-
> virt/kvm/arm/arm.c | 8 +++++++-
> 4 files changed, 56 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> index fa6f2174276b..eb46fc81a440 100644
> --- a/arch/arm/include/asm/kvm_mmu.h
> +++ b/arch/arm/include/asm/kvm_mmu.h
> @@ -221,6 +221,16 @@ static inline unsigned int kvm_get_vmid_bits(void)
> return 8;
> }
>
> +static inline void *kvm_get_hyp_vector(void)
> +{
> + return kvm_ksym_ref(__kvm_hyp_vector);
> +}
> +
> +static inline int kvm_map_vectors(void)
> +{
> + return 0;
> +}
> +
> #endif /* !__ASSEMBLY__ */
>
> #endif /* __ARM_KVM_MMU_H__ */
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index 672c8684d5c2..2d6d4bd9de52 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -309,5 +309,43 @@ static inline unsigned int kvm_get_vmid_bits(void)
> return (cpuid_feature_extract_unsigned_field(reg, ID_AA64MMFR1_VMIDBITS_SHIFT) == 2) ? 16 : 8;
> }
>
> +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
> +#include <asm/mmu.h>
> +
> +static inline void *kvm_get_hyp_vector(void)
> +{
> + struct bp_hardening_data *data = arm64_get_bp_hardening_data();
> + void *vect = kvm_ksym_ref(__kvm_hyp_vector);
> +
> + if (data->fn) {
> + vect = __bp_harden_hyp_vecs_start +
> + data->hyp_vectors_slot * SZ_2K;
> +
> + if (!has_vhe())
> + vect = lm_alias(vect);
> + }
> +
> + return vect;
> +}
> +
> +static inline int kvm_map_vectors(void)
> +{
> + return create_hyp_mappings(kvm_ksym_ref(__bp_harden_hyp_vecs_start),
> + kvm_ksym_ref(__bp_harden_hyp_vecs_end),
> + PAGE_HYP_EXEC);
> +}
> +
> +#else
> +static inline void *kvm_get_hyp_vector(void)
> +{
> + return kvm_ksym_ref(__kvm_hyp_vector);
> +}
> +
> +static inline int kvm_map_vectors(void)
> +{
> + return 0;
> +}
> +#endif
> +
> #endif /* __ASSEMBLY__ */
> #endif /* __ARM64_KVM_MMU_H__ */
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index f7c651f3a8c0..8d4f3c9d6dc4 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -52,7 +52,7 @@ static void __hyp_text __activate_traps_vhe(void)
> val &= ~(CPACR_EL1_FPEN | CPACR_EL1_ZEN);
> write_sysreg(val, cpacr_el1);
>
> - write_sysreg(__kvm_hyp_vector, vbar_el1);
> + write_sysreg(kvm_get_hyp_vector(), vbar_el1);
> }
>
> static void __hyp_text __activate_traps_nvhe(void)
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index 6b60c98a6e22..1c9fdb6db124 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -1158,7 +1158,7 @@ static void cpu_init_hyp_mode(void *dummy)
> pgd_ptr = kvm_mmu_get_httbr();
> stack_page = __this_cpu_read(kvm_arm_hyp_stack_page);
> hyp_stack_ptr = stack_page + PAGE_SIZE;
> - vector_ptr = (unsigned long)kvm_ksym_ref(__kvm_hyp_vector);
> + vector_ptr = (unsigned long)kvm_get_hyp_vector();
>
> __cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
> __cpu_init_stage2();
> @@ -1403,6 +1403,12 @@ static int init_hyp_mode(void)
> goto out_err;
> }
>
> + err = kvm_map_vectors();
> + if (err) {
> + kvm_err("Cannot map vectors\n");
> + goto out_err;
> + }
> +
> /*
> * Map the Hyp stack pages
> */
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH 11/11] arm64: Implement branch predictor hardening for affected Cortex-A CPUs
From: Ard Biesheuvel @ 2018-01-04 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-12-git-send-email-will.deacon@arm.com>
On 4 January 2018 at 15:08, Will Deacon <will.deacon@arm.com> wrote:
> Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing
> and can theoretically be attacked by malicious code.
>
> This patch implements a PSCI-based mitigation for these CPUs when available.
> The call into firmware will invalidate the branch predictor state, preventing
> any malicious entries from affecting other victim contexts.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/kernel/bpi.S | 24 ++++++++++++++++++++++++
> arch/arm64/kernel/cpu_errata.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 66 insertions(+)
>
> diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S
> index 06a931eb2673..2b10d52a0321 100644
> --- a/arch/arm64/kernel/bpi.S
> +++ b/arch/arm64/kernel/bpi.S
> @@ -53,3 +53,27 @@ ENTRY(__bp_harden_hyp_vecs_start)
> vectors __kvm_hyp_vector
> .endr
> ENTRY(__bp_harden_hyp_vecs_end)
> +ENTRY(__psci_hyp_bp_inval_start)
> + stp x0, x1, [sp, #-16]!
> + stp x2, x3, [sp, #-16]!
> + stp x4, x5, [sp, #-16]!
> + stp x6, x7, [sp, #-16]!
> + stp x8, x9, [sp, #-16]!
> + stp x10, x11, [sp, #-16]!
> + stp x12, x13, [sp, #-16]!
> + stp x14, x15, [sp, #-16]!
> + stp x16, x17, [sp, #-16]!
> + stp x18, x19, [sp, #-16]!
Would it be better to update sp only once here?
Also, do x18 and x19 need to be preserved/restored here?
> + mov x0, #0x84000000
> + smc #0
> + ldp x18, x19, [sp], #16
> + ldp x16, x17, [sp], #16
> + ldp x14, x15, [sp], #16
> + ldp x12, x13, [sp], #16
> + ldp x10, x11, [sp], #16
> + ldp x8, x9, [sp], #16
> + ldp x6, x7, [sp], #16
> + ldp x4, x5, [sp], #16
> + ldp x2, x3, [sp], #16
> + ldp x0, x1, [sp], #16
> +ENTRY(__psci_hyp_bp_inval_end)
> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> index 16ea5c6f314e..cb0fb3796bb8 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -53,6 +53,8 @@ static int cpu_enable_trap_ctr_access(void *__unused)
> DEFINE_PER_CPU_READ_MOSTLY(struct bp_hardening_data, bp_hardening_data);
>
> #ifdef CONFIG_KVM
> +extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
> +
> static void __copy_hyp_vect_bpi(int slot, const char *hyp_vecs_start,
> const char *hyp_vecs_end)
> {
> @@ -94,6 +96,9 @@ static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
> spin_unlock(&bp_lock);
> }
> #else
> +#define __psci_hyp_bp_inval_start NULL
> +#define __psci_hyp_bp_inval_end NULL
> +
> static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
> const char *hyp_vecs_start,
> const char *hyp_vecs_end)
> @@ -118,6 +123,21 @@ static void install_bp_hardening_cb(const struct arm64_cpu_capabilities *entry,
>
> __install_bp_hardening_cb(fn, hyp_vecs_start, hyp_vecs_end);
> }
> +
> +#include <linux/psci.h>
> +
> +static int enable_psci_bp_hardening(void *data)
> +{
> + const struct arm64_cpu_capabilities *entry = data;
> +
> + if (psci_ops.get_version)
> + install_bp_hardening_cb(entry,
> + (bp_hardening_cb_t)psci_ops.get_version,
> + __psci_hyp_bp_inval_start,
> + __psci_hyp_bp_inval_end);
> +
> + return 0;
> +}
> #endif /* CONFIG_HARDEN_BRANCH_PREDICTOR */
>
> #define MIDR_RANGE(model, min, max) \
> @@ -261,6 +281,28 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
> MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
> },
> #endif
> +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
> + {
> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
> + .enable = enable_psci_bp_hardening,
> + },
> + {
> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
> + .enable = enable_psci_bp_hardening,
> + },
> + {
> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
> + .enable = enable_psci_bp_hardening,
> + },
> + {
> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
> + .enable = enable_psci_bp_hardening,
> + },
> +#endif
> {
> }
> };
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH V4 11/26] iommu/amd: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2018-01-04 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <46ccdb85-1c23-c9eb-994c-9a66e6fce7cc@amd.com>
On 1/4/2018 11:28 AM, Gary R Hook wrote:
> On 01/04/2018 06:25 AM, Sinan Kaya wrote:
>> On 12/19/2017 12:37 AM, Sinan Kaya wrote:
>>> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
>>> where a PCI device is present. This restricts the device drivers to be
>>> reused for other domain numbers.
>>>
>>> Getting ready to remove pci_get_bus_and_slot() function in favor of
>>> pci_get_domain_bus_and_slot().
>>>
>>> Hard-code the domain number as 0 for the AMD IOMMU driver.
>
> <snip>
>
>>
>> Any comments from the IOMMU people?
>>
>
> pci_get_bus_and_slot() appears to (now) be a convenience function that wraps pci_get_domain_bus_and_slot() while using a 0 for the domain value. Exactly what you are doing here, albeit in a more overt way.
>
> How is this patch advantageous? Seems to me that if other domains need to be enabled, that driver could be changed if and when that requirement arises.
>
> But perhaps I'm missing a nuance here.
>
>
The benefit of the change was discussed here:
https://lkml.org/lkml/2017/12/19/349
I hope it helps.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [GIT PULL] ARM: uniphier: fixes for v4.15 (2nd)
From: Masahiro Yamada @ 2018-01-04 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a1QVn0PXde3q3xVMtdm2r3gS5yqdvSh15V1V+BFtTt9aA@mail.gmail.com>
Hi Arnd,
2018-01-05 1:10 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> On Fri, Dec 29, 2017 at 1:30 PM, Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
>> Hi Arnd, Olof,
>>
>> This is the 2nd bug-fix pull request for v4.15.
>> Just one DT fix. Please pull!
>
> I've ended up cherry-picking that commit manually into the fixes branch:
> We haven't updated the fixes branch to a later -rc, and your pull request
> was based on -rc3, so pulling it would create an ugly backmerge.
>
> You did nothing wrong here, so it seemed unnecessary to ask you for
> a respin based on -rc1. Hope that works for you.
>
> Arnd
Works for me. Thanks!
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* ARM: SoC fixes for 4.15
From: Arnd Bergmann @ 2018-01-04 16:46 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit ce39882eb1d87dd9bb4f89d4ae09ef2547aee079:
Merge tag 'amlogic-fixes-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic
into fixes (2017-12-09 20:23:29 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
tags/armsoc-fixes
for you to fetch changes up to abb62c46d4949d44979fa647740feff3f7538799:
arm64: dts: uniphier: fix gpio-ranges property of PXs3 SoC
(2018-01-04 17:09:01 +0100)
----------------------------------------------------------------
ARM: SoC fixes for 4.15
Fixes this time include mostly device tree changes, as usual,
the notable ones include:
- A number of patches to fix most of the remaining DTC warnings
that got introduced when DTC started warning about some
obvious mistakes. We still have some remaining warnings that
probably may have to wait until 4.16 to get fixed while we
try to figure out what the correct contents should be.
- On Allwinner A64, Ethernet PHYs need a fix after a mistake in
coordination between patches merged through multiple branches.
- Various fixes for PMICs on allwinner based boards
- Two fixes for ethernet link detection on some Renesas machines
- Two stability fixes for rockchip based boards
Aside from device-tree, two other areas got fixes for older
problems:
- For TI Davinci DM365, a couple of fixes were needed to repair
the MMC DMA engine support, apparently this has been broken for
a while.
- One important fix for all Allwinner chips with the PMIC driver
as a loadable module.
----------------------------------------------------------------
[note: this is a bit larger than usual. Most of the fixes were merged
before Christmas into the fixes branch, but then neither of us
was around to send the pull request until now].
Alejandro Mery (3):
ARM: davinci: Use platform_device_register_full() to create pdev
for dm365's eDMA
ARM: davinci: Add dma_mask to dm365's eDMA device
ARM: davinci: fix mmc entries in dm365's dma_slave_map
Arnd Bergmann (8):
Merge tag 'v4.15-rockchip-dts32fixes-1' of
ssh://gitolite.kernel.org/.../mmind/linux-rockchip into fixes
Merge tag 'v4.15-rockchip-dts64fixes-1' of
ssh://gitolite.kernel.org/.../mmind/linux-rockchip into fixes
Merge tag 'at91-ab-4.15-dt-fixes' of
ssh://gitolite.kernel.org/.../abelloni/linux into fixes
Merge tag 'davinci-fixes-for-v4.15' of
ssh://gitolite.kernel.org/.../nsekhar/linux-davinci into fixes
ARM: dts: ls1021a: fix incorrect clock references
ARM: dts: tango4: remove bogus interrupt-controller property
Merge tag 'renesas-fixes-for-v4.15' of
ssh://gitolite.kernel.org/.../horms/renesas into fixes
Merge tag 'sunxi-fixes-for-4.15' of
ssh://gitolite.kernel.org/.../sunxi/linux into fixes
Bogdan Mirea (2):
arm64: dts: renesas: salvator-x: Remove renesas, no-ether-link property
arm64: dts: renesas: ulcb: Remove renesas, no-ether-link property
Chen-Yu Tsai (1):
ARM: dts: sunxi: Convert to CCU index macros for HDMI controller
David Lechner (1):
ARM: dts: da850-lego-ev3: Fix battery voltage gpio
Heiko Stuebner (3):
ARM: dts: rockchip: add cpu0-regulator on rk3066a-marsboard
arm64: dts: rockchip: fix trailing 0 in rk3328 tsadc interrupts
arm64: dts: rockchip: limit rk3328-rock64 gmac speed to 100MBit for now
Icenowy Zheng (1):
arm64: allwinner: a64: add Ethernet PHY regulator for several boards
Jagan Teki (1):
arm64: allwinner: a64-sopine: Fix to use dcdc1 regulator instead of vcc3v3
Javier Martinez Canillas (1):
ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
Joel Stanley (1):
ARM: dts: aspeed-g4: Correct VUART IRQ number
Klaus Goger (1):
arm64: dts: rockchip: remove vdd_log from rk3399-puma
Masahiro Yamada (1):
arm64: dts: uniphier: fix gpio-ranges property of PXs3 SoC
Maxime Ripard (1):
ARM: dts: sun8i: a711: Reinstate the PMIC compatible
Peter Rosin (1):
ARM: dts: at91: disable the nxp,se97b SMBUS timeout on the TSE-850
Rob Herring (1):
ARM: dts: rockchip: fix rk3288 iep-IOMMU interrupts property cells
Sergey Matyukevich (1):
arm64: dts: orange-pi-zero-plus2: fix sdcard detect
Stefan Br?ns (1):
sunxi-rsb: Include OF based modalias in device uevent
arch/arm/boot/dts/aspeed-g4.dtsi | 2 +-
arch/arm/boot/dts/at91-tse850-3.dts | 1 +
arch/arm/boot/dts/da850-lego-ev3.dts | 4 +--
arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 +++
arch/arm/boot/dts/ls1021a-qds.dts | 2 +-
arch/arm/boot/dts/ls1021a-twr.dts | 2 +-
arch/arm/boot/dts/rk3066a-marsboard.dts | 4 +++
arch/arm/boot/dts/rk3288.dtsi | 2 +-
arch/arm/boot/dts/sun4i-a10.dtsi | 4 +--
arch/arm/boot/dts/sun5i-a10s.dtsi | 4 +--
arch/arm/boot/dts/sun6i-a31.dtsi | 4 +--
arch/arm/boot/dts/sun7i-a20.dtsi | 4 +--
arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 1 +
arch/arm/boot/dts/tango4-common.dtsi | 1 -
arch/arm/mach-davinci/dm365.c | 29 ++++++++++++++--------
.../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 1 +
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 1 +
.../dts/allwinner/sun50i-a64-sopine-baseboard.dts | 3 ++-
.../boot/dts/allwinner/sun50i-a64-sopine.dtsi | 11 +-------
.../allwinner/sun50i-h5-orangepi-zero-plus2.dts | 2 +-
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 -
arch/arm64/boot/dts/renesas/ulcb.dtsi | 1 -
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 2 ++
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 2 +-
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 11 --------
arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi | 4 +--
drivers/bus/sunxi-rsb.c | 1 +
27 files changed, 54 insertions(+), 54 deletions(-)
^ permalink raw reply
* [PATCH v3 0/3] arm64: dts: r8a779[56]: Add OPPs table for cpu devices
From: Simon Horman @ 2018-01-04 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103173801.GF22490@bigcity.dyn.berto.se>
On Wed, Jan 03, 2018 at 06:38:01PM +0100, Niklas S?derlund wrote:
> Hi Simon,
>
> Thanks for your work.
>
> I tested these patches together with the dependencies of the
> topic/rcar-gen3-cpufreq-v4 branch, feel free to add to all patches in
> this series.
>
> Tested-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
Thanks, applied.
^ permalink raw reply
* [PATCH V7 11/12] arm64: dts: add syscon for whale2 platform
From: Arnd Bergmann @ 2018-01-04 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAfSe-tc6s6F-1AYEamZubJ7VfMXm-rp18c8pctE51izeHXsnA@mail.gmail.com>
On Fri, Dec 22, 2017 at 6:30 AM, Chunyan Zhang <zhang.lyra@gmail.com> wrote:
> On 22 December 2017 at 07:03, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> On 12/07, Chunyan Zhang wrote:
>>> Some clocks on SC9860 are in the same address area with syscon
>>> devices, the proper syscon node will be quoted under the
>>> definitions of those clocks in DT.
>>>
>>> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
>>> ---
>>
>> These last two can go via arm-soc?
>
> Thanks Stephen!
>
> Hi Arnd, Olof
>
> Could you please take the patch 11, 12 through arm-soc?
Applied both to next/dt now, thanks!
Arnd
^ permalink raw reply
* [PATCH] ARM: dts: kirkwood: fix pin-muxing of MPP7
From: Thomas Petazzoni @ 2018-01-04 16:53 UTC (permalink / raw)
To: linux-arm-kernel
MPP7 is currently muxed as "gpio", but this function doesn't exist for
MPP7, only "gpo" is available. This causes the following error:
kirkwood-pinctrl f1010000.pin-controller: unsupported function gpio on pin mpp7
pinctrl core: failed to register map default (6): invalid type given
kirkwood-pinctrl f1010000.pin-controller: error claiming hogs: -22
kirkwood-pinctrl f1010000.pin-controller: could not claim hogs: -22
kirkwood-pinctrl f1010000.pin-controller: unable to register pinctrl driver
kirkwood-pinctrl: probe of f1010000.pin-controller failed with error -22
So the pinctrl driver is not probed, all device drivers (including the
UART driver) do a -EPROBE_DEFER, and therefore the system doesn't
really boot (well, it boots, but with no UART, and no devices that
require pin-muxing).
Back when the Device Tree file for this board was introduced, the
definition was already wrong. The pinctrl driver also always described
as "gpo" this function for MPP7. However, between Linux 4.10 and 4.11,
a hog pin failing to be muxed was turned from a simple warning to a
hard error that caused the entire pinctrl driver probe to bail
out. This is probably the result of commit 6118714275f0a ("pinctrl:
core: Fix pinctrl_register_and_init() with pinctrl_enable()").
This commit fixes the Device Tree to use the proper "gpo" function for
MPP7, which fixes the boot of OpenBlocks A7, which was broken since
Linux 4.11.
Fixes: f24b56cbcd9d ("ARM: kirkwood: add support for OpenBlocks A7 platform")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/kirkwood-openblocks_a7.dts | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-openblocks_a7.dts b/arch/arm/boot/dts/kirkwood-openblocks_a7.dts
index cf2f5240e176..27cc913ca0f5 100644
--- a/arch/arm/boot/dts/kirkwood-openblocks_a7.dts
+++ b/arch/arm/boot/dts/kirkwood-openblocks_a7.dts
@@ -53,7 +53,8 @@
};
pinctrl: pin-controller at 10000 {
- pinctrl-0 = <&pmx_dip_switches &pmx_gpio_header>;
+ pinctrl-0 = <&pmx_dip_switches &pmx_gpio_header
+ &pmx_gpio_header_gpo>;
pinctrl-names = "default";
pmx_uart0: pmx-uart0 {
@@ -85,11 +86,16 @@
* ground.
*/
pmx_gpio_header: pmx-gpio-header {
- marvell,pins = "mpp17", "mpp7", "mpp29", "mpp28",
+ marvell,pins = "mpp17", "mpp29", "mpp28",
"mpp35", "mpp34", "mpp40";
marvell,function = "gpio";
};
+ pmx_gpio_header_gpo: pxm-gpio-header-gpo {
+ marvell,pins = "mpp7";
+ marvell,function = "gpo";
+ };
+
pmx_gpio_init: pmx-init {
marvell,pins = "mpp38";
marvell,function = "gpio";
--
2.14.3
^ permalink raw reply related
* [PATCH v2 0/4] arm64: defconfig: enable additional led triggers
From: Arnd Bergmann @ 2018-01-04 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAP245DUnO6qoXXoAOakQ_HYTTbR+CgO-nQ-Jm5nOaPeySm968g@mail.gmail.com>
On Tue, Jan 2, 2018 at 8:19 AM, Amit Kucheria <amit.kucheria@linaro.org> wrote:
> On Thu, Dec 21, 2017 at 8:46 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, Dec 6, 2017 at 9:57 AM, Amit Kucheria <amit.kucheria@linaro.org> wrote:
>>> (Adding Arnd)
>>>
>>> Now that the merge window rush has abated, can you please apply this
>>> trivial series?
>>>
>>> On Mon, Nov 6, 2017 at 12:38 PM, Amit Kucheria <amit.kucheria@linaro.org> wrote:
>>>> This patchset enables the kernel panic and disk-activity trigger for LEDs
>>>> and then enables the panic trigger for three 96Boards - DB410c, Hikey and
>>>> Hikey960.
>>>>
>>>> DB410c and Hikey panic behaviour has been tested by triggering a panic
>>>> through /proc/sysrq-trigger, while Hikey960 is only compile-tested.
>>
>> I applied all four now, but it would have been easier for me if you had either
>> sent them to the platform maintainers, or to arm at kernel.org.
>
> The platform maintainers are cc'ed but I guess nobody took them since
> the patchset touched 3 different platforms and a common defconfig.
>
> I'll remember to cc arm at kernel.org in the future but is there any
> reason why this email address isn't listed in MAINTAINERS?
We normally want to have all patches merged through the platform
maintainers, and have no ambiguity regarding who picks things up.
More importantly, being listed in the MAINTAINERS file would result
in us getting thousands of patches each merge window mixed in with
the stuff that we actually do need to see, so that would likely be more
lossy and more work for us.
Arnd
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77970: move node which has no reg property out of bus
From: Simon Horman @ 2018-01-04 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220122549.9452-1-horms+renesas@verge.net.au>
On Wed, Dec 20, 2017 at 01:25:49PM +0100, Simon Horman wrote:
> Move timer node from soc node to root node. The node that have been moved
> do not have any register properties and thus shouldn't be placed on the
> bus.
>
> This problem is flagged by the compiler as follows:
> $ make W=1
> ...
> DTC arch/arm64/boot/dts/renesas/r8a77970-eagle.dtb
> arch/arm64/boot/dts/renesas/r8a77970-eagle.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
> DTC arch/arm64/boot/dts/renesas/r8a77970-v3msk.dtb
> arch/arm64/boot/dts/renesas/r8a77970-v3msk.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Applied
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77995: move nodes which have no reg property out of bus
From: Simon Horman @ 2018-01-04 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220122442.9199-1-horms+renesas@verge.net.au>
On Wed, Dec 20, 2017 at 01:24:42PM +0100, Simon Horman wrote:
> Move pmu_a53 and timer nodes from soc node to root node. The nodes that
> have been moved do not have any register properties and thus shouldn't be
> placed on the bus.
>
> This problem is flagged by the compiler as follows:
> $ make W=1
> ...
> arch/arm64/boot/dts/renesas/r8a77995-draak.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a77995-draak.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Applied
^ permalink raw reply
* [GIT PULL] Gemini DTS updates for v4.16, take 2
From: Arnd Bergmann @ 2018-01-04 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZB7UFXesbQJHjuM_fdkY7w0USD5suGQevo3efsr+wgOg@mail.gmail.com>
On Fri, Dec 22, 2017 at 10:08 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> I realized I forgot two DTS patches and the panel
> driver for enabling video on DIR-685 was merged, so here is
> a second pull request on top of the Gemini DTS pull request
> from yesterday.
>
> Please pull it in on top of the other Gemini DTS patches!
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH 0/3] ARM: dts: renesas: Reduce size of thermal registers
From: Simon Horman @ 2018-01-04 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220121445.31896-1-horms+renesas@verge.net.au>
On Wed, Dec 20, 2017 at 01:14:42PM +0100, Simon Horman wrote:
> Reduce size of thermal registers in DT for the following SoCs:
> * r8a7790 (R-Car H2)
> * r8a7791 (R-Car M3-W)
> * r8a7793 (R-Car M3-N)
>
> According to the "User's Manual: Hardware" v2.00 the registers at base
> 0xe61f0000 extend to an offset of 0x10, rather than 0x14 which is the case
> on the r8a73a4 (R-Mobile APE6).
>
> This should not have any runtime affect as mapping granularity is PAGE_SIZE.
>
> As pointed out by Geert Uytterhoeven.
>
> Based on renesas-devel-20171220-v4.15-rc4
>
> Simon Horman (3):
> ARM: dts: r8a7790: Reduce size of thermal registers
> ARM: dts: r8a7791: Reduce size of thermal registers
> ARM: dts: r8a7793: Reduce size of thermal registers
Applied
^ permalink raw reply
* v4.14.9 on ARMv5: OK with gcc 4.8/5.4, NOK with gcc 7.2
From: Thomas Petazzoni @ 2018-01-04 17:02 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
I'm pretty sure it has already been reported, but just in case: I'm
testing v4.14.9 on an ARMv5 platform (Kirkwood-based OpenBlocks A7).
mvebu_v5_defconfig boots fine when built with gcc 4.8 (good old
Sourcery toolchain) or gcc 5.4 (some old Linaro toolchain), but doesn't
boot at all when built with gcc 7.2 (Fedora toolchain). Even when
configured and booted with earlyprintk, the kernel doesn't say anything.
The toolchain being used is the default ARM toolchain provided by
Fedora 27. It says:
gcc version 7.2.1 20170915 (Red Hat Cross 7.2.1-1) (GCC)
GNU ld version 2.29.1-1.fc27
So it's quite bleeding edge.
Let me know if this has already been fixed, or if I should test a
patch. I have not tested 4.15-rc or next at this point, assuming that
if a fix had been made, it would have been backported to 4.14-stable.
Best regards,
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 08/11] arm64: KVM: Use per-CPU vector when BP hardening is enabled
From: Marc Zyngier @ 2018-01-04 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_wNtjh57PW0jyr39iswiqRMR=5wFezGhgcM4uyv_yuww@mail.gmail.com>
On 04/01/18 16:28, Ard Biesheuvel wrote:
> On 4 January 2018 at 15:08, Will Deacon <will.deacon@arm.com> wrote:
>> From: Marc Zyngier <marc.zyngier@arm.com>
>>
>> Now that we have per-CPU vectors, let's plug then in the KVM/arm64 code.
>>
>
> Why does bp hardening require per-cpu vectors?
The description is not 100% accurate. We have per *CPU type* vectors.
This stems from the following, slightly conflicting requirements:
- We have systems with more than one CPU type (think big-little)
- Different implementations require different BP hardening sequences
- The BP hardening sequence must be executed before doing any branch
The natural solution is to have one set of vectors per CPU type,
containing the BP hardening sequence for that particular implementation,
ending with a branch to the common code.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 08/11] arm64: KVM: Use per-CPU vector when BP hardening is enabled
From: Ard Biesheuvel @ 2018-01-04 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <060b7c34-bce9-da78-f9cb-2e67dd2ee142@arm.com>
On 4 January 2018 at 17:04, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 04/01/18 16:28, Ard Biesheuvel wrote:
>> On 4 January 2018 at 15:08, Will Deacon <will.deacon@arm.com> wrote:
>>> From: Marc Zyngier <marc.zyngier@arm.com>
>>>
>>> Now that we have per-CPU vectors, let's plug then in the KVM/arm64 code.
>>>
>>
>> Why does bp hardening require per-cpu vectors?
>
> The description is not 100% accurate. We have per *CPU type* vectors.
> This stems from the following, slightly conflicting requirements:
>
> - We have systems with more than one CPU type (think big-little)
> - Different implementations require different BP hardening sequences
> - The BP hardening sequence must be executed before doing any branch
>
> The natural solution is to have one set of vectors per CPU type,
> containing the BP hardening sequence for that particular implementation,
> ending with a branch to the common code.
>
Crystal clear, thanks.
^ permalink raw reply
* [PATCH 11/11] arm64: Implement branch predictor hardening for affected Cortex-A CPUs
From: Marc Zyngier @ 2018-01-04 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8E=yWRE9PThFeG3efuT5JLbAK+RpmhTvuEeXwk-iuN9g@mail.gmail.com>
On 04/01/18 16:31, Ard Biesheuvel wrote:
> On 4 January 2018 at 15:08, Will Deacon <will.deacon@arm.com> wrote:
>> Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing
>> and can theoretically be attacked by malicious code.
>>
>> This patch implements a PSCI-based mitigation for these CPUs when available.
>> The call into firmware will invalidate the branch predictor state, preventing
>> any malicious entries from affecting other victim contexts.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> Signed-off-by: Will Deacon <will.deacon@arm.com>
>> ---
>> arch/arm64/kernel/bpi.S | 24 ++++++++++++++++++++++++
>> arch/arm64/kernel/cpu_errata.c | 42 ++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 66 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S
>> index 06a931eb2673..2b10d52a0321 100644
>> --- a/arch/arm64/kernel/bpi.S
>> +++ b/arch/arm64/kernel/bpi.S
>> @@ -53,3 +53,27 @@ ENTRY(__bp_harden_hyp_vecs_start)
>> vectors __kvm_hyp_vector
>> .endr
>> ENTRY(__bp_harden_hyp_vecs_end)
>> +ENTRY(__psci_hyp_bp_inval_start)
>> + stp x0, x1, [sp, #-16]!
>> + stp x2, x3, [sp, #-16]!
>> + stp x4, x5, [sp, #-16]!
>> + stp x6, x7, [sp, #-16]!
>> + stp x8, x9, [sp, #-16]!
>> + stp x10, x11, [sp, #-16]!
>> + stp x12, x13, [sp, #-16]!
>> + stp x14, x15, [sp, #-16]!
>> + stp x16, x17, [sp, #-16]!
>> + stp x18, x19, [sp, #-16]!
>
> Would it be better to update sp only once here?
Maybe. I suppose that's quite uarch dependent, but worth trying.
> Also, do x18 and x19 need to be preserved/restored here?
My bad. I misread the SMCCC and though I needed to save it too. For the
reference, the text says:
"Registers X18-X30 and stack pointers SP_EL0 and SP_ELx are saved by
the function that is called, and must be preserved over the SMC or HVC
call."
I'll amend the patch.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* v4.14.9 on ARMv5: OK with gcc 4.8/5.4, NOK with gcc 7.2
From: Russell King - ARM Linux @ 2018-01-04 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104180238.581b202c@windsurf.lan>
On Thu, Jan 04, 2018 at 06:02:38PM +0100, Thomas Petazzoni wrote:
> Hello,
>
> I'm pretty sure it has already been reported, but just in case: I'm
> testing v4.14.9 on an ARMv5 platform (Kirkwood-based OpenBlocks A7).
> mvebu_v5_defconfig boots fine when built with gcc 4.8 (good old
> Sourcery toolchain) or gcc 5.4 (some old Linaro toolchain), but doesn't
> boot at all when built with gcc 7.2 (Fedora toolchain). Even when
> configured and booted with earlyprintk, the kernel doesn't say anything.
>
> The toolchain being used is the default ARM toolchain provided by
> Fedora 27. It says:
>
> gcc version 7.2.1 20170915 (Red Hat Cross 7.2.1-1) (GCC)
> GNU ld version 2.29.1-1.fc27
>
> So it's quite bleeding edge.
>
> Let me know if this has already been fixed, or if I should test a
> patch. I have not tested 4.15-rc or next at this point, assuming that
> if a fix had been made, it would have been backported to 4.14-stable.
It's a known issue -
http://archive.armlinux.org.uk/lurker/message/20171018.095713.a56a717b.en.html
but so far no patches have been forthcoming for the kernel, because
(I guess) it's deemed to be a gcc bug.
It's one of those discussions that just seemed to die without any
real conclusion.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [RFC PATCH 2/5] perf jevents: add support for arch recommended events
From: John Garry @ 2018-01-04 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221193917.GB1105@krava>
On 21/12/2017 19:39, Jiri Olsa wrote:
>> Hi Jirka,
>> >
>> > When you say reasonable size for x86, I ran a string duplication finder on
>> > the x86 JSONs and the results show a huge amount of duplication. Please
>> > check this:
>> > https://gist.githubusercontent.com/johnpgarry/68bc87e823ae2ce0f7b475b4e55e5795/raw/f4cea138999d8b34151b9586d733592e01774d7a/x86%2520JSON%2520duplication
>> >
>> > Extract:
>> > "Found a 65 line (311 tokens) duplication in the following files:
>> > Starting at line 100 of
>> > /linux/tools/perf/pmu-events/arch/x86/ivybridge/ivb-metrics.json
>> > Starting at line 100 of
>> > /linux/tools/perf/pmu-events/arch/x86/ivytown/ivt-metrics.json
>> > Starting at line 100 of
>> > /linux/tools/perf/pmu-events/arch/x86/broadwell/bdw-metrics.json
>> > Starting at line 100 of
>> > /linux/tools/perf/pmu-events/arch/x86/skylakex/skx-metrics.json
>> > Starting at line 76 of
>> > /linux/tools/perf/pmu-events/arch/x86/jaketown/jkt-metrics.json
>> > Starting at line 100 of
>> > /linux/tools/perf/pmu-events/arch/x86/skylake/skl-metrics.json
>> > Starting at line 76 of
>> > /linux/tools/perf/pmu-events/arch/x86/sandybridge/snb-metrics.json
>> > Starting at line 100 of
>> > /linux/tools/perf/pmu-events/arch/x86/broadwellx/bdx-metrics.json"
>> >
Hi Jirka,
Sorry for the slow reply.
>> > Won't this all potentially have a big maintainence cost?
> as Andi said it's mostly just the disk space,
> which is not big deal
>
> I'm not doing JSON file updates, but I think having
> simple single dir for platform/cpu could save us some
> confusion in future
Understood. But for ARM, which has very standardised architecture
events, it is good to reduce this event duplication between platforms.
>
> however I won't oppose if you want to add this logic,
> but please:
> - use the list_head ;-)
Of course
> - leave the process_one_file function simple
> and separate the level0 processing
ok, this is how it should look already, albeit a couple of
process_one_file() modifications. I'll re-check this.
> - you are using 'EventCode' as an unique ID to find
> the base, but it's not unique for x86, you'll need
> to add some other ID scheme that fits to all archs
Right, so you mentioned earlier using a new keyword token to identify
whether we use the standard event, so we can go his way - ok?
I would also like to mention at this point why I did the event
pre-processing in jevents, and not a separate script:
- current build does not transverse the arch tree
- tree transversal for JSON processing is done in jevents
- a script would mean derived objects, which means:
- makefile changes for derived objects
- jevents would have to deal with derived objects
- jevents already has support for JSON processing
The advantage of using a script is that we keep the JSON processing in
jevents simple.
All the best,
John
>
> thanks,
> jirka
>
^ permalink raw reply
* [PATCH V4 11/26] iommu/amd: deprecate pci_get_bus_and_slot()
From: Gary R Hook @ 2018-01-04 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9014a9e1-9545-4f3c-08c2-8e8eb4762101@codeaurora.org>
On 01/04/2018 10:32 AM, Sinan Kaya wrote:
> On 1/4/2018 11:28 AM, Gary R Hook wrote:
>> On 01/04/2018 06:25 AM, Sinan Kaya wrote:
>>> On 12/19/2017 12:37 AM, Sinan Kaya wrote:
>>>> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
>>>> where a PCI device is present. This restricts the device drivers to be
>>>> reused for other domain numbers.
>>>>
>>>> Getting ready to remove pci_get_bus_and_slot() function in favor of
>>>> pci_get_domain_bus_and_slot().
>>>>
>>>> Hard-code the domain number as 0 for the AMD IOMMU driver.
>>
>> <snip>
>>
>>>
>>> Any comments from the IOMMU people?
>>>
>>
>> pci_get_bus_and_slot() appears to (now) be a convenience function that wraps pci_get_domain_bus_and_slot() while using a 0 for the domain value. Exactly what you are doing here, albeit in a more overt way.
>>
>> How is this patch advantageous? Seems to me that if other domains need to be enabled, that driver could be changed if and when that requirement arises.
>>
>> But perhaps I'm missing a nuance here.
>>
>>
>
> The benefit of the change was discussed here:
>
> https://lkml.org/lkml/2017/12/19/349
>
> I hope it helps.
>
>
Thank you for pointing out that thread directly. I read through it and
thought further about this change.
I am not the maintainer, but as an AMD developer, this is fine change. I
can't ACK but I can agree.
Gary
^ permalink raw reply
* Applied "ASoC: mediatek: update MT2701 AFE documentation to adapt mfd device" to the asoc tree
From: Mark Brown @ 2018-01-04 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a716adbb734cefd8e8ea614a2e4686af8204490e.1515038387.git.ryder.lee@mediatek.com>
The patch
ASoC: mediatek: update MT2701 AFE documentation to adapt mfd device
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 7f12a56367bf526afde7e81820a8c7d97e75ed10 Mon Sep 17 00:00:00 2001
From: Ryder Lee <ryder.lee@mediatek.com>
Date: Thu, 4 Jan 2018 15:44:09 +0800
Subject: [PATCH] ASoC: mediatek: update MT2701 AFE documentation to adapt mfd
device
As the new MFD parent is in place, modify MT2701 AFE documentation to
adapt it. Also add three core clocks in example.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/sound/mt2701-afe-pcm.txt | 171 +++++++++++----------
1 file changed, 93 insertions(+), 78 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt b/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt
index 0450baad2813..6df87b97f7cb 100644
--- a/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt
+++ b/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt
@@ -2,15 +2,17 @@ Mediatek AFE PCM controller for mt2701
Required properties:
- compatible = "mediatek,mt2701-audio";
-- reg: register location and size
- interrupts: should contain AFE and ASYS interrupts
- interrupt-names: should be "afe" and "asys"
- power-domains: should define the power domain
- clocks: Must contain an entry for each entry in clock-names
See ../clocks/clock-bindings.txt for details
- clock-names: should have these clock names:
+ "infra_sys_audio_clk",
"top_audio_mux1_sel",
"top_audio_mux2_sel",
+ "top_audio_a1sys_hp",
+ "top_audio_a2sys_hp",
"i2s0_src_sel",
"i2s1_src_sel",
"i2s2_src_sel",
@@ -45,85 +47,98 @@ Required properties:
- assigned-clocks-parents: parent of input clocks of assigned clocks.
- assigned-clock-rates: list of clock frequencies of assigned clocks.
+Must be a subnode of MediaTek audsys device tree node.
+See ../arm/mediatek/mediatek,audsys.txt for details about the parent node.
+
Example:
- afe: mt2701-afe-pcm at 11220000 {
- compatible = "mediatek,mt2701-audio";
- reg = <0 0x11220000 0 0x2000>,
- <0 0x112A0000 0 0x20000>;
- interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>,
- <GIC_SPI 132 IRQ_TYPE_LEVEL_LOW>;
- interrupt-names = "afe", "asys";
- power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
- clocks = <&topckgen CLK_TOP_AUD_MUX1_SEL>,
- <&topckgen CLK_TOP_AUD_MUX2_SEL>,
- <&topckgen CLK_TOP_AUD_K1_SRC_SEL>,
- <&topckgen CLK_TOP_AUD_K2_SRC_SEL>,
- <&topckgen CLK_TOP_AUD_K3_SRC_SEL>,
- <&topckgen CLK_TOP_AUD_K4_SRC_SEL>,
- <&topckgen CLK_TOP_AUD_K1_SRC_DIV>,
- <&topckgen CLK_TOP_AUD_K2_SRC_DIV>,
- <&topckgen CLK_TOP_AUD_K3_SRC_DIV>,
- <&topckgen CLK_TOP_AUD_K4_SRC_DIV>,
- <&topckgen CLK_TOP_AUD_I2S1_MCLK>,
- <&topckgen CLK_TOP_AUD_I2S2_MCLK>,
- <&topckgen CLK_TOP_AUD_I2S3_MCLK>,
- <&topckgen CLK_TOP_AUD_I2S4_MCLK>,
- <&audiosys CLK_AUD_I2SO1>,
- <&audiosys CLK_AUD_I2SO2>,
- <&audiosys CLK_AUD_I2SO3>,
- <&audiosys CLK_AUD_I2SO4>,
- <&audiosys CLK_AUD_I2SIN1>,
- <&audiosys CLK_AUD_I2SIN2>,
- <&audiosys CLK_AUD_I2SIN3>,
- <&audiosys CLK_AUD_I2SIN4>,
- <&audiosys CLK_AUD_ASRCO1>,
- <&audiosys CLK_AUD_ASRCO2>,
- <&audiosys CLK_AUD_ASRCO3>,
- <&audiosys CLK_AUD_ASRCO4>,
- <&audiosys CLK_AUD_AFE>,
- <&audiosys CLK_AUD_AFE_CONN>,
- <&audiosys CLK_AUD_A1SYS>,
- <&audiosys CLK_AUD_A2SYS>,
- <&audiosys CLK_AUD_AFE_MRGIF>;
+ audsys: audio-subsystem at 11220000 {
+ compatible = "mediatek,mt2701-audsys", "syscon", "simple-mfd";
+ ...
+
+ afe: audio-controller {
+ compatible = "mediatek,mt2701-audio";
+ interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_SPI 132 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "afe", "asys";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
+
+ clocks = <&infracfg CLK_INFRA_AUDIO>,
+ <&topckgen CLK_TOP_AUD_MUX1_SEL>,
+ <&topckgen CLK_TOP_AUD_MUX2_SEL>,
+ <&topckgen CLK_TOP_AUD_48K_TIMING>,
+ <&topckgen CLK_TOP_AUD_44K_TIMING>,
+ <&topckgen CLK_TOP_AUD_K1_SRC_SEL>,
+ <&topckgen CLK_TOP_AUD_K2_SRC_SEL>,
+ <&topckgen CLK_TOP_AUD_K3_SRC_SEL>,
+ <&topckgen CLK_TOP_AUD_K4_SRC_SEL>,
+ <&topckgen CLK_TOP_AUD_K1_SRC_DIV>,
+ <&topckgen CLK_TOP_AUD_K2_SRC_DIV>,
+ <&topckgen CLK_TOP_AUD_K3_SRC_DIV>,
+ <&topckgen CLK_TOP_AUD_K4_SRC_DIV>,
+ <&topckgen CLK_TOP_AUD_I2S1_MCLK>,
+ <&topckgen CLK_TOP_AUD_I2S2_MCLK>,
+ <&topckgen CLK_TOP_AUD_I2S3_MCLK>,
+ <&topckgen CLK_TOP_AUD_I2S4_MCLK>,
+ <&audsys CLK_AUD_I2SO1>,
+ <&audsys CLK_AUD_I2SO2>,
+ <&audsys CLK_AUD_I2SO3>,
+ <&audsys CLK_AUD_I2SO4>,
+ <&audsys CLK_AUD_I2SIN1>,
+ <&audsys CLK_AUD_I2SIN2>,
+ <&audsys CLK_AUD_I2SIN3>,
+ <&audsys CLK_AUD_I2SIN4>,
+ <&audsys CLK_AUD_ASRCO1>,
+ <&audsys CLK_AUD_ASRCO2>,
+ <&audsys CLK_AUD_ASRCO3>,
+ <&audsys CLK_AUD_ASRCO4>,
+ <&audsys CLK_AUD_AFE>,
+ <&audsys CLK_AUD_AFE_CONN>,
+ <&audsys CLK_AUD_A1SYS>,
+ <&audsys CLK_AUD_A2SYS>,
+ <&audsys CLK_AUD_AFE_MRGIF>;
- clock-names = "top_audio_mux1_sel",
- "top_audio_mux2_sel",
- "i2s0_src_sel",
- "i2s1_src_sel",
- "i2s2_src_sel",
- "i2s3_src_sel",
- "i2s0_src_div",
- "i2s1_src_div",
- "i2s2_src_div",
- "i2s3_src_div",
- "i2s0_mclk_en",
- "i2s1_mclk_en",
- "i2s2_mclk_en",
- "i2s3_mclk_en",
- "i2so0_hop_ck",
- "i2so1_hop_ck",
- "i2so2_hop_ck",
- "i2so3_hop_ck",
- "i2si0_hop_ck",
- "i2si1_hop_ck",
- "i2si2_hop_ck",
- "i2si3_hop_ck",
- "asrc0_out_ck",
- "asrc1_out_ck",
- "asrc2_out_ck",
- "asrc3_out_ck",
- "audio_afe_pd",
- "audio_afe_conn_pd",
- "audio_a1sys_pd",
- "audio_a2sys_pd",
- "audio_mrgif_pd";
+ clock-names = "infra_sys_audio_clk",
+ "top_audio_mux1_sel",
+ "top_audio_mux2_sel",
+ "top_audio_a1sys_hp",
+ "top_audio_a2sys_hp",
+ "i2s0_src_sel",
+ "i2s1_src_sel",
+ "i2s2_src_sel",
+ "i2s3_src_sel",
+ "i2s0_src_div",
+ "i2s1_src_div",
+ "i2s2_src_div",
+ "i2s3_src_div",
+ "i2s0_mclk_en",
+ "i2s1_mclk_en",
+ "i2s2_mclk_en",
+ "i2s3_mclk_en",
+ "i2so0_hop_ck",
+ "i2so1_hop_ck",
+ "i2so2_hop_ck",
+ "i2so3_hop_ck",
+ "i2si0_hop_ck",
+ "i2si1_hop_ck",
+ "i2si2_hop_ck",
+ "i2si3_hop_ck",
+ "asrc0_out_ck",
+ "asrc1_out_ck",
+ "asrc2_out_ck",
+ "asrc3_out_ck",
+ "audio_afe_pd",
+ "audio_afe_conn_pd",
+ "audio_a1sys_pd",
+ "audio_a2sys_pd",
+ "audio_mrgif_pd";
- assigned-clocks = <&topckgen CLK_TOP_AUD_MUX1_SEL>,
- <&topckgen CLK_TOP_AUD_MUX2_SEL>,
- <&topckgen CLK_TOP_AUD_MUX1_DIV>,
- <&topckgen CLK_TOP_AUD_MUX2_DIV>;
- assigned-clock-parents = <&topckgen CLK_TOP_AUD1PLL_98M>,
- <&topckgen CLK_TOP_AUD2PLL_90M>;
- assigned-clock-rates = <0>, <0>, <49152000>, <45158400>;
+ assigned-clocks = <&topckgen CLK_TOP_AUD_MUX1_SEL>,
+ <&topckgen CLK_TOP_AUD_MUX2_SEL>,
+ <&topckgen CLK_TOP_AUD_MUX1_DIV>,
+ <&topckgen CLK_TOP_AUD_MUX2_DIV>;
+ assigned-clock-parents = <&topckgen CLK_TOP_AUD1PLL_98M>,
+ <&topckgen CLK_TOP_AUD2PLL_90M>;
+ assigned-clock-rates = <0>, <0>, <49152000>, <45158400>;
+ };
};
--
2.15.1
^ permalink raw reply related
* Applied "ASoC: mediatek: modify MT2701 AFE driver to adapt mfd device" to the asoc tree
From: Mark Brown @ 2018-01-04 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <90c34b9bb2cd7ef15c263a4267e7f083a4f56a85.1515038387.git.ryder.lee@mediatek.com>
The patch
ASoC: mediatek: modify MT2701 AFE driver to adapt mfd device
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From dfa3cbb83e099d5ef9809b67ea3bff3a39dc2f06 Mon Sep 17 00:00:00 2001
From: Ryder Lee <ryder.lee@mediatek.com>
Date: Thu, 4 Jan 2018 15:44:08 +0800
Subject: [PATCH] ASoC: mediatek: modify MT2701 AFE driver to adapt mfd device
As the new MFD parent is in place, modify MT2701 AFE driver to adapt it.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 45 +++++++++++++-----------------
sound/soc/mediatek/mt2701/mt2701-reg.h | 1 -
2 files changed, 20 insertions(+), 26 deletions(-)
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
index 0edadca12a5e..f0cd08fa5c5d 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
@@ -17,6 +17,7 @@
#include <linux/delay.h>
#include <linux/module.h>
+#include <linux/mfd/syscon.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/pm_runtime.h>
@@ -1368,14 +1369,6 @@ static const struct mt2701_i2s_data mt2701_i2s_data[MT2701_I2S_NUM][2] = {
},
};
-static const struct regmap_config mt2701_afe_regmap_config = {
- .reg_bits = 32,
- .reg_stride = 4,
- .val_bits = 32,
- .max_register = AFE_END_ADDR,
- .cache_type = REGCACHE_NONE,
-};
-
static irqreturn_t mt2701_asys_isr(int irq_id, void *dev)
{
int id;
@@ -1414,9 +1407,9 @@ static int mt2701_afe_runtime_resume(struct device *dev)
static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
{
+ struct snd_soc_component *component;
struct mtk_base_afe *afe;
struct mt2701_afe_private *afe_priv;
- struct resource *res;
struct device *dev;
int i, irq_id, ret;
@@ -1446,17 +1439,11 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
return ret;
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-
- afe->base_addr = devm_ioremap_resource(&pdev->dev, res);
-
- if (IS_ERR(afe->base_addr))
- return PTR_ERR(afe->base_addr);
-
- afe->regmap = devm_regmap_init_mmio(&pdev->dev, afe->base_addr,
- &mt2701_afe_regmap_config);
- if (IS_ERR(afe->regmap))
- return PTR_ERR(afe->regmap);
+ afe->regmap = syscon_node_to_regmap(dev->parent->of_node);
+ if (!afe->regmap) {
+ dev_err(dev, "could not get regmap from parent\n");
+ return -ENODEV;
+ }
mutex_init(&afe->irq_alloc_lock);
@@ -1490,6 +1477,12 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
= &mt2701_i2s_data[i][I2S_IN];
}
+ component = kzalloc(sizeof(*component), GFP_KERNEL);
+ if (!component)
+ return -ENOMEM;
+
+ component->regmap = afe->regmap;
+
afe->mtk_afe_hardware = &mt2701_afe_hardware;
afe->memif_fs = mt2701_memif_fs;
afe->irq_fs = mt2701_irq_fs;
@@ -1502,7 +1495,7 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
ret = mt2701_init_clock(afe);
if (ret) {
dev_err(dev, "init clock error\n");
- return ret;
+ goto err_init_clock;
}
platform_set_drvdata(pdev, afe);
@@ -1521,10 +1514,10 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
goto err_platform;
}
- ret = snd_soc_register_component(&pdev->dev,
- &mt2701_afe_pcm_dai_component,
- mt2701_afe_pcm_dais,
- ARRAY_SIZE(mt2701_afe_pcm_dais));
+ ret = snd_soc_add_component(dev, component,
+ &mt2701_afe_pcm_dai_component,
+ mt2701_afe_pcm_dais,
+ ARRAY_SIZE(mt2701_afe_pcm_dais));
if (ret) {
dev_warn(dev, "err_dai_component\n");
goto err_dai_component;
@@ -1538,6 +1531,8 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
pm_runtime_put_sync(dev);
err_pm_disable:
pm_runtime_disable(dev);
+err_init_clock:
+ kfree(component);
return ret;
}
diff --git a/sound/soc/mediatek/mt2701/mt2701-reg.h b/sound/soc/mediatek/mt2701/mt2701-reg.h
index f17c76f37b5f..18e676974f22 100644
--- a/sound/soc/mediatek/mt2701/mt2701-reg.h
+++ b/sound/soc/mediatek/mt2701/mt2701-reg.h
@@ -145,5 +145,4 @@
#define ASYS_I2S_CON_WIDE_MODE_SET(x) ((x) << 1)
#define ASYS_I2S_IN_PHASE_FIX (0x1 << 31)
-#define AFE_END_ADDR 0x15e0
#endif
--
2.15.1
^ permalink raw reply related
* Applied "ASoC: mediatek: add some core clocks for MT2701 AFE" to the asoc tree
From: Mark Brown @ 2018-01-04 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d93643da906e25360a7dbbdcbfaa2228dfd688bf.1515038387.git.ryder.lee@mediatek.com>
The patch
ASoC: mediatek: add some core clocks for MT2701 AFE
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 96365d9fdb2f0d81bfc010298289a8c168931cd0 Mon Sep 17 00:00:00 2001
From: Ryder Lee <ryder.lee@mediatek.com>
Date: Thu, 4 Jan 2018 15:44:07 +0800
Subject: [PATCH] ASoC: mediatek: add some core clocks for MT2701 AFE
Add three core clocks for MT2701 AFE.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c | 30 ++++++++++++++++++++++-
sound/soc/mediatek/mt2701/mt2701-afe-common.h | 3 +++
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c b/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
index 56a057c78c9a..949fc3a1d025 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
@@ -18,8 +18,11 @@
#include "mt2701-afe-clock-ctrl.h"
static const char *const base_clks[] = {
+ [MT2701_INFRA_SYS_AUDIO] = "infra_sys_audio_clk",
[MT2701_TOP_AUD_MCLK_SRC0] = "top_audio_mux1_sel",
[MT2701_TOP_AUD_MCLK_SRC1] = "top_audio_mux2_sel",
+ [MT2701_TOP_AUD_A1SYS] = "top_audio_a1sys_hp",
+ [MT2701_TOP_AUD_A2SYS] = "top_audio_a2sys_hp",
[MT2701_AUDSYS_AFE] = "audio_afe_pd",
[MT2701_AUDSYS_AFE_CONN] = "audio_afe_conn_pd",
[MT2701_AUDSYS_A1SYS] = "audio_a1sys_pd",
@@ -169,10 +172,26 @@ static int mt2701_afe_enable_audsys(struct mtk_base_afe *afe)
struct mt2701_afe_private *afe_priv = afe->platform_priv;
int ret;
- ret = clk_prepare_enable(afe_priv->base_ck[MT2701_AUDSYS_AFE]);
+ /* Enable infra clock gate */
+ ret = clk_prepare_enable(afe_priv->base_ck[MT2701_INFRA_SYS_AUDIO]);
if (ret)
return ret;
+ /* Enable top a1sys clock gate */
+ ret = clk_prepare_enable(afe_priv->base_ck[MT2701_TOP_AUD_A1SYS]);
+ if (ret)
+ goto err_a1sys;
+
+ /* Enable top a2sys clock gate */
+ ret = clk_prepare_enable(afe_priv->base_ck[MT2701_TOP_AUD_A2SYS]);
+ if (ret)
+ goto err_a2sys;
+
+ /* Internal clock gates */
+ ret = clk_prepare_enable(afe_priv->base_ck[MT2701_AUDSYS_AFE]);
+ if (ret)
+ goto err_afe;
+
ret = clk_prepare_enable(afe_priv->base_ck[MT2701_AUDSYS_A1SYS]);
if (ret)
goto err_audio_a1sys;
@@ -193,6 +212,12 @@ static int mt2701_afe_enable_audsys(struct mtk_base_afe *afe)
clk_disable_unprepare(afe_priv->base_ck[MT2701_AUDSYS_A1SYS]);
err_audio_a1sys:
clk_disable_unprepare(afe_priv->base_ck[MT2701_AUDSYS_AFE]);
+err_afe:
+ clk_disable_unprepare(afe_priv->base_ck[MT2701_TOP_AUD_A2SYS]);
+err_a2sys:
+ clk_disable_unprepare(afe_priv->base_ck[MT2701_TOP_AUD_A1SYS]);
+err_a1sys:
+ clk_disable_unprepare(afe_priv->base_ck[MT2701_INFRA_SYS_AUDIO]);
return ret;
}
@@ -205,6 +230,9 @@ static void mt2701_afe_disable_audsys(struct mtk_base_afe *afe)
clk_disable_unprepare(afe_priv->base_ck[MT2701_AUDSYS_A2SYS]);
clk_disable_unprepare(afe_priv->base_ck[MT2701_AUDSYS_A1SYS]);
clk_disable_unprepare(afe_priv->base_ck[MT2701_AUDSYS_AFE]);
+ clk_disable_unprepare(afe_priv->base_ck[MT2701_TOP_AUD_A1SYS]);
+ clk_disable_unprepare(afe_priv->base_ck[MT2701_TOP_AUD_A2SYS]);
+ clk_disable_unprepare(afe_priv->base_ck[MT2701_INFRA_SYS_AUDIO]);
}
int mt2701_afe_enable_clock(struct mtk_base_afe *afe)
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-common.h b/sound/soc/mediatek/mt2701/mt2701-afe-common.h
index 9a2b301a4c21..ae8ddeacfbfe 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-common.h
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-common.h
@@ -61,8 +61,11 @@ enum {
};
enum audio_base_clock {
+ MT2701_INFRA_SYS_AUDIO,
MT2701_TOP_AUD_MCLK_SRC0,
MT2701_TOP_AUD_MCLK_SRC1,
+ MT2701_TOP_AUD_A1SYS,
+ MT2701_TOP_AUD_A2SYS,
MT2701_AUDSYS_AFE,
MT2701_AUDSYS_AFE_CONN,
MT2701_AUDSYS_A1SYS,
--
2.15.1
^ permalink raw reply related
* [PATCH v4 2/7] ARM: davinci: don't use static clk_lookup
From: David Lechner @ 2018-01-04 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <17d6af61-a6db-9dc6-6fde-e9ff44e57389@ti.com>
On 1/4/18 5:10 AM, Sekhar Nori wrote:
> Hi David,
>
> On Monday 01 January 2018 05:09 AM, David Lechner wrote:
>> In preparation of moving to the common clock framework, usage of static
>> struct clk_lookup is removed. The common clock framework uses an opaque
>> struct clk, so we won't be able to use static tables as was previously
>> done.
>>
>> davinci_clk_init() is changed to init a single clock instead of a table
>> and an individual clk_register_clkdev() is added for each clock.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>
> Is there a need for this considering in 6/7 you end up modifying quite a
> bit of this patch again?
No, you are right. And I've been working ahead with device tree support
so I think I want to do this a bit differently anyway.
^ permalink raw reply
* [PATCH v4 3/7] ARM: davinci: fix duplicate clocks
From: David Lechner @ 2018-01-04 17:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e3beaac9-c583-b181-38a8-d0aa6db44045@ti.com>
On 1/4/18 5:12 AM, Sekhar Nori wrote:
> On Monday 01 January 2018 05:09 AM, David Lechner wrote:
>> There are a number of clocks that were duplicated because they are used by
>> more than one device. It is no longer necessary to do this since we are
>> explicitly calling clk_register_clkdev() for each clock. In da830.c, some
>> clocks were using the same LPSC, which would cause problems with reference
>> counting, so these are combinded into one clock each. In da850.c the
>> duplicate clocks had already been fixed by creating dummy child clocks, so
>> these clocks are removed.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>
> If we do end up keeping 2/7, this should be done before that - to avoid
> retouching code that was just introduced.
>
FWIW, this can't be done before because it will cause broken linked
lists in the davinci clocks. But, as I mentioned already, I am going to
try a different approach, so this patch will go away completely.
^ 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