* Re: [PATCH v14 01/18] irqchip/sifive-plic: Convert PLIC driver into a platform driver
From: Lad, Prabhakar @ 2024-04-03 8:29 UTC (permalink / raw)
To: Anup Patel
Cc: Geert Uytterhoeven, Palmer Dabbelt, Paul Walmsley,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Frank Rowand,
Conor Dooley, Marc Zyngier, Björn Töpel, Atish Patra,
Andrew Jones, Sunil V L, Saravana Kannan, Anup Patel, linux-riscv,
linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <20240222094006.1030709-2-apatel@ventanamicro.com>
Hi Anup,
On Thu, Feb 22, 2024 at 9:41 AM Anup Patel <apatel@ventanamicro.com> wrote:
>
> The PLIC driver does not require very early initialization so convert
> it into a platform driver.
>
> After conversion, the PLIC driver is probed after CPUs are brought-up
> so setup cpuhp state after context handler of all online CPUs are
> initialized otherwise PLIC driver crashes for platforms with multiple
> PLIC instances.
>
> Signed-off-by: Anup Patel <apatel@ventanamicro.com>
> ---
> drivers/irqchip/irq-sifive-plic.c | 101 ++++++++++++++++++------------
> 1 file changed, 61 insertions(+), 40 deletions(-)
>
This patch seems to have broken things on RZ/Five SoC, after reverting
this patch I get to boot it back again on v6.9-rc2. Looks like there
is some probe order issue after switching to platform driver?
Cheers,
Prabhakar
> diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
> index 5b7bc4fd9517..7400a07fc479 100644
> --- a/drivers/irqchip/irq-sifive-plic.c
> +++ b/drivers/irqchip/irq-sifive-plic.c
> @@ -64,6 +64,7 @@
> #define PLIC_QUIRK_EDGE_INTERRUPT 0
>
> struct plic_priv {
> + struct device *dev;
> struct cpumask lmask;
> struct irq_domain *irqdomain;
> void __iomem *regs;
> @@ -406,30 +407,50 @@ static int plic_starting_cpu(unsigned int cpu)
> return 0;
> }
>
> -static int __init __plic_init(struct device_node *node,
> - struct device_node *parent,
> - unsigned long plic_quirks)
> +static const struct of_device_id plic_match[] = {
> + { .compatible = "sifive,plic-1.0.0" },
> + { .compatible = "riscv,plic0" },
> + { .compatible = "andestech,nceplic100",
> + .data = (const void *)BIT(PLIC_QUIRK_EDGE_INTERRUPT) },
> + { .compatible = "thead,c900-plic",
> + .data = (const void *)BIT(PLIC_QUIRK_EDGE_INTERRUPT) },
> + {}
> +};
> +
> +static int plic_probe(struct platform_device *pdev)
> {
> int error = 0, nr_contexts, nr_handlers = 0, i;
> - u32 nr_irqs;
> - struct plic_priv *priv;
> + struct device *dev = &pdev->dev;
> + unsigned long plic_quirks = 0;
> struct plic_handler *handler;
> + struct plic_priv *priv;
> + bool cpuhp_setup;
> unsigned int cpu;
> + u32 nr_irqs;
> +
> + if (is_of_node(dev->fwnode)) {
> + const struct of_device_id *id;
> +
> + id = of_match_node(plic_match, to_of_node(dev->fwnode));
> + if (id)
> + plic_quirks = (unsigned long)id->data;
> + }
>
> priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> if (!priv)
> return -ENOMEM;
>
> + priv->dev = dev;
> priv->plic_quirks = plic_quirks;
>
> - priv->regs = of_iomap(node, 0);
> + priv->regs = of_iomap(to_of_node(dev->fwnode), 0);
> if (WARN_ON(!priv->regs)) {
> error = -EIO;
> goto out_free_priv;
> }
>
> error = -EINVAL;
> - of_property_read_u32(node, "riscv,ndev", &nr_irqs);
> + of_property_read_u32(to_of_node(dev->fwnode), "riscv,ndev", &nr_irqs);
> if (WARN_ON(!nr_irqs))
> goto out_iounmap;
>
> @@ -439,13 +460,13 @@ static int __init __plic_init(struct device_node *node,
> if (!priv->prio_save)
> goto out_free_priority_reg;
>
> - nr_contexts = of_irq_count(node);
> + nr_contexts = of_irq_count(to_of_node(dev->fwnode));
> if (WARN_ON(!nr_contexts))
> goto out_free_priority_reg;
>
> error = -ENOMEM;
> - priv->irqdomain = irq_domain_add_linear(node, nr_irqs + 1,
> - &plic_irqdomain_ops, priv);
> + priv->irqdomain = irq_domain_add_linear(to_of_node(dev->fwnode), nr_irqs + 1,
> + &plic_irqdomain_ops, priv);
> if (WARN_ON(!priv->irqdomain))
> goto out_free_priority_reg;
>
> @@ -455,7 +476,7 @@ static int __init __plic_init(struct device_node *node,
> int cpu;
> unsigned long hartid;
>
> - if (of_irq_parse_one(node, i, &parent)) {
> + if (of_irq_parse_one(to_of_node(dev->fwnode), i, &parent)) {
> pr_err("failed to parse parent for context %d.\n", i);
> continue;
> }
> @@ -491,7 +512,7 @@ static int __init __plic_init(struct device_node *node,
>
> /* Find parent domain and register chained handler */
> if (!plic_parent_irq && irq_find_host(parent.np)) {
> - plic_parent_irq = irq_of_parse_and_map(node, i);
> + plic_parent_irq = irq_of_parse_and_map(to_of_node(dev->fwnode), i);
> if (plic_parent_irq)
> irq_set_chained_handler(plic_parent_irq,
> plic_handle_irq);
> @@ -533,20 +554,29 @@ static int __init __plic_init(struct device_node *node,
>
> /*
> * We can have multiple PLIC instances so setup cpuhp state
> - * and register syscore operations only when context handler
> - * for current/boot CPU is present.
> + * and register syscore operations only once after context
> + * handlers of all online CPUs are initialized.
> */
> - handler = this_cpu_ptr(&plic_handlers);
> - if (handler->present && !plic_cpuhp_setup_done) {
> - cpuhp_setup_state(CPUHP_AP_IRQ_SIFIVE_PLIC_STARTING,
> - "irqchip/sifive/plic:starting",
> - plic_starting_cpu, plic_dying_cpu);
> - register_syscore_ops(&plic_irq_syscore_ops);
> - plic_cpuhp_setup_done = true;
> + if (!plic_cpuhp_setup_done) {
> + cpuhp_setup = true;
> + for_each_online_cpu(cpu) {
> + handler = per_cpu_ptr(&plic_handlers, cpu);
> + if (!handler->present) {
> + cpuhp_setup = false;
> + break;
> + }
> + }
> + if (cpuhp_setup) {
> + cpuhp_setup_state(CPUHP_AP_IRQ_SIFIVE_PLIC_STARTING,
> + "irqchip/sifive/plic:starting",
> + plic_starting_cpu, plic_dying_cpu);
> + register_syscore_ops(&plic_irq_syscore_ops);
> + plic_cpuhp_setup_done = true;
> + }
> }
>
> - pr_info("%pOFP: mapped %d interrupts with %d handlers for"
> - " %d contexts.\n", node, nr_irqs, nr_handlers, nr_contexts);
> + pr_info("%pOFP: mapped %d interrupts with %d handlers for %d contexts.\n",
> + to_of_node(dev->fwnode), nr_irqs, nr_handlers, nr_contexts);
> return 0;
>
> out_free_enable_reg:
> @@ -563,20 +593,11 @@ static int __init __plic_init(struct device_node *node,
> return error;
> }
>
> -static int __init plic_init(struct device_node *node,
> - struct device_node *parent)
> -{
> - return __plic_init(node, parent, 0);
> -}
> -
> -IRQCHIP_DECLARE(sifive_plic, "sifive,plic-1.0.0", plic_init);
> -IRQCHIP_DECLARE(riscv_plic0, "riscv,plic0", plic_init); /* for legacy systems */
> -
> -static int __init plic_edge_init(struct device_node *node,
> - struct device_node *parent)
> -{
> - return __plic_init(node, parent, BIT(PLIC_QUIRK_EDGE_INTERRUPT));
> -}
> -
> -IRQCHIP_DECLARE(andestech_nceplic100, "andestech,nceplic100", plic_edge_init);
> -IRQCHIP_DECLARE(thead_c900_plic, "thead,c900-plic", plic_edge_init);
> +static struct platform_driver plic_driver = {
> + .driver = {
> + .name = "riscv-plic",
> + .of_match_table = plic_match,
> + },
> + .probe = plic_probe,
> +};
> +builtin_platform_driver(plic_driver);
> --
> 2.34.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: qcs6490-rb3gen2: Specify zap region for gpu
From: Dmitry Baryshkov @ 2024-04-03 8:31 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Caleb Connolly, Komal Bajaj, Naina Mehta,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20240402-rb3gen2-gpu-v1-1-a51bb6080968@quicinc.com>
On Wed, 3 Apr 2024 at 06:33, Bjorn Andersson <quic_bjorande@quicinc.com> wrote:
>
> Without the zap region defined the enabled GPU will, if able to find the
> other firmware files, attempt to initialize itself without the zap
> firmware loading, which causes the rb3gen2 to freeze or crash.
>
> Add the zap-shader node and define the memory-region and firmware path
> to avoid this problem.
>
> Fixes: 04cf333afc75 ("arm64: dts: qcom: Add base qcs6490-rb3gen2 board dts")
> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> ---
> arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> index 63ebe0774f1d..5b81b5e0b4ce 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> @@ -471,6 +471,13 @@ &gcc {
> <GCC_WPSS_RSCP_CLK>;
> };
>
> +&gpu {
Hmm, Is the GPU enabled by default? It should probably be fixed. I
think we usually do not enable the GPU by default on SoC.dtsi.
But now I understand, why it is marked with Fixes:
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> + zap-shader {
> + memory-region = <&gpu_microcode_mem>;
> + firmware-name = "qcom/qcs6490/a660_zap.mbn";
> + };
> +};
> +
> &qupv3_id_0 {
> status = "okay";
> };
>
> ---
> base-commit: 727900b675b749c40ba1f6669c7ae5eb7eb8e837
> change-id: 20240326-rb3gen2-gpu-4343c5dc7e40
>
> Best regards,
> --
> Bjorn Andersson <quic_bjorande@quicinc.com>
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: leds: add LED_FUNCTION_FNLOCK
From: Hans de Goede @ 2024-04-03 8:33 UTC (permalink / raw)
To: Gergo Koteles, Krzysztof Kozlowski, Ike Panhc, Ilpo Järvinen,
Pavel Machek, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: platform-driver-x86, linux-kernel, linux-leds, devicetree
In-Reply-To: <2710283677cf12ca6b826565ec39652f560a43d8.camel@irl.hu>
Hi George,
On 4/2/24 8:50 PM, Gergo Koteles wrote:
> Hi Krzysztof,
>
> On Tue, 2024-04-02 at 20:08 +0200, Krzysztof Kozlowski wrote:
>> On 02/04/2024 16:36, Gergo Koteles wrote:
>>> Hi Krzysztof,
>>>
>>> On Tue, 2024-04-02 at 15:55 +0200, Krzysztof Kozlowski wrote:
>>>>
>>>> Do we really need to define all these possible LED functions? Please
>>>> link to DTS user for this.
>>>>
>>>
>>> I think for userspace it's easier to support an LED with a specified
>>> name than to use various sysfs attributes. LED devices are easy to find
>>> because they available are in the /sys/class/leds/ directory.
>>> So I think it's a good thing to define LED names somewhere.
>>
>> You did not add anything for user-space, but DT bindings. We do not keep
>> here anything for user-space.
>>
>
> The LED_FUNCTION_KBD_BACKLIGHT confused me. Ok, this shouldn't be here,
> I will remove it from v2.
I don't believe that is necessary, see my direct reply to Krzysztof first
email about this. According to Documentation/leds/leds-class.rst
you did exactly the right thing.
Also thank you for your interesting contribution. I have only briefly
looked over your other 2 patches, but I like the concept.
I'll hopefully have time to do a full review coming Monday.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: stmmac: dwmac-socfpga: use pcs_init/pcs_exit
From: Russell King (Oracle) @ 2024-04-03 8:34 UTC (permalink / raw)
To: Romain Gantois
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, Clément Léger, Thomas Petazzoni,
netdev, devicetree, linux-kernel, linux-renesas-soc, linux-stm32,
linux-arm-kernel
In-Reply-To: <E1rrgQO-005ZOA-KT@rmk-PC.armlinux.org.uk>
On Tue, Apr 02, 2024 at 04:51:48PM +0100, Russell King (Oracle) wrote:
> Use the newly introduced pcs_init() and pcs_exit() operations to
> create and destroy the PCS instance at a more appropriate moment during
> the driver lifecycle, thereby avoiding publishing a network device to
> userspace that has not yet finished its PCS initialisation.
>
> There are other similar issues with this driver which remain
> unaddressed, but these are out of scope for this patch.
Just for the record...
Digging into the history of this driver, the init-after-publish issue
was introduced by commit 3c201b5a84ed ("net: stmmac: socfpga: Remove
re-registration of reset controller") which gives information on why
calling the PHY configuration before stmmac_dvr_probe() didn't work.
This was further modified by 56868deece92 ("stmmac: dwmac-socfpga: add
PM ops and resume function").
I haven't decided what can be done about that yet - and I'm tempted to
leave it as-is for the time being until more of stmmac gets cleaned up.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: leds: add LED_FUNCTION_FNLOCK
From: Krzysztof Kozlowski @ 2024-04-03 8:36 UTC (permalink / raw)
To: Hans de Goede, Gergo Koteles, Ike Panhc, Ilpo Järvinen,
Pavel Machek, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: platform-driver-x86, linux-kernel, linux-leds, devicetree
In-Reply-To: <39acb3b9-a69f-4654-9749-a9af42fea39e@redhat.com>
On 03/04/2024 10:31, Hans de Goede wrote:
> Hi Krzysztof,
>
> On 4/2/24 3:55 PM, Krzysztof Kozlowski wrote:
>> On 02/04/2024 15:21, Gergo Koteles wrote:
>>> Newer laptops have FnLock LED.
>>>
>>> Add a define for this very common function.
>>>
>>> Signed-off-by: Gergo Koteles <soyer@irl.hu>
>>> ---
>>> include/dt-bindings/leds/common.h | 1 +
>>
>> Do we really need to define all these possible LED functions? Please
>> link to DTS user for this.
>
> It is useful to have well established names for common
> LED functions instead of having each driver come up
> with its own name with slightly different spelling
> for various fixed function LEDs.
>
> This is even documented in:
>
> Documentation/leds/leds-class.rst :
>
> """
> LED Device Naming
> =================
>
> Is currently of the form:
>
> "devicename:color:function"
>
> ...
>
>
> - function:
> one of LED_FUNCTION_* definitions from the header
> include/dt-bindings/leds/common.h.
> """
>
> Note this even specifies these definitions should go into
> include/dt-bindings/leds/common.h .
>
> In this case there is no dts user (yet) only an in kernel
> driver which wants to use a LED_FUNCTION_* define to
> establish how to identify FN-lock LEDs going forward.
Ack, reasonable.
>
> Since a lot of LED_FUNCTION_* defines happen to be used
> in dts files these happen to live under include/dt-bindings/
> but the dts files are not the only consumer of these defines (1).
Yes, but if there was no DTS consumer at all, then it is not a binding,
so it should not go to include/dt-bindings.
>
> IMHO having a hard this must be used in a dts file rule
> is not helpful for these kinda files with defines shared
> between dts and non dts cases.
>
> If we were to follow this logic then any addition to
>
> include/uapi/linux/input-event-codes.h
>
> must have a dts user before being approved too ? Since
> that file is included from include/dt-bindings/input/input.h ?
Wait, that's UAPI :) and we just share the constants. That's kind of
special case, but I get what you mean.
>
> TL;DR: not only is this patch fine, this is actually
> the correct place to add such a define according to
> the docs in Documentation/leds/leds-class.rst :
>
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm64: dts: ls1028a: sl28: split variant 3/ads2 carrier
From: Michael Walle @ 2024-04-03 8:38 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, devicetree, linux-kernel, Michael Walle
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
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 045250d0a040..9319791f298c 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-kbox-a-230-ls.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-sl28.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-sl28-var1.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-sl28-var2.dtb
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-sl28-var3.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-sl28-var3-ads2.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-sl28-var4.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-qds.dtb
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts
index ed4e69e87e30..195bdbafdf7c 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts
@@ -10,7 +10,7 @@
/dts-v1/;
#include <dt-bindings/clock/fsl,qoriq-clockgen.h>
-#include "fsl-ls1028a-kontron-sl28.dts"
+#include "fsl-ls1028a-kontron-sl28-var3.dts"
/ {
model = "Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dts
new file mode 100644
index 000000000000..08851ca407a8
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Device Tree file for the Kontron SMARC-sAL28 board.
+ *
+ * This is for the network variant 3 which has one ethernet ports.
+ *
+ * Copyright (C) 2024 Michael Walle <michael@walle.cc>
+ *
+ */
+
+/dts-v1/;
+
+#include "fsl-ls1028a-kontron-sl28.dts"
+
+/ {
+ model = "Kontron SMARC-sAL28 (Single PHY)";
+ compatible = "kontron,sl28-var3", "kontron,sl28", "fsl,ls1028a";
+};
--
2.39.2
^ permalink raw reply related
* Re: [PATCH 1/3] dt-bindings: leds: add LED_FUNCTION_FNLOCK
From: Hans de Goede @ 2024-04-03 8:39 UTC (permalink / raw)
To: Krzysztof Kozlowski, Gergo Koteles, Ike Panhc, Ilpo Järvinen,
Pavel Machek, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: platform-driver-x86, linux-kernel, linux-leds, devicetree
In-Reply-To: <368e9817-0000-4f69-9f09-568827466121@linaro.org>
Hi,
On 4/3/24 10:36 AM, Krzysztof Kozlowski wrote:
> On 03/04/2024 10:31, Hans de Goede wrote:
>> Hi Krzysztof,
>>
>> On 4/2/24 3:55 PM, Krzysztof Kozlowski wrote:
>>> On 02/04/2024 15:21, Gergo Koteles wrote:
>>>> Newer laptops have FnLock LED.
>>>>
>>>> Add a define for this very common function.
>>>>
>>>> Signed-off-by: Gergo Koteles <soyer@irl.hu>
>>>> ---
>>>> include/dt-bindings/leds/common.h | 1 +
>>>
>>> Do we really need to define all these possible LED functions? Please
>>> link to DTS user for this.
>>
>> It is useful to have well established names for common
>> LED functions instead of having each driver come up
>> with its own name with slightly different spelling
>> for various fixed function LEDs.
>>
>> This is even documented in:
>>
>> Documentation/leds/leds-class.rst :
>>
>> """
>> LED Device Naming
>> =================
>>
>> Is currently of the form:
>>
>> "devicename:color:function"
>>
>> ...
>>
>>
>> - function:
>> one of LED_FUNCTION_* definitions from the header
>> include/dt-bindings/leds/common.h.
>> """
>>
>> Note this even specifies these definitions should go into
>> include/dt-bindings/leds/common.h .
>>
>> In this case there is no dts user (yet) only an in kernel
>> driver which wants to use a LED_FUNCTION_* define to
>> establish how to identify FN-lock LEDs going forward.
>
> Ack, reasonable.
>
>>
>> Since a lot of LED_FUNCTION_* defines happen to be used
>> in dts files these happen to live under include/dt-bindings/
>> but the dts files are not the only consumer of these defines (1).
>
> Yes, but if there was no DTS consumer at all, then it is not a binding,
> so it should not go to include/dt-bindings.
>
>>
>> IMHO having a hard this must be used in a dts file rule
>> is not helpful for these kinda files with defines shared
>> between dts and non dts cases.
>>
>> If we were to follow this logic then any addition to
>>
>> include/uapi/linux/input-event-codes.h
>>
>> must have a dts user before being approved too ? Since
>> that file is included from include/dt-bindings/input/input.h ?
>
> Wait, that's UAPI :) and we just share the constants. That's kind of
> special case, but I get what you mean.
>
>>
>> TL;DR: not only is this patch fine, this is actually
>> the correct place to add such a define according to
>> the docs in Documentation/leds/leds-class.rst :
>>
>> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Thanks. Is it ok for me to merge this through the pdx86
tree (once I've reviewed the other 2 patches) ?
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v6 08/11] pinctrl: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210
From: Yangyu Chen @ 2024-04-03 8:38 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-riscv, Conor Dooley, Damien Le Moal, Rob Herring,
Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Guo Ren, Michael Turquette, Stephen Boyd, Philipp Zabel,
linux-gpio, linux-clk, devicetree, linux-kernel
In-Reply-To: <CACRpkdY1wpGM7M5QV5rN0M6JMN_yugQJ7CEtnQjzsheD5AT23A@mail.gmail.com>
> On Apr 2, 2024, at 20:31, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Sat, Mar 23, 2024 at 1:13 PM Yangyu Chen <cyy@cyyself.name> wrote:
>
>> Since SOC_FOO should be deprecated from patch [1], and cleanup for other
>> SoCs is already on the mailing list [2,3,4], we remove the use of
>> SOC_CANAAN and introduced SOC_CANAAN_K210 for K210-specific drivers,
>>
>> Thus, we replace its drivers depends on SOC_CANAAN_K210 and default select
>> when it has the symbol SOC_CANAAN_K210.
>>
>> [1] https://lore.kernel.org/linux-riscv/20221121221414.109965-1-conor@kernel.org/
>> [2] https://lore.kernel.org/linux-riscv/20240305-praying-clad-c4fbcaa7ed0a@spud/
>> [3] https://lore.kernel.org/linux-riscv/20240305-fled-undrilled-41dc0c46bb29@spud/
>> [4] https://lore.kernel.org/linux-riscv/20240305-stress-earflap-d7ddb8655a4d@spud/
>>
>> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
Please add Acked-by to this email [1]. I will separate them in the next
revision.
[1]
https://lore.kernel.org/linux-riscv/tencent_DB11214C8D0D7C48829ADA128E7BB8F13108@qq.com/
Thanks.
> Is this patch something I can just apply to the pinctrl tree?
>
I think not. As Conor said.
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH 00/12] Use clksel for more clocks for dra7
From: Tony Lindgren @ 2024-04-03 8:43 UTC (permalink / raw)
To: linux-omap; +Cc: Benoît Cousson, devicetree
In-Reply-To: <20240328113133.GG5132@atomide.com>
* Tony Lindgren <tony@atomide.com> [240328 11:31]:
> * Tony Lindgren <tony@atomide.com> [240327 09:39]:
> > The DPLL output clocks are problematic at this point as the
> > clock driver makes assumptions based on no reg property in
> > _register_dpll_x2() for the ti,omap4-dpll-x2-clock. After
> > the driver issues are solved, the DPLL output related clocks
> > can also use the clksel binding.
>
> Actually the driver needs changes only for clocks where there's no
> reg entry. For the clocks with a reg entry like dpll_per m2 outputs,
> the following seems to work based on light testing.
Oh but below dpll_per_x2_ck has no reg yet we now add the reg property.
Likely the additional patch below can't be used without driver changes
for _register_dpll_x2().
Regards,
Tony
> 8< -----------------
> diff --git a/arch/arm/boot/dts/ti/omap/dra7xx-clocks.dtsi b/arch/arm/boot/dts/ti/omap/dra7xx-clocks.dtsi
> --- a/arch/arm/boot/dts/ti/omap/dra7xx-clocks.dtsi
> +++ b/arch/arm/boot/dts/ti/omap/dra7xx-clocks.dtsi
> @@ -1425,6 +1425,7 @@ dpll_per_byp_mux: clock@23 {
> };
> };
>
> + /* CM_CLKSEL_DPLL_PER */
> dpll_per_ck: clock@140 {
> #clock-cells = <0>;
> compatible = "ti,omap4-dpll-clock";
> @@ -1433,16 +1434,43 @@ dpll_per_ck: clock@140 {
> reg = <0x0140>, <0x0144>, <0x014c>, <0x0148>;
> };
>
> - dpll_per_m2_ck: clock-dpll-per-m2-8@150 {
> - #clock-cells = <0>;
> - compatible = "ti,divider-clock";
> - clock-output-names = "dpll_per_m2_ck";
> - clocks = <&dpll_per_ck>;
> - ti,max-div = <31>;
> - ti,autoidle-shift = <8>;
> - reg = <0x0150>;
> - ti,index-starts-at-one;
> - ti,invert-autoidle-bit;
> + /* CM_DIV_M2_DPLL_PER */
> + clock@150 {
> + compatible = "ti,clksel";
> + reg = <0x150>;
> + #clock-cells = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dpll_per_m2x2_ck: clock@0 {
> + reg = <0>;
> + #clock-cells = <0>;
> + compatible = "ti,divider-clock";
> + clock-output-names = "dpll_per_m2x2_ck";
> + clocks = <&dpll_per_x2_ck>;
> + ti,max-div = <31>;
> + ti,autoidle-shift = <8>;
> + ti,index-starts-at-one;
> + ti,invert-autoidle-bit;
> + };
> +
> + dpll_per_m2_ck: clock@8 {
> + compatible = "fixed-factor-clock";
> + reg = <8>;
> + #clock-cells = <0>;
> + clocks = <&dpll_per_m2x2_ck>;
> + clock-mult = <1>;
> + clock-div = <2>;
> + clock-output-names = "dpll_per_m2_ck";
> + };
> +
> + dpll_per_x2_ck: clock@10 {
> + reg = <10>;
> + #clock-cells = <0>;
> + compatible = "ti,omap4-dpll-x2-clock";
> + clock-output-names = "dpll_per_x2_ck";
> + clocks = <&dpll_per_ck>;
> + };
> };
>
> func_96m_aon_dclk_div: clock-func-96m-aon-dclk-div {
> @@ -1503,13 +1531,6 @@ dpll_pcie_ref_m2_ck: clock-dpll-pcie-ref-m2-8@210 {
> ti,invert-autoidle-bit;
> };
>
> - dpll_per_x2_ck: clock-dpll-per-x2 {
> - #clock-cells = <0>;
> - compatible = "ti,omap4-dpll-x2-clock";
> - clock-output-names = "dpll_per_x2_ck";
> - clocks = <&dpll_per_ck>;
> - };
> -
> dpll_per_h11x2_ck: clock-dpll-per-h11x2-8@158 {
> #clock-cells = <0>;
> compatible = "ti,divider-clock";
> @@ -1558,18 +1579,6 @@ dpll_per_h14x2_ck: clock-dpll-per-h14x2-8@164 {
> ti,invert-autoidle-bit;
> };
>
> - dpll_per_m2x2_ck: clock-dpll-per-m2x2-8@150 {
> - #clock-cells = <0>;
> - compatible = "ti,divider-clock";
> - clock-output-names = "dpll_per_m2x2_ck";
> - clocks = <&dpll_per_x2_ck>;
> - ti,max-div = <31>;
> - ti,autoidle-shift = <8>;
> - reg = <0x0150>;
> - ti,index-starts-at-one;
> - ti,invert-autoidle-bit;
> - };
> -
> dpll_usb_clkdcoldo: clock-dpll-usb-clkdcoldo {
> #clock-cells = <0>;
> compatible = "fixed-factor-clock";
> --
> 2.44.0
>
^ permalink raw reply
* Re: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support
From: Andy Shevchenko @ 2024-04-03 8:44 UTC (permalink / raw)
To: Cristian Marussi
Cc: Peng Fan, Peng Fan (OSS), Sudeep Holla, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij, Dan Carpenter,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, Oleksii Moisieiev
In-Reply-To: <Zg0N8S05D329BVjN@pluto>
On Wed, Apr 3, 2024 at 11:06 AM Cristian Marussi
<cristian.marussi@arm.com> wrote:
> On Tue, Apr 02, 2024 at 07:39:44PM +0300, Andy Shevchenko wrote:
> > On Tue, Apr 2, 2024 at 6:58 PM Cristian Marussi
> > <cristian.marussi@arm.com> wrote:
> > > On Tue, Apr 02, 2024 at 04:06:06PM +0300, Andy Shevchenko wrote:
> > > > On Tue, Apr 2, 2024 at 10:48 AM Cristian Marussi
> > > > <cristian.marussi@arm.com> wrote:
> > > > > On Sun, Mar 31, 2024 at 01:44:28PM +0000, Peng Fan wrote:
> > > > > > > Sat, Mar 23, 2024 at 08:15:16PM +0800, Peng Fan (OSS) kirjoitti:
...
> > > > > > > > +#include <linux/module.h>
> > > > > > > > +#include <linux/scmi_protocol.h>
> > > > > > > > +#include <linux/slab.h>
> > > > > > >
> > > > > > > This is semi-random list of headers. Please, follow IWYU principle (include
> > > > > > > what you use). There are a lot of inclusions I see missing (just in the context of
> > > > > > > this page I see bits.h, types.h, and asm/byteorder.h).
> > > > > >
> > > > > > Is there any documentation about this requirement?
> > > > > > Some headers are already included by others.
> > > >
> > > > The documentation here is called "a common sense".
> > > > The C language is built like this and we expect that nobody will
> > > > invest into the dependency hell that we have already, that's why IWYU
> > > > principle, please follow it.
> > >
> > > Yes, but given that we have a growing number of SCMI protocols there is a
> > > common local protocols.h header to group all includes needed by any
> > > protocols: the idea behind this (and the devm_ saga down below) was to ease
> > > development of protocols, since there are lots of them and growing, given
> > > the SCMI spec is extensible.
> >
> > Yes, and what you are effectively suggesting is: "Technical debt? Oh,
> > fine, we do not care!" This is not good. I'm in a long term of
> > cleaning up the dependency hell in the kernel (my main focus is
> > kernel.h for now) and I am talking from my experience. I do not like
> > what people are doing in 95% of the code, that's why I really want to
> > stop the bad practices as soon as possible.
>
> Not at all, the aim was exactly the opposite, avoiding that some protocol
> could have been written without all the needed includes: since a basic set
> of headers is definitely common to any protocol you may think to write,
> grouping all there was meant to avoid this...I thought that by moving the
> problem away in one single internal common header was easier to monitor.
Which may or may not be okay. It plays too smart, so the end developer
won't care about real headers they need as they are the only ones who
know the source code in the best possible way.
> I certainly maybe wrong, but I dont see how you can deduce I dont care...
See above, the protocols.h it's a reincarnation (much less twisted and
ugly, though) of something like kernel.h. Do you know why we have a
split to headers instead of having everything in one? It speeds up a
build, it separates namespace (to the extent of what we call
"namespace" in C language), it makes the modularization (of the source
code) better (easier to avoid considering what's not needed), and so
on. I don't think making a "common" header is a good idea.
> ...and maybe, only maybe, what that 95% of people is trying to do in their
> horrible code is to deliver the best reasonably possible thing within their
> timeline while you are barking at them in chase of never to be released utter
> perfection.
Yeah. That's why it's good to teach people about many aspects of the C
language (which is not popular, in particular due to these nuances,
nowadays and we are starving for good developers).
> > Last to add, but not least is that your code may be used as an example
> > for others, hence we really have to do our best in order to avoid bad
> > design, practices, and cargo cults. If this requires more refactoring
> > of the existing code, then do it sooner than later.
...
> > > > > Andy made (mostly) the same remarks on this same patch ~1-year ago on
> > > > > this same patch while it was posted by Oleksii.
> > > > >
> > > > > And I told that time that most of the remarks around devm_ usage were
> > > > > wrong due to how the SCMI core handles protocol initialization (using a
> > > > > devres group transparently).
> > > > >
> > > > > This is what I answered that time.
> > > > >
> > > > > https://lore.kernel.org/linux-arm-kernel/ZJ78hBcjAhiU+ZBO@e120937-lin/#t
> > > > >
> > > > > I wont repeat myself, but, in a nutshell the memory allocation like it
> > > > > is now is fine: a bit happens via devm_ at protocol initialization, the
> > > > > other is doe via explicit kmalloc at runtime and freed via kfree at
> > > > > remove time (if needed...i.e. checking the present flag of some structs)
> > > >
> > > > This sounds like a mess. devm_ is expected to be used only for the
> > > > ->probe() stage, otherwise you may consider cleanup.h (__free() macro)
> > > > to have automatic free at the paths where memory is not needed.
> > >
> > > Indeed, this protocol_init code is called by the SCMI core once for all when
> > > an SCMI driver tries at first to use this specific protocol by 'getting' its
> > > protocol_ops, so it is indeed called inside the probe chain of the driver:
> > > at this point you *can* decide to use devres to allocate memory and be assured
> > > that if the init fails, or when the driver cease to use this protocol (calling
> > > its remove()) and no other driver is using it, all the stuff that have been
> > > allocated related to this protocol will be released by the core for you.
> > > (using an internal devres group)
> > >
> > > Without this you should handle manually all the deallocation manually on
> > > the init error-paths AND also provide all the cleanup explicitly when
> > > the protocol is no more used by any driver (multiple users of the same
> > > protocol instance are possible)...for all protocols.
> >
> > Yes. Is it a problem?
>
> Well, no, but is it not a repetitive and error-prone process ?
Yes. That's why we now have cleanup.h. Please, consider using it instead.
> Is it not the exact reason why devres management exist in first place, to avoid
> repetitive manual alloc/free of resources and related pitfalls ? (even though
> certainly it is normally used in a more conventional and straightforward way)
No. Its scope is to clean the probe-remove parts, one should not
spread it otherwise and one definitely should know its limitations and
corner cases (I even gave some examples back in ca. 2017 in one of my
presentation WRT typical mistakes the developers make
> The idea was to give some sort of aid in the SCMI stack for writing protocols,
> so regarding mem_mgmt, I just built on top of devres facilities, not invented
> anything, to try to avoid repetitions and let the core handle mem allocs/free
> during the probe phases as much as possible: in pinctrl case would be
> particularly trivial to instead manually allocate stuff at init (due to many
> lazy delayed allocations) but other protocols need a lot more to be done at init,
> frequently in a loop to allocate multiple resources descriptors, and manually
> undoing all of that on each error-path and on cleanup is definitely error-prone
> and a pain.
I understand the motivation, but again, devm is a beast in the corner
cases. I believe Laurent Pinchart gave a presentation about how bad
devm can hit you if you don't know what you are doing (OTOH it's hard
to know with devm).
> Last but not least, this whole thing was designed to address the needs of the
> protocols that existed at that time....it is only now with pinctrl lazy-allocations
> at runtime that the ugly cohexistence of devm_ and non-devm allocations became a
> thing....so clearly the thing needs to be improved/rethinked...even dropped if no
> more fitting...
>
> ... or alternatively since devres allocations are anyway optional, you could just
> use regular kmalloc/kfree for this protocol and avoid this dual handling...
Probably, just have a look at cleanup.h.
> ...this was just to put things in context...and I'll happily let Sudeep decide
> what he prefers in the immediate for pinctrl or more in general about all the
> scmi devres, that I've got enough of these pleasant interactions for now...
As I said, it's your call, I'm not preventing you from applying
whatever is going on in the SCMI subsystem. Just tried to point out
the problem(s).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 1/4] interconnect: qcom: icc-rpmh: Add QoS configuration support
From: Odelu Kukatla @ 2024-04-03 8:45 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Georgi Djakov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Kees Cook, cros-qcom-dts-watchers, Gustavo A . R . Silva,
linux-arm-msm, linux-pm, devicetree, linux-kernel,
linux-hardening, quic_rlaggysh, quic_mdtipton
In-Reply-To: <d59896bb-a559-4013-a615-37bb43278b2e@linaro.org>
On 3/27/2024 2:26 AM, Konrad Dybcio wrote:
> On 25.03.2024 7:16 PM, Odelu Kukatla wrote:
>> It adds QoS support for QNOC device and includes support for
>> configuring priority, priority forward disable, urgency forwarding.
>> This helps in priortizing the traffic originating from different
>> interconnect masters at NoC(Network On Chip).
>>
>> Signed-off-by: Odelu Kukatla <quic_okukatla@quicinc.com>
>> ---
>
> [...]
>
>>
>> + if (desc->config) {
>> + struct resource *res;
>> + void __iomem *base;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res)
>> + goto skip_qos_config;
>> +
>> + base = devm_ioremap_resource(dev, res);
>
> You were asked to substitute this call like 3 times already..
>
> devm_platform_get_and_ioremap_resource
>
> or even better, devm_platform_ioremap_resource
>
> [...]
>
>> @@ -70,6 +102,7 @@ struct qcom_icc_node {
>> u64 max_peak[QCOM_ICC_NUM_BUCKETS];
>> struct qcom_icc_bcm *bcms[MAX_BCM_PER_NODE];
>> size_t num_bcms;
>> + const struct qcom_icc_qosbox *qosbox;
>
> I believe I came up with a better approach for storing this.. see [1]
>
> Konrad
>
> [1] https://lore.kernel.org/linux-arm-msm/20240326-topic-rpm_icc_qos_cleanup-v1-4-357e736792be@linaro.org/
>
I see in this series, QoS parameters are moved into struct qcom_icc_desc.
Even though we program QoS at Provider/Bus level, it is property of the node/master connected to a Bus/NoC.
It will be easier later to know which master's QoS we are programming if we add in node data.
Readability point of view, it might be good to keep QoS parameters in node data.
Thanks,
Odelu
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: leds: add LED_FUNCTION_FNLOCK
From: Krzysztof Kozlowski @ 2024-04-03 8:46 UTC (permalink / raw)
To: Hans de Goede, Gergo Koteles, Ike Panhc, Ilpo Järvinen,
Pavel Machek, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: platform-driver-x86, linux-kernel, linux-leds, devicetree
In-Reply-To: <4956933c-49c4-49ab-a91a-7e0efcc211d5@redhat.com>
On 03/04/2024 10:39, Hans de Goede wrote:
>>>
>>> must have a dts user before being approved too ? Since
>>> that file is included from include/dt-bindings/input/input.h ?
>>
>> Wait, that's UAPI :) and we just share the constants. That's kind of
>> special case, but I get what you mean.
>>
>>>
>>> TL;DR: not only is this patch fine, this is actually
>>> the correct place to add such a define according to
>>> the docs in Documentation/leds/leds-class.rst :
>>>
>>> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>>
>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> Thanks. Is it ok for me to merge this through the pdx86
> tree (once I've reviewed the other 2 patches) ?
You need to sync (ack) with LED folks, because by default this should go
via LED subsystem.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v9 07/21] virt: geniezone: Add vm capability check
From: Yi-De Wu (吳一德) @ 2024-04-03 8:50 UTC (permalink / raw)
To: corbet@lwn.net, robh+dt@kernel.org, catalin.marinas@arm.com,
conor+dt@kernel.org, richardcochran@gmail.com,
Yingshiuan Pan (潘穎軒),
krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com,
Ze-yu Wang (王澤宇),
angelogioacchino.delregno@collabora.com, will@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
quic_tsoni@quicinc.com, MY Chuang (莊明躍),
Kevenny Hsieh (謝宜芸),
devicetree@vger.kernel.org,
PeiLun Suei (隋培倫),
Liju-clr Chen (陳麗如), dbrazdil@google.com,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
Shawn Hsiao (蕭志祥), linux-doc@vger.kernel.org,
Chi-shen Yeh (葉奇軒)
In-Reply-To: <c027bf67-e9b2-4eb2-9dee-a47a9c3bdd8a@collabora.com>
On Thu, 2024-02-01 at 10:44 +0100, AngeloGioacchino Del Regno wrote:
> Il 29/01/24 09:32, Yi-De Wu ha scritto:
> > From: "Yingshiuan Pan" <yingshiuan.pan@mediatek.com>
> >
> > Inquire the `capability support` on GenieZone hypervisor.
> > Example:
> > `GZVM_CAP_PROTECTED_VM` or `GZVM_CAP_VM_GPA_SIZE`.
> >
> > Signed-off-by: Yingshiuan Pan <yingshiuan.pan@mediatek.com>
> > Signed-off-by: Jerry Wang <ze-yu.wang@mediatek.com>
> > Signed-off-by: kevenny hsieh <kevenny.hsieh@mediatek.com>
> > Signed-off-by: Liju Chen <liju-clr.chen@mediatek.com>
> > Signed-off-by: Yi-De Wu <yi-de.wu@mediatek.com>
> > ---
> > arch/arm64/geniezone/gzvm_arch_common.h | 2 +
> > arch/arm64/geniezone/vm.c | 122
> > ++++++++++++++++++++++++
> > drivers/virt/geniezone/gzvm_main.c | 27 ++++++
> > drivers/virt/geniezone/gzvm_vm.c | 21 ++++
> > include/linux/gzvm_drv.h | 5 +
> > include/uapi/linux/gzvm.h | 31 ++++++
> > 6 files changed, 208 insertions(+)
> >
> > diff --git a/arch/arm64/geniezone/gzvm_arch_common.h
> > b/arch/arm64/geniezone/gzvm_arch_common.h
> > index 2f66e496dfae..383af0829f11 100644
> > --- a/arch/arm64/geniezone/gzvm_arch_common.h
> > +++ b/arch/arm64/geniezone/gzvm_arch_common.h
> > @@ -13,6 +13,7 @@ enum {
> > GZVM_FUNC_DESTROY_VM = 1,
> > GZVM_FUNC_SET_MEMREGION = 4,
> > GZVM_FUNC_PROBE = 12,
> > + GZVM_FUNC_ENABLE_CAP = 13,
>
> GZVM_FUNC_PROBE = 12,
> GZVM_FUNC_ENABLE_CAP,
>
Given that this is an API from the kernel to the hypervisor, it may be
utilized with various toolchains. Our intention is to explicitly assign
values to prevent any unexpected compiler behavior. For further
details, we'd like to refer to the discussion below.
https://lore.kernel.org/all/20200318125003.GA2727094@kroah.com/
> > NR_GZVM_FUNC,
> > };
> >
>
> Regards,
> Angelo
>
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: leds: add LED_FUNCTION_FNLOCK
From: Hans de Goede @ 2024-04-03 8:51 UTC (permalink / raw)
To: Krzysztof Kozlowski, Gergo Koteles, Ike Panhc, Ilpo Järvinen,
Pavel Machek, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: platform-driver-x86, linux-kernel, linux-leds, devicetree
In-Reply-To: <17a700a7-44f0-4e46-9a0c-4c2da44c9e27@linaro.org>
Hi,
On 4/3/24 10:46 AM, Krzysztof Kozlowski wrote:
> On 03/04/2024 10:39, Hans de Goede wrote:
>>>>
>>>> must have a dts user before being approved too ? Since
>>>> that file is included from include/dt-bindings/input/input.h ?
>>>
>>> Wait, that's UAPI :) and we just share the constants. That's kind of
>>> special case, but I get what you mean.
>>>
>>>>
>>>> TL;DR: not only is this patch fine, this is actually
>>>> the correct place to add such a define according to
>>>> the docs in Documentation/leds/leds-class.rst :
>>>>
>>>> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>>>
>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>
>> Thanks. Is it ok for me to merge this through the pdx86
>> tree (once I've reviewed the other 2 patches) ?
>
> You need to sync (ack) with LED folks, because by default this should go
> via LED subsystem.
Ok, will do.
Pavel, Lee can you give me an ack for merging this through the pdx86 tree?
Regards,
Hans
^ permalink raw reply
* [PATCH v11 1/7] dt-bindings: usb: usbmisc-imx: add fsl,imx8ulp-usbmisc compatible
From: Xu Yang @ 2024-04-03 9:04 UTC (permalink / raw)
To: gregkh, robh+dt, krzysztof.kozlowski+dt, shawnguo, conor+dt
Cc: s.hauer, kernel, festevam, linux-imx, jun.li, linux-usb,
devicetree, linux-arm-kernel, imx, linux-kernel
Add "fsl,imx8ulp-usbmisc" compatible.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v3:
- new patch due to missed this little one
Changes in v4:
- no changes
Changes in v5:
- add Acked-by tag
Changes in v6:
- no changes
Changes in v7:
- no changes
Changes in v8:
- no changes
Changes in v9:
- no changes
Changes in v10:
- no changes
Changes in v11:
- no changes
---
Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml b/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml
index 2d3589d284b2..0a6e7ac1b37e 100644
--- a/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml
+++ b/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml
@@ -33,6 +33,7 @@ properties:
- fsl,imx7ulp-usbmisc
- fsl,imx8mm-usbmisc
- fsl,imx8mn-usbmisc
+ - fsl,imx8ulp-usbmisc
- const: fsl,imx7d-usbmisc
- const: fsl,imx6q-usbmisc
- items:
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] ARM: dts: n900: set charge current limit to 950mA
From: Tony Lindgren @ 2024-04-03 9:03 UTC (permalink / raw)
To: Sicelo A. Mhlongo
Cc: devicetree, Benoît Cousson, Krzysztof Kozlowski,
Conor Dooley, linux-pm, pali, sre, spinal.by, maemo-leste,
linux-omap
In-Reply-To: <20240228083846.2401108-2-absicsz@gmail.com>
* Sicelo A. Mhlongo <absicsz@gmail.com> [240228 10:40]:
> From: Arthur Demchenkov <spinal.by@gmail.com>
>
> The vendor kernel used 950mA as the default. The same value works fine on
> the mainline Linux kernel, and has been tested extensively under Maemo
> Leste [1] and postmarketOS, who have been using it for a number of years.
Thanks applying into omap-for-v6.10/dt.
Tony
> [1] https://github.com/maemo-leste/n9xx-linux/commit/fbc4ce7a84e59215914a8981afe918002b191493
^ permalink raw reply
* [PATCH v11 2/7] arm64: dts: imx8ulp: add usb nodes
From: Xu Yang @ 2024-04-03 9:04 UTC (permalink / raw)
To: gregkh, robh+dt, krzysztof.kozlowski+dt, shawnguo, conor+dt
Cc: s.hauer, kernel, festevam, linux-imx, jun.li, linux-usb,
devicetree, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20240403090438.583326-1-xu.yang_2@nxp.com>
Add USB nodes on i.MX8ULP platform which has 2 USB controllers.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v2:
- no changes
Changes in v3:
- no changes
Changes in v4:
- no changes
Changes in v5:
- no changes
Changes in v6:
- drop usbphy aliases
Changes in v7:
- no changes
Changes in v8:
- no changes
Changes in v9:
- no changes
Changes in v10:
- no changes
Changes in v11:
- adjust reg order
---
arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 62 ++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
index c4a0082f30d3..cbed01bb8cc0 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
@@ -472,6 +472,68 @@ usdhc2: mmc@298f0000 {
status = "disabled";
};
+ usbotg1: usb@29900000 {
+ compatible = "fsl,imx8ulp-usb", "fsl,imx7ulp-usb", "fsl,imx6ul-usb";
+ reg = <0x29900000 0x200>;
+ interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc4 IMX8ULP_CLK_USB0>;
+ power-domains = <&scmi_devpd IMX8ULP_PD_USB0>;
+ phys = <&usbphy1>;
+ fsl,usbmisc = <&usbmisc1 0>;
+ ahb-burst-config = <0x0>;
+ tx-burst-size-dword = <0x8>;
+ rx-burst-size-dword = <0x8>;
+ status = "disabled";
+ };
+
+ usbmisc1: usbmisc@29900200 {
+ compatible = "fsl,imx8ulp-usbmisc", "fsl,imx7d-usbmisc",
+ "fsl,imx6q-usbmisc";
+ reg = <0x29900200 0x200>;
+ #index-cells = <1>;
+ status = "disabled";
+ };
+
+ usbphy1: usb-phy@29910000 {
+ compatible = "fsl,imx8ulp-usbphy", "fsl,imx7ulp-usbphy";
+ reg = <0x29910000 0x10000>;
+ interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc4 IMX8ULP_CLK_USB0_PHY>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
+ usbotg2: usb@29920000 {
+ compatible = "fsl,imx8ulp-usb", "fsl,imx7ulp-usb", "fsl,imx6ul-usb";
+ reg = <0x29920000 0x200>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc4 IMX8ULP_CLK_USB1>;
+ power-domains = <&scmi_devpd IMX8ULP_PD_USDHC2_USB1>;
+ phys = <&usbphy2>;
+ fsl,usbmisc = <&usbmisc2 0>;
+ ahb-burst-config = <0x0>;
+ tx-burst-size-dword = <0x8>;
+ rx-burst-size-dword = <0x8>;
+ status = "disabled";
+ };
+
+ usbmisc2: usbmisc@29920200 {
+ compatible = "fsl,imx8ulp-usbmisc", "fsl,imx7d-usbmisc",
+ "fsl,imx6q-usbmisc";
+ reg = <0x29920200 0x200>;
+ #index-cells = <1>;
+ status = "disabled";
+ };
+
+ usbphy2: usb-phy@29930000 {
+ compatible = "fsl,imx8ulp-usbphy", "fsl,imx7ulp-usbphy";
+ reg = <0x29930000 0x10000>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc4 IMX8ULP_CLK_USB1_PHY>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
fec: ethernet@29950000 {
compatible = "fsl,imx8ulp-fec", "fsl,imx6ul-fec", "fsl,imx6q-fec";
reg = <0x29950000 0x10000>;
--
2.34.1
^ permalink raw reply related
* [PATCH v11 3/7] arm64: dts: imx8ulp-evk: enable usb nodes and add ptn5150 nodes
From: Xu Yang @ 2024-04-03 9:04 UTC (permalink / raw)
To: gregkh, robh+dt, krzysztof.kozlowski+dt, shawnguo, conor+dt
Cc: s.hauer, kernel, festevam, linux-imx, jun.li, linux-usb,
devicetree, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20240403090438.583326-1-xu.yang_2@nxp.com>
Enable 2 USB nodes and add 2 PTN5150 nodes on i.MX8ULP evk board.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v2:
- fix format as suggusted by Fabio
- add PTN5150 nodes
Changes in v3:
- no changes
Changes in v4:
- no changes
Changes in v5:
- no changes
Changes in v6:
- no changes
Changes in v7:
- no changes
Changes in v8:
- no changes
Changes in v9:
- no changes
Changes in v10:
- no changes
Changes in v11:
- fix indent
- adjust order
---
arch/arm64/boot/dts/freescale/imx8ulp-evk.dts | 84 +++++++++++++++++++
1 file changed, 84 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
index 24bb253b938d..e937e5f8fa8b 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
@@ -127,12 +127,70 @@ &lpi2c7 {
pinctrl-1 = <&pinctrl_lpi2c7>;
status = "okay";
+ ptn5150_1: typec@1d {
+ compatible = "nxp,ptn5150";
+ reg = <0x1d>;
+ int-gpios = <&gpiof 3 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_typec1>;
+ status = "disabled";
+ };
+
pcal6408: gpio@21 {
compatible = "nxp,pcal9554b";
reg = <0x21>;
gpio-controller;
#gpio-cells = <2>;
};
+
+ ptn5150_2: typec@3d {
+ compatible = "nxp,ptn5150";
+ reg = <0x3d>;
+ int-gpios = <&gpiof 5 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_typec2>;
+ status = "disabled";
+ };
+};
+
+&usbotg1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb1>;
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ over-current-active-low;
+ status = "okay";
+};
+
+&usbphy1 {
+ fsl,tx-d-cal = <110>;
+ status = "okay";
+};
+
+&usbmisc1 {
+ status = "okay";
+};
+
+&usbotg2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb2>;
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ over-current-active-low;
+ status = "okay";
+};
+
+&usbphy2 {
+ fsl,tx-d-cal = <110>;
+ status = "okay";
+};
+
+&usbmisc2 {
+ status = "okay";
};
&usdhc0 {
@@ -224,6 +282,32 @@ MX8ULP_PAD_PTE13__LPI2C7_SDA 0x20
>;
};
+ pinctrl_typec1: typec1grp {
+ fsl,pins = <
+ MX8ULP_PAD_PTF3__PTF3 0x3
+ >;
+ };
+
+ pinctrl_typec2: typec2grp {
+ fsl,pins = <
+ MX8ULP_PAD_PTF5__PTF5 0x3
+ >;
+ };
+
+ pinctrl_usb1: usb1grp {
+ fsl,pins = <
+ MX8ULP_PAD_PTF2__USB0_ID 0x10003
+ MX8ULP_PAD_PTF4__USB0_OC 0x10003
+ >;
+ };
+
+ pinctrl_usb2: usb2grp {
+ fsl,pins = <
+ MX8ULP_PAD_PTD23__USB1_ID 0x10003
+ MX8ULP_PAD_PTF6__USB1_OC 0x10003
+ >;
+ };
+
pinctrl_usdhc0: usdhc0grp {
fsl,pins = <
MX8ULP_PAD_PTD1__SDHC0_CMD 0x3
--
2.34.1
^ permalink raw reply related
* [PATCH v11 4/7] ARM: dts: imx6: remove fsl,anatop property from usb controller node
From: Xu Yang @ 2024-04-03 9:04 UTC (permalink / raw)
To: gregkh, robh+dt, krzysztof.kozlowski+dt, shawnguo, conor+dt
Cc: s.hauer, kernel, festevam, linux-imx, jun.li, linux-usb,
devicetree, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20240403090438.583326-1-xu.yang_2@nxp.com>
This property is not needed for usb controller. The usb phy needs it
instead.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v7:
- new patch
Changes in v8:
- no changes
Changes in v9:
- no changes
Changes in v10:
- not remove fsl,anatop for imx6ul.dtsi since it's already removed
Changes in v11:
- no changes
---
arch/arm/boot/dts/nxp/imx/imx6sll.dtsi | 1 -
arch/arm/boot/dts/nxp/imx/imx6sx.dtsi | 2 --
2 files changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6sll.dtsi b/arch/arm/boot/dts/nxp/imx/imx6sll.dtsi
index 3659fd5ecfa6..ddeb5b37fb78 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6sll.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6sll.dtsi
@@ -683,7 +683,6 @@ usbotg1: usb@2184000 {
clocks = <&clks IMX6SLL_CLK_USBOH3>;
fsl,usbphy = <&usbphy1>;
fsl,usbmisc = <&usbmisc 0>;
- fsl,anatop = <&anatop>;
ahb-burst-config = <0x0>;
tx-burst-size-dword = <0x10>;
rx-burst-size-dword = <0x10>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6sx.dtsi b/arch/arm/boot/dts/nxp/imx/imx6sx.dtsi
index 0de359d62a47..6d3deba60de5 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6sx.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6sx.dtsi
@@ -929,7 +929,6 @@ usbotg1: usb@2184000 {
clocks = <&clks IMX6SX_CLK_USBOH3>;
fsl,usbphy = <&usbphy1>;
fsl,usbmisc = <&usbmisc 0>;
- fsl,anatop = <&anatop>;
ahb-burst-config = <0x0>;
tx-burst-size-dword = <0x10>;
rx-burst-size-dword = <0x10>;
@@ -957,7 +956,6 @@ usbh: usb@2184400 {
fsl,usbphy = <&usbphynop1>;
fsl,usbmisc = <&usbmisc 2>;
phy_type = "hsic";
- fsl,anatop = <&anatop>;
dr_mode = "host";
ahb-burst-config = <0x0>;
tx-burst-size-dword = <0x10>;
--
2.34.1
^ permalink raw reply related
* [PATCH v11 5/7] arm64: dts: imx93: add usb nodes
From: Xu Yang @ 2024-04-03 9:04 UTC (permalink / raw)
To: gregkh, robh+dt, krzysztof.kozlowski+dt, shawnguo, conor+dt
Cc: s.hauer, kernel, festevam, linux-imx, jun.li, linux-usb,
devicetree, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20240403090438.583326-1-xu.yang_2@nxp.com>
There are 2 USB controllers on i.MX93. Add them.
Acked-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa9352LA/CA
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v2:
- fix format as suggested by Alexander
- change compatible from fsl,imx8mm-usb to fsl,imx93-usb
Changes in v3:
- replace deprecated fsl,usbphy with phys as suggested by Alexander
- reorder nodes
Changes in v4:
- fix the alignment
Changes in v5:
- rename usb_wakeup_clk to usb_wakeup
Changes in v6:
- rename usb_ctrl_root_clk to usb_ctrl_root
Changes in v7:
- no changes
Changes in v8:
- no changes
Changes in v9:
- no changes
Changes in v10:
- no changes
Changes in v11:
- no changes
---
arch/arm64/boot/dts/freescale/imx93.dtsi | 58 ++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx93.dtsi b/arch/arm64/boot/dts/freescale/imx93.dtsi
index 601c94e1fac8..77b3009b048e 100644
--- a/arch/arm64/boot/dts/freescale/imx93.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx93.dtsi
@@ -183,6 +183,20 @@ mqs2: mqs2 {
status = "disabled";
};
+ usbphynop1: usbphynop1 {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0>;
+ clocks = <&clk IMX93_CLK_USB_PHY_BURUNIN>;
+ clock-names = "main_clk";
+ };
+
+ usbphynop2: usbphynop2 {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0>;
+ clocks = <&clk IMX93_CLK_USB_PHY_BURUNIN>;
+ clock-names = "main_clk";
+ };
+
soc@0 {
compatible = "simple-bus";
#address-cells = <1>;
@@ -1167,6 +1181,50 @@ media_blk_ctrl: system-controller@4ac10000 {
status = "disabled";
};
+ usbotg1: usb@4c100000 {
+ compatible = "fsl,imx93-usb", "fsl,imx7d-usb", "fsl,imx27-usb";
+ reg = <0x4c100000 0x200>;
+ interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX93_CLK_USB_CONTROLLER_GATE>,
+ <&clk IMX93_CLK_HSIO_32K_GATE>;
+ clock-names = "usb_ctrl_root", "usb_wakeup";
+ assigned-clocks = <&clk IMX93_CLK_HSIO>;
+ assigned-clock-parents = <&clk IMX93_CLK_SYS_PLL_PFD1_DIV2>;
+ assigned-clock-rates = <133000000>;
+ phys = <&usbphynop1>;
+ fsl,usbmisc = <&usbmisc1 0>;
+ status = "disabled";
+ };
+
+ usbmisc1: usbmisc@4c100200 {
+ compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-usbmisc",
+ "fsl,imx6q-usbmisc";
+ reg = <0x4c100200 0x200>;
+ #index-cells = <1>;
+ };
+
+ usbotg2: usb@4c200000 {
+ compatible = "fsl,imx93-usb", "fsl,imx7d-usb", "fsl,imx27-usb";
+ reg = <0x4c200000 0x200>;
+ interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX93_CLK_USB_CONTROLLER_GATE>,
+ <&clk IMX93_CLK_HSIO_32K_GATE>;
+ clock-names = "usb_ctrl_root", "usb_wakeup";
+ assigned-clocks = <&clk IMX93_CLK_HSIO>;
+ assigned-clock-parents = <&clk IMX93_CLK_SYS_PLL_PFD1_DIV2>;
+ assigned-clock-rates = <133000000>;
+ phys = <&usbphynop2>;
+ fsl,usbmisc = <&usbmisc2 0>;
+ status = "disabled";
+ };
+
+ usbmisc2: usbmisc@4c200200 {
+ compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-usbmisc",
+ "fsl,imx6q-usbmisc";
+ reg = <0x4c200200 0x200>;
+ #index-cells = <1>;
+ };
+
ddr-pmu@4e300dc0 {
compatible = "fsl,imx93-ddr-pmu";
reg = <0x4e300dc0 0x200>;
--
2.34.1
^ permalink raw reply related
* [PATCH v11 6/7] arm64: dts: imx93-11x11-evk: enable usb and typec nodes
From: Xu Yang @ 2024-04-03 9:04 UTC (permalink / raw)
To: gregkh, robh+dt, krzysztof.kozlowski+dt, shawnguo, conor+dt
Cc: s.hauer, kernel, festevam, linux-imx, jun.li, linux-usb,
devicetree, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20240403090438.583326-1-xu.yang_2@nxp.com>
There are 2 Type-C ports and 2 USB controllers on i.MX93. Enable them.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v2:
- remove status property in ptn5110 nodes
- fix dt-schema warnings
Changes in v3:
- no changes
Changes in v4:
- no changes
Changes in v5:
- no changes
Changes in v6:
- no changes
Changes in v7:
- no changes
Changes in v8:
- no changes
Changes in v9:
- use compatible "nxp,ptn5110", "tcpci"
Changes in v10:
- no changes
Changes in v11:
- remove "sleep" pinctrl state
- add newline
---
.../boot/dts/freescale/imx93-11x11-evk.dts | 119 ++++++++++++++++++
1 file changed, 119 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
index 9921ea13ab48..fc340d4573ce 100644
--- a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
@@ -5,6 +5,7 @@
/dts-v1/;
+#include <dt-bindings/usb/pd.h>
#include "imx93.dtsi"
/ {
@@ -104,6 +105,81 @@ &mu2 {
status = "okay";
};
+&lpi2c3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpi2c3>;
+ status = "okay";
+
+ ptn5110: tcpc@50 {
+ compatible = "nxp,ptn5110", "tcpci";
+ reg = <0x50>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
+
+ typec1_con: connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ power-role = "dual";
+ data-role = "dual";
+ try-power-role = "sink";
+ source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
+ PDO_VAR(5000, 20000, 3000)>;
+ op-sink-microwatt = <15000000>;
+ self-powered;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ typec1_dr_sw: endpoint {
+ remote-endpoint = <&usb1_drd_sw>;
+ };
+ };
+ };
+ };
+ };
+
+ ptn5110_2: tcpc@51 {
+ compatible = "nxp,ptn5110", "tcpci";
+ reg = <0x51>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
+
+ typec2_con: connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ power-role = "dual";
+ data-role = "dual";
+ try-power-role = "sink";
+ source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
+ PDO_VAR(5000, 20000, 3000)>;
+ op-sink-microwatt = <15000000>;
+ self-powered;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ typec2_dr_sw: endpoint {
+ remote-endpoint = <&usb2_drd_sw>;
+ };
+ };
+ };
+ };
+ };
+};
+
&eqos {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_eqos>;
@@ -156,6 +232,42 @@ &lpuart5 {
status = "okay";
};
+&usbotg1 {
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ usb-role-switch;
+ disable-over-current;
+ samsung,picophy-pre-emp-curr-control = <3>;
+ samsung,picophy-dc-vol-level-adjust = <7>;
+ status = "okay";
+
+ port {
+ usb1_drd_sw: endpoint {
+ remote-endpoint = <&typec1_dr_sw>;
+ };
+ };
+};
+
+&usbotg2 {
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ usb-role-switch;
+ disable-over-current;
+ samsung,picophy-pre-emp-curr-control = <3>;
+ samsung,picophy-dc-vol-level-adjust = <7>;
+ status = "okay";
+
+ port {
+ usb2_drd_sw: endpoint {
+ remote-endpoint = <&typec2_dr_sw>;
+ };
+ };
+};
+
&usdhc1 {
pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <&pinctrl_usdhc1>;
@@ -222,6 +334,13 @@ MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL 0x57e
>;
};
+ pinctrl_lpi2c3: lpi2c3grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO28__LPI2C3_SDA 0x40000b9e
+ MX93_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e
+ >;
+ };
+
pinctrl_uart1: uart1grp {
fsl,pins = <
MX93_PAD_UART1_RXD__LPUART1_RX 0x31e
--
2.34.1
^ permalink raw reply related
* [PATCH v11 7/7] arm64: dts: imx8mm/n remove clock-names property from usb controller node
From: Xu Yang @ 2024-04-03 9:04 UTC (permalink / raw)
To: gregkh, robh+dt, krzysztof.kozlowski+dt, shawnguo, conor+dt
Cc: s.hauer, kernel, festevam, linux-imx, jun.li, linux-usb,
devicetree, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20240403090438.583326-1-xu.yang_2@nxp.com>
The clock-names property is not needed by usb controller node on imx8mm/n.
This will remove it.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v9:
- new patch
Changes in v10:
- no changes
Changes in v11:
- no changes
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 2 --
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 1 -
2 files changed, 3 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 8a1b42b94dce..696e96b15585 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -1253,7 +1253,6 @@ usbotg1: usb@32e40000 {
reg = <0x32e40000 0x200>;
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk IMX8MM_CLK_USB1_CTRL_ROOT>;
- clock-names = "usb1_ctrl_root_clk";
assigned-clocks = <&clk IMX8MM_CLK_USB_BUS>;
assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_500M>;
phys = <&usbphynop1>;
@@ -1274,7 +1273,6 @@ usbotg2: usb@32e50000 {
reg = <0x32e50000 0x200>;
interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk IMX8MM_CLK_USB1_CTRL_ROOT>;
- clock-names = "usb1_ctrl_root_clk";
assigned-clocks = <&clk IMX8MM_CLK_USB_BUS>;
assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_500M>;
phys = <&usbphynop2>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 932c8b05c75f..f017faf87ecd 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -1213,7 +1213,6 @@ usbotg1: usb@32e40000 {
reg = <0x32e40000 0x200>;
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk IMX8MN_CLK_USB1_CTRL_ROOT>;
- clock-names = "usb1_ctrl_root_clk";
assigned-clocks = <&clk IMX8MN_CLK_USB_BUS>;
assigned-clock-parents = <&clk IMX8MN_SYS_PLL2_500M>;
phys = <&usbphynop1>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net-next v6 11/17] dt-bindings: net: pse-pd: Add another way of describing several PSE PIs
From: Kory Maincent @ 2024-04-03 9:15 UTC (permalink / raw)
To: Rob Herring
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Krzysztof Kozlowski,
Conor Dooley, Oleksij Rempel, Mark Brown, Frank Rowand,
Andrew Lunn, Heiner Kallweit, Russell King, Thomas Petazzoni,
netdev, linux-kernel, linux-doc, devicetree, Dent Project
In-Reply-To: <20240402132637.GA3744978-robh@kernel.org>
On Tue, 2 Apr 2024 08:26:37 -0500
Rob Herring <robh@kernel.org> wrote:
> > + pairset-names:
> > + $ref: /schemas/types.yaml#/definitions/string-array
> > + description:
> > + Names of the pairsets as per IEEE 802.3-2022, Section
> > 145.2.4.
> > + Valid values are "alternative-a" and "alternative-b". Each
> > name
>
> Don't state constraints in prose which are defined as schema
> constraints.
Ok, I will remove the line.
> > + pairsets:
> > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > + description:
> > + List of phandles, each pointing to the power supply for the
> > + corresponding pairset named in 'pairset-names'. This property
> > + aligns with IEEE 802.3-2022, Section 33.2.3 and 145.2.4.
> > + PSE Pinout Alternatives (as per IEEE 802.3-2022 Table
> > 145\u20133)
> > +
> > |-----------|---------------|---------------|---------------|---------------|
> > + | Conductor | Alternative A | Alternative A | Alternative B
> > | Alternative B |
> > + | | (MDI-X) | (MDI) | (X)
> > | (S) |
> > +
> > |-----------|---------------|---------------|---------------|---------------|
> > + | 1 | Negative VPSE | Positive VPSE | \u2014
> > | \u2014 |
> > + | 2 | Negative VPSE | Positive VPSE | \u2014
> > | \u2014 |
> > + | 3 | Positive VPSE | Negative VPSE | \u2014
> > | \u2014 |
> > + | 4 | \u2014 | \u2014 |
> > Negative VPSE | Positive VPSE |
> > + | 5 | \u2014 | \u2014 |
> > Negative VPSE | Positive VPSE |
> > + | 6 | Positive VPSE | Negative VPSE | \u2014
> > | \u2014 |
> > + | 7 | \u2014 | \u2014 |
> > Positive VPSE | Negative VPSE |
> > + | 8 | \u2014 | \u2014 |
> > Positive VPSE | Negative VPSE |
> > + minItems: 1
> > + maxItems: 2
>
> "pairsets" does not follow the normal design pattern of foos, foo-names,
> and #foo-cells. You could add #foo-cells I suppose, but what would cells
> convey? I don't think it's a good fit for what you need.
>
> The other oddity is the number of entries and the names are fixed. That
> is usually defined per consumer.
Theoretically if the RJ45 port binding was supported it would make more sense,
but in reality it's not feasible as the PSE controller need this information
in its init process.
The PSE controller reset all its port to apply a configuration so we can't do
it when the consumer (RJ45) probe. It would reset the other ports if one
consumer is probed later in the process.
> As each entry is just a power rail, why can't the regulator binding be
> used here?
Olekisj already answered about it.
PSE PI is like a regulator but with few different features and more information
like the pinout and the polarity, so we could not really fully rely on the
regulator binding style.
> > +
> > + polarity-supported:
> > + $ref: /schemas/types.yaml#/definitions/string-array
> > + description:
> > + Polarity configuration supported by the PSE PI pairsets.
> > + minItems: 1
> > + maxItems: 4
> > + items:
> > + enum:
> > + - MDI-X
> > + - MDI
> > + - X
> > + - S
> > +
> > + vpwr-supply:
> > + description: Regulator power supply for the PSE PI.
>
> I don't see this being used anywhere.
Right, I forgot to add it to the PD692x0 and TPS23881 binding example!
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v6 3/4] dt-bindings: watchdog: aspeed-wdt: Add aspeed,scu
From: PeterYin @ 2024-04-03 9:18 UTC (permalink / raw)
To: Andrew Jeffery, Rob Herring
Cc: patrick, Wim Van Sebroeck, Guenter Roeck, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, linux-watchdog, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <ab76b0549172cf3e33d6242fa9ea3e6a87b4a58e.camel@codeconstruct.com.au>
Thanks, I can wait you update it and send a new version for wdt driver.
Andrew Jeffery 於 4/2/24 20:09 寫道:
> I had a patch converting it in a local branch which I've now sent:
>
> https://lore.kernel.org/all/20240402120118.282035-1-andrew@codeconstruct.com.au/
>
> Perhaps we can pull it into this series?
^ permalink raw reply
* Re: [PATCH v2 02/18] PCI: endpoint: Introduce pci_epc_map_align()
From: Manivannan Sadhasivam @ 2024-04-03 9:21 UTC (permalink / raw)
To: Damien Le Moal
Cc: Lorenzo Pieralisi, Kishon Vijay Abraham I, Shawn Lin,
Krzysztof Wilczyński, Bjorn Helgaas, Heiko Stuebner,
linux-pci, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, linux-rockchip, linux-arm-kernel, Rick Wertenbroek,
Wilfred Mallawa, Niklas Cassel
In-Reply-To: <eb580d64-1110-479a-9a0b-c2f1eacd23e7@kernel.org>
On Wed, Apr 03, 2024 at 04:54:32PM +0900, Damien Le Moal wrote:
> On 4/3/24 16:45, Manivannan Sadhasivam wrote:
> > On Sat, Mar 30, 2024 at 01:19:12PM +0900, Damien Le Moal wrote:
> >> Some endpoint controllers have requirements on the alignment of the
> >> controller physical memory address that must be used to map a RC PCI
> >> address region. For instance, the rockchip endpoint controller uses
> >> at most the lower 20 bits of a physical memory address region as the
> >> lower bits of an RC PCI address. For mapping a PCI address region of
> >> size bytes starting from pci_addr, the exact number of address bits
> >> used is the number of address bits changing in the address range
> >> [pci_addr..pci_addr + size - 1].
> >>
> >> For this example, this creates the following constraints:
> >> 1) The offset into the controller physical memory allocated for a
> >> mapping depends on the mapping size *and* the starting PCI address
> >> for the mapping.
> >> 2) A mapping size cannot exceed the controller windows size (1MB) minus
> >> the offset needed into the allocated physical memory, which can end
> >> up being a smaller size than the desired mapping size.
> >>
> >> Handling these constraints independently of the controller being used in
> >> a PCI EP function driver is not possible with the current EPC API as
> >> it only provides the ->align field in struct pci_epc_features.
> >> Furthermore, this alignment is static and does not depend on a mapping
> >> pci address and size.
> >>
> >> Solve this by introducing the function pci_epc_map_align() and the
> >> endpoint controller operation ->map_align to allow endpoint function
> >> drivers to obtain the size and the offset into a controller address
> >> region that must be used to map an RC PCI address region. The size
> >> of the physical address region provided by pci_epc_map_align() can then
> >> be used as the size argument for the function pci_epc_mem_alloc_addr().
> >> The offset into the allocated controller memory can be used to
> >> correctly handle data transfers. Of note is that pci_epc_map_align() may
> >> indicate upon return a mapping size that is smaller (but not 0) than the
> >> requested PCI address region size. For such case, an endpoint function
> >> driver must handle data transfers in fragments.
> >>
> >
> > Is there any incentive in exposing pci_epc_map_align()? I mean, why can't it be
> > hidden inside the new alloc() API itself?
>
> I could drop pci_epc_map_align(), but the idea here was to have an API that is
> not restrictive. E.g., a function driver could allocate memory, keep it and
> repetedly use map_align and map() function to remap it to different PCI
> addresses. With your suggestion, that would not be possible.
>
Is there any requirement currently? If not, let's try to introduce it when the
actual requirement comes.
> >
> > Furthermore, is it possible to avoid the map_align() callback and handle the
> > alignment within the EPC driver?
>
> I am not so sure that this is possible because handling the alignment can
> potentially result in changing the amount of memory to allocate, based on the
> PCI address also. So the allocation API would need to change, a lot.
>
Hmm, looking at patch 11/18, I think it might become complicated.
- Mani
> >> + /*
> >> + * Assume a fixed alignment constraint as specified by the controller
> >> + * features.
> >> + */
> >> + features = pci_epc_get_features(epc, func_no, vfunc_no);
> >> + if (!features || !features->align) {
> >> + map->map_pci_addr = pci_addr;
> >> + map->map_size = size;
> >> + map->map_ofst = 0;
> >
> > These values are overwritten anyway below.
>
> Looks like "return" got dropped. Bug. Will re-add it.
>
>
> --
> Damien Le Moal
> Western Digital Research
>
--
மணிவண்ணன் சதாசிவம்
^ 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