* [PATCH 2/3] ARM: spectre-v1: add array_index_mask_nospec() implementation
From: Mark Rutland @ 2018-05-31 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1fONfh-00070F-Tw@rmk-PC.armlinux.org.uk>
On Thu, May 31, 2018 at 02:31:17PM +0100, Russell King wrote:
> Add an implementation of the array_index_mask_nospec() function for
> mitigating Spectre variant 1 throughout the kernel.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> arch/arm/include/asm/barrier.h | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
> index 3d9c1d4b7e75..a89adcf53b99 100644
> --- a/arch/arm/include/asm/barrier.h
> +++ b/arch/arm/include/asm/barrier.h
> @@ -76,6 +76,24 @@ extern void arm_heavy_mb(void);
> #define __smp_rmb() __smp_mb()
> #define __smp_wmb() dmb(ishst)
>
> +#ifdef CONFIG_CPU_SPECTRE
> +static inline unsigned long array_index_mask_nospec(unsigned long idx,
> + unsigned long sz)
> +{
> + unsigned long mask;
> +
> + asm( "cmp %1, %2\n"
> + " sbc %0, %1, %1\n"
> + CSDB
> + : "=r" (mask)
> + : "r" (idx), "Ir" (sz)
> + : "cc");
> +
> + return mask;
> +}
> +#define array_index_mask_nospec array_index_mask_nospec
> +#endif
I believe that the asm should be volatile, otherwise there are cases
where the compiler could remove an invocation that's redundant under
architectural execution, but required under speculation [1].
With that made volatile:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
[1] https://lkml.kernel.org/r/20180530060546.jnjoltsturoduohh at salmiak
^ permalink raw reply
* [PATCH 0/7] add non-strict mode support for arm-smmu-v3
From: Robin Murphy @ 2018-05-31 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <96cc25b9-b21f-6067-384d-f52e6b8b25e7@huawei.com>
On 31/05/18 14:49, Hanjun Guo wrote:
> Hi Robin,
>
> On 2018/5/31 19:24, Robin Murphy wrote:
>> On 31/05/18 08:42, Zhen Lei wrote:
>>> In common, a IOMMU unmap operation follow the below steps:
>>> 1. remove the mapping in page table of the specified iova range
>>> 2. execute tlbi command to invalid the mapping which is cached in TLB
>>> 3. wait for the above tlbi operation to be finished
>>> 4. free the IOVA resource
>>> 5. free the physical memory resource
>>>
>>> This maybe a problem when unmap is very frequently, the combination of tlbi
>>> and wait operation will consume a lot of time. A feasible method is put off
>>> tlbi and iova-free operation, when accumulating to a certain number or
>>> reaching a specified time, execute only one tlbi_all command to clean up
>>> TLB, then free the backup IOVAs. Mark as non-strict mode.
>>>
>>> But it must be noted that, although the mapping has already been removed in
>>> the page table, it maybe still exist in TLB. And the freed physical memory
>>> may also be reused for others. So a attacker can persistent access to memory
>>> based on the just freed IOVA, to obtain sensible data or corrupt memory. So
>>> the VFIO should always choose the strict mode.
>>>
>>> Some may consider put off physical memory free also, that will still follow
>>> strict mode. But for the map_sg cases, the memory allocation is not controlled
>>> by IOMMU APIs, so it is not enforceable.
>>>
>>> Fortunately, Intel and AMD have already applied the non-strict mode, and put
>>> queue_iova() operation into the common file dma-iommu.c., and my work is based
>>> on it. The difference is that arm-smmu-v3 driver will call IOMMU common APIs to
>>> unmap, but Intel and AMD IOMMU drivers are not.
>>>
>>> Below is the performance data of strict vs non-strict for NVMe device:
>>> Randomly Read? IOPS: 146K(strict) vs 573K(non-strict)
>>> Randomly Write IOPS: 143K(strict) vs 513K(non-strict)
>>
>> What hardware is this on? If it's SMMUv3 without MSIs (e.g. D05), then you'll still be using the rubbish globally-blocking sync implementation. If that is the case, I'd be very interested to see how much there is to gain from just improving that - I've had a patch kicking around for a while[1] (also on a rebased branch at [2]), but don't have the means for serious performance testing.
>
> The hardware is the new D06 which the SMMU with MSIs,
Cool! Now that profiling is fairly useful since we got rid of most of
the locks, are you able to get an idea of how the overhead in the normal
case is distributed between arm_smmu_cmdq_insert_cmd() and
__arm_smmu_sync_poll_msi()? We're always trying to improve our
understanding of where command-queue-related overheads turn out to be in
practice, and there's still potentially room to do nicer things than
TLBI_NH_ALL ;)
Robin.
> it's not D05 :)
>
> Thanks
> Hanjun
>
^ permalink raw reply
* [PATCH 0/3] ARM: shmobile: apmu: Cleanups after legacy SMP fallback removal
From: Simon Horman @ 2018-05-31 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527693328-10559-1-git-send-email-geert+renesas@glider.be>
On Wed, May 30, 2018 at 05:15:25PM +0200, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> Now the legacy SMP fallbacks for R-Car H2 and M2-W have been removed, a
> few more code cleanups can be applied.
>
> The third patch is a bit larger than I had hoped, due to the need to
> reshuffle a few functions in the absence of forward declarations.
>
> Tested on Lager (R-Car H2) and Koelsch (R-Car M2-W).
>
> Thanks!
>
> Geert Uytterhoeven (3):
> ARM: shmobile: apmu: Move cpu_leave_lowpower() to SUSPEND section
> ARM: shmobile: apmu: Remove obsolete shmobile_smp_apmu_prepare_cpus()
> ARM: shmobile: apmu: Remove platsmp-apmu.h
This looks fine but I will wait to see if there are other reviews before
applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH v3 2/5] gpio: syscon: rockchip: add GPIO_MUTE support for rk3328
From: Rob Herring @ 2018-05-31 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527737273-8387-3-git-send-email-djw@t-chip.com.cn>
On Wed, May 30, 2018 at 10:27 PM, <djw@t-chip.com.cn> wrote:
> From: Levin Du <djw@t-chip.com.cn>
>
> In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec
> mute control, can also be used for general purpose. It is manipulated by
> the GRF_SOC_CON10 register.
>
> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>
> ---
>
> Changes in v3:
> - Change from general gpio-syscon to specific rk3328-gpio-mute
>
> Changes in v2:
> - Rename gpio_syscon10 to gpio_mute in doc
>
> Changes in v1:
> - Refactured for general gpio-syscon usage for Rockchip SoCs.
> - Add doc rockchip,gpio-syscon.txt
>
> .../bindings/gpio/rockchip,rk3328-gpio-mute.txt | 28 +++++++++++++++++++
> drivers/gpio/gpio-syscon.c | 31 ++++++++++++++++++++++
> 2 files changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
> new file mode 100644
> index 0000000..10bc632
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
> @@ -0,0 +1,28 @@
> +Rockchip RK3328 GPIO controller dedicated for the GPIO_MUTE pin.
> +
> +In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec mute
> +control, can also be used for general purpose. It is manipulated by the
> +GRF_SOC_CON10 register.
> +
> +Required properties:
> +- compatible: Should contain "rockchip,rk3328-gpio-mute".
> +- gpio-controller: Marks the device node as a gpio controller.
> +- #gpio-cells: Should be 2. The first cell is the pin number and
> + the second cell is used to specify the gpio polarity:
> + 0 = Active high,
> + 1 = Active low.
> +
> +Example:
> +
> + grf: syscon at ff100000 {
> + compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
> +
> + gpio_mute: gpio-mute {
Node names should be generic:
gpio {
This also means you can't add another GPIO node in the future and
you'll have to live with "rockchip,rk3328-gpio-mute" covering more
than 1 GPIO if you do need to add more GPIOs.
> + compatible = "rockchip,rk3328-gpio-mute";
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> + };
> +
> +Note: The gpio_mute node should be declared as the child of the GRF (General
> +Register File) node. The GPIO_MUTE pin is referred to as <&gpio_mute 0>.
This is wrong because you should have 2 cells. The phandle doesn't
count as a cell.
Rob
^ permalink raw reply
* [PATCH] MAINTAINERS: Add Actions Semi S900 clk entries
From: Manivannan Sadhasivam @ 2018-05-31 15:23 UTC (permalink / raw)
To: linux-arm-kernel
Add S900 clk entries under ARCH_ACTIONS
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 48bfffe..964cd28 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1143,12 +1143,14 @@ N: owl
F: arch/arm/mach-actions/
F: arch/arm/boot/dts/owl-*
F: arch/arm64/boot/dts/actions/
+F: drivers/clk/actions/
F: drivers/clocksource/owl-*
F: drivers/pinctrl/actions/*
F: drivers/soc/actions/
F: include/dt-bindings/power/owl-*
F: include/linux/soc/actions/
F: Documentation/devicetree/bindings/arm/actions.txt
+F: Documentation/devicetree/bindings/clock/actions,s900-cmu.txt
F: Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt
F: Documentation/devicetree/bindings/power/actions,owl-sps.txt
F: Documentation/devicetree/bindings/timer/actions,owl-timer.txt
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/6] ARM: dra762: hwmod: Add MCAN support
From: Tony Lindgren @ 2018-05-31 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <98c989ca-0694-5150-f74b-35f3e4bf20c0@ti.com>
* 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.
Regards,
Tony
^ permalink raw reply
* [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
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