Re: [PATCH v2 1/1] thermal: ti-soc-thermal: Remove duplicated header file inclusion
On 4/6/2021 2:49 PM, Zhen Lei wrote: Delete one of the header files that are included twice, all included header files are then rearranged alphabetically. Reviewed-by: Keerthy Signed-off-by: Zhen Lei --- drivers/thermal/ti-soc-thermal/ti-bandgap.c | 35 ++--- 1 file changed, 17 insertions(+), 18 deletions(-) diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c b/drivers/thermal/ti-soc-thermal/ti-bandgap.c index 8a3646e26ddd208..5e7e80b4a8171c4 100644 --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c @@ -9,30 +9,29 @@ * Eduardo Valentin */ -#include +#include +#include +#include +#include #include +#include #include -#include #include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include #include #include -#include -#include -#include -#include -#include +#include +#include #include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include #include "ti-bandgap.h"
Re: [PATCH V4 3/5] arm64: dts: ti: am65/j721e: Fix up un-necessary status set to "okay" for crypto
On 11/14/2020 2:48 AM, Nishanth Menon wrote:
The default state of a device tree node is "okay". There is no specific
use of explicitly adding status = "okay" in the SoC dtsi.
Reviewed-by: Keerthy
Signed-off-by: Nishanth Menon
Reviewed-by: Tony Lindgren
Acked-by: Tero Kristo
Cc: Keerthy
---
Change in v4: Dropped Fixes
V3: https://lore.kernel.org/linux-arm-kernel/20201112183538.6805-4...@ti.com/
V2: https://lore.kernel.org/linux-arm-kernel/20201112014929.25227-4...@ti.com/
V1: https://lore.kernel.org/linux-arm-kernel/20201104224356.18040-4...@ti.com/
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 1 -
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 2 --
2 files changed, 3 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index c842b9803f2d..116818912ba2 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -119,7 +119,6 @@ crypto: crypto@4e0 {
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x0 0x04e0 0x00 0x04e0 0x0 0x3>;
- status = "okay";
dmas = <_udmap 0xc000>, <_udmap 0x4000>,
<_udmap 0x4001>;
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index 137966c6be1f..19e602afdb05 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -345,8 +345,6 @@ main_crypto: crypto@4e0 {
#size-cells = <2>;
ranges = <0x0 0x04e0 0x00 0x04e0 0x0 0x3>;
- status = "okay";
-
dmas = <_udmap 0xc000>, <_udmap 0x4000>,
<_udmap 0x4001>;
dma-names = "tx", "rx1", "rx2";
Re: [PATCH] thermal: ti-soc-thermal: Disable the CPU PM notifier for OMAP4430
On 11/3/2020 12:12 PM, Peter Ujfalusi wrote: Eduardo, Keerthy, On 29/10/2020 12.51, Tony Lindgren wrote: * Peter Ujfalusi [201029 10:03]: Disabling the notifier fixes the random shutdowns on OMAP4430 (ES2.0 and ES2.1) but it does not cause any issues on OMAP4460 (PandaES) or OMAP3630 (BeagleXM). Tony's duovero with OMAP4430 ES2.3 did not ninja-shutdown, but he also have constant and steady stream of: thermal thermal_zone0: failed to read out thermal zone (-5) Works for me and I've verified duovero still keeps hitting core ret idle: Can you pick this one up for 5.10 to make omap4430-sdp to be usable (to not shut down randomly). The regression was introduced in 5.10-rc1. Peter, Thanks for the fix. Acked-by: Keerthy Best Regards, Keerthy Tested-by: Tony Lindgren Regards, Tony - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] crypto: sa2ul - Select CRYPTO_AUTHENC
On 9/7/2020 11:52 AM, Herbert Xu wrote:
Resend with new subject.
Thanks Herbert.
Reviewed-by: Keerthy
---8<---
The sa2ul driver uses crypto_authenc_extractkeys and therefore
must select CRYPTO_AUTHENC.
Fixes: 7694b6ca649f ("crypto: sa2ul - Add crypto driver")
Reported-by: kernel test robot
Signed-off-by: Herbert Xu
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index aa3a4ed07a66..c2950127def6 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -873,6 +873,7 @@ config CRYPTO_DEV_SA2UL
select CRYPTO_AES
select CRYPTO_AES_ARM64
select CRYPTO_ALGAPI
+ select CRYPTO_AUTHENC
select HW_RANDOM
select SG_SPLIT
help
Re: [PATCH -next] crypto: sa2ul: add Kconfig selects to fix build error
On 8/6/2020 9:24 PM, Randy Dunlap wrote:
From: Randy Dunlap
sa2ul.c uses sha{1,256,512}_zero_message_hash, so select the
Kconfig symbols that provide those, like other crypto drivers do.
Fixes this build error:
ld: drivers/crypto/sa2ul.o: in function `sa_sha_digest':
sa2ul.c:(.text+0x2b25): undefined reference to `sha512_zero_message_hash'
Thanks for catching this.
Reviewed-by: Keerthy
Signed-off-by: Randy Dunlap
Reported-by: Randy Dunlap # 2020-07-29
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-cry...@vger.kernel.org
Cc: Tero Kristo
Cc: Keerthy
---
drivers/crypto/Kconfig |3 +++
1 file changed, 3 insertions(+)
--- linux-next-20200806.orig/drivers/crypto/Kconfig
+++ linux-next-20200806/drivers/crypto/Kconfig
@@ -873,6 +873,9 @@ config CRYPTO_DEV_SA2UL
select CRYPTO_AES
select CRYPTO_AES_ARM64
select CRYPTO_ALGAPI
+ select CRYPTO_SHA1
+ select CRYPTO_SHA256
+ select CRYPTO_SHA512
select HW_RANDOM
select SG_SPLIT
help
Re: [RFC 2/4] regulator: lp87565: dt: remove duplicated section
On 6/15/2020 1:30 AM, Luca Ceresoli wrote: Hi Rob, Keerthy, On 13/06/20 00:19, Rob Herring wrote: On Wed, Jun 03, 2020 at 10:03:17PM +0200, Luca Ceresoli wrote: The "Required properties:" section is copied verbatim for each of the two supported chips. In preparation to add a new chip variant make it a common section and keep the two examples to differentiate between the two chips. Signed-off-by: Luca Ceresoli --- .../devicetree/bindings/mfd/lp87565.txt | 21 --- 1 file changed, 4 insertions(+), 17 deletions(-) If you want to clean this up, can you convert it to DT schema? Sure, no problem. My only question is who should I set in the "maintainers" property. Keerty, as the original author and TI employee, you surely know this chip series much better than I do. Would you like to be the maintainer for this binding document? Otherwise I can do it "best effort". Hi Luca, You can add me as the maintainer. Regards, Keerthy Regards,
Re: [PATCH v2 linux-next 4/4] arm64: configs: defconfig: Change CONFIG_REMOTEPROC from m to y
On 10/1/2019 12:16 AM, Olof Johansson wrote:
On Mon, Sep 30, 2019 at 6:49 AM Will Deacon wrote:
On Fri, Sep 20, 2019 at 01:29:46PM +0530, Keerthy wrote:
Commit 6334150e9a36 ("remoteproc: don't allow modular build")
changes CONFIG_REMOTEPROC to a boolean from a tristate config
option which inhibits all defconfigs marking CONFIG_REMOTEPROC as
a module in compiling the remoteproc and dependent config options.
So fix the defconfig to have CONFIG_REMOTEPROC built in.
Fixes: 6334150e9a36 ("remoteproc: don't allow modular build")
Signed-off-by: Keerthy
---
arch/arm64/configs/defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 8e05c39eab08..c9a867ac32d4 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -723,7 +723,7 @@ CONFIG_TEGRA_IOMMU_SMMU=y
CONFIG_ARM_SMMU=y
CONFIG_ARM_SMMU_V3=y
CONFIG_QCOM_IOMMU=y
-CONFIG_REMOTEPROC=m
+CONFIG_REMOTEPROC=y
CONFIG_QCOM_Q6V5_MSS=m
CONFIG_QCOM_Q6V5_PAS=m
CONFIG_QCOM_SYSMON=m
Acked-by: Will Deacon
This fixes the following annoying warning from "make defconfig" on arm64:
arch/arm64/configs/defconfig:726:warning: symbol value 'm' invalid for
REMOTEPROC
I'm assuming the fix will go via arm-soc, but I can take it otherwise
(please just let me know).
Thanks, I'll pick this up, but I'll squash the 4 one-line changes into
one commit instead of separate patches.
Thanks Olof.
-Olof
[PATCH v2 linux-next 1/4] arm: configs: omap2plus_defconfig: Change CONFIG_REMOTEPROC from m to y
Commit 6334150e9a36 ("remoteproc: don't allow modular build")
changes CONFIG_REMOTEPROC to a boolean from a tristate config
option which inhibits all defconfigs marking CONFIG_REMOTEPROC as
a module in compiling the remoteproc and dependent config options.
So fix the omap2plus_defconfig to have CONFIG_REMOTEPROC built in.
Fixes: commit 6334150e9a3646 ("remoteproc: don't allow modular build")
Signed-off-by: Keerthy
---
arch/arm/configs/omap2plus_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_defconfig
index 64eb896907bf..af4069476582 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -481,7 +481,7 @@ CONFIG_RTC_DRV_OMAP=m
CONFIG_RTC_DRV_CPCAP=m
CONFIG_DMADEVICES=y
CONFIG_OMAP_IOMMU=y
-CONFIG_REMOTEPROC=m
+CONFIG_REMOTEPROC=y
CONFIG_OMAP_REMOTEPROC=m
CONFIG_WKUP_M3_RPROC=m
CONFIG_SOC_TI=y
--
2.17.1
[PATCH v2 linux-next 4/4] arm64: configs: defconfig: Change CONFIG_REMOTEPROC from m to y
Commit 6334150e9a36 ("remoteproc: don't allow modular build")
changes CONFIG_REMOTEPROC to a boolean from a tristate config
option which inhibits all defconfigs marking CONFIG_REMOTEPROC as
a module in compiling the remoteproc and dependent config options.
So fix the defconfig to have CONFIG_REMOTEPROC built in.
Fixes: 6334150e9a36 ("remoteproc: don't allow modular build")
Signed-off-by: Keerthy
---
arch/arm64/configs/defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 8e05c39eab08..c9a867ac32d4 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -723,7 +723,7 @@ CONFIG_TEGRA_IOMMU_SMMU=y
CONFIG_ARM_SMMU=y
CONFIG_ARM_SMMU_V3=y
CONFIG_QCOM_IOMMU=y
-CONFIG_REMOTEPROC=m
+CONFIG_REMOTEPROC=y
CONFIG_QCOM_Q6V5_MSS=m
CONFIG_QCOM_Q6V5_PAS=m
CONFIG_QCOM_SYSMON=m
--
2.17.1
[PATCH v2 linux-next 2/4] arm: configs: davinci_all_defconfig: Change CONFIG_REMOTEPROC from m to y
Commit 6334150e9a36 ("remoteproc: don't allow modular build")
changes CONFIG_REMOTEPROC to a boolean from a tristate config
option which inhibits all defconfigs marking CONFIG_REMOTEPROC as
a module in compiling the remoteproc and dependent config options.
So fix the davinci_all_defconfig to have CONFIG_REMOTEPROC built in.
Fixes: 6334150e9a36 ("remoteproc: don't allow modular build")
Signed-off-by: Keerthy
---
arch/arm/configs/davinci_all_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/configs/davinci_all_defconfig
b/arch/arm/configs/davinci_all_defconfig
index b34970ce6b31..01e3c0f4be92 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -228,7 +228,7 @@ CONFIG_RTC_DRV_OMAP=m
CONFIG_DMADEVICES=y
CONFIG_TI_EDMA=y
CONFIG_COMMON_CLK_PWM=m
-CONFIG_REMOTEPROC=m
+CONFIG_REMOTEPROC=y
CONFIG_DA8XX_REMOTEPROC=m
CONFIG_MEMORY=y
CONFIG_TI_AEMIF=m
--
2.17.1
[PATCH v2 linux-next 3/4] arm: configs: multi_v7_defconfig: Change CONFIG_REMOTEPROC from m to y
Commit 6334150e9a36 ("remoteproc: don't allow modular build")
changes CONFIG_REMOTEPROC to a boolean from a tristate config
option which inhibits all defconfigs marking CONFIG_REMOTEPROC as
a module in compiling the remoteproc and dependent config options.
So fix the multi_v7_defconfig to have CONFIG_REMOTEPROC built in.
Fixes: 6334150e9a36 ("remoteproc: don't allow modular build")
Signed-off-by: Keerthy
---
arch/arm/configs/multi_v7_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index 13ba53286901..198de8e36d92 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -933,7 +933,7 @@ CONFIG_BCM2835_MBOX=y
CONFIG_ROCKCHIP_IOMMU=y
CONFIG_TEGRA_IOMMU_GART=y
CONFIG_TEGRA_IOMMU_SMMU=y
-CONFIG_REMOTEPROC=m
+CONFIG_REMOTEPROC=y
CONFIG_ST_REMOTEPROC=m
CONFIG_RPMSG_VIRTIO=m
CONFIG_ASPEED_LPC_CTRL=m
--
2.17.1
[PATCH v2 linux-next 0/4] arm/arm64: configs: Convert all CONFIG_REMOTEPROC instances to y
Commit 6334150e9 changes CONFIG_REMOTEPROC to a boolean config option that inhibits all defconfigs marking CONFIG_REMOTEPROC as a module in compiling the remoteproc and dependent config options. So convert all the instances to built in. Boot tested for omap2plus_defconfig for dra7/am4/am3. Any quick testing on other boards welcome. Patches apply on top of linux-next branch Changes in v2: Cc the right lists. Keerthy (4): arm: configs: omap2plus_defconfig: Change CONFIG_REMOTEPROC from m to y arm: configs: davinci_all_defconfig: Change CONFIG_REMOTEPROC from m to y arm: configs: multi_v7_defconfig: Change CONFIG_REMOTEPROC from m to y arm64: configs: defconfig: Change CONFIG_REMOTEPROC from m to y arch/arm/configs/davinci_all_defconfig | 2 +- arch/arm/configs/multi_v7_defconfig| 2 +- arch/arm/configs/omap2plus_defconfig | 2 +- arch/arm64/configs/defconfig | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) -- 2.17.1
remoteproc: don't allow modular build
Hi Christoph/Bjorn, There are a bunch of defconfigs that rely on modular build of remoteproc. If i do a git grep CONFIG_REMOTEPROC on linux-next: arch/arm/configs/davinci_all_defconfig:CONFIG_REMOTEPROC=m arch/arm/configs/multi_v7_defconfig:CONFIG_REMOTEPROC=m arch/arm/configs/omap2plus_defconfig:CONFIG_REMOTEPROC=m arch/arm/configs/qcom_defconfig:CONFIG_REMOTEPROC=y arch/arm64/configs/defconfig:CONFIG_REMOTEPROC=m All of them now stop building the remoteproc as a module and all the dependent modules consequently do not get built. Do you recommend all of them to get converted to built in? That will be some magnitude of change. Best Regards, Keerthy
Re: [PATCH] bus: ti-sysc: Remove unpaired sysc_clkdm_deny_idle()
On 07/09/19 1:31 AM, Tony Lindgren wrote:
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.
Tested-by: Keerthy
I believe still the previous fix [1] for nfs boot is still not on
linux-next. Are you planning on more testing or it will be queued as fixes?
[1] https://lkml.org/lkml/2019/9/5/616
- Keerthy
Fixes: d098913a10f8 ("bus: ti-sysc: Fix clock handling for no-idle quirks")
Cc: Keerthy
Cc: Vignesh Raghavendra
Signed-off-by: Tony Lindgren
---
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);
Re: [PATCH] bus: ti-sysc: Fix handling of invalid clocks
On 06/09/19 3:23 AM, Tony Lindgren wrote:
We can currently get "Unable to handle kernel paging request at
virtual address" for invalid clocks with dts node but no driver:
(__clk_get_hw) from [] (ti_sysc_find_one_clockdomain+0x18/0x34)
(ti_sysc_find_one_clockdomain) from [] (ti_sysc_clkdm_init+0x34/0xdc)
(ti_sysc_clkdm_init) from [] (sysc_probe+0xa50/0x10e8)
(sysc_probe) from [] (platform_drv_probe+0x58/0xa8)
Let's add IS_ERR checks to ti_sysc_clkdm_init() as And let's start treating
clk_get() with -ENOENT as a proper error. If the clock name is specified
in device tree we must succeed with clk_get() to continue. For modules with
no clock names specified in device tree we will just ignore the clocks.
Tested for DS0 and RTC+DDR modes on AM437x
FWIW
Tested-by: Keerthy
Fixes: 2b2f7def058a ("bus: ti-sysc: Add support for missing clockdomain
handling")
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/pdata-quirks.c | 4 ++--
drivers/bus/ti-sysc.c | 5 +
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -491,11 +491,11 @@ static int ti_sysc_clkdm_init(struct device *dev,
struct clk *fck, struct clk *ick,
struct ti_sysc_cookie *cookie)
{
- if (fck)
+ if (!IS_ERR(fck))
cookie->clkdm = ti_sysc_find_one_clockdomain(fck);
if (cookie->clkdm)
return 0;
- if (ick)
+ if (!IS_ERR(ick))
cookie->clkdm = ti_sysc_find_one_clockdomain(ick);
if (cookie->clkdm)
return 0;
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
@@ -280,9 +280,6 @@ static int sysc_get_one_clock(struct sysc *ddata, const
char *name)
ddata->clocks[index] = devm_clk_get(ddata->dev, name);
if (IS_ERR(ddata->clocks[index])) {
- if (PTR_ERR(ddata->clocks[index]) == -ENOENT)
- return 0;
-
dev_err(ddata->dev, "clock get error for %s: %li\n",
name, PTR_ERR(ddata->clocks[index]));
@@ -357,7 +354,7 @@ static int sysc_get_clocks(struct sysc *ddata)
continue;
error = sysc_get_one_clock(ddata, name);
- if (error && error != -ENOENT)
+ if (error)
return error;
}
Re: Suspend/Resume Broken on AM43/AM33 Platforms
On 19/08/19 11:57 AM, Stephen Boyd wrote:
Quoting Keerthy (2019-08-18 21:24:58)
Hi Stephen,
commit 03a3bb7ae63150230c5de645dc95e673ebf17e1a
Author: Stephen Boyd
Date: Mon Aug 5 16:32:41 2019 -0700
hwrng: core - Freeze khwrng thread during suspend
Commit seems to be breaking suspend/resume on TI AM43/AM33 platforms.
rtcwake: wakeup from "mem" using /dev/rtc0 at Sun Nov 18 02:12:12 2018
[ 54.033833] PM: suspend entry (deep)
[ 54.037741] Filesystems sync: 0.000 seconds
[ 54.062730] Freezing user space processes ... (elapsed 0.001 seconds)
done.
[ 54.071313] OOM killer disabled.
[ 54.074572] Freezing remaining freezable tasks ...
[ 74.083121] Freezing of tasks failed after 20.003 seconds (1 tasks
refusing to freeze, wq_busy=0):
[ 74.092257] hwrng R running task0 289 2
0x0020
[ 74.099511] [] (__schedule) from []
(schedule+0x3c/0xc0)
[ 74.106720] [] (schedule) from []
(add_hwgenerator_randomness+0xb0/0x100)
[ 74.115358] [] (add_hwgenerator_randomness) from
[] (hwrng_fillfn+0xc0/0x14c [rng_core])
Thanks for the report. I suspect we need to check for freezer in
add_hwgenerator_randomness(). I find it odd that there's another caller
of add_hwgenerator_randomness(), but maybe the ath9k driver can be
converted to some sort of hwrng driver instead of calling into the
kthread directly.
Anyway, can you try this patch?
I applied the below patch on top of latest next branch.
Fixes the issue.
Thanks,
Keerthy
---8<---
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 5d5ea4ce1442..e2e85ca16410 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -2429,6 +2429,7 @@ void add_hwgenerator_randomness(const char *buffer,
size_t count,
size_t entropy)
{
struct entropy_store *poolp = _pool;
+ bool frozen = false;
if (unlikely(crng_init == 0)) {
crng_fast_load(buffer, count);
@@ -2439,9 +2440,12 @@ void add_hwgenerator_randomness(const char *buffer,
size_t count,
* We'll be woken up again once below random_write_wakeup_thresh,
* or when the calling thread is about to terminate.
*/
- wait_event_interruptible(random_write_wait, kthread_should_stop() ||
+ wait_event_interruptible(random_write_wait,
+ kthread_freezable_should_stop() ||
ENTROPY_BITS(_pool) <= random_write_wakeup_bits);
- mix_pool_bytes(poolp, buffer, count);
- credit_entropy_bits(poolp, entropy);
+ if (!frozen) {
+ mix_pool_bytes(poolp, buffer, count);
+ credit_entropy_bits(poolp, entropy);
+ }
}
EXPORT_SYMBOL_GPL(add_hwgenerator_randomness);
Suspend/Resume Broken on AM43/AM33 Platforms
Hi Stephen, commit 03a3bb7ae63150230c5de645dc95e673ebf17e1a Author: Stephen Boyd Date: Mon Aug 5 16:32:41 2019 -0700 hwrng: core - Freeze khwrng thread during suspend Commit seems to be breaking suspend/resume on TI AM43/AM33 platforms. rtcwake: wakeup from "mem" using /dev/rtc0 at Sun Nov 18 02:12:12 2018 [ 54.033833] PM: suspend entry (deep) [ 54.037741] Filesystems sync: 0.000 seconds [ 54.062730] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 54.071313] OOM killer disabled. [ 54.074572] Freezing remaining freezable tasks ... [ 74.083121] Freezing of tasks failed after 20.003 seconds (1 tasks refusing to freeze, wq_busy=0): [ 74.092257] hwrng R running task0 289 2 0x0020 [ 74.099511] [] (__schedule) from [] (schedule+0x3c/0xc0) [ 74.106720] [] (schedule) from [] (add_hwgenerator_randomness+0xb0/0x100) [ 74.115358] [] (add_hwgenerator_randomness) from [] (hwrng_fillfn+0xc0/0x14c [rng_core]) [ 74.125356] [] (hwrng_fillfn [rng_core]) from [] (kthread+0x134/0x148) [ 74.133764] [] (kthread) from [] (ret_from_fork+0x14/0x2c) [ 74.141093] Exception stack(0xec611fb0 to 0xec611ff8) [ 74.146239] 1fa0: [ 74.154478] 1fc0: [ 74.162764] 1fe0: 0013 [ 74.169499] Restarting kernel threads ... done. [ 74.175628] OOM killer enabled. [ 74.178796] Restarting tasks ... done. [ 74.226769] PM: suspend exit rtcwake: write error 1 One task refusing to freeze is the final error i am seeing. - Keerthy
Re: [PATCH] soc: ti: pm33xx: Fix static checker warnings
On 13/08/19 5:34 PM, Tony Lindgren wrote: * Keerthy [190626 00:50]: The patch fixes a bunch of static checker warnings. Sorry I just noticed that this one is still pending, applying into fixes. Thanks Tony Tony
Re: [PATCH 0/8] ti-sysc related warning fixes for v5.3-rc cycle
On 23/07/19 4:58 PM, Tony Lindgren wrote: Hi all, I noticed that with recent ti-sysc driver changes some new warnings have crept in. Mostly they are caused by having different configuration in the dts compared to the legacy platform data. Let's fix these first before we continue dropping the legacy platform data. I also noticed we need two fixes for the ti-sysc driver while looking at the warnings. Tony, Apart from Patch 2(breaks DS0 on AM3). Rest all work fine. Tested for DS0/RTC+ddr on AM4, DS0 on AM3 Boneblack. You can add my: Tested-by: Keerthy For all the 7 patches except Patch 2. Regards, Keerthy Regards, Tony Tony Lindgren (8): ARM: OMAP2+: Fix missing SYSC_HAS_RESET_STATUS for dra7 epwmss ARM: OMAP2+: Remove unconfigured midlemode for am3 lcdc bus: ti-sysc: Fix handling of forced idle bus: ti-sysc: Fix using configured sysc mask value ARM: dts: Drop bogus ahclkr clocks for dra7 mcasp 3 to 8 ARM: dts: Fix flags for gpio7 ARM: dts: Fix incorrect dcan register mapping for am3, am4 and dra7 ARM: dts: Fix lcdc sysc flags for am3 arch/arm/boot/dts/am33xx-l4.dtsi | 6 +++- arch/arm/boot/dts/am437x-l4.dtsi | 4 +++ .../boot/dts/am57xx-beagle-x15-common.dtsi| 2 +- arch/arm/boot/dts/dra7-evm.dts| 2 +- arch/arm/boot/dts/dra7-l4.dtsi| 31 --- arch/arm/mach-omap2/omap_hwmod_33xx_data.c| 2 +- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 3 +- drivers/bus/ti-sysc.c | 10 +++--- 8 files changed, 31 insertions(+), 29 deletions(-)
Re: [PATCH 2/8] ARM: OMAP2+: Remove unconfigured midlemode for am3 lcdc
On 24/07/19 12:33 AM, Suman Anna wrote:
+ Jyri
On 7/23/19 6:28 AM, Tony Lindgren wrote:
We currently get a warning for lcdc because of a difference
with dts provided configuration compared to the legacy platform
data. This is because lcdc has SYSC_HAS_MIDLEMODE configured in
the platform data without configuring the modes.
Hi Tony,
While I understand that you are trying to match the DT data with the
existing legacy data, do you know if there was a reason why this was
omitted in the first place? Should we be really adding the MSTANDBY_
flags and fix up the DTS node accordingly? I tried looking through the
git log, and the initial commit itself didn't add the MSTANDBY_ flags
but used the SYSC_HAS_MIDLEMODE.
Jyri,
Do you know the history?
Tony/Suman,
This patch breaks DS0 on am3.
- Keerthy
regards
Suman
Let's fix the warning by removing SYSC_HAS_MIDLEMODE. Note that
the am335x TRM lists SYSC_HAS_MIDLEMODE, but it is unused.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -231,7 +231,7 @@ static struct omap_hwmod am33xx_control_hwmod = {
static struct omap_hwmod_class_sysconfig lcdc_sysc = {
.rev_offs = 0x0,
.sysc_offs = 0x54,
- .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
+ .sysc_flags = SYSC_HAS_SIDLEMODE,
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= _hwmod_sysc_type2,
};
Re: [PATCH v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for ARCH_K3
On 29/06/19 2:07 AM, Nishanth Menon wrote: On 09:08-20190628, Keerthy wrote: [..] + select GPIO_SYSFS + select GPIO_DAVINCI Could you help explain the logic of doing this? commit message is basically the diff in English. To me, this does NOT make sense. I understand GPIO_DAVINCI is the driver compatible, but we cant do this for every single SoC driver that is NOT absolutely mandatory for basic functionality. In case of ARM64 could you help me find the right place to enable such SoC specific configs? Is'nt that what defconfig is supposed to be all about? arch/arm64/configs/defconfig Also keep in mind the impact to arm64/configs/defconfig -> every single SoC in the arm64 world will be now rebuild with GPIO_SYSFS.. why force that? This was the practice in arm32 soc specific configs like omap2plus_defconfig. GPIO_SYSFS was he only way to validate. Now i totally understand your concern about every single SoC rebuilding but now where do we need to enable the bare minimal GPIO_DAVINCI config? Well, SYSFS, I cannot agree testing as the rationale in Kconfig.platform. And, looking at [1], I see majority being mandatory components for the SoC bootup. However, most of the "optional" drivers go into arm64 as defconfig (preferably as a module?) and if you find a rationale for recommending DEBUG_GPIO, you could propose that to the community as well. Now, Thinking about this, I'd even challenge the current list of configs as being "select". I'd rather do an "imply"[2] - yes, you need this for the default dtb to boot, however a carefully carved dtb could boot with lesser driver set to get a smaller (and less functional) kernel. v1 i received feedback from Tero to enable in Kconfig.platforms. Hence i shifted to this approach. I noticed that you were posting a v2, for future reference, please use diffstat section to point to lore/patchworks link to point at v1 (I did notice you mentioned you had an update, thanks - link will help catch up on older discussions). This helps a later revision reviewer like me to get context. Tero, would you be able to help with a better rationale as to where the boundaries are to be in your mind, rather than risk every single peripheral driver getting into ARCH_K3? Tero, Could you point me to a better place for enabling? - Keerthy As of right now, I'd rather we do not explode the current list out of bounds. NAK unless we can find a better rationale. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/Kconfig.platforms [2] https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt
[PATCH] gpio: davinci: silence error prints in case of EPROBE_DEFER
Silence error prints in case of EPROBE_DEFER. This avoids
multiple/duplicate defer prints during boot.
Signed-off-by: Keerthy
---
drivers/gpio/gpio-davinci.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index fc494a84a29d..e0b025689625 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -238,8 +238,9 @@ static int davinci_gpio_probe(struct platform_device *pdev)
for (i = 0; i < nirq; i++) {
chips->irqs[i] = platform_get_irq(pdev, i);
if (chips->irqs[i] < 0) {
- dev_info(dev, "IRQ not populated, err = %d\n",
-chips->irqs[i]);
+ if (chips->irqs[i] != -EPROBE_DEFER)
+ dev_info(dev, "IRQ not populated, err = %d\n",
+chips->irqs[i]);
return chips->irqs[i];
}
}
--
2.17.1
Re: [PATCH][next] regulator: lp87565: fix missing break in switch statement
On 02/07/19 5:01 PM, Lee Jones wrote: On Tue, 02 Jul 2019, Colin Ian King wrote: On 02/07/2019 11:44, Lee Jones wrote: On Fri, 28 Jun 2019, Colin Ian King wrote: On 28/06/2019 15:36, Mark Brown wrote: On Thu, Jun 27, 2019 at 02:16:39PM +0100, Colin King wrote: From: Colin Ian King Currently the LP87565_DEVICE_TYPE_LP87561_Q1 case does not have a break statement, causing it to fall through to a dev_err message. Fix this by adding in the missing break statement. This doesn't apply against current code, please check and resend. So it applies cleanly against linux-next, I think the original code landed in mfd/for-mfd-next - c.f. https://lkml.org/lkml/2019/5/28/550 Applied, thanks Colin. I'm confused, who is the official maintainer of the regulator patches nowadays? Mark. But the patch you're fixing is currently in the MFD tree. I sent him an updated pull-request. Thanks Lee! Don't worry mate, you're in good hands. ;)
Re: [PATCH 00/10] crypto: k3: Add sa2ul driver
On 28/06/19 9:49 AM, Herbert Xu wrote: On Tue, Jun 18, 2019 at 05:38:33PM +0530, Keerthy wrote: The series adds Crypto hardware accelerator support for SA2UL. SA2UL stands for security accelerator ultra lite. Please cc linux-cry...@vger.kernel.org. Okay. I will do that. Thanks,
Re: [PATCH v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for ARCH_K3
On 27/06/19 8:02 PM, Nishanth Menon wrote: On 16:39-20190627, Keerthy wrote: Enable GPIO_DAVINCI and related configs for TI K3 AM6 platforms. Signed-off-by: Keerthy --- Changes in v2: * Enabling configs in Kconfig.platforms file instead of defconfig. * Removed GPIO_DEBUG config. arch/arm64/Kconfig.platforms | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 4778c775de1b..6e43a0995ed4 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -97,6 +97,8 @@ config ARCH_K3 select TI_SCI_PROTOCOL select TI_SCI_INTR_IRQCHIP select TI_SCI_INTA_IRQCHIP + select GPIO_SYSFS + select GPIO_DAVINCI Could you help explain the logic of doing this? commit message is basically the diff in English. To me, this does NOT make sense. I understand GPIO_DAVINCI is the driver compatible, but we cant do this for every single SoC driver that is NOT absolutely mandatory for basic functionality. In case of ARM64 could you help me find the right place to enable such SoC specific configs? Also keep in mind the impact to arm64/configs/defconfig -> every single SoC in the arm64 world will be now rebuild with GPIO_SYSFS.. why force that? This was the practice in arm32 soc specific configs like omap2plus_defconfig. GPIO_SYSFS was he only way to validate. Now i totally understand your concern about every single SoC rebuilding but now where do we need to enable the bare minimal GPIO_DAVINCI config? v1 i received feedback from Tero to enable in Kconfig.platforms. Hence i shifted to this approach.
Re: [PATCH][next] regulator: lp87565: fix missing break in switch statement
On 27/06/19 6:46 PM, Colin King wrote:
From: Colin Ian King
Currently the LP87565_DEVICE_TYPE_LP87561_Q1 case does not have a
break statement, causing it to fall through to a dev_err message.
Fix this by adding in the missing break statement.
Addresses-Coverity: ("Missing break in switch")
Fixes: 7ee63bd74750 ("regulator: lp87565: Add 4-phase lp87561 regulator
support")
Signed-off-by: Colin Ian King
---
drivers/regulator/lp87565-regulator.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/regulator/lp87565-regulator.c
b/drivers/regulator/lp87565-regulator.c
index 993c11702083..5d067f7c2116 100644
--- a/drivers/regulator/lp87565-regulator.c
+++ b/drivers/regulator/lp87565-regulator.c
@@ -180,6 +180,7 @@ static int lp87565_regulator_probe(struct platform_device
*pdev)
case LP87565_DEVICE_TYPE_LP87561_Q1:
min_idx = LP87565_BUCK_3210;
max_idx = LP87565_BUCK_3210;
+ break;
Thanks Colin.
Reviewed-by: Keerthy
default:
dev_err(lp87565->dev, "Invalid lp config %d\n",
lp87565->dev_type);
[PATCH v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for ARCH_K3
Enable GPIO_DAVINCI and related configs for TI K3 AM6 platforms. Signed-off-by: Keerthy --- Changes in v2: * Enabling configs in Kconfig.platforms file instead of defconfig. * Removed GPIO_DEBUG config. arch/arm64/Kconfig.platforms | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 4778c775de1b..6e43a0995ed4 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -97,6 +97,8 @@ config ARCH_K3 select TI_SCI_PROTOCOL select TI_SCI_INTR_IRQCHIP select TI_SCI_INTA_IRQCHIP + select GPIO_SYSFS + select GPIO_DAVINCI help This enables support for Texas Instruments' K3 multicore SoC architecture. -- 2.17.1
Re: linux-next: build warning after merge of the mfd tree
On 27/06/19 10:41 AM, Stephen Rothwell wrote:
Hi Lee,
After merging the mfd tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
drivers/regulator/lp87565-regulator.c: In function 'lp87565_regulator_probe':
drivers/regulator/lp87565-regulator.c:182:11: warning: this statement may fall
through [-Wimplicit-fallthrough=]
max_idx = LP87565_BUCK_3210;
Missed adding a break here. Can i send a patch on top of linux-next?
^~~
drivers/regulator/lp87565-regulator.c:183:2: note: here
default:
^~~
Introduced by commit
7ee63bd74750 ("regulator: lp87565: Add 4-phase lp87561 regulator support")
I get these warnings because I am building with -Wimplicit-fallthrough
in attempt to catch new additions early. The gcc warning can be turned
off by adding a /* fall through */ comment at the point the fall through
happens (assuming that the fall through is intentional).
[PATCH] soc: ti: pm33xx: Fix static checker warnings
The patch fixes a bunch of static checker warnings.
Reported-by: Dan Carpenter
Signed-off-by: Keerthy
---
drivers/soc/ti/pm33xx.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/ti/pm33xx.c b/drivers/soc/ti/pm33xx.c
index bb77c220b6f8..5f3a4499cf40 100644
--- a/drivers/soc/ti/pm33xx.c
+++ b/drivers/soc/ti/pm33xx.c
@@ -252,7 +252,7 @@ static int am33xx_pm_begin(suspend_state_t state)
if (state == PM_SUSPEND_MEM && pm_ops->check_off_mode_enable()) {
nvmem = devm_nvmem_device_get(_rtc->dev,
"omap_rtc_scratch0");
- if (nvmem)
+ if (!IS_ERR(nvmem))
nvmem_device_write(nvmem, RTC_SCRATCH_MAGIC_REG * 4, 4,
(void *)_magic_val);
rtc_only_idle = 1;
@@ -278,9 +278,12 @@ static void am33xx_pm_end(void)
struct nvmem_device *nvmem;
nvmem = devm_nvmem_device_get(_rtc->dev, "omap_rtc_scratch0");
+ if (IS_ERR(nvmem))
+ return;
+
m3_ipc->ops->finish_low_power(m3_ipc);
if (rtc_only_idle) {
- if (retrigger_irq)
+ if (retrigger_irq) {
/*
* 32 bits of Interrupt Set-Pending correspond to 32
* 32 interrupts. Compute the bit offset of the
@@ -291,8 +294,10 @@ static void am33xx_pm_end(void)
writel_relaxed(1 << (retrigger_irq & 31),
gic_dist_base + GIC_INT_SET_PENDING_BASE
+ retrigger_irq / 32 * 4);
- nvmem_device_write(nvmem, RTC_SCRATCH_MAGIC_REG * 4, 4,
- (void *));
+ }
+
+ nvmem_device_write(nvmem, RTC_SCRATCH_MAGIC_REG * 4, 4,
+ (void *));
}
rtc_only_idle = 0;
@@ -415,7 +420,7 @@ static int am33xx_pm_rtc_setup(void)
nvmem = devm_nvmem_device_get(_rtc->dev,
"omap_rtc_scratch0");
- if (nvmem) {
+ if (!IS_ERR(nvmem)) {
nvmem_device_read(nvmem, RTC_SCRATCH_MAGIC_REG * 4,
4, (void *)_magic_val);
if ((rtc_magic_val & 0x) != RTC_REG_BOOT_MAGIC)
--
2.17.1
Re: [PATCH V2] net: ethernet: ti: cpsw: Fix suspend/resume break
On 6/24/2019 7:53 PM, David Miller wrote:
From: Keerthy
Date: Mon, 24 Jun 2019 10:46:19 +0530
Commit bfe59032bd6127ee190edb30be9381a01765b958 ("net: ethernet:
ti: cpsw: use cpsw as drv data")changes
the driver data to struct cpsw_common *cpsw. This is done
only in probe/remove but the suspend/resume functions are
still left with struct net_device *ndev. Hence fix both
suspend & resume also to fetch the updated driver data.
Fixes: bfe59032bd6127ee1 ("net: ethernet: ti: cpsw: use cpsw as drv data")
Signed-off-by: Keerthy
Applied but please make it clear that changes are targetting net-next in the
future by saying "[PATCH net-next v2] " in your Subject line.
Sure will do that. Thanks.
Thank you.
[PATCH V2] net: ethernet: ti: cpsw: Fix suspend/resume break
Commit bfe59032bd6127ee190edb30be9381a01765b958 ("net: ethernet:
ti: cpsw: use cpsw as drv data")changes
the driver data to struct cpsw_common *cpsw. This is done
only in probe/remove but the suspend/resume functions are
still left with struct net_device *ndev. Hence fix both
suspend & resume also to fetch the updated driver data.
Fixes: bfe59032bd6127ee1 ("net: ethernet: ti: cpsw: use cpsw as drv data")
Signed-off-by: Keerthy
---
Change in v2:
* Added NULL Checks for cpsw->slaves[i].ndev in suspend/resume functions.
drivers/net/ethernet/ti/cpsw.c | 30 +-
1 file changed, 9 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 7bdd287074fc..32b7b3b74a6b 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2590,20 +2590,13 @@ static int cpsw_remove(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int cpsw_suspend(struct device *dev)
{
- struct net_device *ndev = dev_get_drvdata(dev);
- struct cpsw_common *cpsw = ndev_to_cpsw(ndev);
-
- if (cpsw->data.dual_emac) {
- int i;
+ struct cpsw_common *cpsw = dev_get_drvdata(dev);
+ int i;
- for (i = 0; i < cpsw->data.slaves; i++) {
+ for (i = 0; i < cpsw->data.slaves; i++)
+ if (cpsw->slaves[i].ndev)
if (netif_running(cpsw->slaves[i].ndev))
cpsw_ndo_stop(cpsw->slaves[i].ndev);
- }
- } else {
- if (netif_running(ndev))
- cpsw_ndo_stop(ndev);
- }
/* Select sleep pin state */
pinctrl_pm_select_sleep_state(dev);
@@ -2613,25 +2606,20 @@ static int cpsw_suspend(struct device *dev)
static int cpsw_resume(struct device *dev)
{
- struct net_device *ndev = dev_get_drvdata(dev);
- struct cpsw_common *cpsw = ndev_to_cpsw(ndev);
+ struct cpsw_common *cpsw = dev_get_drvdata(dev);
+ int i;
/* Select default pin state */
pinctrl_pm_select_default_state(dev);
/* shut up ASSERT_RTNL() warning in netif_set_real_num_tx/rx_queues */
rtnl_lock();
- if (cpsw->data.dual_emac) {
- int i;
- for (i = 0; i < cpsw->data.slaves; i++) {
+ for (i = 0; i < cpsw->data.slaves; i++)
+ if (cpsw->slaves[i].ndev)
if (netif_running(cpsw->slaves[i].ndev))
cpsw_ndo_open(cpsw->slaves[i].ndev);
- }
- } else {
- if (netif_running(ndev))
- cpsw_ndo_open(ndev);
- }
+
rtnl_unlock();
return 0;
--
2.17.1
[PATCH] net: ethernet: ti: cpsw: Fix suspend/resume break
Commit bfe59032bd6127ee190edb30be9381a01765b958 ("net: ethernet:
ti: cpsw: use cpsw as drv data")changes
the driver data to struct cpsw_common *cpsw. This is done
only in probe/remove but the suspend/resume functions are
still left with struct net_device *ndev. Hence fix both
suspend & resume also to fetch the updated driver data.
Fixes: bfe59032bd6127ee1 ("net: ethernet: ti: cpsw: use cpsw as drv data")
Signed-off-by: Keerthy
---
drivers/net/ethernet/ti/cpsw.c | 36 +++---
1 file changed, 11 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 7bdd287074fc..2aeaad15e20e 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2590,20 +2590,12 @@ static int cpsw_remove(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int cpsw_suspend(struct device *dev)
{
- struct net_device *ndev = dev_get_drvdata(dev);
- struct cpsw_common *cpsw = ndev_to_cpsw(ndev);
-
- if (cpsw->data.dual_emac) {
- int i;
+ struct cpsw_common *cpsw = dev_get_drvdata(dev);
+ int i;
- for (i = 0; i < cpsw->data.slaves; i++) {
- if (netif_running(cpsw->slaves[i].ndev))
- cpsw_ndo_stop(cpsw->slaves[i].ndev);
- }
- } else {
- if (netif_running(ndev))
- cpsw_ndo_stop(ndev);
- }
+ for (i = 0; i < cpsw->data.slaves; i++)
+ if (netif_running(cpsw->slaves[i].ndev))
+ cpsw_ndo_stop(cpsw->slaves[i].ndev);
/* Select sleep pin state */
pinctrl_pm_select_sleep_state(dev);
@@ -2613,25 +2605,19 @@ static int cpsw_suspend(struct device *dev)
static int cpsw_resume(struct device *dev)
{
- struct net_device *ndev = dev_get_drvdata(dev);
- struct cpsw_common *cpsw = ndev_to_cpsw(ndev);
+ struct cpsw_common *cpsw = dev_get_drvdata(dev);
+ int i;
/* Select default pin state */
pinctrl_pm_select_default_state(dev);
/* shut up ASSERT_RTNL() warning in netif_set_real_num_tx/rx_queues */
rtnl_lock();
- if (cpsw->data.dual_emac) {
- int i;
- for (i = 0; i < cpsw->data.slaves; i++) {
- if (netif_running(cpsw->slaves[i].ndev))
- cpsw_ndo_open(cpsw->slaves[i].ndev);
- }
- } else {
- if (netif_running(ndev))
- cpsw_ndo_open(ndev);
- }
+ for (i = 0; i < cpsw->data.slaves; i++)
+ if (netif_running(cpsw->slaves[i].ndev))
+ cpsw_ndo_open(cpsw->slaves[i].ndev);
+
rtnl_unlock();
return 0;
--
2.17.1
[PATCH 03/10] crypto: sa2ul: Add AES ECB Mode support
Add support for AES algorithm in ECB Mode. Data encryption modes
are supported via MCE engine (programmable mode control engine).
ECB (Electronic code book) is a mode of operation for a block cipher,
with the characteristic that each possible block of plaintext has a
defined corresponding ciphertext value and vice versa. In other words,
the same plaintext value will always result in the same ciphertext value.
Signed-off-by: Keerthy
---
drivers/crypto/sa2ul.c | 76 ++
1 file changed, 76 insertions(+)
diff --git a/drivers/crypto/sa2ul.c b/drivers/crypto/sa2ul.c
index 64bdf6b2b879..a17c1f66c5c1 100644
--- a/drivers/crypto/sa2ul.c
+++ b/drivers/crypto/sa2ul.c
@@ -178,6 +178,38 @@ static u8 mci_cbc_dec_array[3][MODE_CONTROL_BYTES] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
};
+/*
+ * Mode Control Instructions for various Key lengths 128, 192, 256
+ * For ECB (Electronic Code Book) mode for encryption
+ */
+static u8 mci_ecb_enc_array[3][27] = {
+ { 0x21, 0x00, 0x00, 0x80, 0x8a, 0x04, 0xb7, 0x90, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+ { 0x21, 0x00, 0x00, 0x84, 0x8a, 0x04, 0xb7, 0x90, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+ { 0x21, 0x00, 0x00, 0x88, 0x8a, 0x04, 0xb7, 0x90, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+};
+
+/*
+ * Mode Control Instructions for various Key lengths 128, 192, 256
+ * For ECB (Electronic Code Book) mode for decryption
+ */
+static u8 mci_ecb_dec_array[3][27] = {
+ { 0x31, 0x00, 0x00, 0x80, 0x8a, 0x04, 0xb7, 0x90, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+ { 0x31, 0x00, 0x00, 0x84, 0x8a, 0x04, 0xb7, 0x90, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+ { 0x31, 0x00, 0x00, 0x88, 0x8a, 0x04, 0xb7, 0x90, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
+};
+
/*
* Perform 16 byte or 128 bit swizzling
* The SA2UL Expects the security context to
@@ -746,6 +778,26 @@ static int sa_aes_cbc_setkey(struct crypto_ablkcipher
*tfm, const u8 *key,
return sa_aes_setkey(tfm, key, keylen, ad);
}
+static int sa_aes_ecb_setkey(struct crypto_ablkcipher *tfm, const u8 *key,
+unsigned int keylen)
+{
+ struct algo_data *ad = kzalloc(sizeof(*ad), GFP_KERNEL);
+ /* Convert the key size (16/24/32) to the key size index (0/1/2) */
+ int key_idx = (keylen >> 3) - 2;
+
+ ad->enc_eng.eng_id = SA_ENG_ID_EM1;
+ ad->enc_eng.sc_size = SA_CTX_ENC_TYPE1_SZ;
+ ad->auth_eng.eng_id = SA_ENG_ID_NONE;
+ ad->auth_eng.sc_size = 0;
+ ad->mci_enc = mci_ecb_enc_array[key_idx];
+ ad->mci_dec = mci_ecb_dec_array[key_idx];
+ ad->inv_key = true;
+ ad->ealg_id = SA_EALG_ID_AES_ECB;
+ ad->aalg_id = SA_AALG_ID_NONE;
+
+ return sa_aes_setkey(tfm, key, keylen, ad);
+}
+
static void sa_aes_dma_in_callback(void *data)
{
struct sa_rx_data *rxd = (struct sa_rx_data *)data;
@@ -940,6 +992,30 @@ static struct sa_alg_tmpl sa_algs[] = {
}
}
},
+ { .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
+ .alg.crypto = {
+ .cra_name = "ecb(aes)",
+ .cra_driver_name = "ecb-aes-sa2ul",
+ .cra_priority = 3,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+ CRYPTO_ALG_KERN_DRIVER_ONLY |
+ CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK,
+ .cra_blocksize = AES_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct sa_tfm_ctx),
+ .cra_alignmask = 0,
+ .cra_type = _ablkcipher_type,
+ .cra_module = THIS_MODULE,
+ .cra_init = sa_aes_cra_init,
+ .cra_exit = sa_aes_cra_exit,
+ .cra_u.ablkcipher = {
+ .min_keysize= AES_MIN_KEY_SIZE,
+ .max_keysize= AES_MAX_KEY_SIZE,
+ .setkey = sa_aes_ecb_setkey,
+ .encrypt= sa_aes_cbc_encrypt,
+
[PATCH 02/10] crypto: sa2ul: Add crypto driver
The Security Accelerator (SA2_UL) subsystem provides hardware
cryptographic acceleration for the following use cases:
• Encryption and authentication for secure boot
• Encryption and authentication of content in applications
requiring DRM (digital rights management) and
content/asset protection
The device includes one instantiation of SA2_UL named SA2_UL0
SA2_UL supports the following cryptographic industry standards to enable data
authentication, data
integrity and data confidentiality.
Crypto function library for software acceleration
o AES operation
o 3DES operation
o SHA1 operation
o MD5 operation
o SHA2 – 224, 256, 384, 512 operation
Authentication supported via following hardware cores
o SHA1
o MD5
o SHA2 -224
o SHA2-256
o SHA2-384
o SHA2-512
Patch adds a basic crypto driver and currently supports AES
in cbc mode for both encryption and decryption.
Signed-off-by: Keerthy
---
drivers/crypto/Kconfig | 17 +
drivers/crypto/Makefile |1 +
drivers/crypto/sa2ul.c | 1151 +++
drivers/crypto/sa2ul.h | 384 +
4 files changed, 1553 insertions(+)
create mode 100644 drivers/crypto/sa2ul.c
create mode 100644 drivers/crypto/sa2ul.h
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 603413f28fa3..b9a3fa026c74 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -785,4 +785,21 @@ config CRYPTO_DEV_CCREE
source "drivers/crypto/hisilicon/Kconfig"
+config CRYPTO_DEV_SA2UL
+ tristate "Support for TI security accelerator"
+ depends on ARCH_K3 || COMPILE_TEST
+ select ARM64_CRYPTO
+ select CRYPTO_AES
+ select CRYPTO_AES_ARM64
+ select CRYPTO_SHA1
+ select CRYPTO_MD5
+ select CRYPTO_ALGAPI
+ select CRYPTO_AUTHENC
+ select HW_RANDOM
+ default m if ARCH_K3
+ help
+ Keystone devices include a security accelerator engine that may be
+ used for crypto offload. Select this if you want to use hardware
+ acceleration for cryptographic algorithms on these devices.
+
endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index afc4753b5d28..300d31fd24db 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -47,4 +47,5 @@ obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
obj-$(CONFIG_CRYPTO_DEV_BCM_SPU) += bcm/
obj-$(CONFIG_CRYPTO_DEV_SAFEXCEL) += inside-secure/
obj-$(CONFIG_CRYPTO_DEV_ARTPEC6) += axis/
+obj-$(CONFIG_CRYPTO_DEV_SA2UL) += sa2ul.o
obj-y += hisilicon/
diff --git a/drivers/crypto/sa2ul.c b/drivers/crypto/sa2ul.c
new file mode 100644
index ..64bdf6b2b879
--- /dev/null
+++ b/drivers/crypto/sa2ul.c
@@ -0,0 +1,1151 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AM6 SA2UL crypto accelerator driver
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Authors:Keerthy
+ * Vitaly Andrianov
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sa2ul.h"
+
+/* Byte offset for key in encryption security context */
+#define SC_ENC_KEY_OFFSET (1 + 27 + 4)
+/* Byte offset for Aux-1 in encryption security context */
+#define SC_ENC_AUX1_OFFSET (1 + 27 + 4 + 32)
+
+#define SA_CMDL_UPD_ENC 0x0001
+#define SA_CMDL_UPD_AUTH0x0002
+#define SA_CMDL_UPD_ENC_IV 0x0004
+#define SA_CMDL_UPD_AUTH_IV 0x0008
+#define SA_CMDL_UPD_AUX_KEY 0x0010
+
+#define SA_AUTH_SUBKEY_LEN 16
+#define SA_CMDL_PAYLOAD_LENGTH_MASK0x
+#define SA_CMDL_SOP_BYPASS_LEN_MASK0xFF00
+
+#define MODE_CONTROL_BYTES 27
+#define SA_HASH_PROCESSING 0
+#define SA_CRYPTO_PROCESSING 0
+#define SA_UPLOAD_HASH_TO_TLR BIT(6)
+
+#define SA_SW0_FLAGS_MASK 0xF
+#define SA_SW0_CMDL_INFO_MASK 0x1F0
+#define SA_SW0_CMDL_PRESENTBIT(4)
+#define SA_SW0_ENG_ID_MASK 0x3E00
+#define SA_SW0_DEST_INFO_PRESENT BIT(30)
+#define SA_SW2_EGRESS_LENGTH 0xFF00
+
+#define SHA256_DIGEST_WORDS8
+/* Make 32-bit word from 4 bytes */
+#define SA_MK_U32(b0, b1, b2, b3) (((b0) << 24) | ((b1) << 16) | \
+ ((b2) << 8) | (b3))
+
+/* size of SCCTL structure in bytes */
+#define SA_SCCTL_SZ 16
+
+/* Max Authentication tag size */
+#define SA_MAX_AUTH_TAG_SZ 64
+
+#define PRIV_ID0x1
+#define PRIV 0x1
+
+static struct device *sa_k3_dev;
+
+/**
+ * struct sa_cmdl_cfg - Command label configuration descriptor
+ * @enc1st: If the iteration needs encryption before authentication
+ * @aalg: authentication algorithm ID
+ * @enc_eng_id: Encryption Engine ID supported by the SA hardware
+ * @auth_eng_id: authentication Engine ID
+ * @iv_size: Initialization Vector size
+ * @akey: Authentication key
+ * @akey_len: Authentication key length
+ */
+struct sa_cmdl_cfg {
+ int enc1st;
+ int aal
[PATCH 09/10] sa2ul: Add 3DES ECB & CBC Mode support
Triple DES (3DES), officially the Triple Data Encryption Algorithm
(TDEA or Triple DEA), is a symmetric-key block cipher, which applies
the DES cipher algorithm three times to each data block
Add 3DES ECB(Electronic code book) & CBC(Cipher Block Chaining)
Mode support.
Signed-off-by: Keerthy
---
drivers/crypto/sa2ul.c | 112 +
1 file changed, 112 insertions(+)
diff --git a/drivers/crypto/sa2ul.c b/drivers/crypto/sa2ul.c
index 74211cd21c62..8d535fc9867f 100644
--- a/drivers/crypto/sa2ul.c
+++ b/drivers/crypto/sa2ul.c
@@ -210,6 +210,35 @@ static u8 mci_ecb_dec_array[3][27] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
};
+/*
+ * Mode Control Instructions for DES algorithm
+ * For CBC (Cipher Block Chaining) mode and ECB mode
+ * encryption and for decryption respectively
+ */
+static u8 mci_cbc_3des_enc_array[MODE_CONTROL_BYTES] = {
+ 0x20, 0x00, 0x00, 0x18, 0x88, 0x52, 0xaa, 0x4b, 0x7e, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00,
+};
+
+static u8 mci_cbc_3des_dec_array[MODE_CONTROL_BYTES] = {
+ 0x30, 0x00, 0x00, 0x85, 0x0a, 0xca, 0x98, 0xf4, 0x40, 0xc0, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00,
+};
+
+static u8 mci_ecb_3des_enc_array[MODE_CONTROL_BYTES] = {
+ 0x20, 0x00, 0x00, 0x85, 0x0a, 0x04, 0xb7, 0x90, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00,
+};
+
+static u8 mci_ecb_3des_dec_array[MODE_CONTROL_BYTES] = {
+ 0x30, 0x00, 0x00, 0x85, 0x0a, 0x04, 0xb7, 0x90, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00,
+};
+
/*
* Perform 16 byte or 128 bit swizzling
* The SA2UL Expects the security context to
@@ -877,6 +906,39 @@ static int sa_aes_ecb_setkey(struct crypto_ablkcipher
*tfm, const u8 *key,
return sa_aes_setkey(tfm, key, keylen, ad);
}
+static int sa_3des_cbc_setkey(struct crypto_ablkcipher *tfm, const u8 *key,
+ unsigned int keylen)
+{
+ struct algo_data *ad = kzalloc(sizeof(*ad), GFP_KERNEL);
+
+ ad->enc_eng.eng_id = SA_ENG_ID_EM1;
+ ad->enc_eng.sc_size = SA_CTX_ENC_TYPE1_SZ;
+ ad->auth_eng.eng_id = SA_ENG_ID_NONE;
+ ad->auth_eng.sc_size = 0;
+ ad->mci_enc = mci_cbc_3des_enc_array;
+ ad->mci_dec = mci_cbc_3des_dec_array;
+ ad->ealg_id = SA_EALG_ID_3DES_CBC;
+ ad->aalg_id = SA_AALG_ID_NONE;
+
+ return sa_aes_setkey(tfm, key, keylen, ad);
+}
+
+static int sa_3des_ecb_setkey(struct crypto_ablkcipher *tfm, const u8 *key,
+ unsigned int keylen)
+{
+ struct algo_data *ad = kzalloc(sizeof(*ad), GFP_KERNEL);
+
+ ad->enc_eng.eng_id = SA_ENG_ID_EM1;
+ ad->enc_eng.sc_size = SA_CTX_ENC_TYPE1_SZ;
+ ad->auth_eng.eng_id = SA_ENG_ID_NONE;
+ ad->auth_eng.sc_size = 0;
+ ad->mci_enc = mci_ecb_3des_enc_array;
+ ad->mci_dec = mci_ecb_3des_dec_array;
+ ad->aalg_id = SA_AALG_ID_NONE;
+
+ return sa_aes_setkey(tfm, key, keylen, ad);
+}
+
static void sa_aes_dma_in_callback(void *data)
{
struct sa_rx_data *rxd = (struct sa_rx_data *)data;
@@ -1787,6 +1849,56 @@ static struct sa_alg_tmpl sa_algs[] = {
}
}
},
+ { .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
+ .alg.crypto = {
+ .cra_name = "cbc(des3_ede)",
+ .cra_driver_name = "cbc-des3-sa2ul",
+ .cra_priority = 3,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+ CRYPTO_ALG_KERN_DRIVER_ONLY |
+ CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK,
+ .cra_blocksize = DES_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct sa_tfm_ctx),
+ .cra_alignmask = 0,
+ .cra_type = _ablkcipher_type,
+ .cra_module = THIS_MODULE,
+ .cra_init = sa_aes_cra_init,
+ .cra_exit = sa_aes_cra_exit,
+ .cra_u.ablkcipher = {
+ .min_keysize= 3 * DES_KEY_SIZE,
+ .max_keysize= 3 * DES_KEY_SIZE,
+ .ivsize = DES_BLOCK_SIZE,
+ .setkey = sa_3des_cbc_setkey,
+ .encrypt= sa_aes_cbc_encrypt,
+ .decrypt= sa_aes_cbc_decrypt,
+ }
+ }
+ },
+ { .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
+
[PATCH 08/10] crypto: sa2ul: Add hmac(sha256) HMAC algorithm support
HMAC hash-based message authentication code) is a specific type of
message authentication code (MAC) involving a cryptographic hash
function and a secret cryptographic key. It may be used to
simultaneously verify both the data integrity and the authentication
of a message, as with any MAC. Add hmac(sha256) HMAC algorithm support
and the message digest size is 32 bytes.
Signed-off-by: Keerthy
---
drivers/crypto/sa2ul.c | 52 ++
1 file changed, 52 insertions(+)
diff --git a/drivers/crypto/sa2ul.c b/drivers/crypto/sa2ul.c
index e3a1321f0666..74211cd21c62 100644
--- a/drivers/crypto/sa2ul.c
+++ b/drivers/crypto/sa2ul.c
@@ -1673,11 +1673,38 @@ static int sa_sham_sha1_setkey(struct crypto_ahash
*tfm, const u8 *key,
return sa_sham_setkey(tfm, key, keylen, ad);
}
+static int sa_sham_sha256_setkey(struct crypto_ahash *tfm, const u8 *key,
+unsigned int keylen)
+{
+ struct algo_data *ad = kzalloc(sizeof(*ad), GFP_KERNEL);
+
+ ad->enc_eng.eng_id = SA_ENG_ID_NONE;
+ ad->enc_eng.sc_size = SA_CTX_ENC_TYPE1_SZ;
+ ad->auth_eng.eng_id = SA_ENG_ID_AM1;
+ ad->auth_eng.sc_size = SA_CTX_AUTH_TYPE2_SZ;
+ ad->mci_enc = NULL;
+ ad->mci_dec = NULL;
+ ad->inv_key = false;
+ ad->keyed_mac = true;
+ ad->ealg_id = SA_EALG_ID_NONE;
+ ad->aalg_id = SA_AALG_ID_HMAC_SHA2_256;
+ ad->hash_size = SHA256_DIGEST_SIZE;
+ ad->auth_ctrl = 0x4;
+ ad->prep_iopad = sa_hmac_sha256_get_pad;
+
+ return sa_sham_setkey(tfm, key, keylen, ad);
+}
+
static int sa_sham_cra_sha1_init(struct crypto_tfm *tfm)
{
return sa_sham_cra_init_alg(tfm, "sha1");
}
+static int sa_sham_cra_sha256_init(struct crypto_tfm *tfm)
+{
+ return sa_sham_cra_init_alg(tfm, "sha256");
+}
+
static void sa_sham_cra_exit(struct crypto_tfm *tfm)
{
struct crypto_alg *alg = tfm->__crt_alg;
@@ -1839,6 +1866,31 @@ static struct ahash_alg algs_sha[] = {
.cra_exit = sa_sham_cra_exit,
}
},
+{
+ .init = sa_sham_init,
+ .update = sa_sham_update,
+ .final = sa_sham_final,
+ .finup = sa_sham_finup,
+ .digest = sa_sham_digest,
+ .setkey = sa_sham_sha256_setkey,
+ .halg.digestsize= SHA256_DIGEST_SIZE,
+ .halg.statesize = 128,
+ .halg.base = {
+ .cra_name = "hmac(sha256)",
+ .cra_driver_name= "sa-hmac-sha256",
+ .cra_priority = 400,
+ .cra_flags = CRYPTO_ALG_TYPE_AHASH |
+ CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_KERN_DRIVER_ONLY |
+ CRYPTO_ALG_NEED_FALLBACK,
+ .cra_blocksize = SHA256_BLOCK_SIZE,
+ .cra_ctxsize= sizeof(struct sa_tfm_ctx),
+ .cra_alignmask = SA_ALIGN_MASK,
+ .cra_module = THIS_MODULE,
+ .cra_init = sa_sham_cra_sha256_init,
+ .cra_exit = sa_sham_cra_exit,
+ }
+},
};
/* Register the algorithms in crypto framework */
--
2.17.1
[PATCH 05/10] crypto: sha256_generic: Export the Transform function
The transform function can be used as is by other crypto
drivers that need to transform the 256 bit key using cpu.
Hence export it.
Signed-off-by: Keerthy
---
crypto/sha256_generic.c | 3 ++-
include/crypto/sha.h| 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/crypto/sha256_generic.c b/crypto/sha256_generic.c
index b7502a96a0d4..583a3c3b93e0 100644
--- a/crypto/sha256_generic.c
+++ b/crypto/sha256_generic.c
@@ -63,7 +63,7 @@ static inline void BLEND_OP(int I, u32 *W)
W[I] = s1(W[I-2]) + W[I-7] + s0(W[I-15]) + W[I-16];
}
-static void sha256_transform(u32 *state, const u8 *input)
+void sha256_transform(u32 *state, const u8 *input)
{
u32 a, b, c, d, e, f, g, h, t1, t2;
u32 W[64];
@@ -225,6 +225,7 @@ static void sha256_transform(u32 *state, const u8 *input)
a = b = c = d = e = f = g = h = t1 = t2 = 0;
memzero_explicit(W, 64 * sizeof(u32));
}
+EXPORT_SYMBOL(sha256_transform);
static void sha256_generic_block_fn(struct sha256_state *sst, u8 const *src,
int blocks)
diff --git a/include/crypto/sha.h b/include/crypto/sha.h
index 8a46202b1857..6e04f412b0c2 100644
--- a/include/crypto/sha.h
+++ b/include/crypto/sha.h
@@ -95,6 +95,7 @@ struct sha512_state {
struct shash_desc;
+extern void sha256_transform(u32 *state, const u8 *input);
extern int crypto_sha1_update(struct shash_desc *desc, const u8 *data,
unsigned int len);
--
2.17.1
[PATCH 06/10] crypto: sa2ul: Add hmac(sha256)cbc(aes) AEAD Algo support
Add aead support for hmac(sha256)cbc(aes) algorithm. Authenticated
encryption (AE) and authenticated encryption with associated data
(AEAD) is a form of encryption which simultaneously provides
confidentiality, integrity, and authenticity assurances on the data.
hmac(sha256) has a digest size of 32 bytes is used for authetication
and AES in CBC mode is used in conjunction for encryption/decryption.
Signed-off-by: Keerthy
---
drivers/crypto/sa2ul.c | 92 ++
1 file changed, 92 insertions(+)
diff --git a/drivers/crypto/sa2ul.c b/drivers/crypto/sa2ul.c
index 1a1bd882e0d2..9c9008e21867 100644
--- a/drivers/crypto/sa2ul.c
+++ b/drivers/crypto/sa2ul.c
@@ -271,6 +271,42 @@ void sa_hmac_sha1_get_pad(const u8 *key, u16 key_sz, u32
*ipad, u32 *opad)
opad[i] = cpu_to_be32(opad[i]);
}
+void sha256_init(u32 *buf)
+{
+ buf[0] = SHA256_H0;
+ buf[1] = SHA256_H1;
+ buf[2] = SHA256_H2;
+ buf[3] = SHA256_H3;
+ buf[4] = SHA256_H4;
+ buf[5] = SHA256_H5;
+ buf[6] = SHA256_H6;
+ buf[7] = SHA256_H7;
+}
+
+static void sa_hmac_sha256_get_pad(const u8 *key, u16 key_sz, u32 *ipad,
+ u32 *opad)
+{
+ u8 k_ipad[SHA_MESSAGE_BYTES];
+ u8 k_opad[SHA_MESSAGE_BYTES];
+ int i;
+
+ prepare_kiopad(k_ipad, k_opad, key, key_sz);
+
+ /* SHA-256 on k_ipad */
+ sha256_init(ipad);
+ sha256_transform(ipad, k_ipad);
+
+ for (i = 0; i < SHA256_DIGEST_WORDS; i++)
+ ipad[i] = cpu_to_be32(ipad[i]);
+
+ /* SHA-256 on k_opad */
+ sha256_init(opad);
+ sha256_transform(opad, k_opad);
+
+ for (i = 0; i < SHA256_DIGEST_WORDS; i++)
+ opad[i] = cpu_to_be32(opad[i]);
+}
+
/* Derive the inverse key used in AES-CBC decryption operation */
static inline int sa_aes_inv_key(u8 *inv_key, const u8 *key, u16 key_sz)
{
@@ -1198,6 +1234,37 @@ static int sa_aead_cbc_sha1_setkey(struct crypto_aead
*authenc,
return sa_aead_setkey(authenc, key, keylen, ad);
}
+static int sa_aead_cbc_sha256_setkey(struct crypto_aead *authenc,
+const u8 *key, unsigned int keylen)
+{
+ struct algo_data *ad = kzalloc(sizeof(*ad), GFP_KERNEL);
+ struct crypto_authenc_keys keys;
+ int ret = 0, key_idx;
+
+ ret = crypto_authenc_extractkeys(, key, keylen);
+ if (ret)
+ return ret;
+
+ /* Convert the key size (16/24/32) to the key size index (0/1/2) */
+ key_idx = (keys.enckeylen >> 3) - 2;
+
+ ad->enc_eng.eng_id = SA_ENG_ID_EM1;
+ ad->enc_eng.sc_size = SA_CTX_ENC_TYPE1_SZ;
+ ad->auth_eng.eng_id = SA_ENG_ID_AM1;
+ ad->auth_eng.sc_size = SA_CTX_AUTH_TYPE2_SZ;
+ ad->mci_enc = mci_cbc_enc_array[key_idx];
+ ad->mci_dec = mci_cbc_dec_array[key_idx];
+ ad->inv_key = true;
+ ad->keyed_mac = true;
+ ad->ealg_id = SA_EALG_ID_AES_CBC;
+ ad->aalg_id = SA_AALG_ID_HMAC_SHA2_256;
+ ad->hash_size = SHA256_DIGEST_SIZE;
+ ad->auth_ctrl = 0x4;
+ ad->prep_iopad = sa_hmac_sha256_get_pad;
+
+ return sa_aead_setkey(authenc, key, keylen, ad);
+}
+
static int sa_aead_run(struct aead_request *req, u8 *iv, int enc)
{
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
@@ -1418,6 +1485,31 @@ static struct sa_alg_tmpl sa_algs[] = {
.decrypt = sa_aead_decrypt,
}
},
+ {.type = CRYPTO_ALG_TYPE_AEAD,
+ .alg.aead = {
+ .base = {
+ .cra_name = "authenc(hmac(sha256),cbc(aes))",
+ .cra_driver_name =
+
"authenc(hmac(sha256),cbc(aes))-keystone-sa",
+ .cra_blocksize = AES_BLOCK_SIZE,
+ .cra_flags = CRYPTO_ALG_TYPE_AEAD |
+ CRYPTO_ALG_KERN_DRIVER_ONLY |
+ CRYPTO_ALG_ASYNC,
+ .cra_ctxsize = sizeof(struct sa_tfm_ctx),
+ .cra_module = THIS_MODULE,
+ .cra_alignmask = 0,
+ .cra_priority = 3000,
+ },
+ .ivsize = AES_BLOCK_SIZE,
+ .maxauthsize = SHA256_DIGEST_SIZE,
+
+ .init = sa_cra_init_aead,
+ .exit = sa_exit_tfm_aead,
+ .setkey = sa_aead_cbc_sha256_setkey,
+ .encrypt = sa_aead_encrypt,
+ .decrypt = sa_aead_decrypt,
+ }
+ },
};
/* Register the algorithms in crypto framework */
--
2.17.1
[PATCH 04/10] crypto: sa2ul: Add aead support for hmac(sha1)cbc(aes) algorithm
Add aead support for hmac(sha1)cbc(aes) algorithm. Authenticated
encryption (AE) and authenticated encryption with associated data
(AEAD) is a form of encryption which simultaneously provides
confidentiality, integrity, and authenticity assurances on the data.
hmac(sha1) has a digest size of 20 bytes is used for authetication
and AES in CBC mode is used in conjunction for encryption/decryption.
Signed-off-by: Keerthy
---
drivers/crypto/sa2ul.c | 402 +
1 file changed, 402 insertions(+)
diff --git a/drivers/crypto/sa2ul.c b/drivers/crypto/sa2ul.c
index a17c1f66c5c1..1a1bd882e0d2 100644
--- a/drivers/crypto/sa2ul.c
+++ b/drivers/crypto/sa2ul.c
@@ -228,6 +228,49 @@ static void sa_swiz_128(u8 *in, u16 len)
}
}
+/* Prepare the ipad and opad from key as per SHA algorithm step 1*/
+static void prepare_kiopad(u8 *k_ipad, u8 *k_opad, const u8 *key, u16 key_sz)
+{
+ int i;
+
+ for (i = 0; i < key_sz; i++) {
+ k_ipad[i] = key[i] ^ 0x36;
+ k_opad[i] = key[i] ^ 0x5c;
+ }
+
+ /* Instead of XOR with 0 */
+ for (; i < SHA_MESSAGE_BYTES; i++) {
+ k_ipad[i] = 0x36;
+ k_opad[i] = 0x5c;
+ }
+}
+
+/* Generate HMAC-SHA1 intermediate Hash */
+static
+void sa_hmac_sha1_get_pad(const u8 *key, u16 key_sz, u32 *ipad, u32 *opad)
+{
+ u32 ws[SHA_WORKSPACE_WORDS];
+ u8 k_ipad[SHA_MESSAGE_BYTES];
+ u8 k_opad[SHA_MESSAGE_BYTES];
+ int i;
+
+ prepare_kiopad(k_ipad, k_opad, key, key_sz);
+
+ /* SHA-1 on k_ipad */
+ sha_init(ipad);
+ sha_transform(ipad, k_ipad, ws);
+
+ for (i = 0; i < SHA_DIGEST_WORDS; i++)
+ ipad[i] = cpu_to_be32(ipad[i]);
+
+ /* SHA-1 on k_opad */
+ sha_init(opad);
+ sha_transform(opad, k_opad, ws);
+
+ for (i = 0; i < SHA_DIGEST_WORDS; i++)
+ opad[i] = cpu_to_be32(opad[i]);
+}
+
/* Derive the inverse key used in AES-CBC decryption operation */
static inline int sa_aes_inv_key(u8 *inv_key, const u8 *key, u16 key_sz)
{
@@ -814,6 +857,45 @@ static void sa_aes_dma_in_callback(void *data)
ablkcipher_request_complete(req, 0);
}
+static void sa_aead_dma_in_callback(void *data)
+{
+ struct sa_rx_data *rxd = (struct sa_rx_data *)data;
+ struct aead_request *req = (struct aead_request *)rxd->req;
+ struct crypto_aead *tfm = crypto_aead_reqtfm(req);
+ u32 *mdptr;
+ unsigned int start = req->assoclen + req->cryptlen;
+ unsigned int authsize = crypto_aead_authsize(tfm);
+ u8 auth_tag[SA_MAX_AUTH_TAG_SZ];
+ int i, sglen, err = 0;
+ size_t pl, ml;
+
+ mdptr = (u32 *)dmaengine_desc_get_metadata_ptr(rxd->tx_in, , );
+ for (i = 0; i < (authsize / 4); i++)
+ mdptr[i + 4] = htonl(mdptr[i + 4]);
+
+ if (rxd->enc) {
+ scatterwalk_map_and_copy((void *)[4], req->dst,
+start, crypto_aead_authsize(tfm), 1);
+ } else {
+ start -= authsize;
+ scatterwalk_map_and_copy(auth_tag, req->src,
+start, crypto_aead_authsize(tfm), 0);
+
+ err = memcmp((void *)[4],
+auth_tag, authsize) ? -EBADMSG : 0;
+ }
+
+ sglen = sg_nents_for_len(req->dst, req->cryptlen + authsize);
+ dma_unmap_sg(rxd->ddev, req->dst, sglen, DMA_FROM_DEVICE);
+
+ sglen = sg_nents_for_len(req->src, req->assoclen + req->cryptlen);
+ dma_unmap_sg(rxd->ddev, req->src, sglen, DMA_TO_DEVICE);
+
+ aead_request_complete(req, err);
+
+ kfree(rxd);
+}
+
static void
sa_prepare_tx_desc(u32 *mdptr, u32 pslen, u32 *psdata, u32 epiblen, u32 *epib)
{
@@ -965,6 +1047,300 @@ static int sa_aes_cbc_decrypt(struct ablkcipher_request
*req)
return sa_aes_run(req, req->info, 0);
}
+static int sa_init_tfm(struct crypto_tfm *tfm)
+{
+ struct crypto_alg *alg = tfm->__crt_alg;
+ struct sa_tfm_ctx *ctx = crypto_tfm_ctx(tfm);
+ struct sa_crypto_data *data = dev_get_drvdata(sa_k3_dev);
+ int ret;
+
+ if ((alg->cra_flags & CRYPTO_ALG_TYPE_MASK) == CRYPTO_ALG_TYPE_AEAD) {
+ memset(ctx, 0, sizeof(*ctx));
+ ctx->dev_data = data;
+
+ ret = sa_init_ctx_info(>enc, data);
+ if (ret)
+ return ret;
+ ret = sa_init_ctx_info(>dec, data);
+ if (ret) {
+ sa_free_ctx_info(>enc, data);
+ return ret;
+ }
+ }
+
+ dev_dbg(sa_k3_dev, "%s(0x%p) sc-ids(0x%x(0x%pad), 0x%x(0x%pad))\n",
+ __func__, tfm, ctx->enc.sc_id, >enc.sc_phys,
+ ctx->dec.sc_id, >dec.sc_phys);
+ return 0;
+}
+
+/* Algorithm init */
+static int sa_cra_init
[PATCH 10/10] arm64: dts: k3-am6: Add crypto accelarator node
Add crypto accelarator node. Define the psil specific config
node as well. This can be used in Packet Mode alone.
Signed-off-by: Keerthy
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 33
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 91ca5bfeefc2..5e4f9ec39f01 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -91,6 +91,39 @@
power-domains = <_pds 148>;
};
+ crypto: crypto@4E0 {
+ compatible = "ti,sa2ul-crypto";
+ label = "crypto-aes-gbe";
+ reg = <0x0 0x4E0 0x0 0x1200>;
+
+ status = "okay";
+ ti,psil-base = <0x4000>;
+
+ /* tx: crypto_pnp-1, rx: crypto_pnp-1 */
+ dmas = <_udmap 0 UDMA_DIR_TX>,
+ <_udmap 0 UDMA_DIR_RX>,
+ <_udmap 1 UDMA_DIR_RX>;
+ dma-names = "tx", "rx1", "rx2";
+
+ ti,psil-config0 {
+ linux,udma-mode = ;
+ ti,needs-epib;
+ ti,psd-size = <64>;
+ };
+
+ ti,psil-config1 {
+ linux,udma-mode = ;
+ ti,needs-epib;
+ ti,psd-size = <64>;
+ };
+
+ ti,psil-config2 {
+ linux,udma-mode = ;
+ ti,needs-epib;
+ ti,psd-size = <64>;
+ };
+ };
+
main_pmx0: pinmux@11c000 {
compatible = "pinctrl-single";
reg = <0x0 0x11c000 0x0 0x2e4>;
--
2.17.1
[PATCH 07/10] crypto: sa2ul: Add hmac(sha1) HMAC algorithm support
HMAC hash-based message authentication code) is a specific type of
message authentication code (MAC) involving a cryptographic hash
function and a secret cryptographic key. It may be used to
simultaneously verify both the data integrity and the authentication
of a message, as with any MAC. Add hmac(sha1) HMAC algorithm support
and the message digest size is 20 bytes.
Signed-off-by: Keerthy
---
drivers/crypto/sa2ul.c | 347 +
1 file changed, 347 insertions(+)
diff --git a/drivers/crypto/sa2ul.c b/drivers/crypto/sa2ul.c
index 9c9008e21867..e3a1321f0666 100644
--- a/drivers/crypto/sa2ul.c
+++ b/drivers/crypto/sa2ul.c
@@ -1408,6 +1408,307 @@ static int sa_aead_decrypt(struct aead_request *req)
return sa_aead_run(req, req->iv, 0);
}
+static int sa_sham_cra_init_alg(struct crypto_tfm *tfm, const char *alg_base)
+{
+ struct sa_tfm_ctx *ctx = crypto_tfm_ctx(tfm);
+ struct crypto_alg *alg = tfm->__crt_alg;
+ struct sa_crypto_data *data = dev_get_drvdata(sa_k3_dev);
+ int ret;
+
+ if ((alg->cra_flags & CRYPTO_ALG_TYPE_MASK) ==
+ CRYPTO_ALG_TYPE_AHASH) {
+ memset(ctx, 0, sizeof(*ctx));
+ ctx->dev_data = data;
+ ret = sa_init_ctx_info(>enc, data);
+ if (ret)
+ return ret;
+ }
+
+ if (alg_base) {
+ ctx->shash = crypto_alloc_shash(alg_base, 0,
+ CRYPTO_ALG_NEED_FALLBACK);
+ if (IS_ERR(ctx->shash)) {
+ pr_err("base driver %s couldn't be loaded\n", alg_base);
+ return PTR_ERR(ctx->shash);
+ }
+ }
+
+ dev_dbg(sa_k3_dev, "%s(0x%p) sc-ids(0x%x(0x%pad), 0x%x(0x%pad))\n",
+ __func__, tfm, ctx->enc.sc_id, >enc.sc_phys,
+ ctx->dec.sc_id, >dec.sc_phys);
+
+ crypto_ahash_set_reqsize(__crypto_ahash_cast(tfm),
+sizeof(struct sa_dma_req_ctx) +
+SHA512_BLOCK_SIZE);
+
+ return 0;
+}
+
+static void sa_sham_dma_in_callback(void *data)
+{
+ struct sa_rx_data *rxd = (struct sa_rx_data *)data;
+ struct ahash_request *req = (struct ahash_request *)rxd->req;
+ struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
+ unsigned int authsize = crypto_ahash_digestsize(tfm);
+ int i, sg_nents;
+ size_t ml, pl;
+ u32 *mdptr, *result;
+
+ mdptr = (u32 *)dmaengine_desc_get_metadata_ptr(rxd->tx_in, , );
+ result = (u32 *)req->result;
+
+ kfree(rxd);
+
+ for (i = 0; i < (authsize / 4); i++)
+ result[i] = htonl(mdptr[i + 4]);
+
+ sg_nents = sg_nents_for_len(req->src, req->nbytes);
+ dma_unmap_sg(rxd->ddev, req->src, sg_nents, DMA_FROM_DEVICE);
+
+ ahash_request_complete(req, 0);
+
+ kfree(rxd);
+}
+
+static int sa_sham_digest(struct ahash_request *req)
+{
+ struct sa_tfm_ctx *ctx = crypto_ahash_ctx(crypto_ahash_reqtfm(req));
+ struct sa_ctx_info *sa_ctx = >enc;
+ struct dma_async_tx_descriptor *tx_in, *tx_out;
+ struct sa_crypto_data *pdata = dev_get_drvdata(sa_k3_dev);
+ struct sa_dma_req_ctx req_ctx;
+ struct sa_rx_data *rxd;
+ u8 enc_offset;
+ int sg_nents;
+ int psdata_offset;
+ u8 auth_offset = 0;
+ u8 *auth_iv = NULL;
+ u8 *aad = NULL;
+ u8 aad_len = 0;
+ u16 enc_len;
+ u16 auth_len = 0;
+ u32 req_type;
+ u32 *mdptr;
+ struct dma_chan *dma_rx;
+ gfp_t flags;
+ size_t pl, ml;
+ struct device *ddev;
+
+ flags = req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP ?
+ GFP_KERNEL : GFP_ATOMIC;
+ enc_len = 0;
+ auth_len = req->nbytes;
+ enc_offset = 0;
+
+ if (enc_len > 256)
+ dma_rx = pdata->dma_rx2;
+ else
+ dma_rx = pdata->dma_rx1;
+
+ ddev = dma_rx->device->dev;
+ /* Allocate descriptor & submit packet */
+ sg_nents = sg_nents_for_len(req->src, req->nbytes);
+
+ memcpy(req_ctx.cmdl, sa_ctx->cmdl, sa_ctx->cmdl_size);
+ /* Update Command Label */
+ sa_update_cmdl(sa_k3_dev, enc_offset, enc_len,
+ NULL, auth_offset, auth_len,
+ auth_iv, aad_len, aad,
+ _ctx->cmdl_upd_info, req_ctx.cmdl);
+
+ /*
+* Last 2 words in PSDATA will have the crypto alg type &
+* crypto request pointer
+*/
+ req_type = CRYPTO_ALG_TYPE_AHASH;
+
+ psdata_offset = sa_ctx->cmdl_size / sizeof(u32);
+ req_ctx.cmdl[psdata_offset++] = req_type;
+
+ /* map the packet */
+ req_ctx.src = req->src;
+ req_ctx.src_nents = dma_map_sg(ddev, req->src, sg_nents,
[PATCH 00/10] crypto: k3: Add sa2ul driver
The series adds Crypto hardware accelerator support for SA2UL. SA2UL stands for security accelerator ultra lite. The Security Accelerator (SA2_UL) subsystem provides hardware cryptographic acceleration for the following use cases: • Encryption and authentication for secure boot • Encryption and authentication of content in applications requiring DRM (digital rights management) and content/asset protection The device includes one instantiation of SA2_UL named SA2_UL0 SA2UL needs on tx channel and a pair of rx dma channels. This series has dependency on UDMA series. Hence is based on top of: https://patchwork.kernel.org/project/linux-dmaengine/list/?series=114105 The above series adds couple of dmaengine APIs that are used by the sa2ul driver. Hence there is a hard dependency on the above series. Keerthy (10): dt-bindings: crypto: k3: Add sa2ul bindings documentation crypto: sa2ul: Add crypto driver crypto: sa2ul: Add AES ECB Mode support crypto: sa2ul: Add aead support for hmac(sha1)cbc(aes) algorithm crypto: sha256_generic: Export the Transform function crypto: sa2ul: Add hmac(sha256)cbc(aes) AEAD Algo support crypto: sa2ul: Add hmac(sha1) HMAC algorithm support crypto: sa2ul: Add hmac(sha256) HMAC algorithm support sa2ul: Add 3DES ECB & CBC Mode support arm64: dts: k3-am6: Add crypto accelarator node .../devicetree/bindings/crypto/sa2ul.txt | 47 + arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 33 + crypto/sha256_generic.c |3 +- drivers/crypto/Kconfig| 17 + drivers/crypto/Makefile |1 + drivers/crypto/sa2ul.c| 2232 + drivers/crypto/sa2ul.h| 384 +++ include/crypto/sha.h |1 + 8 files changed, 2717 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/crypto/sa2ul.txt create mode 100644 drivers/crypto/sa2ul.c create mode 100644 drivers/crypto/sa2ul.h -- 2.17.1
[PATCH 01/10] dt-bindings: crypto: k3: Add sa2ul bindings documentation
The series adds Crypto hardware accelerator support for SA2UL.
SA2UL stands for security accelerator ultra lite.
The Security Accelerator (SA2_UL) subsystem provides hardware
cryptographic acceleration for the following use cases:
• Encryption and authentication for secure boot
• Encryption and authentication of content in applications
requiring DRM (digital rights management) and
content/asset protection
The device includes one instantiation of SA2_UL named SA2_UL0
SA2UL needs on tx channel and a pair of rx dma channels.
Signed-off-by: Keerthy
---
.../devicetree/bindings/crypto/sa2ul.txt | 47 +++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/sa2ul.txt
diff --git a/Documentation/devicetree/bindings/crypto/sa2ul.txt
b/Documentation/devicetree/bindings/crypto/sa2ul.txt
new file mode 100644
index ..81cc039673b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/sa2ul.txt
@@ -0,0 +1,47 @@
+K3 SoC SA2UL crypto module
+
+Required properties:
+
+- compatible : Should be:
+ - "ti,sa2ul-crypto"
+- reg : Offset and length of the register set for the module
+
+- dmas: DMA specifiers for tx and rx dma. sa2ul needs one tx channel
+ and 2 rx channels. First rx channel for < 256 bytes and
+ the other one for >=256 bytes. See the DMA client binding,
+Documentation/devicetree/bindings/dma/dma.txt
+- dma-names: DMA request names has to have one tx and 2 rx names
+ corresponding to dmas abive.
+- ti,psil-config* - UDMA PSIL native Peripheral using packet mode.
+ SA2UL must have EPIB(Extended protocal information block)
+ and PSDATA(protocol specific data) properties.
+
+Example AM654 SA2UL:
+crypto: crypto@4E0 {
+ compatible = "ti,sa2ul-crypto";
+ reg = <0x0 0x4E0 0x0 0x1200>;
+ ti,psil-base = <0x4000>;
+
+ dmas = <_udmap 0 UDMA_DIR_TX>,
+ <_udmap 0 UDMA_DIR_RX>,
+ <_udmap 1 UDMA_DIR_RX>;
+ dma-names = "tx", "rx1", "rx2";
+
+ ti,psil-config0 {
+ linux,udma-mode = ;
+ ti,needs-epib;
+ ti,psd-size = <64>;
+ };
+
+ ti,psil-config1 {
+ linux,udma-mode = ;
+ ti,needs-epib;
+ ti,psd-size = <64>;
+ };
+
+ ti,psil-config2 {
+ linux,udma-mode = ;
+ ti,needs-epib;
+ ti,psd-size = <64>;
+ };
+};
--
2.17.1
Re: [GIT PULL] Immutable branch between MFD and Regulator due for the v5.3 merge window
On 17/06/19 12:33 PM, Lee Jones wrote: Enjoy! The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-regulator-v5.3 for you to fetch changes up to 7ee63bd74750a2c6fac31805ca0ac67f2522bfa5: regulator: lp87565: Add 4-phase lp87561 regulator support (2019-06-17 08:00:24 +0100) Immutable branch between MFD and Regulator due for the v5.3 merge window Keerthy (3): dt-bindings: mfd: lp87565: Add LP87561 configuration mfd: lp87565: Add support for 4-phase LP87561 combination regulator: lp87565: Add 4-phase lp87561 regulator support Thanks Lee Jones. Documentation/devicetree/bindings/mfd/lp87565.txt | 36 +++ drivers/mfd/lp87565.c | 4 +++ drivers/regulator/lp87565-regulator.c | 17 ++- include/linux/mfd/lp87565.h | 2 ++ 4 files changed, 58 insertions(+), 1 deletion(-)
Re: [RESEND PATCH v2 3/3] regulator: lp87565: Add 4-phase lp87561 regulator support
On 6/13/2019 11:02 PM, Mark Brown wrote: On Thu, Jun 13, 2019 at 10:32:45PM +0530, keerthy wrote: On 6/13/2019 9:15 PM, Mark Brown wrote: On Wed, Jun 12, 2019 at 08:16:20PM +0530, Keerthy wrote: patches 1/3 2/3 are already applied to linux-next. This doesn't build without those patches: They are already on next. Do you want me to resend them as well? That's no good, it still breaks the build of my tree. I can't apply this until the code is in my tree, either through a shared branch or through Lihus' tree. I see I acked the patch, I'll have been expecting the patch to be applied to Lee's tree. If that's not possible or there's no branch then please resend after the merge window. Lee Jones, Could you please pull this patch? - Keerthy
Re: [RESEND PATCH v2 3/3] regulator: lp87565: Add 4-phase lp87561 regulator support
On 6/13/2019 9:15 PM, Mark Brown wrote:
On Wed, Jun 12, 2019 at 08:16:20PM +0530, Keerthy wrote:
patches 1/3 2/3 are already applied to linux-next.
This doesn't build without those patches:
They are already on next. Do you want me to resend them as well?
CC drivers/regulator/lp87565-regulator.o
drivers/regulator/lp87565-regulator.c:156:32: error: ‘LP87565_BUCK_3210’
undeclared here (not in a function); did you mean ‘LP87565_BUCK_10’?
LP87565_REGULATOR("BUCK3210", LP87565_BUCK_3210, "buck3210",
^
[RESEND PATCH v2 3/3] regulator: lp87565: Add 4-phase lp87561 regulator support
The LP8756x family has a single output 4-phase regulator
configuration. Add support for the same. The control
lies in the master buck which is buck0 for 4-phase
configuration. Enable/disable/voltage set happen via
buck0 registers.
Data Sheet: https://www.ti.com/lit/ds/symlink/lp87561-q1.pdf
Signed-off-by: Keerthy
Acked-by: Mark Brown
---
patches 1/3 2/3 are already applied to linux-next.
Changes in v2:
* Changed if/else block to switch statement.
drivers/regulator/lp87565-regulator.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/lp87565-regulator.c
b/drivers/regulator/lp87565-regulator.c
index 81eb4b890c0c..af00d1ffcf33 100644
--- a/drivers/regulator/lp87565-regulator.c
+++ b/drivers/regulator/lp87565-regulator.c
@@ -153,6 +153,12 @@ static const struct lp87565_regulator regulators[] = {
LP87565_REG_BUCK2_CTRL_1,
LP87565_BUCK_CTRL_1_EN, 3230,
buck0_1_2_3_ranges, LP87565_REG_BUCK2_CTRL_2),
+ LP87565_REGULATOR("BUCK3210", LP87565_BUCK_3210, "buck3210",
+ lp87565_buck_ops, 256, LP87565_REG_BUCK0_VOUT,
+ LP87565_BUCK_VSET, LP87565_REG_BUCK0_CTRL_1,
+ LP87565_BUCK_CTRL_1_EN |
+ LP87565_BUCK_CTRL_1_FPWM_MP_0_2, 3230,
+ buck0_1_2_3_ranges, LP87565_REG_BUCK0_CTRL_2),
};
static int lp87565_regulator_probe(struct platform_device *pdev)
@@ -169,9 +175,18 @@ static int lp87565_regulator_probe(struct platform_device
*pdev)
config.driver_data = lp87565;
config.regmap = lp87565->regmap;
- if (lp87565->dev_type == LP87565_DEVICE_TYPE_LP87565_Q1) {
+ switch (lp87565->dev_type) {
+ case LP87565_DEVICE_TYPE_LP87565_Q1:
min_idx = LP87565_BUCK_10;
max_idx = LP87565_BUCK_23;
+ break;
+ case LP87565_DEVICE_TYPE_LP87561_Q1:
+ min_idx = LP87565_BUCK_3210;
+ max_idx = LP87565_BUCK_3210;
+ default:
+ dev_err(lp87565->dev, "Invalid lp config %d\n",
+ lp87565->dev_type);
+ return -EINVAL;
}
for (i = min_idx; i <= max_idx; i++) {
--
2.17.1
Re: [PATCH v2 3/3] regulator: lp87565: Add 4-phase lp87561 regulator support
On 10/06/19 11:18 AM, Lee Jones wrote: On Sat, 08 Jun 2019, Mark Brown wrote: On Sat, Jun 08, 2019 at 09:26:31AM +0530, keerthy wrote: mfd patches are on linux-next already. Hope you can pull this one now that dependencies are met. Someone will need to send me a copy of the patch, if I acked it I was expecting it to go in with the MFD changes. There is/was no need for that. Patches are built-time orthogonal. Sorry i am still not clear. Should i resend this patch?
Re: [PATCH] arm64: configs: Enable GPIO_DAVINCI
On 6/11/2019 11:49 PM, Tero Kristo wrote: On 05/06/2019 09:14, Keerthy wrote: Enable GPIO_DAVINCI and related configs for TI K3 AM6 platforms. Signed-off-by: Keerthy --- arch/arm64/configs/defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index d1b72f99e2f4..57d7a4c207bd 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -385,6 +385,9 @@ CONFIG_PINCTRL_QCS404=y CONFIG_PINCTRL_QDF2XXX=y CONFIG_PINCTRL_QCOM_SPMI_PMIC=y CONFIG_PINCTRL_SDM845=y +CONFIG_DEBUG_GPIO=y Why DEBUG_GPIO? Okay this can be left out. +CONFIG_GPIO_SYSFS=y Also, why GPIO_SYSFS? This has been there for pretty much all the SoCs in the past and one of the ways to validate GPIOs are functional. This is very much needed IMHO. Both of the above are nice for debugging purposes, but should not be enabled by default imho, as they are not needed by drivers. +CONFIG_GPIO_DAVINCI=y I think you should not modify defconfig, rather add these as platform required features under arch/arm64/Kconfig.platforms? I observed CONFIG_RESET_TI_SCI, CONFIG_TI_SCI_PROTOCOL which are platform specific in the defconfig and added them here. Already there are n number of GPIO config options as well under defconfig. If the norm is to add selects under arch/arm64/Kconfig.platforms then i am fine with that as well. Kindly let me know. - Keerthy -Tero CONFIG_GPIO_DWAPB=y CONFIG_GPIO_MB86S7X=y CONFIG_GPIO_PL061=y -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 3/3] regulator: lp87565: Add 4-phase lp87561 regulator support
On 5/28/2019 6:57 PM, Mark Brown wrote: On Tue, May 28, 2019 at 03:23:41PM +0530, Keerthy wrote: On 22/05/19 9:05 PM, Mark Brown wrote: On Thu, May 16, 2019 at 10:02:18AM +0530, Keerthy wrote: Acked-by: Mark Brown This patch will come via the mfd branch? I'd expect so, IIRC it had a build dependency on the earlier patches in the series so if that doesn't happen I'll need to merge the relevant MFD commits. Mark, mfd patches are on linux-next already. Hope you can pull this one now that dependencies are met. - Keerthy
Re: [RFC RESEND PATCH v2 1/4] dt-bindings: gpio: davinci: Add k3 am654 compatible
On 6/8/2019 4:09 AM, Linus Walleij wrote: On Thu, Jun 6, 2019 at 11:55 AM Keerthy wrote: The patch adds k3 am654 compatible, specific properties and an example. Signed-off-by: Keerthy Patch applied with the three others, so now all GPIO changes are in tree. Please funnel all the DTS changes through ARM SoC. Thank you Linus! Tero, Could you pull the dts changes on top of intr dts patches. Regards, Keerthy Yours, Linus Walleij
[RFC RESEND PATCH v2 4/4] arm64: dts: ti: am654-base-board: Add gpio_keys node
There are 2 push buttons: SW5 and SW6 that are basically connected to
WKUP_GPIO0_24 and WKUP_GPIO0_27 respectively. Add the respective
nodes and the pinctrl data to set the mode to GPIO and Input.
Signed-off-by: Keerthy
---
.../arm64/boot/dts/ti/k3-am654-base-board.dts | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
index cf1aa276a1ea..ea50b6e36eff 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -6,6 +6,7 @@
/dts-v1/;
#include "k3-am654.dtsi"
+#include
/ {
compatible = "ti,am654-evm", "ti,am654";
@@ -33,6 +34,25 @@
no-map;
};
};
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+ pinctrl-names = "default";
+ pinctrl-0 = <_button_pins_default>;
+
+ sw5 {
+ label = "GPIO Key USER1";
+ linux,code = ;
+ gpios = <_gpio0 24 GPIO_ACTIVE_LOW>;
+ };
+
+ sw6 {
+ label = "GPIO Key USER2";
+ linux,code = ;
+ gpios = <_gpio0 27 GPIO_ACTIVE_LOW>;
+ };
+ };
};
_pmx0 {
@@ -42,6 +62,13 @@
AM65X_WKUP_IOPAD(0x00e4, PIN_INPUT, 0) /* (AD6)
WKUP_I2C0_SDA */
>;
};
+
+ push_button_pins_default: push_button__pins_default {
+ pinctrl-single,pins = <
+ AM65X_WKUP_IOPAD(0x0030, PIN_INPUT, 7) /* (R5)
WKUP_GPIO0_24 */
+ AM65X_WKUP_IOPAD(0x003c, PIN_INPUT, 7) /* (P2)
WKUP_GPIO0_27 */
+ >;
+ };
};
_pmx0 {
--
2.17.1
[RFC RESEND PATCH v2 3/4] arm64: dts: ti: am6-main: Add gpio nodes
Add gpio0/1 nodes under main domain. They have 96 and 90 gpios
respectively and all are capable of generating banked interrupts.
Signed-off-by: Keerthy
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 22154f401930..182efe70402b 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -350,4 +350,36 @@
ti,sci-rm-range-global-event = <0x1>;
};
};
+
+ main_gpio0: main_gpio0@60 {
+ compatible = "ti,am654-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x60 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <_main_gpio>;
+ interrupts = <57 256>, <57 257>, <57 258>, <57 259>, <57 260>,
+ <57 261>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <96>;
+ ti,davinci-gpio-unbanked = <0>;
+ clocks = <_clks 57 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio1: main_gpio1@601000 {
+ compatible = "ti,am654-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x601000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <_main_gpio>;
+ interrupts = <58 256>, <58 257>, <58 258>, <58 259>, <58 260>,
+ <58 261>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <90>;
+ ti,davinci-gpio-unbanked = <0>;
+ clocks = <_clks 58 0>;
+ clock-names = "gpio";
+ };
};
--
2.17.1
[RFC RESEND PATCH v2 1/4] dt-bindings: gpio: davinci: Add k3 am654 compatible
The patch adds k3 am654 compatible, specific properties and
an example.
Signed-off-by: Keerthy
---
.../devicetree/bindings/gpio/gpio-davinci.txt | 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
index 553b92a7e87b..bc6b4b62df83 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -5,6 +5,7 @@ Required Properties:
"ti,keystone-gpio": for Keystone 2 66AK2H/K, 66AK2L,
66AK2E SoCs
"ti,k2g-gpio", "ti,keystone-gpio": for 66AK2G
+ "ti,am654-gpio", "ti,keystone-gpio": for TI K3 AM654
- reg: Physical base address of the controller and the size of memory mapped
registers.
@@ -145,3 +146,20 @@ gpio0: gpio@260bf00 {
ti,ngpio = <32>;
ti,davinci-gpio-unbanked = <32>;
};
+
+Example for K3 AM654:
+
+wkup_gpio0: wkup_gpio0@4211 {
+ compatible = "ti,am654-gpio", "ti,keystone-gpio";
+ reg = <0x4211 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <_wkup_gpio>;
+ interrupts = <59 128>, <59 129>, <59 130>, <59 131>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <56>;
+ ti,davinci-gpio-unbanked = <0>;
+ clocks = <_clks 59 0>;
+ clock-names = "gpio";
+};
--
2.17.1
[RFC RESEND PATCH v2 0/4] arm64: dts: ti: am6: Add gpio nodes
K3 AM6 platform has 2 instances of gpio banks on main domain and 1 instance on wakeup domin. All are capable of generating banked interrupts. This series also adds 2 goio_keys nodes connected to SW6 SW5 switches and tested for gpio_keys interrupts. The series depends on: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=112791 Posting as RFC as it has dependencies to be merged. Resending with the linux-gpio and gpio Maintainers copied. Changes in v2: * Added a separate am654 compatible. Keerthy (4): dt-bindings: gpio: davinci: Add k3 am654 compatible arm64: dts: ti: am6-wakeup: Add gpio node arm64: dts: ti: am6-main: Add gpio nodes arm64: dts: ti: am654-base-board: Add gpio_keys node .../devicetree/bindings/gpio/gpio-davinci.txt | 18 +++ arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 32 +++ arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi| 15 + .../arm64/boot/dts/ti/k3-am654-base-board.dts | 27 4 files changed, 92 insertions(+) -- 2.17.1
[RFC RESEND PATCH v2 2/4] arm64: dts: ti: am6-wakeup: Add gpio node
Add gpio0 node under wakeup domain. This has 56 gpios
and all are capable of generating banked interrupts.
Signed-off-by: Keerthy
---
arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
index f1ca171abdf8..9cf2c0849a24 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
@@ -74,4 +74,19 @@
ti,sci-dst-id = <56>;
ti,sci-rm-range-girq = <0x4>;
};
+
+ wkup_gpio0: wkup_gpio0@4211 {
+ compatible = "ti,am654-gpio", "ti,keystone-gpio";
+ reg = <0x4211 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <_wkup_gpio>;
+ interrupts = <59 128>, <59 129>, <59 130>, <59 131>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <56>;
+ ti,davinci-gpio-unbanked = <0>;
+ clocks = <_clks 59 0>;
+ clock-names = "gpio";
+ };
};
--
2.17.1
Re: [PATCH v2 2/3] gpio: davinci: Add new compatible for K3 AM654 SoCs
On 05/06/19 7:56 PM, Bartosz Golaszewski wrote:
śr., 5 cze 2019 o 10:02 Keerthy napisał(a):
Add new compatible for K3 AM654 SoCs.
Signed-off-by: Keerthy
---
drivers/gpio/gpio-davinci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 0977590eb996..fc494a84a29d 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -632,6 +632,7 @@ static int davinci_gpio_irq_setup(struct platform_device
*pdev)
static const struct of_device_id davinci_gpio_ids[] = {
{ .compatible = "ti,keystone-gpio", keystone_gpio_get_irq_chip},
+ { .compatible = "ti,am654-gpio", keystone_gpio_get_irq_chip},
Please add a patch adding this compatible to the binding document as well.
https://patchwork.kernel.org/patch/10976445/
Posted but did not add you in Cc. Sorry about that.
- Keerthy
Bart
{ .compatible = "ti,dm6441-gpio", davinci_gpio_get_irq_chip},
{ /* sentinel */ },
};
--
2.17.1
[PATCH v2 0/3] gpio: davinci: Add support for TI K3 AM6 platform
K3 AM6 platform has 2 instances of gpio banks on main domain and 1 instance on wakeup domin. All are capable of generating banked interrupts. Changes in v2: * Introduced a separate compatible for am654. Documentation patch link: https://patchwork.kernel.org/patch/10976445/ Keerthy (3): gpio: davinci: Fix the compiler warning with ARM64 config enabled gpio: davinci: Add new compatible for K3 AM654 SoCs gpio: Davinci: Add K3 dependencies drivers/gpio/Kconfig| 2 +- drivers/gpio/gpio-davinci.c | 7 --- 2 files changed, 5 insertions(+), 4 deletions(-) -- 2.17.1
[PATCH v2 1/3] gpio: davinci: Fix the compiler warning with ARM64 config enabled
Fix the compiler warning with ARM64 config enabled
as the current mask assumes 32 bit by default.
Signed-off-by: Keerthy
---
drivers/gpio/gpio-davinci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 3bbf5804bd11..0977590eb996 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -297,7 +297,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
static void gpio_irq_disable(struct irq_data *d)
{
struct davinci_gpio_regs __iomem *g = irq2regs(d);
- u32 mask = (u32) irq_data_get_irq_handler_data(d);
+ uintptr_t mask = (uintptr_t)irq_data_get_irq_handler_data(d);
writel_relaxed(mask, >clr_falling);
writel_relaxed(mask, >clr_rising);
@@ -306,7 +306,7 @@ static void gpio_irq_disable(struct irq_data *d)
static void gpio_irq_enable(struct irq_data *d)
{
struct davinci_gpio_regs __iomem *g = irq2regs(d);
- u32 mask = (u32) irq_data_get_irq_handler_data(d);
+ uintptr_t mask = (uintptr_t)irq_data_get_irq_handler_data(d);
unsigned status = irqd_get_trigger_type(d);
status &= IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING;
@@ -447,7 +447,7 @@ davinci_gpio_irq_map(struct irq_domain *d, unsigned int irq,
"davinci_gpio");
irq_set_irq_type(irq, IRQ_TYPE_NONE);
irq_set_chip_data(irq, (__force void *)g);
- irq_set_handler_data(irq, (void *)__gpio_mask(hw));
+ irq_set_handler_data(irq, (void *)(uintptr_t)__gpio_mask(hw));
return 0;
}
--
2.17.1
[PATCH v2 3/3] gpio: Davinci: Add K3 dependencies
Add K3 dependencies to enable the driver on K3 platforms. Signed-off-by: Keerthy --- drivers/gpio/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 62f3fe06cd2f..28dba62e2219 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -174,7 +174,7 @@ config GPIO_CLPS711X config GPIO_DAVINCI bool "TI Davinci/Keystone GPIO support" default y if ARCH_DAVINCI - depends on ARM && (ARCH_DAVINCI || ARCH_KEYSTONE) + depends on (ARM || ARM64) && (ARCH_DAVINCI || ARCH_KEYSTONE || ARCH_K3) help Say yes here to enable GPIO support for TI Davinci/Keystone SoCs. -- 2.17.1
[PATCH v2 2/3] gpio: davinci: Add new compatible for K3 AM654 SoCs
Add new compatible for K3 AM654 SoCs.
Signed-off-by: Keerthy
---
drivers/gpio/gpio-davinci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 0977590eb996..fc494a84a29d 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -632,6 +632,7 @@ static int davinci_gpio_irq_setup(struct platform_device
*pdev)
static const struct of_device_id davinci_gpio_ids[] = {
{ .compatible = "ti,keystone-gpio", keystone_gpio_get_irq_chip},
+ { .compatible = "ti,am654-gpio", keystone_gpio_get_irq_chip},
{ .compatible = "ti,dm6441-gpio", davinci_gpio_get_irq_chip},
{ /* sentinel */ },
};
--
2.17.1
[RFC PATCH v2 3/4] arm64: dts: ti: am6-main: Add gpio nodes
Add gpio0/1 nodes under main domain. They have 96 and 90 gpios
respectively and all are capable of generating banked interrupts.
Signed-off-by: Keerthy
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 22154f401930..182efe70402b 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -350,4 +350,36 @@
ti,sci-rm-range-global-event = <0x1>;
};
};
+
+ main_gpio0: main_gpio0@60 {
+ compatible = "ti,am654-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x60 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <_main_gpio>;
+ interrupts = <57 256>, <57 257>, <57 258>, <57 259>, <57 260>,
+ <57 261>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <96>;
+ ti,davinci-gpio-unbanked = <0>;
+ clocks = <_clks 57 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio1: main_gpio1@601000 {
+ compatible = "ti,am654-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x601000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <_main_gpio>;
+ interrupts = <58 256>, <58 257>, <58 258>, <58 259>, <58 260>,
+ <58 261>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <90>;
+ ti,davinci-gpio-unbanked = <0>;
+ clocks = <_clks 58 0>;
+ clock-names = "gpio";
+ };
};
--
2.17.1
[RFC PATCH v2 0/4] arm64: dts: ti: am6: Add gpio nodes
K3 AM6 platform has 2 instances of gpio banks on main domain and 1 instance on wakeup domin. All are capable of generating banked interrupts. This series also adds 2 goio_keys nodes connected to SW6 SW5 switches and tested for gpio_keys interrupts. The series depends on: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=112791 Posting as RFC as it has dependencies to be merged. Changes in v2: * Added a separate am654 compatible. Keerthy (4): dt-bindings: gpio: davinci: Add k3 am654 compatible arm64: dts: ti: am6-wakeup: Add gpio node arm64: dts: ti: am6-main: Add gpio nodes arm64: dts: ti: am654-base-board: Add gpio_keys node .../devicetree/bindings/gpio/gpio-davinci.txt | 18 +++ arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 32 +++ arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi| 15 + .../arm64/boot/dts/ti/k3-am654-base-board.dts | 27 4 files changed, 92 insertions(+) -- 2.17.1
[RFC PATCH v2 4/4] arm64: dts: ti: am654-base-board: Add gpio_keys node
There are 2 push buttons: SW5 and SW6 that are basically connected to
WKUP_GPIO0_24 and WKUP_GPIO0_27 respectively. Add the respective
nodes and the pinctrl data to set the mode to GPIO and Input.
Signed-off-by: Keerthy
---
.../arm64/boot/dts/ti/k3-am654-base-board.dts | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
index cf1aa276a1ea..ea50b6e36eff 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -6,6 +6,7 @@
/dts-v1/;
#include "k3-am654.dtsi"
+#include
/ {
compatible = "ti,am654-evm", "ti,am654";
@@ -33,6 +34,25 @@
no-map;
};
};
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+ pinctrl-names = "default";
+ pinctrl-0 = <_button_pins_default>;
+
+ sw5 {
+ label = "GPIO Key USER1";
+ linux,code = ;
+ gpios = <_gpio0 24 GPIO_ACTIVE_LOW>;
+ };
+
+ sw6 {
+ label = "GPIO Key USER2";
+ linux,code = ;
+ gpios = <_gpio0 27 GPIO_ACTIVE_LOW>;
+ };
+ };
};
_pmx0 {
@@ -42,6 +62,13 @@
AM65X_WKUP_IOPAD(0x00e4, PIN_INPUT, 0) /* (AD6)
WKUP_I2C0_SDA */
>;
};
+
+ push_button_pins_default: push_button__pins_default {
+ pinctrl-single,pins = <
+ AM65X_WKUP_IOPAD(0x0030, PIN_INPUT, 7) /* (R5)
WKUP_GPIO0_24 */
+ AM65X_WKUP_IOPAD(0x003c, PIN_INPUT, 7) /* (P2)
WKUP_GPIO0_27 */
+ >;
+ };
};
_pmx0 {
--
2.17.1
[RFC PATCH v2 1/4] dt-bindings: gpio: davinci: Add k3 am654 compatible
The patch adds k3 am654 compatible, specific properties and
an example.
Signed-off-by: Keerthy
---
.../devicetree/bindings/gpio/gpio-davinci.txt | 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
index 553b92a7e87b..bc6b4b62df83 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -5,6 +5,7 @@ Required Properties:
"ti,keystone-gpio": for Keystone 2 66AK2H/K, 66AK2L,
66AK2E SoCs
"ti,k2g-gpio", "ti,keystone-gpio": for 66AK2G
+ "ti,am654-gpio", "ti,keystone-gpio": for TI K3 AM654
- reg: Physical base address of the controller and the size of memory mapped
registers.
@@ -145,3 +146,20 @@ gpio0: gpio@260bf00 {
ti,ngpio = <32>;
ti,davinci-gpio-unbanked = <32>;
};
+
+Example for K3 AM654:
+
+wkup_gpio0: wkup_gpio0@4211 {
+ compatible = "ti,am654-gpio", "ti,keystone-gpio";
+ reg = <0x4211 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <_wkup_gpio>;
+ interrupts = <59 128>, <59 129>, <59 130>, <59 131>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <56>;
+ ti,davinci-gpio-unbanked = <0>;
+ clocks = <_clks 59 0>;
+ clock-names = "gpio";
+};
--
2.17.1
[RFC PATCH v2 2/4] arm64: dts: ti: am6-wakeup: Add gpio node
Add gpio0 node under wakeup domain. This has 56 gpios
and all are capable of generating banked interrupts.
Signed-off-by: Keerthy
---
arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
index f1ca171abdf8..9cf2c0849a24 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
@@ -74,4 +74,19 @@
ti,sci-dst-id = <56>;
ti,sci-rm-range-girq = <0x4>;
};
+
+ wkup_gpio0: wkup_gpio0@4211 {
+ compatible = "ti,am654-gpio", "ti,keystone-gpio";
+ reg = <0x4211 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <_wkup_gpio>;
+ interrupts = <59 128>, <59 129>, <59 130>, <59 131>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <56>;
+ ti,davinci-gpio-unbanked = <0>;
+ clocks = <_clks 59 0>;
+ clock-names = "gpio";
+ };
};
--
2.17.1
Re: [RFC PATCH 1/3] arm64: dts: ti: am6-wakeup: Add gpio node
On 05/06/19 11:46 AM, Lokesh Vutla wrote:
On 05/06/19 11:38 AM, Keerthy wrote:
Add gpio0 node under wakeup domain. This has 56 gpios
and all are capable of generating banked interrupts.
Signed-off-by: Keerthy
---
arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
index f1ca171abdf8..8c6c99e7c6ed 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
@@ -74,4 +74,19 @@
ti,sci-dst-id = <56>;
ti,sci-rm-range-girq = <0x4>;
};
+
+ wkup_gpio0: wkup_gpio0@4211 {
+ compatible = "ti,k2g-gpio", "ti,keystone-gpio";
This is not k2g. Can you either create a am6 specific compatible or just use
ti,keystone-gpio.
It seems practice is now to have separate compatible. I will add am6
specific compatible.
Thanks and regards,
Lokesh
+ reg = <0x4211 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <_wkup_gpio>;
+ interrupts = <59 128>, <59 129>, <59 130>, <59 131>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <56>;
+ ti,davinci-gpio-unbanked = <0>;
+ clocks = <_clks 59 0>;
+ clock-names = "gpio";
+ };
};
[PATCH] arm64: configs: Enable GPIO_DAVINCI
Enable GPIO_DAVINCI and related configs for TI K3 AM6 platforms. Signed-off-by: Keerthy --- arch/arm64/configs/defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index d1b72f99e2f4..57d7a4c207bd 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -385,6 +385,9 @@ CONFIG_PINCTRL_QCS404=y CONFIG_PINCTRL_QDF2XXX=y CONFIG_PINCTRL_QCOM_SPMI_PMIC=y CONFIG_PINCTRL_SDM845=y +CONFIG_DEBUG_GPIO=y +CONFIG_GPIO_SYSFS=y +CONFIG_GPIO_DAVINCI=y CONFIG_GPIO_DWAPB=y CONFIG_GPIO_MB86S7X=y CONFIG_GPIO_PL061=y -- 2.17.1
[RFC PATCH 1/3] arm64: dts: ti: am6-wakeup: Add gpio node
Add gpio0 node under wakeup domain. This has 56 gpios
and all are capable of generating banked interrupts.
Signed-off-by: Keerthy
---
arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
index f1ca171abdf8..8c6c99e7c6ed 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
@@ -74,4 +74,19 @@
ti,sci-dst-id = <56>;
ti,sci-rm-range-girq = <0x4>;
};
+
+ wkup_gpio0: wkup_gpio0@4211 {
+ compatible = "ti,k2g-gpio", "ti,keystone-gpio";
+ reg = <0x4211 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <_wkup_gpio>;
+ interrupts = <59 128>, <59 129>, <59 130>, <59 131>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <56>;
+ ti,davinci-gpio-unbanked = <0>;
+ clocks = <_clks 59 0>;
+ clock-names = "gpio";
+ };
};
--
2.17.1
[RFC PATCH 2/3] arm64: dts: ti: am6-main: Add gpio nodes
Add gpio0/1 nodes under main domain. They have 96 and 90 gpios
respectively and all are capable of generating banked interrupts.
Signed-off-by: Keerthy
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 22154f401930..24cd9005118c 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -350,4 +350,36 @@
ti,sci-rm-range-global-event = <0x1>;
};
};
+
+ main_gpio0: main_gpio0@60 {
+ compatible = "ti,k2g-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x60 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <_main_gpio>;
+ interrupts = <57 256>, <57 257>, <57 258>, <57 259>, <57 260>,
+ <57 261>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <96>;
+ ti,davinci-gpio-unbanked = <0>;
+ clocks = <_clks 57 0>;
+ clock-names = "gpio";
+ };
+
+ main_gpio1: main_gpio1@601000 {
+ compatible = "ti,k2g-gpio", "ti,keystone-gpio";
+ reg = <0x0 0x601000 0x0 0x100>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <_main_gpio>;
+ interrupts = <58 256>, <58 257>, <58 258>, <58 259>, <58 260>,
+ <58 261>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ti,ngpio = <90>;
+ ti,davinci-gpio-unbanked = <0>;
+ clocks = <_clks 58 0>;
+ clock-names = "gpio";
+ };
};
--
2.17.1
[RFC PATCH 0/3] arm64: dts: ti: am6: Add gpio nodes
K3 AM6 platform has 2 instances of gpio banks on main domain and 1 instance on wakeup domin. All are capable of generating banked interrupts. This series also adds 2 goio_keys nodes connected to SW6 SW5 switches and tested for gpio_keys interrupts. The series depends on: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=112791 Posting as RFC as it has dependencies to be merged. Keerthy (3): arm64: dts: ti: am6-wakeup: Add gpio node arm64: dts: ti: am6-main: Add gpio nodes arm64: dts: ti: am654-base-board: Add gpio_keys node arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 32 +++ arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi| 15 + .../arm64/boot/dts/ti/k3-am654-base-board.dts | 27 3 files changed, 74 insertions(+) -- 2.17.1
[RFC PATCH 3/3] arm64: dts: ti: am654-base-board: Add gpio_keys node
There are 2 push buttons: SW5 and SW6 that are basically connected to
WKUP_GPIO0_24 and WKUP_GPIO0_27 respectively. Add the respective
nodes and the pinctrl data to set the mode to GPIO and Input.
Signed-off-by: Keerthy
---
.../arm64/boot/dts/ti/k3-am654-base-board.dts | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
index cf1aa276a1ea..ea50b6e36eff 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -6,6 +6,7 @@
/dts-v1/;
#include "k3-am654.dtsi"
+#include
/ {
compatible = "ti,am654-evm", "ti,am654";
@@ -33,6 +34,25 @@
no-map;
};
};
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+ pinctrl-names = "default";
+ pinctrl-0 = <_button_pins_default>;
+
+ sw5 {
+ label = "GPIO Key USER1";
+ linux,code = ;
+ gpios = <_gpio0 24 GPIO_ACTIVE_LOW>;
+ };
+
+ sw6 {
+ label = "GPIO Key USER2";
+ linux,code = ;
+ gpios = <_gpio0 27 GPIO_ACTIVE_LOW>;
+ };
+ };
};
_pmx0 {
@@ -42,6 +62,13 @@
AM65X_WKUP_IOPAD(0x00e4, PIN_INPUT, 0) /* (AD6)
WKUP_I2C0_SDA */
>;
};
+
+ push_button_pins_default: push_button__pins_default {
+ pinctrl-single,pins = <
+ AM65X_WKUP_IOPAD(0x0030, PIN_INPUT, 7) /* (R5)
WKUP_GPIO0_24 */
+ AM65X_WKUP_IOPAD(0x003c, PIN_INPUT, 7) /* (P2)
WKUP_GPIO0_27 */
+ >;
+ };
};
_pmx0 {
--
2.17.1
[PATCH 1/2] gpio: davinci: Fix the compiler warning with ARM64 config enabled
Fix the compiler warning with ARM64 config enabled
as the current mask assumes 32 bit by default.
Signed-off-by: Keerthy
---
drivers/gpio/gpio-davinci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 3bbf5804bd11..0977590eb996 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -297,7 +297,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
static void gpio_irq_disable(struct irq_data *d)
{
struct davinci_gpio_regs __iomem *g = irq2regs(d);
- u32 mask = (u32) irq_data_get_irq_handler_data(d);
+ uintptr_t mask = (uintptr_t)irq_data_get_irq_handler_data(d);
writel_relaxed(mask, >clr_falling);
writel_relaxed(mask, >clr_rising);
@@ -306,7 +306,7 @@ static void gpio_irq_disable(struct irq_data *d)
static void gpio_irq_enable(struct irq_data *d)
{
struct davinci_gpio_regs __iomem *g = irq2regs(d);
- u32 mask = (u32) irq_data_get_irq_handler_data(d);
+ uintptr_t mask = (uintptr_t)irq_data_get_irq_handler_data(d);
unsigned status = irqd_get_trigger_type(d);
status &= IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING;
@@ -447,7 +447,7 @@ davinci_gpio_irq_map(struct irq_domain *d, unsigned int irq,
"davinci_gpio");
irq_set_irq_type(irq, IRQ_TYPE_NONE);
irq_set_chip_data(irq, (__force void *)g);
- irq_set_handler_data(irq, (void *)__gpio_mask(hw));
+ irq_set_handler_data(irq, (void *)(uintptr_t)__gpio_mask(hw));
return 0;
}
--
2.17.1
[PATCH 2/2] gpio: Davinci: Add K3 dependencies
Add K3 dependencies to enable the driver on K3 platforms. Signed-off-by: Keerthy --- drivers/gpio/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 62f3fe06cd2f..28dba62e2219 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -174,7 +174,7 @@ config GPIO_CLPS711X config GPIO_DAVINCI bool "TI Davinci/Keystone GPIO support" default y if ARCH_DAVINCI - depends on ARM && (ARCH_DAVINCI || ARCH_KEYSTONE) + depends on (ARM || ARM64) && (ARCH_DAVINCI || ARCH_KEYSTONE || ARCH_K3) help Say yes here to enable GPIO support for TI Davinci/Keystone SoCs. -- 2.17.1
[PATCH 0/2] gpio: davinci: Add support for TI K3 AM6 platform
K3 AM6 platform has 2 instances of gpio banks on main domain and 1 instance on wakeup domin. All are capable of generating banked interrupts. Keerthy (2): gpio: davinci: Fix the compiler warning with ARM64 config enabled gpio: Davinci: Add K3 Specific dependencies drivers/gpio/Kconfig| 2 +- drivers/gpio/gpio-davinci.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) -- 2.17.1
[PATCH] arm: dts: dra72x: Disable usb4_tm target module
usb4_tm is unsed on dra72 and accessing the module
with ti,sysc is causing a boot crash hence disable its target
module.
Fixes: 549fce068a3112 ("ARM: dts: dra7: Add l4 interconnect hierarchy and
ti-sysc data")
Reported-by: Vignesh Raghavendra
Signed-off-by: Keerthy
---
arch/arm/boot/dts/dra72x.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
index 89831552cd86..9c39c6b9b5d6 100644
--- a/arch/arm/boot/dts/dra72x.dtsi
+++ b/arch/arm/boot/dts/dra72x.dtsi
@@ -62,3 +62,7 @@
_rc {
compatible = "ti,dra726-pcie-rc", "ti,dra7-pcie";
};
+
+_tm {
+ status = "disabled";
+};
--
2.17.1
Re: [PATCH v2 3/3] regulator: lp87565: Add 4-phase lp87561 regulator support
On 22/05/19 9:05 PM, Mark Brown wrote: On Thu, May 16, 2019 at 10:02:18AM +0530, Keerthy wrote: The LP8756x family has a single output 4-phase regulator configuration. Add support for the same. The control lies in the master buck which is buck0 for 4-phase configuration. Enable/disable/voltage set happen via buck0 registers. Acked-by: Mark Brown Mark/Lee, This patch will come via the mfd branch? - Keerthy
Re: [PATCHv2 00/13] ti-sysc driver changes to drop custom hwmods property
On 28/05/19 11:54 AM, Tony Lindgren wrote: Hi all, Here are changes to improve ti-sysc driver to the point where we can finally drop the custom hwmods property for most cases. This series drops hwmods property only for omap4 UART and MMC as those can be tested with core retention idle. I'll be posting more patches for dropping hwmods properties as they get tested. Added missing dra71/76 patches on linux-next which get them to boot. Tested for boot on dra71/76. Tested for DS0 on AM43/33. Tested for RTC+DDR mode on am43. For the series: Tested-by: Keerthy Regards, Tony Changes since v1: - Repost the series against v5.2-rc1 as the first patch in the series got accidentally left out for patch "bus: ti-sysc: Add support for missing clockdomain handling" Tony Lindgren (13): bus: ti-sysc: Add support for missing clockdomain handling bus: ti-sysc: Support 16-bit writes too bus: ti-sysc: Make OCP reset work for sysstatus and sysconfig reset bits bus: ti-sysc: Allow QUIRK_LEGACY_IDLE even if legacy_mode is not set bus: ti-sysc: Enable interconnect target module autoidle bit on enable bus: ti-sysc: Handle clockactivity for enable and disable bus: ti-sysc: Handle swsup idle mode quirks bus: ti-sysc: Set ENAWAKEUP if available bus: ti-sysc: Add support for disabling module without legacy mode bus: ti-sysc: Do rstctrl reset handling in two phases bus: ti-sysc: Detect uarts also on omap34xx ARM: dts: Drop legacy custom hwmods property for omap4 uart ARM: dts: Drop legacy custom hwmods property for omap4 mmc arch/arm/boot/dts/omap4-l4.dtsi | 9 - arch/arm/mach-omap2/omap_hwmod.c | 39 +--- arch/arm/mach-omap2/pdata-quirks.c| 60 + drivers/bus/ti-sysc.c | 309 -- include/linux/platform_data/ti-sysc.h | 9 + 5 files changed, 314 insertions(+), 112 deletions(-)
Re: [PATCH 00/12] ti-sysc driver changes to drop custom hwmods property
On 27/05/19 5:43 PM, Tony Lindgren wrote: Hi all, Here are changes to improve ti-sysc driver to the point where we can finally drop the custom hwmods property for most cases. This series drops hwmods property only for omap4 UART and MMC as those can be tested with core retention idle. I'll be posting more patches for dropping hwmods properties as they get tested. Tony, What is the base of this series? It does not apply cleanly neither on linux-next nor on top of 5.2->rc1. If there are dependencies do you have a branch? - Keerthy Regards, Tony Tony Lindgren (12): bus: ti-sysc: Support 16-bit writes too bus: ti-sysc: Make OCP reset work for sysstatus and sysconfig reset bits bus: ti-sysc: Allow QUIRK_LEGACY_IDLE even if legacy_mode is not set bus: ti-sysc: Enable interconnect target module autoidle bit on enable bus: ti-sysc: Handle clockactivity for enable and disable bus: ti-sysc: Handle swsup idle mode quirks bus: ti-sysc: Set ENAWAKEUP if available bus: ti-sysc: Add support for disabling module without legacy mode bus: ti-sysc: Do rstctrl reset handling in two phases bus: ti-sysc: Detect uarts also on omap34xx ARM: dts: Drop legacy custom hwmods property for omap4 uart ARM: dts: Drop legacy custom hwmods property for omap4 mmc arch/arm/boot/dts/omap4-l4.dtsi | 9 -- drivers/bus/ti-sysc.c | 182 -- include/linux/platform_data/ti-sysc.h | 1 + 3 files changed, 140 insertions(+), 52 deletions(-)
[PATCH v2 1/3] dt-bindings: mfd: lp87565: Add lp87561 configuration
lp87561 is a single output 4-phase regulator configuration.
Add support for the same.
Signed-off-by: Keerthy
---
.../devicetree/bindings/mfd/lp87565.txt | 36 +++
1 file changed, 36 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/lp87565.txt
b/Documentation/devicetree/bindings/mfd/lp87565.txt
index a48df7c08ab0..41671e0dc26b 100644
--- a/Documentation/devicetree/bindings/mfd/lp87565.txt
+++ b/Documentation/devicetree/bindings/mfd/lp87565.txt
@@ -41,3 +41,39 @@ lp87565_pmic: pmic@60 {
};
};
};
+
+TI LP87561 PMIC:
+
+This is a single output 4-phase regulator configuration
+
+Required properties:
+ - compatible:"ti,lp87561-q1"
+ - reg: I2C slave address.
+ - gpio-controller: Marks the device node as a GPIO Controller.
+ - #gpio-cells: Should be two. The first cell is the pin number and
+ the second cell is used to specify flags.
+ See ../gpio/gpio.txt for more information.
+ - xxx-in-supply: Phandle to parent supply node of each regulator
+ populated under regulators node. xxx should match
+ the supply_name populated in driver.
+Example:
+
+lp87561_pmic: pmic@62 {
+ compatible = "ti,lp87561-q1";
+ reg = <0x62>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ buck3210-in-supply = <_3v3>;
+
+ regulators: regulators {
+ buck3210_reg: buck3210 {
+ /* VDD_CORE */
+ regulator-name = "buck3210";
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <80>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+};
--
2.17.1
[PATCH v2 2/3] mfd: lp87565: Add support for 4-phase lp87561 combination
Add support for 4-phase lp87561 combination.
Signed-off-by: Keerthy
---
drivers/mfd/lp87565.c | 4
include/linux/mfd/lp87565.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/mfd/lp87565.c b/drivers/mfd/lp87565.c
index 32d2a07d4354..8ad688fe75f9 100644
--- a/drivers/mfd/lp87565.c
+++ b/drivers/mfd/lp87565.c
@@ -33,6 +33,10 @@ static const struct of_device_id of_lp87565_match_table[] = {
.compatible = "ti,lp87565-q1",
.data = (void *)LP87565_DEVICE_TYPE_LP87565_Q1,
},
+ {
+ .compatible = "ti,lp87561-q1",
+ .data = (void *)LP87565_DEVICE_TYPE_LP87561_Q1,
+ },
{}
};
MODULE_DEVICE_TABLE(of, of_lp87565_match_table);
diff --git a/include/linux/mfd/lp87565.h b/include/linux/mfd/lp87565.h
index d0c91ba65525..976447607ea2 100644
--- a/include/linux/mfd/lp87565.h
+++ b/include/linux/mfd/lp87565.h
@@ -17,6 +17,7 @@
enum lp87565_device_type {
LP87565_DEVICE_TYPE_UNKNOWN = 0,
+ LP87565_DEVICE_TYPE_LP87561_Q1,
LP87565_DEVICE_TYPE_LP87565_Q1,
};
@@ -249,6 +250,7 @@ enum LP87565_regulator_id {
LP87565_BUCK_3,
LP87565_BUCK_10,
LP87565_BUCK_23,
+ LP87565_BUCK_3210,
};
/**
--
2.17.1
[PATCH v2 3/3] regulator: lp87565: Add 4-phase lp87561 regulator support
The LP8756x family has a single output 4-phase regulator
configuration. Add support for the same. The control
lies in the master buck which is buck0 for 4-phase
configuration. Enable/disable/voltage set happen via
buck0 registers.
Data Sheet: https://www.ti.com/lit/ds/symlink/lp87561-q1.pdf
Signed-off-by: Keerthy
---
Changes in v2:
* Changed if/else block to switch statement.
drivers/regulator/lp87565-regulator.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/lp87565-regulator.c
b/drivers/regulator/lp87565-regulator.c
index 81eb4b890c0c..af00d1ffcf33 100644
--- a/drivers/regulator/lp87565-regulator.c
+++ b/drivers/regulator/lp87565-regulator.c
@@ -153,6 +153,12 @@ static const struct lp87565_regulator regulators[] = {
LP87565_REG_BUCK2_CTRL_1,
LP87565_BUCK_CTRL_1_EN, 3230,
buck0_1_2_3_ranges, LP87565_REG_BUCK2_CTRL_2),
+ LP87565_REGULATOR("BUCK3210", LP87565_BUCK_3210, "buck3210",
+ lp87565_buck_ops, 256, LP87565_REG_BUCK0_VOUT,
+ LP87565_BUCK_VSET, LP87565_REG_BUCK0_CTRL_1,
+ LP87565_BUCK_CTRL_1_EN |
+ LP87565_BUCK_CTRL_1_FPWM_MP_0_2, 3230,
+ buck0_1_2_3_ranges, LP87565_REG_BUCK0_CTRL_2),
};
static int lp87565_regulator_probe(struct platform_device *pdev)
@@ -169,9 +175,18 @@ static int lp87565_regulator_probe(struct platform_device
*pdev)
config.driver_data = lp87565;
config.regmap = lp87565->regmap;
- if (lp87565->dev_type == LP87565_DEVICE_TYPE_LP87565_Q1) {
+ switch (lp87565->dev_type) {
+ case LP87565_DEVICE_TYPE_LP87565_Q1:
min_idx = LP87565_BUCK_10;
max_idx = LP87565_BUCK_23;
+ break;
+ case LP87565_DEVICE_TYPE_LP87561_Q1:
+ min_idx = LP87565_BUCK_3210;
+ max_idx = LP87565_BUCK_3210;
+ default:
+ dev_err(lp87565->dev, "Invalid lp config %d\n",
+ lp87565->dev_type);
+ return -EINVAL;
}
for (i = min_idx; i <= max_idx; i++) {
--
2.17.1
[PATCH v2 0/3] mfd: lp87565: Add support for 4-phase lp87561 combination
Add support for 4-phase lp87561 combination. Data Sheet: https://www.ti.com/lit/ds/symlink/lp87561-q1.pdf Keerthy (3): dt-bindings: mfd: lp87565: Add lp87561 configuration mfd: lp87565: Add support for 4-phase lp87561 combination regulator: lp87565: Add 4-phase lp87561 regulator support .../devicetree/bindings/mfd/lp87565.txt | 36 +++ drivers/mfd/lp87565.c | 4 +++ drivers/regulator/lp87565-regulator.c | 17 - include/linux/mfd/lp87565.h | 2 ++ 4 files changed, 58 insertions(+), 1 deletion(-) -- 2.17.1
Re: [PATCH 3/3] regulator: lp87565: Add 4-phase lp87561 regulator support
On 15/05/19 4:38 PM, Mark Brown wrote:
On Wed, May 15, 2019 at 03:38:48PM +0530, Keerthy wrote:
@@ -172,6 +178,9 @@ static int lp87565_regulator_probe(struct platform_device
*pdev)
if (lp87565->dev_type == LP87565_DEVICE_TYPE_LP87565_Q1) {
min_idx = LP87565_BUCK_10;
max_idx = LP87565_BUCK_23;
+ } else if (lp87565->dev_type == LP87565_DEVICE_TYPE_LP87561_Q1) {
+ min_idx = LP87565_BUCK_3210;
+ max_idx = LP87565_BUCK_3210;
This if/else chain should be a switch statement.
Okay. I will convert that in v2.
Thanks,
Keerthy
[PATCH 1/3] dt-bindings: mfd: lp87565: Add lp87561 configuration
lp87561 is a single output 4-phase regulator configuration.
Add support for the same.
Data Sheet: https://www.ti.com/lit/ds/symlink/lp87561-q1.pdf
Signed-off-by: Keerthy
---
.../devicetree/bindings/mfd/lp87565.txt | 36 +++
1 file changed, 36 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/lp87565.txt
b/Documentation/devicetree/bindings/mfd/lp87565.txt
index a48df7c08ab0..41671e0dc26b 100644
--- a/Documentation/devicetree/bindings/mfd/lp87565.txt
+++ b/Documentation/devicetree/bindings/mfd/lp87565.txt
@@ -41,3 +41,39 @@ lp87565_pmic: pmic@60 {
};
};
};
+
+TI LP87561 PMIC:
+
+This is a single output 4-phase regulator configuration
+
+Required properties:
+ - compatible:"ti,lp87561-q1"
+ - reg: I2C slave address.
+ - gpio-controller: Marks the device node as a GPIO Controller.
+ - #gpio-cells: Should be two. The first cell is the pin number and
+ the second cell is used to specify flags.
+ See ../gpio/gpio.txt for more information.
+ - xxx-in-supply: Phandle to parent supply node of each regulator
+ populated under regulators node. xxx should match
+ the supply_name populated in driver.
+Example:
+
+lp87561_pmic: pmic@62 {
+ compatible = "ti,lp87561-q1";
+ reg = <0x62>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ buck3210-in-supply = <_3v3>;
+
+ regulators: regulators {
+ buck3210_reg: buck3210 {
+ /* VDD_CORE */
+ regulator-name = "buck3210";
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <80>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+};
--
2.17.1
[PATCH 3/3] regulator: lp87565: Add 4-phase lp87561 regulator support
The LP8756x family has a single output 4-phase regulator
configuration. Add support for the same. The control
lies in the master buck which is buck0 for 4-phase
configuration. Enable/disable/voltage set happen via
buck0 registers.
Data Sheet: https://www.ti.com/lit/ds/symlink/lp87561-q1.pdf
Signed-off-by: Keerthy
---
drivers/regulator/lp87565-regulator.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/regulator/lp87565-regulator.c
b/drivers/regulator/lp87565-regulator.c
index 81eb4b890c0c..8255650df1cd 100644
--- a/drivers/regulator/lp87565-regulator.c
+++ b/drivers/regulator/lp87565-regulator.c
@@ -153,6 +153,12 @@ static const struct lp87565_regulator regulators[] = {
LP87565_REG_BUCK2_CTRL_1,
LP87565_BUCK_CTRL_1_EN, 3230,
buck0_1_2_3_ranges, LP87565_REG_BUCK2_CTRL_2),
+ LP87565_REGULATOR("BUCK3210", LP87565_BUCK_3210, "buck3210",
+ lp87565_buck_ops, 256, LP87565_REG_BUCK0_VOUT,
+ LP87565_BUCK_VSET, LP87565_REG_BUCK0_CTRL_1,
+ LP87565_BUCK_CTRL_1_EN |
+ LP87565_BUCK_CTRL_1_FPWM_MP_0_2, 3230,
+ buck0_1_2_3_ranges, LP87565_REG_BUCK0_CTRL_2),
};
static int lp87565_regulator_probe(struct platform_device *pdev)
@@ -172,6 +178,9 @@ static int lp87565_regulator_probe(struct platform_device
*pdev)
if (lp87565->dev_type == LP87565_DEVICE_TYPE_LP87565_Q1) {
min_idx = LP87565_BUCK_10;
max_idx = LP87565_BUCK_23;
+ } else if (lp87565->dev_type == LP87565_DEVICE_TYPE_LP87561_Q1) {
+ min_idx = LP87565_BUCK_3210;
+ max_idx = LP87565_BUCK_3210;
}
for (i = min_idx; i <= max_idx; i++) {
--
2.17.1
[PATCH 2/3] mfd: lp87565: Add support for 4-phase lp87561 combination
Add support for 4-phase lp87561 combination.
Data Sheet: https://www.ti.com/lit/ds/symlink/lp87561-q1.pdf
Signed-off-by: Keerthy
---
drivers/mfd/lp87565.c | 4
include/linux/mfd/lp87565.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/mfd/lp87565.c b/drivers/mfd/lp87565.c
index 32d2a07d4354..8ad688fe75f9 100644
--- a/drivers/mfd/lp87565.c
+++ b/drivers/mfd/lp87565.c
@@ -33,6 +33,10 @@ static const struct of_device_id of_lp87565_match_table[] = {
.compatible = "ti,lp87565-q1",
.data = (void *)LP87565_DEVICE_TYPE_LP87565_Q1,
},
+ {
+ .compatible = "ti,lp87561-q1",
+ .data = (void *)LP87565_DEVICE_TYPE_LP87561_Q1,
+ },
{}
};
MODULE_DEVICE_TABLE(of, of_lp87565_match_table);
diff --git a/include/linux/mfd/lp87565.h b/include/linux/mfd/lp87565.h
index d0c91ba65525..976447607ea2 100644
--- a/include/linux/mfd/lp87565.h
+++ b/include/linux/mfd/lp87565.h
@@ -17,6 +17,7 @@
enum lp87565_device_type {
LP87565_DEVICE_TYPE_UNKNOWN = 0,
+ LP87565_DEVICE_TYPE_LP87561_Q1,
LP87565_DEVICE_TYPE_LP87565_Q1,
};
@@ -249,6 +250,7 @@ enum LP87565_regulator_id {
LP87565_BUCK_3,
LP87565_BUCK_10,
LP87565_BUCK_23,
+ LP87565_BUCK_3210,
};
/**
--
2.17.1
[PATCH 0/3] mfd: lp87565: Add support for 4-phase lp87561 combination
Add support for 4-phase lp87561 combination. Data Sheet: https://www.ti.com/lit/ds/symlink/lp87561-q1.pdf Keerthy (3): dt-bindings: mfd: lp87565: Add lp87561 configuration mfd: lp87565: Add support for 4-phase lp87561 combination regulator: lp87565: Add 4-phase lp87561 regulator support .../devicetree/bindings/mfd/lp87565.txt | 36 +++ drivers/mfd/lp87565.c | 4 +++ drivers/regulator/lp87565-regulator.c | 9 + include/linux/mfd/lp87565.h | 2 ++ 4 files changed, 51 insertions(+) -- 2.17.1
Re: [PATCH 0/2] Two ti-sysc driver fixes for v5.3 merge window
On 02/05/19 3:11 AM, Tony Lindgren wrote: Hi all, Here are few fixes for the am335x d_can boot issue Sebastian reported for Beaglebone. Tested for AM437x-gp-evm RTC+DDR mode and DS0. Also tried DS0 on Am335x beaglebone black. For the above: Tested-by: Keerthy Regards, Tony Tony Lindgren (2): ARM: dts: Configure osc clock for d_can on am335x bus: ti-sysc: Handle devices with no control registers arch/arm/boot/dts/am33xx-l4.dtsi | 14 ++ arch/arm/boot/dts/am437x-l4.dtsi | 4 drivers/bus/ti-sysc.c| 23 +++ 3 files changed, 17 insertions(+), 24 deletions(-)
[PATCH] soc: ti: pm33xx: Add a print while entering RTC only mode with DDR in self-refresh
Currently there is no way to distinguish if the SoC entered DS0
mode or the RTC only mode. Hence add a print before entering
the RTC only mode.
Signed-off-by: Keerthy
---
drivers/soc/ti/pm33xx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/soc/ti/pm33xx.c b/drivers/soc/ti/pm33xx.c
index fc5802ccb1c0..bb77c220b6f8 100644
--- a/drivers/soc/ti/pm33xx.c
+++ b/drivers/soc/ti/pm33xx.c
@@ -178,6 +178,7 @@ static int am33xx_pm_suspend(suspend_state_t suspend_state)
suspend_wfi_flags);
suspend_wfi_flags &= ~WFI_FLAG_RTC_ONLY;
+ dev_info(pm33xx_dev, "Entering RTC Only mode with DDR in
self-refresh\n");
if (!ret) {
clk_restore_context();
--
2.17.1
Re: linux-next: manual merge of the rtc tree with the omap tree
On 09/04/19 10:52 AM, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the rtc tree got a conflict in:
drivers/rtc/rtc-omap.c
between commit:
6256f7f7f217 ("rtc: OMAP: Add support for rtc-only mode")
from the omap tree and commit:
35118b7a4ea0 ("rtc: omap: let the core handle range")
from the rtc tree.
I fixed it up (I used the latter resolution around tm2bcd() changes) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
Thanks Stephen. I have tested with Latest next and rtc+ddr mode is
functional with an additional fix that Tony is about to queue.
I also reviewed the rtc driver and looks fine.
Re: [PATCH 3/3] ARM: omap2: move platform-specific asm-offset.h to arch/arm/mach-omap2
On 09/04/19 10:37 AM, Masahiro Yamada wrote: On Tue, Apr 9, 2019 at 2:00 PM Keerthy wrote: On 08/04/19 9:48 PM, Tony Lindgren wrote: Hi, * Masahiro Yamada [190408 07:56]: is only generated and included by arch/arm/mach-omap2/, so it does not need to reside in the globally visible include/generated/. I moved and renamed it to arch/arm/mach-omap2/pm-asm-offsets.h since the prefix 'omap2-' is just redundant in mach-omap2/. Signed-off-by: Masahiro Yamada --- Can this be applied to ARM-SOC tree in a series? (with Ack from the platform sub-maintainer.) ti-pm-asm-offsets.h does not need to reside in include/generated/, but you may ask "Why must it get out of include/generated/?" My main motivation is to avoid a race condition in the currently proposed patch: https://lore.kernel.org/patchwork/patch/1052763/ This patch tries to embed some build artifacts into the kernel. If arch/arm/mach-omap2/ and kernel/ are built at the same time, it may embed a truncated file. Looks like a nice improvment to me, adding Keerthy and Dave to Cc. Keerthy and Dave, can you please test this series with am3 and am4 PM code? Tested for Deep Sleep0 on AM33xx Beaglebone-black. Tested for Deep Sleep0 on AM437x-gp-evm. Applied this on top of Tony's for-next with the gpio patch required for RTC+DDR mode on am437x-gp-evm. Was it applied to TI tree? If so ... Arnd, Olof, Please just ignore this patch since it looks it was already applied to TI tree. Masahiro Yamada, No i manually applied this on top. Regards, Keerthy Thanks. Masahiro Yamada Tested-by: Keerthy Regards, Tony arch/arm/mach-omap2/.gitignore | 1 + arch/arm/mach-omap2/Makefile| 5 +++-- arch/arm/mach-omap2/sleep33xx.S | 2 +- arch/arm/mach-omap2/sleep43xx.S | 2 +- 4 files changed, 6 insertions(+), 4 deletions(-) create mode 100644 arch/arm/mach-omap2/.gitignore diff --git a/arch/arm/mach-omap2/.gitignore b/arch/arm/mach-omap2/.gitignore new file mode 100644 index ..79a8d6ea7152 --- /dev/null +++ b/arch/arm/mach-omap2/.gitignore @@ -0,0 +1 @@ +pm-asm-offsets.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 85d1b13c9215..26baeb6477af 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -236,9 +236,10 @@ obj-y += omap_phy_internal.o obj-$(CONFIG_MACH_OMAP2_TUSB6010) += usb-tusb6010.o -include/generated/ti-pm-asm-offsets.h: arch/arm/mach-omap2/pm-asm-offsets.s FORCE +$(obj)/pm-asm-offsets.h: $(obj)/pm-asm-offsets.s FORCE $(call filechk,offsets,__TI_PM_ASM_OFFSETS_H__) -$(obj)/sleep33xx.o $(obj)/sleep43xx.o: include/generated/ti-pm-asm-offsets.h +$(obj)/sleep33xx.o $(obj)/sleep43xx.o: $(obj)/pm-asm-offsets.h targets += pm-asm-offsets.s +clean-files += pm-asm-offsets.h diff --git a/arch/arm/mach-omap2/sleep33xx.S b/arch/arm/mach-omap2/sleep33xx.S index 47a816468cdb..a003769121aa 100644 --- a/arch/arm/mach-omap2/sleep33xx.S +++ b/arch/arm/mach-omap2/sleep33xx.S @@ -6,7 +6,6 @@ * Dave Gerlach, Vaibhav Bedia */ -#include #include #include #include @@ -15,6 +14,7 @@ #include "iomap.h" #include "cm33xx.h" +#include "pm-asm-offsets.h" #define AM33XX_CM_CLKCTRL_MODULESTATE_DISABLED 0x0003 #define AM33XX_CM_CLKCTRL_MODULEMODE_DISABLE 0x0003 diff --git a/arch/arm/mach-omap2/sleep43xx.S b/arch/arm/mach-omap2/sleep43xx.S index 5b9343b58fc7..aa288f361c5e 100644 --- a/arch/arm/mach-omap2/sleep43xx.S +++ b/arch/arm/mach-omap2/sleep43xx.S @@ -6,7 +6,6 @@ * Dave Gerlach, Vaibhav Bedia */ -#include #include #include #include @@ -19,6 +18,7 @@ #include "iomap.h" #include "omap-secure.h" #include "omap44xx.h" +#include "pm-asm-offsets.h" #include "prm33xx.h" #include "prcm43xx.h" -- 2.17.1 -- Best Regards Masahiro Yamada
Re: [PATCH 3/3] ARM: omap2: move platform-specific asm-offset.h to arch/arm/mach-omap2
On 08/04/19 9:48 PM, Tony Lindgren wrote: Hi, * Masahiro Yamada [190408 07:56]: is only generated and included by arch/arm/mach-omap2/, so it does not need to reside in the globally visible include/generated/. I moved and renamed it to arch/arm/mach-omap2/pm-asm-offsets.h since the prefix 'omap2-' is just redundant in mach-omap2/. Signed-off-by: Masahiro Yamada --- Can this be applied to ARM-SOC tree in a series? (with Ack from the platform sub-maintainer.) ti-pm-asm-offsets.h does not need to reside in include/generated/, but you may ask "Why must it get out of include/generated/?" My main motivation is to avoid a race condition in the currently proposed patch: https://lore.kernel.org/patchwork/patch/1052763/ This patch tries to embed some build artifacts into the kernel. If arch/arm/mach-omap2/ and kernel/ are built at the same time, it may embed a truncated file. Looks like a nice improvment to me, adding Keerthy and Dave to Cc. Keerthy and Dave, can you please test this series with am3 and am4 PM code? Tested for Deep Sleep0 on AM33xx Beaglebone-black. Tested for Deep Sleep0 on AM437x-gp-evm. Applied this on top of Tony's for-next with the gpio patch required for RTC+DDR mode on am437x-gp-evm. Tested-by: Keerthy Regards, Tony arch/arm/mach-omap2/.gitignore | 1 + arch/arm/mach-omap2/Makefile| 5 +++-- arch/arm/mach-omap2/sleep33xx.S | 2 +- arch/arm/mach-omap2/sleep43xx.S | 2 +- 4 files changed, 6 insertions(+), 4 deletions(-) create mode 100644 arch/arm/mach-omap2/.gitignore diff --git a/arch/arm/mach-omap2/.gitignore b/arch/arm/mach-omap2/.gitignore new file mode 100644 index ..79a8d6ea7152 --- /dev/null +++ b/arch/arm/mach-omap2/.gitignore @@ -0,0 +1 @@ +pm-asm-offsets.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 85d1b13c9215..26baeb6477af 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -236,9 +236,10 @@ obj-y += omap_phy_internal.o obj-$(CONFIG_MACH_OMAP2_TUSB6010) += usb-tusb6010.o -include/generated/ti-pm-asm-offsets.h: arch/arm/mach-omap2/pm-asm-offsets.s FORCE +$(obj)/pm-asm-offsets.h: $(obj)/pm-asm-offsets.s FORCE $(call filechk,offsets,__TI_PM_ASM_OFFSETS_H__) -$(obj)/sleep33xx.o $(obj)/sleep43xx.o: include/generated/ti-pm-asm-offsets.h +$(obj)/sleep33xx.o $(obj)/sleep43xx.o: $(obj)/pm-asm-offsets.h targets += pm-asm-offsets.s +clean-files += pm-asm-offsets.h diff --git a/arch/arm/mach-omap2/sleep33xx.S b/arch/arm/mach-omap2/sleep33xx.S index 47a816468cdb..a003769121aa 100644 --- a/arch/arm/mach-omap2/sleep33xx.S +++ b/arch/arm/mach-omap2/sleep33xx.S @@ -6,7 +6,6 @@ *Dave Gerlach, Vaibhav Bedia */ -#include #include #include #include @@ -15,6 +14,7 @@ #include "iomap.h" #include "cm33xx.h" +#include "pm-asm-offsets.h" #define AM33XX_CM_CLKCTRL_MODULESTATE_DISABLED 0x0003 #define AM33XX_CM_CLKCTRL_MODULEMODE_DISABLE 0x0003 diff --git a/arch/arm/mach-omap2/sleep43xx.S b/arch/arm/mach-omap2/sleep43xx.S index 5b9343b58fc7..aa288f361c5e 100644 --- a/arch/arm/mach-omap2/sleep43xx.S +++ b/arch/arm/mach-omap2/sleep43xx.S @@ -6,7 +6,6 @@ *Dave Gerlach, Vaibhav Bedia */ -#include #include #include #include @@ -19,6 +18,7 @@ #include "iomap.h" #include "omap-secure.h" #include "omap44xx.h" +#include "pm-asm-offsets.h" #include "prm33xx.h" #include "prcm43xx.h" -- 2.17.1
Re: [PATCH] clocksource/drivers/timer-ti-dm: Remove omap_dm_timer_set_load_start
On 04/04/19 7:47 PM, Tony Lindgren wrote:
* Ladislav Michl [190327 08:12]:
Hello Nathan,
On Tue, Mar 26, 2019 at 10:01:27PM -0700, Nathan Chancellor wrote:
Commit 008258d995a6 ("clocksource/drivers/timer-ti-dm: Make
omap_dm_timer_set_load_start() static") made omap_dm_time_set_load_start
static because its prototype was not defined in a header. Unfortunately,
this causes a build warning on multi_v7_defconfig because this function
is not used anywhere in this translation unit:
drivers/clocksource/timer-ti-dm.c:589:12: error: unused function
'omap_dm_timer_set_load_start' [-Werror,-Wunused-function]
In fact, omap_dm_timer_set_load_start hasn't been used anywhere since
commit f190be7f39a5 ("staging: tidspbridge: remove driver") and the
prototype was removed in commit 592ea6bd1fad ("clocksource: timer-ti-dm:
Make unexported functions static"), which is probably where this should
have happened.
Alternatively you might want to look at "clocksource: timer-ti-dm: Add event
capture": https://patchwork.kernel.org/patch/10237217/ (it makes use of
function being removed here). It is a part of an attempt to add event capture
for OMAP. Of course I would like this functionality to be implemented, but
as I do not have a time to continue, I cannot really object removing this
function.
Just in case you'd be interested in finishing this task ;-)
Well seems like no other takers :) We can always find the missing
function in git history when needed, so I suggest we apply this.
Adding Keerthy to Cc as he just posted a similar patch.
I posted the duplicate. Thanks for looping in.
Regards,
Tony
[PATCH] clocksource: timer-ti-dm: Remove unused omap_dm_timer_set_load_start
omap_dm_timer_set_load_start is no longer used hence delete the
function and remove the below warning.
drivers/clocksource/timer-ti-dm.c:589:12:
warning: ‘omap_dm_timer_set_load_start’ defined but not used
Signed-off-by: Keerthy
---
drivers/clocksource/timer-ti-dm.c | 28
1 file changed, 28 deletions(-)
diff --git a/drivers/clocksource/timer-ti-dm.c
b/drivers/clocksource/timer-ti-dm.c
index 3352da6ed61f..ee8ec5a8cb16 100644
--- a/drivers/clocksource/timer-ti-dm.c
+++ b/drivers/clocksource/timer-ti-dm.c
@@ -585,34 +585,6 @@ static int omap_dm_timer_set_load(struct omap_dm_timer
*timer, int autoreload,
return 0;
}
-/* Optimized set_load which removes costly spin wait in timer_start */
-static int omap_dm_timer_set_load_start(struct omap_dm_timer *timer,
- int autoreload, unsigned int load)
-{
- u32 l;
-
- if (unlikely(!timer))
- return -EINVAL;
-
- omap_dm_timer_enable(timer);
-
- l = omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
- if (autoreload) {
- l |= OMAP_TIMER_CTRL_AR;
- omap_dm_timer_write_reg(timer, OMAP_TIMER_LOAD_REG, load);
- } else {
- l &= ~OMAP_TIMER_CTRL_AR;
- }
- l |= OMAP_TIMER_CTRL_ST;
-
- __omap_dm_timer_load_start(timer, l, load, timer->posted);
-
- /* Save the context */
- timer->context.tclr = l;
- timer->context.tldr = load;
- timer->context.tcrr = load;
- return 0;
-}
static int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable,
unsigned int match)
{
--
2.17.1
Re: [PATCH] regulator: palmas: Remove *rdev[PALMAS_NUM_REGS] from struct palmas_pmic
On 10/03/19 8:36 PM, Axel Lin wrote:
This driver is using devm_regulator_register() so it is not necessary
to save *rdev for clean up. Actually the pmic->rdev[id] is not used now.
Reviewed-by: Keerthy
Signed-off-by: Axel Lin
---
drivers/regulator/palmas-regulator.c | 12
include/linux/mfd/palmas.h | 1 -
2 files changed, 13 deletions(-)
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 7fb9e8dd834e..f13c7c8b1061 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -991,9 +991,6 @@ static int palmas_ldo_registration(struct palmas_pmic *pmic,
return PTR_ERR(rdev);
}
- /* Save regulator for cleanup */
- pmic->rdev[id] = rdev;
-
/* Initialise sleep/init values from platform data */
if (pdata) {
reg_init = pdata->reg_init[id];
@@ -1101,9 +1098,6 @@ static int tps65917_ldo_registration(struct palmas_pmic
*pmic,
return PTR_ERR(rdev);
}
- /* Save regulator for cleanup */
- pmic->rdev[id] = rdev;
-
/* Initialise sleep/init values from platform data */
if (pdata) {
reg_init = pdata->reg_init[id];
@@ -1288,9 +1282,6 @@ static int palmas_smps_registration(struct palmas_pmic
*pmic,
pdev_name);
return PTR_ERR(rdev);
}
-
- /* Save regulator for cleanup */
- pmic->rdev[id] = rdev;
}
return 0;
@@ -1395,9 +1386,6 @@ static int tps65917_smps_registration(struct palmas_pmic
*pmic,
pdev_name);
return PTR_ERR(rdev);
}
-
- /* Save regulator for cleanup */
- pmic->rdev[id] = rdev;
}
return 0;
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index 75e5c8ff85fc..c34d5f0d34d7 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -553,7 +553,6 @@ struct palmas_pmic {
struct palmas *palmas;
struct device *dev;
struct regulator_desc desc[PALMAS_NUM_REGS];
- struct regulator_dev *rdev[PALMAS_NUM_REGS];
struct mutex mutex;
int smps123;
Re: [PATCH RFT] regulator: lp87565: Fix missing register for LP87565_BUCK_0
On 01/03/19 11:46 AM, Axel Lin wrote:
LP87565_BUCK_0 is missed, fix it.
Fixes: f0168a9bf ("regulator: lp87565: Add support for lp87565 PMIC regulators")
Signed-off-by: Axel Lin
---
Hi J Keerthy,
While reading the code, it seems strange that LP87565_BUCK_0 is never used.
So current code only register 3 BUCKs for lp87565-regulator.
Can you confirm if this fix is correct or not?
Axel,
If you look at the if check later:
if (lp87565->dev_type == LP87565_DEVICE_TYPE_LP87565_Q1) {
Currently the device that i am using only uses LP87565_BUCK_10 and
LP87565_BUCK_23(dual phase).
So your patch definitely makes sense when all 4 are used individually.
Thanks for catching this.
Reviewed-by: Keerthy
Thanks,
Axel
drivers/regulator/lp87565-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/lp87565-regulator.c
b/drivers/regulator/lp87565-regulator.c
index 4ed41731a5b1..0418e478c6dc 100644
--- a/drivers/regulator/lp87565-regulator.c
+++ b/drivers/regulator/lp87565-regulator.c
@@ -193,7 +193,7 @@ static int lp87565_regulator_probe(struct platform_device
*pdev)
struct lp87565 *lp87565 = dev_get_drvdata(pdev->dev.parent);
struct regulator_config config = { };
struct regulator_dev *rdev;
- int i, min_idx = LP87565_BUCK_1, max_idx = LP87565_BUCK_3;
+ int i, min_idx = LP87565_BUCK_0, max_idx = LP87565_BUCK_3;
platform_set_drvdata(pdev, lp87565);
Re: linux-5.0-rc3, ti-soc-thermal: unmet dependencies Kconfig warning
On 28/01/19 10:04 PM, Tony Lindgren wrote: > Hi, > > * Randy Dunlap [190126 06:54]: >> Hi, >> >> FYI, I'm seeing this Kconfig warning in 5.0-rc3: > > Thanks for reporting it. > >> WARNING: unmet direct dependencies detected for TI_SOC_THERMAL >> Depends on [n]: THERMAL [=y] && (ARCH_HAS_BANDGAP || COMPILE_TEST [=n]) && >> HAS_IOMEM [=y] >> Selected by [m]: >> - MMC_SDHCI_OMAP [=m] && MMC [=m] && MMC_SDHCI_PLTFM [=m] && OF [=y] >> >> >> Maybe there is already a patch for this? > > Keerthy can you please take a look at this issue? https://lore.kernel.org/patchwork/patch/1030366/ This is fixed. It is in the linux-next already. > > Regards, > > Tony >
Re: [PATCH -next] gpio: davinci: drop pointless static qualifier
On 23/01/19 2:19 PM, YueHaibing wrote:
> There is no need to have the 'gpio_unbanked' variable static since
> new value always be assigned before use it.
Acked-by: Keerthy
>
> Signed-off-by: YueHaibing
> ---
> drivers/gpio/gpio-davinci.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
> index bdb29e5..f250454 100644
> --- a/drivers/gpio/gpio-davinci.c
> +++ b/drivers/gpio/gpio-davinci.c
> @@ -465,7 +465,7 @@ static const struct irq_domain_ops davinci_gpio_irq_ops =
> {
>
> static struct irq_chip *davinci_gpio_get_irq_chip(unsigned int irq)
> {
> - static struct irq_chip_type gpio_unbanked;
> + struct irq_chip_type gpio_unbanked;
>
> gpio_unbanked = *irq_data_get_chip_type(irq_get_irq_data(irq));
>
> @@ -474,7 +474,7 @@ static struct irq_chip
> *davinci_gpio_get_irq_chip(unsigned int irq)
>
> static struct irq_chip *keystone_gpio_get_irq_chip(unsigned int irq)
> {
> - static struct irq_chip gpio_unbanked;
> + struct irq_chip gpio_unbanked;
>
> gpio_unbanked = *irq_get_chip(irq);
> return _unbanked;
>
Re: [Letux-kernel] [PATCH v3 3/3] arm: omap_hwmod disable ick autoidling when a hwmod requires that
On 19/01/19 1:28 PM, J, KEERTHY wrote: > > > On 1/19/2019 12:42 PM, Andreas Kemnade wrote: >> On Sat, 19 Jan 2019 12:09:48 +0530 >> "J, KEERTHY" wrote: >> >>> On 1/19/2019 1:18 AM, Tony Lindgren wrote: >>>> * Andreas Kemnade [190118 19:42]: >>>>> On Fri, 18 Jan 2019 20:38:47 +0100 >>>>> Andreas Kemnade wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> On Fri, 18 Jan 2019 10:36:30 -0800 >>>>>> Tony Lindgren wrote: >>>>>> >>>>>> [...] >>>>>>> til the next workaround. >>>>>>> >>>>>>>> That flags also causes the iclk being enabled/disabled >>>>>>>> manually. >>>>>>> >>>>>>> Yes but SWSUP_IDLE for the interface clock to me currently >>>>>>> just means: >>>>>>> >>>>>>> "manually enable and disable ocp interface clock" >>>>>>> >>>>>> well, if we want to manually disable it and not automatically, >>>>>> we have to disable autoidle or it will be automatically disabled. >>>>>> >>>>>> Disabling it manually when it is already auto-disabled (by >>>>>> autoidle) is >>>>>> just practically a no-op towards the clock. >>>>>> >>>>>>> and with your changes it becomes: >>>>>>> >>>>>>> "manually enable and disable ocp interface clock and block >>>>>>> autoidle while in use". >>>>>>> >>>>>>> So aren't we now changing the way things behave in general >>>>>>> for SWSUP_IDLE? >>>>>>> >>>>>> Yes, we are, so proper testing is needed. But If I read those >>>>>> comments >>>>>> it was always intended this way but not fully implemented because it >>>>>> appeared to be more work like needing a usecounter (which my patchset >>>>>> also adds) for that autoidle flag. >>>>>> >>>>> and there are quite few hwmods marked by this flag. >>>>> And then there are those clocks marked by this flags (on am33xx) which >>>>> do not have that autoidle feature at all, so the risk is not too high. >>>> >>>> Keerthy, can you please test this series on top of the >>>> related clock patches with your am335x PM test cases? >>> >>> Can you point me to the clock series that needs to be tested >>> along with this? >>> >> >> https://patchwork.kernel.org/project/linux-clk/list/?series=66691 > > Thanks Andreas. I will test both series and get back. Tested for DS0 (deeps sleep 0 on am33/am43 boards) No issues seen with the current patch series on top of clock series. Tested-by: Keerthy > >> >> Regards, >> Andreas >>
