* [PATCH RFC] arm64: dts: mediatek: mt8183-kodama: Split into base and overlays
From: Chen-Yu Tsai @ 2024-04-09 9:52 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: dianders, Chen-Yu Tsai, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
All the SKUs of Kodama share much of their .dts, as evident of the
inclusion of a common .dtsi file. However this scheme builds each
.dtb file as a complete device tree.
To deduplicate this, make the common .dtsi file a .dts file, and the
SKU specific .dts files into .dtso overlay source files. Have the build
system assemble the SKU specific .dtb files from these components.
The final composite .dtb files increase in size by around 54 kB, or 22.5%,
due to the inclusion of symbols and fixup tables, and extra phandle
properties. This could be slightly reduced by dropping the symbol and
fixup tables after the overlays are fully applied if desired.
However if the bootloader can assemble the end .dtb using the base .dtb
and overlays, and only those are counted, then the combined size
decreases by around 165 kB, or 68.7%.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Hi,
This is part of the work I'm looking into and will present at EOSS 2024
in Seattle [1].
The idea is to reorganize device trees so that devices within a common
family, instead of having a common .dtsi file, will share a base DTB
and apply one or more overlays on top. This allows an upstream [2] or
downstream [3] bundling script to be able to deduplicate the base DTB
and get some space savings, however minor they are compared to the
kernel binary executable.
This patch gives a simple conversion, but we could even look into
converting the entire MT8183 Kukui family, which are all based on the
"Kukui" hardware reference design.
There are some issues, hence the RFC:
1. The base .dtb doesn't have a valid board compatible string sequence
yet. Suppose we used the sequence
"google,kodama", "mediatek,mt8183"
for the base .dtb in this conversion, would that be acceptable? The
base .dtb would act like a fallback.
2. The composite .dtb files grow in size substantially, due to the base
.dtb file being built with overlay support. The symbols and fixup
tables could be trimmed out with `fdtput`, but there will still be
extra phandles, and also nodes with /omit-if-no-ref/ that would
have been removed.
For this I could maybe come up with a program to minify the DTB. That
would also work for existing composite .dtb files in-tree.
3. Such a scheme would require more awareness on the maintainer's part,
and of the .dtbo authors. The maintainer needs to be aware of how
the composite .dtb files are assembled. The authors need to know that
certain constructs, such as /delete-property/ or /delete-node/, won't
work.
[1] https://eoss24.sched.com/event/1aBGe/second-source-component-probing-on-device-tree-platforms-chen-yu-tsai-google-llc
[2] https://lore.kernel.org/linux-arm-kernel/20240329032836.141899-1-sjg@chromium.org/
[3] https://crrev.com/c/5412876
arch/arm64/boot/dts/mediatek/Makefile | 6 ++++++
...ukui-kodama-sku16.dts => mt8183-kukui-kodama-sku16.dtso} | 4 ++--
...ui-kodama-sku272.dts => mt8183-kukui-kodama-sku272.dtso} | 4 ++--
...ui-kodama-sku288.dts => mt8183-kukui-kodama-sku288.dtso} | 4 ++--
...ukui-kodama-sku32.dts => mt8183-kukui-kodama-sku32.dtso} | 4 ++--
.../{mt8183-kukui-kodama.dtsi => mt8183-kukui-kodama.dts} | 0
6 files changed, 14 insertions(+), 8 deletions(-)
rename arch/arm64/boot/dts/mediatek/{mt8183-kukui-kodama-sku16.dts => mt8183-kukui-kodama-sku16.dtso} (90%)
rename arch/arm64/boot/dts/mediatek/{mt8183-kukui-kodama-sku272.dts => mt8183-kukui-kodama-sku272.dtso} (90%)
rename arch/arm64/boot/dts/mediatek/{mt8183-kukui-kodama-sku288.dts => mt8183-kukui-kodama-sku288.dtso} (90%)
rename arch/arm64/boot/dts/mediatek/{mt8183-kukui-kodama-sku32.dts => mt8183-kukui-kodama-sku32.dtso} (90%)
rename arch/arm64/boot/dts/mediatek/{mt8183-kukui-kodama.dtsi => mt8183-kukui-kodama.dts} (100%)
diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index 9234dadfe1ad..6986d7a2efaa 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -46,6 +46,12 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu-sku22.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-katsu-sku32.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-katsu-sku38.dtb
+
+mt8183-kukui-kodama-sku16-dtbs := mt8183-kukui-kodama.dtb mt8183-kukui-kodama-sku16.dtbo
+mt8183-kukui-kodama-sku272-dtbs := mt8183-kukui-kodama.dtb mt8183-kukui-kodama-sku272.dtbo
+mt8183-kukui-kodama-sku288-dtbs := mt8183-kukui-kodama.dtb mt8183-kukui-kodama-sku288.dtbo
+mt8183-kukui-kodama-sku32-dtbs := mt8183-kukui-kodama.dtb mt8183-kukui-kodama-sku32.dtbo
+
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku16.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku272.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku288.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku16.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku16.dtso
similarity index 90%
rename from arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku16.dts
rename to arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku16.dtso
index 7213cdcca612..20675de68823 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku16.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku16.dtso
@@ -8,9 +8,9 @@
*/
/dts-v1/;
-#include "mt8183-kukui-kodama.dtsi"
+/plugin/;
-/ {
+&{/} {
model = "MediaTek kodama sku16 board";
chassis-type = "tablet";
compatible = "google,kodama-sku16", "google,kodama", "mediatek,mt8183";
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku272.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku272.dtso
similarity index 90%
rename from arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku272.dts
rename to arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku272.dtso
index bbf0cd1aa66d..46ab97a18003 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku272.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku272.dtso
@@ -8,9 +8,9 @@
*/
/dts-v1/;
-#include "mt8183-kukui-kodama.dtsi"
+/plugin/;
-/ {
+&{/} {
model = "MediaTek kodama sku272 board";
chassis-type = "tablet";
compatible = "google,kodama-sku272", "google,kodama", "mediatek,mt8183";
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku288.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku288.dtso
similarity index 90%
rename from arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku288.dts
rename to arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku288.dtso
index a429ffeac3bd..e27b56f1826d 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku288.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku288.dtso
@@ -8,9 +8,9 @@
*/
/dts-v1/;
-#include "mt8183-kukui-kodama.dtsi"
+/plugin/;
-/ {
+&{/} {
model = "MediaTek kodama sku288 board";
chassis-type = "tablet";
compatible = "google,kodama-sku288", "google,kodama", "mediatek,mt8183";
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku32.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku32.dtso
similarity index 90%
rename from arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku32.dts
rename to arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku32.dtso
index 5a416143b4a0..d9a13ff7abf2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku32.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku32.dtso
@@ -8,9 +8,9 @@
*/
/dts-v1/;
-#include "mt8183-kukui-kodama.dtsi"
+/plugin/;
-/ {
+&{/} {
model = "MediaTek kodama sku32 board";
chassis-type = "tablet";
compatible = "google,kodama-sku32", "google,kodama", "mediatek,mt8183";
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dts
similarity index 100%
rename from arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi
rename to arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dts
--
2.44.0.478.gd926399ef9-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH bpf] arm32, bpf: Fix sign-extension mov instruction
From: Puranjay Mohan @ 2024-04-09 9:50 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Russell King, Russell King (Oracle), bpf, linux-arm-kernel,
linux-kernel
Cc: puranjay12
The current implementation of the mov instruction with sign extension
clobbers the source register because it sign extends the source and then
moves it to the destination.
Fix this by moving the src to a temporary register before doing the sign
extension only if src is not an emulated register (on the scratch stack).
Also fix the emit_a32_movsx_r64() to put the register back on scratch
stack if that register is emulated on stack.
Fixes: fc832653fa0d ("arm32, bpf: add support for sign-extension mov instruction")
Reported-by: syzbot+186522670e6722692d86@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/000000000000e9a8d80615163f2a@google.com/
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
---
arch/arm/net/bpf_jit_32.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index 1d672457d02f..8fde6ab66cb4 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -878,6 +878,13 @@ static inline void emit_a32_mov_r(const s8 dst, const s8 src, const u8 off,
rt = arm_bpf_get_reg32(src, tmp[0], ctx);
if (off && off != 32) {
+ /* If rt is not a stacked register, move it to tmp, so it doesn't get clobbered by
+ * the shift operations.
+ */
+ if (rt == src) {
+ emit(ARM_MOV_R(tmp[0], rt), ctx);
+ rt = tmp[0];
+ }
emit(ARM_LSL_I(rt, rt, 32 - off), ctx);
emit(ARM_ASR_I(rt, rt, 32 - off), ctx);
}
@@ -919,15 +926,15 @@ static inline void emit_a32_movsx_r64(const bool is64, const u8 off, const s8 ds
const s8 *tmp = bpf2a32[TMP_REG_1];
const s8 *rt;
- rt = arm_bpf_get_reg64(dst, tmp, ctx);
-
emit_a32_mov_r(dst_lo, src_lo, off, ctx);
if (!is64) {
if (!ctx->prog->aux->verifier_zext)
/* Zero out high 4 bytes */
emit_a32_mov_i(dst_hi, 0, ctx);
} else {
+ rt = arm_bpf_get_reg64(dst, tmp, ctx);
emit(ARM_ASR_I(rt[0], rt[1], 31), ctx);
+ arm_bpf_put_reg64(dst, rt, ctx);
}
}
--
2.40.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [EXT] Re: [PATCH v8 6/6] docs: trusted-encrypted: add DCP as new trust source
From: Kshitiz Varshney @ 2024-04-09 9:48 UTC (permalink / raw)
To: Jarkko Sakkinen, David Gstir, Mimi Zohar, James Bottomley,
Herbert Xu, David S. Miller
Cc: Shawn Guo, Jonathan Corbet, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, dl-linux-imx, Ahmad Fatoum, sigma star Kernel Team,
David Howells, Li Yang, Paul Moore, James Morris, Serge E. Hallyn,
Paul E. McKenney, Randy Dunlap, Catalin Marinas,
Rafael J. Wysocki, Tejun Heo, Steven Rostedt (Google),
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org,
linux-security-module@vger.kernel.org, Richard Weinberger,
David Oberhollenzer, Varun Sethi, Gaurav Jain, Pankaj Gupta
In-Reply-To: <D0ALT2QCUIYB.8NFTE7Z18JKN@kernel.org>
Hi Jarkko,
> -----Original Message-----
> From: Jarkko Sakkinen <jarkko@kernel.org>
> Sent: Wednesday, April 3, 2024 9:18 PM
> To: David Gstir <david@sigma-star.at>; Mimi Zohar <zohar@linux.ibm.com>;
> James Bottomley <jejb@linux.ibm.com>; Herbert Xu
> <herbert@gondor.apana.org.au>; David S. Miller <davem@davemloft.net>
> Cc: Shawn Guo <shawnguo@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Sascha Hauer <s.hauer@pengutronix.de>; Pengutronix
> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> <festevam@gmail.com>; dl-linux-imx <linux-imx@nxp.com>; Ahmad Fatoum
> <a.fatoum@pengutronix.de>; sigma star Kernel Team
> <upstream+dcp@sigma-star.at>; David Howells <dhowells@redhat.com>; Li
> Yang <leoyang.li@nxp.com>; Paul Moore <paul@paul-moore.com>; James
> Morris <jmorris@namei.org>; Serge E. Hallyn <serge@hallyn.com>; Paul E.
> McKenney <paulmck@kernel.org>; Randy Dunlap <rdunlap@infradead.org>;
> Catalin Marinas <catalin.marinas@arm.com>; Rafael J. Wysocki
> <rafael.j.wysocki@intel.com>; Tejun Heo <tj@kernel.org>; Steven Rostedt
> (Google) <rostedt@goodmis.org>; linux-doc@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-integrity@vger.kernel.org;
> keyrings@vger.kernel.org; linux-crypto@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org; linux-security-
> module@vger.kernel.org; Richard Weinberger <richard@nod.at>; David
> Oberhollenzer <david.oberhollenzer@sigma-star.at>
> Subject: [EXT] Re: [PATCH v8 6/6] docs: trusted-encrypted: add DCP as new
> trust source
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report
> this email' button
>
>
> On Wed Apr 3, 2024 at 10:21 AM EEST, David Gstir wrote:
> > Update the documentation for trusted and encrypted KEYS with DCP as
> > new trust source:
> >
> > - Describe security properties of DCP trust source
> > - Describe key usage
> > - Document blob format
> >
> > Co-developed-by: Richard Weinberger <richard@nod.at>
> > Signed-off-by: Richard Weinberger <richard@nod.at>
> > Co-developed-by: David Oberhollenzer
> > <david.oberhollenzer@sigma-star.at>
> > Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
> > Signed-off-by: David Gstir <david@sigma-star.at>
> > ---
> > .../security/keys/trusted-encrypted.rst | 53 +++++++++++++++++++
> > security/keys/trusted-keys/trusted_dcp.c | 19 +++++++
> > 2 files changed, 72 insertions(+)
> >
> > diff --git a/Documentation/security/keys/trusted-encrypted.rst
> > b/Documentation/security/keys/trusted-encrypted.rst
> > index e989b9802f92..f4d7e162d5e4 100644
> > --- a/Documentation/security/keys/trusted-encrypted.rst
> > +++ b/Documentation/security/keys/trusted-encrypted.rst
> > @@ -42,6 +42,14 @@ safe.
> > randomly generated and fused into each SoC at manufacturing time.
> > Otherwise, a common fixed test key is used instead.
> >
> > + (4) DCP (Data Co-Processor: crypto accelerator of various i.MX
> > + SoCs)
> > +
> > + Rooted to a one-time programmable key (OTP) that is generally
> burnt
> > + in the on-chip fuses and is accessible to the DCP encryption engine
> only.
> > + DCP provides two keys that can be used as root of trust: the OTP
> key
> > + and the UNIQUE key. Default is to use the UNIQUE key, but selecting
> > + the OTP key can be done via a module parameter
> (dcp_use_otp_key).
> > +
> > * Execution isolation
> >
> > (1) TPM
> > @@ -57,6 +65,12 @@ safe.
> >
> > Fixed set of operations running in isolated execution environment.
> >
> > + (4) DCP
> > +
> > + Fixed set of cryptographic operations running in isolated execution
> > + environment. Only basic blob key encryption is executed there.
> > + The actual key sealing/unsealing is done on main processor/kernel
> space.
> > +
> > * Optional binding to platform integrity state
> >
> > (1) TPM
> > @@ -79,6 +93,11 @@ safe.
> > Relies on the High Assurance Boot (HAB) mechanism of NXP SoCs
> > for platform integrity.
> >
> > + (4) DCP
> > +
> > + Relies on Secure/Trusted boot process (called HAB by vendor) for
> > + platform integrity.
> > +
> > * Interfaces and APIs
> >
> > (1) TPM
> > @@ -94,6 +113,11 @@ safe.
> >
> > Interface is specific to silicon vendor.
> >
> > + (4) DCP
> > +
> > + Vendor-specific API that is implemented as part of the DCP crypto
> driver in
> > + ``drivers/crypto/mxs-dcp.c``.
> > +
> > * Threat model
> >
> > The strength and appropriateness of a particular trust source
> > for a given @@ -129,6 +153,13 @@ selected trust source:
> > CAAM HWRNG, enable CRYPTO_DEV_FSL_CAAM_RNG_API and ensure
> the device
> > is probed.
> >
> > + * DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs)
> > +
> > + The DCP hardware device itself does not provide a dedicated RNG
> interface,
> > + so the kernel default RNG is used. SoCs with DCP like the i.MX6ULL do
> have
> > + a dedicated hardware RNG that is independent from DCP which can be
> enabled
> > + to back the kernel RNG.
> > +
> > Users may override this by specifying ``trusted.rng=kernel`` on the
> > kernel command-line to override the used RNG with the kernel's random
> number pool.
> >
> > @@ -231,6 +262,19 @@ Usage::
> > CAAM-specific format. The key length for new keys is always in bytes.
> > Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
> >
> > +Trusted Keys usage: DCP
> > +-----------------------
> > +
> > +Usage::
> > +
> > + keyctl add trusted name "new keylen" ring
> > + keyctl add trusted name "load hex_blob" ring
> > + keyctl print keyid
> > +
> > +"keyctl print" returns an ASCII hex copy of the sealed key, which is
> > +in format specific to this DCP key-blob implementation. The key
> > +length for new keys is always in bytes. Trusted Keys can be 32 - 128 bytes
> (256 - 1024 bits).
> > +
> > Encrypted Keys usage
> > --------------------
> >
> > @@ -426,3 +470,12 @@ string length.
> > privkey is the binary representation of TPM2B_PUBLIC excluding the
> > initial TPM2B header which can be reconstructed from the ASN.1 octed
> > string length.
> > +
> > +DCP Blob Format
> > +---------------
> > +
> > +.. kernel-doc:: security/keys/trusted-keys/trusted_dcp.c
> > + :doc: dcp blob format
> > +
> > +.. kernel-doc:: security/keys/trusted-keys/trusted_dcp.c
> > + :identifiers: struct dcp_blob_fmt
> > diff --git a/security/keys/trusted-keys/trusted_dcp.c
> > b/security/keys/trusted-keys/trusted_dcp.c
> > index 16c44aafeab3..b5f81a05be36 100644
> > --- a/security/keys/trusted-keys/trusted_dcp.c
> > +++ b/security/keys/trusted-keys/trusted_dcp.c
> > @@ -19,6 +19,25 @@
> > #define DCP_BLOB_VERSION 1
> > #define DCP_BLOB_AUTHLEN 16
> >
> > +/**
> > + * DOC: dcp blob format
> > + *
> > + * The Data Co-Processor (DCP) provides hardware-bound AES keys using
> > +its
> > + * AES encryption engine only. It does not provide direct key
> sealing/unsealing.
> > + * To make DCP hardware encryption keys usable as trust source, we
> > +define
> > + * our own custom format that uses a hardware-bound key to secure the
> > +sealing
> > + * key stored in the key blob.
> > + *
> > + * Whenever a new trusted key using DCP is generated, we generate a
> > +random 128-bit
> > + * blob encryption key (BEK) and 128-bit nonce. The BEK and nonce are
> > +used to
> > + * encrypt the trusted key payload using AES-128-GCM.
> > + *
> > + * The BEK itself is encrypted using the hardware-bound key using the
> > +DCP's AES
> > + * encryption engine with AES-128-ECB. The encrypted BEK, generated
> > +nonce,
> > + * BEK-encrypted payload and authentication tag make up the blob
> > +format together
> > + * with a version number, payload length and authentication tag.
> > + */
> > +
> > /**
> > * struct dcp_blob_fmt - DCP BLOB format.
> > *
>
> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
>
> I can only test that this does not break a machine without the hardware
> feature.
>
> Is there anyone who could possibly peer test these patches?
I am already working on testing this patchset on i.MX6 platform.
Regards,
Kshitiz
> BR, Jarkko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 8/9] dt-bindings: rtc: stmp3xxx-rtc: convert to dtschema
From: Krzysztof Kozlowski @ 2024-04-09 9:42 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <89e7db2d-1de0-4e2e-a2d2-f00d45399b11@gmail.com>
On 09/04/2024 11:22, Javier Carrasco wrote:
> On 4/9/24 09:40, Krzysztof Kozlowski wrote:
>> On 08/04/2024 17:53, Javier Carrasco wrote:
>>> Convert existing binding to dtschema to support validation.
>>>
>>> The 'fsl,imx28-rtc' compatible is currently not supported, and it is
>>> only referenced in this binding and in nxp/mxs/imx28.dtsi. Therefore,
>>> that compatible has been dropped, which triggers a warning when testing
>>> the DT against the new binding.
>>
>> Instead document missing compatibles and mention this in commit msg.
>>
>
>
> There is no driver that will match 'fsl,imx28-rtc', only
> 'fsl,stmp3xxx-rtc', so I am not sure how to document the missing
> compatible in a sensible way. My first suggestion to account for
I don't understand what driver matching to it has anything to do with
the problem discussed here.
You have DTS, so you can see how it should be written.
> undocumented strings would be:
>
> compatible:
> oneOf:
> - items:
> - enum:
> - fsl,imx23-rtc
> - fsl,imx28-rtc
> - const: fsl,stmp3xxx-rtc
> - const: fsl,stmp3xxx-rtc
>
> Any suggestions or improvements?
>
>>>
>>> There is another reference to fsl,stmp3xxx-rtc in nxp/mxs/imx23.dtsi,
>>> where another unsupported compatible 'fsl,imx23-rtc' is used, and the
>>> same problem would arise when testing the file against the new binding.
>>
>> Please write concise messages... you have to paragraphs about the same?
>> What is the difference here?
>>
> The difference is that 'fsl,imx23-rtc' was not even mentioned in any
> binding, and it can only be found in imx23.dtsi. 'fsl,imx28-rtc' was
> indeed mentioned in the txt binding.
Bindings are not correct. Many times.
>
> My understanding after your comment is that we should gather
> undocumented compatibles and add them to the bindings they would belong
> to,no matter if they are used anywhere or not. I added this one to the
> suggestion above as well.
What do you mean "unused"? If these you call unused, then shall we
remove 90% of such "unused" compatibles from the binding? No. See
writing bindings or hundreds of other bindings as examples. You need
specific part.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/9] dt-bindings: rtc: lpc32xx-rtc: move to trivial-rtc
From: Krzysztof Kozlowski @ 2024-04-09 9:40 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32
In-Reply-To: <6dc808bf-682f-4e91-aac7-7ce6f05a0ab4@gmail.com>
On 09/04/2024 10:52, Javier Carrasco wrote:
> On 4/9/24 09:34, Krzysztof Kozlowski wrote:
>> On 08/04/2024 17:53, Javier Carrasco wrote:
>>> This RTC requires a compatible, a reg and a single interrupt,
>>> which makes it suitable for a direct conversion into trivial-rtc.
>>>
>>> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
>>> ---
>>> Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt | 15 ---------------
>>> Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
>>> 2 files changed, 2 insertions(+), 15 deletions(-)
>>
>> This one no... and if you tested DTS you would see errors, although you
>> need to test specific lpc config, not multi_v7.
>>
>> It does not look like you tested the DTS against bindings. Please run
>> `make dtbs_check W=1` (see
>> Documentation/devicetree/bindings/writing-schema.rst or
>> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
>> for instructions).
>>
>> Anyway, you *must* check all DTS before moving anything to trivial.
>>
>> Does it mean all other bindings were not checked against DTS at all?
>>
>> Best regards,
>> Krzysztof
>>
> Hi,
>
> I did check the conversion against nxp/lpc/lpc3250-phy3250.dts, which
> throws a message about the 'clocks' property.
>
> That property is not documented in the original binding, and even though
> it could be missing, I could not find any function to get a clock (i.e.
Old bindings are not really accurate.
> any form of clk_get()) in rtc-lpc32xx.c, which is the only file where
> the compatible can be found.
>
> Is therefore the property not useless in the dts? My apologies if I am
> missing something here.
Useless for whom? For Linux yes. For U-Boot or out-of-tree users of DTS,
I don't know. Anyway the true question is if there is a clock or there
is no. If there is a clock, then it should be in the binding even if
Linux driver does not use it.
I propose to add it and be done with it.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 04/15] kunit: Add documentation for warning backtrace suppression API
From: David Gow @ 2024-04-09 8:29 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kselftest, David Airlie, Arnd Bergmann, Maíra Canal,
Dan Carpenter, Kees Cook, Daniel Diaz, Arthur Grillo,
Brendan Higgins, Naresh Kamboju, Maarten Lankhorst, Andrew Morton,
Maxime Ripard, Ville Syrjälä, Daniel Vetter,
Thomas Zimmermann, dri-devel, kunit-dev, linux-arch,
linux-arm-kernel, linux-doc, linux-kernel, linux-parisc,
linuxppc-dev, linux-riscv, linux-s390, linux-sh, loongarch,
netdev, x86, Linux Kernel Functional Testing
In-Reply-To: <20240403131936.787234-5-linux@roeck-us.net>
[-- Attachment #1.1: Type: text/plain, Size: 3016 bytes --]
On Wed, 3 Apr 2024 at 21:19, Guenter Roeck <linux@roeck-us.net> wrote:
>
> Document API functions for suppressing warning backtraces.
>
> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
> Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
This looks good to me: thanks for adding the documentation!
If we add integration between this and the KUnit resource system,
we'll need to add that to this documentation.
I wonder if it would make sense to have an example where the
DEFINE_SUPPRESSED_WARNING() is global, e.g., in the test init/exit
functions. That might overcomplicate it a bit.
It also might be nice to document the individual macros with kerneldoc
comments. (Though, that could equally fit in patch #1).
Still, this is the most important bit, so I'm happy to have it as-is.
Reviewed-by: David Gow <davidgow@google.com>
Cheers,
-- David
> v2:
> - Rebased to v6.9-rc1
> - Added Tested-by:, Acked-by:, and Reviewed-by: tags
> v3:
> - Rebased to v6.9-rc2
>
> Documentation/dev-tools/kunit/usage.rst | 30 ++++++++++++++++++++++++-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst
> index 22955d56b379..8d3d36d4103d 100644
> --- a/Documentation/dev-tools/kunit/usage.rst
> +++ b/Documentation/dev-tools/kunit/usage.rst
> @@ -157,6 +157,34 @@ Alternatively, one can take full control over the error message by using
> if (some_setup_function())
> KUNIT_FAIL(test, "Failed to setup thing for testing");
>
> +Suppressing warning backtraces
> +------------------------------
> +
> +Some unit tests trigger warning backtraces either intentionally or as side
> +effect. Such backtraces are normally undesirable since they distract from
> +the actual test and may result in the impression that there is a problem.
> +
> +Such backtraces can be suppressed. To suppress a backtrace in some_function(),
> +use the following code.
> +
> +.. code-block:: c
> +
> + static void some_test(struct kunit *test)
> + {
> + DEFINE_SUPPRESSED_WARNING(some_function);
> +
> + START_SUPPRESSED_WARNING(some_function);
> + trigger_backtrace();
> + END_SUPPRESSED_WARNING(some_function);
> + }
> +
> +SUPPRESSED_WARNING_COUNT() returns the number of suppressed backtraces. If the
> +suppressed backtrace was triggered on purpose, this can be used to check if
> +the backtrace was actually triggered.
> +
> +.. code-block:: c
> +
> + KUNIT_EXPECT_EQ(test, SUPPRESSED_WARNING_COUNT(some_function), 1);
>
> Test Suites
> ~~~~~~~~~~~
> @@ -857,4 +885,4 @@ For example:
> dev_managed_string = devm_kstrdup(fake_device, "Hello, World!");
>
> // Everything is cleaned up automatically when the test ends.
> - }
> \ No newline at end of file
> + }
> --
> 2.39.2
>
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4014 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 0/7] Coresight for Kernel panic and watchdog reset
From: James Clark @ 2024-04-09 9:28 UTC (permalink / raw)
To: Linu Cherian
Cc: linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org,
linux-kernel@vger.kernel.org, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
devicetree@vger.kernel.org, Sunil Kovvuri Goutham, George Cherian,
suzuki.poulose@arm.com, mike.leach@linaro.org, leo.yan@linaro.org
In-Reply-To: <PH0PR18MB5002D016166F97E665BB0F39CE072@PH0PR18MB5002.namprd18.prod.outlook.com>
On 09/04/2024 01:10, Linu Cherian wrote:
> Hi Suzuki/James,
>
>> -----Original Message-----
>> From: Linu Cherian <lcherian@marvell.com>
>> Sent: Thursday, March 7, 2024 9:06 AM
>> To: suzuki.poulose@arm.com; mike.leach@linaro.org; james.clark@arm.com;
>> leo.yan@linaro.org
>> Cc: linux-arm-kernel@lists.infradead.org; coresight@lists.linaro.org; linux-
>> kernel@vger.kernel.org; robh+dt@kernel.org;
>> krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org;
>> devicetree@vger.kernel.org; Sunil Kovvuri Goutham
>> <sgoutham@marvell.com>; George Cherian <gcherian@marvell.com>; Linu
>> Cherian <lcherian@marvell.com>
>> Subject: [PATCH v7 0/7] Coresight for Kernel panic and watchdog reset
>>
>> This patch series is rebased on v6.8-rc4 from coresisght tree,[1], since latest
>> changes are dependent on coresight_get/set_mode APIs.
>>
>
>
> Do you have any feedback on this version ?
>
> Thanks.
>
Hi Linu,
Sorry it was on my list, I'll take a look this week.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 00/13] drm/display: Convert helpers Kconfig symbols to depends on
From: Geert Uytterhoeven @ 2024-04-09 9:26 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Daniel Vetter,
Jani Nikula, dri-devel, Jani Nikula, Lucas De Marchi,
kernel test robot, linux-renesas-soc, linux-arm-kernel
In-Reply-To: <20240327-kms-kconfig-helpers-v3-0-eafee11b84b3@kernel.org>
Hi Maxime,
On Wed, 27 Mar 2024, Maxime Ripard wrote:
> Jani recently pointed out that the Kconfig symbols are a bit difficult
> to work with at the moment when they depend on each other, and that
> using depends on would be a better idea, but no one really did the work
> so far.
>
> So here it goes :)
>
> It's been tested by comparing the riscv defconfig, arm
> multi_v7_defconfig, arm64 defconfig, drm-misc-arm, drm-misc-arm64 and
> drm-misc-x86 before and after this series and making sure they are
> identical.
That is not true: comparing drm-misc/for-linux-next to v6.9-rc2,
arm/multi_v7_defconfig, arm64/defconfig, and riscv/defconfig lost
several of:
- CONFIG_DRM_DW_HDMI,
- CONFIG_DRM_DW_HDMI_AHB_AUDIO,
- CONFIG_DRM_DW_HDMI_CEC,
- CONFIG_DRM_DW_HDMI_I2S_AUDIO,
- CONFIG_DRM_IMX_HDMI.
- CONFIG_DRM_MESON_DW_HDMI,
- CONFIG_DRM_RCAR_DW_HDMI,
- CONFIG_DRM_SUN8I_DW_HDMI,
- CONFIG_ROCKCHIP_DW_HDMI,
- CONFIG_SND_MESON_G12A_TOHDMITX,
> Let me know what you think,
IMHO this series looks like a big usuability issue for anyone
configuring the kernel, and you try to work around this by sprinkling
"default y" around.
The user should not need to know which helpers are needed for the driver
he is interested in. When a symbol selects another symbol, it should
just make sure the dependencies of the target symbol are met.
Thanks for reverting ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set additionalProperties to true
From: Peng Fan @ 2024-04-09 9:25 UTC (permalink / raw)
To: Krzysztof Kozlowski, Peng Fan (OSS), Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Sudeep Holla,
Cristian Marussi
Cc: devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <DU0PR04MB9417C8C5013C72AB1F61F1C588002@DU0PR04MB9417.eurprd04.prod.outlook.com>
Hi Krzysztof,
> Subject: RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> additionalProperties to true
>
> > Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > additionalProperties to true
> >
> > On 08/04/2024 08:08, Peng Fan wrote:
> > >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > >> additionalProperties to true
> > >>
> > >> On 08/04/2024 01:50, Peng Fan wrote:
> > >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > >>>> additionalProperties to true
> > >>>>
> > >>>> On 07/04/2024 12:04, Peng Fan wrote:
> > >>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > >>>>>> set additionalProperties to true
> > >>>>>>
> > >>>>>> On 07/04/2024 02:37, Peng Fan wrote:
> > >>>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > >>>>>>>> set additionalProperties to true
> > >>>>>>>>
> > >>>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> > >>>>>>>>> From: Peng Fan <peng.fan@nxp.com>
> > >>>>>>>>>
> > >>>>>>>>> When adding vendor extension protocols, there is dt-schema
> > >> warning:
> > >>>>>>>>> "
> > >>>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do
> > >>>>>>>>> not match any of the regexes: 'pinctrl-[0-9]+'
> > >>>>>>>>> "
> > >>>>>>>>>
> > >>>>>>>>> Set additionalProperties to true to address the issue.
> > >>>>>>>>
> > >>>>>>>> I do not see anything addressed here, except making the
> > >>>>>>>> binding accepting anything anywhere...
> > >>>>>>>
> > >>>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
> > >>>>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI
> > >>>>>>> protocol
> > >> extension.
> > >>>>>>>
> > >>>>>>> With additionalProperties set to false, I not know how, please
> > suggest.
> > >>>>>>
> > >>>>>> First of all, you cannot affect negatively existing devices
> > >>>>>> (their
> > >>>>>> bindings) and your patch does exactly that. This should make
> > >>>>>> you thing what is the correct approach...
> > >>>>>>
> > >>>>>> Rob gave you the comment about missing compatible - you still
> > >>>>>> did not address that.
> > >>>>>
> > >>>>> I added the compatible in patch 2/6 in the examples "compatible
> > >>>>> =
> > >>>> "arm,scmi";"
> > >>>>
> > >>>> So you claim that your vendor extensions are the same or fully
> > >>>> compatible with arm,scmi and you add nothing... Are your
> > >>>> extensions/protocol valid for arm,scmi?
> > >>>
> > >>> Yes. They are valid for arm,scmi.
> > >>>
> > >>> If yes, why is this in separate binding. If no, why you use
> > >>> someone
> > >>>> else's compatible?
> > >>>
> > >>> Per SCMI Spec
> > >>> 0x80-0xFF: Reserved for vendor or platform-specific extensions to
> > >>> this interface
> > >>>
> > >>> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use
> > >>> the id for their own protocol.
> > >>
> > >> So how are they valid for arm,scmi? I don't understand.
> > >
> > > arm,scmi is a firmware compatible string. The protocol node is a sub-node.
> > > I think the arm,scmi is that saying the firmware following SCMI spec
> > > to implement the protocols.
> > >
> > > For vendor reserved ID, firmware also follow the SCMI spec to
> > > implement their own usage, so from firmware level, it is ARM SCMI
> > > spec
> > compatible.
> >
> > That's not the point. It is obvious that your firmware is compatible
> > with arm,scmi, but what you try to say in this and revised patch is
> > that every arm,scmi is compatible with your implementation. What you
> > are saying is that 0x84 is MISC protocol for every firmware, Qualcomm,
> > NXP, Samsung, TI, Mediatek etc.
> >
> > I claim it is not true. 0x84 is not MISC for Qualcomm, for example.
>
> You are right. I am lost now on how to add vendor ID support, using
> arm,scmi.yaml or adding a new imx,scmi.yaml or else.
Do you have any suggestions on how to add vendor protocol in
dt-schema? I am not sure what to do next, still keep imx,scmi.yaml
or add vendor stuff in arm,scmi.yaml?
Thanks,
Peng.
>
> Please suggest.
>
> Thanks,
> Peng
> >
> > Best regards,
> > Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [EXT] Re: [PATCH v3] arm64: dts: imx8ulpx`
From: Pankaj Gupta @ 2024-04-09 9:23 UTC (permalink / raw)
To: Krzysztof Kozlowski, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, dl-linux-imx, Peng Fan,
Jacky Bai, Bough Chen, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Varun Sethi
In-Reply-To: <e63cd9ec-45f3-4ae7-8d68-e923b35d05f6@linaro.org>
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Tuesday, April 9, 2024 12:57 PM
> To: Pankaj Gupta <pankaj.gupta@nxp.com>; robh+dt@kernel.org;
> krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org;
> shawnguo@kernel.org; s.hauer@pengutronix.de; kernel@pengutronix.de;
> festevam@gmail.com; dl-linux-imx <linux-imx@nxp.com>; Peng Fan
> <peng.fan@nxp.com>; Jacky Bai <ping.bai@nxp.com>; Bough Chen
> <haibo.chen@nxp.com>; devicetree@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> Cc: Varun Sethi <V.Sethi@nxp.com>
> Subject: [EXT] Re: [PATCH v3] arm64: dts: imx8ulpx`
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report
> this email' button
>
>
> On 09/04/2024 09:06, Pankaj Gupta wrote:
> > Add crypto node in device tree for:
> > - CAAM job-ring
> >
> > Signed-off-by: Varun Sethi <v.sethi@nxp.com>
> > Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
>
> v3? Where is the changelog? What was happening here?
[Accepted] Added in v4.
>
> > ---
> > arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 32
> ++++++++++++++++++++++
> > 1 file changed, 32 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> > index 8a6596d5a581..946f2b68d16f 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> > @@ -252,6 +252,38 @@ pcc3: clock-controller@292d0000 {
> > #reset-cells = <1>;
> > };
> >
> > + crypto: crypto@292e0000 {
> > + compatible = "fsl,sec-v4.0";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + reg = <0x292e0000 0x10000>;
> > + ranges = <0 0x292e0000 0x10000>;
>
> Keep the order as requested in DTS coding style.
[Accepted] Corrected in v4.
>
> Best regards,
> Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4] arm64: dts: imx8ulp: add caam jr
From: Pankaj Gupta @ 2024-04-09 9:20 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer,
kernel, festevam, linux-imx, peng.fan, ping.bai, haibo.chen,
devicetree, linux-arm-kernel, linux-kernel
Cc: Pankaj Gupta, Varun Sethi
Add crypto node in device tree for:
- CAAM job-ring
Signed-off-by: Varun Sethi <v.sethi@nxp.com>
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
---
v4:
- Order of node properties changed.
v3:
- Commit message title is changed from "imx8ulp-evk" to "imx8ulp".
v2:
- As requested, this patch is separated from the larger patch-set of 9
patches.
Commit
arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 32 ++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
index 8a6596d5a581..ed86854a59c3 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
@@ -252,6 +252,38 @@ pcc3: clock-controller@292d0000 {
#reset-cells = <1>;
};
+ crypto: crypto@292e0000 {
+ compatible = "fsl,sec-v4.0";
+ reg = <0x292e0000 0x10000>;
+ ranges = <0 0x292e0000 0x10000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ sec_jr0: jr@1000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x1000 0x1000>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sec_jr1: jr@2000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x2000 0x1000>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sec_jr2: jr@3000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x3000 0x1000>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sec_jr3: jr@4000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x4000 0x1000>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
tpm5: tpm@29340000 {
compatible = "fsl,imx8ulp-tpm", "fsl,imx7ulp-tpm";
reg = <0x29340000 0x1000>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH net-next v2 5/5] ARM: dts: r9a06g032: describe GMAC1
From: Romain Gantois @ 2024-04-09 9:21 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, Russell King, Clément Léger
Cc: Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-renesas-soc, linux-stm32, linux-arm-kernel, Romain Gantois
In-Reply-To: <20240409-rzn1-gmac1-v2-0-79ca45f2fc79@bootlin.com>
From: Clément Léger <clement.leger@bootlin.com>
The r9a06g032 SoC of the RZ/N1 family features two GMAC devices named
GMAC1/2, that are based on Synopsys cores. GMAC1 is connected to a
RGMII/RMII converter that is already described in this device tree.
Signed-off-by: "Clément Léger" <clement.leger@bootlin.com>
[rgantois: commit log]
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
arch/arm/boot/dts/renesas/r9a06g032.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/renesas/r9a06g032.dtsi b/arch/arm/boot/dts/renesas/r9a06g032.dtsi
index fa63e1afc4ef..cab7a641f95b 100644
--- a/arch/arm/boot/dts/renesas/r9a06g032.dtsi
+++ b/arch/arm/boot/dts/renesas/r9a06g032.dtsi
@@ -316,6 +316,25 @@ dma1: dma-controller@40105000 {
data-width = <8>;
};
+ gmac1: ethernet@44000000 {
+ compatible = "renesas,r9a06g032-gmac", "renesas,rzn1-gmac", "snps,dwmac";
+ reg = <0x44000000 0x2000>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+ clocks = <&sysctrl R9A06G032_HCLK_GMAC0>;
+ clock-names = "stmmaceth";
+ power-domains = <&sysctrl>;
+ snps,multicast-filter-bins = <256>;
+ snps,perfect-filter-entries = <128>;
+ tx-fifo-depth = <2048>;
+ rx-fifo-depth = <4096>;
+ pcs-handle = <&mii_conv1>;
+ status = "disabled";
+ };
+
gmac2: ethernet@44002000 {
compatible = "renesas,r9a06g032-gmac", "renesas,rzn1-gmac", "snps,dwmac";
reg = <0x44002000 0x2000>;
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH net-next v2 1/5] dt-bindings: net: renesas,rzn1-gmac: Document RZ/N1 GMAC support
From: Romain Gantois @ 2024-04-09 9:21 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, Russell King, Clément Léger
Cc: Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-renesas-soc, linux-stm32, linux-arm-kernel, Romain Gantois
In-Reply-To: <20240409-rzn1-gmac1-v2-0-79ca45f2fc79@bootlin.com>
From: Clément Léger <clement.leger@bootlin.com>
The RZ/N1 series of MPUs feature up to two Gigabit Ethernet controllers.
These controllers are based on Synopsys IPs. They can be connected to
RZ/N1 RGMII/RMII converters.
Add a binding that describes these GMAC devices.
Signed-off-by: "Clément Léger" <clement.leger@bootlin.com>
[rgantois: commit log]
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
.../devicetree/bindings/net/renesas,rzn1-gmac.yaml | 66 ++++++++++++++++++++++
1 file changed, 66 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/renesas,rzn1-gmac.yaml b/Documentation/devicetree/bindings/net/renesas,rzn1-gmac.yaml
new file mode 100644
index 000000000000..d9a8d586e260
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/renesas,rzn1-gmac.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/renesas,rzn1-gmac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas GMAC
+
+maintainers:
+ - Romain Gantois <romain.gantois@bootlin.com>
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a06g032-gmac
+ - renesas,rzn1-gmac
+ required:
+ - compatible
+
+allOf:
+ - $ref: snps,dwmac.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r9a06g032-gmac
+ - const: renesas,rzn1-gmac
+ - const: snps,dwmac
+
+ pcs-handle:
+ description:
+ phandle pointing to a PCS sub-node compatible with
+ renesas,rzn1-miic.yaml#
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r9a06g032-sysctrl.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ ethernet@44000000 {
+ compatible = "renesas,r9a06g032-gmac", "renesas,rzn1-gmac", "snps,dwmac";
+ reg = <0x44000000 0x2000>;
+ interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+ clock-names = "stmmaceth";
+ clocks = <&sysctrl R9A06G032_HCLK_GMAC0>;
+ power-domains = <&sysctrl>;
+ snps,multicast-filter-bins = <256>;
+ snps,perfect-filter-entries = <128>;
+ tx-fifo-depth = <2048>;
+ rx-fifo-depth = <4096>;
+ pcs-handle = <&mii_conv1>;
+ phy-mode = "mii";
+ };
+
+...
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH net-next v2 2/5] net: stmmac: introduce pcs_init/pcs_exit stmmac operations
From: Romain Gantois @ 2024-04-09 9:21 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, Russell King, Clément Léger
Cc: Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-renesas-soc, linux-stm32, linux-arm-kernel,
Russell King (Oracle), Maxime Chevallier, Romain Gantois
In-Reply-To: <20240409-rzn1-gmac1-v2-0-79ca45f2fc79@bootlin.com>
From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
Introduce a mechanism whereby platforms can create their PCS instances
prior to the network device being published to userspace, but after
some of the core stmmac initialisation has been completed. This means
that the data structures that platforms need will be available.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 14 ++++++++++++++
include/linux/stmmac.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index fe3498e86de9..25fa33ae7017 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7208,6 +7208,12 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
if (ret)
return ret;
+ if (priv->plat->pcs_init) {
+ ret = priv->plat->pcs_init(priv, priv->hw);
+ if (ret)
+ return ret;
+ }
+
/* Get the HW capability (new GMAC newer than 3.50a) */
priv->hw_cap_support = stmmac_get_hw_features(priv);
if (priv->hw_cap_support) {
@@ -7290,6 +7296,12 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
return 0;
}
+static void stmmac_hw_exit(struct stmmac_priv *priv)
+{
+ if (priv->plat->pcs_exit)
+ priv->plat->pcs_exit(priv, priv->hw);
+}
+
static void stmmac_napi_add(struct net_device *dev)
{
struct stmmac_priv *priv = netdev_priv(dev);
@@ -7804,6 +7816,7 @@ int stmmac_dvr_probe(struct device *device,
priv->hw->pcs != STMMAC_PCS_RTBI)
stmmac_mdio_unregister(ndev);
error_mdio_register:
+ stmmac_hw_exit(priv);
stmmac_napi_del(ndev);
error_hw_init:
destroy_workqueue(priv->wq);
@@ -7844,6 +7857,7 @@ void stmmac_dvr_remove(struct device *dev)
if (priv->hw->pcs != STMMAC_PCS_TBI &&
priv->hw->pcs != STMMAC_PCS_RTBI)
stmmac_mdio_unregister(ndev);
+ stmmac_hw_exit(priv);
destroy_workqueue(priv->wq);
mutex_destroy(&priv->lock);
bitmap_free(priv->af_xdp_zc_qps);
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index dfa1828cd756..941fde506e51 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -285,6 +285,8 @@ struct plat_stmmacenet_data {
int (*crosststamp)(ktime_t *device, struct system_counterval_t *system,
void *ctx);
void (*dump_debug_regs)(void *priv);
+ int (*pcs_init)(struct stmmac_priv *priv, struct mac_device_info *hw);
+ void (*pcs_exit)(struct stmmac_priv *priv, struct mac_device_info *hw);
void *bsp_priv;
struct clk *stmmac_clk;
struct clk *pclk;
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH net-next v2 4/5] net: stmmac: add support for RZ/N1 GMAC
From: Romain Gantois @ 2024-04-09 9:21 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, Russell King, Clément Léger
Cc: Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-renesas-soc, linux-stm32, linux-arm-kernel, Romain Gantois
In-Reply-To: <20240409-rzn1-gmac1-v2-0-79ca45f2fc79@bootlin.com>
From: Clément Léger <clement.leger@bootlin.com>
Add support for the Renesas RZ/N1 GMAC. This support can make use of a
custom RZ/N1 PCS which is fetched by parsing the pcs-handle device tree
property.
Signed-off-by: "Clément Léger" <clement.leger@bootlin.com>
Co-developed-by: Romain Gantois <romain.gantois@bootlin.com>
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
MAINTAINERS | 6 ++
drivers/net/ethernet/stmicro/stmmac/Kconfig | 12 ++++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-rzn1.c | 88 ++++++++++++++++++++++++
4 files changed, 107 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4745ea94d463..40bd3eb355fd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18848,6 +18848,12 @@ F: include/dt-bindings/net/pcs-rzn1-miic.h
F: include/linux/pcs-rzn1-miic.h
F: net/dsa/tag_rzn1_a5psw.c
+RENESAS RZ/N1 DWMAC GLUE LAYER
+M: Romain Gantois <romain.gantois@bootlin.com>
+S: Maintained
+F: Documentation/devicetree/bindings/net/renesas,rzn1-gmac.yaml
+F: drivers/net/ethernet/stmicro/stmmac/dwmac-rzn1.c
+
RENESAS RZ/N1 RTC CONTROLLER DRIVER
M: Miquel Raynal <miquel.raynal@bootlin.com>
L: linux-rtc@vger.kernel.org
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 4ec61f1ee71a..05cc07b8f48c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -142,6 +142,18 @@ config DWMAC_ROCKCHIP
This selects the Rockchip RK3288 SoC glue layer support for
the stmmac device driver.
+config DWMAC_RZN1
+ tristate "Renesas RZ/N1 dwmac support"
+ default ARCH_RZN1
+ depends on OF && (ARCH_RZN1 || COMPILE_TEST)
+ select PCS_RZN1_MIIC
+ help
+ Support for Ethernet controller on Renesas RZ/N1 SoC family.
+
+ This selects the Renesas RZ/N1 SoC glue layer support for
+ the stmmac device driver. This support can make use of a custom MII
+ converter PCS device.
+
config DWMAC_SOCFPGA
tristate "SOCFPGA dwmac support"
default ARCH_INTEL_SOCFPGA
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 26cad4344701..c2f0e91f6bf8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_DWMAC_MEDIATEK) += dwmac-mediatek.o
obj-$(CONFIG_DWMAC_MESON) += dwmac-meson.o dwmac-meson8b.o
obj-$(CONFIG_DWMAC_QCOM_ETHQOS) += dwmac-qcom-ethqos.o
obj-$(CONFIG_DWMAC_ROCKCHIP) += dwmac-rk.o
+obj-$(CONFIG_DWMAC_RZN1) += dwmac-rzn1.o
obj-$(CONFIG_DWMAC_SOCFPGA) += dwmac-altr-socfpga.o
obj-$(CONFIG_DWMAC_STARFIVE) += dwmac-starfive.o
obj-$(CONFIG_DWMAC_STI) += dwmac-sti.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rzn1.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rzn1.c
new file mode 100644
index 000000000000..e85524c2017c
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rzn1.c
@@ -0,0 +1,88 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2024 Schneider-Electric
+ *
+ * Clément Léger <clement.leger@bootlin.com>
+ */
+
+#include <linux/of.h>
+#include <linux/pcs-rzn1-miic.h>
+#include <linux/phylink.h>
+#include <linux/platform_device.h>
+
+#include "stmmac_platform.h"
+#include "stmmac.h"
+
+static int rzn1_dwmac_pcs_init(struct stmmac_priv *priv,
+ struct mac_device_info *hw)
+{
+ struct device_node *np = priv->device->of_node;
+ struct device_node *pcs_node;
+ struct phylink_pcs *pcs;
+
+ pcs_node = of_parse_phandle(np, "pcs-handle", 0);
+
+ if (pcs_node) {
+ pcs = miic_create(priv->device, pcs_node);
+ of_node_put(pcs_node);
+ if (IS_ERR(pcs))
+ return PTR_ERR(pcs);
+
+ priv->hw->phylink_pcs = pcs;
+ }
+
+ return 0;
+}
+
+static void rzn1_dwmac_pcs_exit(struct stmmac_priv *priv,
+ struct mac_device_info *hw)
+{
+ if (priv->hw->phylink_pcs)
+ miic_destroy(priv->hw->phylink_pcs);
+}
+
+static int rzn1_dwmac_probe(struct platform_device *pdev)
+{
+ struct plat_stmmacenet_data *plat_dat;
+ struct stmmac_resources stmmac_res;
+ struct device *dev = &pdev->dev;
+ int ret;
+
+ ret = stmmac_get_platform_resources(pdev, &stmmac_res);
+ if (ret)
+ return ret;
+
+ plat_dat = devm_stmmac_probe_config_dt(pdev, stmmac_res.mac);
+ if (IS_ERR(plat_dat))
+ return PTR_ERR(plat_dat);
+
+ plat_dat->bsp_priv = plat_dat;
+ plat_dat->pcs_init = rzn1_dwmac_pcs_init;
+ plat_dat->pcs_exit = rzn1_dwmac_pcs_exit;
+
+ ret = stmmac_dvr_probe(dev, plat_dat, &stmmac_res);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static const struct of_device_id rzn1_dwmac_match[] = {
+ { .compatible = "renesas,rzn1-gmac" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, rzn1_dwmac_match);
+
+static struct platform_driver rzn1_dwmac_driver = {
+ .probe = rzn1_dwmac_probe,
+ .remove_new = stmmac_pltfr_remove,
+ .driver = {
+ .name = "rzn1-dwmac",
+ .of_match_table = rzn1_dwmac_match,
+ },
+};
+module_platform_driver(rzn1_dwmac_driver);
+
+MODULE_AUTHOR("Clément Léger <clement.leger@bootlin.com>");
+MODULE_DESCRIPTION("Renesas RZN1 DWMAC specific glue layer");
+MODULE_LICENSE("GPL");
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH net-next v2 3/5] net: stmmac: dwmac-socfpga: use pcs_init/pcs_exit
From: Romain Gantois @ 2024-04-09 9:21 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, Russell King, Clément Léger
Cc: Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-renesas-soc, linux-stm32, linux-arm-kernel,
Russell King (Oracle), Maxime Chevallier, Romain Gantois
In-Reply-To: <20240409-rzn1-gmac1-v2-0-79ca45f2fc79@bootlin.com>
From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
Use the newly introduced pcs_init() and pcs_exit() operations to
create and destroy the PCS instance at a more appropriate moment during
the driver lifecycle, thereby avoiding publishing a network device to
userspace that has not yet finished its PCS initialisation.
There are other similar issues with this driver which remain
unaddressed, but these are out of scope for this patch.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 109 +++++++++++----------
1 file changed, 55 insertions(+), 54 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index 12b4a80ea3aa..67ca163936c8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -379,6 +379,58 @@ static int socfpga_gen10_set_phy_mode(struct socfpga_dwmac *dwmac)
return 0;
}
+static int socfpga_dwmac_pcs_init(struct stmmac_priv *priv,
+ struct mac_device_info *hw)
+{
+ struct socfpga_dwmac *dwmac = priv->plat->bsp_priv;
+ struct regmap_config pcs_regmap_cfg = {
+ .reg_bits = 16,
+ .val_bits = 16,
+ .reg_shift = regmap_upshift(1),
+ };
+ struct mdio_regmap_config mrc;
+ struct regmap *pcs_regmap;
+ struct phylink_pcs *pcs;
+ struct mii_bus *pcs_bus;
+
+ if (!dwmac->tse_pcs_base)
+ return 0;
+
+ pcs_regmap = devm_regmap_init_mmio(priv->device, dwmac->tse_pcs_base,
+ &pcs_regmap_cfg);
+ if (IS_ERR(pcs_regmap))
+ return PTR_ERR(pcs_regmap);
+
+ memset(&mrc, 0, sizeof(mrc));
+ mrc.regmap = pcs_regmap;
+ mrc.parent = priv->device;
+ mrc.valid_addr = 0x0;
+ mrc.autoscan = false;
+
+ /* Can't use ndev->name here because it will not have been initialised,
+ * and in any case, the user can rename network interfaces at runtime.
+ */
+ snprintf(mrc.name, MII_BUS_ID_SIZE, "%s-pcs-mii",
+ dev_name(priv->device));
+ pcs_bus = devm_mdio_regmap_register(priv->device, &mrc);
+ if (IS_ERR(pcs_bus))
+ return PTR_ERR(pcs_bus);
+
+ pcs = lynx_pcs_create_mdiodev(pcs_bus, 0);
+ if (IS_ERR(pcs))
+ return PTR_ERR(pcs);
+
+ hw->phylink_pcs = pcs;
+ return 0;
+}
+
+static void socfpga_dwmac_pcs_exit(struct stmmac_priv *priv,
+ struct mac_device_info *hw)
+{
+ if (hw->phylink_pcs)
+ lynx_pcs_destroy(hw->phylink_pcs);
+}
+
static int socfpga_dwmac_probe(struct platform_device *pdev)
{
struct plat_stmmacenet_data *plat_dat;
@@ -426,6 +478,8 @@ static int socfpga_dwmac_probe(struct platform_device *pdev)
dwmac->ops = ops;
plat_dat->bsp_priv = dwmac;
plat_dat->fix_mac_speed = socfpga_dwmac_fix_mac_speed;
+ plat_dat->pcs_init = socfpga_dwmac_pcs_init;
+ plat_dat->pcs_exit = socfpga_dwmac_pcs_exit;
ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
if (ret)
@@ -444,48 +498,6 @@ static int socfpga_dwmac_probe(struct platform_device *pdev)
if (ret)
goto err_dvr_remove;
- /* Create a regmap for the PCS so that it can be used by the PCS driver,
- * if we have such a PCS
- */
- if (dwmac->tse_pcs_base) {
- struct regmap_config pcs_regmap_cfg;
- struct mdio_regmap_config mrc;
- struct regmap *pcs_regmap;
- struct mii_bus *pcs_bus;
-
- memset(&pcs_regmap_cfg, 0, sizeof(pcs_regmap_cfg));
- memset(&mrc, 0, sizeof(mrc));
-
- pcs_regmap_cfg.reg_bits = 16;
- pcs_regmap_cfg.val_bits = 16;
- pcs_regmap_cfg.reg_shift = REGMAP_UPSHIFT(1);
-
- pcs_regmap = devm_regmap_init_mmio(&pdev->dev, dwmac->tse_pcs_base,
- &pcs_regmap_cfg);
- if (IS_ERR(pcs_regmap)) {
- ret = PTR_ERR(pcs_regmap);
- goto err_dvr_remove;
- }
-
- mrc.regmap = pcs_regmap;
- mrc.parent = &pdev->dev;
- mrc.valid_addr = 0x0;
- mrc.autoscan = false;
-
- snprintf(mrc.name, MII_BUS_ID_SIZE, "%s-pcs-mii", ndev->name);
- pcs_bus = devm_mdio_regmap_register(&pdev->dev, &mrc);
- if (IS_ERR(pcs_bus)) {
- ret = PTR_ERR(pcs_bus);
- goto err_dvr_remove;
- }
-
- stpriv->hw->phylink_pcs = lynx_pcs_create_mdiodev(pcs_bus, 0);
- if (IS_ERR(stpriv->hw->phylink_pcs)) {
- ret = PTR_ERR(stpriv->hw->phylink_pcs);
- goto err_dvr_remove;
- }
- }
-
return 0;
err_dvr_remove:
@@ -494,17 +506,6 @@ static int socfpga_dwmac_probe(struct platform_device *pdev)
return ret;
}
-static void socfpga_dwmac_remove(struct platform_device *pdev)
-{
- struct net_device *ndev = platform_get_drvdata(pdev);
- struct stmmac_priv *priv = netdev_priv(ndev);
- struct phylink_pcs *pcs = priv->hw->phylink_pcs;
-
- stmmac_pltfr_remove(pdev);
-
- lynx_pcs_destroy(pcs);
-}
-
#ifdef CONFIG_PM_SLEEP
static int socfpga_dwmac_resume(struct device *dev)
{
@@ -576,7 +577,7 @@ MODULE_DEVICE_TABLE(of, socfpga_dwmac_match);
static struct platform_driver socfpga_dwmac_driver = {
.probe = socfpga_dwmac_probe,
- .remove_new = socfpga_dwmac_remove,
+ .remove_new = stmmac_pltfr_remove,
.driver = {
.name = "socfpga-dwmac",
.pm = &socfpga_dwmac_pm_ops,
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH net-next v2 0/5] net: stmmac: Add support for RZN1 GMAC devices
From: Romain Gantois @ 2024-04-09 9:21 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, Russell King, Clément Léger
Cc: Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-renesas-soc, linux-stm32, linux-arm-kernel, Romain Gantois,
Russell King (Oracle), Maxime Chevallier
Hello everyone,
This is version two of my series that adds support for a Gigabit Ethernet
controller featured in the Renesas r9a06g032 SoC, of the RZ/N1 family. This
GMAC device is based on a Synopsys IP and is compatible with the stmmac driver.
My former colleague Clément Léger originally sent a series for this driver,
but an issue in bringing up the PCS clock had blocked the upstreaming
process. This issue has since been resolved by the following series:
https://lore.kernel.org/all/20240326-rxc_bugfix-v6-0-24a74e5c761f@bootlin.com/
This series consists of a devicetree binding describing the RZN1 GMAC
controller IP, a node for the GMAC1 device in the r9a06g032 SoC device
tree, and the GMAC driver itself which is a glue layer in stmmac.
There are also two patches by Russell that improve pcs initialization handling
in stmmac.
Best Regards,
Romain Gantois
---
Changes in v2:
- Add pcs_init/exit callbacks in stmmac to solve race condition
- Use pcs_init/exit callbacks in dwmac_socfpga glue layer
- Miscellaneous device tree binding corrections
- Link to v1: https://lore.kernel.org/r/20240402-rzn1-gmac1-v1-0-5be2b2894d8c@bootlin.com
---
Clément Léger (3):
dt-bindings: net: renesas,rzn1-gmac: Document RZ/N1 GMAC support
net: stmmac: add support for RZ/N1 GMAC
ARM: dts: r9a06g032: describe GMAC1
Russell King (Oracle) (2):
net: stmmac: introduce pcs_init/pcs_exit stmmac operations
net: stmmac: dwmac-socfpga: use pcs_init/pcs_exit
.../devicetree/bindings/net/renesas,rzn1-gmac.yaml | 66 +++++++++++++
MAINTAINERS | 6 ++
arch/arm/boot/dts/renesas/r9a06g032.dtsi | 19 ++++
drivers/net/ethernet/stmicro/stmmac/Kconfig | 12 +++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-rzn1.c | 88 +++++++++++++++++
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 109 +++++++++++----------
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 14 +++
include/linux/stmmac.h | 2 +
9 files changed, 263 insertions(+), 54 deletions(-)
---
base-commit: 87c33315af380ca12a2e59ac94edad4fe0481b4c
change-id: 20240402-rzn1-gmac1-685cf8793d0e
Best regards,
--
Romain Gantois <romain.gantois@bootlin.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX BBM protocol
From: Peng Fan @ 2024-04-09 9:13 UTC (permalink / raw)
To: Sudeep Holla, Peng Fan (OSS)
Cc: Cristian Marussi, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <ZhUDZGJilhczKlDD@bogus>
Hi Sudeep,
> Subject: Re: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX
> BBM protocol
>
> On Mon, Apr 08, 2024 at 07:04:43PM +0100, Cristian Marussi wrote:
> > On Fri, Apr 05, 2024 at 08:39:25PM +0800, Peng Fan (OSS) wrote:
> > > From: Peng Fan <peng.fan@nxp.com>
> > >
> > > The i.MX BBM protocol is for managing i.MX BBM module which provides
> > > RTC and BUTTON feature.
> > >
> >
> > I appreciate that you added versioning but I think a bit of
> > documentation about what the protocol and its comamnds purpose is
> > still lacking, as asked by Sudeep previously
> >
> >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Flinux-arm-
> kernel%2FZeGtoJ7ztSe8Kg8R%40bogus%2F%23t&data=
> >
> 05%7C02%7Cpeng.fan%40nxp.com%7Ce92ff78b9126447afe9708dc587358d
> 4%7C686e
> >
> a1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638482499632395762%7C
> Unknown%7C
> >
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVC
> >
> I6Mn0%3D%7C0%7C%7C%7C&sdata=7QP%2BkkjHA3Sa0CdcbbObGG4kgYYK
> XAGA2r%2F%2F
> > x0MogqU%3D&reserved=0
> >
>
> I have decided to ignore all these vendor protocol patches until they have
> some documentation to understand what these protocol are for, what are the
> commands, their input/output parameter details, any conditions are the
> caller and callee,..etc very similar to SCMI spec.
Where do you expect the documentation to be put?
similar as scmi_protocol.h, put in scmi_imx_protcol.h?
>
> To start with can you please expand what is BBM or MISC protocol is ?
ok. Sorry for missing your previous comment in v1. Let me write here briefly
first.
The Battery Backup (BB) Domain contains the Battery Backed Security
Module (BBSM) and the Battery Backed Non-Secure Module (BBNSM).
BBM protocol is to manage i.MX BBSM and BBNSM. This protocol supports
#define COMMAND_PROTOCOL_VERSION 0x0U
#define COMMAND_PROTOCOL_ATTRIBUTES 0x1U
#define COMMAND_PROTOCOL_MESSAGE_ATTRIBUTES 0x2U
#define COMMAND_BBM_GPR_SET 0x3U
#define COMMAND_BBM_GPR_GET 0x4U
#define COMMAND_BBM_RTC_ATTRIBUTES 0x5U
#define COMMAND_BBM_RTC_TIME_SET 0x6U
#define COMMAND_BBM_RTC_TIME_GET 0x7U
#define COMMAND_BBM_RTC_ALARM_SET 0x8U
#define COMMAND_BBM_BUTTON_GET 0x9U
#define COMMAND_BBM_RTC_NOTIFY 0xAU
#define COMMAND_BBM_BUTTON_NOTIFY 0xBU
#define COMMAND_NEGOTIATE_PROTOCOL_VERSION 0x10U
For now in this patchset for linux, we only use RTC, and BUTTON
for system wakeup
For MISC protocol, it is for various misc things, such as discover
build info, get rom passed data, get reset reason, get i.mx
cfg name, control set(for gpio expander under m33 control and
etc). The command as below:
51 #define COMMAND_PROTOCOL_VERSION 0x0U
52 #define COMMAND_PROTOCOL_ATTRIBUTES 0x1U
53 #define COMMAND_PROTOCOL_MESSAGE_ATTRIBUTES 0x2U
54 #define COMMAND_MISC_CONTROL_SET 0x3U
55 #define COMMAND_MISC_CONTROL_GET 0x4U
56 #define COMMAND_MISC_CONTROL_ACTION 0x5U
57 #define COMMAND_MISC_DISCOVER_BUILD_INFO 0x6U
58 #define COMMAND_MISC_ROM_PASSOVER_GET 0x7U
59 #define COMMAND_MISC_CONTROL_NOTIFY 0x8U
60 #define COMMAND_MISC_REASON_ATTRIBUTES 0x9U
61 #define COMMAND_MISC_RESET_REASON 0xAU
62 #define COMMAND_MISC_SI_INFO 0xBU
63 #define COMMAND_MISC_CFG_INFO 0xCU
64 #define COMMAND_MISC_SYSLOG 0xDU
65 #define COMMAND_NEGOTIATE_PROTOCOL_VERSION 0x10U
I will add the information in v3.
But as of now I am not sure
how to proceed with dt-binding, add in vendor stuff
in arm,scmi.yaml or add imx,scmi.yaml
Thanks,
Peng.
> Don't expect me to respond if the requested details are still missing in the
> future versions, I am going to ignore it silently.
>
> I have asked for these in atleast 2 different threads may be not just NXP
> patches but in one instance Qcom patches, but they apply equally here.
>
> --
> Regards,
> Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: imx8mm: fix missing pgc_vpu_* power domain parent
From: Lucas Stach @ 2024-04-09 9:13 UTC (permalink / raw)
To: Vitor Soares, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Vitor Soares, devicetree, imx, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <20240409085802.290439-1-ivitro@gmail.com>
Hi Vitor,
Am Dienstag, dem 09.04.2024 um 09:58 +0100 schrieb Vitor Soares:
> From: Vitor Soares <vitor.soares@toradex.com>
>
> The pgc_vpu_* nodes miss the reference to the power domain parent,
> leading the system to hang during the resume.
>
This change is not correct. The vpumix domain is controlled through the
imx8mm-vpu-blk-ctrl and must not be directly triggered by the child
domains in order to guarantee proper power sequencing.
If the sequencing is incorrect for resume, it needs to be fixed in the
blk-ctrl driver. I'll happily assist if you have any questions about
this intricate mix between GPC and blk-ctrl hardware/drivers.
Regards,
Lucas
> As these PU domains are nested inside the vpumix domain, let's reference
> it accordingly. After this change, the suspend/resume is working.
>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: <stable@vger.kernel.org>
> Closes: https://lore.kernel.org/all/fccbb040330a706a4f7b34875db1d896a0bf81c8.camel@gmail.com/
> Fixes: d39d4bb15310 ("arm64: dts: imx8mm: add GPC node")
> Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
> ---
> arch/arm64/boot/dts/freescale/imx8mm.dtsi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> index 8a1b42b94dce..97d0c6d23ad8 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> @@ -739,16 +739,19 @@ pgc_vpumix: power-domain@6 {
> pgc_vpu_g1: power-domain@7 {
> #power-domain-cells = <0>;
> reg = <IMX8MM_POWER_DOMAIN_VPUG1>;
> + power-domains = <&pgc_vpumix>;
> };
>
> pgc_vpu_g2: power-domain@8 {
> #power-domain-cells = <0>;
> reg = <IMX8MM_POWER_DOMAIN_VPUG2>;
> + power-domains = <&pgc_vpumix>;
> };
>
> pgc_vpu_h1: power-domain@9 {
> #power-domain-cells = <0>;
> reg = <IMX8MM_POWER_DOMAIN_VPUH1>;
> + power-domains = <&pgc_vpumix>;
> };
>
> pgc_dispmix: power-domain@10 {
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 2/2] ARM: dts: imx6: exchange fallback and specific compatible string
From: Shengjiu Wang @ 2024-04-09 8:50 UTC (permalink / raw)
To: lgirdwood, broonie, robh+dt, krzysztof.kozlowski+dt, conor+dt,
shengjiu.wang, linux-sound, devicetree, linux-kernel, shawnguo,
s.hauer, kernel, festevam, imx, linux-arm-kernel
In-Reply-To: <1712652644-28887-1-git-send-email-shengjiu.wang@nxp.com>
exchange fallback and specific compatible string for spdif sound card.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi | 4 ++--
arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi
index 68e97180d33e..51517e27418c 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi
@@ -144,8 +144,8 @@ sound-cs42888 {
};
sound-spdif {
- compatible = "fsl,imx-audio-spdif",
- "fsl,imx-sabreauto-spdif";
+ compatible = "fsl,imx-sabreauto-spdif",
+ "fsl,imx-audio-spdif";
model = "imx-spdif";
spdif-controller = <&spdif>;
spdif-in;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi b/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi
index c6e85e4a0883..67872c16372a 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi
@@ -184,8 +184,8 @@ panel_in: endpoint {
};
sound-spdif {
- compatible = "fsl,imx-audio-spdif",
- "fsl,imx6sx-sdb-spdif";
+ compatible = "fsl,imx6sx-sdb-spdif",
+ "fsl,imx-audio-spdif";
model = "imx-spdif";
spdif-controller = <&spdif>;
spdif-out;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 1/2] ASoC: dt-bindings: imx-audio-spdif: convert to YAML
From: Shengjiu Wang @ 2024-04-09 8:50 UTC (permalink / raw)
To: lgirdwood, broonie, robh+dt, krzysztof.kozlowski+dt, conor+dt,
shengjiu.wang, linux-sound, devicetree, linux-kernel, shawnguo,
s.hauer, kernel, festevam, imx, linux-arm-kernel
In-Reply-To: <1712652644-28887-1-git-send-email-shengjiu.wang@nxp.com>
Convert the imx-audio-spdif binding to YAML.
When testing dtbs_check, found below compatible strings
are not listed in document:
fsl,imx-sabreauto-spdif
fsl,imx6sx-sdb-spdif
So add them in yaml file to pass the test.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
.../bindings/sound/fsl,imx-audio-spdif.yaml | 67 +++++++++++++++++++
.../bindings/sound/imx-audio-spdif.txt | 36 ----------
2 files changed, 67 insertions(+), 36 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,imx-audio-spdif.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
diff --git a/Documentation/devicetree/bindings/sound/fsl,imx-audio-spdif.yaml b/Documentation/devicetree/bindings/sound/fsl,imx-audio-spdif.yaml
new file mode 100644
index 000000000000..fec008ffae43
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,imx-audio-spdif.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,imx-audio-spdif.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX audio complex with S/PDIF transceiver
+
+maintainers:
+ - Shengjiu Wang <shengjiu.wang@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx-sabreauto-spdif
+ - fsl,imx6sx-sdb-spdif
+ - enum:
+ - fsl,imx-audio-spdif
+ - enum:
+ - fsl,imx-audio-spdif
+
+ model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: User specified audio sound card name
+
+ spdif-controller:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the i.MX S/PDIF controller
+
+ spdif-out:
+ type: boolean
+ description:
+ If present, the transmitting function of S/PDIF will be enabled,
+ indicating there's a physical S/PDIF out connector or jack on the
+ board or it's connecting to some other IP block, such as an HDMI
+ encoder or display-controller.
+
+ spdif-in:
+ type: boolean
+ description:
+ If present, the receiving function of S/PDIF will be enabled,
+ indicating there is a physical S/PDIF in connector/jack on the board.
+
+required:
+ - compatible
+ - model
+ - spdif-controller
+
+anyOf:
+ - required:
+ - spdif-in
+ - required:
+ - spdif-out
+
+additionalProperties: false
+
+examples:
+ - |
+ sound-spdif {
+ compatible = "fsl,imx-audio-spdif";
+ model = "imx-spdif";
+ spdif-controller = <&spdif>;
+ spdif-out;
+ spdif-in;
+ };
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
deleted file mode 100644
index da84a442ccea..000000000000
--- a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Freescale i.MX audio complex with S/PDIF transceiver
-
-Required properties:
-
- - compatible : "fsl,imx-audio-spdif"
-
- - model : The user-visible name of this sound complex
-
- - spdif-controller : The phandle of the i.MX S/PDIF controller
-
-
-Optional properties:
-
- - spdif-out : This is a boolean property. If present, the
- transmitting function of S/PDIF will be enabled,
- indicating there's a physical S/PDIF out connector
- or jack on the board or it's connecting to some
- other IP block, such as an HDMI encoder or
- display-controller.
-
- - spdif-in : This is a boolean property. If present, the receiving
- function of S/PDIF will be enabled, indicating there
- is a physical S/PDIF in connector/jack on the board.
-
-* Note: At least one of these two properties should be set in the DT binding.
-
-
-Example:
-
-sound-spdif {
- compatible = "fsl,imx-audio-spdif";
- model = "imx-spdif";
- spdif-controller = <&spdif>;
- spdif-out;
- spdif-in;
-};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 0/2] convert imx-audio-spdif.txt to YAML
From: Shengjiu Wang @ 2024-04-09 8:50 UTC (permalink / raw)
To: lgirdwood, broonie, robh+dt, krzysztof.kozlowski+dt, conor+dt,
shengjiu.wang, linux-sound, devicetree, linux-kernel, shawnguo,
s.hauer, kernel, festevam, imx, linux-arm-kernel
convert imx-audio-spdif.txt to YAML
changes in v3:
- change file name to fsl,imx-audio-spdif.yaml
- change example name back to sound-spdif
- exchange the fallback and specific compatible string
- update anyOf content
changes in v2:
- change file name to imx-spdif.yaml
- remove |
- add anyof for spdif-in and spdif-out requirement
- change example name to sound
Shengjiu Wang (2):
ASoC: dt-bindings: imx-audio-spdif: convert to YAML
ARM: dts: imx6: exchange fallback and specific compatible string
.../bindings/sound/fsl,imx-audio-spdif.yaml | 67 +++++++++++++++++++
.../bindings/sound/imx-audio-spdif.txt | 36 ----------
.../boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi | 4 +-
arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi | 4 +-
4 files changed, 71 insertions(+), 40 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,imx-audio-spdif.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX BBM protocol
From: Sudeep Holla @ 2024-04-09 8:59 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Cristian Marussi, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Peng Fan, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <ZhQxu8LVNKf5QDLm@pluto>
On Mon, Apr 08, 2024 at 07:04:43PM +0100, Cristian Marussi wrote:
> On Fri, Apr 05, 2024 at 08:39:25PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > The i.MX BBM protocol is for managing i.MX BBM module which provides
> > RTC and BUTTON feature.
> >
>
> I appreciate that you added versioning but I think a bit of documentation
> about what the protocol and its comamnds purpose is still lacking, as asked
> by Sudeep previously
>
> https://lore.kernel.org/linux-arm-kernel/ZeGtoJ7ztSe8Kg8R@bogus/#t
>
I have decided to ignore all these vendor protocol patches until they have
some documentation to understand what these protocol are for, what are
the commands, their input/output parameter details, any conditions are the
caller and callee,..etc very similar to SCMI spec.
To start with can you please expand what is BBM or MISC protocol is ?
Don't expect me to respond if the requested details are still missing in
the future versions, I am going to ignore it silently.
I have asked for these in atleast 2 different threads may be not just NXP
patches but in one instance Qcom patches, but they apply equally here.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1] arm64: dts: imx8mm: fix missing pgc_vpu_* power domain parent
From: Vitor Soares @ 2024-04-09 8:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Vitor Soares, devicetree, imx, linux-arm-kernel, linux-kernel,
Lucas Stach, stable
From: Vitor Soares <vitor.soares@toradex.com>
The pgc_vpu_* nodes miss the reference to the power domain parent,
leading the system to hang during the resume.
As these PU domains are nested inside the vpumix domain, let's reference
it accordingly. After this change, the suspend/resume is working.
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: <stable@vger.kernel.org>
Closes: https://lore.kernel.org/all/fccbb040330a706a4f7b34875db1d896a0bf81c8.camel@gmail.com/
Fixes: d39d4bb15310 ("arm64: dts: imx8mm: add GPC node")
Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 8a1b42b94dce..97d0c6d23ad8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -739,16 +739,19 @@ pgc_vpumix: power-domain@6 {
pgc_vpu_g1: power-domain@7 {
#power-domain-cells = <0>;
reg = <IMX8MM_POWER_DOMAIN_VPUG1>;
+ power-domains = <&pgc_vpumix>;
};
pgc_vpu_g2: power-domain@8 {
#power-domain-cells = <0>;
reg = <IMX8MM_POWER_DOMAIN_VPUG2>;
+ power-domains = <&pgc_vpumix>;
};
pgc_vpu_h1: power-domain@9 {
#power-domain-cells = <0>;
reg = <IMX8MM_POWER_DOMAIN_VPUH1>;
+ power-domains = <&pgc_vpumix>;
};
pgc_dispmix: power-domain@10 {
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 4/7] powerpc: mm: accelerate pagefault when badaccess
From: Michael Ellerman @ 2024-04-09 8:56 UTC (permalink / raw)
To: Kefeng Wang, akpm
Cc: Russell King, Catalin Marinas, Will Deacon, Nicholas Piggin,
Christophe Leroy, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexander Gordeev, Gerald Schaefer, Dave Hansen, Andy Lutomirski,
Peter Zijlstra, x86, linux-arm-kernel, linuxppc-dev, linux-riscv,
linux-s390, surenb, linux-mm, Kefeng Wang
In-Reply-To: <20240403083805.1818160-5-wangkefeng.wang@huawei.com>
Kefeng Wang <wangkefeng.wang@huawei.com> writes:
> The access_[pkey]_error() of vma already checked under per-VMA lock, if
> it is a bad access, directly handle error, no need to retry with mmap_lock
> again. In order to release the correct lock, pass the mm_struct into
> bad_access_pkey()/bad_access(), if mm is NULL, release vma lock, or
> release mmap_lock. Since the page faut is handled under per-VMA lock,
> count it as a vma lock event with VMA_LOCK_SUCCESS.
>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
> arch/powerpc/mm/fault.c | 33 ++++++++++++++++++++-------------
> 1 file changed, 20 insertions(+), 13 deletions(-)
I thought there might be a nicer way to do this, plumbing the mm and vma
down through all those levels is a bit of a pain (vma->vm_mm exists
after all).
But I couldn't come up with anything obviously better, without doing
lots of refactoring first, which would be a pain to integrate into this
series.
So anyway, if the series goes ahead:
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
cheers
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index 53335ae21a40..215690452495 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -71,23 +71,26 @@ static noinline int bad_area_nosemaphore(struct pt_regs *regs, unsigned long add
> return __bad_area_nosemaphore(regs, address, SEGV_MAPERR);
> }
>
> -static int __bad_area(struct pt_regs *regs, unsigned long address, int si_code)
> +static int __bad_area(struct pt_regs *regs, unsigned long address, int si_code,
> + struct mm_struct *mm, struct vm_area_struct *vma)
> {
> - struct mm_struct *mm = current->mm;
>
> /*
> * Something tried to access memory that isn't in our memory map..
> * Fix it, but check if it's kernel or user first..
> */
> - mmap_read_unlock(mm);
> + if (mm)
> + mmap_read_unlock(mm);
> + else
> + vma_end_read(vma);
>
> return __bad_area_nosemaphore(regs, address, si_code);
> }
>
> static noinline int bad_access_pkey(struct pt_regs *regs, unsigned long address,
> + struct mm_struct *mm,
> struct vm_area_struct *vma)
> {
> - struct mm_struct *mm = current->mm;
> int pkey;
>
> /*
> @@ -109,7 +112,10 @@ static noinline int bad_access_pkey(struct pt_regs *regs, unsigned long address,
> */
> pkey = vma_pkey(vma);
>
> - mmap_read_unlock(mm);
> + if (mm)
> + mmap_read_unlock(mm);
> + else
> + vma_end_read(vma);
>
> /*
> * If we are in kernel mode, bail out with a SEGV, this will
> @@ -124,9 +130,10 @@ static noinline int bad_access_pkey(struct pt_regs *regs, unsigned long address,
> return 0;
> }
>
> -static noinline int bad_access(struct pt_regs *regs, unsigned long address)
> +static noinline int bad_access(struct pt_regs *regs, unsigned long address,
> + struct mm_struct *mm, struct vm_area_struct *vma)
> {
> - return __bad_area(regs, address, SEGV_ACCERR);
> + return __bad_area(regs, address, SEGV_ACCERR, mm, vma);
> }
>
> static int do_sigbus(struct pt_regs *regs, unsigned long address,
> @@ -479,13 +486,13 @@ static int ___do_page_fault(struct pt_regs *regs, unsigned long address,
>
> if (unlikely(access_pkey_error(is_write, is_exec,
> (error_code & DSISR_KEYFAULT), vma))) {
> - vma_end_read(vma);
> - goto lock_mmap;
> + count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
> + return bad_access_pkey(regs, address, NULL, vma);
> }
>
> if (unlikely(access_error(is_write, is_exec, vma))) {
> - vma_end_read(vma);
> - goto lock_mmap;
> + count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
> + return bad_access(regs, address, NULL, vma);
> }
>
> fault = handle_mm_fault(vma, address, flags | FAULT_FLAG_VMA_LOCK, regs);
> @@ -521,10 +528,10 @@ static int ___do_page_fault(struct pt_regs *regs, unsigned long address,
>
> if (unlikely(access_pkey_error(is_write, is_exec,
> (error_code & DSISR_KEYFAULT), vma)))
> - return bad_access_pkey(regs, address, vma);
> + return bad_access_pkey(regs, address, mm, vma);
>
> if (unlikely(access_error(is_write, is_exec, vma)))
> - return bad_access(regs, address);
> + return bad_access(regs, address, mm, vma);
>
> /*
> * If for any reason at all we couldn't handle the fault,
> --
> 2.27.0
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox