* Re: [GIT PULL] ARM: SoC fixes for -rc8
From: pr-tracker-bot @ 2019-09-06 20:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Lee Jones, Linux Kernel Mailing List,
SoC Team, Simon Horman, Andy Gross, Linus Torvalds, Linux ARM
In-Reply-To: <CAK8P3a0MsTFjqChoz+DLSC8nVnBuvqQdYx6V0SuCybg7MZ79mQ@mail.gmail.com>
The pull request you sent on Fri, 6 Sep 2019 21:48:09 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/armsoc-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/36daa831b55538dc2e4a906de20c5d91033ebb21
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] bus: ti-sysc: Remove unpaired sysc_clkdm_deny_idle()
From: Tony Lindgren @ 2019-09-06 20:01 UTC (permalink / raw)
To: linux-omap
Cc: Nishanth Menon, Tero Kristo, Vignesh Raghavendra, Dave Gerlach,
Keerthy, linux-kernel, Andrew F . Davis, Peter Ujfalusi,
Faiz Abbas, Greg Kroah-Hartman, linux-arm-kernel, Roger Quadros
Commit d098913a10f8 ("bus: ti-sysc: Fix clock handling for no-idle
quirks") fixed handling for no-idle quirk modules that are not enabled
by the bootloader.
But it also caused unpaired clockdomain calls that won't allow idling
the system. That's because clkdm_allow_idle_nolock() and
clkdm_deny_idle_nolock() have usage count with clkdm->forcewake_count.
Let's drop the unpaired sysc_clkdm_deny_idle() to fix idling of devices.
Fixes: d098913a10f8 ("bus: ti-sysc: Fix clock handling for no-idle quirks")
Cc: Keerthy <j-keerthy@ti.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/bus/ti-sysc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -2363,7 +2363,6 @@ static void ti_sysc_idle(struct work_struct *work)
*/
if (ddata->cfg.quirks & (SYSC_QUIRK_NO_IDLE |
SYSC_QUIRK_NO_IDLE_ON_INIT)) {
- sysc_clkdm_deny_idle(ddata);
sysc_disable_main_clocks(ddata);
sysc_disable_opt_clocks(ddata);
sysc_clkdm_allow_idle(ddata);
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv4 01/10] dt-bindings: omap: add new binding for PRM instances
From: Tero Kristo @ 2019-09-06 20:02 UTC (permalink / raw)
To: Tony Lindgren, Rob Herring
Cc: devicetree, linux-omap, Philipp Zabel, Santosh Shilimkar,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190906153658.GB52127@atomide.com>
On 06/09/2019 18:36, Tony Lindgren wrote:
> * Rob Herring <robh+dt@kernel.org> [190906 12:57]:
>> On Fri, Sep 6, 2019 at 11:36 AM Tero Kristo <t-kristo@ti.com> wrote:
>>>
>>> Add new binding for OMAP PRM (Power and Reset Manager) instances. Each
>>> of these will act as a power domain controller and potentially as a reset
>>> provider.
>>>
>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>> ---
>>> v4:
>>> - renamed nodes as power-controller
>>> - added documentation about hierarchy
>>>
>>> .../devicetree/bindings/arm/omap/prm-inst.txt | 31 +++++++++++++++++++
>>> 1 file changed, 31 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>
>> Reviewed-by: Rob Herring <robh@kernel.org>
>
> Looks good to me too:
>
> Reviewed-by: Tony Lindgren <tony@atomide.com>
>
I may need to re-spin slightly new version of this. Stephen has some
comments on the clock driver side I am depending on, he does not like
the hard link between reset + clocks, so I may need to ditch the
"clocks" property from this one also.
I'll see next week which direction I need to go.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 3/4] dt-bindings: Add Qualcomm USB SuperSpeed PHY bindings
From: Stephen Boyd @ 2019-09-06 20:40 UTC (permalink / raw)
To: Bjorn Andersson
Cc: mark.rutland, robh, Jack Pham, devicetree, gregkh, linux-usb,
khasim.mohammed, linux-kernel, kishon, linux-arm-msm, andy.gross,
Jorge Ramirez, shawn.guo, linux-arm-kernel
In-Reply-To: <20190906182530.GD11938@tuxbook-pro>
Quoting Bjorn Andersson (2019-09-06 11:25:30)
> On Thu 05 Sep 22:26 PDT 2019, Stephen Boyd wrote:
>
> >
> > Yes this looks like the approach that should be taken. One question
> > though, is this a micro-b connector or a type-c connector on the board?
> > I thought it was a type-c, so then this USB gpio based connection driver
> > isn't an exact fit?
> >
>
> For this particular case it's a type c connector, but the port
> controller is operated completely passively (and there's no PD or DP
> involved), so the GPIO based approach seems like a good fit.
>
OK. Perhaps the binding needs an update then to have another compatible
string indicating type-c connector that's not able to support PD or DP?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] gpio/mpc8xxx: change irq handler from chained to normal
From: Li Yang @ 2019-09-06 21:46 UTC (permalink / raw)
To: Hui Song
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-gpio, Linus Walleij, lkml, Bartosz Golaszewski, Rob Herring,
Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190906115614.5645-1-hui.song_1@nxp.com>
On Fri, Sep 6, 2019 at 10:20 AM Hui Song <hui.song_1@nxp.com> wrote:
>
> From: Song Hui <hui.song_1@nxp.com>
>
The English below need to be fixed.
> more one gpio controller use share one interrupt,
> make request interrupt to be shared.
More than one gpio controllers can share one interrupt, change the
driver to request shared irq.
>
> Signed-off-by: Laurentiu Tudor <Laurentiu.Tudor@nxp.com>
> Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
> Signed-off-by: Song Hui <hui.song_1@nxp.com>
> ---
> drivers/gpio/gpio-mpc8xxx.c | 20 +++++++++++++-------
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
> index 16a47de..4006250 100644
> --- a/drivers/gpio/gpio-mpc8xxx.c
> +++ b/drivers/gpio/gpio-mpc8xxx.c
> @@ -22,6 +22,7 @@
> #include <linux/irq.h>
> #include <linux/gpio/driver.h>
> #include <linux/bitops.h>
> +#include <linux/interrupt.h>
>
> #define MPC8XXX_GPIO_PINS 32
>
> @@ -127,10 +128,9 @@ static int mpc8xxx_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
> return -ENXIO;
> }
>
> -static void mpc8xxx_gpio_irq_cascade(struct irq_desc *desc)
> +static irqreturn_t mpc8xxx_gpio_irq_cascade(int irq, void *data)
> {
> - struct mpc8xxx_gpio_chip *mpc8xxx_gc = irq_desc_get_handler_data(desc);
> - struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct mpc8xxx_gpio_chip *mpc8xxx_gc = (struct mpc8xxx_gpio_chip *)data;
> struct gpio_chip *gc = &mpc8xxx_gc->gc;
> unsigned int mask;
>
> @@ -139,8 +139,8 @@ static void mpc8xxx_gpio_irq_cascade(struct irq_desc *desc)
> if (mask)
> generic_handle_irq(irq_linear_revmap(mpc8xxx_gc->irq,
> 32 - ffs(mask)));
> - if (chip->irq_eoi)
> - chip->irq_eoi(&desc->irq_data);
> +
> + return IRQ_HANDLED;
> }
>
> static void mpc8xxx_irq_unmask(struct irq_data *d)
> @@ -409,8 +409,14 @@ static int mpc8xxx_probe(struct platform_device *pdev)
> if (devtype->gpio_dir_in_init)
> devtype->gpio_dir_in_init(gc);
>
> - irq_set_chained_handler_and_data(mpc8xxx_gc->irqn,
> - mpc8xxx_gpio_irq_cascade, mpc8xxx_gc);
> + ret = request_irq(mpc8xxx_gc->irqn, mpc8xxx_gpio_irq_cascade,
> + IRQF_NO_THREAD | IRQF_SHARED, "gpio-cascade", mpc8xxx_gc);
> + if (ret) {
> + pr_err("%s: failed to request_irq(%d), ret = %d\n",
> + np->full_name, mpc8xxx_gc->irqn, ret);
> + goto err;
> + }
> +
> return 0;
> err:
> iounmap(mpc8xxx_gc->regs);
> --
> 2.9.5
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] clk: Add support for AST2600 SoC
From: Stephen Boyd @ 2019-09-06 22:03 UTC (permalink / raw)
To: Joel Stanley
Cc: Ryan Chen, linux-aspeed, Andrew Jeffery, Michael Turquette,
Linux Kernel Mailing List, Rob Herring, linux-clk, Linux ARM
In-Reply-To: <CACPK8Xf3C36KMgDmmRtNFqVFHzZx81ko+=54PA4+d5xPitum3g@mail.gmail.com>
Quoting Joel Stanley (2019-08-18 19:03:54)
> On Fri, 16 Aug 2019 at 17:14, Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > Quoting Joel Stanley (2019-08-16 08:58:06)
> > > +static const char * const vclk_parent_names[] = {
> >
> > Can you use the new way of specifying clk parents instead of just using
> > strings?
>
> How does this work? I had a browse of the APIs in clk-provider.h and
> it appeared the functions all take char *s still.
Sorry I didn't reply earlier. I'm going to write a kernel-doc to
describe how to write a "modern" clk driver which should hopefully help
here.
The gist is that you can fill out a clk_parent_data array or a clk_hw
array and set the .name and .fw_name and .index in the clk_parent_data
array to indicate which clks to get from the DT node's "clocks" and
"clock-names" properties.
>
> > > + hw = clk_hw_register_fixed_factor(NULL, "ahb", "hpll", 0, 1, axi_div * ahb_div);
Take this one for example. If 'hpll' is actually a clk_hw pointer in
hand, then you could do something like:
clk_hw_register_fixed_factor_parent_hw(NULL, "ahb", &hpll, 0, 1, axi_div * ahb_div);
And if it's something like a clock from DT you could do
struct clk_parent_data pdata = {
.name = "hpll",
.fw_name = <clock-names string>,
.index = <whatever clock index it is>
};
clk_hw_register_fixed_factor_parent_data(NULL, "ahb", &pdata, 0, 1, axi_div * ahb_div);
I haven't actually written the clk_hw_register_fixed_factor_*() APIs,
because I'm thinking that it would be better to register the pdata with
some more parameters so that the
clk_hw_register_fixed_factor_parent_data() API becomes more like:
clk_hw_register_fixed_factor_parent_data(NULL, "ahb", "hpll",
<clock-names string>, <whatever clock index it is>, 0, 1,
axi_div * ahb_div);
Because there's only one parent. For the mux clk it will be a pointer to
parent_data because I don't see a way around it.
> >
> > There aren't checks for if these things fail. I guess it doesn't matter
> > and just let it fail hard?
>
> I think that's sensible here. If the system has run out of memory this
> early on then there's not going to be much that works.
>
> Thanks for the review. I've fixed all of the style issues you
> mentioned, but would appreciate some guidance on the parent API.
>
Cool! Thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] clk: aspeed: Move structures to header
From: Stephen Boyd @ 2019-09-06 22:23 UTC (permalink / raw)
To: Joel Stanley, Michael Turquette
Cc: linux-aspeed, Andrew Jeffery, linux-kernel, Rob Herring,
linux-clk, linux-arm-kernel
In-Reply-To: <20190825141848.17346-2-joel@jms.id.au>
Quoting Joel Stanley (2019-08-25 07:18:47)
> They will be reused by the ast2600 driver.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] clk: Add support for AST2600 SoC
From: Stephen Boyd @ 2019-09-06 22:23 UTC (permalink / raw)
To: Joel Stanley, Michael Turquette
Cc: linux-aspeed, Andrew Jeffery, linux-kernel, Rob Herring,
linux-clk, linux-arm-kernel
In-Reply-To: <20190825141848.17346-3-joel@jms.id.au>
Quoting Joel Stanley (2019-08-25 07:18:48)
> The ast2600 is a new BMC SoC from ASPEED. It contains many more clocks
> than the previous iterations, so support is broken out into it's own
> driver.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 11/16] ARM: mmp: add support for MMP3 SoC
From: Stephen Boyd @ 2019-09-06 23:48 UTC (permalink / raw)
To: To : Olof Johansson, Lubomir Rintel
Cc: Mark Rutland, devicetree, Jason Cooper, linux-kernel,
Michael Turquette, Russell King, Kishon Vijay Abraham I,
Lubomir Rintel, Cc : Rob Herring, Thomas Gleixner, linux-clk,
linux-arm-kernel
In-Reply-To: <20190830220743.439670-12-lkundrak@v3.sk>
Quoting Lubomir Rintel (2019-08-30 15:07:38)
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 801fa1cd03217..8bb2ac83a1fcc 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -301,6 +301,11 @@ config COMMON_CLK_STM32H7
> ---help---
> Support for stm32h7 SoC family clocks
>
> +config COMMON_CLK_MMP2
> + def_bool COMMON_CLK && (MACH_MMP2_DT || MACH_MMP3_DT)
Does it need to depend on COMMON_CLK? I thought that by being part of
the menuconfig (even if it's a hidden symbol) mean that it wouldn't be
evaulated unless the COMMON_CLK define is =Y.
> + help
> + Support for Marvell MMP2 and MMP3 SoC clocks
> +
> config COMMON_CLK_BD718XX
> tristate "Clock driver for ROHM BD718x7 PMIC"
> depends on MFD_ROHM_BD718XX || MFD_ROHM_BD70528
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC][PATCH v1 0/1] Add support for arm64 to carry ima measurement log in kexec_file_load
From: Prakhar Srivastava @ 2019-09-06 23:51 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: mark.rutland, jean-philippe, arnd, takahiro.akashi, sboyd,
catalin.marinas, yamada.masahiro, kristina.martsenko, duwe,
bauerman, james.morse, tglx, allison
Add support for arm64 to carry ima measurement log
to the next kexec'ed session triggered via kexec_file_load.
- Top of Linux 5.3-rc6
Currently during kexec the kernel file signatures are/can be validated
prior to actual load, the information(PE/ima signature) is not carried
to the next session. This lead to loss of information.
Carrying forward the ima measurement log to the next kexec'ed session.
This allows a verifying party to get the entire runtime event log since
the last full reboot since that is when PCRs were last reset.
Prakhar Srivastava (1):
Add support for arm64 to carry ima measurement log in kexec_file_load
arch/arm64/Kconfig | 7 +
arch/arm64/include/asm/ima.h | 29 ++++
arch/arm64/include/asm/kexec.h | 5 +
arch/arm64/kernel/Makefile | 3 +-
arch/arm64/kernel/ima_kexec.c | 213 +++++++++++++++++++++++++
arch/arm64/kernel/machine_kexec_file.c | 6 +
6 files changed, 262 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/include/asm/ima.h
create mode 100644 arch/arm64/kernel/ima_kexec.c
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC][PATCH v1 1/1] Add support for arm64 to carry ima measurement log in kexec_file_load
From: Prakhar Srivastava @ 2019-09-06 23:51 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: mark.rutland, jean-philippe, arnd, takahiro.akashi, sboyd,
catalin.marinas, yamada.masahiro, kristina.martsenko, duwe,
bauerman, james.morse, tglx, allison
In-Reply-To: <20190906235110.15566-1-prsriva@linux.microsoft.com>
During kexec_file_load, carrying forward the ima measurement log allows
a verifying party to get the entire runtime event log since the last
full reboot since that is when PCRs were last reset.
Signed-off-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
---
arch/arm64/Kconfig | 7 +
arch/arm64/include/asm/ima.h | 29 ++++
arch/arm64/include/asm/kexec.h | 5 +
arch/arm64/kernel/Makefile | 3 +-
arch/arm64/kernel/ima_kexec.c | 213 +++++++++++++++++++++++++
arch/arm64/kernel/machine_kexec_file.c | 6 +
6 files changed, 262 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/include/asm/ima.h
create mode 100644 arch/arm64/kernel/ima_kexec.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3adcec05b1f6..f39b12dbf9e8 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -976,6 +976,13 @@ config KEXEC_VERIFY_SIG
verification for the corresponding kernel image type being
loaded in order for this to work.
+config HAVE_IMA_KEXEC
+ bool "Carry over IMA measurement log during kexec_file_load() syscall"
+ depends on KEXEC_FILE
+ help
+ Select this option to carry over IMA measurement log during
+ kexec_file_load.
+
config KEXEC_IMAGE_VERIFY_SIG
bool "Enable Image signature verification support"
default y
diff --git a/arch/arm64/include/asm/ima.h b/arch/arm64/include/asm/ima.h
new file mode 100644
index 000000000000..e23cee84729f
--- /dev/null
+++ b/arch/arm64/include/asm/ima.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_ARM64_IMA_H
+#define _ASM_ARM64_IMA_H
+
+struct kimage;
+
+int ima_get_kexec_buffer(void **addr, size_t *size);
+int ima_free_kexec_buffer(void);
+
+#ifdef CONFIG_IMA
+void remove_ima_buffer(void *fdt, int chosen_node);
+#else
+static inline void remove_ima_buffer(void *fdt, int chosen_node) {}
+#endif
+
+#ifdef CONFIG_IMA_KEXEC
+int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr,
+ size_t size);
+
+int setup_ima_buffer(const struct kimage *image, void *fdt, int chosen_node);
+#else
+static inline int setup_ima_buffer(const struct kimage *image, void *fdt,
+ int chosen_node)
+{
+ remove_ima_buffer(fdt, chosen_node);
+ return 0;
+}
+#endif /* CONFIG_IMA_KEXEC */
+#endif /* _ASM_ARM64_IMA_H */
diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index 12a561a54128..e8d2412066e7 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -96,6 +96,11 @@ static inline void crash_post_resume(void) {}
struct kimage_arch {
void *dtb;
unsigned long dtb_mem;
+
+#ifdef CONFIG_IMA_KEXEC
+ phys_addr_t ima_buffer_addr;
+ size_t ima_buffer_size;
+#endif
};
extern const struct kexec_file_ops kexec_image_ops;
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 478491f07b4f..580238f2e9a7 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -55,7 +55,8 @@ obj-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
obj-$(CONFIG_HIBERNATION) += hibernate.o hibernate-asm.o
obj-$(CONFIG_KEXEC_CORE) += machine_kexec.o relocate_kernel.o \
cpu-reset.o
-obj-$(CONFIG_KEXEC_FILE) += machine_kexec_file.o kexec_image.o
+obj-$(CONFIG_KEXEC_FILE) += machine_kexec_file.o kexec_image.o \
+ ima_kexec.o
obj-$(CONFIG_ARM64_RELOC_TEST) += arm64-reloc-test.o
arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
diff --git a/arch/arm64/kernel/ima_kexec.c b/arch/arm64/kernel/ima_kexec.c
new file mode 100644
index 000000000000..b14326d541f3
--- /dev/null
+++ b/arch/arm64/kernel/ima_kexec.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Microsoft Corporation.
+ *
+ * Authors:
+ * Prakhar Srivastava <prsriva@linux.microsoft.com>
+ */
+
+#include <linux/slab.h>
+#include <linux/kexec.h>
+#include <linux/of.h>
+#include <linux/memblock.h>
+#include <linux/libfdt.h>
+
+
+/**
+ * delete_fdt_mem_rsv - delete memory reservation with given address and size
+ * @fdt - pointer to the fdt.
+ * @start - start address of the memory.
+ * @size - number of cells to be deletd.
+ *
+ * Return: 0 on success, or negative errno on error.
+ */
+int delete_fdt_mem_rsv(void *fdt, unsigned long start, unsigned long size)
+{
+ int i, ret, num_rsvs = fdt_num_mem_rsv(fdt);
+
+ for (i = 0; i < num_rsvs; i++) {
+ uint64_t rsv_start, rsv_size;
+
+ ret = fdt_get_mem_rsv(fdt, i, &rsv_start, &rsv_size);
+ if (ret) {
+ pr_err("Malformed device tree\n");
+ return -EINVAL;
+ }
+
+ if (rsv_start == start && rsv_size == size) {
+ ret = fdt_del_mem_rsv(fdt, i);
+ if (ret) {
+ pr_err("Error deleting device tree reservation\n");
+ return -EINVAL;
+ }
+
+ return 0;
+ }
+ }
+
+ return -ENOENT;
+}
+
+/**
+ * remove_ima_buffer - remove the IMA buffer property and reservation
+ * @fdt - pointer the fdt.
+ * @chosen_node - node under which property can be found.
+ *
+ * The IMA measurement buffer is either read by now and freeed or a kexec call
+ * needs to replace the ima measurement buffer, clear the property and memory
+ * reservation.
+ */
+void remove_ima_buffer(void *fdt, int chosen_node)
+{
+ int ret, len;
+ const void *prop;
+ uint64_t tmp_start, tmp_end;
+
+ prop = fdt_getprop(fdt, chosen_node, "linux,ima-kexec-buffer", &len);
+ if (prop) {
+ tmp_start = fdt64_to_cpu(*((const fdt64_t *) prop));
+
+ prop = fdt_getprop(fdt, chosen_node,
+ "linux,ima-kexec-buffer-end", &len);
+ if (!prop)
+ return;
+
+ tmp_end = fdt64_to_cpu(*((const fdt64_t *) prop));
+
+ ret = delete_fdt_mem_rsv(fdt, tmp_start, tmp_end - tmp_start);
+
+ if (ret == 0)
+ pr_debug("Removed old IMA buffer reservation.\n");
+ else if (ret != -ENOENT)
+ return;
+
+ fdt_delprop(fdt, chosen_node, "linux,ima-kexec-buffer");
+ fdt_delprop(fdt, chosen_node, "linux,ima-kexec-buffer-end");
+ }
+}
+
+/**
+ * ima_get_kexec_buffer - get IMA buffer from the previous kernel
+ * @addr: On successful return, set to point to the buffer contents.
+ * @size: On successful return, set to the buffer size.
+ *
+ * Return: 0 on success, negative errno on error.
+ */
+int ima_get_kexec_buffer(void **addr, size_t *size)
+{
+ int len;
+ const void *prop;
+ uint64_t tmp_start, tmp_end;
+
+ prop = of_get_property(of_chosen, "linux,ima-kexec-buffer", &len);
+ if (!prop)
+ return -ENOENT;
+
+ tmp_start = fdt64_to_cpu(*((const fdt64_t *) prop));
+
+ prop = of_get_property(of_chosen, "linux,ima-kexec-buffer-end", &len);
+ if (!prop)
+ return -ENOENT;
+
+ tmp_end = fdt64_to_cpu(*((const fdt64_t *) prop));
+
+ *addr = __va(tmp_start);
+ *size = tmp_end - tmp_start;
+
+ return 0;
+}
+
+/**
+ * ima_free_kexec_buffer - free memory used by the IMA buffer
+ *
+ * Return: 0 on success, negative errno on error.
+ */
+int ima_free_kexec_buffer(void)
+{
+ int ret;
+ void *propStart, *propEnd;
+ uint64_t tmp_start, tmp_end;
+
+ propStart = of_find_property(of_chosen, "linux,ima-kexec-buffer",
+ NULL);
+ if (propStart) {
+ tmp_start = fdt64_to_cpu(*((const fdt64_t *) propStart));
+ ret = of_remove_property(of_chosen, propStart);
+ if (!ret) {
+ return ret;
+ }
+
+ propEnd = of_find_property(of_chosen,
+ "linux,ima-kexec-buffer-end", NULL);
+ if (!propEnd) {
+ return -EINVAL;
+ }
+
+ tmp_end = fdt64_to_cpu(*((const fdt64_t *) propEnd));
+
+ ret = of_remove_property(of_chosen, propEnd);
+ if (!ret) {
+ return ret;
+ }
+
+ return memblock_free(tmp_start, tmp_end - tmp_start);
+ }
+ return 0;
+}
+
+#ifdef CONFIG_IMA_KEXEC
+/**
+ * arch_ima_add_kexec_buffer - do arch-specific steps to add the IMA
+ * measurement log.
+ * @image: - pointer to the kimage, to store the address and size of the
+ * IMA measurement log.
+ * @load_addr: - the address where the IMA measurement log is stored.
+ * @size - size of the IMA measurement log.
+ *
+ * Return: 0 on success, negative errno on error.
+ */
+int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr,
+ size_t size)
+{
+ image->arch.ima_buffer_addr = load_addr;
+ image->arch.ima_buffer_size = size;
+ return 0;
+}
+
+/**
+ * setup_ima_buffer - update the fdt to contain the ima mesasurement log
+ * @image: - pointer to the kimage, containing the address and size of
+ * the IMA measurement log.
+ * @fdt: - pointer to the fdt.
+ * @chosen_node: - node under which property is to be defined.
+ *
+ * Return: 0 on success, negative errno on error.
+ */
+int setup_ima_buffer(const struct kimage *image, void *fdt, int chosen_node)
+{
+ int ret;
+
+ remove_ima_buffer(fdt, chosen_node);
+
+ if (!image->arch.ima_buffer_size)
+ return 0;
+
+ ret = fdt_setprop_u64(fdt, chosen_node, "linux,ima-kexec-buffer",
+ image->arch.ima_buffer_addr);
+ if (ret < 0)
+ return ret;
+
+ ret = fdt_setprop_u64(fdt, chosen_node, "linux,ima-kexec-buffer-end",
+ image->arch.ima_buffer_addr +
+ image->arch.ima_buffer_size);
+ if (ret < 0)
+ return ret;
+
+ ret = fdt_add_mem_rsv(fdt, image->arch.ima_buffer_addr,
+ image->arch.ima_buffer_size);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+#endif /* CONFIG_IMA_KEXEC */
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index 58871333737a..de5452539c67 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -21,6 +21,7 @@
#include <linux/types.h>
#include <linux/vmalloc.h>
#include <asm/byteorder.h>
+#include <asm/ima.h>
/* relevant device tree properties */
#define FDT_PROP_INITRD_START "linux,initrd-start"
@@ -85,6 +86,11 @@ static int setup_dtb(struct kimage *image,
goto out;
}
+ /* add ima measuremnet log buffer */
+ ret = setup_ima_buffer(image, dtb, off);
+ if (ret)
+ goto out;
+
/* add kaslr-seed */
ret = fdt_delprop(dtb, off, FDT_PROP_KASLR_SEED);
if (ret == -FDT_ERR_NOTFOUND)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/2] Fix init order of S3C64xx's clock providers
From: Yao Lihua @ 2019-09-07 2:47 UTC (permalink / raw)
To: krzk@kernel.org, kgene@kernel.org,
linux-samsung-soc@vger.kernel.org
Cc: Yao Lihua, linux-arm-kernel@lists.infradead.org
From: Lihua Yao <ylhuajnu@outlook.com>
Ensure fin_pll is initialized before clock-controller@7e00f000 so
we have correct clock frequency like below:
[ 0.000000] S3C6410 clocks: apll = 532000000, mpll = 532000000
[ 0.000000] epll = 24000000, arm_clk = 532000000
Lihua Yao (2):
ARM: dts: s3c64xx: factor out external fixed clocks
ARM: dts: s3c64xx: specify dependency of clock providers
arch/arm/boot/dts/s3c6400.dtsi | 1 +
arch/arm/boot/dts/s3c6410-mini6410.dts | 22 ----------------------
arch/arm/boot/dts/s3c6410-smdk6410.dts | 22 ----------------------
arch/arm/boot/dts/s3c6410.dtsi | 1 +
arch/arm/boot/dts/s3c64xx.dtsi | 14 ++++++++++++++
5 files changed, 16 insertions(+), 44 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] ARM: dts: s3c64xx: factor out external fixed clocks
From: Yao Lihua @ 2019-09-07 2:48 UTC (permalink / raw)
To: krzk@kernel.org, kgene@kernel.org,
linux-samsung-soc@vger.kernel.org
Cc: Yao Lihua, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190907024719.16974-1-ylhuajnu@outlook.com>
From: Lihua Yao <ylhuajnu@outlook.com>
As per arch/arm/mach-s3c64xx/common.c, the external oscillators
of S3C6400 and S3C6410 are identical. Move them to s3c64xx.dtsi
and place under root node directly.
This introduces side effect of changing the initialization order of
fin_pll and clock-controller@7e00f000. As of commit 3f6d439f2022
("clk: reverse default clk provider initialization order in of_clk_init()"),
clock providers are initialized in the orders they are present in the
device tree unless the clocks' dependencies are specified explicitly.
without this patch:
[ 0.000000] S3C6410 clocks: apll = 0, mpll = 0
[ 0.000000] epll = 0, arm_clk = 0
with this patch:
[ 0.000000] S3C6410 clocks: apll = 532000000, mpll = 532000000
[ 0.000000] epll = 24000000, arm_clk = 532000000
Fixes: 3f6d439f2022 ("clk: reverse default clk provider initialization order in of_clk_init()")
Signed-off-by: Lihua Yao <ylhuajnu@outlook.com>
---
arch/arm/boot/dts/s3c6410-mini6410.dts | 22 ----------------------
arch/arm/boot/dts/s3c6410-smdk6410.dts | 22 ----------------------
arch/arm/boot/dts/s3c64xx.dtsi | 14 ++++++++++++++
3 files changed, 14 insertions(+), 44 deletions(-)
diff --git a/arch/arm/boot/dts/s3c6410-mini6410.dts b/arch/arm/boot/dts/s3c6410-mini6410.dts
index 5201512054c4..7028507b7076 100644
--- a/arch/arm/boot/dts/s3c6410-mini6410.dts
+++ b/arch/arm/boot/dts/s3c6410-mini6410.dts
@@ -28,28 +28,6 @@
bootargs = "console=ttySAC0,115200n8 earlyprintk root=/dev/nfs rw nfsroot=192.168.31.2:/srv/nfs/tiny6410,nfsvers=3 ip=dhcp";
};
- clocks {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <0>;
-
- fin_pll: oscillator@0 {
- compatible = "fixed-clock";
- reg = <0>;
- clock-frequency = <12000000>;
- clock-output-names = "fin_pll";
- #clock-cells = <0>;
- };
-
- xusbxti: oscillator@1 {
- compatible = "fixed-clock";
- reg = <1>;
- clock-output-names = "xusbxti";
- clock-frequency = <48000000>;
- #clock-cells = <0>;
- };
- };
-
srom-cs1@18000000 {
compatible = "simple-bus";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/s3c6410-smdk6410.dts b/arch/arm/boot/dts/s3c6410-smdk6410.dts
index a9a5689dc462..10a854b488a8 100644
--- a/arch/arm/boot/dts/s3c6410-smdk6410.dts
+++ b/arch/arm/boot/dts/s3c6410-smdk6410.dts
@@ -28,28 +28,6 @@
bootargs = "console=ttySAC0,115200n8 earlyprintk rootwait root=/dev/mmcblk0p1";
};
- clocks {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <0>;
-
- fin_pll: oscillator@0 {
- compatible = "fixed-clock";
- reg = <0>;
- clock-frequency = <12000000>;
- clock-output-names = "fin_pll";
- #clock-cells = <0>;
- };
-
- xusbxti: oscillator@1 {
- compatible = "fixed-clock";
- reg = <1>;
- clock-output-names = "xusbxti";
- clock-frequency = <48000000>;
- #clock-cells = <0>;
- };
- };
-
srom-cs1@18000000 {
compatible = "simple-bus";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/s3c64xx.dtsi b/arch/arm/boot/dts/s3c64xx.dtsi
index 2e611df37911..672764133cea 100644
--- a/arch/arm/boot/dts/s3c64xx.dtsi
+++ b/arch/arm/boot/dts/s3c64xx.dtsi
@@ -39,6 +39,20 @@
};
};
+ fin_pll: oscillator-0 {
+ compatible = "fixed-clock";
+ clock-frequency = <12000000>;
+ clock-output-names = "fin_pll";
+ #clock-cells = <0>;
+ };
+
+ xusbxti: oscillator-1 {
+ compatible = "fixed-clock";
+ clock-frequency = <48000000>;
+ clock-output-names = "xusbxti";
+ #clock-cells = <0>;
+ };
+
soc: soc {
compatible = "simple-bus";
#address-cells = <1>;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: s3c64xx: specify dependency of clock providers
From: Yao Lihua @ 2019-09-07 2:48 UTC (permalink / raw)
To: krzk@kernel.org, kgene@kernel.org,
linux-samsung-soc@vger.kernel.org
Cc: Yao Lihua, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190907024719.16974-1-ylhuajnu@outlook.com>
From: Lihua Yao <ylhuajnu@outlook.com>
fin_pll is the parent of clock-controller@7e00f000, specify
the dependency to ensure proper initialization order of clock
providers.
Fixes: 3f6d439f2022 ("clk: reverse default clk provider initialization order in of_clk_init()")
Signed-off-by: Lihua Yao <ylhuajnu@outlook.com>
---
arch/arm/boot/dts/s3c6400.dtsi | 1 +
arch/arm/boot/dts/s3c6410.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/s3c6400.dtsi b/arch/arm/boot/dts/s3c6400.dtsi
index 8c28e8a0c824..ef5a8fa3555c 100644
--- a/arch/arm/boot/dts/s3c6400.dtsi
+++ b/arch/arm/boot/dts/s3c6400.dtsi
@@ -34,5 +34,6 @@
compatible = "samsung,s3c6400-clock";
reg = <0x7e00f000 0x1000>;
#clock-cells = <1>;
+ clocks = <&fin_pll>;
};
};
diff --git a/arch/arm/boot/dts/s3c6410.dtsi b/arch/arm/boot/dts/s3c6410.dtsi
index a766d6de696c..b201b71d45b5 100644
--- a/arch/arm/boot/dts/s3c6410.dtsi
+++ b/arch/arm/boot/dts/s3c6410.dtsi
@@ -38,6 +38,7 @@
compatible = "samsung,s3c6410-clock";
reg = <0x7e00f000 0x1000>;
#clock-cells = <1>;
+ clocks = <&fin_pll>;
};
i2c1: i2c@7f00f000 {
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] ARM: SAMSUNG: Fix system restart support on s3c6410
From: Yao Lihua @ 2019-09-07 3:30 UTC (permalink / raw)
To: krzk@kernel.org, kgene@kernel.org,
linux-samsung-soc@vger.kernel.org
Cc: Yao Lihua, linux-arm-kernel@lists.infradead.org
From: Lihua Yao <ylhuajnu@outlook.com>
S3C6410 system restart is triggered by watchdog reset.
Fixes: 9f55342cc2de ("ARM: dts: s3c64xx: Fix infinite interrupt in soft mode")
Signed-off-by: Lihua Yao <ylhuajnu@outlook.com>
---
arch/arm/plat-samsung/watchdog-reset.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/plat-samsung/watchdog-reset.c b/arch/arm/plat-samsung/watchdog-reset.c
index ce42cc640a61..71d85ff323f7 100644
--- a/arch/arm/plat-samsung/watchdog-reset.c
+++ b/arch/arm/plat-samsung/watchdog-reset.c
@@ -62,6 +62,7 @@ void samsung_wdt_reset(void)
#ifdef CONFIG_OF
static const struct of_device_id s3c2410_wdt_match[] = {
{ .compatible = "samsung,s3c2410-wdt" },
+ { .compatible = "samsung,s3c6410-wdt" },
{},
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC][PATCH v1 0/1] Add support for arm64 to carry ima measurement log in kexec_file_load
From: Stephen Boyd @ 2019-09-07 3:56 UTC (permalink / raw)
To: Prakhar Srivastava, linux-arm-kernel, linux-kernel
Cc: mark.rutland, jean-philippe, arnd, takahiro.akashi,
catalin.marinas, yamada.masahiro, kristina.martsenko, duwe,
bauerman, james.morse, tglx, allison
In-Reply-To: <20190906235110.15566-1-prsriva@linux.microsoft.com>
Quoting Prakhar Srivastava (2019-09-06 16:51:09)
> Add support for arm64 to carry ima measurement log
> to the next kexec'ed session triggered via kexec_file_load.
> - Top of Linux 5.3-rc6
>
> Currently during kexec the kernel file signatures are/can be validated
> prior to actual load, the information(PE/ima signature) is not carried
> to the next session. This lead to loss of information.
>
> Carrying forward the ima measurement log to the next kexec'ed session.
> This allows a verifying party to get the entire runtime event log since
> the last full reboot since that is when PCRs were last reset.
>
> Prakhar Srivastava (1):
> Add support for arm64 to carry ima measurement log in kexec_file_load
Did anything change from the last round? Please include changelogs so we
know what to look for.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V3, 2/2] media: i2c: Add Omnivision OV02A10 camera sensor driver
From: Tomasz Figa @ 2019-09-07 3:51 UTC (permalink / raw)
To: Dongchun Zhu
Cc: Mark Rutland, devicetree, Nicolas Boichat, srv_heupstream,
shengnan.wang, Louis Kuo, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, Sakari Ailus,
Matthias Brugger, Cao Bing Bu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
In-Reply-To: <1567733585.21623.163.camel@mhfsdcap03>
On Fri, Sep 6, 2019 at 10:33 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
>
> On Fri, 2019-09-06 at 06:58 +0800, Nicolas Boichat wrote:
> > On Fri, Sep 6, 2019 at 12:05 AM Sakari Ailus
> > <sakari.ailus@linux.intel.com> wrote:
> > >
> > > On Thu, Sep 05, 2019 at 07:53:37PM +0900, Tomasz Figa wrote:
> > > > On Thu, Sep 5, 2019 at 7:45 PM Sakari Ailus
> > > > <sakari.ailus@linux.intel.com> wrote:
> > > > >
> > > > > Hi Dongchun,
> > > > >
> > > > > On Thu, Sep 05, 2019 at 05:41:05PM +0800, Dongchun Zhu wrote:
> > > > >
> > > > > ...
> > > > >
> > > > > > > > + ret = regulator_bulk_enable(OV02A10_NUM_SUPPLIES, ov02a10->supplies);
> > > > > > > > + if (ret < 0) {
> > > > > > > > + dev_err(dev, "Failed to enable regulators\n");
> > > > > > > > + goto disable_clk;
> > > > > > > > + }
> > > > > > > > + msleep_range(7);
> > > > > > >
> > > > > > > This has some potential of clashing with more generic functions in the
> > > > > > > future. Please use usleep_range directly, or msleep.
> > > > > > >
> > > > > >
> > > > > > Did you mean using usleep_range(7*1000, 8*1000), as used in patch v1?
> > > > > > https://patchwork.kernel.org/patch/10957225/
> > > > >
> > > > > Yes, please.
> > > >
> > > > Why not just msleep()?
> > >
> > > msleep() is usually less accurate. I'm not sure it makes a big different in
> > > this case. Perhaps, if someone wants that the sensor is powered on and
> > > streaming as soon as possible.
> >
> > https://elixir.bootlin.com/linux/latest/source/Documentation/timers/timers-howto.txt#L70
> >
> > Use usleep_range for delays up to 20ms (at least that's what the
> > documentation (still) says?)
> >
>
> Thank you for your clarifications.
> From the doc,
> "msleep(1~20) may not do what the caller intends, and
> will often sleep longer (~20 ms actual sleep for any
> value given in the 1~20ms range). In many cases this
> is not the desired behavior."
>
> So, it is supposed to use usleep_range in shorter sleep case,
> such as 5ms.
Thanks for double checking. usleep_range() sounds good then. Sorry for
the noise.
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/9] crypto: Add allwinner subdirectory
From: Maxime Ripard @ 2019-09-07 3:54 UTC (permalink / raw)
To: Corentin Labbe
Cc: mark.rutland, devicetree, herbert, linux-sunxi, linux,
linux-kernel, wens, robh+dt, linux-crypto, davem,
linux-arm-kernel
In-Reply-To: <20190906184551.17858-2-clabbe.montjoie@gmail.com>
On Fri, Sep 06, 2019 at 08:45:43PM +0200, Corentin Labbe wrote:
> Since a second Allwinner crypto driver will be added, it is better to
> create a dedicated subdirectory.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> MAINTAINERS | 6 ++++++
> drivers/crypto/Kconfig | 2 ++
> drivers/crypto/Makefile | 1 +
> drivers/crypto/allwinner/Kconfig | 6 ++++++
I guess it would make sense to move the sun4i driver there too?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/9] dt-bindings: crypto: Add DT bindings documentation for sun8i-ce Crypto Engine
From: Maxime Ripard @ 2019-09-07 4:01 UTC (permalink / raw)
To: Corentin Labbe
Cc: mark.rutland, devicetree, herbert, linux-sunxi, linux,
linux-kernel, wens, robh+dt, linux-crypto, davem,
linux-arm-kernel
In-Reply-To: <20190906184551.17858-4-clabbe.montjoie@gmail.com>
On Fri, Sep 06, 2019 at 08:45:45PM +0200, Corentin Labbe wrote:
> This patch adds documentation for Device-Tree bindings for the
> Crypto Engine cryptographic accelerator driver.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> .../bindings/crypto/allwinner,sun8i-ce.yaml | 84 +++++++++++++++++++
> 1 file changed, 84 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
>
> diff --git a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
> new file mode 100644
> index 000000000000..bd8ccedd6059
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
So, usually we're using the first compatible supported here as the
name.
> @@ -0,0 +1,84 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/crypto/allwinner,sun8i-ce.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Allwinner Crypto Engine driver
> +
> +maintainers:
> + - Corentin Labbe <clabbe@baylibre.com>
> +
> +properties:
> + compatible:
> + oneOf:
> + - const: allwinner,sun8i-h3-crypto
> + - const: allwinner,sun8i-r40-crypto
> + - const: allwinner,sun50i-a64-crypto
> + - const: allwinner,sun50i-h5-crypto
> + - const: allwinner,sun50i-h6-crypto
An enum would be better here, it provides a more obvious error
message.
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> +if:
> + properties:
> + compatible:
> + contains:
> + const: allwinner,sun50i-h6-crypto
> +then:
> + clocks:
> + items:
> + - description: Bus clock
> + - description: Module clock
> + - description: MBus clock
> +
> + clock-names:
> + items:
> + - const: ahb
> + - const: mod
> + - const: mbus
It looks like there's a reset line on the H6 as well for that
controller (register 0x68c of the CCU, "CE_BGR_REG").
> +else:
> + clocks:
> + items:
> + - description: Bus clock
> + - description: Module clock
> +
> + clock-names:
> + items:
> + - const: ahb
> + - const: mod
> +
> + resets:
> + maxItems: 1
> +
> + reset-names:
> + const: ahb
This prevents the usage of the additionalProperties property, which
you should really use.
What you can do instead is moving the clocks and clock-names
description under properties, with a minItems of 2 and a maxItems of
3. Then you can restrict the length of that property to either 2 or 3
depending on the case here.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/9] ARM: dts: sun8i: r40: add crypto engine node
From: Maxime Ripard @ 2019-09-07 4:02 UTC (permalink / raw)
To: Corentin Labbe
Cc: mark.rutland, devicetree, herbert, linux-sunxi, linux,
linux-kernel, wens, robh+dt, linux-crypto, davem,
linux-arm-kernel
In-Reply-To: <20190906184551.17858-5-clabbe.montjoie@gmail.com>
On Fri, Sep 06, 2019 at 08:45:46PM +0200, Corentin Labbe wrote:
> The Crypto Engine is a hardware cryptographic offloader that supports
> many algorithms.
> It could be found on most Allwinner SoCs.
>
> This patch enables the Crypto Engine on the Allwinner R40 SoC Device-tree.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> arch/arm/boot/dts/sun8i-r40.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
> index bde068111b85..7eb649cea163 100644
> --- a/arch/arm/boot/dts/sun8i-r40.dtsi
> +++ b/arch/arm/boot/dts/sun8i-r40.dtsi
> @@ -266,6 +266,17 @@
> #phy-cells = <1>;
> };
>
> + crypto: crypto-engine@1c15000 {
> + compatible = "allwinner,sun8i-r40-crypto";
> + reg = <0x01c15000 0x1000>;
> + interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_CE>, <&ccu CLK_CE>;
> + clock-names = "ahb", "mod";
> + resets = <&ccu RST_BUS_CE>;
> + reset-names = "ahb";
> + status = "okay";
The driver will probe if status is not declared, so if you want it
always enabled you should simply remove status
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/9] ARM64: dts: allwinner: sun50i: Add Crypto Engine node on A64
From: Maxime Ripard @ 2019-09-07 4:02 UTC (permalink / raw)
To: Corentin Labbe
Cc: mark.rutland, devicetree, herbert, linux-sunxi, linux,
linux-kernel, wens, robh+dt, linux-crypto, davem,
linux-arm-kernel
In-Reply-To: <20190906184551.17858-7-clabbe.montjoie@gmail.com>
On Fri, Sep 06, 2019 at 08:45:48PM +0200, Corentin Labbe wrote:
> The Crypto Engine is a hardware cryptographic accelerator that supports
> many algorithms.
> It could be found on most Allwinner SoCs.
>
> This patch enables the Crypto Engine on the Allwinner A64 SoC Device-tree.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 69128a6dfc46..c9e30d462ab1 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -487,6 +487,17 @@
> reg = <0x1c14000 0x400>;
> };
>
> + crypto: crypto@1c15000 {
> + compatible = "allwinner,sun50i-a64-crypto";
> + reg = <0x01c15000 0x1000>;
> + interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "ce_ns";
You didn't document that property
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 9/9] sunxi_defconfig: add new crypto options
From: Maxime Ripard @ 2019-09-07 4:03 UTC (permalink / raw)
To: Corentin Labbe
Cc: mark.rutland, devicetree, herbert, linux-sunxi, linux,
linux-kernel, wens, robh+dt, linux-crypto, davem,
linux-arm-kernel
In-Reply-To: <20190906184551.17858-10-clabbe.montjoie@gmail.com>
On Fri, Sep 06, 2019 at 08:45:51PM +0200, Corentin Labbe wrote:
> This patch adds the new allwinner crypto configs to sunxi_defconfig
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> arch/arm/configs/sunxi_defconfig | 2 ++
> 1 file changed, 2 insertions(+)
Can you also enable it in arm64's defconfig as a module?
>
> diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
> index df433abfcb02..d0ab8ba7710a 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -150,4 +150,6 @@ CONFIG_NLS_CODEPAGE_437=y
> CONFIG_NLS_ISO8859_1=y
> CONFIG_PRINTK_TIME=y
> CONFIG_DEBUG_FS=y
> +CONFIG_CRYPTO_DEV_ALLWINNER=y
> +CONFIG_CRYPTO_DEV_SUN8I_CE=y
> CONFIG_CRYPTO_DEV_SUN4I_SS=y
> --
> 2.21.0
>
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4/4] DTS: bindings: omap: update bindings documentation
From: H. Nikolaus Schaller @ 2019-09-07 6:56 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren, Rob Herring, Adam Ford,
André Roth, Mark Rutland, Rafael J. Wysocki, Viresh Kumar,
Enric Balletbo i Serra, Javier Martinez Canillas, Roger Quadros,
Teresa Remmet, H. Nikolaus Schaller
Cc: devicetree, linux-omap, linux-pm, linux-kernel, kernel,
letux-kernel, linux-arm-kernel
In-Reply-To: <cover.1567839375.git.hns@goldelico.com>
* clarify that we now need either "ti,omap3430" or "ti,omap3630" or "ti,am3517" for omap3 chips
* clarify that "ti,omap3" has no default
* clarify that AM33x is not an "ti,omap3"
* clarify that the list of boards is incomplete
* remove some "ti,am33xx", "ti,omap3"
* add some missing "ti,omap4"
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
.../devicetree/bindings/arm/omap/omap.txt | 30 +++++++++++--------
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index b301f753ed2c..e77635c5422c 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -43,7 +43,7 @@ SoC Families:
- OMAP2 generic - defaults to OMAP2420
compatible = "ti,omap2"
-- OMAP3 generic - defaults to OMAP3430
+- OMAP3 generic
compatible = "ti,omap3"
- OMAP4 generic - defaults to OMAP4430
compatible = "ti,omap4"
@@ -51,6 +51,8 @@ SoC Families:
compatible = "ti,omap5"
- DRA7 generic - defaults to DRA742
compatible = "ti,dra7"
+- AM33x generic
+ compatible = "ti,am33xx"
- AM43x generic - defaults to AM4372
compatible = "ti,am43"
@@ -63,12 +65,14 @@ SoCs:
- OMAP3430
compatible = "ti,omap3430", "ti,omap3"
+ legacy: "ti,omap34xx" - please do not use any more
- AM3517
compatible = "ti,am3517", "ti,omap3"
- OMAP3630
- compatible = "ti,omap36xx", "ti,omap3"
-- AM33xx
- compatible = "ti,am33xx", "ti,omap3"
+ compatible = "ti,omap3630", "ti,omap3"
+ legacy: "ti,omap36xx" - please do not use any more
+- AM335x
+ compatible = "ti,am33xx"
- OMAP4430
compatible = "ti,omap4430", "ti,omap4"
@@ -110,19 +114,19 @@ SoCs:
- AM4372
compatible = "ti,am4372", "ti,am43"
-Boards:
+Boards (incomplete list of examples):
- OMAP3 BeagleBoard : Low cost community board
- compatible = "ti,omap3-beagle", "ti,omap3"
+ compatible = "ti,omap3-beagle", "ti,omap3430", "ti,omap3"
- OMAP3 Tobi with Overo : Commercial expansion board with daughter board
- compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3"
+ compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3430", "ti,omap3"
- OMAP4 SDP : Software Development Board
- compatible = "ti,omap4-sdp", "ti,omap4430"
+ compatible = "ti,omap4-sdp", "ti,omap4430", "ti,omap4"
- OMAP4 PandaBoard : Low cost community board
- compatible = "ti,omap4-panda", "ti,omap4430"
+ compatible = "ti,omap4-panda", "ti,omap4430", "ti,omap4"
- OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board
compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
@@ -134,16 +138,16 @@ Boards:
compatible = "variscite,var-dvk-om44", "variscite,var-som-om44", "ti,omap4460", "ti,omap4";
- OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
- compatible = "ti,omap3-evm", "ti,omap3"
+ compatible = "ti,omap3-evm", "ti,omap3630", "ti,omap3"
- AM335X EVM : Software Development Board for AM335x
- compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3"
+ compatible = "ti,am335x-evm", "ti,am33xx"
- AM335X Bone : Low cost community board
- compatible = "ti,am335x-bone", "ti,am33xx", "ti,omap3"
+ compatible = "ti,am335x-bone", "ti,am33xx"
- AM3359 ICEv2 : Low cost Industrial Communication Engine EVM.
- compatible = "ti,am3359-icev2", "ti,am33xx", "ti,omap3"
+ compatible = "ti,am3359-icev2", "ti,am33xx"
- AM335X OrionLXm : Substation Automation Platform
compatible = "novatech,am335x-lxm", "ti,am33xx"
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/4] OMAP3: convert opp-v1 to opp-v2 and read speed binned / 720MHz grade bits
From: H. Nikolaus Schaller @ 2019-09-07 6:56 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren, Rob Herring, Adam Ford,
André Roth, Mark Rutland, Rafael J. Wysocki, Viresh Kumar,
Enric Balletbo i Serra, Javier Martinez Canillas, Roger Quadros,
Teresa Remmet, H. Nikolaus Schaller
Cc: devicetree, linux-omap, linux-pm, linux-kernel, kernel,
letux-kernel, linux-arm-kernel
Changes PATCH V1:
* fix typo in omap3-ldp.dts
(reported by Tony Lindgren <tony@atomide.com>)
* extend commit message to describe the bit patterns needed
for opp-supported-hw
* add error check to ioremap()
(suggested by Christ van Willegen <cvwillegen@gmail.com>)
* update Documentation/devicetree/bindings/arm/omap/omap.txt
* change bulk update to use "ti,omap3430" and "ti,omap3630"
* update OPP4 of omap3430 to 1275 mV since it was not a valid
voltage for the twl4030 driver (reported by Tony Lindgren
<tony@atomide.com>)
RFC V2 2019-09-04 10:53:43:
* merge separate patch to remove opp-v1 table from n950-n9 into
the general omap3xxx.dtsi patch
(suggested by Viresh Kumar <viresh.kumar@linaro.org>)
* add legacy compatibility to ti,omap3430 and ti,omap3630 for
the ti-cpufreq driver
* make driver and omap3xxx.dtsi patches pass checkpatch
* add bulk patch to explicitly define compatibility to ti,omap3430
and ti,omap36xx in addition to ti,omap3 of all in-tree boards
where it was missing
RFC V1 2019-09-02 12:55:55:
This patch set converts the omap3 opp tables to opp-v2 format
and extends the ti-cpufreq to support omap3.
It adds 720 MHz (omap34xx) and 1 GHz (omap36xx) OPPs but
tells the ti-cpufreq driver to disable them if the speed
binned / 720MHz grade eFuse bits indicate that the chip
is not rated for that speed.
It has been tested (for chip variant detection, not reliability
of the high speed OPPs) on:
* BeagleBoard C2 (omap3530 600MHz)
* BeagleBoard XM B (dm3730 800MHz)
* GTA04A4 (dm3730 800MHz)
* GTA04A5 (dm3730 1GHz)
H. Nikolaus Schaller (4):
cpufreq: ti-cpufreq: add support for omap34xx and omap36xx
ARM: dts: replace opp-v1 tables by opp-v2 for omap34xx and omap36xx
ARM: dts: omap3: bulk convert compatible to be explicitly ti,omap3430
or ti,omap3630 or ti,am3517
DTS: bindings: omap: update bindings documentation
.../devicetree/bindings/arm/omap/omap.txt | 30 +++---
arch/arm/boot/dts/am3517_mt_ventoux.dts | 2 +-
.../boot/dts/logicpd-som-lv-35xx-devkit.dts | 2 +-
.../boot/dts/logicpd-torpedo-35xx-devkit.dts | 2 +-
arch/arm/boot/dts/omap3-beagle-xm.dts | 2 +-
arch/arm/boot/dts/omap3-beagle.dts | 2 +-
arch/arm/boot/dts/omap3-cm-t3530.dts | 2 +-
arch/arm/boot/dts/omap3-cm-t3730.dts | 2 +-
arch/arm/boot/dts/omap3-devkit8000-lcd43.dts | 2 +-
arch/arm/boot/dts/omap3-devkit8000-lcd70.dts | 2 +-
arch/arm/boot/dts/omap3-devkit8000.dts | 2 +-
arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
arch/arm/boot/dts/omap3-ha-lcd.dts | 2 +-
arch/arm/boot/dts/omap3-ha.dts | 2 +-
arch/arm/boot/dts/omap3-igep0020-rev-f.dts | 2 +-
arch/arm/boot/dts/omap3-igep0020.dts | 2 +-
arch/arm/boot/dts/omap3-igep0030-rev-g.dts | 2 +-
arch/arm/boot/dts/omap3-igep0030.dts | 2 +-
arch/arm/boot/dts/omap3-ldp.dts | 2 +-
arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 2 +-
arch/arm/boot/dts/omap3-lilly-dbb056.dts | 2 +-
arch/arm/boot/dts/omap3-n9.dts | 2 +-
arch/arm/boot/dts/omap3-n950-n9.dtsi | 7 --
arch/arm/boot/dts/omap3-n950.dts | 2 +-
.../arm/boot/dts/omap3-overo-storm-alto35.dts | 2 +-
.../boot/dts/omap3-overo-storm-chestnut43.dts | 2 +-
.../boot/dts/omap3-overo-storm-gallop43.dts | 2 +-
.../arm/boot/dts/omap3-overo-storm-palo35.dts | 2 +-
.../arm/boot/dts/omap3-overo-storm-palo43.dts | 2 +-
.../arm/boot/dts/omap3-overo-storm-summit.dts | 2 +-
arch/arm/boot/dts/omap3-overo-storm-tobi.dts | 2 +-
.../boot/dts/omap3-overo-storm-tobiduo.dts | 2 +-
arch/arm/boot/dts/omap3-pandora-1ghz.dts | 2 +-
arch/arm/boot/dts/omap3-sbc-t3530.dts | 2 +-
arch/arm/boot/dts/omap3-sbc-t3730.dts | 2 +-
arch/arm/boot/dts/omap3-sniper.dts | 2 +-
arch/arm/boot/dts/omap3-thunder.dts | 2 +-
arch/arm/boot/dts/omap3-zoom3.dts | 2 +-
arch/arm/boot/dts/omap3430-sdp.dts | 2 +-
arch/arm/boot/dts/omap34xx.dtsi | 65 +++++++++++--
arch/arm/boot/dts/omap36xx.dtsi | 53 +++++++++--
drivers/cpufreq/cpufreq-dt-platdev.c | 2 +-
drivers/cpufreq/ti-cpufreq.c | 91 ++++++++++++++++++-
43 files changed, 245 insertions(+), 77 deletions(-)
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/4] ARM: dts: replace opp-v1 tables by opp-v2 for omap34xx and omap36xx
From: H. Nikolaus Schaller @ 2019-09-07 6:56 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren, Rob Herring, Adam Ford,
André Roth, Mark Rutland, Rafael J. Wysocki, Viresh Kumar,
Enric Balletbo i Serra, Javier Martinez Canillas, Roger Quadros,
Teresa Remmet, H. Nikolaus Schaller
Cc: devicetree, linux-omap, linux-pm, linux-kernel, kernel,
letux-kernel, linux-arm-kernel
In-Reply-To: <cover.1567839375.git.hns@goldelico.com>
In addition, move omap3 from whitelist to blacklist in cpufreq-dt-platdev
in the same patch, because doing either first breaks operation and
may make trouble in bisect.
We also can remove opp-v1 table for omap3-n950-n9 since it is now
automatically detected.
We also fix a wrong OPP4 voltage for omap3430 which must be
0.6V + 54*12.5mV = 1275mV. Otherwise the twl4030 driver will reject
this OPP.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
arch/arm/boot/dts/omap3-n950-n9.dtsi | 7 ---
arch/arm/boot/dts/omap34xx.dtsi | 65 ++++++++++++++++++++++++----
arch/arm/boot/dts/omap36xx.dtsi | 53 +++++++++++++++++++----
drivers/cpufreq/cpufreq-dt-platdev.c | 2 +-
4 files changed, 102 insertions(+), 25 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi b/arch/arm/boot/dts/omap3-n950-n9.dtsi
index 5441e9ffdbb4..e98b0c615f19 100644
--- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -11,13 +11,6 @@
cpus {
cpu@0 {
cpu0-supply = <&vcc>;
- operating-points = <
- /* kHz uV */
- 300000 1012500
- 600000 1200000
- 800000 1325000
- 1000000 1375000
- >;
};
};
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index f572a477f74c..91154829f86a 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -16,19 +16,66 @@
/ {
cpus {
cpu: cpu@0 {
- /* OMAP343x/OMAP35xx variants OPP1-5 */
- operating-points = <
- /* kHz uV */
- 125000 975000
- 250000 1075000
- 500000 1200000
- 550000 1270000
- 600000 1350000
- >;
+ /* OMAP343x/OMAP35xx variants OPP1-6 */
+ operating-points-v2 = <&cpu0_opp_table>;
+
clock-latency = <300000>; /* From legacy driver */
};
};
+ /* see Documentation/devicetree/bindings/opp/opp.txt */
+ cpu0_opp_table: opp-table {
+ compatible = "operating-points-v2-ti-cpu";
+ syscon = <&scm_conf>;
+
+ opp1-125000000 {
+ opp-hz = /bits/ 64 <125000000>;
+ /*
+ * we currently only select the max voltage from table
+ * Table 3-3 of the omap3530 Data sheet (SPRS507F).
+ * Format is: <target min max>
+ */
+ opp-microvolt = <975000 975000 975000>;
+ /*
+ * first value is silicon revision bit mask
+ * second one 720MHz Device Identification bit mask
+ */
+ opp-supported-hw = <0xffffffff 3>;
+ };
+
+ opp2-250000000 {
+ opp-hz = /bits/ 64 <250000000>;
+ opp-microvolt = <1075000 1075000 1075000>;
+ opp-supported-hw = <0xffffffff 3>;
+ opp-suspend;
+ };
+
+ opp3-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-microvolt = <1200000 1200000 1200000>;
+ opp-supported-hw = <0xffffffff 3>;
+ };
+
+ opp4-550000000 {
+ opp-hz = /bits/ 64 <550000000>;
+ opp-microvolt = <1275000 1275000 1275000>;
+ opp-supported-hw = <0xffffffff 3>;
+ };
+
+ opp5-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <1350000 1350000 1350000>;
+ opp-supported-hw = <0xffffffff 3>;
+ };
+
+ opp6-720000000 {
+ opp-hz = /bits/ 64 <720000000>;
+ opp-microvolt = <1350000 1350000 1350000>;
+ /* only high-speed grade omap3530 devices */
+ opp-supported-hw = <0xffffffff 2>;
+ };
+ };
+
ocp@68000000 {
omap3_pmx_core2: pinmux@480025d8 {
compatible = "ti,omap3-padconf", "pinctrl-single";
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 6fb23ada1f64..44f25b0eb45b 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -19,15 +19,52 @@
};
cpus {
- /* OMAP3630/OMAP37xx 'standard device' variants OPP50 to OPP130 */
+ /* OMAP3630/OMAP37xx variants OPP50 to OPP130 and OPP1G */
cpu: cpu@0 {
- operating-points = <
- /* kHz uV */
- 300000 1012500
- 600000 1200000
- 800000 1325000
- >;
- clock-latency = <300000>; /* From legacy driver */
+ operating-points-v2 = <&cpu0_opp_table>;
+
+ clock-latency = <300000>; /* From omap-cpufreq driver */
+ };
+ };
+
+ /* see Documentation/devicetree/bindings/opp/opp.txt */
+ cpu0_opp_table: opp-table {
+ compatible = "operating-points-v2-ti-cpu";
+ syscon = <&scm_conf>;
+
+ opp50-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ /*
+ * we currently only select the max voltage from table
+ * Table 4-19 of the DM3730 Data sheet (SPRS685B)
+ * Format is: <target min max>
+ */
+ opp-microvolt = <1012500 1012500 1012500>;
+ /*
+ * first value is silicon revision bit mask
+ * second one is "speed binned" bit mask
+ */
+ opp-supported-hw = <0xffffffff 3>;
+ opp-suspend;
+ };
+
+ opp100-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <1200000 1200000 1200000>;
+ opp-supported-hw = <0xffffffff 3>;
+ };
+
+ opp130-800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt = <1325000 1325000 1325000>;
+ opp-supported-hw = <0xffffffff 3>;
+ };
+
+ opp1g-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <1375000 1375000 1375000>;
+ /* only on am/dm37x with speed-binned bit set */
+ opp-supported-hw = <0xffffffff 2>;
};
};
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 03dc4244ab00..68b7fc4225f8 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -86,7 +86,6 @@ static const struct of_device_id whitelist[] __initconst = {
{ .compatible = "st-ericsson,u9540", },
{ .compatible = "ti,omap2", },
- { .compatible = "ti,omap3", },
{ .compatible = "ti,omap4", },
{ .compatible = "ti,omap5", },
@@ -132,6 +131,7 @@ static const struct of_device_id blacklist[] __initconst = {
{ .compatible = "ti,am33xx", },
{ .compatible = "ti,am43", },
{ .compatible = "ti,dra7", },
+ { .compatible = "ti,omap3", },
{ }
};
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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