* [GIT PULL] Amlogic defconfig updates for v4.18
From: Olof Johansson @ 2018-05-25 11:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7h7eo4tumf.fsf@baylibre.com>
On Tue, May 15, 2018 at 03:35:36PM -0700, Kevin Hilman wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-defconfig
>
> for you to fetch changes up to 1e3e7a9f27dc73c50ad7b0f06e6e519bbaa3fee9:
>
> ARM: multi_v7_defconfig: enable the Meson PWM controller (2018-04-27 12:06:02 -0700)
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT updates for v4.18
From: Olof Johansson @ 2018-05-25 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hd0xwtuqq.fsf@baylibre.com>
On Tue, May 15, 2018 at 03:33:01PM -0700, Kevin Hilman wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] Amlogic 32-bit DT updates for v4.18
From: Olof Johansson @ 2018-05-25 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hh8n8tuw5.fsf@baylibre.com>
On Tue, May 15, 2018 at 03:29:46PM -0700, Kevin Hilman wrote:
> Hi Arnd, Olof,
>
> This is mostly DT, but contains also contains the mach-meson change to
> build the new DT, which might be more appropriate for the 'soc' branch,
> but I left it here because it's just about enabling the new DT. Let me
> know if you prefer it split out.
>
> Kevin
>
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt
>
> for you to fetch changes up to 35ee52bea66c74a7c33cebda8692d61b1ed7c6e9:
>
> ARM: dts: meson8m2: add support for the Tronsmart MXIII Plus (2018-05-10 17:03:28 -0700)
Merged, thanks!
-Olof
^ permalink raw reply
* [PATCH v2 1/8] driver core: make deferring probe after init optional
From: Robin Murphy @ 2018-05-25 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524181834.GF4828@sirena.org.uk>
On 24/05/18 19:18, Mark Brown wrote:
> On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote:
>
>> Subsystems or drivers may opt-in to this behavior by calling
>> driver_deferred_probe_check_init_done() instead of just returning
>> -EPROBE_DEFER. They may use additional information from DT or kernel's
>> config to decide whether to continue to defer probe or not.
>
> Should userspace have some involvement in this decision? It knows if
> it's got any intention of loading modules for example. Kernel config
> checks might be good enough, though it's going to be a pain to work out
> if the relevant driver is built as a module for example.
Arguably userspace has some control over that already, as in many cases
it can just unbind and reprobe the consumer driver after loading the
provider driver (in my silly IOMMU-drivers-as-modules PoC a while ago I
was delighted to find that it can really be that simple). It's a bit
harder when the device is the primary console or root filesystem, but I
think that's effectively just another variant of the "defer until a
module is loaded" chicken-and-egg problem.
Robin.
^ permalink raw reply
* [GIT PULL v2] arm64: dts: hisilicon dts updates for v4.18
From: Olof Johansson @ 2018-05-25 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5AFAF15A.20500@hisilicon.com>
On Tue, May 15, 2018 at 03:40:26PM +0100, Wei Xu wrote:
> Hi Olof, Hi Arnd,
>
> Please help to pull the following changes.
> Thanks!
>
> Best Regards,
> Wei
>
> ---
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://github.com/hisilicon/linux-hisi.git tags/hisi-arm64-dt-for-4.18v2
>
> for you to fetch changes up to bb61c53601b4af0f33f99ec0a8c9315246a0b6d4:
>
> arm64: dts: hi3798cv200: enable emmc support for poplar board (2018-05-15 14:54:03 +0100)
Merged, thanks.
-Olof
^ permalink raw reply
* [PATCH 15/15] arm: dts: imx: Add missing OPP properties for CPUs
From: Lucas Stach @ 2018-05-25 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <264124e14b966a1bbc07c364fbd89fc55aa765e6.1527244201.git.viresh.kumar@linaro.org>
Hi Viresh,
Am Freitag, den 25.05.2018, 16:02 +0530 schrieb Viresh Kumar:
> The OPP properties, like "operating-points", should either be present
> for all the CPUs of a cluster or none. If these are present only for a
> subset of CPUs of a cluster then things will start falling apart as soon
> as the CPUs are brought online in a different order. For example, this
> will happen because the operating system looks for such properties in
> the CPU node it is trying to bring up, so that it can create an OPP
> table.
>
> Add such missing properties.
>
> Fix other missing properties (like clocks, supply, clock latency) as
> well to make it all work.
This is a lot of duplicate information for what is effectively a shared
cluster wide thing. This does absolutely not _feel_ right.
What problem are you solving here? Why do we need all this duplicate
information? Why can't we fix it by falling back to looking at cpu0 if
needed?
Regards,
Lucas
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> ?arch/arm/boot/dts/imx6dl.dtsi??????| 23 ++++++++++
> ?arch/arm/boot/dts/imx6q-cm-fx6.dts | 66 +++++++++++++++++++++++++++++
> ?arch/arm/boot/dts/imx6q.dtsi???????| 87 ++++++++++++++++++++++++++++++++++++--
> ?arch/arm/boot/dts/imx7d.dtsi???????|??5 +++
> ?4 files changed, 178 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> index b384913c34dd..cc8ffc42d128 100644
> --- a/arch/arm/boot/dts/imx6dl.dtsi
> +++ b/arch/arm/boot/dts/imx6dl.dtsi
> @@ -50,6 +50,29 @@
> > ? device_type = "cpu";
> > ? reg = <1>;
> > ? next-level-cache = <&L2>;
> > + operating-points = <
> > + /* kHz????uV */
> > + 996000??1250000
> > + 792000??1175000
> > + 396000??1150000
> > + >;
> > + fsl,soc-operating-points = <
> > + /* ARM kHz??SOC-PU uV */
> > > + 996000 1175000
> > > + 792000 1175000
> > > + 396000 1175000
> > + >;
> > + clock-latency = <61036>; /* two CLK32 periods */
> > + clocks = <&clks IMX6QDL_CLK_ARM>,
> > + ?<&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
> > + ?<&clks IMX6QDL_CLK_STEP>,
> > + ?<&clks IMX6QDL_CLK_PLL1_SW>,
> > + ?<&clks IMX6QDL_CLK_PLL1_SYS>;
> > + clock-names = "arm", "pll2_pfd2_396m", "step",
> > + ??????"pll1_sw", "pll1_sys";
> > + arm-supply = <®_arm>;
> > + pu-supply = <®_pu>;
> > + soc-supply = <®_soc>;
> > ? };
> > ? };
> ?
> diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts
> index 65ef4cacbc71..18ae4f3be6e3 100644
> --- a/arch/arm/boot/dts/imx6q-cm-fx6.dts
> +++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts
> @@ -187,6 +187,72 @@
> > ? >;
> ?};
> ?
> +&cpu1 {
> > + /*
> > + ?* Although the imx6q fuse indicates that 1.2GHz operation is possible,
> > + ?* the module behaves unstable at this frequency. Hence, remove the
> > + ?* 1.2GHz operation point here.
> > + ?*/
> > + operating-points = <
> > > + /* kHz uV */
> > > + 996000 1250000
> > > + 852000 1250000
> > > + 792000 1175000
> > > + 396000 975000
> > + >;
> > + fsl,soc-operating-points = <
> > > + /* ARM kHz SOC-PU uV */
> > > + 996000 1250000
> > > + 852000 1250000
> > > + 792000 1175000
> > > + 396000 1175000
> > + >;
> +};
> +
> +&cpu2 {
> > + /*
> > + ?* Although the imx6q fuse indicates that 1.2GHz operation is possible,
> > + ?* the module behaves unstable at this frequency. Hence, remove the
> > + ?* 1.2GHz operation point here.
> > + ?*/
> > + operating-points = <
> > > + /* kHz uV */
> > > + 996000 1250000
> > > + 852000 1250000
> > > + 792000 1175000
> > > + 396000 975000
> > + >;
> > + fsl,soc-operating-points = <
> > > + /* ARM kHz SOC-PU uV */
> > > + 996000 1250000
> > > + 852000 1250000
> > > + 792000 1175000
> > > + 396000 1175000
> > + >;
> +};
> +
> +&cpu3 {
> > + /*
> > + ?* Although the imx6q fuse indicates that 1.2GHz operation is possible,
> > + ?* the module behaves unstable at this frequency. Hence, remove the
> > + ?* 1.2GHz operation point here.
> > + ?*/
> > + operating-points = <
> > > + /* kHz uV */
> > > + 996000 1250000
> > > + 852000 1250000
> > > + 792000 1175000
> > > + 396000 975000
> > + >;
> > + fsl,soc-operating-points = <
> > > + /* ARM kHz SOC-PU uV */
> > > + 996000 1250000
> > > + 852000 1250000
> > > + 792000 1175000
> > > + 396000 1175000
> > + >;
> +};
> +
> ?&ecspi1 {
> > ? cs-gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>, <&gpio3 19 GPIO_ACTIVE_HIGH>;
> > ? pinctrl-names = "default";
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index 70483ce72ba6..78b89bb1bfed 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -50,25 +50,106 @@
> > ? soc-supply = <®_soc>;
> > ? };
> ?
> > - cpu at 1 {
> > > + cpu1: cpu at 1 {
> > ? compatible = "arm,cortex-a9";
> > ? device_type = "cpu";
> > ? reg = <1>;
> > ? next-level-cache = <&L2>;
> > + operating-points = <
> > + /* kHz????uV */
> > + 1200000 1275000
> > + 996000??1250000
> > + 852000??1250000
> > + 792000??1175000
> > + 396000??975000
> > + >;
> > + fsl,soc-operating-points = <
> > + /* ARM kHz??SOC-PU uV */
> > + 1200000 1275000
> > > + 996000 1250000
> > > + 852000 1250000
> > > + 792000 1175000
> > > + 396000 1175000
> > + >;
> > + clock-latency = <61036>; /* two CLK32 periods */
> > + clocks = <&clks IMX6QDL_CLK_ARM>,
> > + ?<&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
> > + ?<&clks IMX6QDL_CLK_STEP>,
> > + ?<&clks IMX6QDL_CLK_PLL1_SW>,
> > + ?<&clks IMX6QDL_CLK_PLL1_SYS>;
> > + clock-names = "arm", "pll2_pfd2_396m", "step",
> > + ??????"pll1_sw", "pll1_sys";
> > + arm-supply = <®_arm>;
> > + pu-supply = <®_pu>;
> > + soc-supply = <®_soc>;
> > ? };
> ?
> > - cpu at 2 {
> > > + cpu2: cpu at 2 {
> > ? compatible = "arm,cortex-a9";
> > ? device_type = "cpu";
> > ? reg = <2>;
> > ? next-level-cache = <&L2>;
> > + operating-points = <
> > + /* kHz????uV */
> > + 1200000 1275000
> > + 996000??1250000
> > + 852000??1250000
> > + 792000??1175000
> > + 396000??975000
> > + >;
> > + fsl,soc-operating-points = <
> > + /* ARM kHz??SOC-PU uV */
> > + 1200000 1275000
> > > + 996000 1250000
> > > + 852000 1250000
> > > + 792000 1175000
> > > + 396000 1175000
> > + >;
> > + clock-latency = <61036>; /* two CLK32 periods */
> > + clocks = <&clks IMX6QDL_CLK_ARM>,
> > + ?<&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
> > + ?<&clks IMX6QDL_CLK_STEP>,
> > + ?<&clks IMX6QDL_CLK_PLL1_SW>,
> > + ?<&clks IMX6QDL_CLK_PLL1_SYS>;
> > + clock-names = "arm", "pll2_pfd2_396m", "step",
> > + ??????"pll1_sw", "pll1_sys";
> > + arm-supply = <®_arm>;
> > + pu-supply = <®_pu>;
> > + soc-supply = <®_soc>;
> > ? };
> ?
> > - cpu at 3 {
> > > + cpu3: cpu at 3 {
> > ? compatible = "arm,cortex-a9";
> > ? device_type = "cpu";
> > ? reg = <3>;
> > ? next-level-cache = <&L2>;
> > + operating-points = <
> > + /* kHz????uV */
> > + 1200000 1275000
> > + 996000??1250000
> > + 852000??1250000
> > + 792000??1175000
> > + 396000??975000
> > + >;
> > + fsl,soc-operating-points = <
> > + /* ARM kHz??SOC-PU uV */
> > + 1200000 1275000
> > > + 996000 1250000
> > > + 852000 1250000
> > > + 792000 1175000
> > > + 396000 1175000
> > + >;
> > + clock-latency = <61036>; /* two CLK32 periods */
> > + clocks = <&clks IMX6QDL_CLK_ARM>,
> > + ?<&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
> > + ?<&clks IMX6QDL_CLK_STEP>,
> > + ?<&clks IMX6QDL_CLK_PLL1_SW>,
> > + ?<&clks IMX6QDL_CLK_PLL1_SYS>;
> > + clock-names = "arm", "pll2_pfd2_396m", "step",
> > + ??????"pll1_sw", "pll1_sys";
> > + arm-supply = <®_arm>;
> > + pu-supply = <®_pu>;
> > + soc-supply = <®_soc>;
> > ? };
> > ? };
> ?
> diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
> index 4c9877ec29f2..5434a8aa5602 100644
> --- a/arch/arm/boot/dts/imx7d.dtsi
> +++ b/arch/arm/boot/dts/imx7d.dtsi
> @@ -21,6 +21,11 @@
> > ? compatible = "arm,cortex-a7";
> > ? device_type = "cpu";
> > ? reg = <1>;
> > + operating-points = <
> > > + /* KHz uV */
> > > + 996000 1075000
> > > + 792000 975000
> > + >;
> > ? clock-frequency = <996000000>;
> > ? };
> > ? };
^ permalink raw reply
* [PATCH dts/arm/aspeed-g5 v1] ARM: dts: aspeed-g5: Add IPMI KCS node
From: Wang, Haiyue @ 2018-05-25 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8Xdhmrwfj6tGZ_o_JeoxdOii_5OD5oz80FJFRasvGd1L9w@mail.gmail.com>
Hi Joel & Andrew
This patch is out of date. ;-)
New: https://patchwork.ozlabs.org/patch/893720/
On 2018-05-25 12:34, Joel Stanley wrote:
> Hello Andrew,
>
> On 16 March 2018 at 11:17, Wang, Haiyue <haiyue.wang@linux.intel.com> wrote:
>> Hi Joel and Andrew,
>>
>> Have time to review this patch ? Hope for your comments. :-)
>>
>> BR,
>> Haiyue
>>
>>
>> On 2018-03-07 13:04, Haiyue Wang wrote:
>>> The IPMI KCS device part of the LPC interface and is used for
>>> communication with the host processor.
>>>
>>> Signed-off-by: Haiyue Wang <haiyue.wang@linux.intel.com>
> Do you have time to take a look at these? The device tree doesn't make
> sense to me.
>
> Cheers,
>
> Joel
>
>>> ---
>>> arch/arm/boot/dts/aspeed-g5.dtsi | 43
>>> +++++++++++++++++++++++++++++++++++++++-
>>> 1 file changed, 42 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi
>>> b/arch/arm/boot/dts/aspeed-g5.dtsi
>>> index 8eac57c..f443169 100644
>>> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
>>> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
>>> @@ -267,8 +267,40 @@
>>> ranges = <0x0 0x1e789000 0x1000>;
>>> lpc_bmc: lpc-bmc at 0 {
>>> - compatible =
>>> "aspeed,ast2500-lpc-bmc";
>>> + compatible =
>>> "aspeed,ast2500-lpc-bmc", "simple-mfd", "syscon";
>>> reg = <0x0 0x80>;
>>> + reg-io-width = <4>;
>>> +
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + ranges = <0x0 0x0 0x80>;
>>> +
>>> + kcs1: kcs1 at 0 {
>>> + compatible =
>>> "aspeed,ast2500-kcs-bmc";
>>> + reg = <0x0 0x80>;
>>> + interrupts = <8>;
>>> + kcs_chan = <1>;
>>> + kcs_addr = <0x0>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + kcs2: kcs2 at 0 {
>>> + compatible =
>>> "aspeed,ast2500-kcs-bmc";
>>> + reg = <0x0 0x80>;
>>> + interrupts = <8>;
>>> + kcs_chan = <2>;
>>> + kcs_addr = <0x0>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + kcs3: kcs3 at 0 {
>>> + compatible =
>>> "aspeed,ast2500-kcs-bmc";
>>> + reg = <0x0 0x80>;
>>> + interrupts = <8>;
>>> + kcs_chan = <3>;
>>> + kcs_addr = <0x0>;
>>> + status = "disabled";
>>> + };
>>> };
>>> lpc_host: lpc-host at 80 {
>>> @@ -294,6 +326,15 @@
>>> status = "disabled";
>>> };
>>> + kcs4: kcs4 at 0 {
>>> + compatible =
>>> "aspeed,ast2500-kcs-bmc";
>>> + reg = <0x0 0xa0>;
>>> + interrupts = <8>;
>>> + kcs_chan = <4>;
>>> + kcs_addr = <0x0>;
>>> + status = "disabled";
>>> + };
>>> +
>>> lhc: lhc at 20 {
>>> compatible =
>>> "aspeed,ast2500-lhc";
>>> reg = <0x20 0x24 0x48
>>> 0x8>;
>>
^ permalink raw reply
* [PATCH v4 2/2] arm64: signal: Report signal frame size to userspace via auxv
From: Will Deacon @ 2018-05-25 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524170713.GY13470@e103592.cambridge.arm.com>
On Thu, May 24, 2018 at 06:07:13PM +0100, Dave Martin wrote:
> On Thu, May 24, 2018 at 05:50:48PM +0100, Will Deacon wrote:
> > On Thu, May 24, 2018 at 04:55:17PM +0100, Dave Martin wrote:
> > > On Thu, May 24, 2018 at 01:49:21PM +0100, Will Deacon wrote:
> > > > On Wed, May 23, 2018 at 06:46:56PM +0100, Dave Martin wrote:
> > > > > @@ -936,3 +949,28 @@ asmlinkage void do_notify_resume(struct pt_regs *regs,
> > > > > thread_flags = READ_ONCE(current_thread_info()->flags);
> > > > > } while (thread_flags & _TIF_WORK_MASK);
> > > > > }
> > > > > +
> > > > > +unsigned long __ro_after_init signal_minsigstksz;
> > > > > +
> > > > > +/*
> > > > > + * Determine the stack space required for guaranteed signal devliery.
> > > > > + * This function is used to populate AT_MINSIGSTKSZ at process startup.
> > > > > + * cpufeatures setup is assumed to be complete.
> > > > > + */
> > > > > +void __init minsigstksz_setup(void)
> > > > > +{
> > > > > + struct rt_sigframe_user_layout user;
> > > > > +
> > > > > + init_user_layout(&user);
> > > > > +
> > > > > + /*
> > > > > + * If this fails, SIGFRAME_MAXSZ needs to be enlarged. It won't
> > > > > + * be big enough, but it's our best guess:
> > > > > + */
> > > > > + if (WARN_ON(setup_sigframe_layout(&user, true)))
> > > > > + signal_minsigstksz = SIGFRAME_MAXSZ;
> > > >
> > > > Can we not leave signal_minsigstksz as zero in this case?
> > >
> > > I prefer to distinguish the "kernel went wrong" case (where we just omit
> > > AT_MINSIGSTKSZ for backwards compatibilty) from the "sigframe too
> > > large" case.
> >
> > Hmm, so I'm confused as to the distinction here. Wouldn't an allocation
> > failure in setup_sigframe_layout be indicative of "kernel went wrong"?
> >
> > To put it another way, if we could determine the maximum sigframe size
> > at build time, surely we'd fail the build if SIGFRAME_MAXSZ wasn't big
> > enough? In that case, detecting this at runtime is also pretty bad (hence
>
> Yup
Good, I was starting to worry I was missing something!
> > the WARN_ON) and I think we should drop the aux entry rather than provide
> > a value that is known to be incorrect.
>
> Telling userspace the signal frame size is not optional: by omitting
> AT_MINSIGSTKSZ we implicitly tell userspace than MINSIGSTKSZ
> is sufficient. But in this case we not only know that this is false, we
> know that SIGFRAME_MAXSZ is not sufficient either. But we also know
> that SIGFRAME_MAXSZ is a closer estimate to the true requirement, because
> it's the larger value.
>
> This falls under the heading of "being no more wrong than necessary".
I think I just prefer distinguishing between "AT_MINSIGSTKSZ isn't
present, I'll assume MINSIGSTKSZ is sufficient but it might not be" and
"AT_MINSIGSTKSZ is present, I know that it's sufficient".
> Either way, this is trying to paper over a kernel bug, by telling
> userspace something "sensible". This may not be a sensible course
> of action...
>
> So if you feel strongly I'm happy to not distinguish the two cases and
> just WARN() in minsigstksz_setup() as at present.
Yes, please.
Will
^ permalink raw reply
* [PATCH 03/14] ARM: bugs: hook processor bug checking into SMP and suspend paths
From: Russell King - ARM Linux @ 2018-05-25 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525100359.GC17671@n2100.armlinux.org.uk>
On Fri, May 25, 2018 at 11:03:59AM +0100, Russell King - ARM Linux wrote:
> On Thu, May 24, 2018 at 04:30:40PM -0700, Florian Fainelli wrote:
> > On 05/21/2018 04:44 AM, Russell King wrote:
> > > Check for CPU bugs when secondary processors are being brought online,
> > > and also when CPUs are resuming from a low power mode. This gives an
> > > opportunity to check that processor specific bug workarounds are
> > > correctly enabled for all paths that a CPU re-enters the kernel.
> > >
> > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> >
> > Something I missed, is that this correctly warns about e.g: missing the
> > IBE bit for secondary cores, but it seems to be missing it for the boot CPU:
>
> Are you sure that the boot CPU has the IBE bit clear?
Here's what I get on TI Keystone 2, which doesn't set the IBE bit for
any CPU:
CPU: Testing write buffer coherency: ok
CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
CPU0: Spectre v2: using ICIALLU workaround
/cpus/cpu at 0 missing clock-frequency property
/cpus/cpu at 1 missing clock-frequency property
/cpus/cpu at 2 missing clock-frequency property
/cpus/cpu at 3 missing clock-frequency property
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x80008300 - 0x80008438
Hierarchical SRCU implementation.
smp: Bringing up secondary CPUs ...
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
CPU1: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
CPU1: Spectre v2: using ICIALLU workaround
CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
CPU2: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
CPU2: Spectre v2: using ICIALLU workaround
CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
CPU3: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
CPU3: Spectre v2: using ICIALLU workaround
It should be noted that, if we implement a "bugs" bit exported to
userspace (as I think someone requested) that booting on a system
where only the boot CPU initially comes up (which has the IBE bit
set) and then bringing the secondary CPUs online after userspace
has started (where those CPUs don't have the IBE bit set) will
result in the system initially not being vulnerable, but then
becoming vulnerable when running on those other CPUs.
If the bugs bit had already been checked by userspace, then it would
think that there's no system level vulnerability. Userspace would
need to check the status each time a CPU comes online.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v2 7/8] iommu: Remove IOMMU_OF_DECLARE
From: Will Deacon @ 2018-05-25 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-8-robh@kernel.org>
On Thu, May 24, 2018 at 12:50:23PM -0500, Rob Herring wrote:
> Now that we use the driver core to stop deferred probe for missing
> drivers, IOMMU_OF_DECLARE can be removed.
>
> This is slightly less optimal than having a list of built-in drivers in
> that we'll now defer probe twice before giving up. This shouldn't have a
> significant impact on boot times as past discussions about deferred
> probe have given no evidence of deferred probe having a substantial
> impact.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Frank Rowand <frowand.list@gmail.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: iommu at lists.linux-foundation.org
> Cc: linux-samsung-soc at vger.kernel.org
> Cc: linux-arm-msm at vger.kernel.org
> Cc: linux-rockchip at lists.infradead.org
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> drivers/iommu/arm-smmu-v3.c | 2 --
> drivers/iommu/arm-smmu.c | 7 -------
> drivers/iommu/exynos-iommu.c | 2 --
> drivers/iommu/ipmmu-vmsa.c | 3 ---
> drivers/iommu/msm_iommu.c | 2 --
> drivers/iommu/of_iommu.c | 19 +------------------
> drivers/iommu/qcom_iommu.c | 2 --
> drivers/iommu/rockchip-iommu.c | 2 --
> include/linux/of_iommu.h | 4 ----
> 9 files changed, 1 insertion(+), 42 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 1d647104bccc..22bdabd3d8e0 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -2915,8 +2915,6 @@ static struct platform_driver arm_smmu_driver = {
> };
> module_platform_driver(arm_smmu_driver);
>
> -IOMMU_OF_DECLARE(arm_smmuv3, "arm,smmu-v3");
> -
> MODULE_DESCRIPTION("IOMMU API for ARM architected SMMUv3 implementations");
> MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 69e7c60792a8..9dd7cbaa3b0c 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -2211,13 +2211,6 @@ static struct platform_driver arm_smmu_driver = {
> };
> module_platform_driver(arm_smmu_driver);
>
> -IOMMU_OF_DECLARE(arm_smmuv1, "arm,smmu-v1");
> -IOMMU_OF_DECLARE(arm_smmuv2, "arm,smmu-v2");
> -IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400");
> -IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401");
> -IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500");
> -IOMMU_OF_DECLARE(cavium_smmuv2, "cavium,smmu-v2");
> -
> MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
> MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
> MODULE_LICENSE("GPL v2");
For the SMMU drivers:
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH v10 07/18] arm64: fpsimd: Eliminate task->mm checks
From: Christoffer Dall @ 2018-05-25 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525094515.GA13470@e103592.cambridge.arm.com>
On Fri, May 25, 2018 at 10:45:17AM +0100, Dave Martin wrote:
> On Fri, May 25, 2018 at 11:00:20AM +0200, Christoffer Dall wrote:
> > On Thu, May 24, 2018 at 03:37:15PM +0100, Dave Martin wrote:
> > > On Thu, May 24, 2018 at 12:06:59PM +0200, Christoffer Dall wrote:
> > > > On Thu, May 24, 2018 at 10:50:56AM +0100, Dave Martin wrote:
>
> [...]
>
> > > > I'm not sure what the reader is to make of that. Do you not mean the
> > > > TIF_FOREIGN_FPSTATE is always true for kernel threads?
> > >
> > > Again, this is probably a red herring. TIF_FOREIGN_FPSTATE is always
> > > true for kernel threads prior to the patch, except (randomly) for the
> > > init task.
> >
> > That was really what my initial question was about, and what I thought
> > the commit message should make abundantly clear, because that ties the
> > message together with the code.
> >
> > >
> > > This change is not really about TIF_FOREIGN_FPSTATE at all, rather
> > > that there is nothing to justify handling kernel threads differently,
> > > or even distinguishing kernel threads from user threads at all in this
> > > code.
> >
> > Understood.
>
> And my bad was that I hadn't gone to the effort of understanding my own
> argument -- I'd glad to be called out on that.
>
> > > Part of the confusion (and I had confused myself) comes from the fact
> > > that TIF_FOREIGN_FPSTATE is really a per-cpu property and doesn't make
> > > sense as a per-task property -- i.e., the flag is meaningless for
> > > scheduled-out tasks and we must explicitly "repair" it when scheduling
> > > a task in anyway. I think it's a thread flag primarily so that it's
> > > convenient to check alongside other thread flags in the ret_to_user
> > > work loop. This is somewhat less of a justification now that loop was
> > > ported to C.
> > >
> > > > >
> > > > > The context switch logic is already deliberately optimised to defer
> > > > > reloads of the regs until ret_to_user (or sigreturn as a special
> > > > > case), and save them only if they have been previously loaded.
> > >
> > > Does it help to insert the following here?
> > >
> > > "These paths are the only places where the wrong_task and wrong_cpu
> > > conditions can be made false, by calling fpsimd_bind_task_to_cpu()."
> > >
> >
> > yes it does.
> >
> > > > > Kernel threads by definition never reach these paths. As a result,
> > > >
> > > > I'm struggling with the "As a result," here. Is this because reloads of
> > > > regs in ret_to_user (or sigreturn) are the only places that can make
> > > > wrong_cpu or wrong_task be false?
> > >
> > > See the proposed clarification above. Is that sufficient?
> > >
> >
> > yes.
> >
> > > > (I'm actually wanting to understand this, not just bikeshedding the
> > > > commit message, as new corner cases keep coming up on this logic.)
> > >
> > > That's a good thing, and I would really like to explain it in a
> > > concise manner. See [*] below for the "concise" explanation -- it may
> > > demonstrate why I've been evasive...
> > >
> >
> > I don't think you've been evasive at all, I just think we reason about
> > this in slightly different ways, and I was trying to convince myself why
> > this change is safe and summarize that concisely. I think we've
> > accomplished both :)
>
> OK, good. I reposted speculatively on this basis :)
>
> The commit message is in better shape now, and I very much appreciate
> you kicking the tyres on my reasoning!
>
> [...]
>
> > > As an aside, the big wall of text before the definition of struct
> > > fpsimd_last_state_struct is looking out of date and could use an
> > > update to cover at least some of what is explained in [*] better.
> > >
> > > I'm currently considering that out of scope for this series, but I will
> > > keep it in mind to refresh it in the not too distant future.
> > >
> >
> > Fine with me.
>
> OK, good.
>
> [...]
>
> > > [*] The bigger picture:
> > >
> > > * Consider a relation (C,T) between cpus C and tasks T, such that
>
> [...]
>
> > > but by assuming that the code is already well-optimised, "unnecessary"
> > > save/restore work will not be added. If this were not the case, it
> > > could in any case be fixed independently.
> > >
> > > The observation of this _series_ is that we don't need to do very
> > > much in order to be able to generalise the logic to accept KVM vcpus
> > > in place of T.
> > >
> >
> > Thanks for the explanation.
> > -Christoffer
>
> Was this reasonably understandable? If so I could use it as a basis for
> improving the comment block in fpsimd.c, but I'd want to squash it down
> to the essentials. It's pretty verbose as it stands.
Yes, I think that's a resonable way forward. The thing that I hadn't
fully appreciated before is that you may have a valid relation (C,T)
which you wish to invalidate whilst T may not be running on C at that
particular time.
>
> (What I'd really like to do it take an axe to the logic so that we
> end up with something that doesn't require anything like this amount
> of explanation ... but that's more of an aspiration right now.)
>
I'll be happy to review a potentially simplified design, should you come
up with one at some point in the future.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCHv2] ARM64: KVM: use lm_alias() for kvm_ksym_ref()
From: Mark Rutland @ 2018-05-25 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1f54d71c-6ae1-732f-3ee0-99e38287a3b0@arm.com>
On Fri, May 25, 2018 at 12:08:28PM +0100, Marc Zyngier wrote:
> On 25/05/18 11:50, Mark Rutland wrote:
> > On Thu, May 10, 2018 at 12:13:47PM +0100, Mark Rutland wrote:
> >> For historical reasons, we open-code lm_alias() in kvm_ksym_ref().
> >>
> >> Let's use lm_alias() to avoid duplication and make things clearer.
> >>
> >> As we have to pull this from <linux/mm.h> (which is not safe for
> >> inclusion in assembly), we may as well move the kvm_ksym_ref()
> >> definition into the existing !__ASSEMBLY__ block.
> >>
> >> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> >> Cc: Christoffer Dall <christoffer.dall@arm.com>
> >> Cc: Marc Zyngier <marc.zyngier@arm.com>
> >> Cc: kvmarm at lists.cs.columbia.edu
> >> ---
> >> arch/arm64/include/asm/kvm_asm.h | 7 +++++--
> >> 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > Marc, Christoffer, are you happy to pick this up?
>
> I've queued it some time ago (see kvmarm/queue), but failed to mention
> it on the list...
Ah, cheers!
I'll drop this from my list of things to poke. :)
Thanks,
Mark.
^ permalink raw reply
* [PATCHv2] ARM64: KVM: use lm_alias() for kvm_ksym_ref()
From: Marc Zyngier @ 2018-05-25 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525105010.qswcppfkybznmzka@lakrids.cambridge.arm.com>
On 25/05/18 11:50, Mark Rutland wrote:
> On Thu, May 10, 2018 at 12:13:47PM +0100, Mark Rutland wrote:
>> For historical reasons, we open-code lm_alias() in kvm_ksym_ref().
>>
>> Let's use lm_alias() to avoid duplication and make things clearer.
>>
>> As we have to pull this from <linux/mm.h> (which is not safe for
>> inclusion in assembly), we may as well move the kvm_ksym_ref()
>> definition into the existing !__ASSEMBLY__ block.
>>
>> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
>> Cc: Christoffer Dall <christoffer.dall@arm.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: kvmarm at lists.cs.columbia.edu
>> ---
>> arch/arm64/include/asm/kvm_asm.h | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> Marc, Christoffer, are you happy to pick this up?
I've queued it some time ago (see kvmarm/queue), but failed to mention
it on the list...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 9/9] PM / Domains: Add dev_pm_domain_attach_by_id() to manage multi PM domains
From: Jon Hunter @ 2018-05-25 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFrTtvhxOhf9BPY1=cJ9VQyx9D=P3O0vCV+WXSVR82FozQ@mail.gmail.com>
On 25/05/18 11:45, Ulf Hansson wrote:
...
>> Right, but this case still seems like an error. My understanding is that
>> only drivers will use this API directly and it will not be used by the
>> device driver core (unlike dev_pm_domain_attach), so if anyone calls this
>> attempting to attach another PM domain when one is already attached, they
>> are doing something wrong.
>
> [...]
>
> You may be right!
>
> What I was thinking of is whether multiple PM domains may be optional
> in some cases, but instead a PM domain have already been attached by
> dev_pm_domain_attach(), prior the driver starts to probe.
>
> Then, assuming we return an error for this case, that means the caller
> then need to check the dev->pm_domain pointer, prior calling
> dev_pm_domain_attach_by_id(). Wouldn't it? Perhaps that is more clear
> though?
IMO the driver should know whether is needs multiple power-domains or
not and if it needs multiple then it should just call
dev_pm_domain_attach_by_id() N times without needing to checking
dev->pm_domain first. If it fails then either the PM domain core did
something wrong or power-domains are missing from DT, but either way
there is an error, so let it fail.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH] drm/rockchip: vop: fix irq disabled after vop driver probed
From: Marc Zyngier @ 2018-05-25 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <25470133.K8n9sLBzRS@diego>
[Thanks Robin for pointing me to that patch.]
Hi Heiko,
On 24/05/18 23:06, Heiko St?bner wrote:
> From: Sandy Huang <hjc@rock-chips.com>
>
> The vop irq is shared between vop and iommu and irq probing in the
> iommu driver moved to the probe function recently. This can in some
> cases lead to a stall if the irq is triggered while the vop driver
> still has it disabled.
>
> But there is no real need to disable the irq, as the vop can simply
> also track its enabled state and ignore irqs in that case.
>
> So remove the enable/disable handling and add appropriate condition
> to the irq handler.
>
> Signed-off-by: Sandy Huang <hjc@rock-chips.com>
> [added an actual commit message]
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> Hi Ezequiel,
>
> this patch came from a discussion I had with Rockchip people over the
> iommu changes and resulting issues back in april, but somehow was
> forgotten and not posted to the lists. Correcting that now.
>
> So removing the enable/disable voodoo on the shared interrupt is
> the preferred way.
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 ++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 510cdf0..61493d4 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -549,8 +549,6 @@ static int vop_enable(struct drm_crtc *crtc)
>
> spin_unlock(&vop->reg_lock);
>
> - enable_irq(vop->irq);
> -
> drm_crtc_vblank_on(crtc);
>
> return 0;
> @@ -596,8 +594,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
>
> vop_dsp_hold_valid_irq_disable(vop);
>
> - disable_irq(vop->irq);
> -
> vop->is_enabled = false;
>
> /*
> @@ -1168,6 +1164,13 @@ static irqreturn_t vop_isr(int irq, void *data)
> int ret = IRQ_NONE;
>
> /*
> + * since the irq is shared with iommu, iommu irq is enabled before vop
> + * enable, so before vop enable we do nothing.
> + */
> + if (!vop->is_enabled)
> + return IRQ_NONE;
> +
What guarantee do we have that the IOMMU will actually service that
interrupt? Can't we get into a situation where the interrupt gets
ignored by both drivers and subsequently disabled by the core irq code
as being spurious?
>From what I understood of the way things are plugged together on the
rockchip platforms, each individual VOP is behind a single IOMMU, hence
there there is hardly any point in handling IOMMU interrupts if the VOP
is off.
But I'm missing the actual reason behind this patch. Could you enlighten me?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* qcom: add firmware file for Venus on SDM845
From: Vikash Garodia @ 2018-05-25 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527246209-26685-1-git-send-email-vgarodia@codeaurora.org>
This pull request adds firmware files for Venus h/w codec found on the Qualcomm SDM845 chipset.
The following changes since commit 2a9b2cf50fb32e36e4fc1586c2f6f1421913b553:
Merge branch 'for-upstreaming-v1.7.2' of https://github.com/felix-cavium/linux-firmware (2018-05-18 08:35:22 -0400)
are available in the git repository at:
https://github.com/vgarodia/linux-firmware master
for you to fetch changes up to d6088b9c9d7f49d3c6c43681190889eca0abdcce:
qcom: add venus firmware files for v5.2 (2018-05-25 15:16:43 +0530)
----------------------------------------------------------------
Vikash Garodia (1):
qcom: add venus firmware files for v5.2
WHENCE | 9 +++++++++
qcom/venus-5.2/venus.b00 | Bin 0 -> 212 bytes
qcom/venus-5.2/venus.b01 | Bin 0 -> 6600 bytes
qcom/venus-5.2/venus.b02 | Bin 0 -> 819552 bytes
qcom/venus-5.2/venus.b03 | Bin 0 -> 33536 bytes
qcom/venus-5.2/venus.b04 | 1 +
qcom/venus-5.2/venus.mbn | Bin 0 -> 865408 bytes
qcom/venus-5.2/venus.mdt | Bin 0 -> 6812 bytes
8 files changed, 10 insertions(+)
create mode 100644 qcom/venus-5.2/venus.b00
create mode 100644 qcom/venus-5.2/venus.b01
create mode 100644 qcom/venus-5.2/venus.b02
create mode 100644 qcom/venus-5.2/venus.b03
create mode 100644 qcom/venus-5.2/venus.b04
create mode 100644 qcom/venus-5.2/venus.mbn
create mode 100644 qcom/venus-5.2/venus.mdt
^ permalink raw reply
* qcom: add firmware file for Venus on SDM845
From: Vikash Garodia @ 2018-05-25 11:03 UTC (permalink / raw)
To: linux-arm-kernel
hi,
This pull request adds firmware files for Venus h/w codec found on the Qualcomm SDM845 chipset.
The following changes since commit 2a9b2cf50fb32e36e4fc1586c2f6f1421913b553:
Merge branch 'for-upstreaming-v1.7.2' of https://github.com/felix-cavium/linux-firmware (2018-05-18 08:35:22 -0400)
are available in the git repository at:
https://github.com/vgarodia/linux-firmware master
for you to fetch changes up to d6088b9c9d7f49d3c6c43681190889eca0abdcce:
qcom: add venus firmware files for v5.2 (2018-05-25 15:16:43 +0530)
----------------------------------------------------------------
Vikash Garodia (1):
qcom: add venus firmware files for v5.2
WHENCE | 9 +++++++++
qcom/venus-5.2/venus.b00 | Bin 0 -> 212 bytes
qcom/venus-5.2/venus.b01 | Bin 0 -> 6600 bytes
qcom/venus-5.2/venus.b02 | Bin 0 -> 819552 bytes
qcom/venus-5.2/venus.b03 | Bin 0 -> 33536 bytes
qcom/venus-5.2/venus.b04 | 1 +
qcom/venus-5.2/venus.mbn | Bin 0 -> 865408 bytes
qcom/venus-5.2/venus.mdt | Bin 0 -> 6812 bytes
8 files changed, 10 insertions(+)
create mode 100644 qcom/venus-5.2/venus.b00
create mode 100644 qcom/venus-5.2/venus.b01
create mode 100644 qcom/venus-5.2/venus.b02
create mode 100644 qcom/venus-5.2/venus.b03
create mode 100644 qcom/venus-5.2/venus.b04
create mode 100644 qcom/venus-5.2/venus.mbn
create mode 100644 qcom/venus-5.2/venus.mdt
^ permalink raw reply
* [PATCH v2 11/13] dmaengine: pxa: make the filter function internal
From: Vinod @ 2018-05-25 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-12-robert.jarzmik@free.fr>
On 24-05-18, 09:07, Robert Jarzmik wrote:
> As the pxa architecture and all its related drivers do not rely anymore
> on the filter function, thanks to the slave map conversion, make
> pxad_filter_fn() static, and remove it from the global namespace.
Acked-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* [PATCH v2 10/13] dmaengine: pxa: document pxad_param
From: Vinod @ 2018-05-25 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-11-robert.jarzmik@free.fr>
On 24-05-18, 09:07, Robert Jarzmik wrote:
> Add some documentation for the pxad_param structure, and describe the
> contract behind the minimal required priority of a DMA channel.
Acked-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* REGRESSION: iommu fails to take address limit into account
From: Ard Biesheuvel @ 2018-05-25 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6d95cd70-70bd-9e63-c148-d535fbedb0d0@arm.com>
On 25 May 2018 at 12:49, Robin Murphy <robin.murphy@arm.com> wrote:
> On 25/05/18 11:35, Ard Biesheuvel wrote:
>>
>> On 25 May 2018 at 11:48, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>>
>>> Hello all,
>>>
>>> I am looking into an issue where a platform device is wired to a
>>> MMU-500, and for some reason (which is under investigation) the
>>> platform device can not drive all address bits. I can work around this
>>> by limiting the DMA mask to 40 bits in the driver. However, the IORT
>>> table allows me to set the address limit as well, and so I was
>>> expecting this to be taken into account by the SMMU driver.
>>>
>>> When the iort/iommu layer sets up the DMA operations,
>>> iommu_dma_init_domain() is entered with the expected values:
>>>
>>> base == 0
>>> size == 0x100_0000_0000
>>>
>>> However, the iommu layer ends up generating IOVA addresses that have
>>> bits [47:40] set (which is what the MMU-500 supports). Looking closer,
>>> this is not surprising, given that the end_pfn variable that is
>>> calculated in iommu_dma_init_domain() is no longer used after Zhen's
>>> patch aa3ac9469c185 ("iommu/iova: Make dma_32bit_pfn implicit") was
>>> applied.
>>>
>>> So effectively, this is a regression, and I would like your help
>>> figuring out how to go about fixing this.
>>>
>>
>> I have narrowed it down a bit further: even though the IOVA range
>> ignores the IORT address limit, the device's DMA mask is set
>> correctly. The only problem is that the driver (like all drivers
>> afaict) does not take into account the fact that its DMA mask has
>> already been set by the bus layer before its probe function is called.
>>
>> I could add something like this
>>
>> - if (dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)))
>> + if (dma_get_mask(&pdev->dev) == DMA_BIT_MASK(32) &&
>> + dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)))
>> dev_warn(&pdev->dev, "Failed to enable 64-bit DMA\n");
>>
>> to only override the mask if it is not at its default value, but it
>> feels like papering over the problem given that most drivers appear to
>> ignore the preset mask as well.
>
>
> Yup, that's the crux of it - if, say, the firmware describes an explicit
> restriction to 32 bits, then drivers have no way to tell the difference
> between that and the default mask initialised by the bus code (which they
> *should* be able to widen), and at the moment neither does arch code or
> anyone else (and the current interface between arch code and firmware code
> does not help matters).
>
OK, so I guess we need an additional bus limit field that is
initialized to ~0 and can only be narrowed, and take that into account
when dma_set_mask_and_coherent() is called. Not pretty, but at least
we won't have to fix all the drivers.
^ permalink raw reply
* [PATCHv2] ARM64: KVM: use lm_alias() for kvm_ksym_ref()
From: Mark Rutland @ 2018-05-25 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510111347.32253-1-mark.rutland@arm.com>
On Thu, May 10, 2018 at 12:13:47PM +0100, Mark Rutland wrote:
> For historical reasons, we open-code lm_alias() in kvm_ksym_ref().
>
> Let's use lm_alias() to avoid duplication and make things clearer.
>
> As we have to pull this from <linux/mm.h> (which is not safe for
> inclusion in assembly), we may as well move the kvm_ksym_ref()
> definition into the existing !__ASSEMBLY__ block.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Christoffer Dall <christoffer.dall@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: kvmarm at lists.cs.columbia.edu
> ---
> arch/arm64/include/asm/kvm_asm.h | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
Marc, Christoffer, are you happy to pick this up?
Mark.
> Since v1 [1]:
> * Rebase to v4.17-rc4
> * Fix typo in commit message
>
> Mark.
>
> [1] https://lkml.kernel.org/r/20180406151909.57197-1-mark.rutland at arm.com
>
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index f6648a3e4152..a9ceeec5a76f 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -33,16 +33,19 @@
> #define KVM_ARM64_DEBUG_DIRTY_SHIFT 0
> #define KVM_ARM64_DEBUG_DIRTY (1 << KVM_ARM64_DEBUG_DIRTY_SHIFT)
>
> +#ifndef __ASSEMBLY__
> +
> +#include <linux/mm.h>
> +
> /* Translate a kernel address of @sym into its equivalent linear mapping */
> #define kvm_ksym_ref(sym) \
> ({ \
> void *val = &sym; \
> if (!is_kernel_in_hyp_mode()) \
> - val = phys_to_virt((u64)&sym - kimage_voffset); \
> + val = lm_alias(&sym); \
> val; \
> })
>
> -#ifndef __ASSEMBLY__
> struct kvm;
> struct kvm_vcpu;
>
> --
> 2.11.0
>
^ permalink raw reply
* REGRESSION: iommu fails to take address limit into account
From: Robin Murphy @ 2018-05-25 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_0ECwLhoA2ywp3nntFX=RxfpM+MWFwTain1WN1sMrW9g@mail.gmail.com>
On 25/05/18 11:35, Ard Biesheuvel wrote:
> On 25 May 2018 at 11:48, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> Hello all,
>>
>> I am looking into an issue where a platform device is wired to a
>> MMU-500, and for some reason (which is under investigation) the
>> platform device can not drive all address bits. I can work around this
>> by limiting the DMA mask to 40 bits in the driver. However, the IORT
>> table allows me to set the address limit as well, and so I was
>> expecting this to be taken into account by the SMMU driver.
>>
>> When the iort/iommu layer sets up the DMA operations,
>> iommu_dma_init_domain() is entered with the expected values:
>>
>> base == 0
>> size == 0x100_0000_0000
>>
>> However, the iommu layer ends up generating IOVA addresses that have
>> bits [47:40] set (which is what the MMU-500 supports). Looking closer,
>> this is not surprising, given that the end_pfn variable that is
>> calculated in iommu_dma_init_domain() is no longer used after Zhen's
>> patch aa3ac9469c185 ("iommu/iova: Make dma_32bit_pfn implicit") was
>> applied.
>>
>> So effectively, this is a regression, and I would like your help
>> figuring out how to go about fixing this.
>>
>
> I have narrowed it down a bit further: even though the IOVA range
> ignores the IORT address limit, the device's DMA mask is set
> correctly. The only problem is that the driver (like all drivers
> afaict) does not take into account the fact that its DMA mask has
> already been set by the bus layer before its probe function is called.
>
> I could add something like this
>
> - if (dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)))
> + if (dma_get_mask(&pdev->dev) == DMA_BIT_MASK(32) &&
> + dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)))
> dev_warn(&pdev->dev, "Failed to enable 64-bit DMA\n");
>
> to only override the mask if it is not at its default value, but it
> feels like papering over the problem given that most drivers appear to
> ignore the preset mask as well.
Yup, that's the crux of it - if, say, the firmware describes an explicit
restriction to 32 bits, then drivers have no way to tell the difference
between that and the default mask initialised by the bus code (which
they *should* be able to widen), and at the moment neither does arch
code or anyone else (and the current interface between arch code and
firmware code does not help matters).
Robin.
^ permalink raw reply
* [PATCH v4 02/26] arm64: cpufeature: Add cpufeature for IRQ priority masking
From: Julien Thierry @ 2018-05-25 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3f0afa54-8e98-798e-68dc-bbbc74bd9e19@arm.com>
On 25/05/18 11:41, Suzuki K Poulose wrote:
> On 25/05/18 11:39, Julien Thierry wrote:
>>
>>
>> On 25/05/18 11:36, Suzuki K Poulose wrote:
>>> On 25/05/18 11:17, Julien Thierry wrote:
>>>>
>>>>
>>>> On 25/05/18 11:04, Suzuki K Poulose wrote:
>>>>> On 25/05/18 10:49, Julien Thierry wrote:
>>>>>> Add a cpufeature indicating whether a cpu supports masking interrupts
>>>>>> by priority.
>>>>>
>>>>> How is this different from the SYSREG_GIC_CPUIF cap ? Is it just
>>>>> the description ?
>>>>
>>>> More or less.
>>>>
>>>> It is just to have an easier condition in the rest of the series.
>>>> Basically the PRIO masking feature is enabled if we have a GICv3
>>>> CPUIF working *and* the option was selected at build time. Before
>>>> this meant that I was checking for the GIC_CPUIF cap inside #ifdefs
>>>> (and putting alternatives depending on that inside #ifdefs as well).
>>>>
>>>> Having this as a separate feature feels easier to manage in the
>>>> code. It also makes it clearer at boot time that the kernel will be
>>>> using irq priorities (although I admit it was not the initial
>>>> intention):
>>>>
>>>> [??? 0.000000] CPU features: detected: IRQ priority masking
>>>>
>>>>
>>>> But yes that new feature will be detected only if SYSREG_GIC_CPUIF
>>>> gets detected as well.
>>>
>>> Well, you could always wrap the check like :
>>>
>>> static inline bool system_has_irq_priority_masking(void)
>>> {
>>> ?????return (IS_ENABLED(CONFIG_YOUR_CONFIG) &&
>>> cpus_have_const_cap(HWCAP_SYSREG_GIC_CPUIF));
>>> }
>>>
>>> and use it everywhere.
>>>
>>
>> Yes, but I can't use that in the asm parts that use alternatives and
>> would need to surround them in #ifdef... :\
>
> I thought there is _ALTERNATIVE_CFG() to base the alternative depend on
> a CONFIG_xxx ?
> Doesn't that solve the problem ?
Right, I didn't see that one. It should work yes.
I'll try that when working on the next version.
Thanks,
--
Julien Thierry
^ permalink raw reply
* [PATCH v11 08/19] arm64: fpsimd: Eliminate task->mm checks
From: Dave Martin @ 2018-05-25 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r2m0rqzw.fsf@linaro.org>
On Fri, May 25, 2018 at 11:04:03AM +0100, Alex Benn?e wrote:
>
> Dave Martin <Dave.Martin@arm.com> writes:
>
> > Currently the FPSIMD handling code uses the condition task->mm ==
> > NULL as a hint that task has no FPSIMD register context.
> >
> > The ->mm check is only there to filter out tasks that cannot
> > possibly have FPSIMD context loaded, for optimisation purposes.
> > Also, TIF_FOREIGN_FPSTATE must always be checked anyway before
> > saving FPSIMD context back to memory. For these reasons, the ->mm
> > checks are not useful, providing that TIF_FOREIGN_FPSTATE is
> > maintained in a consistent way for all threads.
> >
> > The context switch logic is already deliberately optimised to defer
> > reloads of the regs until ret_to_user (or sigreturn as a special
> > case), and save them only if they have been previously loaded.
> > These paths are the only places where the wrong_task and wrong_cpu
> > conditions can be made false, by calling fpsimd_bind_task_to_cpu().
> > Kernel threads by definition never reach these paths. As a result,
> > the wrong_task and wrong_cpu tests in fpsimd_thread_switch() will
> > always yield true for kernel threads.
> >
> > This patch removes the redundant checks and special-case code, ensuring that TIF_FOREIGN_FPSTATE is set whenever a kernel thread is scheduled in, and ensures that this flag is set for the init
> > task. The fpsimd_flush_task_state() call already present in
> > copy_thread() ensures the same for any new task.
> >
> > With TIF_FOREIGN_FPSTATE always set for kernel threads, this patch
> > ensures that no extra context save work is added for kernel
> > threads, and eliminates the redundant context saving that may
> > currently occur for kernel threads that have acquired an mm via
> > use_mm().
> >
> > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> > Reviewed-by: Alex Benn?e <alex.bennee@linaro.org>
>
> Still good (although obviously without the ws damage in the commit).
Agreed -- I'll coordinate with Marc to make sure that gets fixed.
Thanks for the review.
[...]
Cheers
---Dave
^ permalink raw reply
* [PATCH 9/9] PM / Domains: Add dev_pm_domain_attach_by_id() to manage multi PM domains
From: Ulf Hansson @ 2018-05-25 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2c63af8c-4745-a751-8d3d-f7122e921e6f@nvidia.com>
On 25 May 2018 at 10:31, Jon Hunter <jonathanh@nvidia.com> wrote:
>
> On 24/05/18 22:11, Ulf Hansson wrote:
>>
>> On 24 May 2018 at 17:48, Jon Hunter <jonathanh@nvidia.com> wrote:
>>>
>>>
>>> On 18/05/18 11:31, Ulf Hansson wrote:
>>>>
>>>>
>>>> The existing dev_pm_domain_attach() function, allows a single PM domain
>>>> to
>>>> be attached per device. To be able to support devices that are
>>>> partitioned
>>>> across multiple PM domains, let's introduce a new interface,
>>>> dev_pm_domain_attach_by_id().
>>>>
>>>> The dev_pm_domain_attach_by_id() returns a new allocated struct device
>>>> with
>>>> the corresponding attached PM domain. This enables for example a driver
>>>> to
>>>> operate on the new device from a power management point of view. The
>>>> driver
>>>> may then also benefit from using the received device, to set up so
>>>> called
>>>> device-links towards its original device. Depending on the situation,
>>>> these
>>>> links may then be dynamically changed.
>>>>
>>>> The new interface is typically called by drivers during their probe
>>>> phase,
>>>> in case they manages devices which uses multiple PM domains. If that is
>>>> the
>>>> case, the driver also becomes responsible of managing the detaching of
>>>> the
>>>> PM domains, which typically should be done at the remove phase.
>>>> Detaching
>>>> is done by calling the existing dev_pm_domain_detach() function and for
>>>> each of the received devices from dev_pm_domain_attach_by_id().
>>>>
>>>> Note, currently its only genpd that supports multiple PM domains per
>>>> device, but dev_pm_domain_attach_by_id() can easily by extended to cover
>>>> other PM domain types, if/when needed.
>>>>
>>>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>>>> ---
>>>> drivers/base/power/common.c | 33 ++++++++++++++++++++++++++++++++-
>>>> include/linux/pm_domain.h | 7 +++++++
>>>> 2 files changed, 39 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/base/power/common.c b/drivers/base/power/common.c
>>>> index 7ae62b6..d3db974 100644
>>>> --- a/drivers/base/power/common.c
>>>> +++ b/drivers/base/power/common.c
>>>> @@ -117,13 +117,44 @@ int dev_pm_domain_attach(struct device *dev, bool
>>>> power_on)
>>>> EXPORT_SYMBOL_GPL(dev_pm_domain_attach);
>>>> /**
>>>> + * dev_pm_domain_attach_by_id - Attach a device to one of its PM
>>>> domains.
>>>
>>>
>>>
>>> Isn't this more of a 'get'?
>>
>>
>> I don't think so, at least according to the common understanding of
>> how we use get and put APIs.
>>
>> For example, clk_get() returns a cookie to a clk, which you then can
>> do a hole bunch of different clk specific operations on.
>>
>> This is different, there are no specific PM domain operations the
>> caller can or should do. Instead the idea is to keep drivers more or
>> less transparent, still using runtime PM as before. The only care the
>> caller need to take is to use device links, which BTW isn't a PM
>> domain specific thing.
>
>
> Yes, but a user can still call pm_runtime_get/put with the device returned
> if they wish to, right?
Correct.
[...]
>>>> + */
>>>> +struct device *dev_pm_domain_attach_by_id(struct device *dev,
>>>> + unsigned int index)
>>>> +{
>>>> + if (dev->pm_domain)
>>>
>>>
>>>
>>> I wonder if this is worthy of a ...
>>>
>>> if (WARN_ON(dev->pm_domain))
>>>
>>>> + return NULL;
>>>
>>>
>>>
>>> Don't we consider this an error case? I wonder why not return PTR_ERR
>>> here
>>> as well? This would be consistent with dev_pm_domain_attach().
>>
>>
>> Please see above comment.
>
>
> Right, but this case still seems like an error. My understanding is that
> only drivers will use this API directly and it will not be used by the
> device driver core (unlike dev_pm_domain_attach), so if anyone calls this
> attempting to attach another PM domain when one is already attached, they
> are doing something wrong.
[...]
You may be right!
What I was thinking of is whether multiple PM domains may be optional
in some cases, but instead a PM domain have already been attached by
dev_pm_domain_attach(), prior the driver starts to probe.
Then, assuming we return an error for this case, that means the caller
then need to check the dev->pm_domain pointer, prior calling
dev_pm_domain_attach_by_id(). Wouldn't it? Perhaps that is more clear
though?
Kind regards
Uffe
^ 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