* [PATCH v3 15/15] powerpc: Add support for suppressing warning backtraces
From: Guenter Roeck @ 2024-04-03 13:19 UTC (permalink / raw)
To: linux-kselftest
Cc: David Airlie, Arnd Bergmann, Maíra Canal, Dan Carpenter,
Kees Cook, Daniel Diaz, David Gow, 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, Guenter Roeck,
Linux Kernel Functional Testing, Michael Ellerman
In-Reply-To: <20240403131936.787234-1-linux@roeck-us.net>
Add name of functions triggering warning backtraces to the __bug_table
object section to enable support for suppressing WARNING backtraces.
To limit image size impact, the pointer to the function name is only added
to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and
CONFIG_DEBUG_BUGVERBOSE are enabled. Otherwise, the __func__ assembly
parameter is replaced with a (dummy) NULL parameter to avoid an image size
increase due to unused __func__ entries (this is necessary because __func__
is not a define but a virtual variable).
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
v2:
- Rebased to v6.9-rc1
- Added Tested-by:, Acked-by:, and Reviewed-by: tags
- Introduced KUNIT_SUPPRESS_BACKTRACE configuration option
v3:
- Rebased to v6.9-rc2
arch/powerpc/include/asm/bug.h | 37 +++++++++++++++++++++++++---------
1 file changed, 28 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
index 1db485aacbd9..5b06745d20aa 100644
--- a/arch/powerpc/include/asm/bug.h
+++ b/arch/powerpc/include/asm/bug.h
@@ -14,6 +14,9 @@
.section __bug_table,"aw"
5001: .4byte \addr - .
.4byte 5002f - .
+#ifdef CONFIG_KUNIT_SUPPRESS_BACKTRACE
+ .4byte 0
+#endif
.short \line, \flags
.org 5001b+BUG_ENTRY_SIZE
.previous
@@ -32,30 +35,46 @@
#endif /* verbose */
#else /* !__ASSEMBLY__ */
-/* _EMIT_BUG_ENTRY expects args %0,%1,%2,%3 to be FILE, LINE, flags and
- sizeof(struct bug_entry), respectively */
+/* _EMIT_BUG_ENTRY expects args %0,%1,%2,%3,%4 to be FILE, __func__, LINE, flags
+ and sizeof(struct bug_entry), respectively */
#ifdef CONFIG_DEBUG_BUGVERBOSE
+
+#ifdef CONFIG_KUNIT_SUPPRESS_BACKTRACE
+# define HAVE_BUG_FUNCTION
+# define __BUG_FUNC_PTR " .4byte %1 - .\n"
+#else
+# define __BUG_FUNC_PTR
+#endif /* CONFIG_KUNIT_SUPPRESS_BACKTRACE */
+
#define _EMIT_BUG_ENTRY \
".section __bug_table,\"aw\"\n" \
"2: .4byte 1b - .\n" \
" .4byte %0 - .\n" \
- " .short %1, %2\n" \
- ".org 2b+%3\n" \
+ __BUG_FUNC_PTR \
+ " .short %2, %3\n" \
+ ".org 2b+%4\n" \
".previous\n"
#else
#define _EMIT_BUG_ENTRY \
".section __bug_table,\"aw\"\n" \
"2: .4byte 1b - .\n" \
- " .short %2\n" \
- ".org 2b+%3\n" \
+ " .short %3\n" \
+ ".org 2b+%4\n" \
".previous\n"
#endif
+#ifdef HAVE_BUG_FUNCTION
+# define __BUG_FUNC __func__
+#else
+# define __BUG_FUNC NULL
+#endif
+
#define BUG_ENTRY(insn, flags, ...) \
__asm__ __volatile__( \
"1: " insn "\n" \
_EMIT_BUG_ENTRY \
- : : "i" (__FILE__), "i" (__LINE__), \
+ : : "i" (__FILE__), "i" (__BUG_FUNC), \
+ "i" (__LINE__), \
"i" (flags), \
"i" (sizeof(struct bug_entry)), \
##__VA_ARGS__)
@@ -80,7 +99,7 @@
if (x) \
BUG(); \
} else { \
- BUG_ENTRY(PPC_TLNEI " %4, 0", 0, "r" ((__force long)(x))); \
+ BUG_ENTRY(PPC_TLNEI " %5, 0", 0, "r" ((__force long)(x))); \
} \
} while (0)
@@ -90,7 +109,7 @@
if (__ret_warn_on) \
__WARN(); \
} else { \
- BUG_ENTRY(PPC_TLNEI " %4, 0", \
+ BUG_ENTRY(PPC_TLNEI " %5, 0", \
BUGFLAG_WARNING | BUGFLAG_TAINT(TAINT_WARN), \
"r" (__ret_warn_on)); \
} \
--
2.39.2
_______________________________________________
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 14/15] riscv: Add support for suppressing warning backtraces
From: Guenter Roeck @ 2024-04-03 13:19 UTC (permalink / raw)
To: linux-kselftest
Cc: David Airlie, Arnd Bergmann, Maíra Canal, Dan Carpenter,
Kees Cook, Daniel Diaz, David Gow, 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, Guenter Roeck,
Linux Kernel Functional Testing, Paul Walmsley, Palmer Dabbelt,
Albert Ou
In-Reply-To: <20240403131936.787234-1-linux@roeck-us.net>
Add name of functions triggering warning backtraces to the __bug_table
object section to enable support for suppressing WARNING backtraces.
To limit image size impact, the pointer to the function name is only added
to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and
CONFIG_DEBUG_BUGVERBOSE are enabled. Otherwise, the __func__ assembly
parameter is replaced with a (dummy) NULL parameter to avoid an image size
increase due to unused __func__ entries (this is necessary because __func__
is not a define but a virtual variable).
To simplify the implementation, unify the __BUG_ENTRY_ADDR and
__BUG_ENTRY_FILE macros into a single macro named __BUG_REL() which takes
the address, file, or function reference as parameter.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
v2:
- Rebased to v6.9-rc1
- Added Tested-by:, Acked-by:, and Reviewed-by: tags
- Introduced KUNIT_SUPPRESS_BACKTRACE configuration option
v3:
- Rebased to v6.9-rc2
arch/riscv/include/asm/bug.h | 38 ++++++++++++++++++++++++------------
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/arch/riscv/include/asm/bug.h b/arch/riscv/include/asm/bug.h
index 1aaea81fb141..79f360af4ad8 100644
--- a/arch/riscv/include/asm/bug.h
+++ b/arch/riscv/include/asm/bug.h
@@ -30,26 +30,39 @@
typedef u32 bug_insn_t;
#ifdef CONFIG_GENERIC_BUG_RELATIVE_POINTERS
-#define __BUG_ENTRY_ADDR RISCV_INT " 1b - ."
-#define __BUG_ENTRY_FILE RISCV_INT " %0 - ."
+#define __BUG_REL(val) RISCV_INT " " __stringify(val) " - ."
#else
-#define __BUG_ENTRY_ADDR RISCV_PTR " 1b"
-#define __BUG_ENTRY_FILE RISCV_PTR " %0"
+#define __BUG_REL(val) RISCV_PTR " " __stringify(val)
#endif
#ifdef CONFIG_DEBUG_BUGVERBOSE
+
+#ifdef CONFIG_KUNIT_SUPPRESS_BACKTRACE
+# define HAVE_BUG_FUNCTION
+# define __BUG_FUNC_PTR __BUG_REL(%1)
+#else
+# define __BUG_FUNC_PTR
+#endif /* CONFIG_KUNIT_SUPPRESS_BACKTRACE */
+
#define __BUG_ENTRY \
- __BUG_ENTRY_ADDR "\n\t" \
- __BUG_ENTRY_FILE "\n\t" \
- RISCV_SHORT " %1\n\t" \
- RISCV_SHORT " %2"
+ __BUG_REL(1b) "\n\t" \
+ __BUG_REL(%0) "\n\t" \
+ __BUG_FUNC_PTR "\n\t" \
+ RISCV_SHORT " %2\n\t" \
+ RISCV_SHORT " %3"
#else
#define __BUG_ENTRY \
- __BUG_ENTRY_ADDR "\n\t" \
- RISCV_SHORT " %2"
+ __BUG_REL(1b) "\n\t" \
+ RISCV_SHORT " %3"
#endif
#ifdef CONFIG_GENERIC_BUG
+#ifdef HAVE_BUG_FUNCTION
+# define __BUG_FUNC __func__
+#else
+# define __BUG_FUNC NULL
+#endif
+
#define __BUG_FLAGS(flags) \
do { \
__asm__ __volatile__ ( \
@@ -58,10 +71,11 @@ do { \
".pushsection __bug_table,\"aw\"\n\t" \
"2:\n\t" \
__BUG_ENTRY "\n\t" \
- ".org 2b + %3\n\t" \
+ ".org 2b + %4\n\t" \
".popsection" \
: \
- : "i" (__FILE__), "i" (__LINE__), \
+ : "i" (__FILE__), "i" (__BUG_FUNC), \
+ "i" (__LINE__), \
"i" (flags), \
"i" (sizeof(struct bug_entry))); \
} while (0)
--
2.39.2
_______________________________________________
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 07/34] Input: stmpe-ts - mark OF related data as maybe unused
From: Uwe Kleine-König @ 2024-04-03 13:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, Dmitry Torokhov, Maxime Coquelin, Alexandre Torgue,
Krzysztof Kozlowski, Arnd Bergmann, linux-input, linux-stm32,
linux-arm-kernel
In-Reply-To: <gh4slqpbzul67vni6hv2opjuvccokfwqnnroxbpqt5oc3kiz65@nbqaxhwltb3z>
[-- Attachment #1.1: Type: text/plain, Size: 3145 bytes --]
Hello again,
On Wed, Apr 03, 2024 at 03:17:32PM +0200, Uwe Kleine-König wrote:
> On Wed, Apr 03, 2024 at 10:06:25AM +0200, Arnd Bergmann wrote:
> > From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> >
> > When compile tested with W=1 on x86_64 with driver as built-in:
> >
> > stmpe-ts.c:371:34: error: unused variable 'stmpe_ts_ids' [-Werror,-Wunused-const-variable]
> >
> > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > drivers/input/touchscreen/stmpe-ts.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/touchscreen/stmpe-ts.c b/drivers/input/touchscreen/stmpe-ts.c
> > index b204fdb2d22c..022b3e94266d 100644
> > --- a/drivers/input/touchscreen/stmpe-ts.c
> > +++ b/drivers/input/touchscreen/stmpe-ts.c
> > @@ -366,7 +366,7 @@ static struct platform_driver stmpe_ts_driver = {
> > };
> > module_platform_driver(stmpe_ts_driver);
> >
> > -static const struct of_device_id stmpe_ts_ids[] = {
> > +static const struct of_device_id stmpe_ts_ids[] __maybe_unused = {
> > { .compatible = "st,stmpe-ts", },
> > { },
> > };
>
> I'd suggest the following instead:
>
> diff --git a/drivers/input/touchscreen/stmpe-ts.c b/drivers/input/touchscreen/stmpe-ts.c
> index b204fdb2d22c..e1afebc641ec 100644
> --- a/drivers/input/touchscreen/stmpe-ts.c
> +++ b/drivers/input/touchscreen/stmpe-ts.c
> @@ -357,21 +357,22 @@ static void stmpe_ts_remove(struct platform_device *pdev)
> stmpe_disable(ts->stmpe, STMPE_BLOCK_TOUCHSCREEN);
> }
>
> -static struct platform_driver stmpe_ts_driver = {
> - .driver = {
> - .name = STMPE_TS_NAME,
> - },
> - .probe = stmpe_input_probe,
> - .remove_new = stmpe_ts_remove,
> -};
> -module_platform_driver(stmpe_ts_driver);
> -
> static const struct of_device_id stmpe_ts_ids[] = {
> { .compatible = "st,stmpe-ts", },
> { },
> };
> MODULE_DEVICE_TABLE(of, stmpe_ts_ids);
>
> +static struct platform_driver stmpe_ts_driver = {
> + .driver = {
> + .name = STMPE_TS_NAME,
> + .of_match_table = stmpe_ts_ids,
> + },
> + .probe = stmpe_input_probe,
> + .remove_new = stmpe_ts_remove,
> +};
> +module_platform_driver(stmpe_ts_driver);
> +
> MODULE_AUTHOR("Luotao Fu <l.fu@pengutronix.de>");
> MODULE_DESCRIPTION("STMPEXXX touchscreen driver");
> MODULE_LICENSE("GPL");
>
> I wonder if with the status quo binding via dt works at all with
> stmpe_ts_driver.driver.of_match_table unset?!
I missed the discussion between Andy and Krzysztof when I wrote my mail.
I still think this should be considered and if .of_match_table should
stay unassigned (e.g. to allow dropping stmpe_ts_ids in case the driver
is built-in?) I think adding a code comment would be appropriate because
having an of_device_id array but not adding it to the driver is unusuall
and generally a bad template for new drivers.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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: (subset) [PATCH v2 0/9] spi: pxa2xx: Drop linux/spi/pxa2xx_spi.h
From: Mark Brown @ 2024-04-03 13:29 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-spi, linux-kernel, linux-arm-kernel, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, Russell King, Arnd Bergmann
In-Reply-To: <Zg04cWhT_Dl6AUik@smile.fi.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 293 bytes --]
On Wed, Apr 03, 2024 at 02:07:29PM +0300, Andy Shevchenko wrote:
> Do I need to do anything else to get the rest applied?
All the concerns I have with swnodes just being a more complex and less
maintainable way of doing things still stand, I'm not clear that this is
making anything better.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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 v4 05/13] mm/arch: Provide pud_pfn() fallback
From: Jason Gunthorpe @ 2024-04-03 13:33 UTC (permalink / raw)
To: Christophe Leroy
Cc: Peter Xu, Nathan Chancellor, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Yang Shi, Kirill A . Shutemov,
Mike Kravetz, John Hubbard, Michael Ellerman, Andrew Jones,
Muchun Song, linux-riscv@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, Andrew Morton, Christoph Hellwig,
Lorenzo Stoakes, Matthew Wilcox, Rik van Riel,
linux-arm-kernel@lists.infradead.org, Andrea Arcangeli,
David Hildenbrand, Aneesh Kumar K . V, Vlastimil Babka,
James Houghton, Mike Rapoport, Axel Rasmussen, Huacai Chen,
WANG Xuerui, loongarch@lists.linux.dev
In-Reply-To: <4b56356e-ac10-4f40-a4c3-7672d6e4a4e5@csgroup.eu>
On Wed, Apr 03, 2024 at 01:17:06PM +0000, Christophe Leroy wrote:
> > That commit makes it sounds like the arch supports huge PUD's through
> > the hugepte mechanism - it says a LTP test failed so something
> > populated a huge PUD at least??
>
> Not sure, I more see it just like a copy/paste of commit 501b81046701
> ("mips: mm: add p?d_leaf() definitions").
>
> The commit message says that the test failed because pmd_leaf() is
> missing, it says nothing about PUD.
AH fair enough, it is probably a C&P then
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 0/3] ARM: dts: Update devicetree of Asrock X570D4U BMC
From: Renze Nicolai @ 2024-04-03 13:28 UTC (permalink / raw)
To: renze, linux-arm-kernel, devicetree, linux-kernel, linux-aspeed,
arnd, olof, soc, robh+dt, krzysztof.kozlowski+dt, joel, andrew
These patches change the GPIO table, ADC channel configuration and
I2C bus configuration of the devicetree for the X570D4U BMC as part of
ongoing efforts to support OpenBMC on this platform.
Changes since v1:
- Fixed warnings indicated by checkpatch.pl
- Change commit message of ADC channels commit to match imperative mood
- Restructure GPIO table to better match other ASPEED devices
- Clarify naming scheme better
Best regards,
Renze Nicolai
Renze Nicolai (3):
ARM: dts: Modify GPIO table for Asrock X570D4U BMC
ARM: dts: Disable unused ADC channels for Asrock X570D4U BMC
ARM: dts: Modify I2C bus configuration
.../dts/aspeed/aspeed-bmc-asrock-x570d4u.dts | 131 ++++++++----------
1 file changed, 57 insertions(+), 74 deletions(-)
--
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
* [PATCH v2 1/3] ARM: dts: Modify GPIO table for Asrock X570D4U BMC
From: Renze Nicolai @ 2024-04-03 13:28 UTC (permalink / raw)
To: renze, linux-arm-kernel, devicetree, linux-kernel, linux-aspeed,
arnd, olof, soc, robh+dt, krzysztof.kozlowski+dt, joel, andrew
In-Reply-To: <20240403133037.37782-1-renze@rnplus.nl>
Restructure GPIO table to fit maximum line length.
Fix mistakes found while working on OpenBMC
userland configuration and based on probing
the board.
Schematic for this board is not available.
Because of this the choice was made to
use a descriptive method for naming the
GPIOs.
- Push-pull outputs start with output-*
- Open-drain outputs start with control-*
- LED outputs start with led-*
- Inputs start with input-*
- Button inputs start with button-*
- Active low signals end with *-n
Signed-off-by: Renze Nicolai <renze@rnplus.nl>
---
.../dts/aspeed/aspeed-bmc-asrock-x570d4u.dts | 95 ++++++++-----------
1 file changed, 37 insertions(+), 58 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts
index 3c975bc41ae7..dff69d6ff146 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts
@@ -79,64 +79,43 @@ iio-hwmon {
&gpio {
status = "okay";
gpio-line-names =
- /*A0-A3*/ "status-locatorled-n", "", "button-nmi-n", "",
- /*A4-A7*/ "", "", "", "",
- /*B0-B3*/ "input-bios-post-cmplt-n", "", "", "",
- /*B4-B7*/ "", "", "", "",
- /*C0-C3*/ "", "", "", "",
- /*C4-C7*/ "", "", "control-locatorbutton", "",
- /*D0-D3*/ "button-power", "control-power", "button-reset", "control-reset",
- /*D4-D7*/ "", "", "", "",
- /*E0-E3*/ "", "", "", "",
- /*E4-E7*/ "", "", "", "",
- /*F0-F3*/ "", "", "", "",
- /*F4-F7*/ "", "", "", "",
- /*G0-G3*/ "output-rtc-battery-voltage-read-enable", "input-id0", "input-id1", "input-id2",
- /*G4-G7*/ "input-alert1-n", "input-alert2-n", "input-alert3-n", "",
- /*H0-H3*/ "", "", "", "",
- /*H4-H7*/ "input-mfg", "", "led-heartbeat-n", "input-caseopen",
- /*I0-I3*/ "", "", "", "",
- /*I4-I7*/ "", "", "", "",
- /*J0-J3*/ "output-bmc-ready", "", "", "",
- /*J4-J7*/ "", "", "", "",
- /*K0-K3*/ "", "", "", "",
- /*K4-K7*/ "", "", "", "",
- /*L0-L3*/ "", "", "", "",
- /*L4-L7*/ "", "", "", "",
- /*M0-M3*/ "", "", "", "",
- /*M4-M7*/ "", "", "", "",
- /*N0-N3*/ "", "", "", "",
- /*N4-N7*/ "", "", "", "",
- /*O0-O3*/ "", "", "", "",
- /*O4-O7*/ "", "", "", "",
- /*P0-P3*/ "", "", "", "",
- /*P4-P7*/ "", "", "", "",
- /*Q0-Q3*/ "", "", "", "",
- /*Q4-Q7*/ "", "", "", "",
- /*R0-R3*/ "", "", "", "",
- /*R4-R7*/ "", "", "", "",
- /*S0-S3*/ "input-bmc-pchhot-n", "", "", "",
- /*S4-S7*/ "", "", "", "",
- /*T0-T3*/ "", "", "", "",
- /*T4-T7*/ "", "", "", "",
- /*U0-U3*/ "", "", "", "",
- /*U4-U7*/ "", "", "", "",
- /*V0-V3*/ "", "", "", "",
- /*V4-V7*/ "", "", "", "",
- /*W0-W3*/ "", "", "", "",
- /*W4-W7*/ "", "", "", "",
- /*X0-X3*/ "", "", "", "",
- /*X4-X7*/ "", "", "", "",
- /*Y0-Y3*/ "", "", "", "",
- /*Y4-Y7*/ "", "", "", "",
- /*Z0-Z3*/ "", "", "led-fault-n", "output-bmc-throttle-n",
- /*Z4-Z7*/ "", "", "", "",
- /*AA0-AA3*/ "input-cpu1-thermtrip-latch-n", "", "input-cpu1-prochot-n", "",
- /*AA4-AC7*/ "", "", "", "",
- /*AB0-AB3*/ "", "", "", "",
- /*AB4-AC7*/ "", "", "", "",
- /*AC0-AC3*/ "", "", "", "",
- /*AC4-AC7*/ "", "", "", "";
+ /* A */ "input-locatorled-n", "", "", "", "", "", "", "",
+ /* B */ "input-bios-post-cmplt-n", "", "", "", "", "", "", "",
+ /* C */ "", "", "", "", "", "", "control-locatorbutton-n", "",
+ /* D */ "button-power-n", "control-power-n", "button-reset-n",
+ "control-reset-n", "", "", "", "",
+ /* E */ "", "", "", "", "", "", "", "",
+ /* F */ "", "", "", "", "", "", "", "",
+ /* G */ "output-hwm-vbat-enable", "input-id0-n", "input-id1-n",
+ "input-id2-n", "input-aux-smb-alert-n", "",
+ "input-psu-smb-alert-n", "",
+ /* H */ "", "", "", "", "input-mfg-mode-n", "",
+ "led-heartbeat-n", "input-case-open-n",
+ /* I */ "", "", "", "", "", "", "", "",
+ /* J */ "output-bmc-ready-n", "", "", "", "", "", "", "",
+ /* K */ "", "", "", "", "", "", "", "",
+ /* L */ "", "", "", "", "", "", "", "",
+ /* M */ "", "", "", "", "", "", "", "",
+ /* N */ "", "", "", "", "", "", "", "",
+ /* O */ "", "", "", "", "", "", "", "",
+ /* P */ "", "", "", "", "", "", "", "",
+ /* Q */ "", "", "", "", "input-bmc-smb-present-n", "", "",
+ "input-pcie-wake-n",
+ /* R */ "", "", "", "", "", "", "", "",
+ /* S */ "input-bmc-pchhot-n", "", "", "", "", "", "", "",
+ /* T */ "", "", "", "", "", "", "", "",
+ /* U */ "", "", "", "", "", "", "", "",
+ /* V */ "", "", "", "", "", "", "", "",
+ /* W */ "", "", "", "", "", "", "", "",
+ /* X */ "", "", "", "", "", "", "", "",
+ /* Y */ "input-sleep-s3-n", "input-sleep-s5-n", "", "", "", "",
+ "", "",
+ /* Z */ "", "", "led-fault-n", "output-bmc-throttle-n", "", "",
+ "", "",
+ /* AA */ "input-cpu1-thermtrip-latch-n", "",
+ "input-cpu1-prochot-n", "", "", "", "", "",
+ /* AB */ "", "input-power-good", "", "", "", "", "", "",
+ /* AC */ "", "", "", "", "", "", "", "";
};
&fmc {
--
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 v2 3/3] ARM: dts: Modify I2C bus configuration
From: Renze Nicolai @ 2024-04-03 13:28 UTC (permalink / raw)
To: renze, linux-arm-kernel, devicetree, linux-kernel, linux-aspeed,
arnd, olof, soc, robh+dt, krzysztof.kozlowski+dt, joel, andrew
In-Reply-To: <20240403133037.37782-1-renze@rnplus.nl>
Enable I2C bus 8 which is exposed on the IPMB_1 connector
on the X570D4U mainboard.
Additionally adds a descriptive comment to I2C busses 1 and 5.
Signed-off-by: Renze Nicolai <renze@rnplus.nl>
---
arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts
index 66318ef8caae..8dee4faa9e07 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts
@@ -162,6 +162,7 @@ &i2c0 {
};
&i2c1 {
+ /* Hardware monitoring SMBus */
status = "okay";
w83773g@4c {
@@ -219,6 +220,7 @@ i2c4mux0ch3: i2c@3 {
};
&i2c5 {
+ /* SMBus on BMC connector (BMC_SMB_1) */
status = "okay";
};
@@ -243,6 +245,11 @@ eth1_macaddress: macaddress@3f88 {
};
};
+&i2c8 {
+ /* SMBus on intelligent platform management bus header (IPMB_1) */
+ status = "okay";
+};
+
&gfx {
status = "okay";
};
--
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 v2 2/3] ARM: dts: Disable unused ADC channels for Asrock X570D4U BMC
From: Renze Nicolai @ 2024-04-03 13:28 UTC (permalink / raw)
To: renze, linux-arm-kernel, devicetree, linux-kernel, linux-aspeed,
arnd, olof, soc, robh+dt, krzysztof.kozlowski+dt, joel, andrew
In-Reply-To: <20240403133037.37782-1-renze@rnplus.nl>
Additionally adds labels describing the ADC channels.
Signed-off-by: Renze Nicolai <renze@rnplus.nl>
---
.../dts/aspeed/aspeed-bmc-asrock-x570d4u.dts | 29 +++++++++----------
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts
index dff69d6ff146..66318ef8caae 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-x570d4u.dts
@@ -337,20 +337,17 @@ fan@5 {
&adc {
status = "okay";
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_adc0_default
- &pinctrl_adc1_default
- &pinctrl_adc2_default
- &pinctrl_adc3_default
- &pinctrl_adc4_default
- &pinctrl_adc5_default
- &pinctrl_adc6_default
- &pinctrl_adc7_default
- &pinctrl_adc8_default
- &pinctrl_adc9_default
- &pinctrl_adc10_default
- &pinctrl_adc11_default
- &pinctrl_adc12_default
- &pinctrl_adc13_default
- &pinctrl_adc14_default
- &pinctrl_adc15_default>;
+ pinctrl-0 = <&pinctrl_adc0_default /* 3VSB */
+ &pinctrl_adc1_default /* 5VSB */
+ &pinctrl_adc2_default /* VCPU */
+ &pinctrl_adc3_default /* VSOC */
+ &pinctrl_adc4_default /* VCCM */
+ &pinctrl_adc5_default /* APU-VDDP */
+ &pinctrl_adc6_default /* PM-VDD-CLDO */
+ &pinctrl_adc7_default /* PM-VDDCR-S5 */
+ &pinctrl_adc8_default /* PM-VDDCR */
+ &pinctrl_adc9_default /* VBAT */
+ &pinctrl_adc10_default /* 3V */
+ &pinctrl_adc11_default /* 5V */
+ &pinctrl_adc12_default>; /* 12V */
};
--
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
* Re: (subset) [PATCH v2 0/9] spi: pxa2xx: Drop linux/spi/pxa2xx_spi.h
From: Andy Shevchenko @ 2024-04-03 13:39 UTC (permalink / raw)
To: Mark Brown
Cc: linux-spi, linux-kernel, linux-arm-kernel, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, Russell King, Arnd Bergmann
In-Reply-To: <b7ac20d0-ca45-4e65-92ff-ddf84da6645a@sirena.org.uk>
On Wed, Apr 03, 2024 at 02:29:38PM +0100, Mark Brown wrote:
> On Wed, Apr 03, 2024 at 02:07:29PM +0300, Andy Shevchenko wrote:
>
> > Do I need to do anything else to get the rest applied?
>
> All the concerns I have with swnodes just being a more complex and less
> maintainable way of doing things still stand, I'm not clear that this is
> making anything better.
As I explained before it's not less maintainable than device tree sources.
The only difference is that we don't have validation tool for in-kernel
tables. And I don't see why we need that. The data describes the platforms
and in the very same way may come to the driver from elsewhere.
How would you validate that? It the same as we trust firmware (boot loader)
or not. If we don't than how should we do at all?
Can you point out what the exact aspect is most significant from C language
perspective that we miss after conversion? Type checking? Something else?
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: (subset) [PATCH v2 0/9] spi: pxa2xx: Drop linux/spi/pxa2xx_spi.h
From: Andy Shevchenko @ 2024-04-03 13:41 UTC (permalink / raw)
To: Mark Brown
Cc: linux-spi, linux-kernel, linux-arm-kernel, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, Russell King, Arnd Bergmann
In-Reply-To: <Zg1cAHEkhIf2vpwJ@smile.fi.intel.com>
On Wed, Apr 03, 2024 at 04:39:13PM +0300, Andy Shevchenko wrote:
> On Wed, Apr 03, 2024 at 02:29:38PM +0100, Mark Brown wrote:
> > On Wed, Apr 03, 2024 at 02:07:29PM +0300, Andy Shevchenko wrote:
> >
> > > Do I need to do anything else to get the rest applied?
> >
> > All the concerns I have with swnodes just being a more complex and less
> > maintainable way of doing things still stand, I'm not clear that this is
> > making anything better.
>
> As I explained before it's not less maintainable than device tree sources.
> The only difference is that we don't have validation tool for in-kernel
> tables. And I don't see why we need that. The data describes the platforms
> and in the very same way may come to the driver from elsewhere.
> How would you validate that? It the same as we trust firmware (boot loader)
> or not. If we don't than how should we do at all?
>
> Can you point out what the exact aspect is most significant from C language
> perspective that we miss after conversion? Type checking? Something else?
Also note, after hiding the data structures from that file we open
the door for the much bigger cleanup, and I have patches already precooked
(need a bit of time to test, though).
--
With Best Regards,
Andy Shevchenko
_______________________________________________
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] arm64: tlb: Fix TLBI RANGE operand
From: Marc Zyngier @ 2024-04-03 13:44 UTC (permalink / raw)
To: Gavin Shan
Cc: linux-arm-kernel, linux-kernel, catalin.marinas, will, akpm,
apopple, mark.rutland, ryan.roberts, rananta, yangyicong,
v-songbaohua, yezhenyu2, yihyu, shan.gavin
In-Reply-To: <20134458-508b-4853-a962-c1b44009e8ed@redhat.com>
On Wed, 03 Apr 2024 12:37:30 +0100,
Gavin Shan <gshan@redhat.com> wrote:
>
> On 4/3/24 18:58, Marc Zyngier wrote:
> > On Wed, 03 Apr 2024 07:49:29 +0100,
> > Gavin Shan <gshan@redhat.com> wrote:
> >>
> >> KVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty
> >> bitmap is collected by VMM and the corresponding PTEs need to be
> >> write-protected again. Unfortunately, the operand passed to the TLBI
> >> RANGE instruction isn't correctly sorted out by commit d1d3aa98b1d4
> >> ("arm64: tlb: Use the TLBI RANGE feature in arm64"). It leads to
> >> crash on the destination VM after live migration because some of the
> >> dirty pages are missed.
> >>
> >> For example, I have a VM where 8GB memory is assigned, starting from
> >> 0x40000000 (1GB). Note that the host has 4KB as the base page size.
> >> All TLBs for VM can be covered by one TLBI RANGE operation. However,
> >> I receives 0xffff708000040000 as the operand, which is wrong and the
> >> correct one should be 0x00007f8000040000. From the wrong operand, we
> >> have 3 and 1 for SCALE (bits[45:44) and NUM (bits943:39], only 1GB
> >> instead of 8GB memory is covered.
> >>
> >> Fix the macro __TLBI_RANGE_NUM() so that the correct NUM and TLBI
> >> RANGE operand are provided.
> >>
> >> Fixes: d1d3aa98b1d4 ("arm64: tlb: Use the TLBI RANGE feature in arm64")
> >> Cc: stable@kernel.org # v5.10+
> >> Reported-by: Yihuang Yu <yihyu@redhat.com>
> >> Signed-off-by: Gavin Shan <gshan@redhat.com>
> >> ---
> >> arch/arm64/include/asm/tlbflush.h | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
> >> index 3b0e8248e1a4..07c4fb4b82b4 100644
> >> --- a/arch/arm64/include/asm/tlbflush.h
> >> +++ b/arch/arm64/include/asm/tlbflush.h
> >> @@ -166,7 +166,7 @@ static inline unsigned long get_trans_granule(void)
> >> */
> >> #define TLBI_RANGE_MASK GENMASK_ULL(4, 0)
> >> #define __TLBI_RANGE_NUM(pages, scale) \
> >> - ((((pages) >> (5 * (scale) + 1)) & TLBI_RANGE_MASK) - 1)
> >> + ((((pages) >> (5 * (scale) + 1)) - 1) & TLBI_RANGE_MASK)
> >> /*
> >> * TLB Invalidation
> >
> > This looks pretty wrong, by the very definition of the comment that's
> > just above:
> >
> > <quote>
> > /*
> > * Generate 'num' values from -1 to 30 with -1 rejected by the
> > * __flush_tlb_range() loop below.
> > */
> > </quote>
> >
> > With your change, num can't ever be negative, and that breaks
> > __flush_tlb_range_op():
> >
> > <quote>
> > num = __TLBI_RANGE_NUM(pages, scale); \
> > if (num >= 0) { \
> > addr = __TLBI_VADDR_RANGE(start >> shift, asid, \
> > scale, num, tlb_level); \
> > __tlbi(r##op, addr); \
> > if (tlbi_user) \
> > __tlbi_user(r##op, addr); \
> > start += __TLBI_RANGE_PAGES(num, scale) << PAGE_SHIFT; \
> > pages -= __TLBI_RANGE_PAGES(num, scale); \
> > } \
> > scale--; \
> > </quote>
> >
> > We'll then shove whatever value we've found in the TLBI operation,
> > leading to unknown results instead of properly adjusting the scale to
> > issue a smaller invalidation.
> >
>
> Marc, thanks for your review and comments.
>
> Indeed, this patch is incomplete at least. I think we need __TLBI_RANGE_NUM()
> to return [-1 31] instead of [-1 30], to be consistent with MAX_TLBI_RANGE_PAGES.
> -1 will be rejected in the following loop. I'm not 100% sure if I did the correct
> calculation though.
>
> /*
> * Generate 'num' values in range [-1 31], but -1 will be rejected
> * by the __flush_tlb_range() loop below.
> */
> #define __TLBI_RANGE_NUM(pages, scale) \
> ({ \
> int __next = (pages) & (1ULL << (5 * (scale) + 6)); \
> int __mask = ((pages) >> (5 * (scale) + 1)) & TLBI_RANGE_MASK; \
> int __num = (((pages) >> (5 * (scale) + 1)) - 1) & \
> TLBI_RANGE_MASK; \
> (__next || __mask) ? __num : -1; \
> })
I'm afraid I don't follow the logic here, and it looks awfully
complex. I came up with something simpler with this:
diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index 3b0e8248e1a4..b3f1a9c61189 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -161,12 +161,18 @@ static inline unsigned long get_trans_granule(void)
#define MAX_TLBI_RANGE_PAGES __TLBI_RANGE_PAGES(31, 3)
/*
- * Generate 'num' values from -1 to 30 with -1 rejected by the
+ * Generate 'num' values from -1 to 31 with -1 rejected by the
* __flush_tlb_range() loop below.
*/
#define TLBI_RANGE_MASK GENMASK_ULL(4, 0)
-#define __TLBI_RANGE_NUM(pages, scale) \
- ((((pages) >> (5 * (scale) + 1)) & TLBI_RANGE_MASK) - 1)
+#define __TLBI_RANGE_NUM(pages, scale) \
+ ({ \
+ int __pages = min((pages), \
+ __TLBI_RANGE_PAGES(31, (scale))); \
+ int __numplus1 = __pages >> (5 * (scale) + 1); \
+ \
+ (__numplus1 - 1); \
+ })
/*
* TLB Invalidation
@@ -379,10 +385,6 @@ static inline void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch)
* 3. If there is 1 page remaining, flush it through non-range operations. Range
* operations can only span an even number of pages. We save this for last to
* ensure 64KB start alignment is maintained for the LPA2 case.
- *
- * Note that certain ranges can be represented by either num = 31 and
- * scale or num = 0 and scale + 1. The loop below favours the latter
- * since num is limited to 30 by the __TLBI_RANGE_NUM() macro.
*/
#define __flush_tlb_range_op(op, start, pages, stride, \
asid, tlb_level, tlbi_user, lpa2) \
>
> Alternatively, we can also limit the number of pages to be invalidated from
> arch/arm64/kvm/hyp/pgtable.c::kvm_tlb_flush_vmid_range() because the maximal
> capacity is (MAX_TLBI_RANGE_PAGES - 1) instead of MAX_TLBI_RANGE_PAGES, as
> the comments for __flush_tlb_range_nosync() say.
>
> - inval_pages = min(pages, MAX_TLBI_RANGE_PAGES);
> + inval_pages = min(pages, MAX_TLBI_RANGE_PAGES - 1);
>
>
> static inline void __flush_tlb_range_nosync(...)
> {
> :
> /*
> * When not uses TLB range ops, we can handle up to
> * (MAX_DVM_OPS - 1) pages;
> * When uses TLB range ops, we can handle up to
> * (MAX_TLBI_RANGE_PAGES - 1) pages.
> */
> if ((!system_supports_tlb_range() &&
> (end - start) >= (MAX_DVM_OPS * stride)) ||
> pages >= MAX_TLBI_RANGE_PAGES) {
> flush_tlb_mm(vma->vm_mm);
> return;
> }
> }
>
> Please let me know which way is better.
I would really prefer to fix the range stuff itself instead of
papering over the problem by reducing the reach of the range
invalidation.
>
> > I think the problem is that you are triggering NUM=31 and SCALE=3,
> > which the current code cannot handle as per the comment above
> > __flush_tlb_range_op() (we can't do NUM=30 and SCALE=4, obviously).
> >
>
> Yes, exactly.
>
> > Can you try the untested patch below?
> >
> >
> > diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
> > index 3b0e8248e1a4..b71a1cece802 100644
> > --- a/arch/arm64/include/asm/tlbflush.h
> > +++ b/arch/arm64/include/asm/tlbflush.h
> > @@ -379,10 +379,6 @@ static inline void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch)
> > * 3. If there is 1 page remaining, flush it through non-range operations. Range
> > * operations can only span an even number of pages. We save this for last to
> > * ensure 64KB start alignment is maintained for the LPA2 case.
> > - *
> > - * Note that certain ranges can be represented by either num = 31 and
> > - * scale or num = 0 and scale + 1. The loop below favours the latter
> > - * since num is limited to 30 by the __TLBI_RANGE_NUM() macro.
> > */
> > #define __flush_tlb_range_op(op, start, pages, stride, \
> > asid, tlb_level, tlbi_user, lpa2) \
> > @@ -407,6 +403,7 @@ do { \
> > \
> > num = __TLBI_RANGE_NUM(pages, scale); \
> > if (num >= 0) { \
> > + num += 1; \
> > addr = __TLBI_VADDR_RANGE(start >> shift, asid, \
> > scale, num, tlb_level); \
> > __tlbi(r##op, addr); \
> >
>
> Thanks, but I don't think it's going to work. The loop will be running infinitely
> because the condition 'if (num >= 0)' can't be met when @pages is 0x200000 when
> @scale is 3/2/1/0 until @scale becomes negative and positive again, but @scale
> isn't in range [0 3]. I ported the chunk of code to user-space and I can see this
> with added printf() messages.
Yeah, we lose num==0, which is silly. Hopefully the hack above helps a
bit.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
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: Fixing the devicetree of Rock 5 Model B (and possibly others)
From: Dragan Simic @ 2024-04-03 13:51 UTC (permalink / raw)
To: Pratham Patel
Cc: Saravana Kannan, sebastian.reichel, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, regressions, stable
In-Reply-To: <D0A122WK7CB9.33B2TP6UCMJBJ@thefossguy.com>
Hello Pratham,
On 2024-04-03 01:32, Pratham Patel wrote:
> On Tue Apr 2, 2024 at 4:54 AM IST, Saravana Kannan wrote:
>> On Sat, Mar 23, 2024 at 10:10 AM Dragan Simic <dsimic@manjaro.org>
>> wrote:
>> > On 2024-03-23 18:02, Pratham Patel wrote:
>> > > I looked at the patch and tried several things, neither resulted in
>> > > anything that would point me to the core issue. Then I tried this:
>> >
>> > Could you, please, clarify a bit what's the actual issue you're
>> > experiencing on your Rock 5B?
>>
>> Pratham, can you reply to this please? I don't really understand what
>> your issue is for me to be able to help.
>
> I apologize for not replying. Somehow, I did not notice the reply from
> Dragan. :(
No worries, I saw the serial console log file in one of your messages,
which actually provided the answer to my question. :)
> Since this patch was applied, an issue in the Rock 5B's DT has been
> unearthed which now results in the kernel being unable to boot
> properly.
>
> Following is the relevant call trace from the UART capture:
>
> [ 21.595068] Call trace:
> [ 21.595288] smp_call_function_many_cond+0x174/0x5f8
> [ 21.595728] on_each_cpu_cond_mask+0x2c/0x40
> [ 21.596109] cpuidle_register_driver+0x294/0x318
> [ 21.596524] cpuidle_register+0x24/0x100
> [ 21.596875] psci_cpuidle_probe+0x2e4/0x490
> [ 21.597247] platform_probe+0x70/0xd0
> [ 21.597575] really_probe+0x18c/0x3d8
> [ 21.597905] __driver_probe_device+0x84/0x180
> [ 21.598294] driver_probe_device+0x44/0x120
> [ 21.598669] __device_attach_driver+0xc4/0x168
> [ 21.599063] bus_for_each_drv+0x8c/0xf0
> [ 21.599408] __device_attach+0xa4/0x1c0
> [ 21.599748] device_initial_probe+0x1c/0x30
> [ 21.600118] bus_probe_device+0xb4/0xc0
> [ 21.600462] device_add+0x68c/0x888
> [ 21.600775] platform_device_add+0x19c/0x270
> [ 21.601154] platform_device_register_full+0xdc/0x178
> [ 21.601602] psci_idle_init+0xa0/0xc8
> [ 21.601934] do_one_initcall+0x60/0x290
> [ 21.602275] kernel_init_freeable+0x20c/0x3e0
> [ 21.602664] kernel_init+0x2c/0x1f8
> [ 21.602979] ret_from_fork+0x10/0x20
>
>> Also, can you give the output of <debugfs>/devices_deferred for the
>> good vs bad case?
>
> I can't provide you with requested output from the bad case, since the
> kernel never moves past this to an initramfs rescue shell, but
> following
> is the output from v6.8.1 (**with aforementioned patch reverted**).
>
> # cat /sys/kernel/debug/devices_deferred
> fc400000.usb platform: wait for supplier /phy@fed90000/usb3-port
> 1-0022 typec_fusb302: cannot register tcpm port
> fc000000.usb platform: wait for supplier /phy@fed80000/usb3-port
>
> It seems that v6.8.2 works _without needing to revert the patch_. I
> will
> have to look into this sometime this week but it seems like
> a8037ceb8964 (arm64: dts: rockchip: drop rockchip,trcm-sync-tx-only
> from rk3588 i2s)
> seems to be the one that fixed the root issue. I will have to test it
> sometime later 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] dt-bindings: firmware: arm,scmi: Update examples for protocol@13
From: Sudeep Holla @ 2024-04-03 13:53 UTC (permalink / raw)
To: Ulf Hansson
Cc: Cristian Marussi, Rob Herring, Krzysztof Kozlowski, devicetree,
linux-arm-kernel
In-Reply-To: <20240403111106.1110940-1-ulf.hansson@linaro.org>
On Wed, Apr 03, 2024 at 01:11:06PM +0200, Ulf Hansson wrote:
> Recently we extended the binding for protocol@13 to allow it to be modelled
> as a generic performance domain. In a way to promote using the new binding,
> let's update the examples.
>
Does it make sense to keep one DVFS example with #clock-cells until we
mark it as deprecated ? Otherwise it may be confusing as the binding still
lists. Or leave some comment in the example or something, I am open for
suggestions.
Other than that,
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
--
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 6/7] wifi: marvell: mwifiex: drop driver owner initialization
From: Kalle Valo @ 2024-04-03 13:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Ulf Hansson, Marcel Holtmann, Luiz Augusto von Dentz,
Matthias Brugger, AngeloGioacchino Del Regno, Jeff Johnson,
Arend van Spriel, Brian Norris, Jérôme Pouiller,
linux-mmc, linux-kernel, linux-bluetooth, linux-arm-kernel,
linux-mediatek, linux-wireless, ath10k, brcm80211,
brcm80211-dev-list.pdl
In-Reply-To: <20240329-module-owner-sdio-v1-6-e4010b11ccaa@linaro.org>
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> writes:
> Core in sdio_register_driver() already sets the .owner, so driver does
> not need to.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
The preferred title format is:
wifi: mwifiex: drop driver owner initialization
But that's just cosmetics. Feel free to take this via sdio tree:
Acked-by: Kalle Valo <kvalo@kernel.org>
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
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 7/7] wifi: silabs: wfx: drop driver owner initialization
From: Kalle Valo @ 2024-04-03 13:54 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Ulf Hansson, Marcel Holtmann, Luiz Augusto von Dentz,
Matthias Brugger, AngeloGioacchino Del Regno, Jeff Johnson,
Arend van Spriel, Brian Norris, Jérôme Pouiller,
linux-mmc, linux-kernel, linux-bluetooth, linux-arm-kernel,
linux-mediatek, linux-wireless, ath10k, brcm80211,
brcm80211-dev-list.pdl
In-Reply-To: <20240329-module-owner-sdio-v1-7-e4010b11ccaa@linaro.org>
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> writes:
> Core in sdio_register_driver() already sets the .owner, so driver does
> not need to.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Also here the preferred title format is:
wifi: wfx: drop driver owner initialization
Feel free to take this via sdio tree:
Acked-by: Kalle Valo <kvalo@kernel.org>
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Fixing the devicetree of Rock 5 Model B (and possibly others)
From: Sebastian Reichel @ 2024-04-03 13:52 UTC (permalink / raw)
To: Pratham Patel
Cc: Saravana Kannan, Dragan Simic, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, regressions, stable
In-Reply-To: <D0A2ZL6S8UG6.2BQKIBQWYB36D@thefossguy.com>
[-- Attachment #1.1: Type: text/plain, Size: 1529 bytes --]
Hi,
On Wed, Apr 03, 2024 at 01:03:07AM +0000, Pratham Patel wrote:
> > > > Also, can you give the output of <debugfs>/devices_deferred for the
> > > > good vs bad case?
> > >
> > > I can't provide you with requested output from the bad case, since the
> > > kernel never moves past this to an initramfs rescue shell, but following
> > > is the output from v6.8.1 (**with aforementioned patch reverted**).
> > >
> > > # cat /sys/kernel/debug/devices_deferred
> > > fc400000.usb platform: wait for supplier /phy@fed90000/usb3-port
> > > 1-0022 typec_fusb302: cannot register tcpm port
> > > fc000000.usb platform: wait for supplier /phy@fed80000/usb3-port
> > >
> > > It seems that v6.8.2 works _without needing to revert the patch_. I will
> > > have to look into this sometime this week but it seems like
> > > a8037ceb8964 (arm64: dts: rockchip: drop rockchip,trcm-sync-tx-only from rk3588 i2s)
> > > seems to be the one that fixed the root issue. I will have to test it
> > > sometime later this week.
> >
> > Ok, once you find the patch that fixes things, let me know too.
>
> Will do!
FWIW the v6.8.1 kernel referenced above is definitely patched, since
upstream's Rock 5B DT does neither describe fusb302, nor the USB
port it is connected to.
We have a few Rock 5B in Kernel CI and upstream boots perfectly
fine:
https://lava.collabora.dev/scheduler/device_type/rk3588-rock-5b
So it could be one of your downstream patches, which is introducing
this problem.
-- Sebastian
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 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: (subset) [PATCH v2 0/9] spi: pxa2xx: Drop linux/spi/pxa2xx_spi.h
From: Mark Brown @ 2024-04-03 14:13 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-spi, linux-kernel, linux-arm-kernel, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, Russell King, Arnd Bergmann
In-Reply-To: <Zg1clCuOwkCNzSgy@smile.fi.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 2036 bytes --]
On Wed, Apr 03, 2024 at 04:41:40PM +0300, Andy Shevchenko wrote:
> On Wed, Apr 03, 2024 at 04:39:13PM +0300, Andy Shevchenko wrote:
> > On Wed, Apr 03, 2024 at 02:29:38PM +0100, Mark Brown wrote:
> > > All the concerns I have with swnodes just being a more complex and less
> > > maintainable way of doing things still stand, I'm not clear that this is
> > > making anything better.
> > As I explained before it's not less maintainable than device tree sources.
> > The only difference is that we don't have validation tool for in-kernel
> > tables. And I don't see why we need that. The data describes the platforms
> > and in the very same way may come to the driver from elsewhere.
> > How would you validate that? It the same as we trust firmware (boot loader)
> > or not. If we don't than how should we do at all?
I don't think we should do this at all, all I see from these changes is
effort in reviewing them - as far as I can tell they are a solution in
search of a problem. DT has some support for validation of the
formatting of the data supplied by the board and offers the potential
for distributing the board description separately to the kernel.
> > Can you point out what the exact aspect is most significant from C language
> > perspective that we miss after conversion? Type checking? Something else?
You're changing the code from supplying data from the board description
via a simple C structure where the compiler offers at least some
validation and where we can just supply directly usable values to an
abstract data structure that's still encoded in C but has less
validation and requires a bunch of code to parse at runtime. Platform
data is unsurprisingly a good solution to the problem of supplying
platform data.
> Also note, after hiding the data structures from that file we open
> the door for the much bigger cleanup, and I have patches already precooked
> (need a bit of time to test, though).
Perhaps those will motivate a change, as things stand I've not seen what
you're proposing to do here.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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 v1 0/4] arm64: dts: freescale: Add Toradex Colibri iMX8DX
From: Rob Herring @ 2024-04-03 14:15 UTC (permalink / raw)
To: Hiago De Franco
Cc: Krzysztof Kozlowski, linux-arm-kernel, Sascha Hauer,
Pengutronix Kernel Team, Conor Dooley, Hiago De Franco, imx,
devicetree, Fabio Estevam, Shawn Guo, linux-kernel
In-Reply-To: <20240402193512.240417-1-hiagofranco@gmail.com>
On Tue, 02 Apr 2024 16:35:08 -0300, Hiago De Franco wrote:
> From: Hiago De Franco <hiago.franco@toradex.com>
>
> This patch series introduces support for Colibri iMX8DX SoM and its
> carrier boards, where the board can be mated with: Aster, Evaluation Board
> v3, Iris v2, and Iris v1. This SoM is a variant of the already supported
> Colibri iMX8QXP, utilizing an NXP i.MX8DX SoC instead of i.MX8QXP.
> Therefore, this patch series also adds support for the i.MX8DX processor.
>
> Hiago De Franco (4):
> arm64: dts: freescale: Add i.MX8DX dtsi
> dt-bindings: arm: fsl: remove reduntant toradex,colibri-imx8x
> dt-bindings: arm: fsl: Add Colibri iMX8DX
> arm64: dts: freescale: Add Toradex Colibri iMX8DX
>
> Documentation/devicetree/bindings/arm/fsl.yaml | 7 ++++---
> arch/arm64/boot/dts/freescale/Makefile | 4 ++++
> .../boot/dts/freescale/imx8dx-colibri-aster.dts | 16 ++++++++++++++++
> .../dts/freescale/imx8dx-colibri-eval-v3.dts | 16 ++++++++++++++++
> .../dts/freescale/imx8dx-colibri-iris-v2.dts | 16 ++++++++++++++++
> .../boot/dts/freescale/imx8dx-colibri-iris.dts | 16 ++++++++++++++++
> .../arm64/boot/dts/freescale/imx8dx-colibri.dtsi | 11 +++++++++++
> arch/arm64/boot/dts/freescale/imx8dx.dtsi | 13 +++++++++++++
> 8 files changed, 96 insertions(+), 3 deletions(-)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8dx-colibri-aster.dts
> create mode 100644 arch/arm64/boot/dts/freescale/imx8dx-colibri-eval-v3.dts
> create mode 100644 arch/arm64/boot/dts/freescale/imx8dx-colibri-iris-v2.dts
> create mode 100644 arch/arm64/boot/dts/freescale/imx8dx-colibri-iris.dts
> create mode 100644 arch/arm64/boot/dts/freescale/imx8dx-colibri.dtsi
> create mode 100644 arch/arm64/boot/dts/freescale/imx8dx.dtsi
>
> --
> 2.39.2
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y freescale/imx8dx-colibri-aster.dtb freescale/imx8dx-colibri-eval-v3.dtb freescale/imx8dx-colibri-iris-v2.dtb freescale/imx8dx-colibri-iris.dtb' for 20240402193512.240417-1-hiagofranco@gmail.com:
arch/arm64/boot/dts/freescale/imx8dx-colibri-aster.dtb: jpegdec@58400000: 'assigned-clock-rates', 'assigned-clocks', 'clock-names', 'clocks', 'slot' do not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/media/nxp,imx8-jpeg.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-aster.dtb: jpegenc@58450000: 'assigned-clock-rates', 'assigned-clocks', 'clock-names', 'clocks', 'slot' do not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/media/nxp,imx8-jpeg.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-eval-v3.dtb: jpegdec@58400000: 'assigned-clock-rates', 'assigned-clocks', 'clock-names', 'clocks', 'slot' do not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/media/nxp,imx8-jpeg.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-eval-v3.dtb: jpegenc@58450000: 'assigned-clock-rates', 'assigned-clocks', 'clock-names', 'clocks', 'slot' do not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/media/nxp,imx8-jpeg.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris-v2.dtb: jpegdec@58400000: 'assigned-clock-rates', 'assigned-clocks', 'clock-names', 'clocks', 'slot' do not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/media/nxp,imx8-jpeg.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris-v2.dtb: jpegenc@58450000: 'assigned-clock-rates', 'assigned-clocks', 'clock-names', 'clocks', 'slot' do not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/media/nxp,imx8-jpeg.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris.dtb: jpegdec@58400000: 'assigned-clock-rates', 'assigned-clocks', 'clock-names', 'clocks', 'slot' do not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/media/nxp,imx8-jpeg.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris.dtb: jpegenc@58450000: 'assigned-clock-rates', 'assigned-clocks', 'clock-names', 'clocks', 'slot' do not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/media/nxp,imx8-jpeg.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-aster.dtb: dma-controller@591f0000: 'clocks' is a required property
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-aster.dtb: dma-controller@591f0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-eval-v3.dtb: dma-controller@591f0000: 'clocks' is a required property
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-aster.dtb: dma-controller@599f0000: 'clocks' is a required property
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-eval-v3.dtb: dma-controller@591f0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-aster.dtb: dma-controller@599f0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris-v2.dtb: dma-controller@591f0000: 'clocks' is a required property
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris-v2.dtb: dma-controller@591f0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-eval-v3.dtb: dma-controller@599f0000: 'clocks' is a required property
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-eval-v3.dtb: dma-controller@599f0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris.dtb: dma-controller@591f0000: 'clocks' is a required property
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris.dtb: dma-controller@591f0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris-v2.dtb: dma-controller@599f0000: 'clocks' is a required property
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris-v2.dtb: dma-controller@599f0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris.dtb: dma-controller@599f0000: 'clocks' is a required property
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris.dtb: dma-controller@599f0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-aster.dtb: dma-controller@5a1f0000: 'clocks' is a required property
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-aster.dtb: dma-controller@5a1f0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-eval-v3.dtb: /bus@5a000000/spi@5a020000/can@0: failed to match any schema with compatible: ['microchip,mcp2515']
arch/arm64/boot/dts/freescale/imx8dx-colibri-eval-v3.dtb: dma-controller@5a1f0000: 'clocks' is a required property
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-eval-v3.dtb: dma-controller@5a1f0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris-v2.dtb: dma-controller@5a1f0000: 'clocks' is a required property
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris-v2.dtb: dma-controller@5a1f0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-aster.dtb: touchscreen@2c: adi,first-conversion-delay: b'\x03' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-aster.dtb: touchscreen@2c: adi,acquisition-time: b'\x01' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-aster.dtb: touchscreen@2c: adi,median-filter-size: b'\x02' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-aster.dtb: touchscreen@2c: adi,averaging: b'\x01' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-aster.dtb: touchscreen@2c: adi,conversion-interval: b'\xff' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris.dtb: dma-controller@5a1f0000: 'clocks' is a required property
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris.dtb: dma-controller@5a1f0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-aster.dtb: /bus@5a000000/i2c@5a800000/touchscreen@2c: failed to match any schema with compatible: ['adi,ad7879-1']
arch/arm64/boot/dts/freescale/imx8dx-colibri-eval-v3.dtb: touchscreen@2c: adi,first-conversion-delay: b'\x03' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-eval-v3.dtb: touchscreen@2c: adi,acquisition-time: b'\x01' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-eval-v3.dtb: touchscreen@2c: adi,median-filter-size: b'\x02' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-eval-v3.dtb: touchscreen@2c: adi,averaging: b'\x01' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-eval-v3.dtb: touchscreen@2c: adi,conversion-interval: b'\xff' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-aster.dtb: dma-controller@5a9f0000: 'clocks' is a required property
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-eval-v3.dtb: /bus@5a000000/i2c@5a800000/touchscreen@2c: failed to match any schema with compatible: ['adi,ad7879-1']
arch/arm64/boot/dts/freescale/imx8dx-colibri-aster.dtb: dma-controller@5a9f0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris-v2.dtb: touchscreen@2c: adi,first-conversion-delay: b'\x03' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris-v2.dtb: touchscreen@2c: adi,acquisition-time: b'\x01' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris-v2.dtb: touchscreen@2c: adi,median-filter-size: b'\x02' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris-v2.dtb: touchscreen@2c: adi,averaging: b'\x01' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris-v2.dtb: touchscreen@2c: adi,conversion-interval: b'\xff' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris-v2.dtb: /bus@5a000000/i2c@5a800000/touchscreen@2c: failed to match any schema with compatible: ['adi,ad7879-1']
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris.dtb: touchscreen@2c: adi,first-conversion-delay: b'\x03' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris.dtb: touchscreen@2c: adi,acquisition-time: b'\x01' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris.dtb: touchscreen@2c: adi,median-filter-size: b'\x02' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris.dtb: touchscreen@2c: adi,averaging: b'\x01' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris.dtb: touchscreen@2c: adi,conversion-interval: b'\xff' is not of type 'object', 'integer', 'array', 'boolean', 'null'
from schema $id: http://devicetree.org/schemas/dt-core.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris.dtb: /bus@5a000000/i2c@5a800000/touchscreen@2c: failed to match any schema with compatible: ['adi,ad7879-1']
arch/arm64/boot/dts/freescale/imx8dx-colibri-eval-v3.dtb: dma-controller@5a9f0000: 'clocks' is a required property
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-eval-v3.dtb: dma-controller@5a9f0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris-v2.dtb: dma-controller@5a9f0000: 'clocks' is a required property
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris-v2.dtb: dma-controller@5a9f0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris.dtb: dma-controller@5a9f0000: 'clocks' is a required property
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dx-colibri-iris.dtb: dma-controller@5a9f0000: Unevaluated properties are not allowed ('power-domains' was unexpected)
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
_______________________________________________
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 v9 0/9] Initial Marvell PXA1908 support
From: Rob Herring @ 2024-04-03 14:15 UTC (permalink / raw)
To: Duje Mihanović
Cc: phone-devel, linux-gpio, Krzysztof Kozlowski,
Guilherme G. Piccoli, linux-kernel, Catalin Marinas,
~postmarketos/upstreaming, Andy Shevchenko, linux-arm-kernel,
devicetree, Krzysztof Kozlowski, Linus Walleij, Kees Cook,
Rob Herring, Stephen Boyd, Lubomir Rintel, Will Deacon,
Karel Balej, linux-clk, Conor Dooley, Tony Lindgren, David Wronek,
Haojian Zhuang, Tony Luck, Conor Dooley, Michael Turquette
In-Reply-To: <20240402-pxa1908-lkml-v9-0-25a003e83c6f@skole.hr>
On Tue, 02 Apr 2024 22:55:36 +0200, Duje Mihanović wrote:
> Hello,
>
> This series adds initial support for the Marvell PXA1908 SoC and
> "samsung,coreprimevelte", a smartphone using the SoC.
>
> USB works and the phone can boot a rootfs from an SD card, but there are
> some warnings in the dmesg:
>
> During SMP initialization:
> [ 0.006519] CPU features: SANITY CHECK: Unexpected variation in SYS_CNTFRQ_EL0. Boot CPU: 0x000000018cba80, CPU1: 0x00000000000000
> [ 0.006542] CPU features: Unsupported CPU feature variation detected.
> [ 0.006589] CPU1: Booted secondary processor 0x0000000001 [0x410fd032]
> [ 0.010710] Detected VIPT I-cache on CPU2
> [ 0.010716] CPU features: SANITY CHECK: Unexpected variation in SYS_CNTFRQ_EL0. Boot CPU: 0x000000018cba80, CPU2: 0x00000000000000
> [ 0.010758] CPU2: Booted secondary processor 0x0000000002 [0x410fd032]
> [ 0.014849] Detected VIPT I-cache on CPU3
> [ 0.014855] CPU features: SANITY CHECK: Unexpected variation in SYS_CNTFRQ_EL0. Boot CPU: 0x000000018cba80, CPU3: 0x00000000000000
> [ 0.014895] CPU3: Booted secondary processor 0x0000000003 [0x410fd032]
>
> SMMU probing fails:
> [ 0.101798] arm-smmu c0010000.iommu: probing hardware configuration...
> [ 0.101809] arm-smmu c0010000.iommu: SMMUv1 with:
> [ 0.101816] arm-smmu c0010000.iommu: no translation support!
>
> A 3.14 based Marvell tree is available on GitHub
> acorn-marvell/brillo_pxa_kernel, and a Samsung one on GitHub
> CoderCharmander/g361f-kernel.
>
> Andreas Färber attempted to upstream support for this SoC in 2017:
> https://lore.kernel.org/lkml/20170222022929.10540-1-afaerber@suse.de/
>
> Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
>
> Changes in v9:
> - Update trailers and rebase on v6.9-rc2, no changes
> - Link to v8: https://lore.kernel.org/20240110-pxa1908-lkml-v8-0-fea768a59474@skole.hr
>
> Changes in v8:
> - Drop SSPA patch
> - Drop broken-cd from eMMC node
> - Specify S-Boot hardcoded initramfs location in device tree
> - Add ARM PMU node
> - Correct inverted modem memory base and size
> - Update trailers
> - Rebase on next-20240110
> - Link to v7: https://lore.kernel.org/20231102-pxa1908-lkml-v7-0-cabb1a0cb52b@skole.hr
> and https://lore.kernel.org/20231102152033.5511-1-duje.mihanovic@skole.hr
>
> Changes in v7:
> - Suppress SND_MMP_SOC_SSPA on ARM64
> - Update trailers
> - Rebase on v6.6-rc7
> - Link to v6: https://lore.kernel.org/r/20231010-pxa1908-lkml-v6-0-b2fe09240cf8@skole.hr
>
> Changes in v6:
> - Address maintainer comments:
> - Add "marvell,pxa1908-padconf" binding to pinctrl-single driver
> - Drop GPIO patch as it's been pulled
> - Update trailers
> - Rebase on v6.6-rc5
> - Link to v5: https://lore.kernel.org/r/20230812-pxa1908-lkml-v5-0-a5d51937ee34@skole.hr
>
> Changes in v5:
> - Address maintainer comments:
> - Move *_NR_CLKS to clock driver from dt binding file
> - Allocate correct number of clocks for each block instead of blindly
> allocating 50 for each
> - Link to v4: https://lore.kernel.org/r/20230807-pxa1908-lkml-v4-0-cb387d73b452@skole.hr
>
> Changes in v4:
> - Address maintainer comments:
> - Relicense clock binding file to BSD-2
> - Add pinctrl-names to SD card node
> - Add vgic registers to GIC node
> - Rebase on v6.5-rc5
> - Link to v3: https://lore.kernel.org/r/20230804-pxa1908-lkml-v3-0-8e48fca37099@skole.hr
>
> Changes in v3:
> - Address maintainer comments:
> - Drop GPIO dynamic allocation patch
> - Move clock register offsets into driver (instead of bindings file)
> - Add missing Tested-by trailer to u32_fract patch
> - Move SoC binding to arm/mrvl/mrvl.yaml
> - Add serial0 alias and stdout-path to board dts to enable UART
> debugging
> - Rebase on v6.5-rc4
> - Link to v2: https://lore.kernel.org/r/20230727162909.6031-1-duje.mihanovic@skole.hr
>
> Changes in v2:
> - Remove earlycon patch as it's been merged into tty-next
> - Address maintainer comments:
> - Clarify GPIO regressions on older PXA platforms
> - Add Fixes tag to commit disabling GPIO pinctrl calls for this SoC
> - Add missing includes to clock driver
> - Clock driver uses HZ_PER_MHZ, u32_fract and GENMASK
> - Dual license clock bindings
> - Change clock IDs to decimal
> - Fix underscores in dt node names
> - Move chosen node to top of board dts
> - Clean up documentation
> - Reorder commits
> - Drop pxa,rev-id
> - Rename muic-i2c to i2c-muic
> - Reword some commits
> - Move framebuffer node to chosen
> - Add aliases for mmc nodes
> - Rebase on v6.5-rc3
> - Link to v1: https://lore.kernel.org/r/20230721210042.21535-1-duje.mihanovic@skole.hr
>
> ---
> Andy Shevchenko (1):
> clk: mmp: Switch to use struct u32_fract instead of custom one
>
> Duje Mihanović (8):
> dt-bindings: pinctrl: pinctrl-single: add marvell,pxa1908-padconf compatible
> pinctrl: single: add marvell,pxa1908-padconf compatible
> dt-bindings: clock: Add Marvell PXA1908 clock bindings
> clk: mmp: Add Marvell PXA1908 clock driver
> dt-bindings: marvell: Document PXA1908 SoC
> arm64: Kconfig.platforms: Add config for Marvell PXA1908 platform
> arm64: dts: Add DTS for Marvell PXA1908 and samsung,coreprimevelte
> MAINTAINERS: add myself as Marvell PXA1908 maintainer
>
> .../devicetree/bindings/arm/mrvl/mrvl.yaml | 5 +
> .../devicetree/bindings/clock/marvell,pxa1908.yaml | 48 +++
> .../bindings/pinctrl/pinctrl-single.yaml | 4 +
> MAINTAINERS | 9 +
> arch/arm64/Kconfig.platforms | 8 +
> arch/arm64/boot/dts/marvell/Makefile | 3 +
> .../dts/marvell/pxa1908-samsung-coreprimevelte.dts | 336 +++++++++++++++++++++
> arch/arm64/boot/dts/marvell/pxa1908.dtsi | 304 +++++++++++++++++++
> drivers/clk/mmp/Makefile | 2 +-
> drivers/clk/mmp/clk-frac.c | 57 ++--
> drivers/clk/mmp/clk-of-mmp2.c | 26 +-
> drivers/clk/mmp/clk-of-pxa168.c | 4 +-
> drivers/clk/mmp/clk-of-pxa1908.c | 328 ++++++++++++++++++++
> drivers/clk/mmp/clk-of-pxa1928.c | 6 +-
> drivers/clk/mmp/clk-of-pxa910.c | 4 +-
> drivers/clk/mmp/clk.h | 10 +-
> drivers/pinctrl/pinctrl-single.c | 1 +
> include/dt-bindings/clock/marvell,pxa1908.h | 88 ++++++
> 18 files changed, 1186 insertions(+), 57 deletions(-)
> ---
> base-commit: 39cd87c4eb2b893354f3b850f916353f2658ae6f
> change-id: 20230803-pxa1908-lkml-6830e8da45c7
>
> Best regards,
> --
> Duje Mihanović <duje.mihanovic@skole.hr>
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y marvell/pxa1908-samsung-coreprimevelte.dtb' for 20240402-pxa1908-lkml-v9-0-25a003e83c6f@skole.hr:
arch/arm64/boot/dts/marvell/pxa1908-samsung-coreprimevelte.dtb: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 0, 0, 0]]}
from schema $id: http://devicetree.org/schemas/root-node.yaml#
arch/arm64/boot/dts/marvell/pxa1908-samsung-coreprimevelte.dtb: pinmux@1e000: #size-cells: 0 was expected
from schema $id: http://devicetree.org/schemas/pinctrl/pinctrl-single.yaml#
arch/arm64/boot/dts/marvell/pxa1908-samsung-coreprimevelte.dtb: pinmux@1e000: pinctrl-single,gpio-range: [[8, 55, 55, 0], [8, 110, 32, 0], [8, 52, 1, 0]] is too long
from schema $id: http://devicetree.org/schemas/pinctrl/pinctrl-single.yaml#
arch/arm64/boot/dts/marvell/pxa1908-samsung-coreprimevelte.dtb: pinmux@1e000: 'pinmux-board-1', 'pinmux-board-2', 'pinmux-board-3', 'pinmux-gpio-keys', 'pinmux-i2c-muic', 'pinmux-sdh0-1', 'pinmux-sdh0-2', 'pinmux-sdh0-3', 'pinmux-uart0', 'ranges' do not match any of the regexes: '-pins(-[0-9]+)?$|-pin$', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/pinctrl/pinctrl-single.yaml#
arch/arm64/boot/dts/marvell/pxa1908-samsung-coreprimevelte.dtb: mmc@80000: pinctrl-names: ['default'] is too short
from schema $id: http://devicetree.org/schemas/mmc/sdhci-pxa.yaml#
arch/arm64/boot/dts/marvell/pxa1908-samsung-coreprimevelte.dtb: mmc@80000: Unevaluated properties are not allowed ('pinctrl-names' was unexpected)
from schema $id: http://devicetree.org/schemas/mmc/sdhci-pxa.yaml#
_______________________________________________
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] arm64: dts: ls1028a: sl28: split variant 3/ads2 carrier
From: Rob Herring @ 2024-04-03 14:15 UTC (permalink / raw)
To: Michael Walle
Cc: linux-arm-kernel, Shawn Guo, linux-kernel, Krzysztof Kozlowski,
Li Yang, devicetree, Conor Dooley
In-Reply-To: <20240403083812.3898480-1-mwalle@kernel.org>
On Wed, 03 Apr 2024 10:38:12 +0200, Michael Walle wrote:
> The devicetree files can be (re-)used in u-boot now, they are imported
> on a regular basis (see OF_UPSTREAM option) there. Up until now, it
> didn't matter for linux and there was just a combined devicetree
> "-var3-ads2" (with ads2 being the carrier board). But if the devicetree
> files are now reused in u-boot, we need to have an individual "-var3"
> variant, because the bootloader is just using the bare "varN" devicetree
> files. Split the "var3" off of the "-var3-ads2" devicetree.
>
> Signed-off-by: Michael Walle <mwalle@kernel.org>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> .../fsl-ls1028a-kontron-sl28-var3-ads2.dts | 2 +-
> .../fsl-ls1028a-kontron-sl28-var3.dts | 18 ++++++++++++++++++
> 3 files changed, 20 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dts
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dtb freescale/fsl-ls1028a-kontron-sl28-var3.dtb' for 20240403083812.3898480-1-mwalle@kernel.org:
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: interrupt-controller@6000000: msi-controller@6020000: '#msi-cells' is a required property
from schema $id: http://devicetree.org/schemas/interrupt-controller/arm,gic-v3.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: thermal-zones: 'core-cluster', 'ddr-controller' do not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\-]{1,12}-thermal$', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/thermal/thermal-zones.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: syscon@1e60000: compatible: 'anyOf' conditional failed, one must be fixed:
['syscon'] is too short
'syscon' is not one of ['allwinner,sun8i-a83t-system-controller', 'allwinner,sun8i-h3-system-controller', 'allwinner,sun8i-v3s-system-controller', 'allwinner,sun50i-a64-system-controller', 'amd,pensando-elba-syscon', 'brcm,cru-clkset', 'freecom,fsg-cs2-system-controller', 'fsl,imx93-aonmix-ns-syscfg', 'fsl,imx93-wakeupmix-syscfg', 'hisilicon,dsa-subctrl', 'hisilicon,hi6220-sramctrl', 'hisilicon,pcie-sas-subctrl', 'hisilicon,peri-subctrl', 'hpe,gxp-sysreg', 'intel,lgm-syscon', 'loongson,ls1b-syscon', 'loongson,ls1c-syscon', 'marvell,armada-3700-usb2-host-misc', 'mediatek,mt8135-pctl-a-syscfg', 'mediatek,mt8135-pctl-b-syscfg', 'mediatek,mt8365-syscfg', 'microchip,lan966x-cpu-syscon', 'microchip,sparx5-cpu-syscon', 'mstar,msc313-pmsleep', 'nuvoton,ma35d1-sys', 'nuvoton,wpcm450-shm', 'rockchip,px30-qos', 'rockchip,rk3036-qos', 'rockchip,rk3066-qos', 'rockchip,rk3128-qos', 'rockchip,rk3228-qos', 'rockchip,rk3288-qos', 'rockchip,rk3368-qos', 'rockchip,rk3399-qos', 'rockchip,rk3568-qos', '
rockchip,rk3588-qos', 'rockchip,rv1126-qos', 'starfive,jh7100-sysmain', 'ti,am62-usb-phy-ctrl', 'ti,am654-dss-oldi-io-ctrl', 'ti,am654-serdes-ctrl', 'ti,j784s4-pcie-ctrl']
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: efuse@1e80000: Unevaluated properties are not allowed ('unique-id@1c' was unexpected)
from schema $id: http://devicetree.org/schemas/nvmem/fsl,layerscape-sfp.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/clock-controller@1300000: failed to match any schema with compatible: ['fsl,ls1028a-clockgen']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/spi@2100000: failed to match any schema with compatible: ['fsl,ls1028a-dspi', 'fsl,ls1021a-v1.0-dspi']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/spi@2100000: failed to match any schema with compatible: ['fsl,ls1028a-dspi', 'fsl,ls1021a-v1.0-dspi']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/spi@2110000: failed to match any schema with compatible: ['fsl,ls1028a-dspi', 'fsl,ls1021a-v1.0-dspi']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/spi@2110000: failed to match any schema with compatible: ['fsl,ls1028a-dspi', 'fsl,ls1021a-v1.0-dspi']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/spi@2120000: failed to match any schema with compatible: ['fsl,ls1028a-dspi', 'fsl,ls1021a-v1.0-dspi']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/spi@2120000: failed to match any schema with compatible: ['fsl,ls1028a-dspi', 'fsl,ls1021a-v1.0-dspi']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/mmc@2140000: failed to match any schema with compatible: ['fsl,ls1028a-esdhc', 'fsl,esdhc']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/mmc@2140000: failed to match any schema with compatible: ['fsl,ls1028a-esdhc', 'fsl,esdhc']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/mmc@2150000: failed to match any schema with compatible: ['fsl,ls1028a-esdhc', 'fsl,esdhc']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/mmc@2150000: failed to match any schema with compatible: ['fsl,ls1028a-esdhc', 'fsl,esdhc']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/gpio@2300000: failed to match any schema with compatible: ['fsl,ls1028a-gpio', 'fsl,qoriq-gpio']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/gpio@2300000: failed to match any schema with compatible: ['fsl,ls1028a-gpio', 'fsl,qoriq-gpio']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/gpio@2310000: failed to match any schema with compatible: ['fsl,ls1028a-gpio', 'fsl,qoriq-gpio']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/gpio@2310000: failed to match any schema with compatible: ['fsl,ls1028a-gpio', 'fsl,qoriq-gpio']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/gpio@2320000: failed to match any schema with compatible: ['fsl,ls1028a-gpio', 'fsl,qoriq-gpio']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/gpio@2320000: failed to match any schema with compatible: ['fsl,ls1028a-gpio', 'fsl,qoriq-gpio']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/usb@3100000: failed to match any schema with compatible: ['fsl,ls1028a-dwc3', 'snps,dwc3']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/usb@3110000: failed to match any schema with compatible: ['fsl,ls1028a-dwc3', 'snps,dwc3']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/sata@3200000: failed to match any schema with compatible: ['fsl,ls1028a-ahci']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pcie@3400000: failed to match any schema with compatible: ['fsl,ls1028a-pcie']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pcie-ep@3400000: failed to match any schema with compatible: ['fsl,ls1028a-pcie-ep', 'fsl,ls-pcie-ep']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pcie-ep@3400000: failed to match any schema with compatible: ['fsl,ls1028a-pcie-ep', 'fsl,ls-pcie-ep']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pcie@3500000: failed to match any schema with compatible: ['fsl,ls1028a-pcie']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pcie-ep@3500000: failed to match any schema with compatible: ['fsl,ls1028a-pcie-ep', 'fsl,ls-pcie-ep']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pcie-ep@3500000: failed to match any schema with compatible: ['fsl,ls1028a-pcie-ep', 'fsl,ls-pcie-ep']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: dma-controller@8380000: '#dma-cells' is a required property
from schema $id: http://devicetree.org/schemas/dma/dma-controller.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/dma-controller@8380000: failed to match any schema with compatible: ['fsl,ls1028a-qdma', 'fsl,ls1021a-qdma']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/dma-controller@8380000: failed to match any schema with compatible: ['fsl,ls1028a-qdma', 'fsl,ls1021a-qdma']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: audio-controller@f100000: dma-names:1: 'tx' was expected
from schema $id: http://devicetree.org/schemas/sound/fsl,sai.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: audio-controller@f110000: dma-names:1: 'tx' was expected
from schema $id: http://devicetree.org/schemas/sound/fsl,sai.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: audio-controller@f120000: dma-names:1: 'tx' was expected
from schema $id: http://devicetree.org/schemas/sound/fsl,sai.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: audio-controller@f130000: dma-names:1: 'tx' was expected
from schema $id: http://devicetree.org/schemas/sound/fsl,sai.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: audio-controller@f140000: dma-names:1: 'tx' was expected
from schema $id: http://devicetree.org/schemas/sound/fsl,sai.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: audio-controller@f150000: dma-names:1: 'tx' was expected
from schema $id: http://devicetree.org/schemas/sound/fsl,sai.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: ranges: [[2181038080, 1, 4160749568, 1, 4160749568, 0, 1441792], [3254779904, 1, 4162191360, 1, 4162191360, 0, 458752], [2181038080, 1, 4162650112, 1, 4162650112, 0, 131072], [3254779904, 1, 4162781184, 1, 4162781184, 0, 131072], [2181038080, 1, 4162912256, 1, 4162912256, 0, 131072], [3254779904, 1, 4163043328, 1, 4163043328, 0, 131072], [2181038080, 1, 4227858432, 1, 4227858432, 0, 4194304]] is too long
from schema $id: http://devicetree.org/schemas/pci/host-generic-pci.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: ethernet@0,0:compatible: ['fsl,enetc'] does not contain items matching the given schema
from schema $id: http://devicetree.org/schemas/pci/host-generic-pci.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: ethernet@0,1:compatible: ['fsl,enetc'] does not contain items matching the given schema
from schema $id: http://devicetree.org/schemas/pci/host-generic-pci.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: ethernet@0,2:compatible: ['fsl,enetc'] does not contain items matching the given schema
from schema $id: http://devicetree.org/schemas/pci/host-generic-pci.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: mdio@0,3:compatible: ['fsl,enetc-mdio'] does not contain items matching the given schema
from schema $id: http://devicetree.org/schemas/pci/host-generic-pci.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: ethernet@0,4:compatible: ['fsl,enetc-ptp'] does not contain items matching the given schema
from schema $id: http://devicetree.org/schemas/pci/host-generic-pci.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: ethernet-switch@0,5:interrupts:0:0: 0 is not one of [1, 2, 3, 4]
from schema $id: http://devicetree.org/schemas/pci/host-generic-pci.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: ethernet-switch@0,5:interrupts:0: [0, 95, 4] is too long
from schema $id: http://devicetree.org/schemas/pci/host-generic-pci.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: ethernet@0,6:compatible: ['fsl,enetc'] does not contain items matching the given schema
from schema $id: http://devicetree.org/schemas/pci/host-generic-pci.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: rcec@1f,0:interrupts:0:0: 0 is not one of [1, 2, 3, 4]
from schema $id: http://devicetree.org/schemas/pci/host-generic-pci.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: rcec@1f,0:interrupts:0: [0, 94, 4] is too long
from schema $id: http://devicetree.org/schemas/pci/host-generic-pci.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'bus-range', 'device_type', 'ethernet-switch@0,5', 'ethernet@0,0', 'ethernet@0,1', 'ethernet@0,2', 'ethernet@0,4', 'ethernet@0,6', 'mdio@0,3', 'msi-map', 'ranges', 'rcec@1f,0' were unexpected)
from schema $id: http://devicetree.org/schemas/pci/host-generic-pci.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: ethernet@0,0:compatible: ['fsl,enetc'] does not contain items matching the given schema
from schema $id: http://devicetree.org/schemas/pci/pci-bus-common.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: ethernet@0,1:compatible: ['fsl,enetc'] does not contain items matching the given schema
from schema $id: http://devicetree.org/schemas/pci/pci-bus-common.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: ethernet@0,2:compatible: ['fsl,enetc'] does not contain items matching the given schema
from schema $id: http://devicetree.org/schemas/pci/pci-bus-common.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: mdio@0,3:compatible: ['fsl,enetc-mdio'] does not contain items matching the given schema
from schema $id: http://devicetree.org/schemas/pci/pci-bus-common.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: ethernet@0,4:compatible: ['fsl,enetc-ptp'] does not contain items matching the given schema
from schema $id: http://devicetree.org/schemas/pci/pci-bus-common.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: ethernet-switch@0,5:interrupts:0:0: 0 is not one of [1, 2, 3, 4]
from schema $id: http://devicetree.org/schemas/pci/pci-bus-common.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: ethernet-switch@0,5:interrupts:0: [0, 95, 4] is too long
from schema $id: http://devicetree.org/schemas/pci/pci-bus-common.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: ethernet@0,6:compatible: ['fsl,enetc'] does not contain items matching the given schema
from schema $id: http://devicetree.org/schemas/pci/pci-bus-common.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: rcec@1f,0:interrupts:0:0: 0 is not one of [1, 2, 3, 4]
from schema $id: http://devicetree.org/schemas/pci/pci-bus-common.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: pcie@1f0000000: rcec@1f,0:interrupts:0: [0, 94, 4] is too long
from schema $id: http://devicetree.org/schemas/pci/pci-bus-common.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pcie@1f0000000/ethernet@0,0: failed to match any schema with compatible: ['fsl,enetc']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pcie@1f0000000/ethernet@0,1: failed to match any schema with compatible: ['fsl,enetc']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pcie@1f0000000/ethernet@0,2: failed to match any schema with compatible: ['fsl,enetc']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pcie@1f0000000/mdio@0,3: failed to match any schema with compatible: ['fsl,enetc-mdio']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pcie@1f0000000/ethernet@0,4: failed to match any schema with compatible: ['fsl,enetc-ptp']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pcie@1f0000000/ethernet@0,6: failed to match any schema with compatible: ['fsl,enetc']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/ierb@1f0800000: failed to match any schema with compatible: ['fsl,ls1028a-enetc-ierb']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pwm@2800000: failed to match any schema with compatible: ['fsl,vf610-ftm-pwm']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pwm@2810000: failed to match any schema with compatible: ['fsl,vf610-ftm-pwm']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pwm@2820000: failed to match any schema with compatible: ['fsl,vf610-ftm-pwm']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pwm@2830000: failed to match any schema with compatible: ['fsl,vf610-ftm-pwm']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pwm@2840000: failed to match any schema with compatible: ['fsl,vf610-ftm-pwm']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pwm@2850000: failed to match any schema with compatible: ['fsl,vf610-ftm-pwm']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pwm@2860000: failed to match any schema with compatible: ['fsl,vf610-ftm-pwm']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/pwm@2870000: failed to match any schema with compatible: ['fsl,vf610-ftm-pwm']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: power-controller@1e34040: '#power-domain-cells' is a required property
from schema $id: http://devicetree.org/schemas/power/power-domain.yaml#
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/power-controller@1e34040: failed to match any schema with compatible: ['fsl,ls1028a-rcpm', 'fsl,qoriq-rcpm-2.1+']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/power-controller@1e34040: failed to match any schema with compatible: ['fsl,ls1028a-rcpm', 'fsl,qoriq-rcpm-2.1+']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/timer@2800000: failed to match any schema with compatible: ['fsl,ls1028a-ftm-alarm']
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dtb: /soc/timer@2810000: failed to match any schema with compatible: ['fsl,ls1028a-ftm-alarm']
_______________________________________________
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 v12 0/7] drm/meson: add support for MIPI DSI Display
From: Rob Herring @ 2024-04-03 14:15 UTC (permalink / raw)
To: Neil Armstrong
Cc: dri-devel, Kevin Hilman, linux-clk, David Airlie, Conor Dooley,
Maxime Ripard, Krzysztof Kozlowski, Martin Blumenstingl,
Michael Turquette, linux-arm-kernel, Nicolas Belin, Stephen Boyd,
linux-amlogic, Thomas Zimmermann, Conor Dooley, Daniel Vetter,
linux-kernel, devicetree, Jerome Brunet, Maarten Lankhorst,
Jagan Teki, Lukas F. Hartmann
In-Reply-To: <20240403-amlogic-v6-4-upstream-dsi-ccf-vim3-v12-0-99ecdfdc87fc@linaro.org>
On Wed, 03 Apr 2024 09:46:31 +0200, Neil Armstrong wrote:
> The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a),
> with a custom glue managing the IP resets, clock and data input similar to the DW-HDMI
> glue on the same Amlogic SoCs.
>
> This is a follow-up of v5 now the DRM patches are applied, the clk & DT changes
> remains for a full DSI support on G12A & SM1 platforms.
>
> The DW-MIPI-DSI transceiver + D-PHY are clocked by the GP0 PLL, and the ENCL encoder + VIU
> pixel reader by the VCLK2 clock using the HDMI PLL.
>
> The DW-MIPI-DSI transceiver gets this pixel stream as input clocked with the VCLK2 clock.
>
> An optional "MEAS" clock can be enabled to measure the delay between each vsync feeding the
> DW-MIPI-DSI transceiver.
>
> The clock setup has been redesigned to use CCF, a common PLL (GP0) and the VCLK2 clock
> path for DSI in preparation of full CCF support and possibly dual display with HDMI.
>
> The change from v5 is that now we use a "VCLK" driver instead of notifier and rely
> on CLK_SET_RATE_GATE to ensure the VCLK gate operation are called.
>
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
> Changes in v12:
> - fix parameters alignment in patch 2
> - update g12a_mipi_dsi_pxclk_div_table comment with jerome's suggestions
> - fix dtbs overlay build, fix missed v11... thx khadas for reporting it off-list & testing
> - Link to v11: https://lore.kernel.org/r/20240325-amlogic-v6-4-upstream-dsi-ccf-vim3-v11-0-04f55de44604@linaro.org
>
> Changes in v11:
> - Rebased on v6.9-rc1
> - Fixed overlay handling/creation
> - Link to v10: https://lore.kernel.org/r/20240205-amlogic-v6-4-upstream-dsi-ccf-vim3-v10-0-dc06073d5330@linaro.org
>
> Changes in v10:
> - Rename regmap_vclk to meson_clk and add _gate for the gate
> - Move COMMON_CLK_MESON_VCLK to following patch
> - Remove CLK_SET_RATE_PARENT from g12a_vclk2_sel, keep it only on mipi_dsi_pxclk_sel
> - Add more info on commit message to specify how clock setup is designed
> - Remove forgotten CLK_IGNORE_UNUSED on g12a_vclk2_input
> - Remove useless CLK_SET_RATE_PARENT on g12a_vclk2_div to stop propagatting rate _after_ vclk2_div
> - Remove invalid CLK_SET_RATE_GATE on g12a_vclk2 since it's not a divider...
> - Drop already applied patches
> - move Khadas TS050 changes as an overlay
> - Link to v9: https://lore.kernel.org/r/20231124-amlogic-v6-4-upstream-dsi-ccf-vim3-v9-0-95256ed139e6@linaro.org
>
> Changes in v9:
> - Colledte reviewed-bys
> - Fixed patches 2 & 4, commit messages and bindings format
> - Link to v8: https://lore.kernel.org/r/20231109-amlogic-v6-4-upstream-dsi-ccf-vim3-v8-0-81e4aeeda193@linaro.org
>
> Changes in v8:
> - Switch vclk clk driver to parm as requested by Jerome
> - Added bindings fixes to amlogic,meson-axg-mipi-pcie-analog & amlogic,g12a-mipi-dphy-analog
> - Fixed DT errors in vim3 example and MNT Reform DT
> - Rebased on next-20231107, successfully tested on VIM3L
> - Link to v7: https://lore.kernel.org/r/20230803-amlogic-v6-4-upstream-dsi-ccf-vim3-v7-0-762219fc5b28@linaro.org
>
> Changes in v7:
> - Added review tags
> - Fixed patch 5 thanks to George
> - Link to v6: https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v6-0-fd2ac9845472@linaro.org
>
> Changes in v6:
> - dropped applied DRM patches
> - dropped clk private prefix patches
> - rebased on top of 20230607-topic-amlogic-upstream-clkid-public-migration-v2-0-38172d17c27a@linaro.org
> - re-ordered/cleaned ENCL patches to match clkid public migration
> - Added new "vclk" driver
> - uses vclk driver instead of notifier
> - cleaned VCLK2 clk flags
> - add px_clk gating from DSI driver
> - Link to v5: https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v5-0-56eb7a4d5b8e@linaro.org
>
> Changes in v5:
> - Aded PRIV all the G12 internal clk IDS to simplify public exposing
> - Fixed the DSI bindings
> - Fixed the DSI HSYNC/VSYNC polarity handling
> - Fixed the DSI clock setup
> - Fixed the DSI phy timings
> - Dropped components for DSI, only keeping it for HDMI
> - Added MNT Reform 2 CM4 DT
> - Dropped already applied PHY fix
> - Link to v4: https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v4-0-2592c29ea263@linaro.org
>
> Changes from v3 at [3]:
> - switched all clk setup via CCF
> - using single PLL for DSI controller & ENCL encoder
> - added ENCL clocks to CCF
> - make the VCLK2 clocks configuration by CCF
> - fixed probe/bind of DSI controller to work with panels & bridges
> - added bit_clk to controller to it can setup the BIT clock aswell
> - added fix for components unbind
> - added fix for analog phy setup value
> - added TS050 timings fix
> - dropped previous clk control patch
>
> Changes from v2 at [2]:
> - Fixed patch 3
> - Added reviews from Jagan
> - Rebased on v5.19-rc1
>
> Changes from v1 at [1]:
> - fixed DSI host bindings
> - add reviewed-by tags for bindings
> - moved magic values to defines thanks to Martin's searches
> - added proper prefixes to defines
> - moved phy_configure to phy_init() dw-mipi-dsi callback
> - moved phy_on to a new phy_power_on() dw-mipi-dsi callback
> - correctly return phy_init/configure errors to callback returns
>
> [1] https://lore.kernel.org/r/20200907081825.1654-1-narmstrong@baylibre.com
> [2] https://lore.kernel.org/r/20220120083357.1541262-1-narmstrong@baylibre.com
> [3] https://lore.kernel.org/r/20220617072723.1742668-1-narmstrong@baylibre.com
>
> ---
> Neil Armstrong (7):
> dt-bindings: arm: amlogic: Document the MNT Reform 2 CM4 adapter with a BPI-CM4 Module
> clk: meson: add vclk driver
> clk: meson: g12a: make VCLK2 and ENCL clock path configurable by CCF
> drm/meson: gate px_clk when setting rate
> arm64: meson: g12-common: add the MIPI DSI nodes
> arm64: meson: khadas-vim3l: add TS050 DSI panel overlay
> arm64: dts: amlogic: meson-g12b-bananapi-cm4: add support for MNT Reform2 with CM4 adaper
>
> Documentation/devicetree/bindings/arm/amlogic.yaml | 1 +
> arch/arm64/boot/dts/amlogic/Makefile | 5 +
> arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 70 ++++
> .../meson-g12b-bananapi-cm4-mnt-reform2.dts | 384 +++++++++++++++++++++
> .../boot/dts/amlogic/meson-khadas-vim3-ts050.dtso | 108 ++++++
> drivers/clk/meson/Kconfig | 5 +
> drivers/clk/meson/Makefile | 1 +
> drivers/clk/meson/g12a.c | 76 ++--
> drivers/clk/meson/vclk.c | 141 ++++++++
> drivers/clk/meson/vclk.h | 51 +++
> drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 7 +
> 11 files changed, 829 insertions(+), 20 deletions(-)
> ---
> base-commit: 4cece764965020c22cff7665b18a012006359095
> change-id: 20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-b8e5217e1f4a
>
> Best regards,
> --
> Neil Armstrong <neil.armstrong@linaro.org>
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb' for 20240403-amlogic-v6-4-upstream-dsi-ccf-vim3-v12-0-99ecdfdc87fc@linaro.org:
arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb: /soc/bus@ff600000/bus@42000/clock-controller@0: failed to match any schema with compatible: ['amlogic,g12a-audio-clkc']
arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb: /soc/bus@ff600000/bus@42000/audio-controller@744: failed to match any schema with compatible: ['amlogic,g12a-tohdmitx']
arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb: sys-ctrl@0: '#address-cells', '#size-cells', 'ranges' do not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml#
arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb: sound: Unevaluated properties are not allowed ('assigned-clock-parents', 'assigned-clock-rates', 'assigned-clocks' were unexpected)
from schema $id: http://devicetree.org/schemas/sound/amlogic,axg-sound-card.yaml#
arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dtb: sound: 'anyOf' conditional failed, one must be fixed:
'clocks' is a required property
'#clock-cells' is a required property
from schema $id: http://devicetree.org/schemas/clock/clock.yaml#
_______________________________________________
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 02/10] perf/alibaba_uncore_drw: Avoid placing cpumask var on stack
From: Mark Rutland @ 2024-04-03 14:16 UTC (permalink / raw)
To: Dawei Li
Cc: will, yury.norov, linux, xueshuai, renyu.zj, yangyicong,
jonathan.cameron, andersson, konrad.dybcio, linux-arm-kernel,
linux-kernel, linux-arm-msm
In-Reply-To: <20240403125109.2054881-3-dawei.li@shingroup.cn>
On Wed, Apr 03, 2024 at 08:51:01PM +0800, Dawei Li wrote:
> For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
> variable on stack is not recommended since it can cause potential stack
> overflow.
>
> Instead, kernel code should always use *cpumask_var API(s) to allocate
> cpumask var in config-neutral way, leaving allocation strategy to
> CONFIG_CPUMASK_OFFSTACK.
>
> But dynamic allocation in cpuhp's teardown callback is somewhat problematic
> for if allocation fails(which is unlikely but still possible):
> - If -ENOMEM is returned to caller, kernel crashes for non-bringup
> teardown;
> - If callback pretends nothing happened and returns 0 to caller, it may
> trap system into an in-consisitent/compromised state;
>
> Use newly-introduced cpumask_any_and_but() to address all issues above.
> It eliminates usage of temporary cpumask var in generic way, no matter how
> the cpumask var is allocated.
>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Dawei Li <dawei.li@shingroup.cn>
I don't think we need to explain all the pitfalls of the approach we haven't
taken. Could we please simplify this down to:
Could we please get rid of the bit that says we should "always use the
*cpumask_var API(s)", and simplify the commit message down to:
| perf/alibaba_uncore_drw: Avoid placing cpumask on the stack
|
| In general it's preferable to avoid placing cpumasks on the stack, as
| for large values of NR_CPUS these can consume significant amounts of
| stack space and make stack overflows more likely.
|
| Use cpumask_any_and_but() to avoid the need for a temporary cpumask on
| the stack.
The logic looks good to me, so with that commit message:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
> drivers/perf/alibaba_uncore_drw_pmu.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/perf/alibaba_uncore_drw_pmu.c b/drivers/perf/alibaba_uncore_drw_pmu.c
> index a9277dcf90ce..d4d14b65c4a5 100644
> --- a/drivers/perf/alibaba_uncore_drw_pmu.c
> +++ b/drivers/perf/alibaba_uncore_drw_pmu.c
> @@ -746,18 +746,14 @@ static int ali_drw_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
> struct ali_drw_pmu_irq *irq;
> struct ali_drw_pmu *drw_pmu;
> unsigned int target;
> - int ret;
> - cpumask_t node_online_cpus;
>
> irq = hlist_entry_safe(node, struct ali_drw_pmu_irq, node);
> if (cpu != irq->cpu)
> return 0;
>
> - ret = cpumask_and(&node_online_cpus,
> - cpumask_of_node(cpu_to_node(cpu)), cpu_online_mask);
> - if (ret)
> - target = cpumask_any_but(&node_online_cpus, cpu);
> - else
> + target = cpumask_any_and_but(cpumask_of_node(cpu_to_node(cpu)),
> + cpu_online_mask, cpu);
> + if (target >= nr_cpu_ids)
> target = cpumask_any_but(cpu_online_mask, cpu);
>
> if (target >= nr_cpu_ids)
> --
> 2.27.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 0/7] mmc/wifi/bluetooth: store owner from modules with sdio_register_driver()
From: Krzysztof Kozlowski @ 2024-04-03 14:16 UTC (permalink / raw)
To: Ulf Hansson, Marcel Holtmann, Luiz Augusto von Dentz,
Matthias Brugger, AngeloGioacchino Del Regno, Kalle Valo,
Jeff Johnson, Arend van Spriel, Brian Norris, Francesco Dolcini,
Jérôme Pouiller
Cc: linux-mmc, linux-bluetooth, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-wireless, ath10k, brcm80211,
brcm80211-dev-list.pdl, Krzysztof Kozlowski, Jeff Johnson,
Francesco Dolcini
Changes in v2:
1. Add "wifi: ath10k: sdio: simplify module initialization" patch, from
my other patchset to avoid conflicts.
2. Add Acks/Rb tags.
3. Drop applied SDIO patch, which was the dependency for the rest
cleanups.
4. Update subjects according to feedback.
- Link to v1: https://lore.kernel.org/r/20240329-module-owner-sdio-v1-0-e4010b11ccaa@linaro.org
Merging
=======
With Acks from Kalle, please take entire set via mmc/sdio.
Description
===========
Modules registering driver with sdio_register_driver() might
forget to set .owner field.
Solve the problem by moving this task away from the drivers to the core
code, just like we did for platform_driver in commit 9447057eaff8
("platform_device: use a macro instead of platform_driver_register").
Best regards,
Krzysztof
---
Krzysztof Kozlowski (7):
Bluetooth: btmrvl_sdio: drop driver owner initialization
Bluetooth: btmtksdio: drop driver owner initialization
wifi: ath10k: sdio: simplify module initialization
wifi: ath10k: sdio: drop driver owner initialization
wifi: brcm80211: drop driver owner initialization
wifi: mwifiex: drop driver owner initialization
wifi: wfx: drop driver owner initialization
drivers/bluetooth/btmrvl_sdio.c | 1 -
drivers/bluetooth/btmtksdio.c | 1 -
drivers/net/wireless/ath/ath10k/sdio.c | 21 +--------------------
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 -
drivers/net/wireless/marvell/mwifiex/sdio.c | 1 -
drivers/net/wireless/silabs/wfx/bus_sdio.c | 1 -
6 files changed, 1 insertion(+), 25 deletions(-)
---
base-commit: 7d860d3177a745017d38b37bc2bff2f090631148
change-id: 20240329-module-owner-sdio-abd5de3f1d74
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 5/7] wifi: brcm80211: drop driver owner initialization
From: Krzysztof Kozlowski @ 2024-04-03 14:16 UTC (permalink / raw)
To: Ulf Hansson, Marcel Holtmann, Luiz Augusto von Dentz,
Matthias Brugger, AngeloGioacchino Del Regno, Kalle Valo,
Jeff Johnson, Arend van Spriel, Brian Norris, Francesco Dolcini,
Jérôme Pouiller
Cc: linux-mmc, linux-bluetooth, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-wireless, ath10k, brcm80211,
brcm80211-dev-list.pdl, Krzysztof Kozlowski
In-Reply-To: <20240403-module-owner-sdio-v2-0-ae46d6b955eb@linaro.org>
Core in sdio_register_driver() already sets the .owner, so driver does
not need to.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
Depends on the patch in mmc tree.
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 00679a990e3d..13391c2d82aa 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -1238,7 +1238,6 @@ static struct sdio_driver brcmf_sdmmc_driver = {
.name = KBUILD_MODNAME,
.id_table = brcmf_sdmmc_ids,
.drv = {
- .owner = THIS_MODULE,
.pm = pm_sleep_ptr(&brcmf_sdio_pm_ops),
.coredump = brcmf_dev_coredump,
},
--
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
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