* [PATCH] ARM: mcpm, perf/arm-cci: export mcpm_is_available
From: Russell King - ARM Linux @ 2018-05-29 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529153013.GH17159@arm.com>
On Tue, May 29, 2018 at 04:30:14PM +0100, Will Deacon wrote:
> Hi Arnd, Russell, [+Nico and Robin]
>
> On Mon, May 28, 2018 at 05:44:36PM +0200, Arnd Bergmann wrote:
> > Now that the ARM CCI PMU driver can be built as a loadable module,
> > we get a link failure when MCPM is enabled:
> >
> > ERROR: "mcpm_is_available" [drivers/perf/arm-cci.ko] undefined!
> >
> > The simplest fix is to export that helper function.
> >
> > Fixes: 8b0c93c20ef7 ("perf/arm-cci: Allow building as a module")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > The patch that caused this is currently part of the arm-perf/for-next/perf
> > branch, it would be good to have the fix there as well.
> > ---
> > arch/arm/common/mcpm_entry.c | 2 ++
> > 1 file changed, 2 insertions(+)
>
> I'm happy to take this via the arm perf tree if others are ok with that.
> Alternatively, I can revert the offending commit if there are objections
> to exporting the symbol.
>
> Russell: do you any preference?
As it claims to fix 8b0c93c20ef7, which I don't have, I can't take this
patch. Do we know which tree has this?
--
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] drivers/bus: arm-cci: fix build warnings
From: Robin Murphy @ 2018-05-29 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528154228.2403116-1-arnd@arndb.de>
On 28/05/18 16:41, Arnd Bergmann wrote:
> When the arm-cci driver is enabled, but both CONFIG_ARM_CCI5xx_PMU and
> CONFIG_ARM_CCI400_PMU are not, we get a warning about how parts of
> the driver are never used:
>
> drivers/perf/arm-cci.c:1454:29: error: 'cci_pmu_models' defined but not used [-Werror=unused-variable]
> drivers/perf/arm-cci.c:693:16: error: 'cci_pmu_event_show' defined but not used [-Werror=unused-function]
> drivers/perf/arm-cci.c:685:16: error: 'cci_pmu_format_show' defined but not used [-Werror=unused-function]
>
> Marking all three functions as __maybe_unused avoids the warnings in
> randconfig builds. I'm doing this lacking any ideas for a better fix.
Yeah, it's a bit of a silly configuration to allow building a driver
supporting no PMU types, but I couldn't find a way to enforce "at least
one sub-option enabled" logic without introducing mutually-exclusive
dependencies which kbuild thinks are recursive.
An alternative would be to remove the CCI400/CCI5x0 configurability
altogether - I've not not looked in detail at how much difference that
actually makes.
Otherwise, as an immediate quick-fix:
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Thanks,
Robin.
> Fixes: 3de6be7a3dd8 ("drivers/bus: Split Arm CCI driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/perf/arm-cci.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/perf/arm-cci.c b/drivers/perf/arm-cci.c
> index e6fadc8e1178..0d09d8e669cd 100644
> --- a/drivers/perf/arm-cci.c
> +++ b/drivers/perf/arm-cci.c
> @@ -120,9 +120,9 @@ enum cci_models {
>
> static void pmu_write_counters(struct cci_pmu *cci_pmu,
> unsigned long *mask);
> -static ssize_t cci_pmu_format_show(struct device *dev,
> +static ssize_t __maybe_unused cci_pmu_format_show(struct device *dev,
> struct device_attribute *attr, char *buf);
> -static ssize_t cci_pmu_event_show(struct device *dev,
> +static ssize_t __maybe_unused cci_pmu_event_show(struct device *dev,
> struct device_attribute *attr, char *buf);
>
> #define CCI_EXT_ATTR_ENTRY(_name, _func, _config) \
> @@ -1451,7 +1451,7 @@ static int cci_pmu_offline_cpu(unsigned int cpu)
> return 0;
> }
>
> -static struct cci_pmu_model cci_pmu_models[] = {
> +static __maybe_unused struct cci_pmu_model cci_pmu_models[] = {
> #ifdef CONFIG_ARM_CCI400_PMU
> [CCI400_R0] = {
> .name = "CCI_400",
>
^ permalink raw reply
* [PATCH] ARM: mcpm, perf/arm-cci: export mcpm_is_available
From: Will Deacon @ 2018-05-29 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529153324.GL17671@n2100.armlinux.org.uk>
Hi Russell,
On Tue, May 29, 2018 at 04:33:24PM +0100, Russell King - ARM Linux wrote:
> On Tue, May 29, 2018 at 04:30:14PM +0100, Will Deacon wrote:
> > Hi Arnd, Russell, [+Nico and Robin]
> >
> > On Mon, May 28, 2018 at 05:44:36PM +0200, Arnd Bergmann wrote:
> > > Now that the ARM CCI PMU driver can be built as a loadable module,
> > > we get a link failure when MCPM is enabled:
> > >
> > > ERROR: "mcpm_is_available" [drivers/perf/arm-cci.ko] undefined!
> > >
> > > The simplest fix is to export that helper function.
> > >
> > > Fixes: 8b0c93c20ef7 ("perf/arm-cci: Allow building as a module")
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > The patch that caused this is currently part of the arm-perf/for-next/perf
> > > branch, it would be good to have the fix there as well.
> > > ---
> > > arch/arm/common/mcpm_entry.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> >
> > I'm happy to take this via the arm perf tree if others are ok with that.
> > Alternatively, I can revert the offending commit if there are objections
> > to exporting the symbol.
> >
> > Russell: do you any preference?
>
> As it claims to fix 8b0c93c20ef7, which I don't have, I can't take this
> patch. Do we know which tree has this?
Yes, sorry, it's in my for-next/perf branch:
https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=for-next/perf&id=8b0c93c20ef78f15d8b760964ff79bda7f68c610
which is now in -next.
I'm happy to take the mcpm patch on top with your ack, but if you have
conflicting changes (or would prefer not to export the symbol to modules)
then I can just revert the patch in my tree for now.
Will
^ permalink raw reply
* [PATCH] ARM: dts: berlin: switch to earlycon
From: Thomas Hebb @ 2018-05-29 15:41 UTC (permalink / raw)
To: linux-arm-kernel
The Synopsys DesignWare 8250 UART in Berlin SoCs is now supported by
8250_early, so we can use earlycon for early console output instead
of earlyprintk, which requires an SoC-specific kernel.
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
---
arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts | 2 +-
arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 2 +-
arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts b/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
index 1c475796d17f..f98798bb684f 100644
--- a/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
+++ b/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
@@ -45,7 +45,7 @@
compatible = "sony,nsz-gs7", "marvell,berlin2", "marvell,berlin";
chosen {
- bootargs = "earlyprintk";
+ bootargs = "earlycon";
stdout-path = "serial0:115200n8";
};
diff --git a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
index ca24def0ce13..20f31cdeaf38 100644
--- a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
+++ b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
@@ -46,7 +46,7 @@
compatible = "google,chromecast", "marvell,berlin2cd", "marvell,berlin";
chosen {
- bootargs = "earlyprintk";
+ bootargs = "earlycon";
stdout-path = "serial0:115200n8";
};
diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
index 57aa5f8a7c77..9834e84a0797 100644
--- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
+++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
@@ -49,7 +49,7 @@
};
chosen {
- bootargs = "earlyprintk";
+ bootargs = "earlycon";
stdout-path = "serial0:115200n8";
};
--
2.17.0
^ permalink raw reply related
* [PATCH] drivers/bus: arm-cci: fix build warnings
From: Will Deacon @ 2018-05-29 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0db1b8cd-b695-6cbf-9b27-f632b76bad11@arm.com>
On Tue, May 29, 2018 at 04:34:01PM +0100, Robin Murphy wrote:
> On 28/05/18 16:41, Arnd Bergmann wrote:
> >When the arm-cci driver is enabled, but both CONFIG_ARM_CCI5xx_PMU and
> >CONFIG_ARM_CCI400_PMU are not, we get a warning about how parts of
> >the driver are never used:
> >
> >drivers/perf/arm-cci.c:1454:29: error: 'cci_pmu_models' defined but not used [-Werror=unused-variable]
> >drivers/perf/arm-cci.c:693:16: error: 'cci_pmu_event_show' defined but not used [-Werror=unused-function]
> >drivers/perf/arm-cci.c:685:16: error: 'cci_pmu_format_show' defined but not used [-Werror=unused-function]
> >
> >Marking all three functions as __maybe_unused avoids the warnings in
> >randconfig builds. I'm doing this lacking any ideas for a better fix.
>
> Yeah, it's a bit of a silly configuration to allow building a driver
> supporting no PMU types, but I couldn't find a way to enforce "at least one
> sub-option enabled" logic without introducing mutually-exclusive
> dependencies which kbuild thinks are recursive.
>
> An alternative would be to remove the CCI400/CCI5x0 configurability
> altogether - I've not not looked in detail at how much difference that
> actually makes.
>
> Otherwise, as an immediate quick-fix:
>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
I'll pick this one up into the arm perf tree.
Will
^ permalink raw reply
* [PATCH] ARM: mcpm, perf/arm-cci: export mcpm_is_available
From: Russell King - ARM Linux @ 2018-05-29 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529154120.GI17159@arm.com>
On Tue, May 29, 2018 at 04:41:20PM +0100, Will Deacon wrote:
> Hi Russell,
>
> On Tue, May 29, 2018 at 04:33:24PM +0100, Russell King - ARM Linux wrote:
> > On Tue, May 29, 2018 at 04:30:14PM +0100, Will Deacon wrote:
> > > Hi Arnd, Russell, [+Nico and Robin]
> > >
> > > On Mon, May 28, 2018 at 05:44:36PM +0200, Arnd Bergmann wrote:
> > > > Now that the ARM CCI PMU driver can be built as a loadable module,
> > > > we get a link failure when MCPM is enabled:
> > > >
> > > > ERROR: "mcpm_is_available" [drivers/perf/arm-cci.ko] undefined!
> > > >
> > > > The simplest fix is to export that helper function.
> > > >
> > > > Fixes: 8b0c93c20ef7 ("perf/arm-cci: Allow building as a module")
> > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > > ---
> > > > The patch that caused this is currently part of the arm-perf/for-next/perf
> > > > branch, it would be good to have the fix there as well.
> > > > ---
> > > > arch/arm/common/mcpm_entry.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > >
> > > I'm happy to take this via the arm perf tree if others are ok with that.
> > > Alternatively, I can revert the offending commit if there are objections
> > > to exporting the symbol.
> > >
> > > Russell: do you any preference?
> >
> > As it claims to fix 8b0c93c20ef7, which I don't have, I can't take this
> > patch. Do we know which tree has this?
>
> Yes, sorry, it's in my for-next/perf branch:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=for-next/perf&id=8b0c93c20ef78f15d8b760964ff79bda7f68c610
>
> which is now in -next.
>
> I'm happy to take the mcpm patch on top with your ack, but if you have
> conflicting changes (or would prefer not to export the symbol to modules)
> then I can just revert the patch in my tree for now.
I have no changes to that file, so:
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Thanks.
--
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 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
From: Will Deacon @ 2018-05-29 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529133615.26889-1-nixiaoming@huawei.com>
On Tue, May 29, 2018 at 09:36:15PM +0800, nixiaoming wrote:
> mark_rodata_ro is only called by the function mark_readonly when
> CONFIG_STRICT_KERNEL_RWX=y,
> if CONFIG_STRICT_KERNEL_RWX is not set
> a compile warning may be triggered: unused function
How are you achieving this configuration? In our Kconfig we select this
unconditionally.
Will
^ permalink raw reply
* [PATCH 2/2] arm64: dts: renesas: condor: add I2C0 support
From: Sergei Shtylyov @ 2018-05-29 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529131012.ohyqwmiaxiiw6noi@verge.net.au>
Hello!
On 05/29/2018 04:10 PM, Simon Horman wrote:
>> Define the Condor board dependent part of the I2C0 device node.
>>
>> The I2C0 bus is populated by 2 ON Semiconductor PCA9654 I/O expanders
>> and Analog Devices ADV7511W HDMI transmitter (but we're only describing
>> the former chips now).
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>> arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 27 ++++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>>
>> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
>> ===================================================================
>> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
>> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
>> @@ -80,6 +80,28 @@
>> clock-frequency = <32768>;
>> };
>>
>> +&i2c0 {
>> + pinctrl-0 = <&i2c0_pins>;
>> + pinctrl-names = "default";
>> +
>> + status = "okay";
>> + clock-frequency = <400000>;
>> +
>> + io_expander0: gpio at 20 {
>
> Hi Sergei,
>
> I'm a little confused about where 0x20 and 0x21 are derived from.
> Could you explain a little?
r-carv3h_system_evaluation_board_rev020.pdf, pp. 16-17, lower left corners.
The schematics gives the 8-bit read/write addresses but we use uniform 7-bit
I2C address in DTs.
>> + compatible = "onnn,pca9654";
>> + reg = <0x20>;
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>> +
>> + io_expander1: gpio at 21 {
>> + compatible = "onnn,pca9654";
>> + reg = <0x21>;
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>> +};
>> +
>> &mmc0 {
>> pinctrl-0 = <&mmc_pins>;
>> pinctrl-1 = <&mmc_pins_uhs>;
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Boris Brezillon @ 2018-05-29 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1affd186-7f78-8bb0-050e-da82143c2982@microchip.com>
On Tue, 29 May 2018 18:21:40 +0300
Eugen Hristev <eugen.hristev@microchip.com> wrote:
> On 29.05.2018 18:15, Boris Brezillon wrote:
> > On Tue, 29 May 2018 18:01:40 +0300
> > Eugen Hristev <eugen.hristev@microchip.com> wrote:
> >
> >> [...]
> >>
> >>
> >>>
> >>> I think you're missing something here. We use the DMA engine in memcpy
> >>> mode (SRAM -> DRAM), not in device mode (dev -> DRAM or DRAM -> dev).
> >>> So there's no dmas prop defined in the DT and there should not be.
> >>>
> >>> Regards,
> >>>
> >>> Boris
> >>>
> >>
> >> Ok, so the memcpy SRAM <-> DRAM will hog the transfer between DRAM and
> >> LCD if my understanding is correct. That's the DMA that Peter wants to
> >> disable with his patch ?
> >>
> >> Then we can then try to force NFC SRAM DMA channels to use just DDR port
> >> 1 or 2 for memcpy ?
> >
> > You mean the dmaengine? According to "14.1.3 Master to Slave Access"
> > that's already the case.
> >
> > Only DMAC0 can access the NFC SRAM and it's done through DMAC0:IF0,
> > then access to DDR is going through port DDR port 1 (DMAC0:IF1) or 2
> > (DMAC0:IF0).
>
> If we can make NFC use port 1 only, then HLCDC could have two ports as
> master 8 & 9, maybe a better bandwidth.
Peter, can you try with the following patch?
--->8---
diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
index ef3f227ce3e6..2a48e870f292 100644
--- a/drivers/dma/at_hdmac_regs.h
+++ b/drivers/dma/at_hdmac_regs.h
@@ -124,8 +124,8 @@
#define ATC_SIF(i) (0x3 & (i)) /* Src tx done via AHB-Lite Interface i */
#define ATC_DIF(i) ((0x3 & (i)) << 4) /* Dst tx done via AHB-Lite Interface i */
/* Specify AHB interfaces */
-#define AT_DMA_MEM_IF 0 /* interface 0 as memory interface */
-#define AT_DMA_PER_IF 1 /* interface 1 as peripheral interface */
+#define AT_DMA_MEM_IF 1 /* interface 0 as memory interface */
+#define AT_DMA_PER_IF 0 /* interface 1 as peripheral interface */
#define ATC_SRC_PIP (0x1 << 8) /* Source Picture-in-Picture enabled */
#define ATC_DST_PIP (0x1 << 12) /* Destination Picture-in-Picture enabled */
^ permalink raw reply related
* [PATCH] ARM: mcpm, perf/arm-cci: export mcpm_is_available
From: Will Deacon @ 2018-05-29 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529154251.GM17671@n2100.armlinux.org.uk>
On Tue, May 29, 2018 at 04:42:51PM +0100, Russell King - ARM Linux wrote:
> On Tue, May 29, 2018 at 04:41:20PM +0100, Will Deacon wrote:
> > Hi Russell,
> >
> > On Tue, May 29, 2018 at 04:33:24PM +0100, Russell King - ARM Linux wrote:
> > > On Tue, May 29, 2018 at 04:30:14PM +0100, Will Deacon wrote:
> > > > Hi Arnd, Russell, [+Nico and Robin]
> > > >
> > > > On Mon, May 28, 2018 at 05:44:36PM +0200, Arnd Bergmann wrote:
> > > > > Now that the ARM CCI PMU driver can be built as a loadable module,
> > > > > we get a link failure when MCPM is enabled:
> > > > >
> > > > > ERROR: "mcpm_is_available" [drivers/perf/arm-cci.ko] undefined!
> > > > >
> > > > > The simplest fix is to export that helper function.
> > > > >
> > > > > Fixes: 8b0c93c20ef7 ("perf/arm-cci: Allow building as a module")
> > > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > > > ---
> > > > > The patch that caused this is currently part of the arm-perf/for-next/perf
> > > > > branch, it would be good to have the fix there as well.
> > > > > ---
> > > > > arch/arm/common/mcpm_entry.c | 2 ++
> > > > > 1 file changed, 2 insertions(+)
> > > >
> > > > I'm happy to take this via the arm perf tree if others are ok with that.
> > > > Alternatively, I can revert the offending commit if there are objections
> > > > to exporting the symbol.
> > > >
> > > > Russell: do you any preference?
> > >
> > > As it claims to fix 8b0c93c20ef7, which I don't have, I can't take this
> > > patch. Do we know which tree has this?
> >
> > Yes, sorry, it's in my for-next/perf branch:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=for-next/perf&id=8b0c93c20ef78f15d8b760964ff79bda7f68c610
> >
> > which is now in -next.
> >
> > I'm happy to take the mcpm patch on top with your ack, but if you have
> > conflicting changes (or would prefer not to export the symbol to modules)
> > then I can just revert the patch in my tree for now.
>
> I have no changes to that file, so:
>
> Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Thanks, I've picked up the fix from Arnd with your Ack and will push out
this evening.
Will
^ permalink raw reply
* [PATCH v9 00/12] Support PPTT for ARM64
From: Geert Uytterhoeven @ 2018-05-29 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <551905a6-eaa8-97df-06ec-1ceedfbc164f@arm.com>
Hi Sudeep,
On Tue, May 29, 2018 at 3:18 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>>>> <catalin.marinas@arm.com> wrote:
>>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>>>> Jeremy Linton (12):
>>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>>>
>>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
>>>>> can add it separately).
>>>>
>>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>>>> system suspend on big.LITTLE systems to hang after shutting down the first
>>>> CPU:
>>>>
>>>> $ echo mem > /sys/power/state
>>>> PM: suspend entry (deep)
>>>> PM: Syncing filesystems ... done.
>>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>>>> OOM killer disabled.
>>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>>>> Disabling non-boot CPUs ...
>>>> CPU1: shutdown
>>>> psci: CPU1 killed.
>>>
>>> Is it OK to assume the suspend failed just after shutting down one CPU
>>> or it's failing during resume ? It depends on whether you had console
>>> disabled or not.
>>
>> I have no-console-suspend enabled.
>> It's failing during suspend, the next lines should be:
>>
>> CPU2: shutdown
>> psci: CPU2 killed.
>> ...
>
> OK, I was hoping to be something during resume as this patch has nothing
> executed during suspend. Do you see any change in topology before and
> after this patch applied. I am interested in the output of:
>
> $ grep "" /sys/devices/system/cpu/cpu*/topology/*
/sys/devices/system/cpu/cpu0/topology/core_id:0
/sys/devices/system/cpu/cpu0/topology/core_siblings:0f
/sys/devices/system/cpu/cpu0/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu0/topology/physical_package_id:0
/sys/devices/system/cpu/cpu0/topology/thread_siblings:01
/sys/devices/system/cpu/cpu0/topology/thread_siblings_list:0
/sys/devices/system/cpu/cpu1/topology/core_id:1
/sys/devices/system/cpu/cpu1/topology/core_siblings:0f
/sys/devices/system/cpu/cpu1/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu1/topology/physical_package_id:0
/sys/devices/system/cpu/cpu1/topology/thread_siblings:02
/sys/devices/system/cpu/cpu1/topology/thread_siblings_list:1
/sys/devices/system/cpu/cpu2/topology/core_id:2
/sys/devices/system/cpu/cpu2/topology/core_siblings:0f
/sys/devices/system/cpu/cpu2/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu2/topology/physical_package_id:0
/sys/devices/system/cpu/cpu2/topology/thread_siblings:04
/sys/devices/system/cpu/cpu2/topology/thread_siblings_list:2
/sys/devices/system/cpu/cpu3/topology/core_id:3
/sys/devices/system/cpu/cpu3/topology/core_siblings:0f
/sys/devices/system/cpu/cpu3/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu3/topology/physical_package_id:0
/sys/devices/system/cpu/cpu3/topology/thread_siblings:08
/sys/devices/system/cpu/cpu3/topology/thread_siblings_list:3
/sys/devices/system/cpu/cpu4/topology/core_id:0
/sys/devices/system/cpu/cpu4/topology/core_siblings:f0
/sys/devices/system/cpu/cpu4/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu4/topology/physical_package_id:1
/sys/devices/system/cpu/cpu4/topology/thread_siblings:10
/sys/devices/system/cpu/cpu4/topology/thread_siblings_list:4
/sys/devices/system/cpu/cpu5/topology/core_id:1
/sys/devices/system/cpu/cpu5/topology/core_siblings:f0
/sys/devices/system/cpu/cpu5/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu5/topology/physical_package_id:1
/sys/devices/system/cpu/cpu5/topology/thread_siblings:20
/sys/devices/system/cpu/cpu5/topology/thread_siblings_list:5
/sys/devices/system/cpu/cpu6/topology/core_id:2
/sys/devices/system/cpu/cpu6/topology/core_siblings:f0
/sys/devices/system/cpu/cpu6/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu6/topology/physical_package_id:1
/sys/devices/system/cpu/cpu6/topology/thread_siblings:40
/sys/devices/system/cpu/cpu6/topology/thread_siblings_list:6
/sys/devices/system/cpu/cpu7/topology/core_id:3
/sys/devices/system/cpu/cpu7/topology/core_siblings:f0
/sys/devices/system/cpu/cpu7/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu7/topology/physical_package_id:1
/sys/devices/system/cpu/cpu7/topology/thread_siblings:80
/sys/devices/system/cpu/cpu7/topology/thread_siblings_list:7
No change before/after (both match my view of the hardware).
>
>>>> For me, it fails on the following big.LITTLE systems:
>>>>
>>>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>>>> R-Car M3-W (2xCA57 + 4xCA53)
>>>>
>>>
>>> Interesting, is it PSCI based system suspend ?
>>
>> Yes it is.
>
> From DT, I guess this platform doesn't have any idle states.
> Does this use genpd power domains ? I see power-domains in the DT, so
> asking to get more info. Do you have any out of tree patches especially
> if they are depending on some topology cpumasks ?
No out-of-tree patches.
I'm testing plain 37c3ec2d810f87ea vs. 37c3ec2d810f87ea^.
There are power-domains in DT, but they're not managed by the new
fancy CPU power domain code.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v9 00/12] Support PPTT for ARM64
From: Geert Uytterhoeven @ 2018-05-29 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529150823.GD17159@arm.com>
Hi Will,
On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>> >>> System supend still works fine on systems with big cores only:
>> >>>
>> >>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>> >>> R-Car M3-N (2xCA57)
>> >>>
>> >>> Reverting this commit fixes the issue for me.
>> >>
>> >> I can't find anything that relates to system suspend in these patches
>> >> unless they are messing with something during CPU hot plug-in back
>> >> during resume.
>> >
>> > It's only the last patch that introduces the breakage.
>> >
>>
>> As specified in the commit log, it won't change any behavior for DT
>> systems if it's non-NUMA or single node system. So I am still wondering
>> what could trigger this regression.
>
> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
> to the scheduler, although I can't see how this would happen.
>
> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
> do you see anything shouting in dmesg?
Thanks, but unfortunately it doesn't help.
I added some debug code to print cpumask, but so far I don't see anything
suspicious.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] ARM: mcpm, perf/arm-cci: export mcpm_is_available
From: Nicolas Pitre @ 2018-05-29 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529153013.GH17159@arm.com>
On Tue, 29 May 2018, Will Deacon wrote:
> Hi Arnd, Russell, [+Nico and Robin]
>
> On Mon, May 28, 2018 at 05:44:36PM +0200, Arnd Bergmann wrote:
> > Now that the ARM CCI PMU driver can be built as a loadable module,
> > we get a link failure when MCPM is enabled:
> >
> > ERROR: "mcpm_is_available" [drivers/perf/arm-cci.ko] undefined!
> >
> > The simplest fix is to export that helper function.
> >
> > Fixes: 8b0c93c20ef7 ("perf/arm-cci: Allow building as a module")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > The patch that caused this is currently part of the arm-perf/for-next/perf
> > branch, it would be good to have the fix there as well.
> > ---
> > arch/arm/common/mcpm_entry.c | 2 ++
> > 1 file changed, 2 insertions(+)
>
> I'm happy to take this via the arm perf tree if others are ok with that.
> Alternatively, I can revert the offending commit if there are objections
> to exporting the symbol.
Looks fine to me.
Acked-by: Nicolas Pitre <nico@linaro.org>
Nicolas
^ permalink raw reply
* [PATCH v4] arm64: allwinner: a64: Add Amarula A64-Relic initial support
From: Maxime Ripard @ 2018-05-29 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524111631.11864-1-jagan@amarulasolutions.com>
On Thu, May 24, 2018 at 04:46:31PM +0530, Jagan Teki wrote:
> Amarula A64-Relic is Allwinner A64 based IoT device, which support
> - Allwinner A64 Cortex-A53
> - Mali-400MP2 GPU
> - AXP803 PMIC
> - 1GB DDR3 RAM
> - 8GB eMMC
> - AP6330 Wifi/BLE
> - MIPI-DSI
> - CSI: OV5640 sensor
> - USB OTG
> - 12V DC power supply
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Applied, thanks
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2] rtc: sun6i: Fix bit_idx value for clk_register_gate
From: Jagan Teki @ 2018-05-29 16:04 UTC (permalink / raw)
To: linux-arm-kernel
From: Michael Trimarchi <michael@amarulasolutions.com>
clk-gate core will take bit_idx through clk_register_gate
and then do clk_gate_ops by using BIT(bit_idx), but rtc-sun6i
is passing bit_idx as BIT(bit_idx) it becomes BIT(BIT(bit_idx)
which is wrong and eventually external gate clock is not enabling.
This patch fixed by passing bit index and the original change
introduced from below commit.
"rtc: sun6i: Add support for the external oscillator gate"
(sha1: 17ecd246414b3a0fe0cb248c86977a8bda465b7b)
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- add suffix _OFFSET with macro name to distinguish b/w
register actual values vs offset.
drivers/rtc/rtc-sun6i.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index 2e6fb275acc8..2cd5a7b1a2e3 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -74,7 +74,7 @@
#define SUN6I_ALARM_CONFIG_WAKEUP BIT(0)
#define SUN6I_LOSC_OUT_GATING 0x0060
-#define SUN6I_LOSC_OUT_GATING_EN BIT(0)
+#define SUN6I_LOSC_OUT_GATING_EN_OFFSET 0
/*
* Get date values
@@ -255,7 +255,7 @@ static void __init sun6i_rtc_clk_init(struct device_node *node)
&clkout_name);
rtc->ext_losc = clk_register_gate(NULL, clkout_name, rtc->hw.init->name,
0, rtc->base + SUN6I_LOSC_OUT_GATING,
- SUN6I_LOSC_OUT_GATING_EN, 0,
+ SUN6I_LOSC_OUT_GATING_EN_OFFSET, 0,
&rtc->lock);
if (IS_ERR(rtc->ext_losc)) {
pr_crit("Couldn't register the LOSC external gate\n");
--
2.14.3
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: renesas: r8a77980: add I2C support
From: Sergei Shtylyov @ 2018-05-29 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529130504.lpkpgads7lfomois@verge.net.au>
On 05/29/2018 04:05 PM, Simon Horman wrote:
>> Define the generic R8A77980 parts of the I2C[0-5] device node.
>>
>> Based on the original (and large) patch by Vladimir Barinov.
>>
>> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>> arch/arm64/boot/dts/renesas/r8a77980.dtsi | 111 ++++++++++++++++++++++++++++++
>> 1 file changed, 111 insertions(+)
>>
>> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
>> ===================================================================
>> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
>> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
[...]
>> @@ -135,6 +144,108 @@
[...]
>> + i2c3: i2c at e66d0000 {
>> + compatible = "renesas,i2c-r8a77980",
>> + "renesas,rcar-gen3-i2c";
>> + reg = <0 0xe66d0000 0 0x40>;
>> + interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&cpg CPG_MOD 928>;
>> + power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
>> + resets = <&cpg 928>;
>> + dmas = <&dmac1 0x97>, <&dmac1 0x96>,
>> + <&dmac2 0x97>, <&dmac2 0x96>;
>> + dma-names = "tx", "rx", "tx", "rx";
>> + i2c-scl-internal-delay-ns = <6>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + status = "disabled";
>> + };
>
> DMA for i2c3 and i2c4 seems unclear in v0.80 and v1.00 of the User's Manual.
> Although what is described here does match v0.55E of the User's Manual.
Hm, looking at all these manuals, I'm not even seeing V3H I2C3/4 having DMA
in v0.55E!
> Have you been able to confirm what is correct here?
No. Probably need to drop I2C3/4 DMA altogether...
> Other than that this patch looks fine to me.
TY!
[...]
MBR, Sergei
^ permalink raw reply
* [RFT v3 1/4] perf cs-etm: Generate branch sample for missed packets
From: Mathieu Poirier @ 2018-05-29 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529002538.GA11317@leoy-ThinkPad-X240s>
On 28 May 2018 at 18:25, Leo Yan <leo.yan@linaro.org> wrote:
> Hi Mathieu,
>
> On Mon, May 28, 2018 at 04:13:47PM -0600, Mathieu Poirier wrote:
>> Leo and/or Robert,
>>
>> On Mon, May 28, 2018 at 04:45:00PM +0800, Leo Yan wrote:
>> > Commit e573e978fb12 ("perf cs-etm: Inject capabilitity for CoreSight
>> > traces") reworks the samples generation flow from CoreSight trace to
>> > match the correct format so Perf report tool can display the samples
>> > properly.
>> >
>> > But the change has side effect for branch packet handling, it only
>> > generate branch samples by checking previous packet flag
>> > 'last_instr_taken_branch' is true, this results in below three kinds
>> > packets are missed to generate branch samples:
>> >
>> > - The start tracing packet at the beginning of tracing data;
>> > - The exception handling packet;
>> > - If one CS_ETM_TRACE_ON packet is inserted, we also miss to handle it
>> > for branch samples. CS_ETM_TRACE_ON packet itself can give the info
>> > that there have a discontinuity in the trace, on the other hand we
>> > also miss to generate proper branch sample for packets before and
>> > after CS_ETM_TRACE_ON packet.
>> >
>> > This patch is to add branch sample handling for up three kinds packets:
>> >
>> > - In function cs_etm__sample(), check if 'prev_packet->sample_type' is
>> > zero and in this case it generates branch sample for the start tracing
>> > packet; furthermore, we also need to handle the condition for
>> > prev_packet::end_addr is zero in the cs_etm__last_executed_instr();
>> >
>> > - In function cs_etm__sample(), check if 'prev_packet->exc' is true and
>> > generate branch sample for exception handling packet;
>> >
>> > - If there has one CS_ETM_TRACE_ON packet is coming, we firstly generate
>> > branch sample in the function cs_etm__flush(), this can save complete
>> > info for the previous CS_ETM_RANGE packet just before CS_ETM_TRACE_ON
>> > packet. We also generate branch sample for the new CS_ETM_RANGE
>> > packet after CS_ETM_TRACE_ON packet, this have two purposes, the
>> > first one purpose is to save the info for the new CS_ETM_RANGE packet,
>> > the second purpose is to save CS_ETM_TRACE_ON packet info so we can
>> > have hint for a discontinuity in the trace.
>> >
>> > For CS_ETM_TRACE_ON packet, its fields 'packet->start_addr' and
>> > 'packet->end_addr' equal to 0xdeadbeefdeadbeefUL which are emitted in
>> > the decoder layer as dummy value. This patch is to convert these
>> > values to zeros for more readable; this is accomplished by functions
>> > cs_etm__last_executed_instr() and cs_etm__first_executed_instr(). The
>> > later one is a new function introduced by this patch.
>> >
>> > Reviewed-by: Robert Walker <robert.walker@arm.com>
>> > Fixes: e573e978fb12 ("perf cs-etm: Inject capabilitity for CoreSight traces")
>> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
>> > ---
>> > tools/perf/util/cs-etm.c | 93 +++++++++++++++++++++++++++++++++++++-----------
>> > 1 file changed, 73 insertions(+), 20 deletions(-)
>> >
>> > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
>> > index 822ba91..8418173 100644
>> > --- a/tools/perf/util/cs-etm.c
>> > +++ b/tools/perf/util/cs-etm.c
>> > @@ -495,6 +495,20 @@ static inline void cs_etm__reset_last_branch_rb(struct cs_etm_queue *etmq)
>> > static inline u64 cs_etm__last_executed_instr(struct cs_etm_packet *packet)
>> > {
>> > /*
>> > + * The packet is the start tracing packet if the end_addr is zero,
>> > + * returns 0 for this case.
>> > + */
>> > + if (!packet->end_addr)
>> > + return 0;
>>
>> What is considered to be the "start tracing packet"? Right now the only two
>> kind of packets inserted in the decoder packet buffer queue are INST_RANGE and
>> TRACE_ON. How can we hit a condition where packet->end-addr == 0?
>
> When the first CS_ETM_RANGE packet is coming, etmq->prev_packet is
> initialized by the function cs_etm__alloc_queue(), so
> etmq->prev_packet->end_addr is zero:
>
> etmq->prev_packet = zalloc(szp);
>
> As you mentioned, we should only have two kind of packets for
> CS_ETM_RANGE and CS_ETM_TRACE_ON. Currently we skip to handle the
> first CS_ETM_TRACE_ON packet in function cs_etm__flush(), we also can
> refine the function cs_etm__flush() to handle the first coming
> CS_ETM_TRACE_ON packet, after that all packets will be CS_ETM_RANGE
> and CS_ETM_TRACE_ON and have no chance to hit 'packet->end_addr = 0'.
>
> Does this make sense for you?
That is the right way to handle this condition and it gives us a
reliable state machine.
>
> --- Packet dumping when first packet coming ---
> cs_etm__flush: prev_packet: sample_type=0 exc=0 exc_ret=0 cpu=0 start_addr=0x0 end_addr=0x0 last_instr_taken_branch=0
> cs_etm__flush: packet: sample_type=2 exc=0 exc_ret=0 cpu=1 start_addr=0xdeadbeefdeadbeef end_addr=0xdeadbeefdeadbeef last_instr_taken_branch=0
>
>> > +
>> > + /*
>> > + * The packet is the CS_ETM_TRACE_ON packet if the end_addr is
>> > + * magic number 0xdeadbeefdeadbeefUL, returns 0 for this case.
>> > + */
>> > + if (packet->end_addr == 0xdeadbeefdeadbeefUL)
>> > + return 0;
>>
>> As it is with the above, I find triggering on addresses to be brittle and hard
>> to maintain on the long run. Packets all have a sample_type field that should
>> be used in cases like this one. That way we know exactly the condition that is
>> targeted.
>
> Will do this.
>
>> While working on this set, please spin-off another patch that defines
>> CS_ETM_INVAL_ADDR 0xdeadbeefdeadbeefUL and replace all the cases where the
>> numeral is used. That way we stop using the hard coded value.
>
> Will do this.
Much appreciated.
>
> As now this patch is big with more complex logic, so I consider to
> split it into small patches:
>
> - Define CS_ETM_INVAL_ADDR;
> - Fix for CS_ETM_TRACE_ON packet;
> - Fix for exception packet;
>
> Does this make sense for you? I have concern that this patch is a
> fixing patch, so not sure after spliting patches will introduce
> trouble for applying them for other stable kernels ...
Reverse the order:
- Fix for CS_ETM_TRACE_ON packet;
- Fix for exception packet;
- Define CS_ETM_INVAL_ADDR;
But you may not need to - see next comment.
>
>> > +
>> > + /*
>> > * The packet records the execution range with an exclusive end address
>> > *
>> > * A64 instructions are constant size, so the last executed
>> > @@ -505,6 +519,18 @@ static inline u64 cs_etm__last_executed_instr(struct cs_etm_packet *packet)
>> > return packet->end_addr - A64_INSTR_SIZE;
>> > }
>> >
>> > +static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
>> > +{
>> > + /*
>> > + * The packet is the CS_ETM_TRACE_ON packet if the start_addr is
>> > + * magic number 0xdeadbeefdeadbeefUL, returns 0 for this case.
>> > + */
>> > + if (packet->start_addr == 0xdeadbeefdeadbeefUL)
>> > + return 0;
>>
>> Same comment as above.
>
> Will do this.
>
>> > +
>> > + return packet->start_addr;
>> > +}
>> > +
>> > static inline u64 cs_etm__instr_count(const struct cs_etm_packet *packet)
>> > {
>> > /*
>> > @@ -546,7 +572,7 @@ static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq)
>> >
>> > be = &bs->entries[etmq->last_branch_pos];
>> > be->from = cs_etm__last_executed_instr(etmq->prev_packet);
>> > - be->to = etmq->packet->start_addr;
>> > + be->to = cs_etm__first_executed_instr(etmq->packet);
>> > /* No support for mispredict */
>> > be->flags.mispred = 0;
>> > be->flags.predicted = 1;
>> > @@ -701,7 +727,7 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq)
>> > sample.ip = cs_etm__last_executed_instr(etmq->prev_packet);
>> > sample.pid = etmq->pid;
>> > sample.tid = etmq->tid;
>> > - sample.addr = etmq->packet->start_addr;
>> > + sample.addr = cs_etm__first_executed_instr(etmq->packet);
>> > sample.id = etmq->etm->branches_id;
>> > sample.stream_id = etmq->etm->branches_id;
>> > sample.period = 1;
>> > @@ -897,13 +923,28 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
>> > etmq->period_instructions = instrs_over;
>> > }
>> >
>> > - if (etm->sample_branches &&
>> > - etmq->prev_packet &&
>> > - etmq->prev_packet->sample_type == CS_ETM_RANGE &&
>> > - etmq->prev_packet->last_instr_taken_branch) {
>> > - ret = cs_etm__synth_branch_sample(etmq);
>> > - if (ret)
>> > - return ret;
>> > + if (etm->sample_branches && etmq->prev_packet) {
>> > + bool generate_sample = false;
>> > +
>> > + /* Generate sample for start tracing packet */
>> > + if (etmq->prev_packet->sample_type == 0 ||
>>
>> What kind of packet is sample_type == 0 ?
>
> Just as explained above, sample_type == 0 is the packet which
> initialized in the function cs_etm__alloc_queue().
>
>> > + etmq->prev_packet->sample_type == CS_ETM_TRACE_ON)
>> > + generate_sample = true;
>> > +
>> > + /* Generate sample for exception packet */
>> > + if (etmq->prev_packet->exc == true)
>> > + generate_sample = true;
>>
>> Please don't do that. Exception packets have a type of their own and can be
>> added to the decoder packet queue the same way INST_RANGE and TRACE_ON packets
>> are. Moreover exception packet containt an address that, if I'm reading the
>> documenation properly, can be used to keep track of instructions that were
>> executed between the last address of the previous range packet and the address
>> executed just before the exception occurred. Mike and Rob will have to confirm
>> this as the decoder may be doing all that hard work for us.
>
> Sure, will wait for Rob and Mike to confirm for this.
>
> At my side, I dump the packet, the exception packet isn't passed to
> cs-etm.c layer, the decoder layer only sets the flag
> 'packet->exc = true' when exception packet is coming [1].
That's because we didn't need the information. Now that we do a
function that will insert a packet in the decoder packet queue and
deal with the new packet type in the main decoder loop [2]. At that
point your work may not be eligible for stable anymore and I think it
is fine. Robert's work was an enhancement over mine and yours is an
enhancement over his.
[2]. https://elixir.bootlin.com/linux/v4.17-rc7/source/tools/perf/util/cs-etm.c#L999
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c#n364
>
>> > +
>> > + /* Generate sample for normal branch packet */
>> > + if (etmq->prev_packet->sample_type == CS_ETM_RANGE &&
>> > + etmq->prev_packet->last_instr_taken_branch)
>> > + generate_sample = true;
>> > +
>> > + if (generate_sample) {
>> > + ret = cs_etm__synth_branch_sample(etmq);
>> > + if (ret)
>> > + return ret;
>> > + }
>> > }
>> >
>> > if (etm->sample_branches || etm->synth_opts.last_branch) {
>> > @@ -922,11 +963,16 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
>> > static int cs_etm__flush(struct cs_etm_queue *etmq)
>> > {
>> > int err = 0;
>> > + struct cs_etm_auxtrace *etm = etmq->etm;
>> > struct cs_etm_packet *tmp;
>> >
>> > - if (etmq->etm->synth_opts.last_branch &&
>> > - etmq->prev_packet &&
>> > - etmq->prev_packet->sample_type == CS_ETM_RANGE) {
>> > + if (!etmq->prev_packet)
>> > + return 0;
>> > +
>> > + if (etmq->prev_packet->sample_type != CS_ETM_RANGE)
>> > + return 0;
>> > +
>> > + if (etmq->etm->synth_opts.last_branch) {
>>
>> If you add:
>>
>> if (!etmq->etm->synth_opts.last_branch)
>> return 0;
>>
>> You can avoid indenting the whole block.
>
> No, here we cannot do like this. Except we need to handle the
> condition for 'etmq->etm->synth_opts.last_branch', we also need to
> handle 'etm->sample_branches'. These two conditions are saperate and
> decide by different command parameters from 'perf script'.
Pardon me - I didn't see the addition of the new '}' just below.
>
>> > /*
>> > * Generate a last branch event for the branches left in the
>> > * circular buffer at the end of the trace.
>> > @@ -939,18 +985,25 @@ static int cs_etm__flush(struct cs_etm_queue *etmq)
>> > err = cs_etm__synth_instruction_sample(
>> > etmq, addr,
>> > etmq->period_instructions);
>> > + if (err)
>> > + return err;
>> > etmq->period_instructions = 0;
>> > + }
>> >
>> > - /*
>> > - * Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for
>> > - * the next incoming packet.
>> > - */
>> > - tmp = etmq->packet;
>> > - etmq->packet = etmq->prev_packet;
>> > - etmq->prev_packet = tmp;
>> > + if (etm->sample_branches) {
>> > + err = cs_etm__synth_branch_sample(etmq);
>> > + if (err)
>> > + return err;
>> > }
>> >
>> > - return err;
>> > + /*
>> > + * Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for
>> > + * the next incoming packet.
>> > + */
>> > + tmp = etmq->packet;
>> > + etmq->packet = etmq->prev_packet;
>> > + etmq->prev_packet = tmp;
>>
>> Robert, I remember noticing that when you first submitted the code but forgot to
>> go back to it. What is the point of swapping the packets? I understand
>>
>> etmq->prev_packet = etmq->packet;
>>
>> But not
>>
>> etmq->packet = tmp;
>>
>> After all etmq->packet will be clobbered as soon as cs_etm_decoder__get_packet()
>> is called, which is alwasy right after either cs_etm__sample() or
>> cs_etm__flush().
>
> Yeah, I have the same question for this :)
>
> Thanks for suggestions and reviewing.
>
>> Thanks,
>> Mathieu
>>
>>
>>
>> > + return 0;
>> > }
>> >
>> > static int cs_etm__run_decoder(struct cs_etm_queue *etmq)
>> > --
>> > 2.7.4
>> >
^ permalink raw reply
* [PATCH v2] rtc: sun6i: Fix bit_idx value for clk_register_gate
From: Maxime Ripard @ 2018-05-29 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529160425.23697-1-jagan@amarulasolutions.com>
On Tue, May 29, 2018 at 09:34:25PM +0530, Jagan Teki wrote:
> From: Michael Trimarchi <michael@amarulasolutions.com>
>
> clk-gate core will take bit_idx through clk_register_gate
> and then do clk_gate_ops by using BIT(bit_idx), but rtc-sun6i
> is passing bit_idx as BIT(bit_idx) it becomes BIT(BIT(bit_idx)
> which is wrong and eventually external gate clock is not enabling.
>
> This patch fixed by passing bit index and the original change
> introduced from below commit.
> "rtc: sun6i: Add support for the external oscillator gate"
> (sha1: 17ecd246414b3a0fe0cb248c86977a8bda465b7b)
>
> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
I said it in the v1 already, but this should be sent to stable and
have a fixes tag.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v3 3/3] x86/mm: add TLB purge to free pmd/pte page interfaces
From: Kani, Toshi @ 2018-05-29 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529144438.GM18595@8bytes.org>
On Tue, 2018-05-29 at 16:44 +0200, Joerg Roedel wrote:
> On Wed, May 16, 2018 at 05:32:07PM -0600, Toshi Kani wrote:
> > pmd = (pmd_t *)pud_page_vaddr(*pud);
> > + pmd_sv = (pmd_t *)__get_free_page(GFP_KERNEL);
> > + if (!pmd_sv)
> > + return 0;
>
> So your code still needs to allocate a full page where a simple
> list_head on the stack would do the same job.
Can you explain why you think allocating a page here is a major problem?
As I explained before, pud_free_pmd_page() covers an extremely rare case
which I could not even hit with a huge number of ioremap() calls until
I instrumented alloc_vmap_area() to force this case to happen. I do not
think pages should be listed for such a rare case.
> Ingo, Thomas, can you please just revert the original broken patch for
> now until there is proper fix?
If we just revert, please apply patch 1/3 first. This patch address the
BUG_ON issue on PAE. This is a real issue that needs a fix ASAP.
The page-directory cache issue on x64, which is addressed by patch 3/3,
is a theoretical issue that I could not hit by putting ioremap() calls
into a loop for a whole day. Nobody hit this issue, either.
The simple revert patch Joerg posted a while ago causes
pmd_free_pte_page() to fail on x64. This causes multiple pmd mappings
to fall into pte mappings on my test systems. This can be seen as a
degradation, and I am afraid that it is more harmful than good.
Thanks,
-Toshi
^ permalink raw reply
* [PATCH v2 1/5] crypto: ccree: correct host regs offset
From: Simon Horman @ 2018-05-29 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527171551-21979-2-git-send-email-gilad@benyossef.com>
On Thu, May 24, 2018 at 03:19:06PM +0100, Gilad Ben-Yossef wrote:
> The product signature and HW revision register have different offset on the
> older HW revisions.
> This fixes the problem of the driver failing sanity check on silicon
> despite working on the FPGA emulation systems.
>
> Fixes: 27b3b22dd98c ("crypto: ccree - add support for older HW revs")
Did the above introduce a regression that is fixed by this patch
or did it add a feature that only works with this patch?
In the case of the latter I would drop the Fixes tag,
but I don't feel strongly about it.
> Cc: stable at vger.kernel.org
> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Minor not below not withstanding,
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> drivers/crypto/ccree/cc_debugfs.c | 7 +++++--
> drivers/crypto/ccree/cc_driver.c | 8 ++++++--
> drivers/crypto/ccree/cc_driver.h | 2 ++
> drivers/crypto/ccree/cc_host_regs.h | 6 ++++--
> 4 files changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/crypto/ccree/cc_debugfs.c b/drivers/crypto/ccree/cc_debugfs.c
> index 08f8db4..5ca184e 100644
> --- a/drivers/crypto/ccree/cc_debugfs.c
> +++ b/drivers/crypto/ccree/cc_debugfs.c
> @@ -26,7 +26,8 @@ struct cc_debugfs_ctx {
> static struct dentry *cc_debugfs_dir;
>
> static struct debugfs_reg32 debug_regs[] = {
> - CC_DEBUG_REG(HOST_SIGNATURE),
> + { .name = "SIGNATURE" }, /* Must be 0th */
> + { .name = "VERSION" }, /* Must be 1st */
> CC_DEBUG_REG(HOST_IRR),
> CC_DEBUG_REG(HOST_POWER_DOWN_EN),
> CC_DEBUG_REG(AXIM_MON_ERR),
> @@ -34,7 +35,6 @@ static struct debugfs_reg32 debug_regs[] = {
> CC_DEBUG_REG(HOST_IMR),
> CC_DEBUG_REG(AXIM_CFG),
> CC_DEBUG_REG(AXIM_CACHE_PARAMS),
> - CC_DEBUG_REG(HOST_VERSION),
> CC_DEBUG_REG(GPR_HOST),
> CC_DEBUG_REG(AXIM_MON_COMP),
> };
> @@ -58,6 +58,9 @@ int cc_debugfs_init(struct cc_drvdata *drvdata)
> struct debugfs_regset32 *regset;
> struct dentry *file;
>
> + debug_regs[0].offset = drvdata->sig_offset;
> + debug_regs[1].offset = drvdata->ver_offset;
> +
> ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> if (!ctx)
> return -ENOMEM;
> diff --git a/drivers/crypto/ccree/cc_driver.c b/drivers/crypto/ccree/cc_driver.c
> index 89ce013..6f93ce7 100644
> --- a/drivers/crypto/ccree/cc_driver.c
> +++ b/drivers/crypto/ccree/cc_driver.c
> @@ -207,9 +207,13 @@ static int init_cc_resources(struct platform_device *plat_dev)
> if (hw_rev->rev >= CC_HW_REV_712) {
> new_drvdata->hash_len_sz = HASH_LEN_SIZE_712;
> new_drvdata->axim_mon_offset = CC_REG(AXIM_MON_COMP);
> + new_drvdata->sig_offset = CC_REG(HOST_SIGNATURE_712);
> + new_drvdata->ver_offset = CC_REG(HOST_VERSION_712);
> } else {
> new_drvdata->hash_len_sz = HASH_LEN_SIZE_630;
> new_drvdata->axim_mon_offset = CC_REG(AXIM_MON_COMP8);
> + new_drvdata->sig_offset = CC_REG(HOST_SIGNATURE_630);
> + new_drvdata->ver_offset = CC_REG(HOST_VERSION_630);
> }
>
> platform_set_drvdata(plat_dev, new_drvdata);
> @@ -276,7 +280,7 @@ static int init_cc_resources(struct platform_device *plat_dev)
> }
>
> /* Verify correct mapping */
> - signature_val = cc_ioread(new_drvdata, CC_REG(HOST_SIGNATURE));
> + signature_val = cc_ioread(new_drvdata, new_drvdata->sig_offset);
> if (signature_val != hw_rev->sig) {
> dev_err(dev, "Invalid CC signature: SIGNATURE=0x%08X != expected=0x%08X\n",
> signature_val, hw_rev->sig);
> @@ -287,7 +291,7 @@ static int init_cc_resources(struct platform_device *plat_dev)
>
> /* Display HW versions */
> dev_info(dev, "ARM CryptoCell %s Driver: HW version 0x%08X, Driver version %s\n",
> - hw_rev->name, cc_ioread(new_drvdata, CC_REG(HOST_VERSION)),
> + hw_rev->name, cc_ioread(new_drvdata, new_drvdata->ver_offset),
> DRV_MODULE_VERSION);
>
> rc = init_cc_regs(new_drvdata, true);
> diff --git a/drivers/crypto/ccree/cc_driver.h b/drivers/crypto/ccree/cc_driver.h
> index 2048fde..95f82b2 100644
> --- a/drivers/crypto/ccree/cc_driver.h
> +++ b/drivers/crypto/ccree/cc_driver.h
> @@ -129,6 +129,8 @@ struct cc_drvdata {
This patch doesn't make things (much) worse
but struct cc_drvdata has a rather incomplete kdoc.
> enum cc_hw_rev hw_rev;
> u32 hash_len_sz;
> u32 axim_mon_offset;
> + u32 sig_offset;
> + u32 ver_offset;
> };
>
> struct cc_crypto_alg {
> diff --git a/drivers/crypto/ccree/cc_host_regs.h b/drivers/crypto/ccree/cc_host_regs.h
> index f510018..616b2e1 100644
> --- a/drivers/crypto/ccree/cc_host_regs.h
> +++ b/drivers/crypto/ccree/cc_host_regs.h
> @@ -45,7 +45,8 @@
> #define CC_HOST_ICR_DSCRPTR_WATERMARK_QUEUE0_CLEAR_BIT_SIZE 0x1UL
> #define CC_HOST_ICR_AXIM_COMP_INT_CLEAR_BIT_SHIFT 0x17UL
> #define CC_HOST_ICR_AXIM_COMP_INT_CLEAR_BIT_SIZE 0x1UL
> -#define CC_HOST_SIGNATURE_REG_OFFSET 0xA24UL
> +#define CC_HOST_SIGNATURE_712_REG_OFFSET 0xA24UL
> +#define CC_HOST_SIGNATURE_630_REG_OFFSET 0xAC8UL
> #define CC_HOST_SIGNATURE_VALUE_BIT_SHIFT 0x0UL
> #define CC_HOST_SIGNATURE_VALUE_BIT_SIZE 0x20UL
> #define CC_HOST_BOOT_REG_OFFSET 0xA28UL
> @@ -105,7 +106,8 @@
> #define CC_HOST_BOOT_ONLY_ENCRYPT_LOCAL_BIT_SIZE 0x1UL
> #define CC_HOST_BOOT_AES_EXISTS_LOCAL_BIT_SHIFT 0x1EUL
> #define CC_HOST_BOOT_AES_EXISTS_LOCAL_BIT_SIZE 0x1UL
> -#define CC_HOST_VERSION_REG_OFFSET 0xA40UL
> +#define CC_HOST_VERSION_712_REG_OFFSET 0xA40UL
> +#define CC_HOST_VERSION_630_REG_OFFSET 0xAD8UL
> #define CC_HOST_VERSION_VALUE_BIT_SHIFT 0x0UL
> #define CC_HOST_VERSION_VALUE_BIT_SIZE 0x20UL
> #define CC_HOST_KFDE0_VALID_REG_OFFSET 0xA60UL
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2 2/5] crypto: ccree: better clock handling
From: Simon Horman @ 2018-05-29 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527171551-21979-3-git-send-email-gilad@benyossef.com>
On Thu, May 24, 2018 at 03:19:07PM +0100, Gilad Ben-Yossef wrote:
> Use managed clock handling, differentiate between no clock (possibly OK)
> and clock init failure (never OK) and correctly handle clock detection
> being deferred.
>
> Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> drivers/crypto/ccree/cc_driver.c | 20 +++++++++++++++++++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/ccree/cc_driver.c b/drivers/crypto/ccree/cc_driver.c
> index 6f93ce7..b266657 100644
> --- a/drivers/crypto/ccree/cc_driver.c
> +++ b/drivers/crypto/ccree/cc_driver.c
> @@ -190,6 +190,7 @@ static int init_cc_resources(struct platform_device *plat_dev)
> u64 dma_mask;
> const struct cc_hw_data *hw_rev;
> const struct of_device_id *dev_id;
> + struct clk *clk;
> int rc = 0;
>
> new_drvdata = devm_kzalloc(dev, sizeof(*new_drvdata), GFP_KERNEL);
> @@ -219,7 +220,24 @@ static int init_cc_resources(struct platform_device *plat_dev)
> platform_set_drvdata(plat_dev, new_drvdata);
> new_drvdata->plat_dev = plat_dev;
>
> - new_drvdata->clk = of_clk_get(np, 0);
> + clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(clk))
> + switch (PTR_ERR(clk)) {
> + /* Clock is optional so this might be fine */
> + case -ENOENT:
> + break;
> +
> + /* Clock not available, let's try again soon */
> + case -EPROBE_DEFER:
> + return -EPROBE_DEFER;
> +
> + default:
> + dev_err(dev, "Error getting clock: %ld\n",
> + PTR_ERR(clk));
> + return PTR_ERR(clk);
> + }
> + new_drvdata->clk = clk;
> +
> new_drvdata->coherent = of_dma_is_coherent(np);
>
> /* Get device resources */
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2 3/5] crypto: ccree: silence debug prints
From: Simon Horman @ 2018-05-29 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527171551-21979-4-git-send-email-gilad@benyossef.com>
On Thu, May 24, 2018 at 03:19:08PM +0100, Gilad Ben-Yossef wrote:
> The cache parameter register configuration was being too verbose.
> Use dev_dbg() to only provide the information if needed.
>
> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH v2 5/5] arm64: dts: renesas: r8a7795: add ccree binding
From: Simon Horman @ 2018-05-29 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527171551-21979-6-git-send-email-gilad@benyossef.com>
On Thu, May 24, 2018 at 03:19:10PM +0100, Gilad Ben-Yossef wrote:
> Add bindings for CryptoCell instance in the SoC.
>
> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
In so far as I can review the details of this (which is not much) this
looks fine to me. I am, however, a little unclear in when it should be
accepted.
> ---
> arch/arm64/boot/dts/renesas/r8a7795.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index d842940..3ac75db 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -528,6 +528,15 @@
> status = "disabled";
> };
>
> + arm_cc630p: crypto at e6601000 {
> + compatible = "arm,cryptocell-630p-ree";
> + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
> + reg = <0x0 0xe6601000 0 0x1000>;
> + clocks = <&cpg CPG_MOD 229>;
> + resets = <&cpg 229>;
> + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> + };
> +
> i2c3: i2c at e66d0000 {
> #address-cells = <1>;
> #size-cells = <0>;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] kvm: no need to check return value of debugfs_create functions
From: Greg Kroah-Hartman @ 2018-05-29 16:22 UTC (permalink / raw)
To: linux-arm-kernel
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
This cleans up the error handling a lot, as this code will never get
hit.
Cc: Paul Mackerras <paulus@ozlabs.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Christoffer Dall <christoffer.dall@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Kr?m??" <rkrcmar@redhat.com>
Cc: Arvind Yadav <arvind.yadav.cs@gmail.com>
Cc: Eric Auger <eric.auger@redhat.com>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: kvm-ppc at vger.kernel.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: kvmarm at lists.cs.columbia.edu
Cc: kvm at vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kvm/book3s_hv.c | 3 +--
virt/kvm/arm/vgic/vgic-debug.c | 17 ++++-----------
virt/kvm/arm/vgic/vgic.h | 4 ++--
virt/kvm/kvm_main.c | 40 +++++++---------------------------
4 files changed, 15 insertions(+), 49 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 4d07fca5121c..67d7de1470cc 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -3950,8 +3950,7 @@ static int kvmppc_core_init_vm_hv(struct kvm *kvm)
*/
snprintf(buf, sizeof(buf), "vm%d", current->pid);
kvm->arch.debugfs_dir = debugfs_create_dir(buf, kvm_debugfs_dir);
- if (!IS_ERR_OR_NULL(kvm->arch.debugfs_dir))
- kvmppc_mmu_debugfs_init(kvm);
+ kvmppc_mmu_debugfs_init(kvm);
return 0;
}
diff --git a/virt/kvm/arm/vgic/vgic-debug.c b/virt/kvm/arm/vgic/vgic-debug.c
index 10b38178cff2..0140b29079b6 100644
--- a/virt/kvm/arm/vgic/vgic-debug.c
+++ b/virt/kvm/arm/vgic/vgic-debug.c
@@ -263,21 +263,12 @@ static const struct file_operations vgic_debug_fops = {
.release = seq_release
};
-int vgic_debug_init(struct kvm *kvm)
+void vgic_debug_init(struct kvm *kvm)
{
- if (!kvm->debugfs_dentry)
- return -ENOENT;
-
- if (!debugfs_create_file("vgic-state", 0444,
- kvm->debugfs_dentry,
- kvm,
- &vgic_debug_fops))
- return -ENOMEM;
-
- return 0;
+ debugfs_create_file("vgic-state", 0444, kvm->debugfs_dentry, kvm,
+ &vgic_debug_fops);
}
-int vgic_debug_destroy(struct kvm *kvm)
+void vgic_debug_destroy(struct kvm *kvm)
{
- return 0;
}
diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h
index 830e815748a0..3c38c5349953 100644
--- a/virt/kvm/arm/vgic/vgic.h
+++ b/virt/kvm/arm/vgic/vgic.h
@@ -229,8 +229,8 @@ void vgic_get_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr);
int vgic_lazy_init(struct kvm *kvm);
int vgic_init(struct kvm *kvm);
-int vgic_debug_init(struct kvm *kvm);
-int vgic_debug_destroy(struct kvm *kvm);
+void vgic_debug_init(struct kvm *kvm);
+void vgic_debug_destroy(struct kvm *kvm);
bool lock_all_vcpus(struct kvm *kvm);
void unlock_all_vcpus(struct kvm *kvm);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index c7b2e927f699..0ad400f353fc 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -572,10 +572,7 @@ static int kvm_create_vm_debugfs(struct kvm *kvm, int fd)
return 0;
snprintf(dir_name, sizeof(dir_name), "%d-%d", task_pid_nr(current), fd);
- kvm->debugfs_dentry = debugfs_create_dir(dir_name,
- kvm_debugfs_dir);
- if (!kvm->debugfs_dentry)
- return -ENOMEM;
+ kvm->debugfs_dentry = debugfs_create_dir(dir_name, kvm_debugfs_dir);
kvm->debugfs_stat_data = kcalloc(kvm_debugfs_num_entries,
sizeof(*kvm->debugfs_stat_data),
@@ -591,11 +588,8 @@ static int kvm_create_vm_debugfs(struct kvm *kvm, int fd)
stat_data->kvm = kvm;
stat_data->offset = p->offset;
kvm->debugfs_stat_data[p - debugfs_entries] = stat_data;
- if (!debugfs_create_file(p->name, 0644,
- kvm->debugfs_dentry,
- stat_data,
- stat_fops_per_vm[p->kind]))
- return -ENOMEM;
+ debugfs_create_file(p->name, 0644, kvm->debugfs_dentry,
+ stat_data, stat_fops_per_vm[p->kind]);
}
return 0;
}
@@ -3896,29 +3890,18 @@ static void kvm_uevent_notify_change(unsigned int type, struct kvm *kvm)
kfree(env);
}
-static int kvm_init_debug(void)
+static void kvm_init_debug(void)
{
- int r = -EEXIST;
struct kvm_stats_debugfs_item *p;
kvm_debugfs_dir = debugfs_create_dir("kvm", NULL);
- if (kvm_debugfs_dir == NULL)
- goto out;
kvm_debugfs_num_entries = 0;
for (p = debugfs_entries; p->name; ++p, kvm_debugfs_num_entries++) {
- if (!debugfs_create_file(p->name, 0644, kvm_debugfs_dir,
- (void *)(long)p->offset,
- stat_fops[p->kind]))
- goto out_dir;
+ debugfs_create_file(p->name, 0644, kvm_debugfs_dir,
+ (void *)(long)p->offset,
+ stat_fops[p->kind]);
}
-
- return 0;
-
-out_dir:
- debugfs_remove_recursive(kvm_debugfs_dir);
-out:
- return r;
}
static int kvm_suspend(void)
@@ -4046,20 +4029,13 @@ int kvm_init(void *opaque, unsigned vcpu_size, unsigned vcpu_align,
kvm_preempt_ops.sched_in = kvm_sched_in;
kvm_preempt_ops.sched_out = kvm_sched_out;
- r = kvm_init_debug();
- if (r) {
- pr_err("kvm: create debugfs files failed\n");
- goto out_undebugfs;
- }
+ kvm_init_debug();
r = kvm_vfio_ops_init();
WARN_ON(r);
return 0;
-out_undebugfs:
- unregister_syscore_ops(&kvm_syscore_ops);
- misc_deregister(&kvm_dev);
out_unreg:
kvm_async_pf_deinit();
out_free:
--
2.17.0
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: renesas: r8a77980: add I2C support
From: Geert Uytterhoeven @ 2018-05-29 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3675b19f-b800-172f-9472-c47a37760fa9@cogentembedded.com>
On Mon, May 28, 2018 at 10:13 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Define the generic R8A77980 parts of the I2C[0-5] device node.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
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