* [PATCH 2/2] ARM64: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro
From: Peng Donglin @ 2018-06-13 1:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b55024472e101a33b3d6b098aa2ce23c5b5dd6f7.1528819790.git.dolinux.peng@gmail.com>
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Peng Donglin <dolinux.peng@gmail.com>
---
arch/arm64/mm/ptdump_debugfs.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/arm64/mm/ptdump_debugfs.c b/arch/arm64/mm/ptdump_debugfs.c
index 02b18f8..24d786f 100644
--- a/arch/arm64/mm/ptdump_debugfs.c
+++ b/arch/arm64/mm/ptdump_debugfs.c
@@ -10,18 +10,7 @@ static int ptdump_show(struct seq_file *m, void *v)
ptdump_walk_pgd(m, info);
return 0;
}
-
-static int ptdump_open(struct inode *inode, struct file *file)
-{
- return single_open(file, ptdump_show, inode->i_private);
-}
-
-static const struct file_operations ptdump_fops = {
- .open = ptdump_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(ptdump);
int ptdump_debugfs_register(struct ptdump_info *info, const char *name)
{
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] ARM: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro
From: Peng Donglin @ 2018-06-13 1:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528819790.git.dolinux.peng@gmail.com>
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Peng Donglin <dolinux.peng@gmail.com>
---
arch/arm/mm/ptdump_debugfs.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/arm/mm/ptdump_debugfs.c b/arch/arm/mm/ptdump_debugfs.c
index be8d87b..79002fe 100644
--- a/arch/arm/mm/ptdump_debugfs.c
+++ b/arch/arm/mm/ptdump_debugfs.c
@@ -11,18 +11,7 @@ static int ptdump_show(struct seq_file *m, void *v)
ptdump_walk_pgd(m, info);
return 0;
}
-
-static int ptdump_open(struct inode *inode, struct file *file)
-{
- return single_open(file, ptdump_show, inode->i_private);
-}
-
-static const struct file_operations ptdump_fops = {
- .open = ptdump_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(ptdump);
int ptdump_debugfs_register(struct ptdump_info *info, const char *name)
{
--
2.7.4
^ permalink raw reply related
* [PATCH 09/10] Input: ams_delta_serio: use IRQ resource
From: Janusz Krzysztofik @ 2018-06-13 1:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612222104.GC38773@dtor-ws>
On Wednesday, June 13, 2018 12:21:04 AM CEST Dmitry Torokhov wrote:
> On Sat, Jun 09, 2018 at 04:02:23PM +0200, Janusz Krzysztofik wrote:
> > ...
> > @@ -141,14 +141,11 @@ static int ams_delta_serio_init(struct
> > platform_device *pdev)>
> > * at FIQ level, switch back from edge to simple interrupt handler
> > * to avoid bad interaction.
> > */
> >
> > - irq_set_handler(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK),
> > - handle_simple_irq);
> > + irq_set_handler(irq, handle_simple_irq);
>
> Do we still need to do this here, or it can be moved into board file?
You're right, it should be possible to move it. I'll check possible options
and submit a follow up patch.
Thanks,
Janusz
^ permalink raw reply
* [PATCH 04/10] Input: ams_delta_serio: Replace power GPIO with regulator
From: Janusz Krzysztofik @ 2018-06-13 1:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612221724.GB38773@dtor-ws>
On Wednesday, June 13, 2018 12:17:24 AM CEST Dmitry Torokhov wrote:
> On Sat, Jun 09, 2018 at 04:02:18PM +0200, Janusz Krzysztofik wrote:
> > ...
> > + priv->vcc = devm_regulator_get(&pdev->dev, "vcc");
> > + if (IS_ERR(priv->vcc)) {
> > + err = PTR_ERR(priv->vcc);
> > + dev_err(&pdev->dev, "regulator request failed (%d)\n", err);
> > + /* Fail softly if the regulator is not available yet */
> > + if (err == -ENODEV)
> > + err = -EPROBE_DEFER;
>
> Hmm, if regulator is not ready yet, devm_regulator_get() should be
> returning -EPROBE_DEFER already, we should not have to convert -ENODEV
> to -EPROBE_DEFER...
Regulator is not ready because its initialization at subsys_initcall is
deferred by not ready GPIO pin, that in turn is caused by gpio-mmio driver,
unlike many other GPIO drivers, registered as late as at device_initcall.
I agree devm_regulator_get() could return -EPROBE_DEFER in this case, but I
can see it does that only when of_get_regulator() indicates the regulator
should exist. In non-dt case there is apparently no way to justify if it
should unless its consumer supply table was already in place. For that,
registration of that table would have to be independent of successful
registration of the regulator itself while it's not. Maybe it should, but
that's a separate topic for a separate discussion, I think.
> Is it because we have_full_constraints() returns false? You might need
> to add call to regulator_has_full_constraints() to your board file.
If have_full_constraints() returned true before the regulator or its consumer
supply table is ready, devm_regulator_get() would happily return a dummy
regulator and our keyboard would never get its power.
I'm afraid we have to live with that return code conversion as long as the
only user of this driver is not migrated to dt.
Thanks,
Janusz
^ permalink raw reply
* [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715
From: Florian Fainelli @ 2018-06-13 0:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612202411.29798-3-nm@ti.com>
On June 12, 2018 1:24:09 PM PDT, Nishanth Menon <nm@ti.com> wrote:
>As recommended by Arm in [1], ACTLR[0] (Enable invalidates of BTB)
>needs to be set[2] for BTB to be invalidated on ICIALLU. This needs to
>be done unconditionally for Cortex-A15 processors. Provide a config
>option for platforms to enable this option based on impact analysis
>for products.
>
>NOTE: This patch in itself is NOT the final solution, this requires:
>a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
> provide direct access to ACR register.
>b) Operating Systems such as Linux to provide adequate workaround in
>the
> right locations.
This is the case as of 4.18 so you could probably reference CONFIG_CPU_SPECTRE and CONFIG_HARDEN_BRANCH_PREDICTOR in a v2.
>c) This workaround applies to only the boot processor. It is important
> to apply workaround as necessary (context-save-restore) around low
> power context loss OR additional processors as necessary in either
> firmware support OR elsewhere in OS.
About that, I don't know enough of uboot but are there existing PSCI or other seemingly standard secondary core support in uboot that would make us go through the same initialization as the boot CPU? If not, is everything going to be largely implementation specific and scattered between uboot and the hypervisors or kernel?
FWIW, this is what prompted me to submit this:
https://patchwork.kernel.org/patch/10453643/
>
>[1] https://developer.arm.com/support/security-update
>[2]
>http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438c/BABGHIBG.html
>
>Cc: Marc Zyngier <marc.zyngier@arm.com>
>Cc: Russell King <linux@arm.linux.org.uk>
>Cc: Tony Lindgren <tony@atomide.com>
>Cc: Robin Murphy <robin.murphy@arm.com>
>Cc: Florian Fainelli <f.fainelli@gmail.com>
>Cc: Catalin Marinas <catalin.marinas@arm.com>
>Cc: Will Deacon <will.deacon@arm.com>
>Cc: Christoffer Dall <christoffer.dall@linaro.org>
>Cc: Andre Przywara <Andre.Przywara@arm.com>
>Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>Cc: Tom Rini <trini@konsulko.com>
>Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
>
>Signed-off-by: Nishanth Menon <nm@ti.com>
>---
> arch/arm/Kconfig | 4 ++++
> arch/arm/cpu/armv7/start.S | 8 ++++++++
> 2 files changed, 12 insertions(+)
>
>diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>index 9e32d5b43cb0..98f58fd27696 100644
>--- a/arch/arm/Kconfig
>+++ b/arch/arm/Kconfig
>@@ -109,6 +109,7 @@ config SYS_ARM_MPU
> # CONFIG_ARM_ERRATA_798870
> # CONFIG_ARM_ERRATA_801819
> # CONFIG_ARM_CORTEX_A8_CVE_2017_5715
>+# CONFIG_ARM_CORTEX_A15_CVE_2017_5715
>
> config ARM_ERRATA_430973
> bool
>@@ -182,6 +183,9 @@ config ARM_ERRATA_855873
> config ARM_CORTEX_A8_CVE_2017_5715
> bool
>
>+config ARM_CORTEX_A15_CVE_2017_5715
>+ bool
>+
> config CPU_ARM720T
> bool
> select SYS_CACHE_SHIFT_5
>diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
>index 3beaf5a93d81..81edec01bf32 100644
>--- a/arch/arm/cpu/armv7/start.S
>+++ b/arch/arm/cpu/armv7/start.S
>@@ -241,6 +241,14 @@ skip_errata_798870:
> skip_errata_801819:
> #endif
>
>+#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
>+ mrc p15, 0, r0, c1, c0, 1 @ read auxilary control register
>+ orr r0, r0, #1 << 0 @ Enable invalidates of BTB
>+ push {r1-r5} @ Save the cpu info registers
>+ bl v7_arch_cp15_set_acr
>+ pop {r1-r5} @ Restore the cpu info - fall through
>+#endif
>+
> #ifdef CONFIG_ARM_ERRATA_454179
> mrc p15, 0, r0, c1, c0, 1 @ Read ACR
>
--
Florian
^ permalink raw reply
* [PATCH 0/4] ARM: Provide workaround setup bits for CVE-2017-5715 (A8/A15)
From: Marek Vasut @ 2018-06-12 23:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612202411.29798-1-nm@ti.com>
On 06/12/2018 10:24 PM, Nishanth Menon wrote:
> Hi,
>
> This is a follow on from https://marc.info/?l=u-boot&m=151691688828176&w=2 (RFC)
>
> NOTE:
> * As per ARM recommendations[2], and discussions in list[1] ARM
> Cortex-A9/12/17 do not need additional steps in u-boot to enable the
> OS level workarounds.
> * This itself is'nt a complete solution and is based on recommendation
> This from Arm[2] for variant 2 CVE-2017-5715 -> Kernel changes can be seen on
> linux next (next-20180612) or on linux master (upcoming v4.18-rc1 tag).
> * I think it is necessary on older SoCs without firmware support
> (such as older OMAPs and AM*) to have kernel support mirroring what we do in
> u-boot to support additional cores AND/OR low power states where contexts are
> lost (assuming ACR states are'nt saved). just my 2 cents.
>
> Few of the tests (with linux next-20180612):
> AM571-IDK: https://pastebin.ubuntu.com/p/sr5X6sN3Tr/ (single core A15)
> OMAP5-uEVM: https://pastebin.ubuntu.com/p/9yDM22bJ6n/ (dual core A15)
> OMAP3-beagle-xm: https://pastebin.ubuntu.com/p/9DfDkpyxym/ (Single A8)
> AM335x-Beaglebone-black: https://pastebin.ubuntu.com/p/DczT9jPMwb/ (Single A8)
>
> Nishanth Menon (4):
> ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for
> CVE-2017-5715
> ARM: Introduce ability to enable invalidate of BTB with ICIALLU on
> Cortex-A15 for CVE-2017-5715
> ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of
> BTB) to facilitate CVE_2017-5715 WA in OS
> ARM: mach-omap2: omap3/am335x: Enable ACR::IBE on Cortex-A8 SoCs for
> CVE-2017-5715
>
> arch/arm/Kconfig | 9 +++++++++
> arch/arm/cpu/armv7/start.S | 15 +++++++++++++--
> arch/arm/mach-omap2/Kconfig | 3 +++
> 3 files changed, 25 insertions(+), 2 deletions(-)
>
> [1] https://marc.info/?t=151639906500002&r=1&w=2
> [2] https://developer.arm.com/support/security-update
> [3] https://marc.info/?t=151543790400007&r=1&w=2 and the latest in:
> https://marc.info/?l=linux-arm-kernel&m=151689379521082&w=2
> [4]
> https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6
> https://www.op-tee.org/security-advisories/
> https://www.linaro.org/blog/meltdown-spectre/
>
Except for that minor insignificant nit about BIT() macro, entire series
Acked-by: Marek Vasut <marek.vasut@gmail.com>
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 3/4] ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS
From: Marek Vasut @ 2018-06-12 23:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612202411.29798-4-nm@ti.com>
On 06/12/2018 10:24 PM, Nishanth Menon wrote:
> Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr
> function to setup the bits, we are able to override the settings.
>
> Without this enabled, Linux kernel reports:
> CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
>
> With this enabled, Linux kernel reports:
> CPU0: Spectre v2: using ICIALLU workaround
>
> NOTE: This by itself does not enable the workaround for CPU1 (on
> OMAP5 and DRA72/AM572 SoCs) and may require additional kernel patches.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> arch/arm/mach-omap2/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 3bb1ecb58de0..77820cc8d1e4 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -53,6 +53,7 @@ config OMAP54XX
> bool "OMAP54XX SoC"
> select ARM_ERRATA_798870
> select SYS_THUMB_BUILD
> + select ARM_CORTEX_A15_CVE_2017_5715
> imply NAND_OMAP_ELM
> imply NAND_OMAP_GPMC
> imply SPL_DISPLAY_PRINT
>
Can this be enabled for all CA15 systems somehow ? I am sure there are
more that are vulnerable.
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715
From: Marek Vasut @ 2018-06-12 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612202411.29798-3-nm@ti.com>
On 06/12/2018 10:24 PM, Nishanth Menon wrote:
> As recommended by Arm in [1], ACTLR[0] (Enable invalidates of BTB)
> needs to be set[2] for BTB to be invalidated on ICIALLU. This needs to
> be done unconditionally for Cortex-A15 processors. Provide a config
> option for platforms to enable this option based on impact analysis
> for products.
>
> NOTE: This patch in itself is NOT the final solution, this requires:
> a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
> provide direct access to ACR register.
> b) Operating Systems such as Linux to provide adequate workaround in the
> right locations.
> c) This workaround applies to only the boot processor. It is important
> to apply workaround as necessary (context-save-restore) around low
> power context loss OR additional processors as necessary in either
> firmware support OR elsewhere in OS.
>
> [1] https://developer.arm.com/support/security-update
> [2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438c/BABGHIBG.html
>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Christoffer Dall <christoffer.dall@linaro.org>
> Cc: Andre Przywara <Andre.Przywara@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Tom Rini <trini@konsulko.com>
> Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> arch/arm/Kconfig | 4 ++++
> arch/arm/cpu/armv7/start.S | 8 ++++++++
> 2 files changed, 12 insertions(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 9e32d5b43cb0..98f58fd27696 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -109,6 +109,7 @@ config SYS_ARM_MPU
> # CONFIG_ARM_ERRATA_798870
> # CONFIG_ARM_ERRATA_801819
> # CONFIG_ARM_CORTEX_A8_CVE_2017_5715
> +# CONFIG_ARM_CORTEX_A15_CVE_2017_5715
>
> config ARM_ERRATA_430973
> bool
> @@ -182,6 +183,9 @@ config ARM_ERRATA_855873
> config ARM_CORTEX_A8_CVE_2017_5715
> bool
>
> +config ARM_CORTEX_A15_CVE_2017_5715
> + bool
> +
> config CPU_ARM720T
> bool
> select SYS_CACHE_SHIFT_5
> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
> index 3beaf5a93d81..81edec01bf32 100644
> --- a/arch/arm/cpu/armv7/start.S
> +++ b/arch/arm/cpu/armv7/start.S
> @@ -241,6 +241,14 @@ skip_errata_798870:
> skip_errata_801819:
> #endif
>
> +#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
> + mrc p15, 0, r0, c1, c0, 1 @ read auxilary control register
> + orr r0, r0, #1 << 0 @ Enable invalidates of BTB
Can we use BIT() macro in the assembler code too ?
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
From: Rob Herring @ 2018-06-12 22:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <395f1fe8-76f1-8310-d09e-63e25bca23d2@broadcom.com>
On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
<scott.branden@broadcom.com> wrote:
> Hi Rob,
>
> Could you please kindly comment on change below.
>
> It allows board variants to be added easily via a simple define for
> different number of SATA ports.
>
>
>
> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>
>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>
>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>> ports based on NUM_SATA defined.
>>> Now, all that needs to be done is define NUM_SATA per board.
>>
>> Rob could you review this and let us know if this approach is okay or
>> not? Thank you!
>>
>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>> ---
>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> index 8c68e0c..7f6d176 100644
>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> @@ -43,7 +43,11 @@
>>> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>> +#if (NUM_SATA > 0)
>>> + status = "okay";
>>> +#else
>>> status = "disabled";
>>> +#endif
This only works if ports are contiguously enabled (0-N). You might not
care, but it is not a pattern that works in general. And I'm not a fan
of C preprocessing in DT files in general beyond just defines for
single numbers.
Rob
^ permalink raw reply
* [PATCH] net: stmmac: dwmac-meson8b: Fix an error handling path in 'meson8b_dwmac_probe()'
From: David Miller @ 2018-06-12 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611175227.27509-1-christophe.jaillet@wanadoo.fr>
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Mon, 11 Jun 2018 19:52:27 +0200
> If 'of_device_get_match_data()' fails, we need to release some resources as
> done in the other error handling path of this function.
>
> Fixes: efacb568c962 ("net: stmmac: dwmac-meson: extend phy mode setting")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Applied.
^ permalink raw reply
* [PATCH] net: thunderx: prevent concurrent data re-writing by nicvf_set_rx_mode
From: David Miller @ 2018-06-12 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <036618ae-887f-44b5-2b39-451b81191cc1@redhat.com>
From: Dean Nelson <dnelson@redhat.com>
Date: Mon, 11 Jun 2018 06:22:14 -0500
> On 06/10/2018 02:35 PM, David Miller wrote:
>> From: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
>> Date: Fri, 8 Jun 2018 02:27:59 -0700
>>
>>> + /* Save message data locally to prevent them from
>>> + * being overwritten by next ndo_set_rx_mode call().
>>> + */
>>> + spin_lock(&nic->rx_mode_wq_lock);
>>> + mode = vf_work->mode;
>>> + mc = vf_work->mc;
>>> + vf_work->mc = NULL;
>
> If I'm reading this code correctly, I believe nic->rx_mode_work.mc
> will
> have been set to NULL before the lock is dropped by
> nicvf_set_rx_mode_task() and acquired by nicvf_set_rx_mode().
>
>
>>> + spin_unlock(&nic->rx_mode_wq_lock);
>> At the moment you drop this lock, the memory behind 'mc' can be
>> freed up by:
>>
>>> + spin_lock(&nic->rx_mode_wq_lock);
>>> + kfree(nic->rx_mode_work.mc);
>
> So the kfree() will be called with a NULL pointer and quickly return.
>
>
>> And you'll crash when you dereference it above via
>> __nicvf_set_rx_mode_task().
>>
>
> I believe the call to kfree() in nicvf_set_rx_mode() is there to free
> up a mc_list that has been allocated by nicvf_set_rx_mode() during a
> previous callback to the function, one that has not yet been processed
> by nicvf_set_rx_mode_task().
>
> In this way only the last 'unprocessed' callback to
> nicvf_set_rx_mode()
> gets processed should there be multiple callbacks occurring between
> the
> times the nicvf_set_rx_mode_task() runs.
>
> In my testing with this patch, this is what I see happening.
You're right, my bad.
Patch applied.
^ permalink raw reply
* [PATCH 01/10] ARM: OMAP1: ams-delta: drop GPIO lookup table for serio device
From: Dmitry Torokhov @ 2018-06-12 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180609140224.32606-1-jmkrzyszt@gmail.com>
Hi Janusz,
On Sat, Jun 09, 2018 at 04:02:15PM +0200, Janusz Krzysztofik wrote:
> GPIO lookup table for ams-delta-serio device was introduced by commit
> 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables").
> Unfortunately, a follow up patch "Input: ams_delta_serio: use GPIO
> lookup table" was not accepted by subystem maintainer who requested
> conversion of the driver to a platform driver, replacepemnt of IRQ GPIO
> pin with IRQ resource, replacement of GPIO pin providing keyboard power
> with a regulator and removal of remaining GPIO pins from the driver as
> not handled by it.
>
> Let's start with removal of no the longer needed GPIO lookup table from
> the board init file.
>
> Series created and tested on top of next-20180608 tag from linux-next
> tree.
This all is really nice (modulo a couple of questions), thank you for
implementing this. How do you want to merge this? Through OMAP tree or
input?
>
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
> ---
> arch/arm/mach-omap1/board-ams-delta.c | 19 -------------------
> 1 file changed, 19 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
> index 80f54cb54276..18e0ff437b27 100644
> --- a/arch/arm/mach-omap1/board-ams-delta.c
> +++ b/arch/arm/mach-omap1/board-ams-delta.c
> @@ -504,20 +504,6 @@ static struct platform_device cx20442_codec_device = {
> .id = -1,
> };
>
> -static struct gpiod_lookup_table ams_delta_serio_gpio_table = {
> - .table = {
> - GPIO_LOOKUP(OMAP_GPIO_LABEL, AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
> - "data", 0),
> - GPIO_LOOKUP(OMAP_GPIO_LABEL, AMS_DELTA_GPIO_PIN_KEYBRD_CLK,
> - "clock", 0),
> - GPIO_LOOKUP(LATCH2_LABEL, LATCH2_PIN_KEYBRD_PWR,
> - "power", 0),
> - GPIO_LOOKUP(LATCH2_LABEL, LATCH2_PIN_KEYBRD_DATAOUT,
> - "dataout", 0),
> - { },
> - },
> -};
> -
> static struct platform_device *ams_delta_devices[] __initdata = {
> &latch1_gpio_device,
> &latch2_gpio_device,
> @@ -534,7 +520,6 @@ static struct platform_device *late_devices[] __initdata = {
>
> static struct gpiod_lookup_table *ams_delta_gpio_tables[] __initdata = {
> &ams_delta_audio_gpio_table,
> - &ams_delta_serio_gpio_table,
> };
>
> static struct gpiod_lookup_table *late_gpio_tables[] __initdata = {
> @@ -580,10 +565,6 @@ static void __init ams_delta_init(void)
> */
> ams_delta_audio_gpio_table.dev_id =
> dev_name(&ams_delta_audio_device.dev);
> - /*
> - * No device name is assigned to GPIO lookup table for serio device
> - * as long as serio driver is not converted to platform device driver.
> - */
>
> gpiod_add_lookup_tables(ams_delta_gpio_tables,
> ARRAY_SIZE(ams_delta_gpio_tables));
> --
> 2.16.1
>
--
Dmitry
^ permalink raw reply
* [PATCH 09/10] Input: ams_delta_serio: use IRQ resource
From: Dmitry Torokhov @ 2018-06-12 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180609140224.32606-9-jmkrzyszt@gmail.com>
On Sat, Jun 09, 2018 at 04:02:23PM +0200, Janusz Krzysztofik wrote:
> The driver still obtains IRQ number from a hardcoded GPIO. Use IRQ
> resource instead.
>
> For this to work on Amstrad Delta, add the IRQ resource to
> ams-delta-serio platform device structure. Obtain the IRQ number
> assigned to "keyboard_clk" GPIO pin from FIQ initialization routine.
>
> As a benefit, the driver no longer needs to include
> <mach/board-ams-delta.h>.
>
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
> ---
> arch/arm/mach-omap1/ams-delta-fiq.c | 8 +++++++-
> arch/arm/mach-omap1/ams-delta-fiq.h | 3 ++-
> arch/arm/mach-omap1/board-ams-delta.c | 17 ++++++++++++++++-
> drivers/input/serio/ams_delta_serio.c | 28 ++++++++++------------------
> 4 files changed, 35 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/ams-delta-fiq.c b/arch/arm/mach-omap1/ams-delta-fiq.c
> index e72935034d42..e9d350117240 100644
> --- a/arch/arm/mach-omap1/ams-delta-fiq.c
> +++ b/arch/arm/mach-omap1/ams-delta-fiq.c
> @@ -20,6 +20,7 @@
> #include <linux/module.h>
> #include <linux/io.h>
> #include <linux/platform_data/ams-delta-fiq.h>
> +#include <linux/platform_device.h>
>
> #include <mach/board-ams-delta.h>
>
> @@ -84,7 +85,8 @@ static irqreturn_t deferred_fiq(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> -void __init ams_delta_init_fiq(struct gpio_chip *chip)
> +void __init ams_delta_init_fiq(struct gpio_chip *chip,
> + struct platform_device *serio)
> {
> struct gpio_desc *gpiod, *data = NULL, *clk = NULL;
> void *fiqhandler_start;
> @@ -201,6 +203,10 @@ void __init ams_delta_init_fiq(struct gpio_chip *chip)
> val = omap_readl(OMAP_IH1_BASE + offset) | 1;
> omap_writel(val, OMAP_IH1_BASE + offset);
>
> + /* Initialize serio device IRQ resource */
> + serio->resource[0].start = gpiod_to_irq(clk);
> + serio->resource[0].end = serio->resource[0].start;
> +
> return;
>
> out_gpio:
> diff --git a/arch/arm/mach-omap1/ams-delta-fiq.h b/arch/arm/mach-omap1/ams-delta-fiq.h
> index 3f691d68aa62..fd76df3cce37 100644
> --- a/arch/arm/mach-omap1/ams-delta-fiq.h
> +++ b/arch/arm/mach-omap1/ams-delta-fiq.h
> @@ -35,7 +35,8 @@
> #ifndef __ASSEMBLER__
> extern unsigned char qwerty_fiqin_start, qwerty_fiqin_end;
>
> -extern void __init ams_delta_init_fiq(struct gpio_chip *chip);
> +extern void __init ams_delta_init_fiq(struct gpio_chip *chip,
> + struct platform_device *pdev);
> #endif
>
> #endif
> diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
> index fe9a3e7cbfeb..84177ba3e39a 100644
> --- a/arch/arm/mach-omap1/board-ams-delta.c
> +++ b/arch/arm/mach-omap1/board-ams-delta.c
> @@ -504,9 +504,24 @@ static struct platform_device cx20442_codec_device = {
> .id = -1,
> };
>
> +static struct resource ams_delta_serio_resources[] = {
> + {
> + .flags = IORESOURCE_IRQ,
> + /*
> + * Initialize IRQ resource with invalid IRQ number.
> + * It will be replaced with dynamically allocated GPIO IRQ
> + * obtained from GPIO chip as soon as the chip is available.
> + */
> + .start = -EINVAL,
> + .end = -EINVAL,
> + },
> +};
> +
> static struct platform_device ams_delta_serio_device = {
> .name = "ams-delta-serio",
> .id = PLATFORM_DEVID_NONE,
> + .num_resources = ARRAY_SIZE(ams_delta_serio_resources),
> + .resource = ams_delta_serio_resources,
> };
>
> static struct regulator_consumer_supply keybrd_pwr_consumers[] = {
> @@ -615,7 +630,7 @@ static void __init omap_gpio_deps_init(void)
> return;
> }
>
> - ams_delta_init_fiq(chip);
> + ams_delta_init_fiq(chip, &ams_delta_serio_device);
> }
>
> static void __init ams_delta_init(void)
> diff --git a/drivers/input/serio/ams_delta_serio.c b/drivers/input/serio/ams_delta_serio.c
> index 5d0bd2005648..03640b171516 100644
> --- a/drivers/input/serio/ams_delta_serio.c
> +++ b/drivers/input/serio/ams_delta_serio.c
> @@ -20,7 +20,6 @@
> * However, when used with the E3 mailboard that producecs non-standard
> * scancodes, a custom key table must be prepared and loaded from userspace.
> */
> -#include <linux/gpio.h>
> #include <linux/irq.h>
> #include <linux/platform_data/ams-delta-fiq.h>
> #include <linux/platform_device.h>
> @@ -29,8 +28,6 @@
> #include <linux/slab.h>
> #include <linux/module.h>
>
> -#include <mach/board-ams-delta.h>
> -
> #define DRIVER_NAME "ams-delta-serio"
>
> MODULE_AUTHOR("Matt Callow");
> @@ -113,7 +110,7 @@ static int ams_delta_serio_init(struct platform_device *pdev)
> {
> struct ams_delta_serio *priv;
> struct serio *serio;
> - int err;
> + int irq, err;
>
> priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> if (!priv)
> @@ -129,9 +126,12 @@ static int ams_delta_serio_init(struct platform_device *pdev)
> return err;
> }
>
> - err = request_irq(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK),
> - ams_delta_serio_interrupt, IRQ_TYPE_EDGE_RISING,
> - DRIVER_NAME, priv);
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0)
> + return -ENXIO;
> +
> + err = devm_request_irq(&pdev->dev, irq, ams_delta_serio_interrupt,
> + IRQ_TYPE_EDGE_RISING, DRIVER_NAME, priv);
> if (err < 0) {
> dev_err(&pdev->dev, "IRQ request failed (%d)\n", err);
> return err;
> @@ -141,14 +141,11 @@ static int ams_delta_serio_init(struct platform_device *pdev)
> * at FIQ level, switch back from edge to simple interrupt handler
> * to avoid bad interaction.
> */
> - irq_set_handler(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK),
> - handle_simple_irq);
> + irq_set_handler(irq, handle_simple_irq);
Do we still need to do this here, or it can be moved into board file?
>
> serio = kzalloc(sizeof(*serio), GFP_KERNEL);
> - if (!serio) {
> - err = -ENOMEM;
> - goto irq;
> - }
> + if (!serio)
> + return -ENOMEM;
>
> priv->serio = serio;
>
> @@ -167,10 +164,6 @@ static int ams_delta_serio_init(struct platform_device *pdev)
> dev_info(&serio->dev, "%s\n", serio->name);
>
> return 0;
> -
> -irq:
> - free_irq(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK), priv);
> - return err;
> }
>
> static int ams_delta_serio_exit(struct platform_device *pdev)
> @@ -178,7 +171,6 @@ static int ams_delta_serio_exit(struct platform_device *pdev)
> struct ams_delta_serio *priv = platform_get_drvdata(pdev);
>
> serio_unregister_port(priv->serio);
> - free_irq(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK), 0);
>
> return 0;
> }
> --
> 2.16.1
>
--
Dmitry
^ permalink raw reply
* [PATCH 04/10] Input: ams_delta_serio: Replace power GPIO with regulator
From: Dmitry Torokhov @ 2018-06-12 22:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180609140224.32606-4-jmkrzyszt@gmail.com>
On Sat, Jun 09, 2018 at 04:02:18PM +0200, Janusz Krzysztofik wrote:
> Modify the driver so it no longer requests and manipulates the
> "keybrd_pwr" GPIO pin but a "vcc" regulator supply instead.
>
> For this to work with Amstrad Delta, define a regulator over the
> "keybrd_pwr" GPIO pin with the "vcc" supply for ams-delta-serio device
> and register it from the board file. Both assign an absulute GPIO
> number to the soon depreciated .gpio member of the regulator config
> structure, and also build and register a GPIO lookup table so it is
> ready for use by the regulator driver as soon as its upcoming update
> is applied.
>
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
> ---
> arch/arm/mach-omap1/board-ams-delta.c | 63 +++++++++++++++++++++++++++++++++--
> drivers/input/serio/ams_delta_serio.c | 27 ++++++++++-----
> 2 files changed, 79 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
> index 2119d2d3ba84..706eb2f9301d 100644
> --- a/arch/arm/mach-omap1/board-ams-delta.c
> +++ b/arch/arm/mach-omap1/board-ams-delta.c
> @@ -509,6 +509,46 @@ static struct platform_device ams_delta_serio_device = {
> .id = PLATFORM_DEVID_NONE,
> };
>
> +static struct regulator_consumer_supply keybrd_pwr_consumers[] = {
> + /*
> + * Initialize supply .dev_name with NULL. It will be replaced
> + * with serio dev_name() as soon as the serio device is registered.
> + */
> + REGULATOR_SUPPLY("vcc", NULL),
> +};
> +
> +static struct regulator_init_data keybrd_pwr_initdata = {
> + .constraints = {
> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> + },
> + .num_consumer_supplies = ARRAY_SIZE(keybrd_pwr_consumers),
> + .consumer_supplies = keybrd_pwr_consumers,
> +};
> +
> +static struct fixed_voltage_config keybrd_pwr_config = {
> + .supply_name = "keybrd_pwr",
> + .microvolts = 5000000,
> + .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
> + .enable_high = 1,
> + .init_data = &keybrd_pwr_initdata,
> +};
> +
> +static struct platform_device keybrd_pwr_device = {
> + .name = "reg-fixed-voltage",
> + .id = PLATFORM_DEVID_AUTO,
> + .dev = {
> + .platform_data = &keybrd_pwr_config,
> + },
> +};
> +
> +static struct gpiod_lookup_table keybrd_pwr_gpio_table = {
> + .table = {
> + GPIO_LOOKUP(LATCH2_LABEL, LATCH2_PIN_KEYBRD_PWR, NULL,
> + GPIO_ACTIVE_HIGH),
> + { },
> + },
> +};
> +
> static struct platform_device *ams_delta_devices[] __initdata = {
> &latch1_gpio_device,
> &latch2_gpio_device,
> @@ -526,6 +566,7 @@ static struct platform_device *late_devices[] __initdata = {
>
> static struct gpiod_lookup_table *ams_delta_gpio_tables[] __initdata = {
> &ams_delta_audio_gpio_table,
> + &keybrd_pwr_gpio_table,
> };
>
> static struct gpiod_lookup_table *late_gpio_tables[] __initdata = {
> @@ -566,12 +607,30 @@ static void __init ams_delta_init(void)
> platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
>
> /*
> - * As soon as devices have been registered, assign their dev_names
> - * to respective GPIO lookup tables before they are added.
> + * As soon as regulator consumers have been registered, assign their
> + * dev_names to consumer supply entries of respective regulators.
> + */
> + keybrd_pwr_consumers[0].dev_name =
> + dev_name(&ams_delta_serio_device.dev);
> +
> + /*
> + * Once consumer supply entries are populated with dev_names,
> + * register regulator devices. At this stage only the keyboard
> + * power regulator has its consumer supply table fully populated.
> + */
> + platform_device_register(&keybrd_pwr_device);
> +
> + /*
> + * As soon as GPIO consumers have been registered, assign
> + * their dev_names to respective GPIO lookup tables.
> */
> ams_delta_audio_gpio_table.dev_id =
> dev_name(&ams_delta_audio_device.dev);
> + keybrd_pwr_gpio_table.dev_id = dev_name(&keybrd_pwr_device.dev);
>
> + /*
> + * Once GPIO lookup tables are populated with dev_names, register them.
> + */
> gpiod_add_lookup_tables(ams_delta_gpio_tables,
> ARRAY_SIZE(ams_delta_gpio_tables));
>
> diff --git a/drivers/input/serio/ams_delta_serio.c b/drivers/input/serio/ams_delta_serio.c
> index 551a4fa73fe4..d48beab1d00d 100644
> --- a/drivers/input/serio/ams_delta_serio.c
> +++ b/drivers/input/serio/ams_delta_serio.c
> @@ -23,6 +23,7 @@
> #include <linux/gpio.h>
> #include <linux/irq.h>
> #include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
> #include <linux/serio.h>
> #include <linux/slab.h>
> #include <linux/module.h>
> @@ -39,6 +40,7 @@ MODULE_LICENSE("GPL");
>
> struct ams_delta_serio {
> struct serio *serio;
> + struct regulator *vcc;
> };
>
> static int check_data(struct serio *serio, int data)
> @@ -94,16 +96,18 @@ static irqreturn_t ams_delta_serio_interrupt(int irq, void *dev_id)
>
> static int ams_delta_serio_open(struct serio *serio)
> {
> - /* enable keyboard */
> - gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 1);
> + struct ams_delta_serio *priv = serio->port_data;
>
> - return 0;
> + /* enable keyboard */
> + return regulator_enable(priv->vcc);
> }
>
> static void ams_delta_serio_close(struct serio *serio)
> {
> + struct ams_delta_serio *priv = serio->port_data;
> +
> /* disable keyboard */
> - gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
> + regulator_disable(priv->vcc);
> }
>
> static const struct gpio ams_delta_gpios[] __initconst_or_module = {
> @@ -117,11 +121,6 @@ static const struct gpio ams_delta_gpios[] __initconst_or_module = {
> .flags = GPIOF_DIR_IN,
> .label = "serio-clock",
> },
> - {
> - .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
> - .flags = GPIOF_OUT_INIT_LOW,
> - .label = "serio-power",
> - },
> {
> .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT,
> .flags = GPIOF_OUT_INIT_LOW,
> @@ -146,6 +145,16 @@ static int ams_delta_serio_init(struct platform_device *pdev)
> goto serio;
> }
>
> + priv->vcc = devm_regulator_get(&pdev->dev, "vcc");
> + if (IS_ERR(priv->vcc)) {
> + err = PTR_ERR(priv->vcc);
> + dev_err(&pdev->dev, "regulator request failed (%d)\n", err);
> + /* Fail softly if the regulator is not available yet */
> + if (err == -ENODEV)
> + err = -EPROBE_DEFER;
Hmm, if regulator is not ready yet, devm_regulator_get() should be
returning -EPROBE_DEFER already, we should not have to convert -ENODEV
to -EPROBE_DEFER...
Is it because we have_full_constraints() returns false? You might need
to add call to regulator_has_full_constraints() to your board file.
> + goto gpio;
> + }
> +
> err = request_irq(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK),
> ams_delta_serio_interrupt, IRQ_TYPE_EDGE_RISING,
> DRIVER_NAME, priv);
> --
> 2.16.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH 1/2] ASoC: pxa: add binding for pxa2xx-ac97 audio complex
From: Rob Herring @ 2018-06-12 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611202211.15501-1-robert.jarzmik@free.fr>
On Mon, Jun 11, 2018 at 10:22:10PM +0200, Robert Jarzmik wrote:
> This adds a binding for the Marvell PXA audio complex, available in
> pxa2xx and pxa3xx variants.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> .../bindings/sound/marvell,pxa2xx-ac97.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt b/Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt
> new file mode 100644
> index 000000000000..b3f2882d9c7d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt
> @@ -0,0 +1,25 @@
> +Marvell PXA2xx audio complex
> +
> +This descriptions matches the AC97 controller found in pxa2xx and pxa3xx series.
> +
> +Required properties:
> + - compatible: "marvell,pxa2xx-ac97"
Don't use wildcards in compatible strings. Though this is so old...
> + - reg: device MMIO address space
> + - interrupts: single interrupt generated by AC97 IP
> + - clocks: input clock of the AC97 IP, refer to clock-bindings.txt
> +
> +Optional properties:
> + - pinctrl-names, pinctrl-0: refer to pinctrl-bindings.txt
> + - reset-gpio: gpio used for AC97 reset, refer to gpio.txt
reset-gpios
> +
> +Example:
> + ac97: sound at 40500000 {
> + compatible = "marvell,pxa2xx-ac97";
> + reg = < 0x40500000 0x1000 >;
> + interrupts = <14>;
> + reset-gpio = <&gpio 113 GPIO_ACTIVE_HIGH>;
> + #sound-dai-cells = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = < &pmux_ac97_default >;
> + status = "okay";
Don't show status in examples.
> + };
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC PATCH 1/3] Documentation: dt: keystone: ti-sci: Add optional host-id parameter
From: Nishanth Menon @ 2018-06-12 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612213922.GA26791@rob-hp-laptop>
On 21:39-20180612, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 01:26:38AM -0500, Nishanth Menon wrote:
> > Texas Instrument's System Control Interface (TISCI) permits the
> > ability for Operating Systems to running in virtual machines to be
>
> ...for OSs running in virtual...
Ack. thanks.
>
> > able to independently communicate with the firmware without the need
> > going through an hypervisor.
> >
> > The "host-id" in effect is the hardware representation of the
> > host (example: VMs locked to a core) as identified to the System
> > Controller.
>
> So the hypervisor will fill in host-id's for each VM instance?
Yes OR have it's own device tree blobs representation of it's own host
IDs assigned by system firmware. This provides complete independence of
VMs to communicate with the system controller (once the host-id is
provided) without switching to hyp for arbitration (and yes, verified
ability with jailhouse hypervisor and multiple linux instances operating
simultaneously). This also has the added benefit of:
1. The burden of hypervisor from being involved in PM functionality as each
of the VMs can operate autonomously.
2. In TI SoCs which are heterogeneous, the system firmware plays the role
of system master communicating with multiple firmware(running on various
uCs) and OSes running on bigger cores.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [RFC PATCH 5/8] dt-bindings: mailbox: ti,message-manager: Add support for secure proxy threads
From: Nishanth Menon @ 2018-06-12 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612211128.GA22038@rob-hp-laptop>
On 21:11-20180612, Rob Herring wrote:
[...]
> > diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> > index ebf0e3710cee..de796e90cac6 100644
> > --- a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> > +++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> > @@ -7,22 +7,40 @@ manager is broken up into queues in different address regions that are called
> > "proxies" - each instance is unidirectional and is instantiated at SoC
> > integration level to indicate receive or transmit path.
> >
> > +This can also be used to describe Texas Instrument's Secure Proxy
> > +controller that allows for individually configurable "threads" or
> > +"proxies" which allow for independent communication scheme.
>
> There seems to be very little re-use here. I think I would make this
> its own doc.
Agreed. will do the same in the formal series. Thanks.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
From: Nishanth Menon @ 2018-06-12 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612210640.GA20728@rob-hp-laptop>
On 21:06-20180612, Rob Herring wrote:
> > diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
> > index 4b0f05adb228..c35d5ece1156 100644
> > --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
> > +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
> > @@ -1,6 +1,7 @@
> > OMAP UART controller
> >
> > Required properties:
> > +- compatible : should be "ti,am654-uart" for AM654 controllers
>
> Not compatible with any existing TI 8250 UARTs?
Base is compatible, however there are differences in DMA operation and
few additional bits. omap4-uart is sufficient for a basic PIO mode of
operation given initialization a bootloader might do for base console.
I will split the bindings off into it's own patch to keep the confusion
to a minimum and allowing serial driver change to go in independently.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC
From: Nishanth Menon @ 2018-06-12 22:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612210519.GA17653@rob-hp-laptop>
On 21:05-20180612, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 01:01:20AM -0500, Nishanth Menon wrote:
[...]
> > +Boards based on K3 Multicore SoC architecture shall have the following property:
> > +- compatible: Every hardware block introduced in K3 Multicore SoC
> > + architecture shall be of the form:
> > + "ti,XXX-YYY", where:
> > + 'XXX' represents the specific SoC part for which the support is added.
> > + 'YYY' represents the corresponding peripheral in SoC being supported.
>
> No need to explain standard DT convention here. (But I don't think we
> have this convention documented anywhere, so patches welcome. :))
>
Thanks. Will drop off from my series (will skip the generic dts
convention for now ;) ).
--
Regards,
Nishanth Menon
^ permalink raw reply
* [U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715
From: Nishanth Menon @ 2018-06-12 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612214049.GA17671@n2100.armlinux.org.uk>
On 21:40-20180612, Russell King - ARM Linux wrote:
[...]
> > I started respinning the series, while there is definitely a use of
> > implementing in u-boot,
> > I am starting to wonder if we should also be doing this in kernel.
>
> How does the kernel set the bit when the kernel is running in non-secure
> mode, when the ACTLR is read-only in that mode?
For OMAP5/DRA7 SMP systems, I just posted a patch that seems to resolve
it:
https://patchwork.kernel.org/patch/10461273/
This'd be similar in implementation to ARM erratum 801819 workaround
that needs two pieces (u-boot + kernel). I am not really worried about
OMAP5/DRA7 since they should'nt loose context in Low power modes.
Other SoCs need to be aware of the constraints.
/me wishes PSCI was a standard during ARMv7, but it was'nt... So
legacy v7 SoCs have implementations that are kind of different (even
smc calling conventions vary).
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 2/4] dt-bindings: clk: at91: Document all the PMC compatibles
From: Rob Herring @ 2018-06-12 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607084107.4461-3-alexandre.belloni@bootlin.com>
On Thu, Jun 07, 2018 at 10:41:05AM +0200, Alexandre Belloni wrote:
> Add missing PMC compatibles to the list of available compatibles.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> Documentation/devicetree/bindings/clock/at91-clock.txt | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/4] dt-bindings: arm: remove PMC bindings
From: Rob Herring @ 2018-06-12 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607084107.4461-2-alexandre.belloni@bootlin.com>
On Thu, Jun 07, 2018 at 10:41:04AM +0200, Alexandre Belloni wrote:
> The PMC bindings are fully described in
> Documentation/devicetree/bindings/clock/at91-clock.txt. Remove the
> duplicate and incomplete documentation.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> .../devicetree/bindings/arm/atmel-pmc.txt | 14 --------------
> 1 file changed, 14 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/atmel-pmc.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715
From: Russell King - ARM Linux @ 2018-06-12 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGo_u6qyf1Z+zSG-17TYRDPzG8V_0_-nk1F15HB4tPyT9rbUYQ@mail.gmail.com>
On Tue, Jun 12, 2018 at 02:13:38PM -0500, Nishanth Menon wrote:
> On Tue, May 22, 2018 at 9:05 AM, Fabio Estevam <festevam@gmail.com> wrote:
> > On Thu, Jan 25, 2018 at 7:45 PM, Nishanth Menon <nm@ti.com> wrote:
> >> Hi Folks,
> >>
> >> This is a follow through on the discussion we have had in [1].
> >> This itself is'nt a complete solution and is based on recommendation
> >> This from Arm[2] for variant 2 CVE-2017-5715
> >>
> >> The Linux kernel discussions are spread out in [3], ATF and OPTEE
> >> status are available in [4].
> >>
> >> This is just an RFC series (build tested at this point) to check if
> >> the direction is fine and should follow the final solution once kernel
> >> patches get to upstream, IMHO.
> >>
> >> NOTE: As per ARM recommendations[2], and discussions in list[1] ARM
> >> Cortex-A9/12/17 do not need additional steps in u-boot to enable the
> >> OS level workarounds.
> >>
> >> Nishanth Menon (2):
> >> ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for
> >> CVE-2017-5715
> >> ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for
> >> CVE-2017-5715
> >
>
> I started respinning the series, while there is definitely a use of
> implementing in u-boot,
> I am starting to wonder if we should also be doing this in kernel.
How does the kernel set the bit when the kernel is running in non-secure
mode, when the ACTLR is read-only in that mode?
--
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
* [RFC PATCH 1/3] Documentation: dt: keystone: ti-sci: Add optional host-id parameter
From: Rob Herring @ 2018-06-12 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605062640.3356-2-nm@ti.com>
On Tue, Jun 05, 2018 at 01:26:38AM -0500, Nishanth Menon wrote:
> Texas Instrument's System Control Interface (TISCI) permits the
> ability for Operating Systems to running in virtual machines to be
...for OSs running in virtual...
> able to independently communicate with the firmware without the need
> going through an hypervisor.
>
> The "host-id" in effect is the hardware representation of the
> host (example: VMs locked to a core) as identified to the System
> Controller.
So the hypervisor will fill in host-id's for each VM instance?
>
> This is introduced as an optional parameter to maintain consistency
> with legacy device tree blobs.
>
> We call this with a vendor prefix to prevent any possible confusion
> with SCSI ID (m68k) kernel option.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> Documentation/devicetree/bindings/arm/keystone/ti,sci.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> index 31f5f9a104cc..b56a02c10ae6 100644
> --- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> @@ -45,11 +45,15 @@ Optional Properties:
> debug_messages - Map the Debug message region
> - reg: register space corresponding to the debug_messages
> - ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
> +- ti,host-id: Integer value corresponding to the host ID assigned by Firmware
> + for identification of host processing entities such as virtual
> + machines
>
> Example (K2G):
> -------------
> pmmc: pmmc {
> compatible = "ti,k2g-sci";
> + ti,host-id = <2>;
> mbox-names = "rx", "tx";
> mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>,
> <&msgmgr &msgmgr_proxy_pmmc_tx>;
> --
> 2.15.1
>
^ permalink raw reply
* [PATCH] ARM: DRA7/OMAP5: Enable ACTLR[0] (Enable invalidates of BTB) for secondary cores
From: Nishanth Menon @ 2018-06-12 21:36 UTC (permalink / raw)
To: linux-arm-kernel
Call secure services to enable ACTLR[0] (Enable invalidates of BTB with
ICIALLU) when branch hardening is enabled for kernel.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Based on: next-20180612 +
Uboot series posted: https://marc.info/?l=u-boot&m=152883522011042&w=2
With Just u-boot changes alone: OMAP5-uevm: https://pastebin.ubuntu.com/p/9yDM22bJ6n/
with kernel changes added on: https://pastebin.ubuntu.com/p/gXPBGGYRPX/
arch/arm/mach-omap2/omap-smp.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 69df3620eca5..28fc80ea675b 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -109,6 +109,32 @@ void omap5_erratum_workaround_801819(void)
static inline void omap5_erratum_workaround_801819(void) { }
#endif
+#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
+static void omap5_harden_predictor(void)
+{
+ u32 acr, acr_mask;
+
+ asm volatile ("mrc p15, 0, %0, c1, c0, 1" : "=r" (acr));
+
+ /*
+ * BIT(0) - Disables streaming. All write-allocate lines allocate in
+ */
+ acr_mask = BIT(0);
+
+ /* do we already have it done.. if yes, skip expensive smc */
+ if ((acr & acr_mask) == acr_mask)
+ return;
+
+ acr |= acr_mask;
+ omap_smc1(OMAP5_DRA7_MON_SET_ACR_INDEX, acr);
+
+ pr_debug("%s: ARM ACR setup for CVE_2017_5715 applied on CPU%d\n",
+ __func__, smp_processor_id());
+}
+#else
+static inline void omap5_harden_predictor(void) { }
+#endif
+
static void omap4_secondary_init(unsigned int cpu)
{
/*
@@ -131,6 +157,8 @@ static void omap4_secondary_init(unsigned int cpu)
set_cntfreq();
/* Configure ACR to disable streaming WA for 801819 */
omap5_erratum_workaround_801819();
+ /* Enable ACR to allow for ICUALLU workaround */
+ omap5_harden_predictor();
}
/*
--
2.15.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox