* [PATCH v4 2/7] clk: at91: add I2S clock mux driver
From: Stephen Boyd @ 2018-05-31 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527251668-31396-3-git-send-email-codrin.ciubotariu@microchip.com>
Quoting Codrin Ciubotariu (2018-05-25 05:34:23)
> This driver is a simple muxing driver that controls the
> I2S's clock input by using syscon/regmap to change the parrent.
s/parrent/parent/
> The available inputs can be Peripheral clock and Generated clock.
Why capitalize peripheral and generated?
>
> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
> ---
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index 1254bf9..903f23c 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -27,6 +27,7 @@ config SOC_SAMA5D2
> select HAVE_AT91_H32MX
> select HAVE_AT91_GENERATED_CLK
> select HAVE_AT91_AUDIO_PLL
> + select HAVE_AT91_I2S_MUX_CLK
> select PINCTRL_AT91PIO4
> help
> Select this if ou are using one of Microchip's SAMA5D2 family SoC.
> @@ -129,6 +130,9 @@ config HAVE_AT91_GENERATED_CLK
> config HAVE_AT91_AUDIO_PLL
> bool
>
> +config HAVE_AT91_I2S_MUX_CLK
> + bool
> +
> config SOC_SAM_V4_V5
> bool
>
I guess this is OK.
> diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
> index 082596f..facc169 100644
> --- a/drivers/clk/at91/Makefile
> +++ b/drivers/clk/at91/Makefile
> @@ -13,3 +13,4 @@ obj-$(CONFIG_HAVE_AT91_USB_CLK) += clk-usb.o
> obj-$(CONFIG_HAVE_AT91_SMD) += clk-smd.o
> obj-$(CONFIG_HAVE_AT91_H32MX) += clk-h32mx.o
> obj-$(CONFIG_HAVE_AT91_GENERATED_CLK) += clk-generated.o
> +obj-$(CONFIG_HAVE_AT91_I2S_MUX_CLK) += clk-i2s-mux.o
> diff --git a/drivers/clk/at91/clk-i2s-mux.c b/drivers/clk/at91/clk-i2s-mux.c
> new file mode 100644
> index 0000000..2d56ded
> --- /dev/null
> +++ b/drivers/clk/at91/clk-i2s-mux.c
> @@ -0,0 +1,117 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2018 Microchip Technology Inc,
> + * Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
> + *
> + *
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/of.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +
> +#include <soc/at91/atmel-sfr.h>
> +
> +#define I2S_BUS_NR 2
> +
> +struct clk_i2s_mux {
> + struct clk_hw hw;
> + struct regmap *regmap;
> + u32 bus_id;
Can be a u8?
> +};
> +
> +#define to_clk_i2s_mux(hw) container_of(hw, struct clk_i2s_mux, hw)
> +
> +static u8 clk_i2s_mux_get_parent(struct clk_hw *hw)
> +{
> + struct clk_i2s_mux *mux = to_clk_i2s_mux(hw);
> + u32 val;
> +
> + regmap_read(mux->regmap, AT91_SFR_I2SCLKSEL, &val);
> +
> + return (val & BIT(mux->bus_id)) >> mux->bus_id;
> +}
> +
> +static int clk_i2s_mux_set_parent(struct clk_hw *hw, u8 index)
> +{
> + struct clk_i2s_mux *mux = to_clk_i2s_mux(hw);
> +
> + return regmap_update_bits(mux->regmap, AT91_SFR_I2SCLKSEL,
> + BIT(mux->bus_id), index << mux->bus_id);
> +}
> +
> +const struct clk_ops clk_i2s_mux_ops = {
static?
> + .get_parent = clk_i2s_mux_get_parent,
> + .set_parent = clk_i2s_mux_set_parent,
> + .determine_rate = __clk_mux_determine_rate,
> +};
> +
> +static struct clk_hw * __init
> +at91_clk_i2s_mux_register(struct regmap *regmap, const char *name,
> + const char * const *parent_names,
> + unsigned int num_parents, u32 bus_id)
> +{
> + struct clk_init_data init = {};
> + struct clk_i2s_mux *i2s_ck;
> + int ret;
> +
> + i2s_ck = kzalloc(sizeof(*i2s_ck), GFP_KERNEL);
> + if (!i2s_ck)
> + return ERR_PTR(-ENOMEM);
> +
> + init.name = name;
> + init.ops = &clk_i2s_mux_ops;
> + init.parent_names = parent_names;
> + init.num_parents = num_parents;
> + init.flags = CLK_IGNORE_UNUSED;
Really? Why?
> +
> + i2s_ck->hw.init = &init;
> + i2s_ck->bus_id = bus_id;
> + i2s_ck->regmap = regmap;
> +
> + ret = clk_hw_register(NULL, &i2s_ck->hw);
> + if (ret) {
> + kfree(i2s_ck);
> + return ERR_PTR(ret);
> + }
> +
> + return &i2s_ck->hw;
> +}
^ permalink raw reply
* [PATCH v4 1/7] dt-bindings: clk: at91: add an I2S mux clock
From: Stephen Boyd @ 2018-05-31 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJ=T0p17hHg6=obtydt7T-yrAeOr7C2XAEnDFQ-c0b5XQ@mail.gmail.com>
Quoting Rob Herring (2018-05-31 07:20:57)
> On Thu, May 31, 2018 at 5:25 AM, Codrin Ciubotariu
> <codrin.ciubotariu@microchip.com> wrote:
> > On 31.05.2018 03:58, Rob Herring wrote:
> >>
> >> On Fri, May 25, 2018 at 03:34:22PM +0300, Codrin Ciubotariu wrote:
> >>>
> >>> The I2S mux clock can be used to select the I2S input clock. The
> >>> available parents are the peripheral and the generated clocks.
> >>>
> >>> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
> >>> ---
> >>> .../devicetree/bindings/clock/at91-clock.txt | 34
> >>> ++++++++++++++++++++++
> >>> 1 file changed, 34 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt
> >>> b/Documentation/devicetree/bindings/clock/at91-clock.txt
> >>> index 51c259a..1c46b3c 100644
> >>> --- a/Documentation/devicetree/bindings/clock/at91-clock.txt
> >>> +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
> >>> @@ -90,6 +90,8 @@ Required properties:
> >>> "atmel,sama5d2-clk-audio-pll-pmc"
> >>> at91 audio pll output on AUDIOPLLCLK that feeds the PMC
> >>> and can be used by peripheral clock or generic clock
> >>> + "atmel,sama5d2-clk-i2s-mux":
> >>> + at91 I2S clock source selection
> >>
> >>
> >> Is this boolean or takes some values. If latter, what are valid values?
> >
> >
> > This is the compatible string of the clock driver.
>
> Ah, now I remember. AT91 uses fine grained clock nodes in DT. Is there
> still a plan to fix this?
I'm also interested in a plan.
> >>
> >>> + compatible = "atmel,sama5d2-clk-i2s-mux";
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>
> >>
> >> How do you address this block? My guess is you don't because it is just
> >> part of some other block and you are just creating this node to
> >> instantiate a driver. Just make the node for the actual h/w block a
> >> clock provider and define the clock ids (0 and 1).
> >
> >
> > This block is not addressed, but its children are. The register we access in
> > this driver is not part of other block. It's a SFR register, accessed
> > through syscon and it has nothing to do with the I2S IP (see SAMA5D2 DS,
> > page 1256, fig. 44-1: I2SC Block Diagram) that is the consumer of this
> > clock. Adding a clock-id property in the I2S node would be just like v3 of
> > this series, with the difference that we use clock-id instead of alias id to
> > set the clock parent, which is not how you suggested back then.
>
> I wasn't suggesting a clock-id property, but a clock specifier (i.e.
> make #clock-cells 1).
>
> But AT91 clocks are all a mess, so I don't know what to tell you.
>
If #clock-cells of 1 works then we should go with that. It's still weird
that we need random nodes to add more clks, but I guess that's how it's
going to be for each at91 clk driver until it changes to be one big
provider node.
^ permalink raw reply
* [PATCH v2 00/12] coresight: tmc-etr Transparent buffer management
From: Mathieu Poirier @ 2018-05-31 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527599737-28408-1-git-send-email-suzuki.poulose@arm.com>
On 29 May 2018 at 07:15, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> This series is split of the Coresight ETR perf support patches posted
> here [0]. The CATU support and perf backend support will be posted as
> separate series for better management and review of the patches.
>
> This series adds the support for TMC ETR Scatter-Gather mode to allow
> using physical non-contiguous buffer for holding the trace data. It
> also adds a layer to handle the buffer management in a transparent
> manner, independent of the underlying mode used by the TMC ETR.
> The layer chooses the ETR mode based on different parameters (size,
> re-using a set of pages, presence of an SMMU etc.).
>
> Finally we add a sysfs parameter to tune the buffer size for ETR in
> sysfs-mode.
>
> During the testing, we found out that if the TMC ETR is not properly
> connected to the memory subsystem, the ETR could lock-up the system
> while waiting for the "read" transactions to complete in scatter-gather
> mode. So, we do not use the mode on a system unless it is safe to do
> so. This is specified by a DT property "arm,scatter-gather".
>
> Applies on coreisght-next tree from Mathieu
>
> Changes since previous version [1]:
> - Rebased to Mathieu's coresight-next tree to resolve a conflict.
> - Added tags for DT changes from Rob and Mathieu
> - Split the SG mode backend support patch from the
> ETR-BUF patch.
> - Address other comments from Mathieu
>
> Changes since splitted series [0] :
> - Split the series in [0]
> - Address comments on v2
> - Rename DT property "scatter-gather" to "arm,scatter-gather"
> - Add ETM PID for Cortex-A35, use macros to make the listing easier
>
> [0] - http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/574875.html
> [1] - http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/579135.html
>
> Suzuki K Poulose (12):
> coresight: ETM: Add support for Arm Cortex-A73 and Cortex-A35
> coresight: tmc: Hide trace buffer handling for file read
> coresight: tmc-etr: Do not clean trace buffer
> coresight: tmc-etr: Disallow perf mode
> coresight: Add helper for inserting synchronization packets
> dts: bindings: Restrict coresight tmc-etr scatter-gather mode
> dts: juno: Add scatter-gather support for all revisions
> coresight: Add generic TMC sg table framework
> coresight: Add support for TMC ETR SG unit
> coresight: tmc-etr: Add transparent buffer management
> coresight: tmc-etr buf: Add TMC scatter gather mode backend
> coresight: tmc: Add configuration support for trace buffer size
>
> .../ABI/testing/sysfs-bus-coresight-devices-tmc | 8 +
> .../devicetree/bindings/arm/coresight.txt | 5 +-
> arch/arm64/boot/dts/arm/juno-base.dtsi | 1 +
> drivers/hwtracing/coresight/coresight-etb10.c | 12 +-
> drivers/hwtracing/coresight/coresight-etm4x.c | 31 +-
> drivers/hwtracing/coresight/coresight-priv.h | 10 +-
> drivers/hwtracing/coresight/coresight-tmc-etf.c | 45 +-
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 1010 ++++++++++++++++++--
> drivers/hwtracing/coresight/coresight-tmc.c | 83 +-
> drivers/hwtracing/coresight/coresight-tmc.h | 110 ++-
> drivers/hwtracing/coresight/coresight.c | 3 +-
> 11 files changed, 1144 insertions(+), 174 deletions(-)
Applied after correcting indentation problems and rectifying the
kernel version and date in "sysfs-bus-coresight-devices-tmc".
Mathieu
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 3/3] ARM: spectre-v1: fix syscall entry
From: Mark Rutland @ 2018-05-31 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1fONfn-00070N-9W@rmk-PC.armlinux.org.uk>
On Thu, May 31, 2018 at 02:31:23PM +0100, Russell King wrote:
> Prevent speculation at the syscall table decoding by clamping the index
> used to zero on invalid system call numbers, and using the csdb
> speculative barrier.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> arch/arm/kernel/entry-common.S | 14 +++-----------
> arch/arm/kernel/entry-header.S | 25 +++++++++++++++++++++++++
> 2 files changed, 28 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
> index 3c4f88701f22..78b9f20dd6a3 100644
> --- a/arch/arm/kernel/entry-common.S
> +++ b/arch/arm/kernel/entry-common.S
> @@ -242,9 +242,7 @@ ENTRY(vector_swi)
> tst r10, #_TIF_SYSCALL_WORK @ are we tracing syscalls?
> bne __sys_trace
>
> - cmp scno, #NR_syscalls @ check upper syscall limit
> - badr lr, ret_fast_syscall @ return address
> - ldrcc pc, [tbl, scno, lsl #2] @ call sys_* routine
> + invoke_syscall tbl, scno, r10, ret_fast_syscall
>
> add r1, sp, #S_OFF
> 2: cmp scno, #(__ARM_NR_BASE - __NR_SYSCALL_BASE)
> @@ -278,14 +276,8 @@ ENDPROC(vector_swi)
> mov r1, scno
> add r0, sp, #S_OFF
> bl syscall_trace_enter
> -
> - badr lr, __sys_trace_return @ return address
> - mov scno, r0 @ syscall number (possibly new)
> - add r1, sp, #S_R0 + S_OFF @ pointer to regs
> - cmp scno, #NR_syscalls @ check upper syscall limit
> - ldmccia r1, {r0 - r6} @ have to reload r0 - r6
> - stmccia sp, {r4, r5} @ and update the stack args
> - ldrcc pc, [tbl, scno, lsl #2] @ call sys_* routine
> + mov scno, r0
> + invoke_syscall tbl, scno, r10, __sys_trace_return, reload=1
> cmp scno, #-1 @ skip the syscall?
> bne 2b
> add sp, sp, #S_OFF @ restore stack
I *think* you might also need to adjust sys_syscall.
> diff --git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S
> index 0f07579af472..773424843d6e 100644
> --- a/arch/arm/kernel/entry-header.S
> +++ b/arch/arm/kernel/entry-header.S
> @@ -378,6 +378,31 @@
> #endif
> .endm
>
> + .macro invoke_syscall, table, nr, tmp, ret, reload=0
> +#ifdef CONFIG_CPU_SPECTRE
> + mov \tmp, \nr
> + cmp \tmp, #NR_syscalls @ check upper syscall limit
> + movcs \tmp, #0
> + csdb
To the best of my understanding, this sequence is sufficient.
> + badr lr, \ret @ return address
> + .if \reload
> + add r1, sp, #S_R0 + S_OFF @ pointer to regs
> + ldmccia r1, {r0 - r6} @ reload r0-r6
> + stmccia sp, {r4, r5} @ update stack arguments
> + .endif
> + ldrcc pc, [\table, \tmp, lsl #2] @ call sys_* routine
> +#else
> + cmp \nr, #NR_syscalls @ check upper syscall limit
> + badr lr, \ret @ return address
> + .if \reload
> + add r1, sp, #S_R0 + S_OFF @ pointer to regs
> + ldmccia r1, {r0 - r6} @ reload r0-r6
> + stmccia sp, {r4, r5} @ update stack arguments
> + .endif
> + ldrcc pc, [\table, \nr, lsl #2] @ call sys_* routine
> +#endif
> + .endm
I couldn't find a nice way to avoid dupliacting the body without more
ifdeffery, given the nr parameter can't be clobbered.
So modulo sys_syscall, this looks good to me.
Mark.
^ permalink raw reply
* [PATCH v4 1/7] dt-bindings: clk: at91: add an I2S mux clock
From: Rob Herring @ 2018-05-31 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152778070837.144038.4555982304713569160@swboyd.mtv.corp.google.com>
On Thu, May 31, 2018 at 10:31 AM, Stephen Boyd <sboyd@kernel.org> wrote:
> Quoting Rob Herring (2018-05-31 07:20:57)
>> On Thu, May 31, 2018 at 5:25 AM, Codrin Ciubotariu
>> <codrin.ciubotariu@microchip.com> wrote:
>> > On 31.05.2018 03:58, Rob Herring wrote:
>> >>
>> >> On Fri, May 25, 2018 at 03:34:22PM +0300, Codrin Ciubotariu wrote:
>> >>>
>> >>> The I2S mux clock can be used to select the I2S input clock. The
>> >>> available parents are the peripheral and the generated clocks.
>> >>>
>> >>> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
>> >>> ---
>> >>> .../devicetree/bindings/clock/at91-clock.txt | 34
>> >>> ++++++++++++++++++++++
>> >>> 1 file changed, 34 insertions(+)
>> >>>
>> >>> diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt
>> >>> b/Documentation/devicetree/bindings/clock/at91-clock.txt
>> >>> index 51c259a..1c46b3c 100644
>> >>> --- a/Documentation/devicetree/bindings/clock/at91-clock.txt
>> >>> +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
>> >>> @@ -90,6 +90,8 @@ Required properties:
>> >>> "atmel,sama5d2-clk-audio-pll-pmc"
>> >>> at91 audio pll output on AUDIOPLLCLK that feeds the PMC
>> >>> and can be used by peripheral clock or generic clock
>> >>> + "atmel,sama5d2-clk-i2s-mux":
>> >>> + at91 I2S clock source selection
>> >>
>> >>
>> >> Is this boolean or takes some values. If latter, what are valid values?
>> >
>> >
>> > This is the compatible string of the clock driver.
>>
>> Ah, now I remember. AT91 uses fine grained clock nodes in DT. Is there
>> still a plan to fix this?
>
> I'm also interested in a plan.
>
>> >>
>> >>> + compatible = "atmel,sama5d2-clk-i2s-mux";
>> >>> + #address-cells = <1>;
>> >>> + #size-cells = <0>;
>> >>
>> >>
>> >> How do you address this block? My guess is you don't because it is just
>> >> part of some other block and you are just creating this node to
>> >> instantiate a driver. Just make the node for the actual h/w block a
>> >> clock provider and define the clock ids (0 and 1).
>> >
>> >
>> > This block is not addressed, but its children are. The register we access in
>> > this driver is not part of other block. It's a SFR register, accessed
>> > through syscon and it has nothing to do with the I2S IP (see SAMA5D2 DS,
>> > page 1256, fig. 44-1: I2SC Block Diagram) that is the consumer of this
>> > clock. Adding a clock-id property in the I2S node would be just like v3 of
>> > this series, with the difference that we use clock-id instead of alias id to
>> > set the clock parent, which is not how you suggested back then.
>>
>> I wasn't suggesting a clock-id property, but a clock specifier (i.e.
>> make #clock-cells 1).
>>
>> But AT91 clocks are all a mess, so I don't know what to tell you.
>>
>
> If #clock-cells of 1 works then we should go with that. It's still weird
> that we need random nodes to add more clks, but I guess that's how it's
> going to be for each at91 clk driver until it changes to be one big
> provider node.
Seems to me that clock additions could use a new binding and we start
with a new driver that handles these few clocks initially. But I
haven't looked whether both can coexist.
Rob
^ permalink raw reply
* [PATCH v2 2/6] arm64: KVM: Handle Set/Way CMOs as NOPs if FWB is present
From: Mark Rutland @ 2018-05-31 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <83a4edd3-abea-b6c4-9513-3705cc92b52b@arm.com>
On Thu, May 31, 2018 at 02:00:11PM +0100, Marc Zyngier wrote:
> On 31/05/18 12:51, Mark Rutland wrote:
> > On Wed, May 30, 2018 at 01:47:02PM +0100, Marc Zyngier wrote:
> >> Set/Way handling is one of the ugliest corners of KVM. We shouldn't
> >> have to handle that, but better safe than sorry.
> >>
> >> Thankfully, FWB fixes this for us by not requiering any maintenance
> >> whatsoever, which means we don't have to emulate S/W CMOs, and don't
> >> have to track VM ops either.
> >>
> >> We still have to trap S/W though, if only to prevent the guest from
> >> doing something bad.
> >
> > S/W ops *also* do I-cache maintenance, so we'd still need to emulate
> > that. Though it looks like we're missing that today...
>
> This doesn't look right: CSSELR_EL1 does indeed have an InD bit, but
> that's only for the purpose of reading CSSIDR_EL1. DC CSW and co
> directly take a level *without* the InD bit, and seem to be limited to
> "data and unified cache".
>
> Am I missing something?
No; I was mistaken.
Sorry for the noise!
Mark.
^ permalink raw reply
* [PATCH v4 1/7] dt-bindings: clk: at91: add an I2S mux clock
From: Alexandre Belloni @ 2018-05-31 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJ=T0p17hHg6=obtydt7T-yrAeOr7C2XAEnDFQ-c0b5XQ@mail.gmail.com>
On 31/05/2018 09:20:57-0500, Rob Herring wrote:
> On Thu, May 31, 2018 at 5:25 AM, Codrin Ciubotariu
> <codrin.ciubotariu@microchip.com> wrote:
> > On 31.05.2018 03:58, Rob Herring wrote:
> >>
> >> On Fri, May 25, 2018 at 03:34:22PM +0300, Codrin Ciubotariu wrote:
> >>>
> >>> The I2S mux clock can be used to select the I2S input clock. The
> >>> available parents are the peripheral and the generated clocks.
> >>>
> >>> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
> >>> ---
> >>> .../devicetree/bindings/clock/at91-clock.txt | 34
> >>> ++++++++++++++++++++++
> >>> 1 file changed, 34 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt
> >>> b/Documentation/devicetree/bindings/clock/at91-clock.txt
> >>> index 51c259a..1c46b3c 100644
> >>> --- a/Documentation/devicetree/bindings/clock/at91-clock.txt
> >>> +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
> >>> @@ -90,6 +90,8 @@ Required properties:
> >>> "atmel,sama5d2-clk-audio-pll-pmc"
> >>> at91 audio pll output on AUDIOPLLCLK that feeds the PMC
> >>> and can be used by peripheral clock or generic clock
> >>> + "atmel,sama5d2-clk-i2s-mux":
> >>> + at91 I2S clock source selection
> >>
> >>
> >> Is this boolean or takes some values. If latter, what are valid values?
> >
> >
> > This is the compatible string of the clock driver.
>
> Ah, now I remember. AT91 uses fine grained clock nodes in DT. Is there
> still a plan to fix this?
>
There is still a plan to do that, hopefully soon (I'd like to aim for
the next release or the one after).
I think this one should go in as-is so it can be fixed with all the
other one at once.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PULL REQUEST] arm: Actions DT for v4.18
From: Manivannan Sadhasivam @ 2018-05-31 16:04 UTC (permalink / raw)
To: linux-arm-kernel
Hi Andreas,
Here is the pull request for Devicetree and Maintainer changes for the Actions
platform as suggested by Linus Walleij. Relevant drivers are already applied
by the respective subsystem maintainers.
Please pull it in!
PS: I haven't added the SPS patches since it is not yet reviewed by you.
Thanks,
Mani
The following changes since commit ee7ffc878fdedd82831df81af6ec334daff9decb:
Add linux-next specific files for 20180530 (2018-05-30 21:42:04 +1000)
are available in the git repository at:
git://git.linaro.org/people/manivannan.sadhasivam/linux.git s900-for-next
for you to fetch changes up to b2a2e190e41c92e10aec8440c4207efc8abd0643:
MAINTAINERS: Add Actions Semi S900 clk entries (2018-05-31 15:17:34 +0530)
----------------------------------------------------------------
Manivannan Sadhasivam (8):
arm64: dts: actions: Add S900 clock management unit nodes
arm64: dts: actions: Source CMU clock for UART5
arm64: dts: actions: Add pinctrl node for S900
arm64: actions: Enable PINCTRL in platforms Kconfig
MAINTAINERS: Add reviewer for ACTIONS platforms
arm64: dts: actions: Add gpio properties to pinctrl node for S900
arm64: dts: actions: Add gpio line names to Bubblegum-96 board
MAINTAINERS: Add Actions Semi S900 clk entries
MAINTAINERS | 3 +
arch/arm64/Kconfig.platforms | 1 +
arch/arm64/boot/dts/actions/s900-bubblegum-96.dts | 183 +++++++++++++++++++++-
arch/arm64/boot/dts/actions/s900.dtsi | 29 ++++
4 files changed, 209 insertions(+), 7 deletions(-)
^ permalink raw reply
* [PATCH v2 3/3] ARM: spectre-v1: fix syscall entry
From: Russell King @ 2018-05-31 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531155543.t6b3feckgmq6ebwa@lakrids.cambridge.arm.com>
Prevent speculation at the syscall table decoding by clamping the index
used to zero on invalid system call numbers, and using the csdb
speculative barrier.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/kernel/entry-common.S | 18 +++++++-----------
| 25 +++++++++++++++++++++++++
2 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 3c4f88701f22..20df608bf343 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -242,9 +242,7 @@ ENTRY(vector_swi)
tst r10, #_TIF_SYSCALL_WORK @ are we tracing syscalls?
bne __sys_trace
- cmp scno, #NR_syscalls @ check upper syscall limit
- badr lr, ret_fast_syscall @ return address
- ldrcc pc, [tbl, scno, lsl #2] @ call sys_* routine
+ invoke_syscall tbl, scno, r10, ret_fast_syscall
add r1, sp, #S_OFF
2: cmp scno, #(__ARM_NR_BASE - __NR_SYSCALL_BASE)
@@ -278,14 +276,8 @@ ENDPROC(vector_swi)
mov r1, scno
add r0, sp, #S_OFF
bl syscall_trace_enter
-
- badr lr, __sys_trace_return @ return address
- mov scno, r0 @ syscall number (possibly new)
- add r1, sp, #S_R0 + S_OFF @ pointer to regs
- cmp scno, #NR_syscalls @ check upper syscall limit
- ldmccia r1, {r0 - r6} @ have to reload r0 - r6
- stmccia sp, {r4, r5} @ and update the stack args
- ldrcc pc, [tbl, scno, lsl #2] @ call sys_* routine
+ mov scno, r0
+ invoke_syscall tbl, scno, r10, __sys_trace_return, reload=1
cmp scno, #-1 @ skip the syscall?
bne 2b
add sp, sp, #S_OFF @ restore stack
@@ -363,6 +355,10 @@ ENTRY(\sym)
bic scno, r0, #__NR_OABI_SYSCALL_BASE
cmp scno, #__NR_syscall - __NR_SYSCALL_BASE
cmpne scno, #NR_syscalls @ check range
+#ifdef CONFIG_CPU_SPECTRE
+ movhs scno, #0
+ csdb
+#endif
stmloia sp, {r5, r6} @ shuffle args
movlo r0, r1
movlo r1, r2
--git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S
index 0f07579af472..773424843d6e 100644
--- a/arch/arm/kernel/entry-header.S
+++ b/arch/arm/kernel/entry-header.S
@@ -378,6 +378,31 @@
#endif
.endm
+ .macro invoke_syscall, table, nr, tmp, ret, reload=0
+#ifdef CONFIG_CPU_SPECTRE
+ mov \tmp, \nr
+ cmp \tmp, #NR_syscalls @ check upper syscall limit
+ movcs \tmp, #0
+ csdb
+ badr lr, \ret @ return address
+ .if \reload
+ add r1, sp, #S_R0 + S_OFF @ pointer to regs
+ ldmccia r1, {r0 - r6} @ reload r0-r6
+ stmccia sp, {r4, r5} @ update stack arguments
+ .endif
+ ldrcc pc, [\table, \tmp, lsl #2] @ call sys_* routine
+#else
+ cmp \nr, #NR_syscalls @ check upper syscall limit
+ badr lr, \ret @ return address
+ .if \reload
+ add r1, sp, #S_R0 + S_OFF @ pointer to regs
+ ldmccia r1, {r0 - r6} @ reload r0-r6
+ stmccia sp, {r4, r5} @ update stack arguments
+ .endif
+ ldrcc pc, [\table, \nr, lsl #2] @ call sys_* routine
+#endif
+ .endm
+
/*
* These are the registers used in the syscall handler, and allow us to
* have in theory up to 7 arguments to a function - r0 to r6.
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/3] ARM: spectre-v1: fix syscall entry
From: Mark Rutland @ 2018-05-31 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1fOQ5w-0007ej-El@rmk-PC.armlinux.org.uk>
On Thu, May 31, 2018 at 05:06:32PM +0100, Russell King wrote:
> Prevent speculation at the syscall table decoding by clamping the index
> used to zero on invalid system call numbers, and using the csdb
> speculative barrier.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
> arch/arm/kernel/entry-common.S | 18 +++++++-----------
> arch/arm/kernel/entry-header.S | 25 +++++++++++++++++++++++++
> 2 files changed, 32 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
> index 3c4f88701f22..20df608bf343 100644
> --- a/arch/arm/kernel/entry-common.S
> +++ b/arch/arm/kernel/entry-common.S
> @@ -242,9 +242,7 @@ ENTRY(vector_swi)
> tst r10, #_TIF_SYSCALL_WORK @ are we tracing syscalls?
> bne __sys_trace
>
> - cmp scno, #NR_syscalls @ check upper syscall limit
> - badr lr, ret_fast_syscall @ return address
> - ldrcc pc, [tbl, scno, lsl #2] @ call sys_* routine
> + invoke_syscall tbl, scno, r10, ret_fast_syscall
>
> add r1, sp, #S_OFF
> 2: cmp scno, #(__ARM_NR_BASE - __NR_SYSCALL_BASE)
> @@ -278,14 +276,8 @@ ENDPROC(vector_swi)
> mov r1, scno
> add r0, sp, #S_OFF
> bl syscall_trace_enter
> -
> - badr lr, __sys_trace_return @ return address
> - mov scno, r0 @ syscall number (possibly new)
> - add r1, sp, #S_R0 + S_OFF @ pointer to regs
> - cmp scno, #NR_syscalls @ check upper syscall limit
> - ldmccia r1, {r0 - r6} @ have to reload r0 - r6
> - stmccia sp, {r4, r5} @ and update the stack args
> - ldrcc pc, [tbl, scno, lsl #2] @ call sys_* routine
> + mov scno, r0
> + invoke_syscall tbl, scno, r10, __sys_trace_return, reload=1
> cmp scno, #-1 @ skip the syscall?
> bne 2b
> add sp, sp, #S_OFF @ restore stack
> @@ -363,6 +355,10 @@ ENTRY(\sym)
> bic scno, r0, #__NR_OABI_SYSCALL_BASE
> cmp scno, #__NR_syscall - __NR_SYSCALL_BASE
> cmpne scno, #NR_syscalls @ check range
> +#ifdef CONFIG_CPU_SPECTRE
> + movhs scno, #0
> + csdb
> +#endif
> stmloia sp, {r5, r6} @ shuffle args
> movlo r0, r1
> movlo r1, r2
> diff --git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S
> index 0f07579af472..773424843d6e 100644
> --- a/arch/arm/kernel/entry-header.S
> +++ b/arch/arm/kernel/entry-header.S
> @@ -378,6 +378,31 @@
> #endif
> .endm
>
> + .macro invoke_syscall, table, nr, tmp, ret, reload=0
> +#ifdef CONFIG_CPU_SPECTRE
> + mov \tmp, \nr
> + cmp \tmp, #NR_syscalls @ check upper syscall limit
> + movcs \tmp, #0
> + csdb
> + badr lr, \ret @ return address
> + .if \reload
> + add r1, sp, #S_R0 + S_OFF @ pointer to regs
> + ldmccia r1, {r0 - r6} @ reload r0-r6
> + stmccia sp, {r4, r5} @ update stack arguments
> + .endif
> + ldrcc pc, [\table, \tmp, lsl #2] @ call sys_* routine
> +#else
> + cmp \nr, #NR_syscalls @ check upper syscall limit
> + badr lr, \ret @ return address
> + .if \reload
> + add r1, sp, #S_R0 + S_OFF @ pointer to regs
> + ldmccia r1, {r0 - r6} @ reload r0-r6
> + stmccia sp, {r4, r5} @ update stack arguments
> + .endif
> + ldrcc pc, [\table, \nr, lsl #2] @ call sys_* routine
> +#endif
> + .endm
> +
> /*
> * These are the registers used in the syscall handler, and allow us to
> * have in theory up to 7 arguments to a function - r0 to r6.
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v4 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
From: Christoph Hellwig @ 2018-05-31 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530140625.21247-3-thierry.reding@gmail.com>
> +#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
> + if (dev->archdata.mapping) {
> + struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
> +
> + arm_iommu_detach_device(dev);
> + arm_iommu_release_mapping(mapping);
> + }
> +#endif
Having this hidden in a helper would be nicer, but anything that
doesn't directly expose the dma_map_ops to a driver is fine with me.
So from the dma-mapping POV:
Acked-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* [PATCH v2 00/12] coresight: tmc-etr Transparent buffer management
From: Suzuki K Poulose @ 2018-05-31 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkxStH5R0_8WFF1oe=PCCFr4Ko+0J+Xhn-wzopFFDgrRCw@mail.gmail.com>
On 31/05/18 16:36, Mathieu Poirier wrote:
> On 29 May 2018 at 07:15, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>> Suzuki K Poulose (12):
>> coresight: ETM: Add support for Arm Cortex-A73 and Cortex-A35
>> coresight: tmc: Hide trace buffer handling for file read
>> coresight: tmc-etr: Do not clean trace buffer
>> coresight: tmc-etr: Disallow perf mode
>> coresight: Add helper for inserting synchronization packets
>> dts: bindings: Restrict coresight tmc-etr scatter-gather mode
>> dts: juno: Add scatter-gather support for all revisions
>> coresight: Add generic TMC sg table framework
>> coresight: Add support for TMC ETR SG unit
>> coresight: tmc-etr: Add transparent buffer management
>> coresight: tmc-etr buf: Add TMC scatter gather mode backend
>> coresight: tmc: Add configuration support for trace buffer size
>>
>> .../ABI/testing/sysfs-bus-coresight-devices-tmc | 8 +
>> .../devicetree/bindings/arm/coresight.txt | 5 +-
>> arch/arm64/boot/dts/arm/juno-base.dtsi | 1 +
>> drivers/hwtracing/coresight/coresight-etb10.c | 12 +-
>> drivers/hwtracing/coresight/coresight-etm4x.c | 31 +-
>> drivers/hwtracing/coresight/coresight-priv.h | 10 +-
>> drivers/hwtracing/coresight/coresight-tmc-etf.c | 45 +-
>> drivers/hwtracing/coresight/coresight-tmc-etr.c | 1010 ++++++++++++++++++--
>> drivers/hwtracing/coresight/coresight-tmc.c | 83 +-
>> drivers/hwtracing/coresight/coresight-tmc.h | 110 ++-
>> drivers/hwtracing/coresight/coresight.c | 3 +-
>> 11 files changed, 1144 insertions(+), 174 deletions(-)
>
> Applied after correcting indentation problems and rectifying the
> kernel version and date in "sysfs-bus-coresight-devices-tmc".
Mathieu,
Thanks for the fixups.
Suzuki
^ permalink raw reply
* [PATCH v4] coresight: documentation: update sysfs section
From: Kim Phillips @ 2018-05-31 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516152458.d392b0d1e09393da30e2aeb6@arm.com>
- Align and show updated ls devices output from the TC2, based on
current driver
- Provide an example from an ETMv4 based system (Juno)
- Reflect changes to the way the RAM write pointer is accessed since
it got changed in commit 7d83d17795ef ("coresight: tmc: adding sysFS
management entries").
Cc: Jonathan Corbet <corbet@lwn.net>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Kim Phillips <kim.phillips@arm.com>
---
v4: v3 + Randy and Mathieu's acked-bys, for Jonathan to apply.
v3: address Randy Dunlap's showns->shown, corrected - and + line merging
v2: address Mathieu's comment about clarifying the sinks on the Juno
vs. TC2 platforms.
Documentation/trace/coresight.txt | 43 +++++++++++++++++++------------
1 file changed, 26 insertions(+), 17 deletions(-)
diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt
index 6f0120c3a4f1..15d2a0f1e1b8 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -141,13 +141,25 @@ register the device with the core framework. The unregister function takes
a reference to a "struct coresight_device", obtained at registration time.
If everything goes well during the registration process the new devices will
-show up under /sys/bus/coresight/devices, as showns here for a TC2 platform:
+show up under /sys/bus/coresight/devices, as shown here for a TC2 platform:
root:~# ls /sys/bus/coresight/devices/
-replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
-20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm replicator
+20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
root:~#
+and here for a Juno platform:
+
+root at juno:~# ls /sys/bus/coresight/devices/
+20010000.etf 20120000.replicator 22040000.etm 230c0000.funnel
+20030000.tpiu 20130000.funnel 220c0000.funnel 23140000.etm
+20040000.funnel 20140000.etf 22140000.etm 23240000.etm
+20070000.etr 20150000.funnel 23040000.etm 23340000.etm
+root at juno:~#
+
+Note that on Juno users can select the ETF, ETR and TPIU as a sink target while
+on TC2, the ETB and TPIU can be selected.
+
The functions take a "struct coresight_device", which looks like this:
struct coresight_desc {
@@ -193,16 +205,16 @@ the information carried in "THIS_MODULE".
How to use the tracer modules
-----------------------------
-Before trace collection can start, a coresight sink needs to be identify.
+Before trace collection can start, a coresight sink needs to be identified.
There is no limit on the amount of sinks (nor sources) that can be enabled at
any given moment. As a generic operation, all device pertaining to the sink
class will have an "active" entry in sysfs:
root:/sys/bus/coresight/devices# ls
-replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
-20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm replicator
+20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
root:/sys/bus/coresight/devices# ls 20010000.etb
-enable_sink status trigger_cntr
+enable_sink mgmt power subsystem trigger_cntr uevent
root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
1
@@ -216,16 +228,13 @@ trigger a trace capture:
root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
1
-root:/sys/bus/coresight/devices# cat 20010000.etb/status
-Depth: 0x2000
-Status: 0x1
-RAM read ptr: 0x0
-RAM wrt ptr: 0x19d3 <----- The write pointer is moving
-Trigger cnt: 0x0
-Control: 0x1
-Flush status: 0x0
-Flush ctrl: 0x2001
-root:/sys/bus/coresight/devices#
+
+Observe the write pointer moving:
+
+root:/sys/bus/coresight/devices# cat 20010000.etb/mgmt/rwp
+0x1a8
+root:/sys/bus/coresight/devices# cat 20010000.etb/mgmt/rwp
+0x19a6
Trace collection is stopped the same way:
--
2.17.0
^ permalink raw reply related
* [PATCH 2/3] clk: bcm: Update and add tingray clock entries
From: Rob Herring @ 2018-05-31 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527266717-8406-3-git-send-email-ray.jui@broadcom.com>
On Fri, May 25, 2018 at 09:45:16AM -0700, Ray Jui wrote:
> Update and add Stingray clock definitions and tables so they match the
> binding document and the latest ASIC datasheet
>
> Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
> drivers/clk/bcm/clk-sr.c | 135 ++++++++++++++++++++++++++++++++-----
> include/dt-bindings/clock/bcm-sr.h | 24 +++++--
This goes in the 1st patch.
> 2 files changed, 137 insertions(+), 22 deletions(-)
^ permalink raw reply
* [PATCH v2 1/6] ARM: dra762: hwmod: Add MCAN support
From: Faiz Abbas @ 2018-05-31 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531152623.GN5705@atomide.com>
Hi,
On Thursday 31 May 2018 08:56 PM, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [180531 06:18]:
>> On 30/05/18 18:54, Tony Lindgren wrote:
>>> * Tero Kristo <t-kristo@ti.com> [180530 15:44]:
>>>> On 30/05/18 18:28, Tony Lindgren wrote:
>>>>> * Tero Kristo <t-kristo@ti.com> [180530 15:18]:
>>>>>> For the OCP if part, I think that is still needed until we switch over to
>>>>>> full sysc driver. clkctrl_offs you probably also need because that is used
>>>>>> for mapping the omap_hwmod against a specific clkctrl clock. Those can be
>>>>>> only removed once we are done with hwmod (or figure out some other way to
>>>>>> assign the clkctrl clock to a hwmod.)
>>>>>
>>>>> Hmm might be worth testing. I thought your commit 70f05be32133
>>>>> ("ARM: OMAP2+: hwmod: populate clkctrl clocks for hwmods if available")
>>>>> already parses the clkctrl from dts?
>>>>
>>>> It maps the clkctrl clock to be used by hwmod, if those are available. We
>>>> didn't add any specific clock entries to DT for mapping the actual clkctrl
>>>> clock without the hwmod_data hints yet though, as that was deemed temporary
>>>> solution only due to transition to interconnect driver. I.e., you would need
>>>> something like this in DT for every device node:
>>>>
>>>> &uart3 {
>>>> clocks = <l4per_clkctrl UART3_CLK 0>;
>>>> clock-names = "clkctrl";
>>>> };
>>>>
>>>> ... which is currently not present.
>>>
>>> Hmm is that not the "fck" clkctrl clock we have already in
>>> the dts files for the interconnect target modules?
>>
>> Oh okay, yeah, we could parse that one, but currently it is not done, and is
>> not present for everything either I believe.
>>
>>> We can also use pdata callbacks to pass the clock node if
>>> needed. But I guess I don't quite still understand what we
>>> are missing :)
>>
>> So, what is missing is the glue logic only from the hwmod codebase. Right
>> now this is not supported but should be relatively trivial thing to add if
>> we really want to do this.
>
> OK let's think about this a bit for v4.19 then.
>
I am not sure what the conclusion is. Should I try removing the
clkctrl_offsets, clkdm_name, and main_clk?
Thanks,
Faiz
^ permalink raw reply
* [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN
From: Faiz Abbas @ 2018-05-31 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531134507.GK5705@atomide.com>
Hi,
On Thursday 31 May 2018 07:15 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180531 10:22]:
>> On Wednesday 30 May 2018 08:34 PM, Tony Lindgren wrote:
>>> Looks good to me except I think the reset won't do anything currently
>>> with ti-sysc.c unless you specfify also "ti,hwmods" for the module?
>>>
>>> Can you please check? It might be worth adding the reset function to
>>> ti-sysc.c for non "ti,hwmods" case and that just might remove the
>>> need for any hwmod code for this module.
>>>
>>
>> If I understand correctly, this involves adding a (*reset_module) in
>> ti_sysc_platform_data and defining a ti_sysc_reset_module() in ti-sysc.c
>> similar to ti_sysc_idle_module(). Right?
>
> Well try moving "ti,hwmods" to the module level first. Then reset will
> happen with enable.
Ok. Let me try that.
Thanks,
Faiz
^ permalink raw reply
* [PATCH v2 1/6] ARM: dra762: hwmod: Add MCAN support
From: Tony Lindgren @ 2018-05-31 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f74763ed-7e27-146b-6856-6be1b2ba630d@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180531 16:36]:
> Hi,
>
> On Thursday 31 May 2018 08:56 PM, Tony Lindgren wrote:
> > * Tero Kristo <t-kristo@ti.com> [180531 06:18]:
> >> On 30/05/18 18:54, Tony Lindgren wrote:
> >>> * Tero Kristo <t-kristo@ti.com> [180530 15:44]:
> >>>> On 30/05/18 18:28, Tony Lindgren wrote:
> >>>>> * Tero Kristo <t-kristo@ti.com> [180530 15:18]:
> >>>>>> For the OCP if part, I think that is still needed until we switch over to
> >>>>>> full sysc driver. clkctrl_offs you probably also need because that is used
> >>>>>> for mapping the omap_hwmod against a specific clkctrl clock. Those can be
> >>>>>> only removed once we are done with hwmod (or figure out some other way to
> >>>>>> assign the clkctrl clock to a hwmod.)
> >>>>>
> >>>>> Hmm might be worth testing. I thought your commit 70f05be32133
> >>>>> ("ARM: OMAP2+: hwmod: populate clkctrl clocks for hwmods if available")
> >>>>> already parses the clkctrl from dts?
> >>>>
> >>>> It maps the clkctrl clock to be used by hwmod, if those are available. We
> >>>> didn't add any specific clock entries to DT for mapping the actual clkctrl
> >>>> clock without the hwmod_data hints yet though, as that was deemed temporary
> >>>> solution only due to transition to interconnect driver. I.e., you would need
> >>>> something like this in DT for every device node:
> >>>>
> >>>> &uart3 {
> >>>> clocks = <l4per_clkctrl UART3_CLK 0>;
> >>>> clock-names = "clkctrl";
> >>>> };
> >>>>
> >>>> ... which is currently not present.
> >>>
> >>> Hmm is that not the "fck" clkctrl clock we have already in
> >>> the dts files for the interconnect target modules?
> >>
> >> Oh okay, yeah, we could parse that one, but currently it is not done, and is
> >> not present for everything either I believe.
> >>
> >>> We can also use pdata callbacks to pass the clock node if
> >>> needed. But I guess I don't quite still understand what we
> >>> are missing :)
> >>
> >> So, what is missing is the glue logic only from the hwmod codebase. Right
> >> now this is not supported but should be relatively trivial thing to add if
> >> we really want to do this.
> >
> > OK let's think about this a bit for v4.19 then.
> >
>
> I am not sure what the conclusion is. Should I try removing the
> clkctrl_offsets, clkdm_name, and main_clk?
No need to, it's not going to work currently without them.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 00/17] arm64 SSBD (aka Spectre-v4) mitigation
From: Catalin Marinas @ 2018-05-31 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529121121.24927-1-marc.zyngier@arm.com>
On Tue, May 29, 2018 at 01:11:04PM +0100, Marc Zyngier wrote:
> Marc Zyngier (17):
> arm/arm64: smccc: Add SMCCC-specific return codes
> arm64: Call ARCH_WORKAROUND_2 on transitions between EL0 and EL1
> arm64: Add per-cpu infrastructure to call ARCH_WORKAROUND_2
> arm64: Add ARCH_WORKAROUND_2 probing
> arm64: Add 'ssbd' command-line option
> arm64: ssbd: Add global mitigation state accessor
> arm64: ssbd: Skip apply_ssbd if not using dynamic mitigation
> arm64: ssbd: Restore mitigation status on CPU resume
> arm64: ssbd: Introduce thread flag to control userspace mitigation
> arm64: ssbd: Add prctl interface for per-thread mitigation
> arm64: KVM: Add HYP per-cpu accessors
> arm64: KVM: Add ARCH_WORKAROUND_2 support for guests
> arm64: KVM: Handle guest's ARCH_WORKAROUND_2 requests
> arm64: KVM: Add ARCH_WORKAROUND_2 discovery through
> ARCH_FEATURES_FUNC_ID
I queued the 14 patches above for 4.18.
> arm64: Add test_and_clear_flag and set_flag atomic assembler
> primitives
> arm64: ssbd: Enable delayed setting of TIF_SSBD
> arm64: ssbd: Implement arch_seccomp_spec_mitigate
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH] dt-bindings: arm: Remove obsolete insignal-boards.txt
From: Rob Herring @ 2018-05-31 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528185310.21971-1-krzk@kernel.org>
On Mon, May 28, 2018 at 08:53:10PM +0200, Krzysztof Kozlowski wrote:
> The compatibles mentioned in insignal-boards.txt are already documented
> under devicetree/bindings/arm/samsung/samsung-boards.txt. Also the
> contents of insignal-boards.txt is not accurate, e.g. does not mention
> Arndale boards.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> Documentation/devicetree/bindings/arm/insignal-boards.txt | 8 --------
> 1 file changed, 8 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/insignal-boards.txt
Reviewd-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2] arm64: allwinner: a64-amarula-relic: Enable AP6330 WiFi support
From: Jagan Teki @ 2018-05-31 16:51 UTC (permalink / raw)
To: linux-arm-kernel
Enable AP6330 WiFi/BT combo chip on Amarula A64-Relic board:
- WiFi SDIO interface is connected to MMC1
- WiFi WL-PMU-EN pin connected to gpio PL2: attach to mmc-pwrseq
- WiFi WL-WAKE-AP pin connected to gpio PL3
- 32kHz external oscillator gate clock from RTC
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- Move external rtc clock nodes into main rtc node definition
of sun50i-a64.dtsi
.../dts/allwinner/sun50i-a64-amarula-relic.dts | 31 ++++++++++++++++++++++
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 3 +++
2 files changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
index ce4a256ff086..eac4793c8502 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
@@ -21,12 +21,43 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+ wifi_pwrseq: wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&rtc 1>;
+ clock-names = "ext_clock";
+ reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* WL-PMU-EN: PL2 */
+ };
};
&ehci0 {
status = "okay";
};
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ vmmc-supply = <®_dcdc1>;
+ /*
+ * Schematic shows both dldo4 and eldo1 connected for vcc-io-wifi, but
+ * dldo4 connection shows DNP(Do Not Populate) and eldo1 connected with
+ * 0Ohm register to vcc-io-wifi so eldo1 is used.
+ */
+ vqmmc-supply = <®_eldo1>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+
+ brcmf: wifi at 1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ interrupt-parent = <&r_pio>;
+ interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* WL-WAKE-AP: PL3 */
+ interrupt-names = "host-wake";
+ };
+};
+
&mmc2 {
pinctrl-names = "default";
pinctrl-0 = <&mmc2_pins>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 1b2ef28c42bd..82516aec4153 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -634,6 +634,9 @@
reg = <0x01f00000 0x54>;
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+ clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
+ clocks = <&osc32k>;
+ #clock-cells = <1>;
};
r_intc: interrupt-controller at 1f00c00 {
--
2.14.3
^ permalink raw reply related
* [PATCH v1 2/2] arm64: handle NOTIFY_SEI notification by the APEI driver
From: James Morse @ 2018-05-31 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531110115.uglmicy3nzwfoyx3@lakrids.cambridge.arm.com>
Hi Mark, Dongjiu Geng,
On 31/05/18 12:01, Mark Rutland wrote:
> In do_serror() we already handle nmi_{enter,exit}(), so there's no need
> for that here.
Even better: nmi_enter() has a BUG_ON(in_nmi()).
> TBH, I don't understand why do_sea() does that conditionally today.
> Unless there's some constraint I'm missing,
APEI uses a different fixmap entry and locks when in_nmi(). This was because we
may interrupt the irq-masked region in APEI that was using the regular memory.
(e.g. the 'polled' notification, or something backed by an interrupt.) But,
Borislav has spotted other things in here that are broken[0]. I'm working on
rolling all that into 'v5' of the in_nmi() rework stuff.
We currently get away with this on arm because 'SEA' is the only NMI-like thing,
and it occurs synchronously. The problem cases are all also cases where the
kernel text is corrupt, which we can't possibly hope to handle.
For NOTIFY_SDEI and NOTIFY_SEI this is the wrong pattern as these are
asynchronous. do_serror() has already done most of the work for NOTIFY_SEI, but
we need to use the estatus queue in APEI, which is currently x86 only.
> I think it would make more
> sense to do that regardless of whether the interrupted context had
> interrupts enabled. James -- does that make sense to you?
>
> If you update the prior patch with a stub for !CONFIG_ACPI_APEI_SEI, you
> can simplify all of the above additions down to:
>
> if (!ghes_notify_sei())
> return;
>
> ... which would look a lot nicer.
The code that calls ghes_notify_sei() may need calling by KVM too, but its
default action to an 'unclaimed' SError will be different.
Because of the race between memory_failure() and return-to-userspace, we may
need to kick the irq work queue (if we can), as we return from do_serror(). [1]
and [2] provide an example for NOTIFY_SEA. SDEI does this by returning to the
kernel through the IRQ handler, (which handles the KVM case too).
I think this series is unsafe until we can use the estatus queue in APEI. Its
also missing the handling for an SError interrupting a KVM guest.
Thanks,
James
[0] https://www.spinics.net/lists/arm-kernel/msg653332.html
[1] https://www.spinics.net/lists/arm-kernel/msg649237.html
[2] https://www.spinics.net/lists/arm-kernel/msg649239.html
^ permalink raw reply
* [PATCH v2 00/17] arm64 SSBD (aka Spectre-v4) mitigation
From: Marc Zyngier @ 2018-05-31 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531164133.6z6py7nl55ty473e@armageddon.cambridge.arm.com>
Hi Catalin,
On 31/05/18 17:41, Catalin Marinas wrote:
> On Tue, May 29, 2018 at 01:11:04PM +0100, Marc Zyngier wrote:
>> Marc Zyngier (17):
>> arm/arm64: smccc: Add SMCCC-specific return codes
>> arm64: Call ARCH_WORKAROUND_2 on transitions between EL0 and EL1
>> arm64: Add per-cpu infrastructure to call ARCH_WORKAROUND_2
>> arm64: Add ARCH_WORKAROUND_2 probing
>> arm64: Add 'ssbd' command-line option
>> arm64: ssbd: Add global mitigation state accessor
>> arm64: ssbd: Skip apply_ssbd if not using dynamic mitigation
>> arm64: ssbd: Restore mitigation status on CPU resume
>> arm64: ssbd: Introduce thread flag to control userspace mitigation
>> arm64: ssbd: Add prctl interface for per-thread mitigation
>> arm64: KVM: Add HYP per-cpu accessors
>> arm64: KVM: Add ARCH_WORKAROUND_2 support for guests
>> arm64: KVM: Handle guest's ARCH_WORKAROUND_2 requests
>> arm64: KVM: Add ARCH_WORKAROUND_2 discovery through
>> ARCH_FEATURES_FUNC_ID
>
> I queued the 14 patches above for 4.18.
I just realized that your for-next/core branch is based on
4.17-rc4, which means arch/arm64/kernel/ssbd.c won't compile
(it relies on some of the symbols introduced with the x86
stuff in 4.17-rc7.
You can work around it by adding the following hack:
>From 8a0dbe9fb468c03b3913d17af9dce7358f899ee3 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier@arm.com>
Date: Thu, 31 May 2018 17:54:11 +0100
Subject: [PATCH] fixup! arm64: ssbd: Add prctl interface for per-thread
mitigation
---
arch/arm64/kernel/ssbd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/kernel/ssbd.c b/arch/arm64/kernel/ssbd.c
index 07b12c034ec2..3432e5ef9f41 100644
--- a/arch/arm64/kernel/ssbd.c
+++ b/arch/arm64/kernel/ssbd.c
@@ -11,7 +11,9 @@
/*
* prctl interface for SSBD
+ * FIXME: Drop the below ifdefery once merged in 4.18.
*/
+#ifdef PR_SPEC_STORE_BYPASS
static int ssbd_prctl_set(struct task_struct *task, unsigned long ctrl)
{
int state = arm64_get_ssbd_state();
@@ -105,3 +107,4 @@ int arch_prctl_spec_ctrl_get(struct task_struct *task, unsigned long which)
return -ENODEV;
}
}
+#endif /* PR_SPEC_STORE_BYPASS */
--
2.17.1
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related
* [linux-sunxi] [PATCH v2] arm64: allwinner: a64-amarula-relic: Enable AP6330 WiFi support
From: Christopher Obbard @ 2018-05-31 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531165109.8476-1-jagan@amarulasolutions.com>
Hi Jagan,
I cannot find any information on this board online, so I am guessing
it has not been released yet and you are developing software support
now.
Do you have any datasheet/overview document of the board?
Rather than making a lot of noise on the various MLs, why not wait
until all hardware has a driver written for it & bugs have been been
smashed, then patch in one series?
Christopher Obbard
64 Studio Ltd.
On 31 May 2018 at 17:51, Jagan Teki <jagan@amarulasolutions.com> wrote:
> Enable AP6330 WiFi/BT combo chip on Amarula A64-Relic board:
> - WiFi SDIO interface is connected to MMC1
> - WiFi WL-PMU-EN pin connected to gpio PL2: attach to mmc-pwrseq
> - WiFi WL-WAKE-AP pin connected to gpio PL3
> - 32kHz external oscillator gate clock from RTC
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v2:
> - Move external rtc clock nodes into main rtc node definition
> of sun50i-a64.dtsi
>
> .../dts/allwinner/sun50i-a64-amarula-relic.dts | 31 ++++++++++++++++++++++
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 3 +++
> 2 files changed, 34 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> index ce4a256ff086..eac4793c8502 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> @@ -21,12 +21,43 @@
> chosen {
> stdout-path = "serial0:115200n8";
> };
> +
> + wifi_pwrseq: wifi-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + clocks = <&rtc 1>;
> + clock-names = "ext_clock";
> + reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* WL-PMU-EN: PL2 */
> + };
> };
>
> &ehci0 {
> status = "okay";
> };
>
> +&mmc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins>;
> + vmmc-supply = <®_dcdc1>;
> + /*
> + * Schematic shows both dldo4 and eldo1 connected for vcc-io-wifi, but
> + * dldo4 connection shows DNP(Do Not Populate) and eldo1 connected with
> + * 0Ohm register to vcc-io-wifi so eldo1 is used.
> + */
> + vqmmc-supply = <®_eldo1>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
> +
> + brcmf: wifi at 1 {
> + reg = <1>;
> + compatible = "brcm,bcm4329-fmac";
> + interrupt-parent = <&r_pio>;
> + interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* WL-WAKE-AP: PL3 */
> + interrupt-names = "host-wake";
> + };
> +};
> +
> &mmc2 {
> pinctrl-names = "default";
> pinctrl-0 = <&mmc2_pins>;
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 1b2ef28c42bd..82516aec4153 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -634,6 +634,9 @@
> reg = <0x01f00000 0x54>;
> interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
> + clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
> + clocks = <&osc32k>;
> + #clock-cells = <1>;
> };
>
> r_intc: interrupt-controller at 1f00c00 {
> --
> 2.14.3
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH v2 0/2] arm64: align KPTI interface with x86
From: Mark Langsdorf @ 2018-05-31 17:08 UTC (permalink / raw)
To: linux-arm-kernel
ARM64 supports KPTI, but support isn't documented and KPTI can be enabled
or disabled silently. Also, x86_64 supports the nopti kernel parameter,
but ARM64 doesn't.
Add the nopti argument, update the documentation so that ARM64 as well
as x86 supports nopti, add documentation for the existing kpti parameter,
and revise how kpti is logged.
--Mark Langsdorf
Changes from v1:
- Two patches dealing with debugfs dropped as x86 doesn't have this capability
- Documentation changed so that the existing kpti argument is documented,
instead of a pti argument similar to what x86 uses but arm64 does not.
- when logging kpti status, made it clear when status is set by default
^ permalink raw reply
* [PATCH v2 1/2] arm64: capabilities: add nopti command line argument
From: Mark Langsdorf @ 2018-05-31 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531170832.14263-1-mlangsdo@redhat.com>
The x86 kernel and the documentation use 'nopti' as the kernel command
line argument to disable kernel page table isolation, so add nopti to
the arm64 kernel for compatibility.
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
---
Documentation/admin-guide/kernel-parameters.txt | 19 +++++++++++++++----
arch/arm64/kernel/cpufeature.c | 11 ++++++++++-
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index f2040d4..cf0c728 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3342,8 +3342,8 @@
pt. [PARIDE]
See Documentation/blockdev/paride.txt.
- pti= [X86_64] Control Page Table Isolation of user and
- kernel address spaces. Disabling this feature
+ pti= [X86_64] Control Page Table Isolation of user
+ and kernel address spaces. Disabling this feature
removes hardening, but improves performance of
system calls and interrupts.
@@ -3354,8 +3354,19 @@
Not specifying this option is equivalent to pti=auto.
- nopti [X86_64]
- Equivalent to pti=off
+ kpti= [ARM64] Control Page Table Isolation of user
+ and kernel address spaces. Disabling this feature
+ removes hardening, but improves performance of
+ system calls and interrupts.
+
+ on - unconditionally enable
+ off - unconditionally disable
+
+ Not specifying this option will enable kpti on all
+ systems that support it.
+
+ nopti [X86_64, ARM64]
+ Equivalent to pti=off on X86_64 or kpti=off on ARM64
pty.legacy_count=
[KNL] Number of legacy pty's. Overwrites compiled-in
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9d1b06d..7c5d8712 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -934,10 +934,19 @@ static int __init parse_kpti(char *str)
if (ret)
return ret;
- __kpti_forced = enabled ? 1 : -1;
+ if (!__kpti_forced)
+ __kpti_forced = enabled ? 1 : -1;
return 0;
}
__setup("kpti=", parse_kpti);
+
+/* for compatibility with documentation and x86 nopti command line arg */
+static int __init force_nokpti(char *arg)
+{
+ __kpti_forced = -1;
+ return 0;
+}
+early_param("nopti", force_nokpti);
#endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
#ifdef CONFIG_ARM64_HW_AFDBM
--
2.9.5
^ 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