* [PATCHv2] ARM32: Support mremap() for sigpage/vDSO
From: Dmitry Safonov @ 2017-04-25 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414132529.8337-1-dsafonov@virtuozzo.com>
On 04/14/2017 04:25 PM, Dmitry Safonov wrote:
> CRIU restores application mappings on the same place where they
> were before Checkpoint. That means, that we need to move vDSO
> and sigpage during restore on exactly the same place where
> they were before C/R.
>
> Make mremap() code update mm->context.{sigpage,vdso} pointers
> during VMA move. Sigpage is used for landing after handling
> a signal - if the pointer is not updated during moving, the
> application might crash on any signal after mremap().
>
> vDSO pointer on ARM32 is used only for setting auxv at this moment,
> update it during mremap() in case of future usage.
>
> Without those updates, current work of CRIU on ARM32 is not reliable.
> Historically, we error Checkpointing if we find vDSO page on ARM32
> and suggest user to disable CONFIG_VDSO.
> But that's not correct - it goes from x86 where signal processing
> is ended in vDSO blob. For arm32 it's sigpage, which is not disabled
> with `CONFIG_VDSO=n'.
>
> Looks like C/R was working by luck - because userspace on ARM32 at
> this moment always sets SA_RESTORER.
>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Cyrill Gorcunov <gorcunov@openvz.org>
> Cc: Pavel Emelyanov <xemul@virtuozzo.com>
> Cc: Christopher Covington <cov@codeaurora.org>
> Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
> ---
> v2: (buildbot) Fix (unsinged long) to (void*) cast warning.
>
> arch/arm/kernel/process.c | 8 ++++++++
> arch/arm/kernel/vdso.c | 18 ++++++++++++++++++
> arch/x86/entry/vdso/vma.c | 3 ---
> mm/mmap.c | 4 ++++
> 4 files changed, 30 insertions(+), 3 deletions(-)
Ping?
>
> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index 939e8b58c59d..1e6039cac68d 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -404,9 +404,17 @@ static unsigned long sigpage_addr(const struct mm_struct *mm,
> static struct page *signal_page;
> extern struct page *get_signal_page(void);
>
> +static int sigpage_mremap(const struct vm_special_mapping *sm,
> + struct vm_area_struct *new_vma)
> +{
> + current->mm->context.sigpage = new_vma->vm_start;
> + return 0;
> +}
> +
> static const struct vm_special_mapping sigpage_mapping = {
> .name = "[sigpage]",
> .pages = &signal_page,
> + .mremap = sigpage_mremap,
> };
>
> int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
> diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
> index 53cf86cf2d1a..a4d6dc0f2427 100644
> --- a/arch/arm/kernel/vdso.c
> +++ b/arch/arm/kernel/vdso.c
> @@ -54,8 +54,26 @@ static const struct vm_special_mapping vdso_data_mapping = {
> .pages = &vdso_data_page,
> };
>
> +static int vdso_mremap(const struct vm_special_mapping *sm,
> + struct vm_area_struct *new_vma)
> +{
> + unsigned long new_size = new_vma->vm_end - new_vma->vm_start;
> + unsigned long vdso_size;
> +
> + /* without VVAR page */
> + vdso_size = (vdso_total_pages - 1) << PAGE_SHIFT;
> +
> + if (vdso_size != new_size)
> + return -EINVAL;
> +
> + current->mm->context.vdso = new_vma->vm_start;
> +
> + return 0;
> +}
> +
> static struct vm_special_mapping vdso_text_mapping __ro_after_init = {
> .name = "[vdso]",
> + .mremap = vdso_mremap,
> };
>
> struct elfinfo {
> diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
> index 226ca70dc6bd..363730caa60e 100644
> --- a/arch/x86/entry/vdso/vma.c
> +++ b/arch/x86/entry/vdso/vma.c
> @@ -77,9 +77,6 @@ static int vdso_mremap(const struct vm_special_mapping *sm,
> if (image->size != new_size)
> return -EINVAL;
>
> - if (WARN_ON_ONCE(current->mm != new_vma->vm_mm))
> - return -EFAULT;
> -
> vdso_fix_landing(image, new_vma);
> current->mm->context.vdso = (void __user *)new_vma->vm_start;
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index bfbe8856d134..534aef99cfe9 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -3152,8 +3152,12 @@ static int special_mapping_mremap(struct vm_area_struct *new_vma)
> {
> struct vm_special_mapping *sm = new_vma->vm_private_data;
>
> + if (WARN_ON_ONCE(current->mm != new_vma->vm_mm))
> + return -EFAULT;
> +
> if (sm->mremap)
> return sm->mremap(sm, new_vma);
> +
> return 0;
> }
>
>
--
Dmitry
^ permalink raw reply
* [PATCH 2/2] arm64: pmu: Wire-up L2 cache events for ARMv8 PMUv3
From: Florian Fainelli @ 2017-04-25 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425124427.GI24484@arm.com>
On 04/25/2017 05:44 AM, Will Deacon wrote:
> Hi Florian,
>
> On Thu, Apr 20, 2017 at 12:05:46PM -0700, Florian Fainelli wrote:
>> The ARMv8 PMUv3 cache map did not include the L2 cache events, add
>> them.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> arch/arm64/kernel/perf_event.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
>> index 4f011cdd756d..a664c575f3fd 100644
>> --- a/arch/arm64/kernel/perf_event.c
>> +++ b/arch/arm64/kernel/perf_event.c
>> @@ -264,6 +264,11 @@ static const unsigned armv8_pmuv3_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
>> [C(L1I)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L1I_CACHE,
>> [C(L1I)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L1I_CACHE_REFILL,
>>
>> + [C(LL)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE,
>> + [C(LL)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL,
>> + [C(LL)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE,
>> + [C(LL)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL,
>
> I don't think this is correct in general. 'LL' stands for "last-level",
> which may be L3 or even a system cache in the interconnect. Tying that to L2
> is the wrong thing to do from perf's generic event perspective.
>
> I'm ok with what you're proposing for A53 (where the PMU can only count
> events out to the L2), but I'm reluctant to make this change for the generic
> PMUv3 events.
That makes sense, shall I resubmit the first patch by itself or can you
or Catalin take it as-is?
Thanks!
--
Florian
^ permalink raw reply
* [PATCH] clk: sunxi-ng: Fix dependency on sunxi_gate
From: Corentin Labbe @ 2017-04-25 17:12 UTC (permalink / raw)
To: linux-arm-kernel
When CONFIG_SUNXI_CCU is set but no other SUNXI_CCU is selected i got
the following build error:
drivers/built-in.o: In function `ccu_pll_notifier_cb':
drivers/clk/sunxi-ng/ccu_common.c:71: undefined reference to `ccu_gate_helper_disable'
drivers/clk/sunxi-ng/ccu_common.c:73: undefined reference to `ccu_gate_helper_enable'
The problem is the function ccu_pll_notifier_cb in ccu_common.c need
some function from ccu_gate.c which is not compiled since SUNXI_CCU_GATE
is not selected.
This patch remove SUNXI_CCU_GATE and compile ccu_gate.c unconditionnaly
since all other combination of options select SUNXI_CCU_GATE finally.
Fixes: 02ae2bc6febd ("clk: sunxi-ng: Add clk notifier to gate then ungate PLL clocks")
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/clk/sunxi-ng/Kconfig | 11 -----------
drivers/clk/sunxi-ng/Makefile | 2 +-
2 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index 8bee225..d7842f9 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -15,9 +15,6 @@ config SUNXI_CCU_DIV
config SUNXI_CCU_FRAC
bool
-config SUNXI_CCU_GATE
- bool
-
config SUNXI_CCU_MUX
bool
@@ -32,24 +29,19 @@ config SUNXI_CCU_PHASE
config SUNXI_CCU_NK
bool
- select SUNXI_CCU_GATE
config SUNXI_CCU_NKM
bool
- select SUNXI_CCU_GATE
config SUNXI_CCU_NKMP
bool
- select SUNXI_CCU_GATE
config SUNXI_CCU_NM
bool
select SUNXI_CCU_FRAC
- select SUNXI_CCU_GATE
config SUNXI_CCU_MP
bool
- select SUNXI_CCU_GATE
select SUNXI_CCU_MUX
# SoC Drivers
@@ -119,7 +111,6 @@ config SUN8I_A33_CCU
config SUN8I_A83T_CCU
bool "Support for the Allwinner A83T CCU"
select SUNXI_CCU_DIV
- select SUNXI_CCU_GATE
select SUNXI_CCU_NKMP
select SUNXI_CCU_NM
select SUNXI_CCU_MP
@@ -154,7 +145,6 @@ config SUN9I_A80_CCU
bool "Support for the Allwinner A80 CCU"
select SUNXI_CCU_DIV
select SUNXI_CCU_MULT
- select SUNXI_CCU_GATE
select SUNXI_CCU_NKMP
select SUNXI_CCU_NM
select SUNXI_CCU_MP
@@ -165,7 +155,6 @@ config SUN9I_A80_CCU
config SUN8I_R_CCU
bool "Support for Allwinner SoCs' PRCM CCUs"
select SUNXI_CCU_DIV
- select SUNXI_CCU_GATE
default MACH_SUN8I || (ARCH_SUNXI && ARM64)
endif
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 78028c8..52aab41 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -1,11 +1,11 @@
# Common objects
obj-$(CONFIG_SUNXI_CCU) += ccu_common.o
obj-$(CONFIG_SUNXI_CCU) += ccu_reset.o
+obj-$(CONFIG_SUNXI_CCU) += ccu_gate.o
# Base clock types
obj-$(CONFIG_SUNXI_CCU_DIV) += ccu_div.o
obj-$(CONFIG_SUNXI_CCU_FRAC) += ccu_frac.o
-obj-$(CONFIG_SUNXI_CCU_GATE) += ccu_gate.o
obj-$(CONFIG_SUNXI_CCU_MUX) += ccu_mux.o
obj-$(CONFIG_SUNXI_CCU_MULT) += ccu_mult.o
obj-$(CONFIG_SUNXI_CCU_PHASE) += ccu_phase.o
--
2.10.2
^ permalink raw reply related
* [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override
From: Fabio Estevam @ 2017-04-25 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BsgXRfgZ0hszk2Vgo2keVDHH1BLbJTbW+awMS2cBoNow@mail.gmail.com>
On Tue, Apr 25, 2017 at 2:02 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Leonard,
>
> On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez
> <leonard.crestez@nxp.com> wrote:
>> The board file for imx6sx-dbg overrides cpufreq operating points to use
>> higher voltages. This is done because the board has a shared rail for
>> VDD_ARM_IN and VDD_SOC_IN and when using LDO bypass the shared voltage
>> needs to be a value suitable for both ARM and SOC.
>>
>> This was introduced in:
>>
>> commit 54183bd7f766 ("ARM: imx6sx-sdb: add revb board and make it default")
>>
>> This only only applies to LDO bypass mode, a feature not present in
>> upstream. When LDOs are enabled the effect is to use higher voltages than
>> necesarry for no good reason.
>>
>> Setting these higher voltages can make some boards fail to boot with ugly
>> semi-random crashes, reminiscent of memory corruption. These failures
>> happen the first time the lowest idle state is used. Remove the OPP
>> override in order to fix those crashes.
>>
>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>>
>> ---
>> It's not clear exactly why the crashes happen. Perhaps waking up from idle
>> draws more power than is available? Removing this override is a correct
>> change anyway so maybe there is no need to investigate deeper.
>
> Marek just sent a similar one a few minutes ago:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-April/503230.html
Forgot to add Marek.
^ permalink raw reply
* [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override
From: Fabio Estevam @ 2017-04-25 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <89cc7192100bdc9ce546bf6000446e629457ebc1.1493138693.git.leonard.crestez@nxp.com>
Hi Leonard,
On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:
> The board file for imx6sx-dbg overrides cpufreq operating points to use
> higher voltages. This is done because the board has a shared rail for
> VDD_ARM_IN and VDD_SOC_IN and when using LDO bypass the shared voltage
> needs to be a value suitable for both ARM and SOC.
>
> This was introduced in:
>
> commit 54183bd7f766 ("ARM: imx6sx-sdb: add revb board and make it default")
>
> This only only applies to LDO bypass mode, a feature not present in
> upstream. When LDOs are enabled the effect is to use higher voltages than
> necesarry for no good reason.
>
> Setting these higher voltages can make some boards fail to boot with ugly
> semi-random crashes, reminiscent of memory corruption. These failures
> happen the first time the lowest idle state is used. Remove the OPP
> override in order to fix those crashes.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>
> ---
> It's not clear exactly why the crashes happen. Perhaps waking up from idle
> draws more power than is available? Removing this override is a correct
> change anyway so maybe there is no need to investigate deeper.
Marek just sent a similar one a few minutes ago:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-April/503230.html
^ permalink raw reply
* [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override
From: Leonard Crestez @ 2017-04-25 16:57 UTC (permalink / raw)
To: linux-arm-kernel
The board file for imx6sx-dbg overrides cpufreq operating points to use
higher voltages. This is done because the board has a shared rail for
VDD_ARM_IN and VDD_SOC_IN and when using LDO bypass the shared voltage
needs to be a value suitable for both ARM and SOC.
This was introduced in:
commit 54183bd7f766 ("ARM: imx6sx-sdb: add revb board and make it default")
This only only applies to LDO bypass mode, a feature not present in
upstream. When LDOs are enabled the effect is to use higher voltages than
necesarry for no good reason.
Setting these higher voltages can make some boards fail to boot with ugly
semi-random crashes, reminiscent of memory corruption. These failures
happen the first time the lowest idle state is used. Remove the OPP
override in order to fix those crashes.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
It's not clear exactly why the crashes happen. Perhaps waking up from idle
draws more power than is available? Removing this override is a correct
change anyway so maybe there is no need to investigate deeper.
arch/arm/boot/dts/imx6sx-sdb.dts | 17 -----------------
1 file changed, 17 deletions(-)
diff --git a/arch/arm/boot/dts/imx6sx-sdb.dts b/arch/arm/boot/dts/imx6sx-sdb.dts
index 5bb8fd5..d71da30 100644
--- a/arch/arm/boot/dts/imx6sx-sdb.dts
+++ b/arch/arm/boot/dts/imx6sx-sdb.dts
@@ -12,23 +12,6 @@
model = "Freescale i.MX6 SoloX SDB RevB Board";
};
-&cpu0 {
- operating-points = <
- /* kHz uV */
- 996000 1250000
- 792000 1175000
- 396000 1175000
- 198000 1175000
- >;
- fsl,soc-operating-points = <
- /* ARM kHz SOC uV */
- 996000 1250000
- 792000 1175000
- 396000 1175000
- 198000 1175000
- >;
-};
-
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default";
--
2.7.4
^ permalink raw reply related
* support autofocus / autogain in libv4l2
From: Nicolas Dufresne @ 2017-04-25 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425113009.GH30553@pali>
Le mardi 25 avril 2017 ? 13:30 +0200, Pali Roh?r a ?crit?:
> Pinos (renamed from PulseVideo)
>
> https://blogs.gnome.org/uraeus/2015/06/30/introducing-pulse-video/
> https://cgit.freedesktop.org/~wtay/pinos/
>
> But from git history it looks like it is probably dead now...
This is also incorrect. See "work" branch. It is still a one man show,
code being aggressively re-factored. I suspect this will be the case
until the "form" is considered acceptable.
Nicolas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170425/7a9df95e/attachment.sig>
^ permalink raw reply
* support autofocus / autogain in libv4l2
From: Nicolas Dufresne @ 2017-04-25 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425080538.GA30380@amd>
Le mardi 25 avril 2017 ? 10:05 +0200, Pavel Machek a ?crit?:
> Well, fd's are hard, because application can do fork() and now
> interesting stuff happens. Threads are tricky, because now you have
> locking etc.
>
> libv4l2 is designed to be LD_PRELOADED. That is not really feasible
> with "complex" library.
That is incorrect. The library propose an API where you simply replace
certain low level calls, like ioctl -> v4l2_ioctl, open -> v4l2_open().
You have to do that explicitly in your existing code. It does not
abstract the API itself unlike libdrm.
Nicolas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170425/82d4ed25/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: Preventing READ_IMPLIES_EXEC propagation
From: Will Deacon @ 2017-04-25 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d4205c8c-c8cd-ef35-a6bd-3444a7b3ac48@huawei.com>
On Tue, Apr 25, 2017 at 02:11:29PM +0800, dongbo (E) wrote:
> From: Dong Bo <dongbo4@huawei.com>
>
> Once the READ_IMPLIES_EXEC flag is set on arm64, the flag is
> propagated to its child processes, even the ELF files are
> marked as not requiring executable stack.
>
> Signed-off-by: Dong Bo <dongbo4@huawei.com>
> ---
> arch/arm64/include/asm/elf.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> index 5d17004..5941e7f 100644
> --- a/arch/arm64/include/asm/elf.h
> +++ b/arch/arm64/include/asm/elf.h
> @@ -142,6 +142,7 @@
> ({ \
> clear_bit(TIF_32BIT, ¤t->mm->context.flags); \
> clear_thread_flag(TIF_32BIT); \
> + current->personality &= ~READ_IMPLIES_EXEC; \
> })
> /* update AT_VECTOR_SIZE_ARCH if the number of NEW_AUX_ENT entries changes */
This looks good to me:
Acked-by: Will Deacon <will.deacon@arm.com>
We might also want a comment in the compat code to say that we inherit
the flag to follow the arch/arm/ behaviour.
Anyway, I'd like to see this sit in -next for a bit, so would rather hold
this off until 4.12.
Will
^ permalink raw reply
* [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP
From: Will Deacon @ 2017-04-25 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFpQJXWX=0GQ5hse4E_OSdnYhMOA7CvqeoHe9AdMsyoZJmrPQQ@mail.gmail.com>
On Tue, Apr 25, 2017 at 09:13:40AM +0530, Ganapatrao Kulkarni wrote:
> On Mon, Apr 24, 2017 at 9:15 PM, Will Deacon <will.deacon@arm.com> wrote:
> > On Thu, Apr 20, 2017 at 02:56:50PM +0530, Ganapatrao Kulkarni wrote:
> >> On Thu, Apr 20, 2017 at 2:19 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> >> > On Wed, Apr 19, 2017 at 11:14:06PM +0530, Ganapatrao Kulkarni wrote:
> >> >> commit d98ecda (arm64: perf: Count EL2 events if the kernel is running in HYP)
> >> >> is returning error for perf syscall with mixed attribute set for exclude_kernel
> >> >> and exclude_hv. This change is breaking some applications (observed with hhvm)
> >> >> when ran on VHE enabled platforms.
> >> >>
> >> >> Adding fix to consider only exclude_kernel attribute when kernel is
> >> >> running in HYP. Also adding sysfs file to notify the bhehaviour
> >> >> of attribute exclude_hv.
> >> >>
> >> >> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
> >> >> ---
> >> >>
> >> >> Changelog:
> >> >>
> >> >> V2:
> >> >> - Changes as per Will Deacon's suggestion.
> >> >>
> >> >> V1: Initial patch
> >> >>
> >> >> arch/arm64/kernel/perf_event.c | 28 ++++++++++++++++++++++++----
> >> >> include/linux/perf/arm_pmu.h | 1 +
> >> >> 2 files changed, 25 insertions(+), 4 deletions(-)
> >> >>
> >> >> @@ -871,14 +890,13 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
> >> >>
> >> >> if (attr->exclude_idle)
> >> >> return -EPERM;
> >> >> - if (is_kernel_in_hyp_mode() &&
> >> >> - attr->exclude_kernel != attr->exclude_hv)
> >> >> - return -EINVAL;
> >> >> + if (is_kernel_in_hyp_mode() && !attr->exclude_kernel)
> >> >> + config_base |= ARMV8_PMU_INCLUDE_EL2;
> >> >> if (attr->exclude_user)
> >> >> config_base |= ARMV8_PMU_EXCLUDE_EL0;
> >> >> if (!is_kernel_in_hyp_mode() && attr->exclude_kernel)
> >> >> config_base |= ARMV8_PMU_EXCLUDE_EL1;
> >> >> - if (!attr->exclude_hv)
> >> >> + if (!is_kernel_in_hyp_mode() && !attr->exclude_hv)
> >> >> config_base |= ARMV8_PMU_INCLUDE_EL2;
> >> >
> >> > This isn't quite what Will suggested.
> >> >
> >> > The idea was that userspace would read sysfs, then use that to determine
> >> > the correct exclusion parameters [1,2]. This logic was not expected to
> >> > change; it correctly validates whether we can provide what the user
> >> > requests.
> >>
> >> OK, if you are ok with sysfs part, i can send next version with that
> >> change only?.
> >
> > I think the sysfs part is still a little dodgy, since you still expose the
> > "exclude_hv" file with a value of 0 when not running at EL2, which would
> > imply that exclude_hv is forced to zero. I don't think that's correct.
>
> okay, i can make exclude_hv visible only when kernel booted in EL2.
> is it ok to have empty directory "attr" when kernel booted to EL1?
> attr can be place holder for any other miscellaneous attributes, that
> can be added in future.
Sounds good to me, although I'll seek comment from the other perf folks
before merging anything with ABI implications.
Will
^ permalink raw reply
* support autofocus / autogain in libv4l2
From: Nicolas Dufresne @ 2017-04-25 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425080815.GD30553@pali>
Le mardi 25 avril 2017 ? 10:08 +0200, Pali Roh?r a ?crit?:
> On Tuesday 25 April 2017 10:05:38 Pavel Machek wrote:
> > > > It would be nice if more than one application could be
> > > > accessing the
> > > > camera at the same time... (I.e. something graphical running
> > > > preview
> > > > then using command line tool to grab a picture.) This one is
> > > > definitely not solveable inside a library...
> > >
> > > Someone once suggested to have something like pulseaudio for V4L.
> > > For such usage, a server would be interesting. Yet, I would code
> > > it
> > > in a way that applications using libv4l will talk with such
> > > daemon
> > > in a transparent way.
> >
> > Yes, we need something like pulseaudio for V4L. And yes, we should
> > make it transparent for applications using libv4l.
>
> IIRC there is already some effort in writing such "video" server
> which
> would support accessing more application into webcam video, like
> pulseaudio server for accessing more applications to microphone
> input.
>
Because references are nice:
https://blogs.gnome.org/uraeus/2015/06/30/introducing-pulse-video/
https://gstconf.ubicast.tv/videos/camera-sharing-and-sandboxing-with-pinos/
And why the internals are not going to be implemented using GStreamer in the end:
https://gstconf.ubicast.tv/videos/keep-calm-and-refactor-about-the-essence-of-gstreamer/
regards,
Nicolas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170425/c6b3f95c/attachment-0001.sig>
^ permalink raw reply
* [PATCH 0/3] Add fault_major, fault_minor page fault trace events
From: Will Deacon @ 2017-04-25 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413022040.10156-1-credmonster@gmail.com>
On Wed, Apr 12, 2017 at 10:20:37PM -0400, Chris Redmon wrote:
> These changes add common trace events for major and minor page faults,
> as well as adding these traces to the arm and arm64 architectures. These
> traces offer useful information for determining the source of page faults
> in realtime systems, as well as the time penalty for taking a major or
> minor page fault.
>
> I made an attempt to minimize the overhead when these tracepoints are not
> enabled, but I'm willing to make more changes if desired.
Why is this necessary, given that we already report these types of fault
as perf sw events?
Will
^ permalink raw reply
* [PATCH] arm64: kernel: restrict /dev/mem read() calls to linear region
From: Will Deacon @ 2017-04-25 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_j9GzO2_35Xutg4CbhdK7CekhYcOx0r+OCw_N5uGBWdA@mail.gmail.com>
On Wed, Apr 12, 2017 at 09:31:38AM +0100, Ard Biesheuvel wrote:
> On 12 April 2017 at 09:29, Alexander Graf <agraf@suse.de> wrote:
> >
> >
> > On 12.04.17 10:26, Ard Biesheuvel wrote:
> >>
> >> When running lscpu on an AArch64 system that has SMBIOS version 2.0
> >> tables, it will segfault in the following way:
> >>
> >> Unable to handle kernel paging request at virtual address
> >> ffff8000bfff0000
> >> pgd = ffff8000f9615000
> >> [ffff8000bfff0000] *pgd=0000000000000000
> >> Internal error: Oops: 96000007 [#1] PREEMPT SMP
> >> Modules linked in:
> >> CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103
> >> Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
> >> task: ffff8000fa78e800 task.stack: ffff8000f9780000
> >> PC is at __arch_copy_to_user+0x90/0x220
> >> LR is at read_mem+0xcc/0x140
> >>
> >> This is caused by the fact that lspci issues a read() on /dev/mem at the
> >> offset where it expects to find the SMBIOS structure array. However, this
> >> region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec),
> >> and so it is omitted from the linear mapping.
> >>
> >> So let's restrict /dev/mem read/write access to those areas that are
> >> covered by the linear region.
> >>
> >> Reported-by: Alexander Graf <agraf@suse.de>
> >> Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as
> >> MEMBLOCK_NOMAP")
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >> ---
> >> arch/arm64/mm/mmap.c | 9 +++------
> >> 1 file changed, 3 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
> >> index 7b0d55756eb1..2956240d17d7 100644
> >> --- a/arch/arm64/mm/mmap.c
> >> +++ b/arch/arm64/mm/mmap.c
> >> @@ -18,6 +18,7 @@
> >>
> >> #include <linux/elf.h>
> >> #include <linux/fs.h>
> >> +#include <linux/memblock.h>
> >> #include <linux/mm.h>
> >> #include <linux/mman.h>
> >> #include <linux/export.h>
> >> @@ -103,12 +104,8 @@ void arch_pick_mmap_layout(struct mm_struct *mm)
> >> */
> >> int valid_phys_addr_range(phys_addr_t addr, size_t size)
> >> {
> >> - if (addr < PHYS_OFFSET)
> >> - return 0;
> >> - if (addr + size > __pa(high_memory - 1) + 1)
> >> - return 0;
> >> -
> >> - return 1;
> >> + return memblock_is_map_memory(addr) &&
> >> + memblock_is_map_memory(addr + size - 1);
> >
> >
> > Is that safe? Are we guaranteed that size is less than one page? Otherwise,
> > someone could map a region that spans over a reserved one:
> >
> > [conv mem]
> > [reserved]
> > [conv mem]
> >
>
> Well, I will leave it to the maintainers to decide how elaborate they
> want this logic to become, given that read()ing from /dev/mem is
> something we are not eager to support in the first place.
>
> But indeed, if the start and end of the region are covered by the
> linear region, there could potentially be an uncovered hole in the
> middle.
I think it would be worth handling that case, even if it means we have to
walk over the memblocks which the region overlaps.
Will
^ permalink raw reply
* [PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v6)
From: Eric Anholt @ 2017-04-25 16:45 UTC (permalink / raw)
To: linux-arm-kernel
Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for
now, so it's useful to be able to test that mode on an upstream
kernel. It's also been useful for me to use the same board for 32-bit
and 64-bit development.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/bcm2837-rpi-3-b.dts | 1 +
2 files changed, 2 insertions(+)
create mode 100644 arch/arm/boot/dts/bcm2837-rpi-3-b.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 011808490fed..eded842d9978 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -72,6 +72,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
bcm2835-rpi-b-plus.dtb \
bcm2835-rpi-a-plus.dtb \
bcm2836-rpi-2-b.dtb \
+ bcm2837-rpi-3-b.dtb \
bcm2835-rpi-zero.dtb
dtb-$(CONFIG_ARCH_BCM_5301X) += \
bcm4708-asus-rt-ac56u.dtb \
diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
new file mode 100644
index 000000000000..c72a27d908b6
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
@@ -0,0 +1 @@
+#include "arm64/broadcom/bcm2837-rpi-3-b.dts"
--
2.11.0
^ permalink raw reply related
* [PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v5)
From: Eric Anholt @ 2017-04-25 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <68d88bf7-1f47-4056-3b70-7b97d9a02953@i2se.com>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> Am 24.04.2017 um 22:00 schrieb Eric Anholt:
>> Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for
>> now, so it's useful to be able to test that mode on an upstream
>> kernel. It's also been useful for me to use the same board for 32-bit
>> and 64-bit development.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> ---
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/bcm2837-rpi-3.b.dts | 1 +
>> 2 files changed, 2 insertions(+)
>> create mode 100644 arch/arm/boot/dts/bcm2837-rpi-3.b.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 011808490fed..eded842d9978 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -72,6 +72,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
>> bcm2835-rpi-b-plus.dtb \
>> bcm2835-rpi-a-plus.dtb \
>> bcm2836-rpi-2-b.dtb \
>> + bcm2837-rpi-3-b.dtb \
>> bcm2835-rpi-zero.dtb
>> dtb-$(CONFIG_ARCH_BCM_5301X) += \
>> bcm4708-asus-rt-ac56u.dtb \
>> diff --git a/arch/arm/boot/dts/bcm2837-rpi-3.b.dts b/arch/arm/boot/dts/bcm2837-rpi-3.b.dts
>> new file mode 100644
>> index 000000000000..8c8aa4d1e9b3
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/bcm2837-rpi-3.b.dts
>> @@ -0,0 +1 @@
>> +#include "arm64/broadcom/bcm2837-rpi-3.b.dts"
>
> Looks like a typo in the dts filename and in the include ( dot instead
> of dash ).
Sorry about that, everyone. I remember doing builds of the patch, but
maybe things succeeded because there was already a .dtb present in my
tree or something.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170425/e8afe944/attachment.sig>
^ permalink raw reply
* [PATCH] [RFC] ARM: dts: imx6sx-sdb: Drop OPP hackery
From: Marek Vasut @ 2017-04-25 16:42 UTC (permalink / raw)
To: linux-arm-kernel
The imx6sx-sdb has one power supply that drives both VDDARM_IN
and VDDSOC_IN, which is the sw1a regulator on the PFUZE PMIC.
Connect both inputs to the sw1a regulator on the PMIC and drop
the OPP hackery which is no longer needed as the power framework
will take care of the regulator configuration as needed.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
---
Note: Fabio, if you have a chance, please give this a spin and see
if this works.
---
arch/arm/boot/dts/imx6sx-sdb.dts | 25 ++++++++-----------------
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/imx6sx-sdb.dts b/arch/arm/boot/dts/imx6sx-sdb.dts
index 5bb8fd57e7f5..c0139d7e497a 100644
--- a/arch/arm/boot/dts/imx6sx-sdb.dts
+++ b/arch/arm/boot/dts/imx6sx-sdb.dts
@@ -12,23 +12,6 @@
model = "Freescale i.MX6 SoloX SDB RevB Board";
};
-&cpu0 {
- operating-points = <
- /* kHz uV */
- 996000 1250000
- 792000 1175000
- 396000 1175000
- 198000 1175000
- >;
- fsl,soc-operating-points = <
- /* ARM kHz SOC uV */
- 996000 1250000
- 792000 1175000
- 396000 1175000
- 198000 1175000
- >;
-};
-
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default";
@@ -145,3 +128,11 @@
reg = <1>;
};
};
+
+®_arm {
+ vin-supply = <&sw1a_reg>;
+};
+
+®_soc {
+ vin-supply = <&sw1a_reg>;
+};
--
2.11.0
^ permalink raw reply related
* [PATCH] staging: bcm2835-audio: changed the printk KERN_* to pr_*
From: Jaikumar Dhanapal @ 2017-04-25 16:41 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
Code style warnings related to debug information are fixed in the file
'drivers/staging/bcm2835-audio/bcm2835.h'.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-staging-bcm2835-audio-changed-the-printk-KERN_-to-pr-.patch
Type: text/x-diff
Size: 2229 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170425/90e2ad78/attachment.bin>
^ permalink raw reply
* [PATCH V15 04/11] efi: parse ARM processor error
From: Borislav Petkov @ 2017-04-25 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b39e05d4-fcec-ec26-5aa9-895655eb513c@codeaurora.org>
On Tue, Apr 25, 2017 at 10:05:31AM -0600, Baicar, Tyler wrote:
> That seems like something that should be done outside of these patches (if
> added to the kernel at all). The decoding for this information would all be
> vendor specific, so I'm not sure if we want to pollute the EFI code with
> vendor specific error decoding. Currently we are using the RAS Daemon user
> space tool for the decoding of this information since vendors can easily
> pick up this tool and add an extension for their vendor specific parsing.
> These prints will only happen when the firmware supports the vendor specific
> error information anyway.
The same questions apply here: what do you do if the machine panics
because the error is fatal and you can't get it to run any userspace?
Wouldn't it be good to decode the whole error?
Right now we photograph screens on Intel x86 and feed the typed MCA info
by hand to mcelog. Hardly an optimal situation.
On AMD, there's a decoder which actually can dump the decoded critical
error. (Or could - that's in flux again :-\).
So yes, if stuff is too vendor-specific then you probably don't
want to decode it (or add a vendor-specific decoding module like
edac_mce_amd.ko, for example). But the tables from the UEFI spec,
documenting IP-specific error types which should be valid for most if
not all ARM64 implementations adhering to the spec, would be useful to
decode.
In general, the more we can decode the error in the kernel and the less
we need an external help to do so, the better.
Thanks.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* [PATCH/RFC 2/2] soc: renesas: Rework Kconfig and Makefile logic
From: Geert Uytterhoeven @ 2017-04-25 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493137626-21404-1-git-send-email-geert+renesas@glider.be>
The goals are to:
- Allow precise control over and automatic selection of which
(sub)drivers are used for which SoC,
- Allow adding support for new SoCs easily,
- Allow compile-testing of all (sub)drivers,
- Keep driver selection logic in the subsystem-specific Kconfig,
independent from the architecture-specific Kconfig (i.e. no "select"
from arch/arm64/Kconfig.platforms), to avoid dependencies.
This is implemented by:
- Introducing Kconfig symbols for all drivers and sub-drivers,
- Introducing the Kconfig symbol SOC_RENESAS, which is enabled
automatically when building for a Renesas ARM platform, and which
enables all required drivers without interaction of the user, based
on SoC-specific ARCH_* symbols,
- Allowing the user to enable any Kconfig symbol manually if
COMPILE_TEST is enabled,
- Using the new Kconfig symbols instead of the ARCH_* symbols to
control compilation in the Makefile,
- Always entering drivers/soc/renesas/ during the build.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 2 +-
drivers/soc/renesas/Kconfig | 63 ++++++++++++++++++++++++++++++++++++
drivers/soc/renesas/Makefile | 31 +++++++++---------
drivers/soc/renesas/rcar-sysc.c | 24 +++++++-------
include/linux/soc/renesas/rcar-rst.h | 3 +-
6 files changed, 92 insertions(+), 32 deletions(-)
create mode 100644 drivers/soc/renesas/Kconfig
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index f09023f7ab119025..de4fcdbae2a8fa03 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -4,6 +4,7 @@ source "drivers/soc/bcm/Kconfig"
source "drivers/soc/fsl/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/renesas/Kconfig"
source "drivers/soc/rockchip/Kconfig"
source "drivers/soc/samsung/Kconfig"
source "drivers/soc/sunxi/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 05eae52a30b45133..59d8c937f4a8748e 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -8,7 +8,7 @@ obj-$(CONFIG_MACH_DOVE) += dove/
obj-y += fsl/
obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/
obj-$(CONFIG_ARCH_QCOM) += qcom/
-obj-$(CONFIG_ARCH_RENESAS) += renesas/
+obj-y += renesas/
obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
obj-$(CONFIG_SOC_SAMSUNG) += samsung/
obj-$(CONFIG_ARCH_SUNXI) += sunxi/
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
new file mode 100644
index 0000000000000000..87a4be46bd9834c1
--- /dev/null
+++ b/drivers/soc/renesas/Kconfig
@@ -0,0 +1,63 @@
+config SOC_RENESAS
+ bool "Renesas SoC driver support" if COMPILE_TEST && !ARCH_RENESAS
+ default y if ARCH_RENESAS
+ select SOC_BUS
+ select RST_RCAR if ARCH_RCAR_GEN1 || ARCH_RCAR_GEN2 || \
+ ARCH_R8A7795 || ARCH_R8A7796
+ select SYSC_R8A7743 if ARCH_R8A7743
+ select SYSC_R8A7745 if ARCH_R8A7745
+ select SYSC_R8A7779 if ARCH_R8A7779
+ select SYSC_R8A7790 if ARCH_R8A7790
+ select SYSC_R8A7791 if ARCH_R8A7791 || ARCH_R8A7793
+ select SYSC_R8A7792 if ARCH_R8A7792
+ select SYSC_R8A7794 if ARCH_R8A7794
+ select SYSC_R8A7795 if ARCH_R8A7795
+ select SYSC_R8A7796 if ARCH_R8A7796
+
+if SOC_RENESAS
+
+# SoC
+config SYSC_R8A7743
+ bool "RZ/G1M System Controller support" if COMPILE_TEST
+ select SYSC_RCAR
+
+config SYSC_R8A7745
+ bool "RZ/G1E System Controller support" if COMPILE_TEST
+ select SYSC_RCAR
+
+config SYSC_R8A7779
+ bool "R-Car H1 System Controller support" if COMPILE_TEST
+ select SYSC_RCAR
+
+config SYSC_R8A7790
+ bool "R-Car H2 System Controller support" if COMPILE_TEST
+ select SYSC_RCAR
+
+config SYSC_R8A7791
+ bool "R-Car M2-W/N System Controller support" if COMPILE_TEST
+ select SYSC_RCAR
+
+config SYSC_R8A7792
+ bool "R-Car V2H System Controller support" if COMPILE_TEST
+ select SYSC_RCAR
+
+config SYSC_R8A7794
+ bool "R-Car E2 System Controller support" if COMPILE_TEST
+ select SYSC_RCAR
+
+config SYSC_R8A7795
+ bool "R-Car H3 System Controller support" if COMPILE_TEST
+ select SYSC_RCAR
+
+config SYSC_R8A7796
+ bool "R-Car M3-W System Controller support" if COMPILE_TEST
+ select SYSC_RCAR
+
+# Family
+config RST_RCAR
+ bool "R-Car Reset Controller support" if COMPILE_TEST
+
+config SYSC_RCAR
+ bool "R-Car System Controller support" if COMPILE_TEST
+
+endif # SOC_RENESAS
diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index d9115cb5ed9dae78..1a1a297b26a79613 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -1,18 +1,17 @@
-obj-$(CONFIG_SOC_BUS) += renesas-soc.o
+# Generic, must be first because of soc_device_register()
+obj-$(CONFIG_SOC_RENESAS) += renesas-soc.o
-obj-$(CONFIG_ARCH_RCAR_GEN1) += rcar-rst.o
-obj-$(CONFIG_ARCH_RCAR_GEN2) += rcar-rst.o
-obj-$(CONFIG_ARCH_R8A7795) += rcar-rst.o
-obj-$(CONFIG_ARCH_R8A7796) += rcar-rst.o
+# SoC
+obj-$(CONFIG_SYSC_R8A7743) += r8a7743-sysc.o
+obj-$(CONFIG_SYSC_R8A7745) += r8a7745-sysc.o
+obj-$(CONFIG_SYSC_R8A7779) += r8a7779-sysc.o
+obj-$(CONFIG_SYSC_R8A7790) += r8a7790-sysc.o
+obj-$(CONFIG_SYSC_R8A7791) += r8a7791-sysc.o
+obj-$(CONFIG_SYSC_R8A7792) += r8a7792-sysc.o
+obj-$(CONFIG_SYSC_R8A7794) += r8a7794-sysc.o
+obj-$(CONFIG_SYSC_R8A7795) += r8a7795-sysc.o
+obj-$(CONFIG_SYSC_R8A7796) += r8a7796-sysc.o
-obj-$(CONFIG_ARCH_R8A7743) += rcar-sysc.o r8a7743-sysc.o
-obj-$(CONFIG_ARCH_R8A7745) += rcar-sysc.o r8a7745-sysc.o
-obj-$(CONFIG_ARCH_R8A7779) += rcar-sysc.o r8a7779-sysc.o
-obj-$(CONFIG_ARCH_R8A7790) += rcar-sysc.o r8a7790-sysc.o
-obj-$(CONFIG_ARCH_R8A7791) += rcar-sysc.o r8a7791-sysc.o
-obj-$(CONFIG_ARCH_R8A7792) += rcar-sysc.o r8a7792-sysc.o
-# R-Car M2-N is identical to R-Car M2-W w.r.t. power domains.
-obj-$(CONFIG_ARCH_R8A7793) += rcar-sysc.o r8a7791-sysc.o
-obj-$(CONFIG_ARCH_R8A7794) += rcar-sysc.o r8a7794-sysc.o
-obj-$(CONFIG_ARCH_R8A7795) += rcar-sysc.o r8a7795-sysc.o
-obj-$(CONFIG_ARCH_R8A7796) += rcar-sysc.o r8a7796-sysc.o
+# Family
+obj-$(CONFIG_RST_RCAR) += rcar-rst.o
+obj-$(CONFIG_SYSC_RCAR) += rcar-sysc.o
diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
index 528a13742aeb98d8..dcad5c42a5e81c87 100644
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@ -275,35 +275,33 @@ static void __init rcar_sysc_pd_setup(struct rcar_sysc_pd *pd)
}
static const struct of_device_id rcar_sysc_matches[] = {
-#ifdef CONFIG_ARCH_R8A7743
+#ifdef CONFIG_SYSC_R8A7743
{ .compatible = "renesas,r8a7743-sysc", .data = &r8a7743_sysc_info },
#endif
-#ifdef CONFIG_ARCH_R8A7745
+#ifdef CONFIG_SYSC_R8A7745
{ .compatible = "renesas,r8a7745-sysc", .data = &r8a7745_sysc_info },
#endif
-#ifdef CONFIG_ARCH_R8A7779
+#ifdef CONFIG_SYSC_R8A7779
{ .compatible = "renesas,r8a7779-sysc", .data = &r8a7779_sysc_info },
#endif
-#ifdef CONFIG_ARCH_R8A7790
+#ifdef CONFIG_SYSC_R8A7790
{ .compatible = "renesas,r8a7790-sysc", .data = &r8a7790_sysc_info },
#endif
-#ifdef CONFIG_ARCH_R8A7791
+#ifdef CONFIG_SYSC_R8A7791
{ .compatible = "renesas,r8a7791-sysc", .data = &r8a7791_sysc_info },
-#endif
-#ifdef CONFIG_ARCH_R8A7792
- { .compatible = "renesas,r8a7792-sysc", .data = &r8a7792_sysc_info },
-#endif
-#ifdef CONFIG_ARCH_R8A7793
/* R-Car M2-N is identical to R-Car M2-W w.r.t. power domains. */
{ .compatible = "renesas,r8a7793-sysc", .data = &r8a7791_sysc_info },
#endif
-#ifdef CONFIG_ARCH_R8A7794
+#ifdef CONFIG_SYSC_R8A7792
+ { .compatible = "renesas,r8a7792-sysc", .data = &r8a7792_sysc_info },
+#endif
+#ifdef CONFIG_SYSC_R8A7794
{ .compatible = "renesas,r8a7794-sysc", .data = &r8a7794_sysc_info },
#endif
-#ifdef CONFIG_ARCH_R8A7795
+#ifdef CONFIG_SYSC_R8A7795
{ .compatible = "renesas,r8a7795-sysc", .data = &r8a7795_sysc_info },
#endif
-#ifdef CONFIG_ARCH_R8A7796
+#ifdef CONFIG_SYSC_R8A7796
{ .compatible = "renesas,r8a7796-sysc", .data = &r8a7796_sysc_info },
#endif
{ /* sentinel */ }
diff --git a/include/linux/soc/renesas/rcar-rst.h b/include/linux/soc/renesas/rcar-rst.h
index 787e7ad53d45f61c..2c231f2280a6dc50 100644
--- a/include/linux/soc/renesas/rcar-rst.h
+++ b/include/linux/soc/renesas/rcar-rst.h
@@ -1,8 +1,7 @@
#ifndef __LINUX_SOC_RENESAS_RCAR_RST_H__
#define __LINUX_SOC_RENESAS_RCAR_RST_H__
-#if defined(CONFIG_ARCH_RCAR_GEN1) || defined(CONFIG_ARCH_RCAR_GEN2) || \
- defined(CONFIG_ARCH_R8A7795) || defined(CONFIG_ARCH_R8A7796)
+#ifdef CONFIG_RST_RCAR
int rcar_rst_read_mode_pins(u32 *mode);
#else
static inline int rcar_rst_read_mode_pins(u32 *mode) { return -ENODEV; }
--
2.7.4
^ permalink raw reply related
* [PATCH/RFC 1/2] clk: renesas: Rework Kconfig and Makefile logic
From: Geert Uytterhoeven @ 2017-04-25 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493137626-21404-1-git-send-email-geert+renesas@glider.be>
The goals are to:
- Allow precise control over and automatic selection of which
(sub)drivers are used for which SoC (which may change in the
future),
- Allow adding support for new SoCs easily,
- Allow compile-testing of all (sub)drivers,
- Keep driver selection logic in the subsystem-specific Kconfig
independent from the architecture-specific Kconfig (i.e. no "select"
from arch/arm64/Kconfig.platforms), to avoid dependencies.
This is implemented by:
- Introducing Kconfig symbols for all drivers and sub-drivers,
- Introducing the Kconfig symbol CLK_RENESAS, which is enabled
automatically when building for a Renesas ARM platform, and which
enables all required drivers without interaction of the user, based
on SoC-specific ARCH_* symbols,
- Allowing the user to enable any Kconfig symbol manually if
COMPILE_TEST is enabled,
- Using the new Kconfig symbols instead of the ARCH_* symbols to
control compilation in the Makefile,
- Always entering drivers/clk/renesas/ during the build.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
This rework was sparked by a discussion with Olof about the Renesas
clock driver dependencies.
For now, some of the 'bool "foo clock support" if COMPILE_TEST' will
need to be replaced by 'bool', as compile-testing all drivers depends on
independent fixes, some in other subsystems.
Before anyone responds "But the CLK_R8A779[0-4] symbols can be removed,
just select CLK_RCAR_GEN2 directly!": the latter will go away, as the
shared R-Car Gen2 clock driver (which depends on describing most clocks
in DT, which is error prone, inflexible, and which prevents implementing
module reset support) will be replaced by SoC-specific drivers using the
CPG/MSSR driver core, as is already done on R-Car Gen3 and on RZ/G.
Compatibility with old DTBs will be preserved through a new Kconfig
option.
---
drivers/clk/Makefile | 2 +-
drivers/clk/renesas/Kconfig | 129 ++++++++++++++++++++++++++++-----
drivers/clk/renesas/Makefile | 37 +++++-----
drivers/clk/renesas/renesas-cpg-mssr.c | 8 +-
4 files changed, 137 insertions(+), 39 deletions(-)
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 92c12b86c2e86f20..6d341c802b299241 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -74,7 +74,7 @@ obj-$(CONFIG_COMMON_CLK_NXP) += nxp/
obj-$(CONFIG_MACH_PISTACHIO) += pistachio/
obj-$(CONFIG_COMMON_CLK_PXA) += pxa/
obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/
-obj-$(CONFIG_ARCH_RENESAS) += renesas/
+obj-y += renesas/
obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
obj-$(CONFIG_COMMON_CLK_SAMSUNG) += samsung/
obj-$(CONFIG_ARCH_SIRF) += sirf/
diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
index 2586dfa0026bb015..ec17edc6c4ab2e2a 100644
--- a/drivers/clk/renesas/Kconfig
+++ b/drivers/clk/renesas/Kconfig
@@ -1,20 +1,115 @@
+config CLK_RENESAS
+ bool "Renesas SoC clock support" if COMPILE_TEST && !ARCH_RENESAS
+ default y if ARCH_RENESAS
+ select CLK_EMEV2 if ARCH_EMEV2
+ select CLK_RZA1 if ARCH_R7S72100
+ select CLK_R8A73A4 if ARCH_R8A73A4
+ select CLK_R8A7740 if ARCH_R8A7740
+ select CLK_R8A7743 if ARCH_R8A7743
+ select CLK_R8A7745 if ARCH_R8A7745
+ select CLK_R8A7778 if ARCH_R8A7778
+ select CLK_R8A7779 if ARCH_R8A7779
+ select CLK_R8A7790 if ARCH_R8A7790
+ select CLK_R8A7791 if ARCH_R8A7791 || ARCH_R8A7793
+ select CLK_R8A7792 if ARCH_R8A7792
+ select CLK_R8A7794 if ARCH_R8A7794
+ select CLK_R8A7795 if ARCH_R8A7795
+ select CLK_R8A7796 if ARCH_R8A7796
+ select CLK_SH73A0 if ARCH_SH73A0
+
+if CLK_RENESAS
+
+# SoC
+config CLK_EMEV2
+ bool "Emma Mobile EV2 clock support" if COMPILE_TEST
+
+config CLK_RZA1
+ bool "RZ/A1H clock support" if COMPILE_TEST
+ select CLK_RENESAS_CPG_MSTP
+
+config CLK_R8A73A4
+ bool "R-Mobile APE6 clock support" if COMPILE_TEST
+ select CLK_RENESAS_CPG_MSTP
+ select CLK_RENESAS_DIV6
+
+config CLK_R8A7740
+ bool "R-Mobile A1 clock support" if COMPILE_TEST
+ select CLK_RENESAS_CPG_MSTP
+ select CLK_RENESAS_DIV6
+
+config CLK_R8A7743
+ bool "RZ/G1M clock support" if COMPILE_TEST
+ select CLK_RCAR_GEN2_CPG
+
+config CLK_R8A7745
+ bool "RZ/G1E clock support" if COMPILE_TEST
+ select CLK_RCAR_GEN2_CPG
+
+config CLK_R8A7778
+ bool "R-Car M1A clock support" if COMPILE_TEST
+ select CLK_RENESAS_CPG_MSTP
+
+config CLK_R8A7779
+ bool "R-Car H1 clock support" if COMPILE_TEST
+ select CLK_RENESAS_CPG_MSTP
+
+config CLK_R8A7790
+ bool "R-Car H2 clock support" if COMPILE_TEST
+ select CLK_RCAR_GEN2
+ select CLK_RENESAS_DIV6
+
+config CLK_R8A7791
+ bool "R-Car M2-W/N clock support" if COMPILE_TEST
+ select CLK_RCAR_GEN2
+ select CLK_RENESAS_DIV6
+
+config CLK_R8A7792
+ bool "R-Car V2H clock support" if COMPILE_TEST
+ select CLK_RCAR_GEN2
+
+config CLK_R8A7794
+ bool "R-Car E2 clock support" if COMPILE_TEST
+ select CLK_RCAR_GEN2
+ select CLK_RENESAS_DIV6
+
+config CLK_R8A7795
+ bool "R-Car H3 clock support" if COMPILE_TEST
+ select CLK_RCAR_GEN3_CPG
+
+config CLK_R8A7796
+ bool "R-Car M3-W clock support" if COMPILE_TEST
+ select CLK_RCAR_GEN3_CPG
+
+config CLK_SH73A0
+ bool "SH-Mobile AG5 clock support" if COMPILE_TEST
+ select CLK_RENESAS_CPG_MSTP
+ select CLK_RENESAS_DIV6
+
+
+# Family
+config CLK_RCAR_GEN2
+ bool "R-Car Gen2 clock support" if COMPILE_TEST
+ select CLK_RENESAS_CPG_MSTP
+ select CLK_RENESAS_DIV6
+
+config CLK_RCAR_GEN2_CPG
+ bool "R-Car Gen2 CPG clock support" if COMPILE_TEST
+ select CLK_RENESAS_CPG_MSSR
+
+config CLK_RCAR_GEN3_CPG
+ bool "R-Car Gen3 CPG clock support" if COMPILE_TEST
+ select CLK_RENESAS_CPG_MSSR
+
+
+# Generic
config CLK_RENESAS_CPG_MSSR
- bool
- default y if ARCH_R8A7743
- default y if ARCH_R8A7745
- default y if ARCH_R8A7795
- default y if ARCH_R8A7796
+ bool "CPG/MSSR clock support" if COMPILE_TEST
+ select CLK_RENESAS_DIV6
config CLK_RENESAS_CPG_MSTP
- bool
- default y if ARCH_R7S72100
- default y if ARCH_R8A73A4
- default y if ARCH_R8A7740
- default y if ARCH_R8A7778
- default y if ARCH_R8A7779
- default y if ARCH_R8A7790
- default y if ARCH_R8A7791
- default y if ARCH_R8A7792
- default y if ARCH_R8A7793
- default y if ARCH_R8A7794
- default y if ARCH_SH73A0
+ bool "MSTP clock support" if COMPILE_TEST
+
+config CLK_RENESAS_DIV6
+ bool "DIV6 clock support" if COMPILE_TEST
+
+endif # CLK_RENESAS
diff --git a/drivers/clk/renesas/Makefile b/drivers/clk/renesas/Makefile
index 5b8fccf574787632..aa24c2f5078ca333 100644
--- a/drivers/clk/renesas/Makefile
+++ b/drivers/clk/renesas/Makefile
@@ -1,19 +1,22 @@
-obj-$(CONFIG_ARCH_EMEV2) += clk-emev2.o
-obj-$(CONFIG_ARCH_R7S72100) += clk-rz.o
-obj-$(CONFIG_ARCH_R8A73A4) += clk-r8a73a4.o clk-div6.o
-obj-$(CONFIG_ARCH_R8A7740) += clk-r8a7740.o clk-div6.o
-obj-$(CONFIG_ARCH_R8A7743) += r8a7743-cpg-mssr.o rcar-gen2-cpg.o
-obj-$(CONFIG_ARCH_R8A7745) += r8a7745-cpg-mssr.o rcar-gen2-cpg.o
-obj-$(CONFIG_ARCH_R8A7778) += clk-r8a7778.o
-obj-$(CONFIG_ARCH_R8A7779) += clk-r8a7779.o
-obj-$(CONFIG_ARCH_R8A7790) += clk-rcar-gen2.o clk-div6.o
-obj-$(CONFIG_ARCH_R8A7791) += clk-rcar-gen2.o clk-div6.o
-obj-$(CONFIG_ARCH_R8A7792) += clk-rcar-gen2.o
-obj-$(CONFIG_ARCH_R8A7793) += clk-rcar-gen2.o clk-div6.o
-obj-$(CONFIG_ARCH_R8A7794) += clk-rcar-gen2.o clk-div6.o
-obj-$(CONFIG_ARCH_R8A7795) += r8a7795-cpg-mssr.o rcar-gen3-cpg.o
-obj-$(CONFIG_ARCH_R8A7796) += r8a7796-cpg-mssr.o rcar-gen3-cpg.o
-obj-$(CONFIG_ARCH_SH73A0) += clk-sh73a0.o clk-div6.o
+# SoC
+obj-$(CONFIG_CLK_EMEV2) += clk-emev2.o
+obj-$(CONFIG_CLK_RZA1) += clk-rz.o
+obj-$(CONFIG_CLK_R8A73A4) += clk-r8a73a4.o
+obj-$(CONFIG_CLK_R8A7740) += clk-r8a7740.o
+obj-$(CONFIG_CLK_R8A7743) += r8a7743-cpg-mssr.o
+obj-$(CONFIG_CLK_R8A7745) += r8a7745-cpg-mssr.o
+obj-$(CONFIG_CLK_R8A7778) += clk-r8a7778.o
+obj-$(CONFIG_CLK_R8A7779) += clk-r8a7779.o
+obj-$(CONFIG_CLK_R8A7795) += r8a7795-cpg-mssr.o
+obj-$(CONFIG_CLK_R8A7796) += r8a7796-cpg-mssr.o
+obj-$(CONFIG_CLK_SH73A0) += clk-sh73a0.o
-obj-$(CONFIG_CLK_RENESAS_CPG_MSSR) += renesas-cpg-mssr.o clk-div6.o
+# Family
+obj-$(CONFIG_CLK_RCAR_GEN2) += clk-rcar-gen2.o
+obj-$(CONFIG_CLK_RCAR_GEN2_CPG) += rcar-gen2-cpg.o
+obj-$(CONFIG_CLK_RCAR_GEN3_CPG) += rcar-gen3-cpg.o
+
+# Generic
+obj-$(CONFIG_CLK_RENESAS_CPG_MSSR) += renesas-cpg-mssr.o
obj-$(CONFIG_CLK_RENESAS_CPG_MSTP) += clk-mstp.o
+obj-$(CONFIG_CLK_RENESAS_DIV6) += clk-div6.o
diff --git a/drivers/clk/renesas/renesas-cpg-mssr.c b/drivers/clk/renesas/renesas-cpg-mssr.c
index 1799e160c88f8299..4b281a8d06edf1d3 100644
--- a/drivers/clk/renesas/renesas-cpg-mssr.c
+++ b/drivers/clk/renesas/renesas-cpg-mssr.c
@@ -627,25 +627,25 @@ static inline int cpg_mssr_reset_controller_register(struct cpg_mssr_priv *priv)
static const struct of_device_id cpg_mssr_match[] = {
-#ifdef CONFIG_ARCH_R8A7743
+#ifdef CONFIG_CLK_R8A7743
{
.compatible = "renesas,r8a7743-cpg-mssr",
.data = &r8a7743_cpg_mssr_info,
},
#endif
-#ifdef CONFIG_ARCH_R8A7745
+#ifdef CONFIG_CLK_R8A7745
{
.compatible = "renesas,r8a7745-cpg-mssr",
.data = &r8a7745_cpg_mssr_info,
},
#endif
-#ifdef CONFIG_ARCH_R8A7795
+#ifdef CONFIG_CLK_R8A7795
{
.compatible = "renesas,r8a7795-cpg-mssr",
.data = &r8a7795_cpg_mssr_info,
},
#endif
-#ifdef CONFIG_ARCH_R8A7796
+#ifdef CONFIG_CLK_R8A7796
{
.compatible = "renesas,r8a7796-cpg-mssr",
.data = &r8a7796_cpg_mssr_info,
--
2.7.4
^ permalink raw reply related
* [PATCH/RFC 0/2] clk / soc: renesas: Rework Kconfig and Makefile logic
From: Geert Uytterhoeven @ 2017-04-25 16:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
This RFC patch series reworks the Kconfig and Makefile logic for the
Renesas clock and SoC drivers. It was sparked by a discussion with Olof
about the Renesas clock driver dependencies.
The goals are to:
- Allow precise control over and automatic selection of which
(sub)drivers are used for which SoC (which may change in the
future),
- Allow adding support for new SoCs easily,
- Allow compile-testing of all (sub)drivers,
- Keep driver selection logic in the subsystem-specific Kconfig
independent from the architecture-specific Kconfig (i.e. no "select"
from arch/arm64/Kconfig.platforms), to avoid dependencies.
The series can't be applied as-is, because compile-testing all drivers
depends on independent fixes, some in other subsystems.
More details are provided in the individual patch descriptions.
For testing, this patch series, plus several fixes to allow more
compile-testing, are available in the
topic/clk-soc-renesas-Kconfig-rework branch of my renesas-drivers git
repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
This has been tested on R-Car Gen2 and Gen3, and compile-tested for
various other configurations.
Thanks for your comments!
Geert Uytterhoeven (2):
[RFC] clk: renesas: Rework Kconfig and Makefile logic
[RFC] soc: renesas: Rework Kconfig and Makefile logic
drivers/clk/Makefile | 2 +-
drivers/clk/renesas/Kconfig | 129 ++++++++++++++++++++++++++++-----
drivers/clk/renesas/Makefile | 37 +++++-----
drivers/clk/renesas/renesas-cpg-mssr.c | 8 +-
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 2 +-
drivers/soc/renesas/Kconfig | 63 ++++++++++++++++
drivers/soc/renesas/Makefile | 31 ++++----
drivers/soc/renesas/rcar-sysc.c | 24 +++---
include/linux/soc/renesas/rcar-rst.h | 3 +-
10 files changed, 229 insertions(+), 71 deletions(-)
create mode 100644 drivers/soc/renesas/Kconfig
--
2.7.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v4 00/21] PCI: fix config space memory mappings
From: Jingoo Han @ 2017-04-25 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2e24e205-d761-9172-9463-4a53e1a0de4d@jonmasters.org>
On Tuesday, April 25, 2017 2:41 AM, Jon Masters wrote:
>
> On 04/19/2017 12:48 PM, Lorenzo Pieralisi wrote:
>
> > On some platforms (ie ARM/ARM64) ioremap fails to comply with the PCI
> > configuration non-posted write transactions requirement, because it
> > provides a memory mapping that issues "bufferable" or, in PCI terms
> > "posted" write transactions. Likewise, the current pci_remap_iospace()
> > implementation maps the physical address range that the PCI translates
> > to I/O space cycles to virtual address space through pgprot_device()
> > attributes that on eg ARM64 provides a memory mapping issuing
> > posted writes transactions, which is not PCI specifications compliant.
>
> Side note that I've pinged all of the ARM server vendors and asked them
> to verify this patch series on their platforms.
Good! I really want to know the result of these patches on ARM serves.
Please share it with us. Good luck.
Best regards,
Jingoo Han
>
> Jon.
^ permalink raw reply
* [patch V2 00/24] cpu/hotplug: Convert get_online_cpus() to a percpu_rwsem
From: Mark Rutland @ 2017-04-25 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170418170442.665445272@linutronix.de>
Hi,
This series appears to break boot on some arm64 platforms, seen with
next-20170424. More info below.
On Tue, Apr 18, 2017 at 07:04:42PM +0200, Thomas Gleixner wrote:
> get_online_cpus() is used in hot pathes in mainline and even more so in
> RT. That can show up badly under certain conditions because every locker
> contends on a global mutex. RT has it's own homebrewn mitigation which is
> an (badly done) open coded implementation of percpu_rwsems with recursion
> support.
>
> The proper replacement for that are percpu_rwsems, but that requires to
> remove recursion support.
>
> The conversion unearthed real locking issues which were previously not
> visible because the get_online_cpus() lockdep annotation was implemented
> with recursion support which prevents lockdep from tracking full dependency
> chains. These potential deadlocks are not related to recursive calls, they
> trigger on the first invocation because lockdep now has the full dependency
> chains available.
Catalin spotted next-20170424 wouldn't boot on a Juno system, where we see the
following splat (repeated forever) when we try to bring up the first secondary
CPU:
[ 0.213406] smp: Bringing up secondary CPUs ...
[ 0.250326] CPU features: enabling workaround for ARM erratum 832075
[ 0.250334] BUG: scheduling while atomic: swapper/1/0/0x00000002
[ 0.250337] Modules linked in:
[ 0.250346] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.11.0-rc7-next-20170424 #2
[ 0.250349] Hardware name: ARM Juno development board (r1) (DT)
[ 0.250353] Call trace:
[ 0.250365] [<ffff000008088510>] dump_backtrace+0x0/0x238
[ 0.250371] [<ffff00000808880c>] show_stack+0x14/0x20
[ 0.250377] [<ffff00000839d854>] dump_stack+0x9c/0xc0
[ 0.250384] [<ffff0000080e3540>] __schedule_bug+0x50/0x70
[ 0.250391] [<ffff000008932ecc>] __schedule+0x52c/0x5a8
[ 0.250395] [<ffff000008932f80>] schedule+0x38/0xa0
[ 0.250400] [<ffff000008935e8c>] rwsem_down_read_failed+0xc4/0x108
[ 0.250407] [<ffff0000080fe8e0>] __percpu_down_read+0x100/0x118
[ 0.250414] [<ffff0000080c0b60>] get_online_cpus+0x70/0x78
[ 0.250420] [<ffff0000081749e8>] static_key_enable+0x28/0x48
[ 0.250425] [<ffff00000808de90>] update_cpu_capabilities+0x78/0xf8
[ 0.250430] [<ffff00000808d14c>] update_cpu_errata_workarounds+0x1c/0x28
[ 0.250435] [<ffff00000808e004>] check_local_cpu_capabilities+0xf4/0x128
[ 0.250440] [<ffff00000808e894>] secondary_start_kernel+0x8c/0x118
[ 0.250444] [<000000008093d1b4>] 0x8093d1b4
I can reproduce this with the current head of the linux-tip smp/hotplug
branch (commit 77c60400c82bd993), with arm64 defconfig on a Juno R1
system.
When we bring the secondary CPU online, we detect an erratum that wasn't
present on the boot CPU, and try to enable a static branch we use to
track the erratum. The call to static_branch_enable() blows up as above.
I see that we now have static_branch_disable_cpuslocked(), but we don't
have an equivalent for enable. I'm not sure what we should be doing
here.
Thanks,
Mark.
> The following patch series addresses this by
>
> - Cleaning up places which call get_online_cpus() nested
>
> - Replacing a few instances with cpu_hotplug_disable() to prevent circular
> locking dependencies.
>
> The series depends on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core
> plus
> Linus tree merged in to avoid conflicts
>
> It's available in git from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.hotplug
>
> Changes since V1:
>
> - Fixed fallout reported by kbuild bot
> - Repaired the recursive call in perf
> - Repaired the interaction with jumplabels (Peter Zijlstra)
> - Renamed _locked to _cpuslocked
> - Picked up Acked-bys
>
> Thanks,
>
> tglx
>
> -------
> arch/arm/kernel/hw_breakpoint.c | 5
> arch/mips/kernel/jump_label.c | 2
> arch/powerpc/kvm/book3s_hv.c | 8 -
> arch/powerpc/platforms/powernv/subcore.c | 3
> arch/s390/kernel/time.c | 2
> arch/x86/events/core.c | 1
> arch/x86/events/intel/cqm.c | 12 -
> arch/x86/kernel/cpu/mtrr/main.c | 2
> b/arch/sparc/kernel/jump_label.c | 2
> b/arch/tile/kernel/jump_label.c | 2
> b/arch/x86/events/intel/core.c | 4
> b/arch/x86/kernel/jump_label.c | 2
> b/kernel/jump_label.c | 31 ++++-
> drivers/acpi/processor_driver.c | 4
> drivers/cpufreq/cpufreq.c | 9 -
> drivers/hwtracing/coresight/coresight-etm3x.c | 12 -
> drivers/hwtracing/coresight/coresight-etm4x.c | 12 -
> drivers/pci/pci-driver.c | 47 ++++---
> include/linux/cpu.h | 2
> include/linux/cpuhotplug.h | 29 ++++
> include/linux/jump_label.h | 3
> include/linux/padata.h | 3
> include/linux/pci.h | 1
> include/linux/stop_machine.h | 26 +++-
> kernel/cpu.c | 157 ++++++++------------------
> kernel/events/core.c | 9 -
> kernel/padata.c | 39 +++---
> kernel/stop_machine.c | 7 -
> 28 files changed, 228 insertions(+), 208 deletions(-)
>
>
>
^ permalink raw reply
* [PATCH V15 04/11] efi: parse ARM processor error
From: Baicar, Tyler @ 2017-04-25 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424175240.3nvhbxzwicxnk6og@pd.tnic>
On 4/24/2017 11:52 AM, Borislav Petkov wrote:
> On Fri, Apr 21, 2017 at 12:22:09PM -0600, Baicar, Tyler wrote:
>> I guess it's not really needed. It just may be useful considering there can
>> be numerous error info structures, numerous context info structures, and a
>> variable length vendor information section. I can move this print to only in
>> the length check failure cases.
> And? Why does the user care?
>
> I mean, it is good for debugging when you wanna see you're parsing the
> error info data properly but otherwise it doesn't improve the error
> reporting one bit.
I'll move this to just happen when the length check fails.
>> Because these are part of the error information structure. I wouldn't think
>> FW would populate error information structures that are different versions
>> in the same processor error, but it could be possible from the spec (at
>> least once there are different versions of the table).
> Same argument as above.
I can remove it then.
>
>> There is an error information 64 bit value in the ARM processor error
>> information structure. (UEFI spec 2.6 table 261)
> So that's IP-dependent and explained in the following tables. Any plans
> on decoding that too?
Yes, I do plan on adding further decoding for these values in the future.
>
>> Why's that? Dumping this vendor specific error information is similar to the
>> unrecognized CPER section reporting which is also meant for vendor specific
>> information https://lkml.org/lkml/2017/4/18/751
> And how do those naked bytes help the user understand the error happening?
>
> Even in your example you have:
>
> [ 140.739210] {1}[Hardware Error]: 00000000: 4d415201 4d492031 453a4d45 435f4343 .RAM1 IMEM:ECC_C
> [ 140.739214] {1}[Hardware Error]: 00000010: 53515f45 44525f42 00000000 00000000 E_QSB_RD........
>
> Which looks like some correctable ECC DRAM error and is actually begging
> to be decoded in a human-readable form. So let's do that completely and
> not dump partially decoded information.
That seems like something that should be done outside of these patches
(if added to the kernel at all). The decoding for this information would
all be vendor specific, so I'm not sure if we want to pollute the EFI
code with vendor specific error decoding. Currently we are using the RAS
Daemon user space tool for the decoding of this information since
vendors can easily pick up this tool and add an extension for their
vendor specific parsing. These prints will only happen when the firmware
supports the vendor specific error information anyway.
Thanks,
Tyler
--
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
* Applied "regulator: arizona: Split KConfig options for LDO1 and MICSUPP regulators" to the regulator tree
From: Mark Brown @ 2017-04-25 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492512234-19210-3-git-send-email-rf@opensource.wolfsonmicro.com>
The patch
regulator: arizona: Split KConfig options for LDO1 and MICSUPP regulators
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.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 7e6425968bf742b9772aa5bae1250158c9312e31 Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Date: Tue, 18 Apr 2017 11:43:48 +0100
Subject: [PATCH] regulator: arizona: Split KConfig options for LDO1 and
MICSUPP regulators
The CS47L24 Arizona codec and most Madera codecs do not have a LDO1
regulator. Split the LDO1 and MICSUPP regulators into separate KConfig
options so the LDO1 is only built into the kernel if needed.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/regulator/Kconfig | 14 +++++++++++---
drivers/regulator/Makefile | 3 ++-
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index be06eb29c681..c026b09c479c 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -125,12 +125,20 @@ config REGULATOR_AB8500
This driver supports the regulators found on the ST-Ericsson mixed
signal AB8500 PMIC
-config REGULATOR_ARIZONA
- tristate "Wolfson Arizona class devices"
+config REGULATOR_ARIZONA_LDO1
+ tristate "Wolfson Arizona class devices LDO1"
depends on MFD_ARIZONA
depends on SND_SOC
help
- Support for the regulators found on Wolfson Arizona class
+ Support for the LDO1 regulators found on Wolfson Arizona class
+ devices.
+
+config REGULATOR_ARIZONA_MICSUPP
+ tristate "Wolfson Arizona class devices MICSUPP"
+ depends on MFD_ARIZONA
+ depends on SND_SOC
+ help
+ Support for the MICSUPP regulators found on Wolfson Arizona class
devices.
config REGULATOR_AS3711
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index ef7725e2592a..313a7ca97b4d 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -19,7 +19,8 @@ obj-$(CONFIG_REGULATOR_ACT8865) += act8865-regulator.o
obj-$(CONFIG_REGULATOR_ACT8945A) += act8945a-regulator.o
obj-$(CONFIG_REGULATOR_AD5398) += ad5398.o
obj-$(CONFIG_REGULATOR_ANATOP) += anatop-regulator.o
-obj-$(CONFIG_REGULATOR_ARIZONA) += arizona-micsupp.o arizona-ldo1.o
+obj-$(CONFIG_REGULATOR_ARIZONA_LDO1) += arizona-ldo1.o
+obj-$(CONFIG_REGULATOR_ARIZONA_MICSUPP) += arizona-micsupp.o
obj-$(CONFIG_REGULATOR_AS3711) += as3711-regulator.o
obj-$(CONFIG_REGULATOR_AS3722) += as3722-regulator.o
obj-$(CONFIG_REGULATOR_AXP20X) += axp20x-regulator.o
--
2.11.0
^ permalink raw reply related
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