* [PATCH 1/9] arm64: dts: rockchip: Add cpu regulators and vcc5v0_sys to Khadas Edge 2
From: efectn @ 2024-03-30 11:25 UTC (permalink / raw)
To: heiko
Cc: conor+dt, devicetree, efectn, krzysztof.kozlowski+dt,
linux-arm-kernel, linux-kernel, linux-rockchip, robh+dt,
sebastian.reichel
In-Reply-To: <5a7bd2cd8703e51382abfc11242de59d45286477.1708381247.git.efectn@protonmail.com>
Hi Heiko,
Sorry if i bother you. Can you review the series? If there is a problem i will send the v2.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/4] kprobes: Remove core dependency on modules
From: Jarkko Sakkinen @ 2024-03-30 11:32 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Mark Rutland, linux-kernel, agordeev, anil.s.keshavamurthy, aou,
bp, catalin.marinas, dave.hansen, davem, gor, hca, jcalvinowens,
linux-arm-kernel, mingo, mpe, naveen.n.rao, palmer, paul.walmsley,
tglx, will
In-Reply-To: <20240328084701.84aacecba30e83a9ce08a6d8@kernel.org>
On Thu Mar 28, 2024 at 1:47 AM EET, Masami Hiramatsu (Google) wrote:
> On Wed, 27 Mar 2024 19:46:50 +0200
> "Jarkko Sakkinen" <jarkko@kernel.org> wrote:
>
> > On Wed Mar 27, 2024 at 2:01 AM EET, Masami Hiramatsu (Google) wrote:
> > > On Tue, 26 Mar 2024 17:38:18 +0000
> > > Mark Rutland <mark.rutland@arm.com> wrote:
> > >
> > > > On Tue, Mar 26, 2024 at 07:13:51PM +0200, Jarkko Sakkinen wrote:
> > > > > On Tue Mar 26, 2024 at 6:36 PM EET, Mark Rutland wrote:
> > > >
> > > > > > +#ifdef CONFIG_MODULES
> > > > > > /* Check if 'p' is probing a module. */
> > > > > > *probed_mod = __module_text_address((unsigned long) p->addr);
> > > > > > if (*probed_mod) {
> > > > > > @@ -1605,6 +1606,8 @@ static int check_kprobe_address_safe(struct kprobe *p,
> > > > > > ret = -ENOENT;
> > > > > > }
> > > > > > }
> > > > > > +#endif
> > > > >
> > > > > This can be scoped a bit more (see v7 of my patch set).
> > > >
> > > > > > +#ifdef CONFIG_MODULES
> > > > > > static nokprobe_inline bool trace_kprobe_module_exist(struct trace_kprobe *tk)
> > > > > > {
> > > > > > char *p;
> > > > > > @@ -129,6 +130,9 @@ static nokprobe_inline bool trace_kprobe_module_exist(struct trace_kprobe *tk)
> > > > > >
> > > > > > return ret;
> > > > > > }
> > > > > > +#else
> > > > > > +#define trace_kprobe_module_exist(tk) false /* aka a module never exists */
> > > > > > +#endif /* CONFIG_MODULES */
> > > > > >
> > > > > > static bool trace_kprobe_is_busy(struct dyn_event *ev)
> > > > > > {
> > > > > > @@ -670,6 +674,7 @@ static int register_trace_kprobe(struct trace_kprobe *tk)
> > > > > > return ret;
> > > > > > }
> > > > > >
> > > > > > +#ifdef CONFIG_MODULES
> > > > > > /* Module notifier call back, checking event on the module */
> > > > > > static int trace_kprobe_module_callback(struct notifier_block *nb,
> > > > > > unsigned long val, void *data)
> > > > > > @@ -699,6 +704,9 @@ static int trace_kprobe_module_callback(struct notifier_block *nb,
> > > > > >
> > > > > > return NOTIFY_DONE;
> > > > > > }
> > > > > > +#else
> > > > > > +#define trace_kprobe_module_callback (NULL)
> > > > > > +#endif /* CONFIG_MODULES */
> > > > >
> > > > > The last two CONFIG_MODULES sections could be combined. This was also in
> > > > > v7.
> > > >
> > > > > Other than lgtm.
> > > >
> > > > Great! I've folded your v7 changes in, and pushed that out to:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=kprobes/without-modules
> > > >
> > > > I'll hold off sending that out to the list until other folk have had a chance
> > > > to comment.
> > >
> > > Yeah, the updated one looks good to me too.
> > >
> > > Thanks!
> >
> > As for RISC-V:
> >
> > Tested-by: Jarkko Sakkinen <jarkko@kernel.org> # arch/riscv
>
> Thank you for testing!
>
> >
> > I'm fine with adding to all patches because it would be hard
> > to place tested-by to any specific patch (e.g. if this was a
> > syscall I would give tested-by just for that patch).
>
> Except for the 1st patch because that is for arm64, right? :)
Right! For that not required :-)
>
> >
> > Just adding disclaimer because depending on subsystem people
> > are more or less strict with this tag :-)
> >
> > BR, Jarkko
>
> Thanks,
BR, Jarkko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [v1 0/3] Add i.MX8Q HSIO PHY driver support
From: Krzysztof Kozlowski @ 2024-03-30 11:55 UTC (permalink / raw)
To: Richard Zhu, vkoul, kishon, robh+dt, krzysztof.kozlowski+dt,
conor+dt, frank.li
Cc: linux-phy, devicetree, linux-arm-kernel, linux-kernel, kernel,
linux-imx
In-Reply-To: <1711699790-16494-1-git-send-email-hongxing.zhu@nxp.com>
On 29/03/2024 09:09, Richard Zhu wrote:
> v1 changes:
> - Rebase to the 6.9-rc1, and constify of_phandle_args in xlate.
> No other changes.
>
I found some RFC of this... confusing so:
1. v1 is the first version. If you send RFC, that RFC is v1, so anything
newer is v2 or whatever.
2. One patchset per 24h. Give people chance to actually review your code.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()
From: Krzysztof Kozlowski @ 2024-03-30 12:18 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Eric Auger,
Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
> Merging
> =======
> All further patches depend on the first amba patch, therefore please ack
> and this should go via one tree.
>
> Description
> ===========
> Modules registering driver with amba_driver_register() often forget to
> set .owner field.
>
> Solve the problem by moving this task away from the drivers to the core
> amba bus code, just like we did for platform_driver in commit
> 9447057eaff8 ("platform_device: use a macro instead of
> platform_driver_register").
>
> Best regards,
I tried to submit this series to Russell patch tracker and failed. This
is ridiculous. It's 2024 and instead of normal process, like every other
maintainer, so b4 or Patchwork, we have some unusable system rejecting
standard patches.
First, it depends some weird, duplicated signed-off-by's. Second it
submitting patch-by-patch, all with clicking on some web (!!!) interface.
I did it, clicked 19 times and system was happy... but then on email
said the patches were rejected. Couldn't tell it after submitting first
patch via the web?
That's the response:
-------------
Your patch has not been logged because:
Error: Please supply a summary subject line briefly describing
your patch.
Error: Please supply a "KernelVersion: " tag after "PATCH FOLLOWS" or
"---".
Error: the patch you are submitting has one or more missing or incorrect
Signed-off-by lines:
- author signoff <krzkreg@gmail.com> is missing.
Please see the file Documentation/SubmittingPatches, section 11
for details on signing off patches.
Please see https://www.armlinux.org.uk/developer/patches/info.shtml
for more information.
-------------
This is unbelievable waste of time. I am not going to use this tracker.
It's huge obstacle and huge waste of submitters time.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()
From: Krzysztof Kozlowski @ 2024-03-30 12:19 UTC (permalink / raw)
To: Suzuki K Poulose, Russell King, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Eric Auger,
Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <d8fa8e1a-b2ce-4d91-9ab5-ad1b160111c6@arm.com>
On 27/03/2024 10:22, Suzuki K Poulose wrote:
> On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
>> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>>> Hi Krzysztof
>>>
>>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>>> Merging
>>>> =======
>>>> All further patches depend on the first amba patch, therefore please ack
>>>> and this should go via one tree.
>>>
>>> Are you able to provide a stable branch with these patches once you pull
>>
>> I doubt I will be merging this. I think amba code goes through Russell.
>>
>>> them in to "one tree" here ? We have changes coming up in the coresight
>>> tree, which would conflict with the changes here (horribly).
>>>
>>
>> You mean conflict with coresight conversion to platform driver? Worst
>
> Yes.
>
>> case it is solveable: just drop .owner.
>
> Or, we could merge the CoreSight changes (as they are really not
> affected by the problem this series is trying to address) after the
> base changes land in AMBA, via the CoreSight tree.
I'll provide you a stable branch to fetch. I was defeated by Russell's
patch tracking system.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [External] Re: [PATCH bpf-next v2 1/9] bpf: tracing: add support to record and check the accessed args
From: Steven Rostedt @ 2024-03-30 12:27 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: 梦龙董, Alexei Starovoitov, Jiri Olsa,
Andrii Nakryiko, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Eddy Z, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, David S. Miller,
David Ahern, Dave Hansen, X86 ML, Mathieu Desnoyers,
Quentin Monnet, bpf, linux-arm-kernel, LKML, linux-riscv,
linux-s390, Network Development, linux-trace-kernel,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32
In-Reply-To: <CAEf4BzYgzOti+Hfdn3SUCjuofGedXRSGApVDD+K2TdG6oNE-pw@mail.gmail.com>
On Fri, 29 Mar 2024 16:28:33 -0700
Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> I thought I'll just ask instead of digging through code, sorry for
> being lazy :) Is there any way to pass pt_regs/ftrace_regs captured
> before function execution to a return probe (fexit/kretprobe)? I.e.,
> how hard is it to pass input function arguments to a kretprobe? That's
> the biggest advantage of fexit over kretprobe, and if we can make
> these original pt_regs/ftrace_regs available to kretprobe, then
> multi-kretprobe will effectively be this multi-fexit.
This should be possible with the updates that Masami is doing with the
fgraph code.
-- Steve
_______________________________________________
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] Add support for Emcraft Systems NavQ+ kit
From: Gilles Talis @ 2024-03-30 13:34 UTC (permalink / raw)
To: devicetree, imx, linux-arm-kernel
Cc: conor+dt, krzysztof.kozlowski+dt, robh, shawnguo, festevam, alex,
andrew, Gilles Talis
Hello
This series adds a device tree file for the Emcraft Systems NavQ+ kit [1]
The first patch adds a new vendor prefix for Emcraft Systems
The second one adds the board to the arm/fsl.yaml DT bindings.
Last patch adds device tree file for the kit.
[1] https://www.emcraft.com/products/1222
Changes in v2:
- Add Acked-by review tags
- Fixed device tree warnings reported by dtbs_check
- Reworked leds node
- Remove unused i2c6 pinctrl entry
- Removed unused regulator node in Ethernet entry
- Link to v1: https://lore.kernel.org/imx/20240328202320.187596-1-gilles.talis@gmail.com/
---
Gilles Talis (3):
dt-bindings: vendor-prefixes: Add Emcraft Systems
dt-bindings: arm: Add Emcraft Systems i.MX8M Plus NavQ+ Kit
arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit
.../devicetree/bindings/arm/fsl.yaml | 1 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../arm64/boot/dts/freescale/imx8mp-navqp.dts | 424 ++++++++++++++++++
4 files changed, 428 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
base-commit: 4cece764965020c22cff7665b18a012006359095
--
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
* [PATCH v2 1/3] dt-bindings: vendor-prefixes: Add Emcraft Systems
From: Gilles Talis @ 2024-03-30 13:34 UTC (permalink / raw)
To: devicetree, imx, linux-arm-kernel
Cc: conor+dt, krzysztof.kozlowski+dt, robh, shawnguo, festevam, alex,
andrew, Gilles Talis, Krzysztof Kozlowski
In-Reply-To: <20240330133410.41408-1-gilles.talis@gmail.com>
Add an entry for Emcraft Systems (https://www.emcraft.com/)
Signed-off-by: Gilles Talis <gilles.talis@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index b97d298b3eb6..8b978c6f1dfd 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -438,6 +438,8 @@ patternProperties:
description: Dongguan EmbedFire Electronic Technology Co., Ltd.
"^embest,.*":
description: Shenzhen Embest Technology Co., Ltd.
+ "^emcraft,.*":
+ description: Emcraft Systems
"^emlid,.*":
description: Emlid, Ltd.
"^emmicro,.*":
--
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 v2 3/3] arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit
From: Gilles Talis @ 2024-03-30 13:34 UTC (permalink / raw)
To: devicetree, imx, linux-arm-kernel
Cc: conor+dt, krzysztof.kozlowski+dt, robh, shawnguo, festevam, alex,
andrew, Gilles Talis
In-Reply-To: <20240330133410.41408-1-gilles.talis@gmail.com>
The Emcraft Systems NavQ+ kit is a mobile robotics platform
based on NXP i.MX8 MPlus SoC.
The following interfaces and devices are enabled:
- eMMC
- Gigabit Ethernet
- RTC
- SD-Card
- UART console
Signed-off-by: Gilles Talis <gilles.talis@gmail.com>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../arm64/boot/dts/freescale/imx8mp-navqp.dts | 424 ++++++++++++++++++
2 files changed, 425 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 045250d0a040..bf99864c0bc4 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -166,6 +166,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-pdk3.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-icore-mx8mp-edimm2.2.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-msc-sm2s-ep1.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-navqp.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-phyboard-pollux-rdk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-hdmi.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-lt6.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts b/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
new file mode 100644
index 000000000000..5fd1614982cd
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
@@ -0,0 +1,424 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2021 Emcraft Systems
+ * Copyright 2024 Gilles Talis <gilles.talis@gmail.com>
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+#include "imx8mp.dtsi"
+
+/ {
+ model = "Emcraft Systems i.MX8MPlus NavQ+ Kit";
+ compatible = "emcraft,imx8mp-navqp", "fsl,imx8mp";
+
+ chosen {
+ stdout-path = &uart2;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_led>;
+
+ led-0 {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio3 16 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+ regulator-name = "VSD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ startup-delay-us = <100>;
+ off-on-delay-us = <12000>;
+ };
+};
+
+&A53_0 {
+ cpu-supply = <&buck2>;
+};
+
+&A53_1 {
+ cpu-supply = <&buck2>;
+};
+
+&A53_2 {
+ cpu-supply = <&buck2>;
+};
+
+&A53_3 {
+ cpu-supply = <&buck2>;
+};
+
+&eqos {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_eqos>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy0>;
+ status = "okay";
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ reset-gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <1000>;
+ reset-deassert-us = <10000>;
+ qca,disable-smarteee;
+ qca,disable-hibernation-mode;
+ };
+ };
+};
+
+&i2c1 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+
+ pmic@25 {
+ compatible = "nxp,pca9450c";
+ reg = <0x25>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pmic>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+ regulators {
+ BUCK1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <2187500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck2: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <2187500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ nxp,dvs-run-voltage = <950000>;
+ nxp,dvs-standby-voltage = <850000>;
+ };
+
+ BUCK4 {
+ regulator-name = "BUCK4";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ BUCK5 {
+ regulator-name = "BUCK5";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ BUCK6 {
+ regulator-name = "BUCK6";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <1600000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO2 {
+ regulator-name = "LDO2";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1150000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO3 {
+ regulator-name = "LDO3";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO4 {
+ regulator-name = "LDO4";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ LDO5 {
+ regulator-name = "LDO5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+};
+
+&i2c3 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+};
+
+&i2c4 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c4>;
+ status = "okay";
+
+ rtc@53 {
+ compatible = "nxp,pcf2131";
+ reg = <0x53>;
+ };
+};
+
+&uart2 {
+ /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+/* SD Card */
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ bus-width = <4>;
+ status = "okay";
+};
+
+/* eMMC */
+&usdhc3 {
+ assigned-clocks = <&clk IMX8MP_CLK_USDHC3>;
+ assigned-clock-rates = <400000000>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_eqos: eqosgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_ENET_MDC__ENET_QOS_MDC 0x3
+ MX8MP_IOMUXC_ENET_MDIO__ENET_QOS_MDIO 0x3
+ MX8MP_IOMUXC_ENET_RD0__ENET_QOS_RGMII_RD0 0x91
+ MX8MP_IOMUXC_ENET_RD1__ENET_QOS_RGMII_RD1 0x91
+ MX8MP_IOMUXC_ENET_RD2__ENET_QOS_RGMII_RD2 0x91
+ MX8MP_IOMUXC_ENET_RD3__ENET_QOS_RGMII_RD3 0x91
+ MX8MP_IOMUXC_ENET_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 0x91
+ MX8MP_IOMUXC_ENET_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x91
+ MX8MP_IOMUXC_ENET_TD0__ENET_QOS_RGMII_TD0 0x1f
+ MX8MP_IOMUXC_ENET_TD1__ENET_QOS_RGMII_TD1 0x1f
+ MX8MP_IOMUXC_ENET_TD2__ENET_QOS_RGMII_TD2 0x1f
+ MX8MP_IOMUXC_ENET_TD3__ENET_QOS_RGMII_TD3 0x1f
+ MX8MP_IOMUXC_ENET_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x1f
+ MX8MP_IOMUXC_ENET_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x1f
+ MX8MP_IOMUXC_SAI2_RXC__GPIO4_IO22 0x110
+ >;
+ };
+
+ pinctrl_gpio_led: gpioledgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_READY_B__GPIO3_IO16 0x19
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C1_SCL__I2C1_SCL 0x400001c3
+ MX8MP_IOMUXC_I2C1_SDA__I2C1_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL 0x400001c3
+ MX8MP_IOMUXC_I2C2_SDA__I2C2_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C3_SCL__I2C3_SCL 0x400001c3
+ MX8MP_IOMUXC_I2C3_SDA__I2C3_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c4: i2c4grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C4_SCL__I2C4_SCL 0x400001c3
+ MX8MP_IOMUXC_I2C4_SDA__I2C4_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_pmic: pmicgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
+ >;
+ };
+
+ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_RESET_B__GPIO2_IO19 0x41
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX 0x49
+ MX8MP_IOMUXC_UART2_TXD__UART2_DCE_TX 0x49
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x190
+ MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d0
+ MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d0
+ MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d0
+ MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d0
+ MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d0
+ MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc1
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x194
+ MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d4
+ MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d4
+ MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d4
+ MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d4
+ MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d4
+ MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc1
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x196
+ MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d6
+ MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d6
+ MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d6
+ MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d6
+ MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d6
+ MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc1
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD2_CD_B__GPIO2_IO12 0x1c4
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x190
+ MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d0
+ MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d0
+ MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d0
+ MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d0
+ MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d0
+ MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d0
+ MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d0
+ MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d0
+ MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d0
+ MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x190
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x194
+ MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d4
+ MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d4
+ MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d4
+ MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d4
+ MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d4
+ MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d4
+ MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d4
+ MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d4
+ MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d4
+ MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x194
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x196
+ MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d6
+ MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d6
+ MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d6
+ MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d6
+ MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d6
+ MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d6
+ MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d6
+ MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d6
+ MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d6
+ MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x196
+ >;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO02__WDOG1_WDOG_B 0xc6
+ >;
+ };
+};
--
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 v2 2/3] dt-bindings: arm: Add Emcraft Systems i.MX8M Plus NavQ+ Kit
From: Gilles Talis @ 2024-03-30 13:34 UTC (permalink / raw)
To: devicetree, imx, linux-arm-kernel
Cc: conor+dt, krzysztof.kozlowski+dt, robh, shawnguo, festevam, alex,
andrew, Gilles Talis, Krzysztof Kozlowski
In-Reply-To: <20240330133410.41408-1-gilles.talis@gmail.com>
Add DT compatible string for Emcraft NavQ+ kit based on
the i.MX8M Plus SoC from NXP
Signed-off-by: Gilles Talis <gilles.talis@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 0027201e19f8..cec1b31d0792 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1050,6 +1050,7 @@ properties:
- enum:
- beacon,imx8mp-beacon-kit # i.MX8MP Beacon Development Kit
- dmo,imx8mp-data-modul-edm-sbc # i.MX8MP eDM SBC
+ - emcraft,imx8mp-navqp # i.MX8MP Emcraft Systems NavQ+ Kit
- fsl,imx8mp-evk # i.MX8MP EVK Board
- gateworks,imx8mp-gw71xx-2x # i.MX8MP Gateworks Board
- gateworks,imx8mp-gw72xx-2x # i.MX8MP Gateworks Board
--
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 10/10] ARM: Use common uncore PMU capabilities
From: Shawn Guo @ 2024-03-30 14:59 UTC (permalink / raw)
To: Robin Murphy
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Will Deacon, Alexander Shishkin,
Jiri Olsa, Ian Rogers, Adrian Hunter, linux-kernel,
linux-arm-kernel, x86, linux-perf-users, jialong.yang,
Russell King, Shawn Guo, Sascha Hauer
In-Reply-To: <de2646ca1d333cd9286f22ed3a5e8d57d22833b1.1710257512.git.robin.murphy@arm.com>
On Tue, Mar 12, 2024 at 05:34:12PM +0000, Robin Murphy wrote:
> Switch the ARM system PMU drivers over to the new common capabilities,
> allowing to remove all the checks that perf core now takes care of.
>
> CC: Russell King <linux@armlinux.org.uk>
> CC: Shawn Guo <shawnguo@kernel.org>
> CC: Sascha Hauer <s.hauer@pengutronix.de>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> arch/arm/mach-imx/mmdc.c | 16 +---------------
Acked-by: Shawn Guo <shawnguo@kernel.org>
> arch/arm/mm/cache-l2x0-pmu.c | 12 +-----------
> 2 files changed, 2 insertions(+), 26 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mmdc.c b/arch/arm/mach-imx/mmdc.c
> index 444a7eaa320c..806ab6675b37 100644
> --- a/arch/arm/mach-imx/mmdc.c
> +++ b/arch/arm/mach-imx/mmdc.c
> @@ -280,20 +280,6 @@ static int mmdc_pmu_event_init(struct perf_event *event)
> struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
> int cfg = event->attr.config;
>
> - if (event->attr.type != event->pmu->type)
> - return -ENOENT;
> -
> - if (is_sampling_event(event) || event->attach_state & PERF_ATTACH_TASK)
> - return -EOPNOTSUPP;
> -
> - if (event->cpu < 0) {
> - dev_warn(pmu_mmdc->dev, "Can't provide per-task data!\n");
> - return -EOPNOTSUPP;
> - }
> -
> - if (event->attr.sample_period)
> - return -EINVAL;
> -
> if (cfg < 0 || cfg >= MMDC_NUM_COUNTERS)
> return -EINVAL;
>
> @@ -445,7 +431,7 @@ static int mmdc_pmu_init(struct mmdc_pmu *pmu_mmdc,
> .start = mmdc_pmu_event_start,
> .stop = mmdc_pmu_event_stop,
> .read = mmdc_pmu_event_update,
> - .capabilities = PERF_PMU_CAP_NO_EXCLUDE,
> + .capabilities = PERF_PMU_UNCORE_CAPS,
> },
> .mmdc_base = mmdc_base,
> .dev = dev,
> diff --git a/arch/arm/mm/cache-l2x0-pmu.c b/arch/arm/mm/cache-l2x0-pmu.c
> index 993fefdc167a..a2567d953fdb 100644
> --- a/arch/arm/mm/cache-l2x0-pmu.c
> +++ b/arch/arm/mm/cache-l2x0-pmu.c
> @@ -295,16 +295,6 @@ static int l2x0_pmu_event_init(struct perf_event *event)
> {
> struct hw_perf_event *hw = &event->hw;
>
> - if (event->attr.type != l2x0_pmu->type)
> - return -ENOENT;
> -
> - if (is_sampling_event(event) ||
> - event->attach_state & PERF_ATTACH_TASK)
> - return -EINVAL;
> -
> - if (event->cpu < 0)
> - return -EINVAL;
> -
> if (event->attr.config & ~L2X0_EVENT_CNT_CFG_SRC_MASK)
> return -EINVAL;
>
> @@ -524,7 +514,7 @@ static __init int l2x0_pmu_init(void)
> .del = l2x0_pmu_event_del,
> .event_init = l2x0_pmu_event_init,
> .attr_groups = l2x0_pmu_attr_groups,
> - .capabilities = PERF_PMU_CAP_NO_EXCLUDE,
> + .capabilities = PERF_PMU_UNCORE_CAPS,
> };
>
> l2x0_pmu_reset();
> --
> 2.39.2.101.g768bb238c484.dirty
>
_______________________________________________
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 0/2] arm64: dts: fsl-lx2162a-som: add description for rtc
From: Shawn Guo @ 2024-03-30 15:07 UTC (permalink / raw)
To: Josua Mayer
Cc: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20240312-lx2162-rtc-v1-0-1f4cd431b1cf@solid-run.com>
On Tue, Mar 12, 2024 at 08:56:53PM +0100, Josua Mayer wrote:
> Josua Mayer (2):
> arm64: dts: fsl-lx2162a-som: add description for rtc
> arm64: dts: fsl-lx2162a-clearfog: add alias for i2c bus iic6
Applied both, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit
From: Andrew Lunn @ 2024-03-30 16:46 UTC (permalink / raw)
To: Gilles Talis
Cc: devicetree, imx, linux-arm-kernel, conor+dt,
krzysztof.kozlowski+dt, robh, shawnguo, festevam, alex
In-Reply-To: <20240330133410.41408-4-gilles.talis@gmail.com>
> +&eqos {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_eqos>;
> + phy-mode = "rgmii-id";
> + phy-handle = <ðphy0>;
> + status = "okay";
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy0: ethernet-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + reset-gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <1000>;
> + reset-deassert-us = <10000>;
> + qca,disable-smarteee;
> + qca,disable-hibernation-mode;
> + };
> + };
> +};
Thanks for removing the regulator.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit
From: Fabio Estevam @ 2024-03-30 17:03 UTC (permalink / raw)
To: Gilles Talis
Cc: devicetree, imx, linux-arm-kernel, conor+dt,
krzysztof.kozlowski+dt, robh, shawnguo, alex, andrew
In-Reply-To: <20240330133410.41408-4-gilles.talis@gmail.com>
Hi Gilles,
On Sat, Mar 30, 2024 at 10:34 AM Gilles Talis <gilles.talis@gmail.com> wrote:
>
> The Emcraft Systems NavQ+ kit is a mobile robotics platform
> based on NXP i.MX8 MPlus SoC.
>
> The following interfaces and devices are enabled:
> - eMMC
> - Gigabit Ethernet
> - RTC
> - SD-Card
> - UART console
>
> Signed-off-by: Gilles Talis <gilles.talis@gmail.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [External] Re: [PATCH bpf-next v2 1/9] bpf: tracing: add support to record and check the accessed args
From: Jiri Olsa @ 2024-03-30 17:52 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andrii Nakryiko, 梦龙董, Alexei Starovoitov,
Andrii Nakryiko, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Eddy Z, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, David S. Miller,
David Ahern, Dave Hansen, X86 ML, Mathieu Desnoyers,
Quentin Monnet, bpf, linux-arm-kernel, LKML, linux-riscv,
linux-s390, Network Development, linux-trace-kernel,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32
In-Reply-To: <20240330082755.1cbeb8c6@rorschach.local.home>
On Sat, Mar 30, 2024 at 08:27:55AM -0400, Steven Rostedt wrote:
> On Fri, 29 Mar 2024 16:28:33 -0700
> Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> > I thought I'll just ask instead of digging through code, sorry for
> > being lazy :) Is there any way to pass pt_regs/ftrace_regs captured
> > before function execution to a return probe (fexit/kretprobe)? I.e.,
> > how hard is it to pass input function arguments to a kretprobe? That's
> > the biggest advantage of fexit over kretprobe, and if we can make
> > these original pt_regs/ftrace_regs available to kretprobe, then
> > multi-kretprobe will effectively be this multi-fexit.
>
> This should be possible with the updates that Masami is doing with the
> fgraph code.
yes, I have bpf kprobe-multi link support for that [0] (it's on top of
Masami's fprobe-over-fgraph changes) we discussed that in [1]
jirka
[0] https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git/log/?h=bpf/session_data
[1] https://lore.kernel.org/bpf/20240228090242.4040210-1-jolsa@kernel.org/
_______________________________________________
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 00/19] amba: store owner from modules with amba_driver_register()
From: Krzysztof Kozlowski @ 2024-03-30 17:58 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Eric Auger,
Alex Williamson, Krzysztof Kozlowski
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
On Tue, 26 Mar 2024 21:23:30 +0100, Krzysztof Kozlowski wrote:
> Merging
> =======
> All further patches depend on the first amba patch, therefore please ack
> and this should go via one tree.
>
> Description
> ===========
> Modules registering driver with amba_driver_register() often forget to
> set .owner field.
>
> [...]
Applied, thanks!
[01/19] amba: store owner from modules with amba_driver_register()
(no commit info)
[02/19] coresight: cti: drop owner assignment
(no commit info)
[03/19] coresight: catu: drop owner assignment
(no commit info)
[04/19] coresight: etm3x: drop owner assignment
(no commit info)
[05/19] coresight: etm4x: drop owner assignment
(no commit info)
[06/19] coresight: funnel: drop owner assignment
(no commit info)
[07/19] coresight: replicator: drop owner assignment
(no commit info)
[08/19] coresight: etb10: drop owner assignment
(no commit info)
[09/19] coresight: stm: drop owner assignment
(no commit info)
[10/19] coresight: tmc: drop owner assignment
(no commit info)
[11/19] coresight: tpda: drop owner assignment
(no commit info)
[12/19] coresight: tpdm: drop owner assignment
(no commit info)
[13/19] coresight: tpiu: drop owner assignment
(no commit info)
[14/19] i2c: nomadik: drop owner assignment
(no commit info)
[15/19] hwrng: nomadik: drop owner assignment
(no commit info)
[16/19] dmaengine: pl330: drop owner assignment
(no commit info)
[17/19] Input: ambakmi - drop owner assignment
(no commit info)
[18/19] memory: pl353-smc: drop owner assignment
(no commit info)
[19/19] vfio: amba: drop owner assignment
(no commit info)
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
* Re: [PATCH 00/19] amba: store owner from modules with amba_driver_register()
From: Krzysztof Kozlowski @ 2024-03-30 18:00 UTC (permalink / raw)
To: Russell King, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Eric Auger,
Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <171182151736.34189.6433134738765363803.b4-ty@linaro.org>
On 30/03/2024 18:58, Krzysztof Kozlowski wrote:
>
> On Tue, 26 Mar 2024 21:23:30 +0100, Krzysztof Kozlowski wrote:
>> Merging
>> =======
>> All further patches depend on the first amba patch, therefore please ack
>> and this should go via one tree.
>>
>> Description
>> ===========
>> Modules registering driver with amba_driver_register() often forget to
>> set .owner field.
>>
>> [...]
>
> Applied, thanks!
>
> [01/19] amba: store owner from modules with amba_driver_register()
> (no commit info)
Patchset applied here:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt.git/log/?h=for-v6.10/module-owner-amba
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 4/4] dt-bindings: aspeed: Add eSPI controller
From: Krzysztof Kozlowski @ 2024-03-30 18:36 UTC (permalink / raw)
To: Manojkiran Eda, patrick.rudolph, chiawei_wang, ryan_chen,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-mtd
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
miquel.raynal, richard, vigneshr, jk, openbmc, broonie, linux-spi
In-Reply-To: <582c276c-ea2f-456c-9bf9-47e39289a0b6@gmail.com>
On 28/03/2024 12:33, Manojkiran Eda wrote:
>>>>> + description: Controls the flash channel of eSPI hardware
>>>> That explains nothing. Unless you wanted to use here MTD bindings.
>>>>
>>>> This binding did not improve much. I don't understand why this is not
>>>> SPI (nothing in commit msg, nothing in description), what is eSPI,
>>>
>>> eSPI uses Peripheral, Virtual Wire, Out of Band, and Flash Access
>>> channels to communicate different sets of data.
>>
>> And what are these channels? What does it mean a "channel"? Is it just
>> how you organize transfers and classes of devices? Or some sort of
>> addressable instance on the bus?
>>
>
> Yes, an espi channel provides a means to allow multiple independent
> flows of traffic to share the same physical bus. Each of the channels
> has its own dedicated resources such as queue and flow control.
Resources as queue and flow-control? Where are they defined in
Devicetree? Which binding?
>
>> The channels feel like some sort of software or logical concept, not
>> physical. Physical would be endpoint with peripheral. Or flash memory.
>
> A channel is a logical communication pathway or interface between the
> chipset and peripheral devices. The concept of channels in the ESPI
> protocol helps organize and manage different types of communication
> between the chipset and peripherals. Each channel may have its own set
> of protocols, data transfer rates, and supported features, tailored to
> the requirements of the devices it serves.
>
>> How do they fit here?
>
> I am not sure I understand, can you please elaborate ?
All this suggests channel is programming aspect of your device thus does
not have to be represented in DT. I don't know, come with any DT
property to back up your case...
So far I see only interrupts and clocks, but then I would claim these
could be part of parent node.
Rob said it last time: your split of nodes looks artificial and it all
looks like one node.
Your DTS reg like:
reg = <0x0 0x800>,<0x0 0x4000000>;
proves it. I don't know if this is just bug in your code or some silly
DTS just to create fake children. :/
>
>>>
>>> * The *Peripheral* Channel is used for communication between eSPI host
>>> bridge located on the master side and eSPI endpoints located on the
>>> slave side. LPC Host and LPC Peripherals are an example of eSPI host
>>> bridge and eSPI endpoints respectively.
>>> * *Virtual Wire* Channel: The Virtual Wire channel is used to
>>> communicate the state of sideband pins or GPIO tunneled through eSPI
>>> as in-band messages. Serial IRQ interrupts are communicated through
>>> this channel as in-band messages.
>>> * *OOB* Channel: The SMBus packets are tunneled through eSPI as
>>> Out-Of-Band (OOB) messages. The whole SMBus packet is embedded
>>> inside the eSPI OOB message as data.
>>> * *Flash Access* Channel: The Flash Access channel provides a path
>>> allowing the flash components to be shared run-time between chipset
>>> and the eSPI slaves that require flash accesses such as EC (Embedded
>>> Controller) and BMC.
>>
>> Please make binding complete, so define all of the channels.
>
>
> I would like to inquire about the rationale behind this request. Based
Rationale - writing bindings document.
https://elixir.bootlin.com/linux/v6.9-rc1/source/Documentation/devicetree/bindings/writing-bindings.rst#L17
> on previous feedback received from the upstream efforts
> [https://lore.kernel.org/openbmc/HK0PR06MB37798462D17443C697433D7191D09@HK0PR06MB3779.apcprd06.prod.outlook.com/],
> suggestions were made to model the flash channel by utilizing the mtd
> subsystem, the virtual wire channel by utilizing the GPIO subsystem, and
> to consider the OOB channel as a type of i2c device, thereby allowing it
> to be utilized by the existing in-kernel MCTP subsystem, among others.
> My intention was to prioritize upstreaming the flash channel binding,
> along with its driver code, before proceeding to address other channels.
Just to clarify: I don't care about drivers and we do not talk about
them here.
> I am curious to understand if it is a strict requirement to have the
> complete binding upstreamed before addressing the device drivers code.
What if your other "devices" or "channels" are entirely different and
binding would just not work? Or how can we understand the design if you
upstream only part of it?
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm: kasan: clear stale stack poison
From: Russell King (Oracle) @ 2024-03-30 18:36 UTC (permalink / raw)
To: Boy Wu (吳勃誼)
Cc: matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
kasan-dev@googlegroups.com,
angelogioacchino.delregno@collabora.com, linux-mm@kvack.org
In-Reply-To: <6837adc26ed09b9acd6a2239a14014cd3f16c87c.camel@mediatek.com>
On Fri, Mar 29, 2024 at 03:17:39AM +0000, Boy Wu (吳勃誼) wrote:
> Hi Russell:
>
> Kingly ping
I'm afraid I know nowt about KASAN. It was added to ARM32 by others.
I've no idea whether this is correct or not. Can we get someone who
knows KASAN to review this?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
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 v5 1/1] dt-bindings: net: dwmac: Document STM32 property st,ext-phyclk
From: Krzysztof Kozlowski @ 2024-03-30 18:40 UTC (permalink / raw)
To: Christophe Roullier, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Maxime Coquelin, Alexandre Torgue, Richard Cochran,
Jose Abreu, Liam Girdwood, Mark Brown, Marek Vasut
Cc: netdev, devicetree, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20240328140803.324141-2-christophe.roullier@foss.st.com>
On 28/03/2024 15:08, Christophe Roullier wrote:
> The Linux kernel dwmac-stm32 driver currently supports three DT
> properties used to configure whether PHY clock are generated by
> the MAC or supplied to the MAC from the PHY.
>
> Originally there were two properties, st,eth-clk-sel and
> st,eth-ref-clk-sel, each used to configure MAC clocking in
> different bus mode and for different MAC clock frequency.
> Since it is possible to determine the MAC 'eth-ck' clock
> frequency from the clock subsystem and PHY bus mode from
> the 'phy-mode' property, two disparate DT properties are
> no longer required to configure MAC clocking.
>
> Linux kernel commit 1bb694e20839 ("net: ethernet: stmmac: simplify phy modes management for stm32")
> introduced a third, unified, property st,ext-phyclk. This property
> covers both use cases of st,eth-clk-sel and st,eth-ref-clk-sel DT
> properties, as well as a new use case for 25 MHz clock generated
> by the MAC.
>
> The third property st,ext-phyclk is so far undocumented,
> document it.
>
> Below table summarizes the clock requirement and clock sources for
> supported PHY interface modes.
> __________________________________________________________________________
> |PHY_MODE | Normal | PHY wo crystal| PHY wo crystal |No 125Mhz from PHY|
> | | | 25MHz | 50MHz | |
>
> ---------------------------------------------------------------------------
> | MII | - | eth-ck | n/a | n/a |
> | | | st,ext-phyclk | | |
>
> ---------------------------------------------------------------------------
> | GMII | - | eth-ck | n/a | n/a |
> | | | st,ext-phyclk | | |
>
> ---------------------------------------------------------------------------
> | RGMII | - | eth-ck | n/a | eth-ck |
> | | | st,ext-phyclk | | st,eth-clk-sel or|
> | | | | | st,ext-phyclk |
>
> ---------------------------------------------------------------------------
> | RMII | - | eth-ck | eth-ck | n/a |
> | | | st,ext-phyclk | st,eth-ref-clk-sel | |
> | | | | or st,ext-phyclk | |
>
> ---------------------------------------------------------------------------
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com>
Can you please start testing patches *before* sending them?
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 00/13] firmware: qcom: qseecom: convert to using the TZ allocator
From: Bartosz Golaszewski @ 2024-03-30 19:16 UTC (permalink / raw)
To: Maximilian Luz
Cc: Bartosz Golaszewski, Andy Gross, Bjorn Andersson, Konrad Dybcio,
Elliot Berman, Krzysztof Kozlowski, Guru Das Srinagesh,
Andrew Halaney, Alex Elder, Srini Kandagatla, Arnd Bergmann,
linux-arm-msm, linux-kernel, linux-arm-kernel, kernel,
Bartosz Golaszewski
In-Reply-To: <9db0fc7b-f24a-4d76-b8bd-ec577ecba0c6@gmail.com>
On Fri, 29 Mar 2024 20:57:52 +0100, Maximilian Luz
<luzmaximilian@gmail.com> said:
> On 3/29/24 8:46 PM, Bartosz Golaszewski wrote:
>> On Fri, 29 Mar 2024 at 20:39, Maximilian Luz <luzmaximilian@gmail.com> wrote:
>>>
>>> On 3/29/24 8:26 PM, Bartosz Golaszewski wrote:
>>>> On Fri, 29 Mar 2024 at 20:22, Maximilian Luz <luzmaximilian@gmail.com> wrote:
>>>>>
>>>>> On 3/29/24 8:07 PM, Bartosz Golaszewski wrote:
>>>>>>
>>>>>> Both with and without SHM bridge?
>>>>>
>>>>> With CONFIG_QCOM_TZMEM_MODE_GENERIC=y (and the upcoming fix) everything
>>>>> works. With CONFIG_QCOM_TZMEM_MODE_SHMBRIDGE=y things unfortunately
>>>>> still get stuck at boot (regardless of the fix). I think that's
>>>>> happening even before anything efivar related should come up.
>>>>>
>>>>
>>>> This is on X13s? I will get one in 3 weeks. Can you get the bootlog
>>>> somehow? Does the laptop have any serial console?
>>>
>>> Surface Pro X (sc8180x), but it should be similar enough to the X13s in
>>> that regard. At least from what people with access to the X13s told me,
>>> the qseecom stuff seems to behave the same.
>>>
>>> Unfortunately I don't have a direct serial console. Best I have is
>>> USB-serial, but it's not even getting there. I'll have to try and see if
>>> I can get some more info on the screen.
>>>
>>
>> I have access to a sc8180x-primus board, does it make sense to test
>> with this one? If so, could you give me instructions on how to do it?
>
> I guess it's worth a shot.
>
> From what I can tell, there shouldn't be any patches in my tree that
> would conflict with it. So I guess it should just be building it with
> CONFIG_QCOM_TZMEM_MODE_SHMBRIDGE=y and booting.
>
> I am currently testing it on top of a patched v6.8 tree though (but that
> should just contain patches to get the Pro X running). You can find the
> full tree at
>
> https://github.com/linux-surface/kernel/tree/spx/v6.8
>
> The last commit is the fix I mentioned, so you might want to revert
> that, since the shmem issue triggers regardless of that and it prevents
> your series from applying cleanly.
>
> Best regards,
> Max
>
sc8180x-primus' support upstream is quite flaky. The board boots 50% of time.
However it's true that with SHM bridge it gets to:
mount: mounting efivarfs on /sys/firmware/efi/efivars failed:
Operation not supported
and stops 100% of the time. Without SHM bridge I cannot boot it either because
I suppose I need the patch you sent yesterday. I haven't had the time to
rebase it yet, it's quite intrusive to my series.
I can confirm that with that patch the board still boots but still 50% of the
time.
Bart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [External] Re: [PATCH bpf-next v2 1/9] bpf: tracing: add support to record and check the accessed args
From: Steven Rostedt @ 2024-03-30 19:37 UTC (permalink / raw)
To: 梦龙董
Cc: Alexei Starovoitov, Jiri Olsa, Andrii Nakryiko,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Eddy Z,
Song Liu, Yonghong Song, John Fastabend, KP Singh,
Stanislav Fomichev, Hao Luo, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, David S. Miller,
David Ahern, Dave Hansen, X86 ML, Mathieu Desnoyers,
Quentin Monnet, bpf, linux-arm-kernel, LKML, linux-riscv,
linux-s390, Network Development, linux-trace-kernel,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32
In-Reply-To: <CALz3k9idLX10+Gh18xWepwtgvp4VZ3zQfY4aoNXn0gCh8Fs_fA@mail.gmail.com>
On Sat, 30 Mar 2024 11:18:29 +0800
梦龙董 <dongmenglong.8@bytedance.com> wrote:
> > If you really want to have thousands of functions, why not just register it
> > with ftrace itself. It will give you the arguments via the ftrace_regs
> > structure. Can't you just register a program as the callback?
> >
>
> Ennn...I don't understand. The main purpose for
> me to use TRACING is:
>
> 1. we can directly access the memory, which is more
> efficient.
I'm not sure what you mean by the above. Access what memory?
> 2. we can obtain the function args in FEXIT, which
> kretprobe can't do it. And this is the main reason.
I didn't mention kretprobe. If you need access to the exit of the function,
you can use Masami's fgraph update.
fentry -> ftrace_trampoline -> your_code
For fgraph:
fentry -> ftrace_trampoline -> fgraph [sets up return call] -> your_entry_code
function ret -> fgraph_ret_handler -> your_exit_code
And you will be able to pass data from the entry to the exit code,
including parameters.
-- Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v2 3/5] dt-bindings: clock: meson: document A1 SoC audio clock controller driver
From: Jan Dakinevich @ 2024-03-30 19:42 UTC (permalink / raw)
To: Jerome Brunet
Cc: Neil Armstrong, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kevin Hilman,
Martin Blumenstingl, Philipp Zabel, linux-amlogic, linux-clk,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1j4jcp9qdl.fsf@starbuckisacylon.baylibre.com>
On 3/29/24 15:24, Jerome Brunet wrote:
>
> On Thu 28 Mar 2024 at 04:08, Jan Dakinevich <jan.dakinevich@salutedevices.com> wrote:
>
>> Add device tree bindings for A1 SoC audio clock and reset controllers.
>>
>> Signed-off-by: Jan Dakinevich <jan.dakinevich@salutedevices.com>
>> ---
>> .../bindings/clock/amlogic,a1-audio-clkc.yaml | 141 ++++++++++++++++++
>> .../dt-bindings/clock/amlogic,a1-audio-clkc.h | 122 +++++++++++++++
>> .../reset/amlogic,meson-a1-audio-reset.h | 29 ++++
>> 3 files changed, 292 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/clock/amlogic,a1-audio-clkc.yaml
>> create mode 100644 include/dt-bindings/clock/amlogic,a1-audio-clkc.h
>> create mode 100644 include/dt-bindings/reset/amlogic,meson-a1-audio-reset.h
>>
>> diff --git a/Documentation/devicetree/bindings/clock/amlogic,a1-audio-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a1-audio-clkc.yaml
>> new file mode 100644
>> index 000000000000..1c9ef3292f3c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/amlogic,a1-audio-clkc.yaml
>> @@ -0,0 +1,141 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/clock/amlogic,a1-audio-clkc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Amlogic A1 Audio Clock Control Unit and Reset Controller
>> +
>> +maintainers:
>> + - Neil Armstrong <neil.armstrong@linaro.org>
>> + - Jerome Brunet <jbrunet@baylibre.com>
>> + - Jan Dakinevich <jan.dakinevich@salutedevices.com>
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - amlogic,a1-audio-clkc
>> + - amlogic,a1-audio2-clkc
>> +
>> + '#clock-cells':
>> + const: 1
>> +
>> + '#reset-cells':
>> + const: 1
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + clocks:
>> + minItems: 6
>> + maxItems: 7
>> +
>> + clock-names:
>> + minItems: 6
>> + maxItems: 7
>> +
>> +required:
>> + - compatible
>> + - '#clock-cells'
>> + - reg
>> + - clocks
>> + - clock-names
>> +
>> +allOf:
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - amlogic,a1-audio-clkc
>> + then:
>> + properties:
>> + clocks:
>> + items:
>> + - description: input core clock
>> + - description: input main peripheral bus clock
>> + - description: input dds_in
>> + - description: input fixed pll div2
>> + - description: input fixed pll div3
>> + - description: input hifi_pll
>> + - description: input oscillator (usually at 24MHz)
>> + clocks-names:
>> + items:
>> + - const: core
>> + - const: pclk
>> + - const: dds_in
>> + - const: fclk_div2
>> + - const: fclk_div3
>> + - const: hifi_pll
>> + - const: xtal
>> + required:
>> + - '#reset-cells'
>> + else:
>> + properties:
>> + clocks:
>> + items:
>> + - description: input main peripheral bus clock
>> + - description: input dds_in
>> + - description: input fixed pll div2
>> + - description: input fixed pll div3
>> + - description: input hifi_pll
>> + - description: input oscillator (usually at 24MHz)
>> + clock-names:
>> + items:
>> + - const: pclk
>> + - const: dds_in
>> + - const: fclk_div2
>> + - const: fclk_div3
>> + - const: hifi_pll
>> + - const: xtal
>
> All the optional slave clock inputs are missing from this dcoumentation..
> They need to be documentated as well
>
Hmmm... here should be a list of 26 entries. First 6 of them are
mandatory, other are optional.
I have no ideas left on how to describe it in yaml, also I can't find
something similar beside existing schemas... Maybe you can give some advice.
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/clock/amlogic,a1-pll-clkc.h>
>> + #include <dt-bindings/clock/amlogic,a1-peripherals-clkc.h>
>> + #include <dt-bindings/clock/amlogic,a1-audio-clkc.h>
>> + audio {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + clkc_audio: audio-clock-controller@fe050000 {
>> + compatible = "amlogic,a1-audio-clkc";
>> + reg = <0x0 0xfe050000 0x0 0xb0>;
>> + #clock-cells = <1>;
>> + #reset-cells = <1>;
>> + clocks = <&clkc_audio2 AUD2_CLKID_AUDIOTOP>,
>> + <&clkc_periphs CLKID_AUDIO>,
>> + <&clkc_periphs CLKID_DDS_IN>,
>> + <&clkc_pll CLKID_FCLK_DIV2>,
>> + <&clkc_pll CLKID_FCLK_DIV3>,
>> + <&clkc_pll CLKID_HIFI_PLL>,
>> + <&xtal>;
>> + clock-names = "core",
>> + "pclk",
>> + "dds_in",
>> + "fclk_div2",
>> + "fclk_div3",
>> + "hifi_pll",
>> + "xtal";
>> + };
>> +
>> + clkc_audio2: audio-clock-controller@fe054800 {
>> + compatible = "amlogic,a1-audio2-clkc";
>> + reg = <0x0 0xfe054800 0x0 0x20>;
>> + #clock-cells = <1>;
>> + clocks = <&clkc_periphs CLKID_AUDIO>,
>> + <&clkc_periphs CLKID_DDS_IN>,
>> + <&clkc_pll CLKID_FCLK_DIV2>,
>> + <&clkc_pll CLKID_FCLK_DIV3>,
>> + <&clkc_pll CLKID_HIFI_PLL>,
>> + <&xtal>;
>> + clock-names = "pclk",
>> + "dds_in",
>> + "fclk_div2",
>> + "fclk_div3",
>> + "hifi_pll",
>> + "xtal";
>> + };
>> + };
>> diff --git a/include/dt-bindings/clock/amlogic,a1-audio-clkc.h b/include/dt-bindings/clock/amlogic,a1-audio-clkc.h
>> new file mode 100644
>> index 000000000000..b30df3b1ae08
>> --- /dev/null
>> +++ b/include/dt-bindings/clock/amlogic,a1-audio-clkc.h
>> @@ -0,0 +1,122 @@
>> +/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
>> +/*
>> + * Copyright (c) 2024, SaluteDevices. All Rights Reserved.
>> + *
>> + * Author: Jan Dakinevich <jan.dakinevich@salutedevices.com>
>> + */
>> +
>> +#ifndef __A1_AUDIO_CLKC_BINDINGS_H
>> +#define __A1_AUDIO_CLKC_BINDINGS_H
>> +
>> +#define AUD_CLKID_DDR_ARB 1
>> +#define AUD_CLKID_TDMIN_A 2
>> +#define AUD_CLKID_TDMIN_B 3
>> +#define AUD_CLKID_TDMIN_LB 4
>> +#define AUD_CLKID_LOOPBACK 5
>> +#define AUD_CLKID_TDMOUT_A 6
>> +#define AUD_CLKID_TDMOUT_B 7
>> +#define AUD_CLKID_FRDDR_A 8
>> +#define AUD_CLKID_FRDDR_B 9
>> +#define AUD_CLKID_TODDR_A 10
>> +#define AUD_CLKID_TODDR_B 11
>> +#define AUD_CLKID_SPDIFIN 12
>> +#define AUD_CLKID_RESAMPLE 13
>> +#define AUD_CLKID_EQDRC 14
>> +#define AUD_CLKID_LOCKER 15
>> +#define AUD_CLKID_MST_A_MCLK_SEL 16
>> +#define AUD_CLKID_MST_A_MCLK_DIV 17
>> +#define AUD_CLKID_MST_A_MCLK 18
>> +#define AUD_CLKID_MST_B_MCLK_SEL 19
>> +#define AUD_CLKID_MST_B_MCLK_DIV 20
>> +#define AUD_CLKID_MST_B_MCLK 21
>> +#define AUD_CLKID_MST_C_MCLK_SEL 22
>> +#define AUD_CLKID_MST_C_MCLK_DIV 23
>> +#define AUD_CLKID_MST_C_MCLK 24
>> +#define AUD_CLKID_MST_D_MCLK_SEL 25
>> +#define AUD_CLKID_MST_D_MCLK_DIV 26
>> +#define AUD_CLKID_MST_D_MCLK 27
>> +#define AUD_CLKID_SPDIFIN_CLK_SEL 28
>> +#define AUD_CLKID_SPDIFIN_CLK_DIV 29
>> +#define AUD_CLKID_SPDIFIN_CLK 30
>> +#define AUD_CLKID_RESAMPLE_CLK_SEL 31
>> +#define AUD_CLKID_RESAMPLE_CLK_DIV 32
>> +#define AUD_CLKID_RESAMPLE_CLK 33
>> +#define AUD_CLKID_LOCKER_IN_CLK_SEL 34
>> +#define AUD_CLKID_LOCKER_IN_CLK_DIV 35
>> +#define AUD_CLKID_LOCKER_IN_CLK 36
>> +#define AUD_CLKID_LOCKER_OUT_CLK_SEL 37
>> +#define AUD_CLKID_LOCKER_OUT_CLK_DIV 38
>> +#define AUD_CLKID_LOCKER_OUT_CLK 39
>> +#define AUD_CLKID_EQDRC_CLK_SEL 40
>> +#define AUD_CLKID_EQDRC_CLK_DIV 41
>> +#define AUD_CLKID_EQDRC_CLK 42
>> +#define AUD_CLKID_MST_A_SCLK_PRE_EN 43
>> +#define AUD_CLKID_MST_A_SCLK_DIV 44
>> +#define AUD_CLKID_MST_A_SCLK_POST_EN 45
>> +#define AUD_CLKID_MST_A_SCLK 46
>> +#define AUD_CLKID_MST_B_SCLK_PRE_EN 47
>> +#define AUD_CLKID_MST_B_SCLK_DIV 48
>> +#define AUD_CLKID_MST_B_SCLK_POST_EN 49
>> +#define AUD_CLKID_MST_B_SCLK 50
>> +#define AUD_CLKID_MST_C_SCLK_PRE_EN 51
>> +#define AUD_CLKID_MST_C_SCLK_DIV 52
>> +#define AUD_CLKID_MST_C_SCLK_POST_EN 53
>> +#define AUD_CLKID_MST_C_SCLK 54
>> +#define AUD_CLKID_MST_D_SCLK_PRE_EN 55
>> +#define AUD_CLKID_MST_D_SCLK_DIV 56
>> +#define AUD_CLKID_MST_D_SCLK_POST_EN 57
>> +#define AUD_CLKID_MST_D_SCLK 58
>> +#define AUD_CLKID_MST_A_LRCLK_DIV 59
>> +#define AUD_CLKID_MST_A_LRCLK 60
>> +#define AUD_CLKID_MST_B_LRCLK_DIV 61
>> +#define AUD_CLKID_MST_B_LRCLK 62
>> +#define AUD_CLKID_MST_C_LRCLK_DIV 63
>> +#define AUD_CLKID_MST_C_LRCLK 64
>> +#define AUD_CLKID_MST_D_LRCLK_DIV 65
>> +#define AUD_CLKID_MST_D_LRCLK 66
>> +#define AUD_CLKID_TDMIN_A_SCLK_SEL 67
>> +#define AUD_CLKID_TDMIN_A_SCLK_PRE_EN 68
>> +#define AUD_CLKID_TDMIN_A_SCLK_POST_EN 69
>> +#define AUD_CLKID_TDMIN_A_SCLK 70
>> +#define AUD_CLKID_TDMIN_A_LRCLK 71
>> +#define AUD_CLKID_TDMIN_B_SCLK_SEL 72
>> +#define AUD_CLKID_TDMIN_B_SCLK_PRE_EN 73
>> +#define AUD_CLKID_TDMIN_B_SCLK_POST_EN 74
>> +#define AUD_CLKID_TDMIN_B_SCLK 75
>> +#define AUD_CLKID_TDMIN_B_LRCLK 76
>> +#define AUD_CLKID_TDMIN_LB_SCLK_SEL 77
>> +#define AUD_CLKID_TDMIN_LB_SCLK_PRE_EN 78
>> +#define AUD_CLKID_TDMIN_LB_SCLK_POST_EN 79
>> +#define AUD_CLKID_TDMIN_LB_SCLK 80
>> +#define AUD_CLKID_TDMIN_LB_LRCLK 81
>> +#define AUD_CLKID_TDMOUT_A_SCLK_SEL 82
>> +#define AUD_CLKID_TDMOUT_A_SCLK_PRE_EN 83
>> +#define AUD_CLKID_TDMOUT_A_SCLK_POST_EN 84
>> +#define AUD_CLKID_TDMOUT_A_SCLK 85
>> +#define AUD_CLKID_TDMOUT_A_LRCLK 86
>> +#define AUD_CLKID_TDMOUT_B_SCLK_SEL 87
>> +#define AUD_CLKID_TDMOUT_B_SCLK_PRE_EN 88
>> +#define AUD_CLKID_TDMOUT_B_SCLK_POST_EN 89
>> +#define AUD_CLKID_TDMOUT_B_SCLK 90
>> +#define AUD_CLKID_TDMOUT_B_LRCLK 91
>> +
>> +#define AUD2_CLKID_DDR_ARB 1
>> +#define AUD2_CLKID_PDM 2
>> +#define AUD2_CLKID_TDMIN_VAD 3
>> +#define AUD2_CLKID_TODDR_VAD 4
>> +#define AUD2_CLKID_VAD 5
>> +#define AUD2_CLKID_AUDIOTOP 6
>> +#define AUD2_CLKID_VAD_MCLK_SEL 7
>> +#define AUD2_CLKID_VAD_MCLK_DIV 8
>> +#define AUD2_CLKID_VAD_MCLK 9
>> +#define AUD2_CLKID_VAD_CLK_SEL 10
>> +#define AUD2_CLKID_VAD_CLK_DIV 11
>> +#define AUD2_CLKID_VAD_CLK 12
>> +#define AUD2_CLKID_PDM_DCLK_SEL 13
>> +#define AUD2_CLKID_PDM_DCLK_DIV 14
>> +#define AUD2_CLKID_PDM_DCLK 15
>> +#define AUD2_CLKID_PDM_SYSCLK_SEL 16
>> +#define AUD2_CLKID_PDM_SYSCLK_DIV 17
>> +#define AUD2_CLKID_PDM_SYSCLK 18
>> +
>> +#endif /* __A1_AUDIO_CLKC_BINDINGS_H */
>> diff --git a/include/dt-bindings/reset/amlogic,meson-a1-audio-reset.h b/include/dt-bindings/reset/amlogic,meson-a1-audio-reset.h
>> new file mode 100644
>> index 000000000000..653fddba1d8f
>> --- /dev/null
>> +++ b/include/dt-bindings/reset/amlogic,meson-a1-audio-reset.h
>> @@ -0,0 +1,29 @@
>> +/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
>> +/*
>> + * Copyright (c) 2024, SaluteDevices. All Rights Reserved.
>> + *
>> + * Author: Jan Dakinevich <jan.dakinevich@salutedevices.com>
>> + */
>> +
>> +#ifndef _DT_BINDINGS_AMLOGIC_MESON_A1_AUDIO_RESET_H
>> +#define _DT_BINDINGS_AMLOGIC_MESON_A1_AUDIO_RESET_H
>> +
>> +#define AUD_RESET_DDRARB 0
>> +#define AUD_RESET_TDMIN_A 1
>> +#define AUD_RESET_TDMIN_B 2
>> +#define AUD_RESET_TDMIN_LB 3
>> +#define AUD_RESET_LOOPBACK 4
>> +#define AUD_RESET_TDMOUT_A 5
>> +#define AUD_RESET_TDMOUT_B 6
>> +#define AUD_RESET_FRDDR_A 7
>> +#define AUD_RESET_FRDDR_B 8
>> +#define AUD_RESET_TODDR_A 9
>> +#define AUD_RESET_TODDR_B 10
>> +#define AUD_RESET_SPDIFIN 11
>> +#define AUD_RESET_RESAMPLE 12
>> +#define AUD_RESET_EQDRC 13
>> +#define AUD_RESET_LOCKER 14
>> +#define AUD_RESET_TOACODEC 30
>> +#define AUD_RESET_CLKTREE 31
>> +
>> +#endif /* _DT_BINDINGS_AMLOGIC_MESON_A1_AUDIO_RESET_H */
>
>
--
Best regards
Jan Dakinevich
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] drm/rockchip: cdn-dp: drop driver owner assignment
From: Krzysztof Kozlowski @ 2024-03-30 20:27 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Daniel Vetter,
dri-devel, linux-arm-kernel, linux-rockchip, linux-kernel
Cc: Krzysztof Kozlowski
Core in platform_driver_register() already sets the .owner, so driver
does not need to. Whatever is set here will be anyway overwritten by
main driver calling platform_driver_register().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index a855c45ae7f3..419542c66b53 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1259,7 +1259,6 @@ struct platform_driver cdn_dp_driver = {
.shutdown = cdn_dp_shutdown,
.driver = {
.name = "cdn-dp",
- .owner = THIS_MODULE,
.of_match_table = cdn_dp_dt_ids,
.pm = &cdn_dp_pm_ops,
},
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 00/11] drm/exynos: drop driver owner initialization
From: Krzysztof Kozlowski @ 2024-03-30 20:33 UTC (permalink / raw)
To: Inki Dae, Seung-Woo Kim, Kyungmin Park, David Airlie,
Daniel Vetter, Krzysztof Kozlowski, Alim Akhtar
Cc: dri-devel, linux-arm-kernel, linux-samsung-soc, linux-kernel
Simplify the code by dropping unnecessary .owner initialization in the
driver.
Best regards,
Krzysztof
---
Krzysztof Kozlowski (11):
drm/exynos: fimc: drop driver owner initialization
drm/exynos: fimd: drop driver owner initialization
drm/exynos: dsi: drop driver owner initialization
drm/exynos: g2d: drop driver owner initialization
drm/exynos: gsc: drop driver owner initialization
drm/exynos: mic: drop driver owner initialization
drm/exynos: rotator: drop driver owner initialization
drm/exynos: scaler: drop driver owner initialization
drm/exynos: vidi: drop driver owner initialization
drm/exynos: hdmi: drop driver owner initialization
drm/exynos: mixer: drop driver owner initialization
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1 -
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 1 -
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 -
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 1 -
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 1 -
drivers/gpu/drm/exynos/exynos_drm_mic.c | 1 -
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 1 -
drivers/gpu/drm/exynos/exynos_drm_scaler.c | 1 -
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 1 -
drivers/gpu/drm/exynos/exynos_hdmi.c | 1 -
drivers/gpu/drm/exynos/exynos_mixer.c | 1 -
11 files changed, 11 deletions(-)
---
base-commit: 7fdcff3312e16ba8d1419f8a18f465c5cc235ecf
change-id: 20240330-b4-module-owner-drm-exynos-d2f1b2d48af3
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
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