* Re: [PATCH v2] arm64: dts: qcom: qcs6490-rb3gen2: Enable UFS
From: Konrad Dybcio @ 2024-04-04 18:50 UTC (permalink / raw)
To: Bjorn Andersson, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20240327-rb3gen2-ufs-v2-1-3de6b5dd78dd@quicinc.com>
On 3/28/24 03:01, Bjorn Andersson wrote:
> The rb3gen2 has UFS memory, adjust the necessary supply voltage and add
> the controller and phy nodes to enable this.
>
> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
^ permalink raw reply
* Re: [PATCH v3 08/29] mm: Define VM_SHADOW_STACK for RISC-V
From: David Hildenbrand @ 2024-04-04 18:58 UTC (permalink / raw)
To: Deepak Gupta, paul.walmsley, rick.p.edgecombe, broonie,
Szabolcs.Nagy, kito.cheng, keescook, ajones, conor.dooley, cleger,
atishp, alex, bjorn, alexghiti, samuel.holland, conor
Cc: linux-doc, linux-riscv, linux-kernel, devicetree, linux-mm,
linux-arch, linux-kselftest, corbet, palmer, aou, robh+dt,
krzysztof.kozlowski+dt, oleg, akpm, arnd, ebiederm, Liam.Howlett,
vbabka, lstoakes, shuah, brauner, andy.chiu, jerry.shih,
hankuan.chen, greentime.hu, evan, xiao.w.wang, charlie, apatel,
mchitale, dbarboza, sameo, shikemeng, willy, vincent.chen, guoren,
samitolvanen, songshuaishuai, gerg, heiko, bhe, jeeheng.sia, cyy,
maskray, ancientmodern4, mathis.salmen, cuiyunhui, bgray, mpe,
baruch, alx, catalin.marinas, revest, josh, shr, deller, omosnace,
ojeda, jhubbard
In-Reply-To: <20240403234054.2020347-9-debug@rivosinc.com>
On 04.04.24 01:34, Deepak Gupta wrote:
> VM_SHADOW_STACK is defined by x86 as vm flag to mark a shadow stack vma.
>
> x86 uses VM_HIGH_ARCH_5 bit but that limits shadow stack vma to 64bit only.
> arm64 follows same path (see links)
>
> To keep things simple, RISC-V follows the same.
> This patch adds `ss` for shadow stack in process maps.
>
> Links:
> https://lore.kernel.org/lkml/20231009-arm64-gcs-v6-12-78e55deaa4dd@kernel.org/#r
>
> Signed-off-by: Deepak Gupta <debug@rivosinc.com>
> ---
> fs/proc/task_mmu.c | 3 +++
> include/linux/mm.h | 11 ++++++++++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 3f78ebbb795f..d9d63eb74f0d 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -702,6 +702,9 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
> #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
> #ifdef CONFIG_X86_USER_SHADOW_STACK
> [ilog2(VM_SHADOW_STACK)] = "ss",
> +#endif
> +#ifdef CONFIG_RISCV_USER_CFI
> + [ilog2(VM_SHADOW_STACK)] = "ss",
> #endif
> };
> size_t i;
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index f5a97dec5169..64109f6c70f5 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -352,7 +352,16 @@ extern unsigned int kobjsize(const void *objp);
> * for more details on the guard size.
> */
> # define VM_SHADOW_STACK VM_HIGH_ARCH_5
> -#else
> +#endif
> +
> +#ifdef CONFIG_RISCV_USER_CFI
> +/*
> + * RISC-V is going along with using VM_HIGH_ARCH_5 bit position for shadow stack
> + */
Wow, really?! I could never have guesses that from the code :P
Just drop that comment. Are them semantics the same as for the x86 variant documented?
("VM_SHADOW_STACK should not be set with VM_SHARED because of lack of")
I assume so. So it might now make sense to merge both paths
#if defined(CONFIG_X86_USER_SHADOW_STACK) || defined(CONFIG_RISCV_USER_CFI)
or even introduce some ARCH_HAS_SHADOW_STACK so we can remove these
arch-specific thingies here.
--
Cheers,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v3 09/29] mm: abstract shadow stack vma behind `vma_is_shadow_stack`
From: David Hildenbrand @ 2024-04-04 19:02 UTC (permalink / raw)
To: Deepak Gupta, paul.walmsley, rick.p.edgecombe, broonie,
Szabolcs.Nagy, kito.cheng, keescook, ajones, conor.dooley, cleger,
atishp, alex, bjorn, alexghiti, samuel.holland, conor
Cc: linux-doc, linux-riscv, linux-kernel, devicetree, linux-mm,
linux-arch, linux-kselftest, corbet, palmer, aou, robh+dt,
krzysztof.kozlowski+dt, oleg, akpm, arnd, ebiederm, Liam.Howlett,
vbabka, lstoakes, shuah, brauner, andy.chiu, jerry.shih,
hankuan.chen, greentime.hu, evan, xiao.w.wang, charlie, apatel,
mchitale, dbarboza, sameo, shikemeng, willy, vincent.chen, guoren,
samitolvanen, songshuaishuai, gerg, heiko, bhe, jeeheng.sia, cyy,
maskray, ancientmodern4, mathis.salmen, cuiyunhui, bgray, mpe,
baruch, alx, catalin.marinas, revest, josh, shr, deller, omosnace,
ojeda, jhubbard, Mike Rapoport
In-Reply-To: <20240403234054.2020347-10-debug@rivosinc.com>
On 04.04.24 01:34, Deepak Gupta wrote:
> VM_SHADOW_STACK (alias to VM_HIGH_ARCH_5) to encode shadow stack VMA.
>
> This patch changes checks of VM_SHADOW_STACK flag in generic code to call
> to a function `vma_is_shadow_stack` which will return true if its a
> shadow stack vma and default stub (when support doesnt exist) returns false.
>
> Signed-off-by: Deepak Gupta <debug@rivosinc.com>
> Suggested-by: Mike Rapoport <rppt@kernel.org>
> ---
> include/linux/mm.h | 13 ++++++++++++-
> mm/gup.c | 5 +++--
> mm/internal.h | 2 +-
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 64109f6c70f5..9952937be659 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -363,8 +363,19 @@ extern unsigned int kobjsize(const void *objp);
>
> #ifndef VM_SHADOW_STACK
> # define VM_SHADOW_STACK VM_NONE
> +
> +static inline bool vma_is_shadow_stack(vm_flags_t vm_flags)
> +{
> + return false;
> +}
> +#else
> +static inline bool vma_is_shadow_stack(vm_flags_t vm_flags)
> +{
> + return (vm_flags & VM_SHADOW_STACK);
> +}
> #endif
You can simply do outside the ifdef
static inline bool vma_is_shadow_stack(vm_flags_t vm_flags)
{
return !!(vm_flags & VM_SHADOW_STACK);
}
This will work even when VM_SHADOW_STACK is defined to be VM_NONE.
>
> +
unrelated code change
> #if defined(CONFIG_X86)
> # define VM_PAT VM_ARCH_1 /* PAT reserves whole VMA at once (x86) */
> #elif defined(CONFIG_PPC)
> @@ -3473,7 +3484,7 @@ static inline unsigned long stack_guard_start_gap(struct vm_area_struct *vma)
> return stack_guard_gap;
>
> /* See reasoning around the VM_SHADOW_STACK definition */
> - if (vma->vm_flags & VM_SHADOW_STACK)
> + if (vma->vm_flags && vma_is_shadow_stack(vma->vm_flags))
Pretty sure:
if (vma_is_shadow_stack(vma->vm_flags))
> return PAGE_SIZE;
>
> return 0;
> diff --git a/mm/gup.c b/mm/gup.c
> index df83182ec72d..a7a02eb0a6b3 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1053,7 +1053,7 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags)
> !writable_file_mapping_allowed(vma, gup_flags))
> return -EFAULT;
>
> - if (!(vm_flags & VM_WRITE) || (vm_flags & VM_SHADOW_STACK)) {
> + if (!(vm_flags & VM_WRITE) || vma_is_shadow_stack(vm_flags)) {
> if (!(gup_flags & FOLL_FORCE))
> return -EFAULT;
> /* hugetlb does not support FOLL_FORCE|FOLL_WRITE. */
> @@ -1071,7 +1071,8 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags)
> if (!is_cow_mapping(vm_flags))
> return -EFAULT;
> }
> - } else if (!(vm_flags & VM_READ)) {
> + } else if (!(vm_flags & VM_READ) && !vma_is_shadow_stack(vm_flags)) {
> + /* reads allowed if its shadow stack vma */
> if (!(gup_flags & FOLL_FORCE))
> return -EFAULT;
> /*
Unless I am missing something, this is not a simple cleanup. It should
go into a separate patch with a clearly documented reason for that change.
--
Cheers,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v3 08/29] mm: Define VM_SHADOW_STACK for RISC-V
From: Mark Brown @ 2024-04-04 19:04 UTC (permalink / raw)
To: David Hildenbrand
Cc: Deepak Gupta, paul.walmsley, rick.p.edgecombe, Szabolcs.Nagy,
kito.cheng, keescook, ajones, conor.dooley, cleger, atishp, alex,
bjorn, alexghiti, samuel.holland, conor, linux-doc, linux-riscv,
linux-kernel, devicetree, linux-mm, linux-arch, linux-kselftest,
corbet, palmer, aou, robh+dt, krzysztof.kozlowski+dt, oleg, akpm,
arnd, ebiederm, Liam.Howlett, vbabka, lstoakes, shuah, brauner,
andy.chiu, jerry.shih, hankuan.chen, greentime.hu, evan,
xiao.w.wang, charlie, apatel, mchitale, dbarboza, sameo,
shikemeng, willy, vincent.chen, guoren, samitolvanen,
songshuaishuai, gerg, heiko, bhe, jeeheng.sia, cyy, maskray,
ancientmodern4, mathis.salmen, cuiyunhui, bgray, mpe, baruch, alx,
catalin.marinas, revest, josh, shr, deller, omosnace, ojeda,
jhubbard
In-Reply-To: <8fb37319-288c-4f77-9cd7-92f17bb567ee@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 375 bytes --]
On Thu, Apr 04, 2024 at 08:58:06PM +0200, David Hildenbrand wrote:
> or even introduce some ARCH_HAS_SHADOW_STACK so we can remove these
> arch-specific thingies here.
It would be convenient if you could pull the ARCH_HAS_USER_SHADOW_STACK
patch out of my clone3 series to do that:
https://lore.kernel.org/all/20240203-clone3-shadow-stack-v5-3-322c69598e4b@kernel.org/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [RFC PATCH 1/2] dt-bindings: pcie: Document QCOM PCIE ECAM compatible root complex
From: Mayank Rana @ 2024-04-04 19:11 UTC (permalink / raw)
To: linux-pci, lpieralisi, kw, robh, bhelgaas, andersson,
manivannan.sadhasivam, krzysztof.kozlowski+dt, conor+dt,
devicetree
Cc: linux-arm-msm, quic_ramkri, quic_nkela, quic_shazhuss,
quic_msarkar, quic_nitegupt, Mayank Rana
In-Reply-To: <1712257884-23841-1-git-send-email-quic_mrana@quicinc.com>
On some of Qualcomm platform, firmware configures PCIe controller in RC
mode with static iATU window mappings of configuration space for entire
supported bus range in ECAM compatible mode. Firmware also manages PCIe
PHY as well required system resources. Here document properties and
required configuration to power up QCOM PCIe ECAM compatible root complex
and PHY for PCIe functionality.
Signed-off-by: Mayank Rana <quic_mrana@quicinc.com>
---
.../devicetree/bindings/pci/qcom,pcie-ecam.yaml | 94 ++++++++++++++++++++++
1 file changed, 94 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml
new file mode 100644
index 00000000..c209f12
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/qcom,pcie-ecam.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm ECAM compliant PCI express root complex
+
+description: |
+ Qualcomm SOC based ECAM compatible PCIe root complex supporting MSI controller.
+ Firmware configures PCIe controller in RC mode with static iATU window mappings
+ of configuration space for entire supported bus range in ECAM compatible mode.
+
+maintainers:
+ - Mayank Rana <quic_mrana@quicinc.com>
+
+allOf:
+ - $ref: /schemas/pci/pci-bus.yaml#
+ - $ref: /schemas/power-domain/power-domain-consumer.yaml
+
+properties:
+ compatible:
+ const: qcom,pcie-ecam-rc
+
+ reg:
+ minItems: 1
+ description: ECAM address space starting from root port till supported bus range
+
+ interrupts:
+ minItems: 1
+ maxItems: 8
+
+ ranges:
+ minItems: 2
+ maxItems: 3
+
+ iommu-map:
+ minItems: 1
+ maxItems: 16
+
+ power-domains:
+ maxItems: 1
+ description: A phandle to node which is able support way to communicate with firmware
+ for enabling PCIe controller and PHY as well managing all system resources needed to
+ make both controller and PHY operational for PCIe functionality.
+
+ dma-coherent: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - ranges
+ - power-domains
+ - device_type
+ - linux,pci-domain
+ - bus-range
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pcie0: pci@1c00000 {
+ compatible = "qcom,pcie-ecam-rc";
+ reg = <0x4 0x00000000 0 0x10000000>;
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x01000000 0x0 0x40000000 0x0 0x40000000 0x0 0x100000>,
+ <0x02000000 0x0 0x40100000 0x0 0x40100000 0x0 0x1ff00000>,
+ <0x43000000 0x4 0x10100000 0x4 0x10100000 0x0 0x100000>;
+ bus-range = <0x00 0xff>;
+ dma-coherent;
+ linux,pci-domain = <0>;
+ power-domains = <&scmi5_pd 0>;
+ power-domain-names = "power";
+ iommu-map = <0x0 &pcie_smmu 0x0000 0x1>,
+ <0x100 &pcie_smmu 0x0001 0x1>;
+ interrupt-parent = <&intc>;
+ interrupts = <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+...
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 0/2] Add Qualcomm PCIe ECAM root complex driver
From: Mayank Rana @ 2024-04-04 19:11 UTC (permalink / raw)
To: linux-pci, lpieralisi, kw, robh, bhelgaas, andersson,
manivannan.sadhasivam, krzysztof.kozlowski+dt, conor+dt,
devicetree
Cc: linux-arm-msm, quic_ramkri, quic_nkela, quic_shazhuss,
quic_msarkar, quic_nitegupt, Mayank Rana
On some of Qualcomm platform, firmware takes care of system resources
related to PCIe PHY and controller as well bringing up PCIe link and
having static iATU configuration for PCIe controller to work into
ECAM compliant mode. Hence add Qualcomm PCIe ECAM root complex driver.
Tested:
- Validated NVME functionality with PCIe0 and PCIe1 on SA877p-ride platform
Mayank Rana (2):
dt-bindings: pcie: Document QCOM PCIE ECAM compatible root complex
PCI: Add Qualcomm PCIe ECAM root complex driver
.../devicetree/bindings/pci/qcom,pcie-ecam.yaml | 94 ++++
drivers/pci/controller/Kconfig | 12 +
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pcie-qcom-ecam.c | 575 +++++++++++++++++++++
4 files changed, 682 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml
create mode 100644 drivers/pci/controller/pcie-qcom-ecam.c
--
2.7.4
^ permalink raw reply
* [RFC PATCH 2/2] PCI: Add Qualcomm PCIe ECAM root complex driver
From: Mayank Rana @ 2024-04-04 19:11 UTC (permalink / raw)
To: linux-pci, lpieralisi, kw, robh, bhelgaas, andersson,
manivannan.sadhasivam, krzysztof.kozlowski+dt, conor+dt,
devicetree
Cc: linux-arm-msm, quic_ramkri, quic_nkela, quic_shazhuss,
quic_msarkar, quic_nitegupt, Mayank Rana
In-Reply-To: <1712257884-23841-1-git-send-email-quic_mrana@quicinc.com>
On some of Qualcomm platform, firmware configures PCIe controller into
ECAM mode allowing static memory allocation for configuration space of
supported bus range. Firmware also takes care of bringing up PCIe PHY
and performing required operation to bring PCIe link into D0. Firmware
also manages system resources (e.g. clocks/regulators/resets/ bus voting).
Hence add Qualcomm PCIe ECAM root complex driver which enumerates PCIe
root complex and connected PCIe devices. Firmware won't be enumerating
or powering up PCIe root complex until this driver invokes power domain
based notification to bring PCIe link into D0/D3cold mode.
This driver also support MSI functionality using PCIe controller based
MSI controller as GIC ITS based MSI functionality is not available on
some of platform.
Signed-off-by: Mayank Rana <quic_mrana@quicinc.com>
---
drivers/pci/controller/Kconfig | 12 +
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pcie-qcom-ecam.c | 575 ++++++++++++++++++++++++++++++++
3 files changed, 588 insertions(+)
create mode 100644 drivers/pci/controller/pcie-qcom-ecam.c
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index e534c02..abbd9f2 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -353,6 +353,18 @@ config PCIE_XILINX_CPM
Say 'Y' here if you want kernel support for the
Xilinx Versal CPM host bridge.
+config PCIE_QCOM_ECAM
+ tristate "QCOM PCIe ECAM host controller"
+ depends on ARCH_QCOM && PCI
+ depends on OF
+ select PCI_MSI
+ select PCI_HOST_COMMON
+ select IRQ_DOMAIN
+ help
+ Say 'Y' here if you want to use ECAM shift mode compatible Qualcomm
+ PCIe root host controller. The controller is programmed using firmware
+ to support ECAM compatible memory address space.
+
source "drivers/pci/controller/cadence/Kconfig"
source "drivers/pci/controller/dwc/Kconfig"
source "drivers/pci/controller/mobiveil/Kconfig"
diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
index f2b19e6..2f1ee1e 100644
--- a/drivers/pci/controller/Makefile
+++ b/drivers/pci/controller/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_PCI_LOONGSON) += pci-loongson.o
obj-$(CONFIG_PCIE_HISI_ERR) += pcie-hisi-error.o
obj-$(CONFIG_PCIE_APPLE) += pcie-apple.o
obj-$(CONFIG_PCIE_MT7621) += pcie-mt7621.o
+obj-$(CONFIG_PCIE_QCOM_ECAM) += pcie-qcom-ecam.o
# pcie-hisi.o quirks are needed even without CONFIG_PCIE_DW
obj-y += dwc/
diff --git a/drivers/pci/controller/pcie-qcom-ecam.c b/drivers/pci/controller/pcie-qcom-ecam.c
new file mode 100644
index 00000000..5b4c68b
--- /dev/null
+++ b/drivers/pci/controller/pcie-qcom-ecam.c
@@ -0,0 +1,575 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Qualcomm PCIe ECAM root host controller driver
+ * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/irq.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/irqdomain.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/msi.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_pci.h>
+#include <linux/pci.h>
+#include <linux/pci-ecam.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/pm_runtime.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+
+#define PCIE_MSI_CTRL_BASE (0x820)
+#define PCIE_MSI_CTRL_SIZE (0x68)
+#define PCIE_MSI_CTRL_ADDR_OFFS (0x0)
+#define PCIE_MSI_CTRL_UPPER_ADDR_OFFS (0x4)
+#define PCIE_MSI_CTRL_INT_N_EN_OFFS(n) (0x8 + 0xc * (n))
+#define PCIE_MSI_CTRL_INT_N_MASK_OFFS(n) (0xc + 0xc * (n))
+#define PCIE_MSI_CTRL_INT_N_STATUS_OFFS(n) (0x10 + 0xc * (n))
+
+#define MSI_DB_ADDR 0xa0000000
+#define MSI_IRQ_PER_GRP (32)
+
+/**
+ * struct qcom_msi_irq - MSI IRQ information
+ * @client: pointer to MSI client struct
+ * @grp: group the irq belongs to
+ * @grp_index: index in group
+ * @hwirq: hwirq number
+ * @virq: virq number
+ * @pos: position in MSI bitmap
+ */
+struct qcom_msi_irq {
+ struct qcom_msi_client *client;
+ struct qcom_msi_grp *grp;
+ unsigned int grp_index;
+ unsigned int hwirq;
+ unsigned int virq;
+ u32 pos;
+};
+
+/**
+ * struct qcom_msi_grp - MSI group information
+ * @int_en_reg: memory-mapped interrupt enable register address
+ * @int_mask_reg: memory-mapped interrupt mask register address
+ * @int_status_reg: memory-mapped interrupt status register address
+ * @mask: tracks masked/unmasked MSI
+ * @irqs: structure to MSI IRQ information
+ */
+struct qcom_msi_grp {
+ void __iomem *int_en_reg;
+ void __iomem *int_mask_reg;
+ void __iomem *int_status_reg;
+ u32 mask;
+ struct qcom_msi_irq irqs[MSI_IRQ_PER_GRP];
+};
+
+/**
+ * struct qcom_msi - PCIe controller based MSI controller information
+ * @clients: list for tracking clients
+ * @dev: platform device node
+ * @nr_hwirqs: total number of hardware IRQs
+ * @nr_virqs: total number of virqs
+ * @nr_grps: total number of groups
+ * @grps: pointer to all groups information
+ * @bitmap: tracks used/unused MSI
+ * @mutex: for modifying MSI client list and bitmap
+ * @inner_domain: parent domain; gen irq related
+ * @msi_domain: child domain; pcie related
+ * @msi_db_addr: MSI doorbell address
+ * @cfg_lock: lock for configuring MSI controller registers
+ * @pcie_msi_cfg: memory-mapped MSI controller register space
+ */
+struct qcom_msi {
+ struct list_head clients;
+ struct device *dev;
+ int nr_hwirqs;
+ int nr_virqs;
+ int nr_grps;
+ struct qcom_msi_grp *grps;
+ unsigned long *bitmap;
+ struct mutex mutex;
+ struct irq_domain *inner_domain;
+ struct irq_domain *msi_domain;
+ phys_addr_t msi_db_addr;
+ spinlock_t cfg_lock;
+ void __iomem *pcie_msi_cfg;
+};
+
+/**
+ * struct qcom_msi_client - structure for each client of MSI controller
+ * @node: list to track number of MSI clients
+ * @msi: client specific MSI controller based resource pointer
+ * @dev: client's dev of pci_dev
+ * @nr_irqs: number of irqs allocated for client
+ * @msi_addr: MSI doorbell address
+ */
+struct qcom_msi_client {
+ struct list_head node;
+ struct qcom_msi *msi;
+ struct device *dev;
+ unsigned int nr_irqs;
+ phys_addr_t msi_addr;
+};
+
+static void qcom_msi_handler(struct irq_desc *desc)
+{
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct qcom_msi_grp *msi_grp;
+ u32 status;
+ int i;
+
+ chained_irq_enter(chip, desc);
+
+ msi_grp = irq_desc_get_handler_data(desc);
+ status = readl_relaxed(msi_grp->int_status_reg);
+ status ^= (msi_grp->mask & status);
+ writel(status, msi_grp->int_status_reg);
+
+ for (i = 0; status; i++, status >>= 1)
+ if (status & 0x1)
+ generic_handle_irq(msi_grp->irqs[i].virq);
+
+ chained_irq_exit(chip, desc);
+}
+
+static void qcom_msi_mask_irq(struct irq_data *data)
+{
+ struct irq_data *parent_data;
+ struct qcom_msi_irq *msi_irq;
+ struct qcom_msi_grp *msi_grp;
+ struct qcom_msi *msi;
+ unsigned long flags;
+
+ parent_data = data->parent_data;
+ if (!parent_data)
+ return;
+
+ msi_irq = irq_data_get_irq_chip_data(parent_data);
+ msi = msi_irq->client->msi;
+ msi_grp = msi_irq->grp;
+
+ spin_lock_irqsave(&msi->cfg_lock, flags);
+ pci_msi_mask_irq(data);
+ msi_grp->mask |= BIT(msi_irq->grp_index);
+ writel(msi_grp->mask, msi_grp->int_mask_reg);
+ spin_unlock_irqrestore(&msi->cfg_lock, flags);
+}
+
+static void qcom_msi_unmask_irq(struct irq_data *data)
+{
+ struct irq_data *parent_data;
+ struct qcom_msi_irq *msi_irq;
+ struct qcom_msi_grp *msi_grp;
+ struct qcom_msi *msi;
+ unsigned long flags;
+
+ parent_data = data->parent_data;
+ if (!parent_data)
+ return;
+
+ msi_irq = irq_data_get_irq_chip_data(parent_data);
+ msi = msi_irq->client->msi;
+ msi_grp = msi_irq->grp;
+
+ spin_lock_irqsave(&msi->cfg_lock, flags);
+ msi_grp->mask &= ~BIT(msi_irq->grp_index);
+ writel(msi_grp->mask, msi_grp->int_mask_reg);
+ pci_msi_unmask_irq(data);
+ spin_unlock_irqrestore(&msi->cfg_lock, flags);
+}
+
+static struct irq_chip qcom_msi_irq_chip = {
+ .name = "qcom_pci_msi",
+ .irq_enable = qcom_msi_unmask_irq,
+ .irq_disable = qcom_msi_mask_irq,
+ .irq_mask = qcom_msi_mask_irq,
+ .irq_unmask = qcom_msi_unmask_irq,
+};
+
+static int qcom_msi_domain_prepare(struct irq_domain *domain, struct device *dev,
+ int nvec, msi_alloc_info_t *arg)
+{
+ struct qcom_msi *msi = domain->parent->host_data;
+ struct qcom_msi_client *client;
+
+ client = kzalloc(sizeof(*client), GFP_KERNEL);
+ if (!client)
+ return -ENOMEM;
+
+ client->msi = msi;
+ client->dev = dev;
+ client->msi_addr = msi->msi_db_addr;
+ mutex_lock(&msi->mutex);
+ list_add_tail(&client->node, &msi->clients);
+ mutex_unlock(&msi->mutex);
+
+ /* zero out struct for pcie msi framework */
+ memset(arg, 0, sizeof(*arg));
+ return 0;
+}
+
+static struct msi_domain_ops qcom_msi_domain_ops = {
+ .msi_prepare = qcom_msi_domain_prepare,
+};
+
+static struct msi_domain_info qcom_msi_domain_info = {
+ .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
+ MSI_FLAG_MULTI_PCI_MSI | MSI_FLAG_PCI_MSIX),
+ .ops = &qcom_msi_domain_ops,
+ .chip = &qcom_msi_irq_chip,
+};
+
+static int qcom_msi_irq_set_affinity(struct irq_data *data,
+ const struct cpumask *mask, bool force)
+{
+ struct irq_data *parent_data = irq_get_irq_data(irqd_to_hwirq(data));
+ int ret = 0;
+
+ if (!parent_data)
+ return -ENODEV;
+
+ /* set affinity for MSI HW IRQ */
+ if (parent_data->chip->irq_set_affinity)
+ ret = parent_data->chip->irq_set_affinity(parent_data, mask, force);
+
+ return ret;
+}
+
+static void qcom_msi_irq_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
+{
+ struct irq_data *parent_data = irq_get_irq_data(irqd_to_hwirq(data));
+ struct qcom_msi_irq *msi_irq = irq_data_get_irq_chip_data(data);
+ struct qcom_msi_client *client = msi_irq->client;
+
+ if (!parent_data)
+ return;
+
+ msg->address_lo = lower_32_bits(client->msi_addr);
+ msg->address_hi = upper_32_bits(client->msi_addr);
+ msg->data = msi_irq->pos;
+}
+
+static struct irq_chip qcom_msi_bottom_irq_chip = {
+ .name = "qcom_msi",
+ .irq_set_affinity = qcom_msi_irq_set_affinity,
+ .irq_compose_msi_msg = qcom_msi_irq_compose_msi_msg,
+};
+
+static int qcom_msi_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
+ unsigned int nr_irqs, void *args)
+{
+ struct device *dev = ((msi_alloc_info_t *)args)->desc->dev;
+ struct qcom_msi_client *tmp, *client = NULL;
+ struct qcom_msi *msi = domain->host_data;
+ int i, ret = 0;
+ int pos;
+
+ mutex_lock(&msi->mutex);
+ list_for_each_entry(tmp, &msi->clients, node) {
+ if (tmp->dev == dev) {
+ client = tmp;
+ break;
+ }
+ }
+
+ if (!client) {
+ dev_err(msi->dev, "failed to find MSI client dev\n");
+ ret = -ENODEV;
+ goto out;
+ }
+
+ pos = bitmap_find_next_zero_area(msi->bitmap, msi->nr_virqs, 0,
+ nr_irqs, nr_irqs - 1);
+ if (pos > msi->nr_virqs) {
+ ret = -ENOSPC;
+ goto out;
+ }
+
+ bitmap_set(msi->bitmap, pos, nr_irqs);
+ for (i = 0; i < nr_irqs; i++) {
+ u32 grp = pos / MSI_IRQ_PER_GRP;
+ u32 index = pos % MSI_IRQ_PER_GRP;
+ struct qcom_msi_irq *msi_irq = &msi->grps[grp].irqs[index];
+
+ msi_irq->virq = virq + i;
+ msi_irq->client = client;
+ irq_domain_set_info(domain, msi_irq->virq,
+ msi_irq->hwirq,
+ &qcom_msi_bottom_irq_chip, msi_irq,
+ handle_simple_irq, NULL, NULL);
+ client->nr_irqs++;
+ pos++;
+ }
+out:
+ mutex_unlock(&msi->mutex);
+ return ret;
+}
+
+static void qcom_msi_irq_domain_free(struct irq_domain *domain, unsigned int virq,
+ unsigned int nr_irqs)
+{
+ struct irq_data *data = irq_domain_get_irq_data(domain, virq);
+ struct qcom_msi_client *client;
+ struct qcom_msi_irq *msi_irq;
+ struct qcom_msi *msi;
+
+ if (!data)
+ return;
+
+ msi_irq = irq_data_get_irq_chip_data(data);
+ client = msi_irq->client;
+ msi = client->msi;
+
+ mutex_lock(&msi->mutex);
+ bitmap_clear(msi->bitmap, msi_irq->pos, nr_irqs);
+
+ client->nr_irqs -= nr_irqs;
+ if (!client->nr_irqs) {
+ list_del(&client->node);
+ kfree(client);
+ }
+ mutex_unlock(&msi->mutex);
+
+ irq_domain_free_irqs_parent(domain, virq, nr_irqs);
+}
+
+static const struct irq_domain_ops msi_domain_ops = {
+ .alloc = qcom_msi_irq_domain_alloc,
+ .free = qcom_msi_irq_domain_free,
+};
+
+static int qcom_msi_alloc_domains(struct qcom_msi *msi)
+{
+ msi->inner_domain = irq_domain_add_linear(NULL, msi->nr_virqs,
+ &msi_domain_ops, msi);
+ if (!msi->inner_domain) {
+ dev_err(msi->dev, "failed to create IRQ inner domain\n");
+ return -ENOMEM;
+ }
+
+ msi->msi_domain = pci_msi_create_irq_domain(of_node_to_fwnode(msi->dev->of_node),
+ &qcom_msi_domain_info, msi->inner_domain);
+ if (!msi->msi_domain) {
+ dev_err(msi->dev, "failed to create MSI domain\n");
+ irq_domain_remove(msi->inner_domain);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static int qcom_msi_irq_setup(struct qcom_msi *msi)
+{
+ struct qcom_msi_grp *msi_grp;
+ struct qcom_msi_irq *msi_irq;
+ int i, index, ret;
+ unsigned int irq;
+
+ /* setup each MSI group. nr_hwirqs == nr_grps */
+ for (i = 0; i < msi->nr_hwirqs; i++) {
+ irq = irq_of_parse_and_map(msi->dev->of_node, i);
+ if (!irq) {
+ dev_err(msi->dev,
+ "MSI: failed to parse/map interrupt\n");
+ ret = -ENODEV;
+ goto free_irqs;
+ }
+
+ msi_grp = &msi->grps[i];
+ msi_grp->int_en_reg = msi->pcie_msi_cfg +
+ PCIE_MSI_CTRL_INT_N_EN_OFFS(i);
+ msi_grp->int_mask_reg = msi->pcie_msi_cfg +
+ PCIE_MSI_CTRL_INT_N_MASK_OFFS(i);
+ msi_grp->int_status_reg = msi->pcie_msi_cfg +
+ PCIE_MSI_CTRL_INT_N_STATUS_OFFS(i);
+
+ for (index = 0; index < MSI_IRQ_PER_GRP; index++) {
+ msi_irq = &msi_grp->irqs[index];
+
+ msi_irq->grp = msi_grp;
+ msi_irq->grp_index = index;
+ msi_irq->pos = (i * MSI_IRQ_PER_GRP) + index;
+ msi_irq->hwirq = irq;
+ }
+
+ irq_set_chained_handler_and_data(irq, qcom_msi_handler, msi_grp);
+ }
+
+ return 0;
+
+free_irqs:
+ for (--i; i >= 0; i--) {
+ irq = msi->grps[i].irqs[0].hwirq;
+
+ irq_set_chained_handler_and_data(irq, NULL, NULL);
+ irq_dispose_mapping(irq);
+ }
+
+ return ret;
+}
+
+static void qcom_msi_config(struct irq_domain *domain)
+{
+ struct qcom_msi *msi;
+ int i;
+
+ msi = domain->parent->host_data;
+
+ /* program termination address */
+ writel(msi->msi_db_addr, msi->pcie_msi_cfg + PCIE_MSI_CTRL_ADDR_OFFS);
+ writel(0, msi->pcie_msi_cfg + PCIE_MSI_CTRL_UPPER_ADDR_OFFS);
+
+ /* restore mask and enable all interrupts for each group */
+ for (i = 0; i < msi->nr_grps; i++) {
+ struct qcom_msi_grp *msi_grp = &msi->grps[i];
+
+ writel(msi_grp->mask, msi_grp->int_mask_reg);
+ writel(~0, msi_grp->int_en_reg);
+ }
+}
+
+static void qcom_msi_deinit(struct qcom_msi *msi)
+{
+ irq_domain_remove(msi->msi_domain);
+ irq_domain_remove(msi->inner_domain);
+}
+
+static struct qcom_msi *qcom_msi_init(struct device *dev)
+{
+ struct qcom_msi *msi;
+ u64 addr;
+ int ret;
+
+ msi = devm_kzalloc(dev, sizeof(*msi), GFP_KERNEL);
+ if (!msi)
+ return ERR_PTR(-ENOMEM);
+
+ msi->dev = dev;
+ mutex_init(&msi->mutex);
+ spin_lock_init(&msi->cfg_lock);
+ INIT_LIST_HEAD(&msi->clients);
+
+ msi->msi_db_addr = MSI_DB_ADDR;
+ msi->nr_hwirqs = of_irq_count(dev->of_node);
+ if (!msi->nr_hwirqs) {
+ dev_err(msi->dev, "no hwirqs found\n");
+ return ERR_PTR(-ENODEV);
+ }
+
+ if (of_property_read_reg(dev->of_node, 0, &addr, NULL) < 0) {
+ dev_err(msi->dev, "failed to get reg address\n");
+ return ERR_PTR(-ENODEV);
+ }
+
+ dev_dbg(msi->dev, "hwirq:%d pcie_msi_cfg:%llx\n", msi->nr_hwirqs, addr);
+ msi->pcie_msi_cfg = devm_ioremap(dev, addr + PCIE_MSI_CTRL_BASE, PCIE_MSI_CTRL_SIZE);
+ if (!msi->pcie_msi_cfg)
+ return ERR_PTR(-ENOMEM);
+
+ msi->nr_virqs = msi->nr_hwirqs * MSI_IRQ_PER_GRP;
+ msi->nr_grps = msi->nr_hwirqs;
+ msi->grps = devm_kcalloc(dev, msi->nr_grps, sizeof(*msi->grps), GFP_KERNEL);
+ if (!msi->grps)
+ return ERR_PTR(-ENOMEM);
+
+ msi->bitmap = devm_kcalloc(dev, BITS_TO_LONGS(msi->nr_virqs),
+ sizeof(*msi->bitmap), GFP_KERNEL);
+ if (!msi->bitmap)
+ return ERR_PTR(-ENOMEM);
+
+ ret = qcom_msi_alloc_domains(msi);
+ if (ret)
+ return ERR_PTR(ret);
+
+ ret = qcom_msi_irq_setup(msi);
+ if (ret) {
+ qcom_msi_deinit(msi);
+ return ERR_PTR(ret);
+ }
+
+ qcom_msi_config(msi->msi_domain);
+ return msi;
+}
+
+static int qcom_pcie_ecam_suspend_noirq(struct device *dev)
+{
+ return pm_runtime_put_sync(dev);
+}
+
+static int qcom_pcie_ecam_resume_noirq(struct device *dev)
+{
+ return pm_runtime_get_sync(dev);
+}
+
+static int qcom_pcie_ecam_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct qcom_msi *msi;
+ int ret;
+
+ ret = devm_pm_runtime_enable(dev);
+ if (ret)
+ return ret;
+
+ ret = pm_runtime_resume_and_get(dev);
+ if (ret < 0) {
+ dev_err(dev, "fail to enable pcie controller: %d\n", ret);
+ return ret;
+ }
+
+ msi = qcom_msi_init(dev);
+ if (IS_ERR(msi)) {
+ pm_runtime_put_sync(dev);
+ return PTR_ERR(msi);
+ }
+
+ ret = pci_host_common_probe(pdev);
+ if (ret) {
+ dev_err(dev, "pci_host_common_probe() failed:%d\n", ret);
+ qcom_msi_deinit(msi);
+ pm_runtime_put_sync(dev);
+ }
+
+ return ret;
+}
+
+static const struct dev_pm_ops qcom_pcie_ecam_pm_ops = {
+ NOIRQ_SYSTEM_SLEEP_PM_OPS(qcom_pcie_ecam_suspend_noirq,
+ qcom_pcie_ecam_resume_noirq)
+};
+
+static const struct pci_ecam_ops qcom_pcie_ecam_ops = {
+ .pci_ops = {
+ .map_bus = pci_ecam_map_bus,
+ .read = pci_generic_config_read,
+ .write = pci_generic_config_write,
+ }
+};
+
+static const struct of_device_id qcom_pcie_ecam_of_match[] = {
+ {
+ .compatible = "qcom,pcie-ecam-rc",
+ .data = &qcom_pcie_ecam_ops,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, qcom_pcie_ecam_of_match);
+
+static struct platform_driver qcom_pcie_ecam_driver = {
+ .probe = qcom_pcie_ecam_probe,
+ .driver = {
+ .name = "qcom-pcie-ecam-rc",
+ .suppress_bind_attrs = true,
+ .of_match_table = qcom_pcie_ecam_of_match,
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ .pm = &qcom_pcie_ecam_pm_ops,
+ },
+};
+module_platform_driver(qcom_pcie_ecam_driver);
+
+MODULE_DESCRIPTION("Qualcomm PCIe ECAM root complex driver");
+MODULE_LICENSE("GPL");
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 08/29] mm: Define VM_SHADOW_STACK for RISC-V
From: David Hildenbrand @ 2024-04-04 19:15 UTC (permalink / raw)
To: Mark Brown
Cc: Deepak Gupta, paul.walmsley, rick.p.edgecombe, Szabolcs.Nagy,
kito.cheng, keescook, ajones, conor.dooley, cleger, atishp, alex,
bjorn, alexghiti, samuel.holland, conor, linux-doc, linux-riscv,
linux-kernel, devicetree, linux-mm, linux-arch, linux-kselftest,
corbet, palmer, aou, robh+dt, krzysztof.kozlowski+dt, oleg, akpm,
arnd, ebiederm, Liam.Howlett, vbabka, lstoakes, shuah, brauner,
andy.chiu, jerry.shih, hankuan.chen, greentime.hu, evan,
xiao.w.wang, charlie, apatel, mchitale, dbarboza, sameo,
shikemeng, willy, vincent.chen, guoren, samitolvanen,
songshuaishuai, gerg, heiko, bhe, jeeheng.sia, cyy, maskray,
ancientmodern4, mathis.salmen, cuiyunhui, bgray, mpe, baruch, alx,
catalin.marinas, revest, josh, shr, deller, omosnace, ojeda,
jhubbard
In-Reply-To: <d3689521-58a7-47df-bd6a-0e2e60464491@sirena.org.uk>
On 04.04.24 21:04, Mark Brown wrote:
> On Thu, Apr 04, 2024 at 08:58:06PM +0200, David Hildenbrand wrote:
>
>> or even introduce some ARCH_HAS_SHADOW_STACK so we can remove these
>> arch-specific thingies here.
>
> It would be convenient if you could pull the ARCH_HAS_USER_SHADOW_STACK
> patch out of my clone3 series to do that:
>
> https://lore.kernel.org/all/20240203-clone3-shadow-stack-v5-3-322c69598e4b@kernel.org/
Crazy, I completely forgot about that one. Yes!
--
Cheers,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v3 08/29] mm: Define VM_SHADOW_STACK for RISC-V
From: Deepak Gupta @ 2024-04-04 19:21 UTC (permalink / raw)
To: David Hildenbrand
Cc: Mark Brown, paul.walmsley, rick.p.edgecombe, Szabolcs.Nagy,
kito.cheng, keescook, ajones, conor.dooley, cleger, atishp, alex,
bjorn, alexghiti, samuel.holland, conor, linux-doc, linux-riscv,
linux-kernel, devicetree, linux-mm, linux-arch, linux-kselftest,
corbet, palmer, aou, robh+dt, krzysztof.kozlowski+dt, oleg, akpm,
arnd, ebiederm, Liam.Howlett, vbabka, lstoakes, shuah, brauner,
andy.chiu, jerry.shih, hankuan.chen, greentime.hu, evan,
xiao.w.wang, charlie, apatel, mchitale, dbarboza, sameo,
shikemeng, willy, vincent.chen, guoren, samitolvanen,
songshuaishuai, gerg, heiko, bhe, jeeheng.sia, cyy, maskray,
ancientmodern4, mathis.salmen, cuiyunhui, bgray, mpe, baruch, alx,
catalin.marinas, revest, josh, shr, deller, omosnace, ojeda,
jhubbard
In-Reply-To: <604863a6-0387-4f29-9c4e-5ef86a8ca904@redhat.com>
On Thu, Apr 4, 2024 at 12:15 PM David Hildenbrand <david@redhat.com> wrote:
>
> On 04.04.24 21:04, Mark Brown wrote:
> > On Thu, Apr 04, 2024 at 08:58:06PM +0200, David Hildenbrand wrote:
> >
> >> or even introduce some ARCH_HAS_SHADOW_STACK so we can remove these
> >> arch-specific thingies here.
> >
> > It would be convenient if you could pull the ARCH_HAS_USER_SHADOW_STACK
> > patch out of my clone3 series to do that:
> >
> > https://lore.kernel.org/all/20240203-clone3-shadow-stack-v5-3-322c69598e4b@kernel.org/
>
> Crazy, I completely forgot about that one. Yes!
I missed that. Roger.
Will do that in the next series.
Thanks.
^ permalink raw reply
* Re: [PATCH v1 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
From: kernel test robot @ 2024-04-04 19:21 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, chunkuang.hu
Cc: oe-kbuild-all, robh, krzysztof.kozlowski+dt, conor+dt, p.zabel,
airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
matthias.bgg, angelogioacchino.delregno, shawn.sung, yu-chang.lee,
ck.hu, jitao.shi, devicetree, linux-kernel, dri-devel,
linux-mediatek, linux-arm-kernel, wenst, kernel
In-Reply-To: <20240404081635.91412-3-angelogioacchino.delregno@collabora.com>
Hi AngeloGioacchino,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on robh/for-next pza/reset/next linus/master v6.9-rc2 next-20240404]
[cannot apply to pza/imx-drm/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/AngeloGioacchino-Del-Regno/dt-bindings-display-mediatek-Add-OF-graph-support-for-board-path/20240404-161930
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link: https://lore.kernel.org/r/20240404081635.91412-3-angelogioacchino.delregno%40collabora.com
patch subject: [PATCH v1 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20240405/202404050315.7WBDW2E8-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202404050315.7WBDW2E8-lkp@intel.com/
dtcheck warnings: (new ones prefixed by >>)
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: properties:port:properties:required: ['endpoint@0'] is not of type 'object', 'boolean'
from schema $id: http://json-schema.org/draft-07/schema#
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: properties:port:properties: 'required' should not be valid under {'$ref': '#/definitions/json-schema-prop-names'}
hint: A json-schema keyword was found instead of a DT property name.
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: properties:port:properties:required: ['endpoint@0'] is not of type 'object', 'boolean'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
--
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: ignoring, error in schema: properties: port: properties: required
Documentation/devicetree/bindings/net/snps,dwmac.yaml: mac-mode: missing type definition
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [RFC PATCH 1/2] dt-bindings: pcie: Document QCOM PCIE ECAM compatible root complex
From: Krzysztof Kozlowski @ 2024-04-04 19:30 UTC (permalink / raw)
To: Mayank Rana, linux-pci, lpieralisi, kw, robh, bhelgaas, andersson,
manivannan.sadhasivam, krzysztof.kozlowski+dt, conor+dt,
devicetree
Cc: linux-arm-msm, quic_ramkri, quic_nkela, quic_shazhuss,
quic_msarkar, quic_nitegupt
In-Reply-To: <1712257884-23841-2-git-send-email-quic_mrana@quicinc.com>
On 04/04/2024 21:11, Mayank Rana wrote:
> On some of Qualcomm platform, firmware configures PCIe controller in RC
On which?
Your commit or binding must answer to all such questions.
> mode with static iATU window mappings of configuration space for entire
> supported bus range in ECAM compatible mode. Firmware also manages PCIe
> PHY as well required system resources. Here document properties and
> required configuration to power up QCOM PCIe ECAM compatible root complex
> and PHY for PCIe functionality.
>
> Signed-off-by: Mayank Rana <quic_mrana@quicinc.com>
> ---
> .../devicetree/bindings/pci/qcom,pcie-ecam.yaml | 94 ++++++++++++++++++++++
> 1 file changed, 94 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml
>
> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml
> new file mode 100644
> index 00000000..c209f12
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml
> @@ -0,0 +1,94 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/qcom,pcie-ecam.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm ECAM compliant PCI express root complex
> +
> +description: |
Do not need '|' unless you need to preserve formatting.
> + Qualcomm SOC based ECAM compatible PCIe root complex supporting MSI controller.
Which SoC?
> + Firmware configures PCIe controller in RC mode with static iATU window mappings
> + of configuration space for entire supported bus range in ECAM compatible mode.
> +
> +maintainers:
> + - Mayank Rana <quic_mrana@quicinc.com>
> +
> +allOf:
> + - $ref: /schemas/pci/pci-bus.yaml#
> + - $ref: /schemas/power-domain/power-domain-consumer.yaml
> +
> +properties:
> + compatible:
> + const: qcom,pcie-ecam-rc
No, this must have SoC specific compatibles.
> +
> + reg:
> + minItems: 1
maxItems instead
> + description: ECAM address space starting from root port till supported bus range
> +
> + interrupts:
> + minItems: 1
> + maxItems: 8
This is way too unspecific.
> +
> + ranges:
> + minItems: 2
> + maxItems: 3
Why variable?
> +
> + iommu-map:
> + minItems: 1
> + maxItems: 16
Why variable?
Open existing bindings and look how it is done.
> +
> + power-domains:
> + maxItems: 1
> + description: A phandle to node which is able support way to communicate with firmware
> + for enabling PCIe controller and PHY as well managing all system resources needed to
> + make both controller and PHY operational for PCIe functionality.
This description does not tell me much. Say something specific. And drop
redundant parts like phandle.
> +
> + dma-coherent: true
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - ranges
> + - power-domains
> + - device_type
> + - linux,pci-domain
> + - bus-range
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + pcie0: pci@1c00000 {
> + compatible = "qcom,pcie-ecam-rc";
> + reg = <0x4 0x00000000 0 0x10000000>;
> + device_type = "pci";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x01000000 0x0 0x40000000 0x0 0x40000000 0x0 0x100000>,
> + <0x02000000 0x0 0x40100000 0x0 0x40100000 0x0 0x1ff00000>,
> + <0x43000000 0x4 0x10100000 0x4 0x10100000 0x0 0x100000>;
Follow DTS coding style about placement and alignment.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH 2/2] PCI: Add Qualcomm PCIe ECAM root complex driver
From: Krzysztof Kozlowski @ 2024-04-04 19:33 UTC (permalink / raw)
To: Mayank Rana, linux-pci, lpieralisi, kw, robh, bhelgaas, andersson,
manivannan.sadhasivam, krzysztof.kozlowski+dt, conor+dt,
devicetree
Cc: linux-arm-msm, quic_ramkri, quic_nkela, quic_shazhuss,
quic_msarkar, quic_nitegupt
In-Reply-To: <1712257884-23841-3-git-send-email-quic_mrana@quicinc.com>
On 04/04/2024 21:11, Mayank Rana wrote:
> On some of Qualcomm platform, firmware configures PCIe controller into
> ECAM mode allowing static memory allocation for configuration space of
> supported bus range. Firmware also takes care of bringing up PCIe PHY
> and performing required operation to bring PCIe link into D0. Firmware
> also manages system resources (e.g. clocks/regulators/resets/ bus voting).
> Hence add Qualcomm PCIe ECAM root complex driver which enumerates PCIe
> root complex and connected PCIe devices. Firmware won't be enumerating
> or powering up PCIe root complex until this driver invokes power domain
> based notification to bring PCIe link into D0/D3cold mode.
...
> +
> +static int qcom_pcie_ecam_suspend_noirq(struct device *dev)
> +{
> + return pm_runtime_put_sync(dev);
> +}
> +
> +static int qcom_pcie_ecam_resume_noirq(struct device *dev)
> +{
> + return pm_runtime_get_sync(dev);
> +}
> +
> +static int qcom_pcie_ecam_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct qcom_msi *msi;
> + int ret;
> +
> + ret = devm_pm_runtime_enable(dev);
> + if (ret)
> + return ret;
> +
> + ret = pm_runtime_resume_and_get(dev);
> + if (ret < 0) {
> + dev_err(dev, "fail to enable pcie controller: %d\n", ret);
> + return ret;
> + }
> +
> + msi = qcom_msi_init(dev);
> + if (IS_ERR(msi)) {
> + pm_runtime_put_sync(dev);
> + return PTR_ERR(msi);
> + }
> +
> + ret = pci_host_common_probe(pdev);
> + if (ret) {
> + dev_err(dev, "pci_host_common_probe() failed:%d\n", ret);
Don't print function name, but instead say something useful. Above error
message is so not useful that just drop it.
> + qcom_msi_deinit(msi);
> + pm_runtime_put_sync(dev);
> + }
> +
> + return ret;
> +}
> +
> +static const struct dev_pm_ops qcom_pcie_ecam_pm_ops = {
> + NOIRQ_SYSTEM_SLEEP_PM_OPS(qcom_pcie_ecam_suspend_noirq,
> + qcom_pcie_ecam_resume_noirq)
> +};
> +
> +static const struct pci_ecam_ops qcom_pcie_ecam_ops = {
> + .pci_ops = {
> + .map_bus = pci_ecam_map_bus,
> + .read = pci_generic_config_read,
> + .write = pci_generic_config_write,
> + }
> +};
> +
> +static const struct of_device_id qcom_pcie_ecam_of_match[] = {
> + {
> + .compatible = "qcom,pcie-ecam-rc",
> + .data = &qcom_pcie_ecam_ops,
Why do you have ops/match data for generic compatible?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH 0/2] Add Qualcomm PCIe ECAM root complex driver
From: Krzysztof Kozlowski @ 2024-04-04 19:33 UTC (permalink / raw)
To: Mayank Rana, linux-pci, lpieralisi, kw, robh, bhelgaas, andersson,
manivannan.sadhasivam, krzysztof.kozlowski+dt, conor+dt,
devicetree
Cc: linux-arm-msm, quic_ramkri, quic_nkela, quic_shazhuss,
quic_msarkar, quic_nitegupt
In-Reply-To: <1712257884-23841-1-git-send-email-quic_mrana@quicinc.com>
On 04/04/2024 21:11, Mayank Rana wrote:
> On some of Qualcomm platform, firmware takes care of system resources
> related to PCIe PHY and controller as well bringing up PCIe link and
> having static iATU configuration for PCIe controller to work into
> ECAM compliant mode. Hence add Qualcomm PCIe ECAM root complex driver.
>
> Tested:
> - Validated NVME functionality with PCIe0 and PCIe1 on SA877p-ride platform
>
RFC means code is not ready, right? Please get internal review done and
send it when it is ready. I am not sure if you expect any reviews. Some
people send RFC and do not expect reviews. Some expect. I have no clue
and I do not want to waste my time. Please clarify what you expect from
maintainers regarding this contribution.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: Add SM8550 Xperia 1 V
From: Konrad Dybcio @ 2024-04-04 19:41 UTC (permalink / raw)
To: neil.armstrong, James Schulman, David Rhodes, Richard Fitzgerald,
Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ricardo Rivera-Matos, Bjorn Andersson, Abel Vesa,
Sai Prakash Ranjan, Kees Cook, Tony Luck, Guilherme G. Piccoli
Cc: Marijn Suijten, alsa-devel, patches, linux-sound, devicetree,
linux-kernel, linux-arm-msm, linux-hardening
In-Reply-To: <05e6f92c-388c-4bc6-a4cd-e9d981166d1c@linaro.org>
On 2/12/24 18:26, Neil Armstrong wrote:
> On 12/02/2024 14:10, Konrad Dybcio wrote:
>> Add support for Sony Xperia 1 V, a.k.a PDX234. This device is a part
>> of the SoMC SM8550 Yodo platform.
>>
[...]
>> +/* TODO: Only one SID of PMR735D seems accessible? */
>
>
> What's reported by the cpuinfo pmic array ?
PMK8550 2.1
PM8550 2.0
PM8550VS 2.0
PM8550VS 2.0
PM8550VS 2.0
PM8550VE 2.0
PM8550VS 2.0
PM8550B 2.0
PMR735D 2.0
PM8010 1.1
PM8010 1.1
Not sure if there's only one or the other one is secure?
>
> <snip>
>
> With the pcie thing fixed:
> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
It's gonna be fine with the recent aux clock additions. If you
have no further comments, I'll happily ask for this to be merged ;)
Konrad
^ permalink raw reply
* Re: [PATCH] clk: rockchip: clk-rk3568.c: Add missing USB480M_PHY mux
From: Heiko Stuebner @ 2024-04-04 19:43 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sascha Hauer
Cc: linux-clk, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, David Jander, Sascha Hauer
In-Reply-To: <20240404-clk-rockchip-rk3568-add-usb480m-phy-mux-v1-1-e8542afd58b9@pengutronix.de>
Hi Sascha,
Am Donnerstag, 4. April 2024, 09:27:01 CEST schrieb Sascha Hauer:
> From: David Jander <david@protonic.nl>
>
> The USB480M clock can source from a MUX that selects the clock to come
> from either of the USB-phy internal 480MHz PLLs. These clocks are
> provided by the USB phy driver.
>
> Signed-off-by: David Jander <david@protonic.nl>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> drivers/clk/rockchip/clk-rk3568.c | 4 ++++
> include/dt-bindings/clock/rk3568-cru.h | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/clk/rockchip/clk-rk3568.c b/drivers/clk/rockchip/clk-rk3568.c
> index 8cb21d10beca2..2d44bcaef046b 100644
> --- a/drivers/clk/rockchip/clk-rk3568.c
> +++ b/drivers/clk/rockchip/clk-rk3568.c
> @@ -215,6 +215,7 @@ static const struct rockchip_cpuclk_reg_data rk3568_cpuclk_data = {
>
> PNAME(mux_pll_p) = { "xin24m" };
> PNAME(mux_usb480m_p) = { "xin24m", "usb480m_phy", "clk_rtc_32k" };
> +PNAME(mux_usb480m_phy_p) = { "clk_usbphy0_480m", "clk_usbphy1_480m"};
> PNAME(mux_armclk_p) = { "apll", "gpll" };
> PNAME(clk_i2s0_8ch_tx_p) = { "clk_i2s0_8ch_tx_src", "clk_i2s0_8ch_tx_frac", "i2s0_mclkin", "xin_osc0_half" };
> PNAME(clk_i2s0_8ch_rx_p) = { "clk_i2s0_8ch_rx_src", "clk_i2s0_8ch_rx_frac", "i2s0_mclkin", "xin_osc0_half" };
> @@ -485,6 +486,9 @@ static struct rockchip_clk_branch rk3568_clk_branches[] __initdata = {
> MUX(USB480M, "usb480m", mux_usb480m_p, CLK_SET_RATE_PARENT,
> RK3568_MODE_CON0, 14, 2, MFLAGS),
>
> + MUX(USB480M_PHY, "usb480m_phy", mux_usb480m_phy_p, CLK_SET_RATE_PARENT,
> + RK3568_MISC_CON2, 15, 1, MFLAGS),
> +
> /* PD_CORE */
> COMPOSITE(0, "sclk_core_src", apll_gpll_npll_p, CLK_IGNORE_UNUSED,
> RK3568_CLKSEL_CON(2), 8, 2, MFLAGS, 0, 4, DFLAGS | CLK_DIVIDER_READ_ONLY,
> diff --git a/include/dt-bindings/clock/rk3568-cru.h b/include/dt-bindings/clock/rk3568-cru.h
> index d29890865150d..5263085c5b238 100644
> --- a/include/dt-bindings/clock/rk3568-cru.h
> +++ b/include/dt-bindings/clock/rk3568-cru.h
> @@ -78,6 +78,7 @@
> #define CPLL_333M 9
> #define ARMCLK 10
> #define USB480M 11
> +#define USB480M_PHY 12
> #define ACLK_CORE_NIU2BUS 18
> #define CLK_CORE_PVTM 19
> #define CLK_CORE_PVTM_CORE 20
>
Please separate the code change and clock-id addition into separate
patches. That way dt-maintainers will more easily see that there are
changes to the dt-binding inside.
Other than that, the change looks fine :-)
Thanks
Heiko
^ permalink raw reply
* [PATCH v2 0/2] mfd: Add ROHM BD71879
From: Andreas Kemnade @ 2024-04-04 19:54 UTC (permalink / raw)
To: lee, robh+dt, krzysztof.kozlowski+dt, conor+dt, mazziesaccount,
devicetree, linux-kernel
Cc: Andreas Kemnade
Add software-compatible variant of the BD71828.
Changes in v2:
allow compatible = "rohm,bd71879", "rohm,bd71828"
Andreas Kemnade (2):
dt-bindings: mfd: Add ROHM BD71879
mfd: rohm-bd71828: Add software-compatible variant BD71879
.../devicetree/bindings/mfd/rohm,bd71828-pmic.yaml | 7 ++++++-
drivers/mfd/rohm-bd71828.c | 4 ++++
2 files changed, 10 insertions(+), 1 deletion(-)
--
2.39.2
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: mfd: Add ROHM BD71879
From: Andreas Kemnade @ 2024-04-04 19:54 UTC (permalink / raw)
To: lee, robh+dt, krzysztof.kozlowski+dt, conor+dt, mazziesaccount,
devicetree, linux-kernel
Cc: Andreas Kemnade
In-Reply-To: <20240404195423.666446-1-andreas@kemnade.info>
As this chip was seen in several devices in the wild, add it.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Suggested-by: Matti Vaittinen <mazziesaccount@gmail.com>
---
.../devicetree/bindings/mfd/rohm,bd71828-pmic.yaml | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
index 0b62f854bf6b..07f99738fcf6 100644
--- a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
@@ -17,7 +17,12 @@ description: |
properties:
compatible:
- const: rohm,bd71828
+ oneOf:
+ - const: rohm,bd71828
+
+ - items:
+ - const: rohm,bd71879
+ - const: rohm,bd71828
reg:
description:
--
2.39.2
^ permalink raw reply related
* [PATCH v2 2/2] mfd: rohm-bd71828: Add software-compatible variant BD71879
From: Andreas Kemnade @ 2024-04-04 19:54 UTC (permalink / raw)
To: lee, robh+dt, krzysztof.kozlowski+dt, conor+dt, mazziesaccount,
devicetree, linux-kernel
Cc: Andreas Kemnade
In-Reply-To: <20240404195423.666446-1-andreas@kemnade.info>
Add the BD71879 PMIC which is software-compatible to the BD71828, so reuse
the same device_type enum.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Suggested-by: Matti Vaittinen <mazziesaccount@gmail.com>
Acked-by: Matti Vaittinen <mazziesaccount@gmail.com>
---
drivers/mfd/rohm-bd71828.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/mfd/rohm-bd71828.c b/drivers/mfd/rohm-bd71828.c
index 4a1fa8a0d76a..f0b444690d4d 100644
--- a/drivers/mfd/rohm-bd71828.c
+++ b/drivers/mfd/rohm-bd71828.c
@@ -585,6 +585,10 @@ static const struct of_device_id bd71828_of_match[] = {
{
.compatible = "rohm,bd71828",
.data = (void *)ROHM_CHIP_TYPE_BD71828,
+ }, {
+ .compatible = "rohm,bd71879",
+ /* equivalent from a software point of view */
+ .data = (void *)ROHM_CHIP_TYPE_BD71828,
}, {
.compatible = "rohm,bd71815",
.data = (void *)ROHM_CHIP_TYPE_BD71815,
--
2.39.2
^ permalink raw reply related
* Re: [PATCH v9 0/4] PCI: brcmstb: Configure appropriate HW CLKREQ# mode
From: Cyril Brulebois @ 2024-04-04 20:01 UTC (permalink / raw)
To: Jim Quinlan
Cc: linux-pci, Nicolas Saenz Julienne, Bjorn Helgaas,
Lorenzo Pieralisi, Phil Elwell, bcm-kernel-feedback-list,
Conor Dooley,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Jim Quinlan, Krzysztof Kozlowski,
Krzysztof Wilczyński,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Lorenzo Pieralisi, Rob Herring
In-Reply-To: <20240403213902.26391-1-james.quinlan@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 3351 bytes --]
Hi Jim,
Jim Quinlan <james.quinlan@broadcom.com> (2024-04-03):
> v9 -- v8 was setting an internal bus timeout to accomodate large L1 exit
> latencies. After meeting the PCIe HW team it was revealed that the
> HW default timeout value was set low for the purposes of HW debugging
> convenience; for nominal operation it needs to be set to a higher
> value independent of this submission's purpose. This is now a
> separate commit.
>
> -- With v8, Bjorne asked what was preventing a device from exceeding the
> time required for the above internal bus timeout. The answer to this
> is for us to set the endpoints' max latency {no-,}snoop value to
> something below this internal timeout value. If the endpoint
> respects this value as it should, it will not send an LTR request
> with a larger latency value and not put itself in a situation
> that requires more latency than is possible for the platform.
>
> Typically, ACPI or FW sets these max latency values. In most of our
> systems we do not have this happening so it is up to the RC driver to
> set these values in the endpoint devices. If the endpoints already
> have non-zero values that are lower than what we are setting, we let
> them be, as it is possible ACPI or FW set them and knows something
> that we do not.
>
> -- The "clkreq" commit has only been changed to remove the code that was
> setting the timeout value, as this code is now its own commit.
Given the bot's feedback, I took the liberty of running tests on your
patch series except with an extra “static” keyword. On my build system,
gcc 12 wasn't complaining about it but I didn't spend time trying to
find the right options, or trying a switch to clang to confirm the
before/after situation:
-void brcm_set_downstream_devs_ltr_max(struct brcm_pcie *pcie)
+static void brcm_set_downstream_devs_ltr_max(struct brcm_pcie *pcie)
Anyway, this is still:
Tested-by: Cyril Brulebois <cyril@debamax.com>
Test setup:
-----------
- using a $CM with the 20230111 EEPROM
- on the same CM4 IO Board
- with a $PCIE board (PCIe to multiple USB ports)
- and the same Samsung USB flash drive + Logitech keyboard.
where $CM is one of:
- CM4 Lite Rev 1.0
- CM4 8/32 Rev 1.0
- CM4 4/32 Rev 1.1
and $PCIE is one of:
- SupaHub PCE6U1C-R02, VER 006
- SupaHub PCE6U1C-R02, VER 006S
- Waveshare VIA VL805/806-based
Results:
--------
1. Given this is already v9, and given I don't see how this could have
possibly changed, I didn't build or tested an unpatched kernel,
which I would still expect to produce either a successful boot
*without* seeing the devices plugged on the PCIe-to-USB board or the
dreaded SError in most cases.
2. With a patched kernel (v6.7-562-g9f8413c4a66f2 + this series +
“static” in front of brcm_set_downstream_devs_ltr_max()), for all
$CM/$PCIE combinations, I'm getting a system that boots, sees the
flash drive, and gives decent read/write performance on it (plus a
functional keyboard).
Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: (subset) [PATCH v4 1/3] dt-bindings: arm: merge qcom,idle-state with idle-state
From: Bjorn Andersson @ 2024-04-04 21:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Jonathan Cameron, Jonathan Corbet,
Stephen Boyd, Lorenzo Pieralisi, Anup Patel, David Heidelberg
Cc: Luca Weiss, Rob Herring, Ulf Hansson, Catalin Marinas,
Krzysztof Kozlowski, devicetree, linux-kernel, linux-riscv
In-Reply-To: <20231202234832.155306-1-david@ixit.cz>
On Sun, 03 Dec 2023 00:47:17 +0100, David Heidelberg wrote:
> Merge Qualcomm-specific idle-state binding with generic one.
>
>
Applied, thanks!
[2/3] ARM: dts: qcom: include cpu in idle-state node names
commit: e48919dc1ed568f895eca090dc6c5dc56b12480c
[3/3] ARM: dts: qcom: msm8916: idle-state compatible require the generic idle-state
commit: 8f2cc88cd4a35e33931ca1375ea508c8c9267b57
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sm8150-hdk: enable WiFI support
From: Bjorn Andersson @ 2024-04-04 21:22 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Baryshkov
Cc: linux-arm-msm, devicetree, linux-kernel, Kalle Valo, Jeff Johnson,
ath10k
In-Reply-To: <20240403-sm8150-hdk-wifi-v1-1-8da3063829c2@linaro.org>
On Wed, 03 Apr 2024 20:10:12 +0300, Dmitry Baryshkov wrote:
> Enable modem DSP and WiFI devices on the SM8150 HDK device. The HDK is
> manufactured by Lantronix, but it attributed to Qualcomm, so the
> calibration string uses Qualcomm as manufacturer.
>
> For reference:
>
> ath10k_snoc 18800000.wifi: qmi chip_id 0x30224 chip_family 0x4001 board_id 0x55 soc_id 0x40060000
> ath10k_snoc 18800000.wifi: qmi fw_version 0x32040163 fw_build_timestamp 2019-10-08 05:42 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.3.2.0-00355-QCAHLSWMTPLZ-1
> ath10k_snoc 18800000.wifi: wcn3990 hw1.0 target 0x00000008 chip_id 0x00000000 sub 0000:0000
> ath10k_snoc 18800000.wifi: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 0
> ath10k_snoc 18800000.wifi: firmware ver api 5 features wowlan,mgmt-tx-by-reference,non-bmi crc32 b3d4b790
> ath10k_snoc 18800000.wifi: htt-ver 3.73 wmi-op 4 htt-op 3 cal file max-sta 32 raw 0 hwcrypto 1
> ath10k_snoc 18800000.wifi: invalid MAC address; choosing random
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: sm8150-hdk: enable WiFI support
commit: e5fd6512f6e842d8c5883b9fa4d72c8a5295efdc
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sm8350: Add interconnects to UFS
From: Bjorn Andersson @ 2024-04-04 21:22 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Baryshkov
Cc: linux-arm-msm, devicetree
In-Reply-To: <20240313-sm8350-ufs-icc-v1-1-73fa2da99779@linaro.org>
On Wed, 13 Mar 2024 03:32:09 +0200, Dmitry Baryshkov wrote:
> To ensure that UFS doesn't get disconnected from NoC, add interconnect properties
> to the UFS controller.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: sm8350: Add interconnects to UFS
commit: cb06e2b406279f65890233af103c638d3752d328
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 0/2] arm64: dts: qcom: msm8916: drop dtbTool compatibles
From: Bjorn Andersson @ 2024-04-04 21:22 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Baryshkov
Cc: linux-arm-msm, devicetree, Stephan Gerhold
In-Reply-To: <20240314-msm8916-drop-compats-v2-0-5a4b40f832d3@linaro.org>
On Thu, 14 Mar 2024 03:42:47 +0200, Dmitry Baryshkov wrote:
> Only two boards ever has adopted the dtbTool-specific compatibles.
> However the dtbTool should not be used anymore. It was required only for
> the old, broken lk1st bootloader. All users of those boards should have
> updated to use lk2nd instead. Otherwise several important features
> (secondary CPU cores, WiFi, BT) will not work with the upstream kernel.
>
> Drop these extra compatibles, merging these two boards into the common
> bindings case for msm8916.
>
> [...]
Applied, thanks!
[1/2] dt-bindings: arm: qcom: drop dtbTool-specific compatibles
commit: 88d0e4e10d77bb4e575b74ac0f6dd3140ecc3bcd
[2/2] arm64: dts: qcom: msm8916: drop dtbTool-specific compatibles
commit: 3867ad6d39cd97875aca7e5f1b17ea6dd5b1107a
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v3 0/4] arm64: dts: fix several display-related schema warnings
From: Bjorn Andersson @ 2024-04-04 21:22 UTC (permalink / raw)
To: Rob Clark, Abhinav Kumar, Sean Paul, Marijn Suijten, David Airlie,
Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Vinod Koul, Dmitry Baryshkov
Cc: linux-arm-msm, dri-devel, freedreno, devicetree,
Krzysztof Kozlowski
In-Reply-To: <20240402-fd-fix-schema-v3-0-817ea6ddf775@linaro.org>
On Tue, 02 Apr 2024 05:57:14 +0300, Dmitry Baryshkov wrote:
> Fix several warnings produced by the display nodes.
>
> Please excuse me for the spam for sending v3 soon after v2.
>
>
Applied, thanks!
[2/4] arm64: dts: qcom: sc8180x: drop legacy property #stream-id-cells
commit: 7fb5680b589d5eae64ada1d917b6ff2dab82f5ae
[3/4] arm64: dts: qcom: sc8180x: Drop flags for mdss irqs
commit: 580701ec27f61e0996dd5fcd23b091b6bf6933e3
[4/4] arm64: dts: qcom: sc8180x: add dp_p1 register blocks to DP nodes
commit: 1106ea2266d11ebd97c3493a0c36a45272bfb67a
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: ipq8074: Remove unused gpio from QPIC pins
From: Bjorn Andersson @ 2024-04-04 21:22 UTC (permalink / raw)
To: Paweł Owoc
Cc: Robert Marko, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20240313102713.1727458-1-frut3k7@gmail.com>
On Wed, 13 Mar 2024 11:27:06 +0100, Paweł Owoc wrote:
> gpio16 will only be used for LCD support, as its NAND/LCDC data[8]
> so its bit 9 of the parallel QPIC interface, and ONFI NAND is only 8
> or 16-bit with only 8-bit one being supported in our case so that pin
> is unused.
>
> It should be dropped from the default NAND pinctrl configuration
> as its unused and only needed for LCD.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: ipq8074: Remove unused gpio from QPIC pins
commit: 5f78d9213ae753e2242b0f6a5d4a5e98e55ddc76
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ 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