Re: [PATCH v2 15/19] arch/powerpc: Implement with generic helpers
Thomas Zimmermann writes:
> Replace the architecture's fb_is_primary_device() with the generic
> one from . No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Christophe Leroy
> ---
> arch/powerpc/include/asm/fb.h | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
Looks fine.
Acked-by: Michael Ellerman (powerpc)
cheers
> diff --git a/arch/powerpc/include/asm/fb.h b/arch/powerpc/include/asm/fb.h
> index 6541ab77c5b9..5f1a2e5f7654 100644
> --- a/arch/powerpc/include/asm/fb.h
> +++ b/arch/powerpc/include/asm/fb.h
> @@ -2,8 +2,8 @@
> #ifndef _ASM_FB_H_
> #define _ASM_FB_H_
>
> -#include
> #include
> +
> #include
>
> static inline void fb_pgprotect(struct file *file, struct vm_area_struct
> *vma,
> @@ -13,10 +13,8 @@ static inline void fb_pgprotect(struct file *file, struct
> vm_area_struct *vma,
>vma->vm_end - vma->vm_start,
>vma->vm_page_prot);
> }
> +#define fb_pgprotect fb_pgprotect
>
> -static inline int fb_is_primary_device(struct fb_info *info)
> -{
> - return 0;
> -}
> +#include
>
> #endif /* _ASM_FB_H_ */
> --
> 2.40.0
Re: linux-next: manual merge of the drm tree with the powerpc tree
Stephen Rothwell writes:
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/amd/display/Kconfig
>
> between commit:
>
> 78f0929884d4 ("powerpc/64: Always build with 128-bit long double")
>
> from the powerpc tree and commit:
>
> 4652ae7a51b7 ("drm/amd/display: Rename DCN config to FP")
>
> from the drm tree.
> I fixed it up (I used the powerpc version - with "(PPC64 && ALTIVEC)")
> and can carry the fix as necessary.
Thanks, that's the right resolution.
Not much we can do to avoid that conflict, we'll just have to tell Linus
about it at pull request time.
cheers
[powerpc:next] BUILD SUCCESS 8002725b9e3369ce8616d32dc2e7a57870475142
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next branch HEAD: 8002725b9e3369ce8616d32dc2e7a57870475142 powerpc/32: Include thread_info.h in head_booke.h elapsed time: 726m configs tested: 171 configs skipped: 20 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alphaallyesconfig gcc alpha defconfig gcc arc allyesconfig gcc arc buildonly-randconfig-r006-20230410 gcc arc defconfig gcc arc randconfig-r043-20230409 gcc arc randconfig-r043-20230410 gcc arc randconfig-r043-20230411 gcc arm allmodconfig gcc arm allyesconfig gcc arm buildonly-randconfig-r005-20230409 clang arm defconfig gcc arm omap1_defconfig clang arm randconfig-r026-20230409 clang arm randconfig-r033-20230410 gcc arm randconfig-r046-20230409 clang arm randconfig-r046-20230410 clang arm randconfig-r046-20230411 gcc arm64allyesconfig gcc arm64 defconfig gcc arm64randconfig-r004-20230410 clang arm64randconfig-r015-20230409 gcc arm64randconfig-r031-20230409 clang arm64randconfig-r031-20230410 clang csky buildonly-randconfig-r001-20230409 gcc csky buildonly-randconfig-r004-20230411 gcc cskydefconfig gcc hexagon randconfig-r012-20230411 clang hexagon randconfig-r025-20230411 clang hexagon randconfig-r026-20230411 clang hexagon randconfig-r041-20230409 clang hexagon randconfig-r041-20230410 clang hexagon randconfig-r041-20230411 clang hexagon randconfig-r045-20230409 clang hexagon randconfig-r045-20230410 clang hexagon randconfig-r045-20230411 clang i386 allyesconfig gcc i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-a001-20230410 clang i386 randconfig-a002-20230410 clang i386 randconfig-a003-20230410 clang i386 randconfig-a004-20230410 clang i386 randconfig-a005-20230410 clang i386 randconfig-a006-20230410 clang i386 randconfig-a011-20230410 gcc i386 randconfig-a012-20230410 gcc i386 randconfig-a013-20230410 gcc i386 randconfig-a014-20230410 gcc i386 randconfig-a015-20230410 gcc i386 randconfig-a016-20230410 gcc i386 randconfig-r006-20230410 clang ia64 allmodconfig gcc ia64 buildonly-randconfig-r003-20230410 gcc ia64 buildonly-randconfig-r006-20230411 gcc ia64defconfig gcc ia64 randconfig-r016-20230410 gcc ia64 randconfig-r016-20230411 gcc ia64 randconfig-r031-20230411 gcc ia64 randconfig-r036-20230410 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchbuildonly-randconfig-r001-20230410 gcc loongarchbuildonly-randconfig-r002-20230410 gcc loongarchbuildonly-randconfig-r004-20230409 gcc loongarch defconfig gcc loongarchrandconfig-r011-20230410 gcc loongarchrandconfig-r015-20230411 gcc loongarchrandconfig-r023-20230411 gcc loongarchrandconfig-r033-20230411 gcc loongarchrandconfig-r035-20230409 gcc m68k allmodconfig gcc m68k buildonly-randconfig-r002-20230409 gcc m68kdefconfig gcc m68k randconfig-r015-20230410 gcc m68k randconfig-r021-20230410 gcc m68k randconfig-r024-20230409 gcc microblaze buildonly-randconfig-r003-20230411 gcc microblaze buildonly-randconfig-r006-20230409 gcc microblaze randconfig-r023-20230410 gcc mips allmodconfig gcc mips allyesconfig gcc mips buildonly-randconfig-r001-20230409 gcc mips buildonly-randconfig-r001-20230410 gcc mips buildonly-randconfig-r002-20230409 gcc mips
[powerpc:merge] BUILD SUCCESS dbb657a5b3626e8f03770abfe8b5af191f2f7230
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge branch HEAD: dbb657a5b3626e8f03770abfe8b5af191f2f7230 .gitignore: Don't ignore .github elapsed time: 720m configs tested: 130 configs skipped: 12 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alphaallyesconfig gcc alphabuildonly-randconfig-r005-20230409 gcc alpha defconfig gcc alpharandconfig-r005-20230410 gcc alpharandconfig-r006-20230410 gcc alpharandconfig-r011-20230410 gcc alpharandconfig-r013-20230409 gcc alpharandconfig-r025-20230410 gcc arc allyesconfig gcc arc defconfig gcc arc randconfig-r001-20230410 gcc arc randconfig-r004-20230409 gcc arc randconfig-r033-20230410 gcc arc randconfig-r043-20230409 gcc arc randconfig-r043-20230410 gcc arm allmodconfig gcc arm allyesconfig gcc arm defconfig gcc arm randconfig-r046-20230409 clang arm randconfig-r046-20230410 clang arm64allyesconfig gcc arm64buildonly-randconfig-r002-20230409 clang arm64 defconfig gcc arm64randconfig-r002-20230409 clang arm64randconfig-r012-20230410 gcc csky buildonly-randconfig-r003-20230410 gcc cskydefconfig gcc hexagon buildonly-randconfig-r006-20230410 clang hexagon randconfig-r013-20230410 clang hexagon randconfig-r016-20230409 clang hexagon randconfig-r041-20230409 clang hexagon randconfig-r041-20230410 clang hexagon randconfig-r045-20230409 clang hexagon randconfig-r045-20230410 clang i386 allyesconfig gcc i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-a001-20230410 clang i386 randconfig-a002-20230410 clang i386 randconfig-a003-20230410 clang i386 randconfig-a004-20230410 clang i386 randconfig-a005-20230410 clang i386 randconfig-a006-20230410 clang i386 randconfig-a011 clang i386 randconfig-a012 gcc i386 randconfig-a013 clang i386 randconfig-a014 gcc i386 randconfig-a015 clang i386 randconfig-a016 gcc i386 randconfig-r002-20230410 clang ia64 allmodconfig gcc ia64defconfig gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchbuildonly-randconfig-r003-20230409 gcc loongarch defconfig gcc loongarchrandconfig-r022-20230409 gcc loongarchrandconfig-r026-20230410 gcc loongarchrandconfig-r033-20230409 gcc m68k allmodconfig gcc m68kdefconfig gcc m68k randconfig-r014-20230409 gcc m68k randconfig-r015-20230409 gcc microblaze randconfig-r015-20230410 gcc microblaze randconfig-r032-20230410 gcc mips allmodconfig gcc mips allyesconfig gcc mips randconfig-r016-20230410 clang mips randconfig-r032-20230409 gcc mips randconfig-r034-20230409 gcc nios2 defconfig gcc nios2randconfig-r006-20230409 gcc openrisc buildonly-randconfig-r006-20230409 gcc openrisc randconfig-r022-20230410 gcc parisc buildonly-randconfig-r002-20230410 gcc parisc defconfig gcc parisc randconfig-r011-20230409 gcc parisc randconfig-r014-20230410 gcc parisc randconfig-r023-20230410 gcc parisc64defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc powerpc randconfig-r012-20230409 gcc powerpc randconfig-r035-20230409 clang riscvallmodconfig gcc riscv allnocon
linux-next: manual merge of the drm tree with the powerpc tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/display/Kconfig
between commit:
78f0929884d4 ("powerpc/64: Always build with 128-bit long double")
from the powerpc tree and commit:
4652ae7a51b7 ("drm/amd/display: Rename DCN config to FP")
from the drm tree.
I fixed it up (I used the powerpc version - with "(PPC64 && ALTIVEC)")
and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpPomSFHmffg.pgp
Description: OpenPGP digital signature
Re: [PATCH] powerpc/boot: Fix crt0.S current address branch form
Michael Ellerman writes: > Nicholas Piggin writes: >> Use the preferred form of branch-and-link for finding the current >> address so objtool doesn't think it is an unannotated intra-function >> call. > > We don't run objtool on this code in mainline AFAIK. Because BOOTAS > doesn't call it. But as Nick pointed out, if you run: $ make arch/powerpc/boot/crt0.o It does run objtool, because it uses the generic cmd_as_o_S rule instead of the BOOTAS rule. cheers
[Bug 216041] Stack overflow at boot (do_IRQ: stack overflow: 1984) on a PowerMac G4 DP, KASAN debug build
https://bugzilla.kernel.org/show_bug.cgi?id=216041 --- Comment #10 from Christophe Leroy (christophe.le...@csgroup.eu) --- I'm away from the office until April 24th -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 216041] Stack overflow at boot (do_IRQ: stack overflow: 1984) on a PowerMac G4 DP, KASAN debug build
https://bugzilla.kernel.org/show_bug.cgi?id=216041 Michael Ellerman (mich...@ellerman.id.au) changed: What|Removed |Added Status|RESOLVED|CLOSED -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 216041] Stack overflow at boot (do_IRQ: stack overflow: 1984) on a PowerMac G4 DP, KASAN debug build
https://bugzilla.kernel.org/show_bug.cgi?id=216041
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||mich...@ellerman.id.au
Resolution|--- |CODE_FIX
--- Comment #9 from Michael Ellerman (mich...@ellerman.id.au) ---
The two patches mentioned in comment #7 were merged as:
3e8635fb2e07 ("powerpc/kasan: Force thread size increase with KASAN")
https://git.kernel.org/torvalds/c/3e8635fb2e072672cbc650989ffedf8300ad67fb
41f20d6db2b6 ("powerpc/irq: Increase stack_overflow detection limit when KASAN
is enabled")
https://git.kernel.org/torvalds/c/41f20d6db2b64677225bb0b97df956241c353ef8
The boot failure with v5.19-rc1 might have been some other issue?
I'll close this for now, please reopen if you see this again.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
[Bug 215470] Unable to boot NXP P2020 processor (freeze before any print to stdout)
https://bugzilla.kernel.org/show_bug.cgi?id=215470 Michael Ellerman (mich...@ellerman.id.au) changed: What|Removed |Added Status|RESOLVED|CLOSED -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 215470] Unable to boot NXP P2020 processor (freeze before any print to stdout)
https://bugzilla.kernel.org/show_bug.cgi?id=215470 Michael Ellerman (mich...@ellerman.id.au) changed: What|Removed |Added Status|NEW |RESOLVED CC||mich...@ellerman.id.au Resolution|--- |CODE_FIX --- Comment #1 from Michael Ellerman (mich...@ellerman.id.au) --- Fixed in v6.0 by commit https://git.kernel.org/torvalds/c/18db466a9a306406dab3b134014d9f6ed642471c -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 216095] sysfs: cannot create duplicate filename '/devices/platform/of-display'
https://bugzilla.kernel.org/show_bug.cgi?id=216095 Michael Ellerman (mich...@ellerman.id.au) changed: What|Removed |Added Status|RESOLVED|CLOSED CC||mich...@ellerman.id.au Resolution|OBSOLETE|CODE_FIX -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v3 6/6] PCI/AER: Unmask RCEC internal errors to enable RCH downstream port error handling
From: Robert Richter
RCEC AER corrected and uncorrectable internal errors (CIE/UIE) are
disabled by default. [1][2] Enable them to receive CXL downstream port
errors of a Restricted CXL Host (RCH).
[1] CXL 3.0 Spec, 12.2.1.1 - RCH Downstream Port Detected Errors
[2] PCIe Base Spec 6.0, 7.8.4.3 Uncorrectable Error Mask Register,
7.8.4.6 Correctable Error Mask Register
Co-developed-by: Terry Bowman
Signed-off-by: Robert Richter
Signed-off-by: Terry Bowman
Cc: "Oliver O'Halloran"
Cc: Bjorn Helgaas
Cc: Mahesh J Salgaonkar
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
---
drivers/pci/pcie/aer.c | 73 ++
1 file changed, 73 insertions(+)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index 171a08fd8ebd..3973c731e11d 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -1000,7 +1000,79 @@ static void cxl_handle_error(struct pci_dev *dev, struct
aer_err_info *info)
pcie_walk_rcec(dev, cxl_handle_error_iter, info);
}
+static bool cxl_error_is_native(struct pci_dev *dev)
+{
+ struct pci_host_bridge *host = pci_find_host_bridge(dev->bus);
+
+ if (pcie_ports_native)
+ return true;
+
+ return host->native_aer && host->native_cxl_error;
+}
+
+static int handles_cxl_error_iter(struct pci_dev *dev, void *data)
+{
+ int *handles_cxl = data;
+
+ *handles_cxl = is_cxl_mem_dev(dev) && cxl_error_is_native(dev);
+
+ return *handles_cxl;
+}
+
+static bool handles_cxl_errors(struct pci_dev *rcec)
+{
+ int handles_cxl = 0;
+
+ if (!rcec->aer_cap)
+ return false;
+
+ if (pci_pcie_type(rcec) == PCI_EXP_TYPE_RC_EC)
+ pcie_walk_rcec(rcec, handles_cxl_error_iter, &handles_cxl);
+
+ return !!handles_cxl;
+}
+
+static int __cxl_unmask_internal_errors(struct pci_dev *rcec)
+{
+ int aer, rc;
+ u32 mask;
+
+ /*
+* Internal errors are masked by default, unmask RCEC's here
+* PCI6.0 7.8.4.3 Uncorrectable Error Mask Register (Offset 08h)
+* PCI6.0 7.8.4.6 Correctable Error Mask Register (Offset 14h)
+*/
+ aer = rcec->aer_cap;
+ rc = pci_read_config_dword(rcec, aer + PCI_ERR_UNCOR_MASK, &mask);
+ if (rc)
+ return rc;
+ mask &= ~PCI_ERR_UNC_INTN;
+ rc = pci_write_config_dword(rcec, aer + PCI_ERR_UNCOR_MASK, mask);
+ if (rc)
+ return rc;
+
+ rc = pci_read_config_dword(rcec, aer + PCI_ERR_COR_MASK, &mask);
+ if (rc)
+ return rc;
+ mask &= ~PCI_ERR_COR_INTERNAL;
+ rc = pci_write_config_dword(rcec, aer + PCI_ERR_COR_MASK, mask);
+
+ return rc;
+}
+
+static void cxl_unmask_internal_errors(struct pci_dev *rcec)
+{
+ if (!handles_cxl_errors(rcec))
+ return;
+
+ if (__cxl_unmask_internal_errors(rcec))
+ dev_err(&rcec->dev, "cxl: Failed to unmask internal errors");
+ else
+ dev_dbg(&rcec->dev, "cxl: Internal errors unmasked");
+}
+
#else
+static inline void cxl_unmask_internal_errors(struct pci_dev *dev) { }
static inline void cxl_handle_error(struct pci_dev *dev,
struct aer_err_info *info) { }
#endif
@@ -1397,6 +1469,7 @@ static int aer_probe(struct pcie_device *dev)
return status;
}
+ cxl_unmask_internal_errors(port);
aer_enable_rootport(rpc);
pci_info(port, "enabled with IRQ %d\n", dev->irq);
return 0;
--
2.34.1
[PATCH v3 5/6] PCI/AER: Forward RCH downstream port-detected errors to the CXL.mem dev handler
From: Robert Richter
In Restricted CXL Device (RCD) mode a CXL device is exposed as an
RCiEP, but CXL downstream and upstream ports are not enumerated and
not visible in the PCIe hierarchy. Protocol and link errors are sent
to an RCEC.
Restricted CXL host (RCH) downstream port-detected errors are signaled
as internal AER errors, either Uncorrectable Internal Error (UIE) or
Corrected Internal Errors (CIE). The error source is the id of the
RCEC. A CXL handler must then inspect the error status in various CXL
registers residing in the dport's component register space (CXL RAS
cap) or the dport's RCRB (AER ext cap). [1]
Errors showing up in the RCEC's error handler must be handled and
connected to the CXL subsystem. Implement this by forwarding the error
to all CXL devices below the RCEC. Since the entire CXL device is
controlled only using PCIe Configuration Space of device 0, Function
0, only pass it there [2]. These devices have the Memory Device class
code set (PCI_CLASS_MEMORY_CXL, 502h) and the existing cxl_pci driver
can implement the handler. In addition to errors directed to the CXL
endpoint device, the handler must also inspect the CXL downstream
port's CXL RAS and PCIe AER external capabilities that is connected to
the device.
Since CXL downstream port errors are signaled using internal errors,
the handler requires those errors to be unmasked. This is subject of a
follow-on patch.
The reason for choosing this implementation is that a CXL RCEC device
is bound to the AER port driver, but the driver does not allow it to
register a custom specific handler to support CXL. Connecting the RCEC
hard-wired with a CXL handler does not work, as the CXL subsystem
might not be present all the time. The alternative to add an
implementation to the portdrv to allow the registration of a custom
RCEC error handler isn't worth doing it as CXL would be its only user.
Instead, just check for an CXL RCEC and pass it down to the connected
CXL device's error handler. With this approach the code can entirely
be implemented in the PCIe AER driver and is independent of the CXL
subsystem. The CXL driver only provides the handler.
[1] CXL 3.0 spec, 12.2.1.1 RCH Downstream Port-detected Errors
[2] CXL 3.0 spec, 8.1.3 PCIe DVSEC for CXL Devices
Co-developed-by: Terry Bowman
Signed-off-by: Robert Richter
Signed-off-by: Terry Bowman
Cc: "Oliver O'Halloran"
Cc: Bjorn Helgaas
Cc: Mahesh J Salgaonkar
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
---
drivers/pci/pcie/Kconfig | 8 ++
drivers/pci/pcie/aer.c | 61
2 files changed, 69 insertions(+)
diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig
index 228652a59f27..b0dbd864d3a3 100644
--- a/drivers/pci/pcie/Kconfig
+++ b/drivers/pci/pcie/Kconfig
@@ -49,6 +49,14 @@ config PCIEAER_INJECT
gotten from:
https://git.kernel.org/cgit/linux/kernel/git/gong.chen/aer-inject.git/
+config PCIEAER_CXL
+ bool "PCI Express CXL RAS support"
+ default y
+ depends on PCIEAER && CXL_PCI
+ help
+ This enables CXL error handling for Restricted CXL Hosts
+ (RCHs).
+
#
# PCI Express ECRC
#
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index 7a25b62d9e01..171a08fd8ebd 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -946,6 +946,65 @@ static bool find_source_device(struct pci_dev *parent,
return true;
}
+#ifdef CONFIG_PCIEAER_CXL
+
+static bool is_cxl_mem_dev(struct pci_dev *dev)
+{
+ /*
+* A CXL device is controlled only using PCIe Configuration
+* Space of device 0, Function 0.
+*/
+ if (dev->devfn != PCI_DEVFN(0, 0))
+ return false;
+
+ /* Right now there is only a CXL.mem driver */
+ if ((dev->class >> 8) != PCI_CLASS_MEMORY_CXL)
+ return false;
+
+ return true;
+}
+
+static bool is_internal_error(struct aer_err_info *info)
+{
+ if (info->severity == AER_CORRECTABLE)
+ return info->status & PCI_ERR_COR_INTERNAL;
+
+ return info->status & PCI_ERR_UNC_INTN;
+}
+
+static void handle_error_source(struct pci_dev *dev, struct aer_err_info
*info);
+
+static int cxl_handle_error_iter(struct pci_dev *dev, void *data)
+{
+ struct aer_err_info *e_info = (struct aer_err_info *)data;
+
+ if (!is_cxl_mem_dev(dev))
+ return 0;
+
+ /* pci_dev_put() in handle_error_source() */
+ dev = pci_dev_get(dev);
+ if (dev)
+ handle_error_source(dev, e_info);
+
+ return 0;
+}
+
+static void cxl_handle_error(struct pci_dev *dev, struct aer_err_info *info)
+{
+ /*
+* CXL downstream port errors are signaled as RCEC internal
+* errors. Forward them to all CXL devices below the RCEC.
+*/
+ if (pci_pcie_type(dev) == PCI_EXP_TYPE_RC_EC &&
+ is_internal_error(info))
+ pcie_walk_rcec(dev, cxl_handle_error_ite
Re: [PATCH v13 03/15] dt-bindings: Convert gpio-mmio to yaml
On Tue, 11 Apr 2023 14:43:00 -0400, Sean Anderson wrote:
> This is a generic binding for simple MMIO GPIO controllers. Although we
> have a single driver for these controllers, they were previously spread
> over several files. Consolidate them. The register descriptions are
> adapted from the comments in the source. There is no set order for the
> registers, and some registers may be omitted. Because of this, reg-names
> is mandatory, and no order is specified.
>
> Rename brcm,bcm6345-gpio to brcm,bcm63xx-gpio to reflect that bcm6345
> has moved.
>
> Signed-off-by: Sean Anderson
> Reviewed-by: Linus Walleij
> ---
> Linus or Bartosz, feel free to pick this up as the rest of this series
> may not be merged any time soon.
>
> Changes in v13:
> - Fix references to brcm,bcm63xx-gpio.yaml (neé brcm,bcm6345-gpio)
>
> Changes in v12:
> - Put compatible first
> - Keep gpio-controller to one line
> - Add little-endian property
> - Alphabetize compatibles
> - Remove some comments
> - Remove some examples with insufficient novelty
>
> Changes in v11:
> - Keep empty (or almost-empty) properties on a single line
> - Don't use | unnecessarily
> - Use gpio as the node name for examples
> - Rename brcm,bcm6345-gpio.yaml to brcm,bcm63xx-gpio.yaml
>
> Changes in v10:
> - New
>
> ...m6345-gpio.yaml => brcm,bcm63xx-gpio.yaml} | 16 +--
> .../devicetree/bindings/gpio/gpio-mmio.yaml | 117 ++
> .../bindings/gpio/ni,169445-nand-gpio.txt | 38 --
> .../devicetree/bindings/gpio/wd,mbl-gpio.txt | 38 --
> .../mfd/brcm,bcm6318-gpio-sysctl.yaml | 4 +-
> .../mfd/brcm,bcm63268-gpio-sysctl.yaml| 4 +-
> .../mfd/brcm,bcm6328-gpio-sysctl.yaml | 4 +-
> .../mfd/brcm,bcm6358-gpio-sysctl.yaml | 4 +-
> .../mfd/brcm,bcm6362-gpio-sysctl.yaml | 4 +-
> .../mfd/brcm,bcm6368-gpio-sysctl.yaml | 4 +-
> 10 files changed, 130 insertions(+), 103 deletions(-)
> rename Documentation/devicetree/bindings/gpio/{brcm,bcm6345-gpio.yaml =>
> brcm,bcm63xx-gpio.yaml} (78%)
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
> delete mode 100644
> Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt
> delete mode 100644 Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
./Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml: $id: relative
path/filename doesn't match actual path or filename
expected: http://devicetree.org/schemas/gpio/brcm,bcm63xx-gpio.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.example.dtb:
syscon@1080: gpio@0: False schema does not allow {'compatible':
['brcm,bcm6318-gpio'], 'reg-names': ['dirout', 'dat'], 'reg': [[0, 8], [8, 8]],
'gpio-controller': True, 'gpio-ranges': [[1, 0, 0, 50]], '#gpio-cells': [[2]]}
From schema:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/brcm,bcm6318-gpio-sysctl.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.example.dtb:
syscon@10c0: gpio@0: False schema does not allow {'compatible':
['brcm,bcm63268-gpio'], 'reg-names': ['dirout', 'dat'], 'reg': [[0, 8], [8,
8]], 'gpio-controller': True, 'gpio-ranges': [[1, 0, 0, 52]], '#gpio-cells':
[[2]]}
From schema:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/brcm,bcm63268-gpio-sysctl.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.example.dtb:
syscon@1080: gpio@0: False schema does not allow {'compatible':
['brcm,bcm6362-gpio'], 'reg-names': ['dirout', 'dat'], 'reg': [[0, 8], [8, 8]],
'gpio-controller': True, 'gpio-ranges': [[1, 0, 0, 48]], '#gpio-cells': [[2]]}
From schema:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/brcm,bcm6362-gpio-sysctl.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.example.dtb:
syscon@1080: gpio@0: False schema does not allow {'compatible':
['brcm,bcm6328-gpio'], 'reg-names': ['dirout', 'dat'], 'reg': [[0, 8], [8, 8]],
'gpio-controller': True, 'gpio-ranges': [[1, 0, 0, 32]], '#gpio-cells': [[2]]}
From schema:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/brcm,bcm6328-gpio-sysctl.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/brcm,bcm6358-gpio-sysctl.example.dtb:
syscon@fffe0080: gpio@0: False schema does not allow {'compatible':
['brcm,bcm6358-gpio'], 'reg-names': ['dirout', 'dat'], 'reg': [[0, 8], [8, 8]],
'gpio-controller': True, 'gpio-ranges': [[1, 0, 0, 40]], '#gpio-cells': [[2]]}
From schema:
/builds/robherring/dt-review-ci/linux/Documen
RE: [PATCH v2 0/5] locking: Introduce local{,64}_try_cmpxchg
From: Dave Hansen > Sent: 11 April 2023 14:44 > > On 4/11/23 04:35, Mark Rutland wrote: > > I agree it'd be nice to have performance figures, but I think those would > > only > > need to demonstrate a lack of a regression rather than a performance > > improvement, and I think it's fairly clear from eyeballing the generated > > instructions that a regression isn't likely. > > Thanks for the additional context. > > I totally agree that there's zero burden here to show a performance > increase. If anyone can think of a quick way to do _some_ kind of > benchmark on the code being changed and just show that it's free of > brown paper bags, it would be appreciated. Nothing crazy, just think of > one workload (synthetic or not) that will stress the paths being changed > and run it with and without these changes. Make sure there are not > surprises. > > I also agree that it's unlikely to be brown paper bag material. The only thing I can think of is that, on x86, the locked variant may actually be faster! Both require exclusive access to the cache line (the unlocked variant always does the write! [1]). So if the cache line is contended between cpu the unlocked variant might ping-pong the cache line twice! Of course, if the line is shared like that then performance is horrid. [1] I checked on an uncached PCIe address on which I can monitor the TLP. The write always happens so you can use cmpxchg18b with a 'known bad value' to do a 16 byte read as a single TLP (without using an SSE register). David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
[PATCH v13 14/15] arm64: dts: ls1088ardb: Add SFP cage
dpmac1 defaults to a fixed link. However, it has an SFP cage, so we can
determine more about the link (such as whether it's up/down) by
describing it. The GPIOs are part of the "QIXIS" FPGA. For now, just
model them as individual registers.
Signed-off-by: Sean Anderson
---
Changes in v13:
- Split off SFP addition from serdes support
.../boot/dts/freescale/fsl-ls1088a-rdb.dts| 51 ++-
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
index 391c2b8afa81..9fb1960f1258 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
@@ -10,11 +10,27 @@
/dts-v1/;
+#include
+
#include "fsl-ls1088a.dtsi"
/ {
model = "LS1088A RDB Board";
compatible = "fsl,ls1088a-rdb", "fsl,ls1088a";
+
+ sfp_slot: sfp {
+ compatible = "sff,sfp";
+ i2c-bus = <&sfp_i2c>;
+ los-gpios = <&los_stat 5 GPIO_ACTIVE_HIGH>;
+ tx-fault-gpios = <&los_stat 4 GPIO_ACTIVE_HIGH>;
+ tx-disable-gpios = <&brdcfg9 4 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+&dpmac1 {
+ managed = "in-band-status";
+ pcs-handle = <&pcs1>;
+ sfp = <&sfp_slot>;
};
&dpmac2 {
@@ -170,6 +186,12 @@ rtc@51 {
interrupts-extended = <&extirq 0
IRQ_TYPE_LEVEL_LOW>;
};
};
+
+ sfp_i2c: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x6>;
+ };
};
};
@@ -184,8 +206,31 @@ nand@0,0 {
};
fpga: board-control@2,0 {
- compatible = "fsl,ls1088ardb-fpga", "fsl,fpga-qixis";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,ls1088ardb-fpga", "fsl,fpga-qixis",
+"simple-bus";
reg = <0x2 0x0 0x100>;
+ ranges = <0x0 0x2 0x0 0x100>;
+
+ los_stat: gpio-controller@1d {
+ #gpio-cells = <2>;
+ compatible = "fsl,fpga-qixis-los-stat",
+"ni,169445-nand-gpio";
+ reg = <0x1d 0x1>;
+ reg-names = "dat";
+ gpio-controller;
+ no-output;
+ };
+
+ brdcfg9: gpio-controller@59 {
+ #gpio-cells = <2>;
+ compatible = "fsl,fpga-qixis-brdcfg9",
+"ni,169445-nand-gpio";
+ reg = <0x59 0x1>;
+ reg-names = "dat";
+ gpio-controller;
+ };
};
};
@@ -202,6 +247,10 @@ &esdhc {
status = "okay";
};
+&pcs_mdio1 {
+ status = "okay";
+};
+
&pcs_mdio2 {
status = "okay";
};
--
2.35.1.1320.gc452695387.dirty
[PATCH v13 15/15] arm64: dts: ls1088ardb: Add serdes descriptions
This adds serdes support to the LS1088ARDB. I have tested the QSGMII
ports as well as the two 10G ports. Linux hangs around when the serdes
is initialized if the si5341 is enabled with the in-tree driver, so I
have modeled it as a two fixed clocks instead.
To enable serdes support, the DPC needs to set the macs to
MAC_LINK_TYPE_BACKPLANE. All MACs using the same QSGMII should be
converted at once. Additionally, in order to change interface types, the
MC firmware must support DPAA2_MAC_FEATURE_PROTOCOL_CHANGE.
Signed-off-by: Sean Anderson
---
Changes in v13:
- Split off interrupt and SFP changes into separate commits
Changes in v10:
- Move serdes bindings to SoC dtsi
- Use "descriptions" instead of "bindings"
- Don't use /clocks
- Add missing gpio-controller properties
Changes in v9:
- Add fsl,unused-lanes-reserved to allow a gradual transition, depending
on the mac link type.
- Remove unused clocks
- Fix some phy mode node names
- phy-type -> fsl,phy
Changes in v8:
- Rename serdes phy handles like the LS1046A
- Add SFP slot binding
- Fix incorrect lane ordering (it's backwards on the LS1088A just like it is in
the LS1046A).
- Fix duplicated lane 2 (it should have been lane 3).
- Fix incorrectly-documented value for XFI1.
- Remove interrupt for aquantia phy. It never fired for whatever reason,
preventing the link from coming up.
- Add GPIOs for QIXIS FPGA.
- Enable MAC1 PCS
- Remove si5341 binding
Changes in v4:
- Convert to new bindings
.../boot/dts/freescale/fsl-ls1088a-rdb.dts| 30 +++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
index 9fb1960f1258..ede537b644e8 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
@@ -18,6 +18,18 @@ / {
model = "LS1088A RDB Board";
compatible = "fsl,ls1088a-rdb", "fsl,ls1088a";
+ clk_100mhz: clock-100mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1>;
+ };
+
+ clk_156mhz: clock-156mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <15625>;
+ };
+
sfp_slot: sfp {
compatible = "sff,sfp";
i2c-bus = <&sfp_i2c>;
@@ -27,16 +39,26 @@ sfp_slot: sfp {
};
};
+&serdes1 {
+ clocks = <&clk_100mhz>, <&clk_156mhz>;
+ clock-names = "ref0", "ref1";
+ fsl,unused-lanes-reserved;
+ status = "okay";
+};
+
&dpmac1 {
managed = "in-band-status";
pcs-handle = <&pcs1>;
+ phys = <&serdes1_C>;
sfp = <&sfp_slot>;
};
&dpmac2 {
phy-handle = <&mdio2_aquantia_phy>;
phy-connection-type = "10gbase-r";
+ managed = "in-band-status";
pcs-handle = <&pcs2>;
+ phys = <&serdes1_D>;
};
&dpmac3 {
@@ -44,6 +66,7 @@ &dpmac3 {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <&pcs3_0>;
+ phys = <&serdes1_A>;
};
&dpmac4 {
@@ -51,6 +74,7 @@ &dpmac4 {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <&pcs3_1>;
+ phys = <&serdes1_A>;
};
&dpmac5 {
@@ -58,6 +82,7 @@ &dpmac5 {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <&pcs3_2>;
+ phys = <&serdes1_A>;
};
&dpmac6 {
@@ -65,6 +90,7 @@ &dpmac6 {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <&pcs3_3>;
+ phys = <&serdes1_A>;
};
&dpmac7 {
@@ -72,6 +98,7 @@ &dpmac7 {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <&pcs7_0>;
+ phys = <&serdes1_B>;
};
&dpmac8 {
@@ -79,6 +106,7 @@ &dpmac8 {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <&pcs7_1>;
+ phys = <&serdes1_B>;
};
&dpmac9 {
@@ -86,6 +114,7 @@ &dpmac9 {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <&pcs7_2>;
+ phys = <&serdes1_B>;
};
&dpmac10 {
@@ -93,6 +122,7 @@ &dpmac10 {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <&pcs7_3>;
+ phys = <&serdes1_B>;
};
&emdio1 {
--
2.35.1.1320.gc452695387.dirty
[PATCH v13 12/15] arm64: dts: ls1088a: Prevent PCSs from probing as phys
The internal PCSs are not always accessible during boot (such as if the
serdes has deselected the appropriate link mode). Give them appropriate
compatible strings so they don't automatically (fail to) probe as
genphys.
Signed-off-by: Sean Anderson
---
(no changes since v8)
Changes in v8:
- New
.../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 30 ---
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 59b401daad4d..bbc714f84577 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -932,7 +932,8 @@ pcs_mdio1: mdio@8c07000 {
#size-cells = <0>;
status = "disabled";
- pcs1: ethernet-phy@0 {
+ pcs1: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -945,7 +946,8 @@ pcs_mdio2: mdio@8c0b000 {
#size-cells = <0>;
status = "disabled";
- pcs2: ethernet-phy@0 {
+ pcs2: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -958,19 +960,23 @@ pcs_mdio3: mdio@8c0f000 {
#size-cells = <0>;
status = "disabled";
- pcs3_0: ethernet-phy@0 {
+ pcs3_0: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
- pcs3_1: ethernet-phy@1 {
+ pcs3_1: ethernet-pcs@1 {
+ compatible = "fsl,lynx-pcs";
reg = <1>;
};
- pcs3_2: ethernet-phy@2 {
+ pcs3_2: ethernet-pcs@2 {
+ compatible = "fsl,lynx-pcs";
reg = <2>;
};
- pcs3_3: ethernet-phy@3 {
+ pcs3_3: ethernet-pcs@3 {
+ compatible = "fsl,lynx-pcs";
reg = <3>;
};
};
@@ -983,19 +989,23 @@ pcs_mdio7: mdio@8c1f000 {
#size-cells = <0>;
status = "disabled";
- pcs7_0: ethernet-phy@0 {
+ pcs7_0: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
- pcs7_1: ethernet-phy@1 {
+ pcs7_1: ethernet-pcs@1 {
+ compatible = "fsl,lynx-pcs";
reg = <1>;
};
- pcs7_2: ethernet-phy@2 {
+ pcs7_2: ethernet-pcs@2 {
+ compatible = "fsl,lynx-pcs";
reg = <2>;
};
- pcs7_3: ethernet-phy@3 {
+ pcs7_3: ethernet-pcs@3 {
+ compatible = "fsl,lynx-pcs";
reg = <3>;
};
};
--
2.35.1.1320.gc452695387.dirty
[PATCH v13 13/15] arm64: dts: ls1088ardb: Remove aquantia interrupt
On my board I have never been able to get this interrupt to work. As
such, the link does not come up. To fix this, remove the interrupt,
forcing polling mode. It has been reported that this interrupt works on
other boards. However, switching to polling will only result in a modest
decrease in link up/down delay (.5s on average).
Signed-off-by: Sean Anderson
---
Changes in v13:
- Split interrupt changes off from serdes support
arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
index ee8e932628d1..391c2b8afa81 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
@@ -128,7 +128,6 @@ &emdio2 {
mdio2_aquantia_phy: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c45";
- interrupts-extended = <&extirq 2 IRQ_TYPE_LEVEL_LOW>;
reg = <0x0>;
};
};
--
2.35.1.1320.gc452695387.dirty
[PATCH v13 11/15] arm64: dts: ls1088a: Add serdes nodes
This adds nodes for the SerDes devices. They are disabled by default
to prevent any breakage on existing boards.
Signed-off-by: Sean Anderson
---
(no changes since v10)
Changes in v10:
- Move serdes bindings to SoC dtsi
- Add support for all (ethernet) serdes modes
- Refer to "nodes" instead of "bindings"
- Move compatible/reg first
Changes in v4:
- Convert to new bindings
Changes in v3:
- New
.../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 126 ++
1 file changed, 126 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index e5fb137ac02b..59b401daad4d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -9,6 +9,7 @@
*/
#include
#include
+#include
#include
/ {
@@ -238,6 +239,131 @@ reset: syscon@1e6 {
reg = <0x0 0x1e6 0x0 0x1>;
};
+ serdes1: serdes@1ea {
+ compatible = "fsl,ls1088a-serdes", "fsl,lynx-10g";
+ reg = <0x0 0x1ea 0x0 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
+ status = "disabled";
+
+ /*
+* XXX: Lane A uses pins SD1_RX3_P/N! That is, the lane
+* numbers and pin numbers are _reversed_.
+*/
+ serdes1_A: phy@0 {
+ #phy-cells = <0>;
+ reg = <0>;
+
+ /* SG3 */
+ sgmii-0 {
+ fsl,pccr = <0x8>;
+ fsl,index = <0>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+
+ /* QSGb */
+ qsgmii-0 {
+ fsl,pccr = <0x9>;
+ fsl,index = <0>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+ };
+
+ serdes1_B: phy@1 {
+ #phy-cells = <0>;
+ reg = <1>;
+
+ /* SG7 */
+ sgmii-1 {
+ fsl,pccr = <0x8>;
+ fsl,index = <1>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+
+ /* QSGa */
+ qsgmii-1 {
+ fsl,pccr = <0x9>;
+ fsl,index = <1>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+
+ /* TODO: PCIe1 */
+ };
+
+ serdes1_C: phy@2 {
+ #phy-cells = <0>;
+ reg = <2>;
+
+ /* SG1 */
+ sgmii-2 {
+ fsl,pccr = <0x8>;
+ fsl,index = <2>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+
+ /*
+* XFI1
+* Table 23-1 and section 23.5.16.4 disagree;
+* this reflects the table.
+*
+* fsl,cfg is documented as 1, but it is set to
+* 2 by the RCW! This is the same as the
+* LS1046A.
+*/
+ xfi-0 {
+ fsl,pccr = <0xb>;
+ fsl,index = <0>;
+ fsl,cfg = <0x2>;
+ fsl,type = ;
+ };
+ };
+
+ serdes1_D: phy@3 {
+ #phy-cells = <0>;
+ reg = <3>;
+
+ /* SG2 */
+ sgmii-3 {
+ fsl,pccr = <0x8>;
+ fsl,index = <3>;
+ fsl,cfg = <0x1>;
+
[PATCH v13 09/15] arm64: dts: ls1046a: Add serdes nodes
This adds nodes for the SerDes devices. They are disabled by default
to prevent any breakage on existing boards.
Signed-off-by: Sean Anderson
---
(no changes since v10)
Changes in v10:
- Move serdes bindings to SoC dtsi
- Add support for all (ethernet) serdes modes
- Refer to "nodes" instead of "bindings"
- Move compatible/reg first
Changes in v4:
- Convert to new bindings
Changes in v3:
- Describe modes in device tree
Changes in v2:
- Use one phy cell for SerDes1, since no lanes can be grouped
- Disable SerDes by default to prevent breaking boards inadvertently.
.../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 111 ++
1 file changed, 111 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index a01e3cfec77f..f6361fafaef7 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
/ {
compatible = "fsl,ls1046a";
@@ -424,6 +425,116 @@ sfp: efuse@1e8 {
clock-names = "sfp";
};
+ serdes1: serdes@1ea {
+ compatible = "fsl,ls1046a-serdes", "fsl,lynx-10g";
+ reg = <0x0 0x1ea 0x0 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
+ status = "disabled";
+
+ /*
+* XXX: Lane A uses pins SD1_RX3_P/N! That is, the lane
+* numbers and pin numbers are _reversed_. In addition,
+* the PCCR documentation is _inconsistent_ in its
+* usage of these terms!
+*
+* PCCR "Lane 0" refers to...
+* =
+*0 Lane A
+*2 Lane A
+*8 Lane A
+*9 Lane A
+*B Lane D!
+*/
+ serdes1_A: phy@0 {
+ #phy-cells = <0>;
+ reg = <0>;
+
+ /* SGMII.6 */
+ sgmii-0 {
+ fsl,pccr = <0x8>;
+ fsl,index = <0>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+ };
+
+ serdes1_B: phy@1 {
+ #phy-cells = <0>;
+ reg = <1>;
+
+ /* SGMII.5 */
+ sgmii-1 {
+ fsl,pccr = <0x8>;
+ fsl,index = <1>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+
+ /* QSGMII.6,5,10,1 */
+ qsgmii-1 {
+ fsl,pccr = <0x9>;
+ fsl,index = <1>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+
+ /* TODO: PCIe.1 */
+ };
+
+ serdes1_C: phy@2 {
+ #phy-cells = <0>;
+ reg = <2>;
+
+ /* SGMII.10 */
+ sgmii-2 {
+ fsl,pccr = <0x8>;
+ fsl,index = <2>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+
+ /* XFI.10 */
+ xfi-0 {
+ fsl,pccr = <0xb>;
+ fsl,index = <0>;
+ fsl,cfg = <0x2>;
+ fsl,type = ;
+ };
+ };
+
+ serdes1_D: phy@3 {
+ #phy-cells = <0>;
+ reg = <3>;
+
+ /* SGMII.9 */
+ sgmii-3 {
+ fsl,pccr = <0x8>;
+ fsl,index = <3>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+
+
[PATCH v13 07/15] phy: fsl: Add Lynx 10G SerDes driver
This adds support for the Lynx 10G "SerDes" devices found on various NXP QorIQ SoCs. There may be up to four SerDes devices on each SoC, each supporting up to eight lanes. Protocol support for each SerDes is highly heterogeneous, with each SoC typically having a totally different selection of supported protocols for each lane. Additionally, the SerDes devices on each SoC also have differing support. One SerDes will typically support Ethernet on most lanes, while the other will typically support PCIe on most lanes. There is wide hardware support for this SerDes. It is present on QorIQ T-Series and Layerscape processors. Because each SoC typically has specific instructions and exceptions for its SerDes, I have limited the initial scope of this module to just the LS1046A and LS1088A. Additionally, I have only added support for Ethernet protocols. There is not a great need for dynamic reconfiguration for other protocols (except perhaps for M.2 cards), so support for them may never be added. Nevertheless, I have tried to provide an obvious path for adding support for other SoCs as well as other protocols. SATA just needs support for configuring LNmSSCR0. PCIe may need to configure the equalization registers. It also uses multiple lanes. I have tried to write the driver with multi-lane support in mind, so there should not need to be any large changes. Although there are 6 protocols supported, I have only tested SGMII and XFI. The rest have been implemented as described in the datasheet. Most of these protocols should work "as-is", but 10GBASE-KR will need PCS support for link training. Unlike some other phys where e.g. PCIe x4 will use 4 separate phys all configured for PCIe, this driver uses one phy configured to use 4 lanes. This is because while the individual lanes may be configured individually, the protocol selection acts on all lanes at once. Additionally, the order which lanes should be configured in is specified by the datasheet. To coordinate this, lanes are reserved in phy_init, and released in phy_exit. This driver was written with reference to the LS1046A reference manual. However, it was informed by reference manuals for all processors with mEMACs, especially the T4240 (which appears to have a "maxed-out" configuration). The earlier P-series processors appear to be similar, but have a different overall register layout (using "banks" instead of separate SerDes). Perhaps this those use a "5G Lynx SerDes." Signed-off-by: Sean Anderson --- (no changes since v10) Changes in v10: - Fix debugging print with incorrect error variable Changes in v9: - Split off clock "driver" into its own patch to allow for better review. - Add ability to defer lane initialization to phy_init. This allows for easier transitioning between firmware-managed serdes and Linux- managed serdes, as the consumer (such as dpaa2, which knows what the firmware is doing) has the last say on who gets control. - phy-type -> fsl,phy Changes in v8: - Remove unused variable from lynx_ls_mode_init Changes in v7: - Break out call order into generic documentation - Refuse to switch "major" protocols - Update Kconfig to reflect restrictions - Remove set/clear of "pcs reset" bit, since it doesn't seem to fix anything. Changes in v6: - Update MAINTAINERS to include new files - Include bitfield.h and slab.h to allow compilation on non-arm64 arches. - Depend on COMMON_CLK and either layerscape/ppc Changes in v5: - Remove references to PHY_INTERFACE_MODE_1000BASEKX to allow this series to be applied directly to linux/master. - Add fsl,lynx-10g.h to MAINTAINERS Changes in v4: - Rework all debug statements to remove use of __func__. Additional information has been provided as necessary. - Consider alternative parent rates in round_rate and not in set_rate. Trying to modify out parent's rate in set_rate will deadlock. - Explicitly perform a stop/reset sequence in set_rate. This way we always ensure that the PLL is properly stopped. - Set the power-down bit when disabling the PLL. We can do this now that enable/disable aren't abused during the set rate sequence. - Fix typos in QSGMII_OFFSET and XFI_OFFSET - Rename LNmTECR0_TEQ_TYPE_PRE to LNmTECR0_TEQ_TYPE_POST to better reflect its function (adding post-cursor equalization). - Use of_clk_hw_onecell_get instead of a custom function. - Return struct clks from lynx_clks_init instead of embedding lynx_clk in lynx_priv. - Rework PCCR helper functions; T-series SoCs differ from Layerscape SoCs primarily in the layout and offset of the PCCRs. This will help bring a cleaner abstraction layer. The caps have been removed, since this handles the only current usage. - Convert to use new binding format. As a result of this, we no longer need to have protocols for PCIe or SATA. Additionally, modes now live in lynx_group instead of lynx_priv. - Remove teq from lynx_proto_params, since it can be determined from preq_ratio/postq_ratio. - Fix an early return from lynx_se
[PATCH v13 10/15] arm64: dts: ls1046ardb: Add serdes descriptions
This adds appropriate descriptions for the macs which use the SerDes. The
156.25MHz fixed clock is a crystal. The 100MHz clocks (there are
actually 3) come from a Renesas 6V49205B at address 69 on i2c0. There is
no driver for this device (and as far as I know all you can do with the
100MHz clocks is gate them), so I have chosen to model it as a single
fixed clock.
Note: the SerDes1 lane numbering for the LS1046A is *reversed*.
This means that Lane A (what the driver thinks is lane 0) uses pins
SD1_TX3_P/N.
Signed-off-by: Sean Anderson
---
(no changes since v10)
Changes in v10:
- Move serdes descriptions to SoC dtsi
- Don't use /clocks
- Use "descriptions" instead of "bindings"
- Split off defconfig change into separate patch
Changes in v9:
- Fix name of phy mode node
- phy-type -> fsl,phy
Changes in v8:
- Rename serdes phy handles to use _A, _B, etc. instead of _0, _1, etc.
This should help remind readers that the numbering corresponds to the
physical layout of the registers, and not the lane (pin) number.
Changes in v6:
- XGI.9 -> XFI.9
Changes in v4:
- Convert to new bindings
.../boot/dts/freescale/fsl-ls1046a-rdb.dts| 26 +++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
index 07f6cc6e354a..0d6dcfd1630a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
@@ -26,6 +26,24 @@ aliases {
chosen {
stdout-path = "serial0:115200n8";
};
+
+ clk_100mhz: clock-100mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1>;
+ };
+
+ clk_156mhz: clock-156mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <15625>;
+ };
+};
+
+&serdes1 {
+ clocks = <&clk_100mhz>, <&clk_156mhz>;
+ clock-names = "ref0", "ref1";
+ status = "okay";
};
&duart0 {
@@ -140,21 +158,29 @@ ethernet@e6000 {
ethernet@e8000 {
phy-handle = <&sgmii_phy1>;
phy-connection-type = "sgmii";
+ phys = <&serdes1_B>;
+ phy-names = "serdes";
};
ethernet@ea000 {
phy-handle = <&sgmii_phy2>;
phy-connection-type = "sgmii";
+ phys = <&serdes1_A>;
+ phy-names = "serdes";
};
ethernet@f { /* 10GEC1 */
phy-handle = <&aqr106_phy>;
phy-connection-type = "xgmii";
+ phys = <&serdes1_D>;
+ phy-names = "serdes";
};
ethernet@f2000 { /* 10GEC2 */
phy-connection-type = "10gbase-r";
managed = "in-band-status";
+ phys = <&serdes1_C>;
+ phy-names = "serdes";
};
mdio@fc000 {
--
2.35.1.1320.gc452695387.dirty
[PATCH v13 06/15] clk: Add Lynx 10G SerDes PLL driver
This adds support for the PLLs found in Lynx 10G "SerDes" devices found on various NXP QorIQ SoCs. There are two PLLs in each SerDes. This driver has been split from the main PHY driver to allow for better review, even though these PLLs are not present anywhere else besides the SerDes. An auxiliary device is not used as it offers no benefits over a function call (and there is no need to have a separate device). The PLLs are modeled as clocks proper to let us take advantage of the existing clock infrastructure. I have not given the same treatment to the per-lane clocks because they need to be programmed in-concert with the rest of the lane settings. One tricky thing is that the VCO (PLL) rate exceeds 2^32 (maxing out at around 5GHz). This will be a problem on 32-bit platforms, since clock rates are stored as unsigned longs. To work around this, the pll clock rate is generally treated in units of kHz. The PLLs are configured rather interestingly. Instead of the usual direct programming of the appropriate divisors, the input and output clock rates are selected directly. Generally, the only restriction is that the input and output must be integer multiples of each other. This suggests some kind of internal look-up table. The datasheets generally list out the supported combinations explicitly, and not all input/output combinations are documented. I'm not sure if this is due to lack of support, or due to an oversight. If this becomes an issue, then some combinations can be blacklisted (or whitelisted). This may also be necessary for other SoCs which have more stringent clock requirements. Signed-off-by: Sean Anderson --- (no changes since v10) Changes in v10: - Remove unnecessary inclusion of clk.h - Don't gate clocks in compatibility mode Changes in v9: - Convert some u32s to unsigned long to match arguments - Switch from round_rate to determine_rate - Drop explicit reference to reference clock - Use .parent_names when requesting parents - Use devm_clk_hw_get_clk to pass clocks back to serdes - Fix indentation - Split off from following patch to allow for better review MAINTAINERS| 7 + drivers/clk/Makefile | 1 + drivers/clk/clk-fsl-lynx-10g.c | 510 + drivers/phy/freescale/Kconfig | 6 + include/linux/phy/lynx-10g.h | 16 ++ 5 files changed, 540 insertions(+) create mode 100644 drivers/clk/clk-fsl-lynx-10g.c create mode 100644 include/linux/phy/lynx-10g.h diff --git a/MAINTAINERS b/MAINTAINERS index fce67b74e4a2..8da893681de6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12195,6 +12195,13 @@ S: Maintained W: http://linux-test-project.github.io/ T: git https://github.com/linux-test-project/ltp.git +LYNX 10G SERDES DRIVER +M: Sean Anderson +S: Maintained +F: drivers/clk/clk-fsl-lynx-10g.c +F: include/dt-bindings/clock/fsl,lynx-10g.h +F: include/linux/phy/lynx-10g.h + LYNX 28G SERDES PHY DRIVER M: Ioana Ciornei L: net...@vger.kernel.org diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index e3ca0d058a25..eebed69f6c58 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -33,6 +33,7 @@ obj-$(CONFIG_ARCH_SPARX5) += clk-sparx5.o obj-$(CONFIG_COMMON_CLK_EN7523)+= clk-en7523.o obj-$(CONFIG_COMMON_CLK_FIXED_MMIO)+= clk-fixed-mmio.o obj-$(CONFIG_COMMON_CLK_FSL_FLEXSPI) += clk-fsl-flexspi.o +obj-$(CONFIG_PHY_FSL_LYNX_10G) += clk-fsl-lynx-10g.o obj-$(CONFIG_COMMON_CLK_FSL_SAI) += clk-fsl-sai.o obj-$(CONFIG_COMMON_CLK_GEMINI)+= clk-gemini.o obj-$(CONFIG_COMMON_CLK_ASPEED)+= clk-aspeed.o diff --git a/drivers/clk/clk-fsl-lynx-10g.c b/drivers/clk/clk-fsl-lynx-10g.c new file mode 100644 index ..78357303b578 --- /dev/null +++ b/drivers/clk/clk-fsl-lynx-10g.c @@ -0,0 +1,510 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2022 Sean Anderson + * + * This file contains the implementation for the PLLs found on Lynx 10G phys. + * + * XXX: The VCO rate of the PLLs can exceed ~4GHz, which is the maximum rate + * expressable in an unsigned long. To work around this, rates are specified in + * kHz. This is as if there was a division by 1000 in the PLL. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define PLL_STRIDE 0x20 +#define PLLa(a, off) ((a) * PLL_STRIDE + (off)) +#define PLLaRSTCTL(a) PLLa(a, 0x00) +#define PLLaCR0(a) PLLa(a, 0x04) + +#define PLLaRSTCTL_RSTREQ BIT(31) +#define PLLaRSTCTL_RST_DONEBIT(30) +#define PLLaRSTCTL_RST_ERR BIT(29) +#define PLLaRSTCTL_PLLRST_BBIT(7) +#define PLLaRSTCTL_SDRST_B BIT(6) +#define PLLaRSTCTL_SDENBIT(5) + +#define PLLaRSTCTL_ENABLE_SET (PLLaRSTCTL_RST_DONE | PLLaRSTCTL_PLLRST_B | \ +PLLaRSTCTL_SDRST_B | PLLaRSTCTL_SDEN) +#define PLLaRSTCTL_ENABLE_MASK (PLLaRSTCTL_ENABLE_SET | PLLaRSTCTL_RST_ER
[PATCH v13 08/15] phy: lynx10g: Enable by default on Layerscape
The next few patches will break ethernet if the serdes is not enabled, so enable the serdes driver by default on Layerscape. Signed-off-by: Sean Anderson --- (no changes since v10) Changes in v10: - New drivers/phy/freescale/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig index 6bebe00f5889..b396162dc859 100644 --- a/drivers/phy/freescale/Kconfig +++ b/drivers/phy/freescale/Kconfig @@ -54,6 +54,7 @@ config PHY_FSL_LYNX_10G depends on ARCH_LAYERSCAPE || PPC || COMPILE_TEST select GENERIC_PHY select REGMAP_MMIO + default y if ARCH_LAYERSCAPE help This adds support for the Lynx "SerDes" devices found on various QorIQ SoCs. There may be up to four SerDes devices on each SoC, and each -- 2.35.1.1320.gc452695387.dirty
[PATCH v13 02/15] dt-bindings: phy: Add Lynx 10G phy binding
This adds a binding for the SerDes module found on QorIQ processors. Each phy is a subnode of the top-level device, possibly supporting multiple lanes and protocols. This "thick" #phy-cells is used due to allow for better organization of parameters. Note that the particular parameters necessary to select a protocol-controller/lane combination vary across different SoCs, and even within different SerDes on the same SoC. The driver is designed to be able to completely reconfigure lanes at runtime. Generally, the phy consumer can select the appropriate protocol using set_mode. There are two PLLs, each of which can be used as the master clock for each lane. Each PLL has its own reference. For the moment they are required, because it simplifies the driver implementation. Absent reference clocks can be modeled by a fixed-clock with a rate of 0. Signed-off-by: Sean Anderson Reviewed-by: Rob Herring --- (no changes since v9) Changes in v9: - Add fsl,unused-lanes-reserved to allow for a gradual transition between firmware and Linux control of the SerDes - Change phy-type back to fsl,type, as I was getting the error '#phy-cells' is a dependency of 'phy-type' Changes in v7: - Use double quotes everywhere in yaml Changes in v6: - fsl,type -> phy-type Changes in v4: - Use subnodes to describe lane configuration, instead of describing PCCRs. This is the same style used by phy-cadence-sierra et al. Changes in v3: - Manually expand yaml references - Add mode configuration to device tree Changes in v2: - Rename to fsl,lynx-10g.yaml - Refer to the device in the documentation, rather than the binding - Move compatible first - Document phy cells in the description - Allow a value of 1 for phy-cells. This allows for compatibility with the similar (but according to Ioana Ciornei different enough) lynx-28g binding. - Remove minItems - Use list for clock-names - Fix example binding having too many cells in regs - Add #clock-cells. This will allow using assigned-clocks* to configure the PLLs. - Document the structure of the compatible strings .../devicetree/bindings/phy/fsl,lynx-10g.yaml | 248 ++ 1 file changed, 248 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/fsl,lynx-10g.yaml diff --git a/Documentation/devicetree/bindings/phy/fsl,lynx-10g.yaml b/Documentation/devicetree/bindings/phy/fsl,lynx-10g.yaml new file mode 100644 index ..7c364f7de85c --- /dev/null +++ b/Documentation/devicetree/bindings/phy/fsl,lynx-10g.yaml @@ -0,0 +1,248 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/fsl,lynx-10g.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP Lynx 10G SerDes + +maintainers: + - Sean Anderson + +description: | + These Lynx "SerDes" devices are found in NXP's QorIQ line of processors. The + SerDes provides up to eight lanes. Each lane may be configured individually, + or may be combined with adjacent lanes for a multi-lane protocol. The SerDes + supports a variety of protocols, including up to 10G Ethernet, PCIe, SATA, and + others. The specific protocols supported for each lane depend on the + particular SoC. + +properties: + compatible: +items: + - enum: + - fsl,ls1046a-serdes + - fsl,ls1088a-serdes + - const: fsl,lynx-10g + + "#address-cells": +const: 1 + + "#size-cells": +const: 0 + + "#clock-cells": +const: 1 +description: | + The cell contains an ID as described in dt-bindings/clock/fsl,lynx-10g.h. + Note that when assigning a rate to a PLL, the PLL's rate is divided by + 1000 to avoid overflow. A rate of 500 corresponds to 5GHz. + + clocks: +maxItems: 2 +description: | + Clock for each PLL reference clock input. + + clock-names: +minItems: 2 +maxItems: 2 +items: + enum: +- ref0 +- ref1 + + fsl,unused-lanes-reserved: +$ref: /schemas/types.yaml#/definitions/flag +description: | + Unused lanes are reserved for firmware use, and should not be disabled. + Normally, groups containing unused lanes may be reconfigured or disabled + to save power. However, when this property is present, unused lanes will + not be touched until they are used by another driver. This allows + migrating from firmware control of lanes to driver control. + + Lanes not present in any group will never be modified, regardless of the + presence of this property. + + reg: +maxItems: 1 + +patternProperties: + "^phy@": +type: object + +description: | + A contiguous group of lanes which will be configured together. Each group + corresponds to one phy device. Lanes not described by any group will be + left as-is. + +properties: + "#phy-cells": +const: 0 + + reg: +minItems: 1 +maxItems: 8 +description: + The lanes in the group. These must
[PATCH v13 03/15] dt-bindings: Convert gpio-mmio to yaml
This is a generic binding for simple MMIO GPIO controllers. Although we
have a single driver for these controllers, they were previously spread
over several files. Consolidate them. The register descriptions are
adapted from the comments in the source. There is no set order for the
registers, and some registers may be omitted. Because of this, reg-names
is mandatory, and no order is specified.
Rename brcm,bcm6345-gpio to brcm,bcm63xx-gpio to reflect that bcm6345
has moved.
Signed-off-by: Sean Anderson
Reviewed-by: Linus Walleij
---
Linus or Bartosz, feel free to pick this up as the rest of this series
may not be merged any time soon.
Changes in v13:
- Fix references to brcm,bcm63xx-gpio.yaml (neé brcm,bcm6345-gpio)
Changes in v12:
- Put compatible first
- Keep gpio-controller to one line
- Add little-endian property
- Alphabetize compatibles
- Remove some comments
- Remove some examples with insufficient novelty
Changes in v11:
- Keep empty (or almost-empty) properties on a single line
- Don't use | unnecessarily
- Use gpio as the node name for examples
- Rename brcm,bcm6345-gpio.yaml to brcm,bcm63xx-gpio.yaml
Changes in v10:
- New
...m6345-gpio.yaml => brcm,bcm63xx-gpio.yaml} | 16 +--
.../devicetree/bindings/gpio/gpio-mmio.yaml | 117 ++
.../bindings/gpio/ni,169445-nand-gpio.txt | 38 --
.../devicetree/bindings/gpio/wd,mbl-gpio.txt | 38 --
.../mfd/brcm,bcm6318-gpio-sysctl.yaml | 4 +-
.../mfd/brcm,bcm63268-gpio-sysctl.yaml| 4 +-
.../mfd/brcm,bcm6328-gpio-sysctl.yaml | 4 +-
.../mfd/brcm,bcm6358-gpio-sysctl.yaml | 4 +-
.../mfd/brcm,bcm6362-gpio-sysctl.yaml | 4 +-
.../mfd/brcm,bcm6368-gpio-sysctl.yaml | 4 +-
10 files changed, 130 insertions(+), 103 deletions(-)
rename Documentation/devicetree/bindings/gpio/{brcm,bcm6345-gpio.yaml =>
brcm,bcm63xx-gpio.yaml} (78%)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
delete mode 100644
Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt
delete mode 100644 Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt
diff --git a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
b/Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml
similarity index 78%
rename from Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
rename to Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml
index 4d69f79df859..e11f4af49c52 100644
--- a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/gpio/brcm,bcm6345-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BCM6345 GPIO controller
+title: Broadcom BCM63xx GPIO controller
maintainers:
- Álvaro Fernández Rojas
@@ -18,8 +18,6 @@ description: |+
BCM6338 have 8-bit data and dirout registers, where GPIO state can be read
and/or written, and the direction changed from input to output.
- BCM6345 have 16-bit data and dirout registers, where GPIO state can be read
- and/or written, and the direction changed from input to output.
BCM6318, BCM6328, BCM6358, BCM6362, BCM6368 and BCM63268 have 32-bit data
and dirout registers, where GPIO state can be read and/or written, and the
direction changed from input to output.
@@ -29,7 +27,6 @@ properties:
enum:
- brcm,bcm6318-gpio
- brcm,bcm6328-gpio
- - brcm,bcm6345-gpio
- brcm,bcm6358-gpio
- brcm,bcm6362-gpio
- brcm,bcm6368-gpio
@@ -63,17 +60,6 @@ required:
additionalProperties: false
examples:
- - |
-gpio@fffe0406 {
- compatible = "brcm,bcm6345-gpio";
- reg-names = "dirout", "dat";
- reg = <0xfffe0406 2>, <0xfffe040a 2>;
- native-endian;
-
- gpio-controller;
- #gpio-cells = <2>;
-};
-
- |
gpio@0 {
compatible = "brcm,bcm63268-gpio";
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
new file mode 100644
index ..b394e058256e
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/gpio-mmio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic MMIO GPIO
+
+maintainers:
+ - Linus Walleij
+ - Bartosz Golaszewski
+
+description:
+ Some simple GPIO controllers may consist of a single data register or a pair
+ of set/clear-bit registers. Such controllers are common for glue logic in
+ FPGAs or ASICs. Commonly, these controllers are accessed over memory-mapped
+ NAND-style parallel busses.
+
+properties:
+ compatible:
+enum:
+ - brcm,bcm6345-gpio
+ - ni,169445-nand-gpio
+ - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO controller
+
+ b
[PATCH v13 01/15] dt-bindings: phy: Add 2500BASE-X and 10GBASE-R
This adds some modes necessary for Lynx 10G support. 2500BASE-X, also known as 2.5G SGMII, is 1000BASE-X/SGMII overclocked to 3.125 GHz, with autonegotiation disabled. 10GBASE-R, also known as XFI, is the protocol spoken between the PMA and PMD ethernet layers for 10GBASE-T and 10GBASE-S/L/E. It is typically used to communicate directly with SFP+ modules, or with 10GBASE-T phys. Signed-off-by: Sean Anderson Acked-by: Rob Herring --- PR increasing phy-type maximum [1]. If this commit could be applied sooner rather than later, I'd appreciate it. This should help avoid another respin if someone else adds another phy type. [1] https://github.com/devicetree-org/dt-schema/pull/85 (no changes since v6) Changes in v6: - Bump PHY_TYPE_2500BASEX to 13, since PHY_TYPE_USXGMII was added in the meantime Changes in v4: - New include/dt-bindings/phy/phy.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/dt-bindings/phy/phy.h b/include/dt-bindings/phy/phy.h index 6b901b342348..5b2b674d8d25 100644 --- a/include/dt-bindings/phy/phy.h +++ b/include/dt-bindings/phy/phy.h @@ -23,5 +23,7 @@ #define PHY_TYPE_DPHY 10 #define PHY_TYPE_CPHY 11 #define PHY_TYPE_USXGMII 12 +#define PHY_TYPE_2500BASEX 13 +#define PHY_TYPE_10GBASER 14 #endif /* _DT_BINDINGS_PHY */ -- 2.35.1.1320.gc452695387.dirty
[PATCH v13 05/15] dt-bindings: clock: Add ids for Lynx 10g PLLs
This adds ids for the Lynx 10g SerDes's internal PLLs. These may be used with assigned-clock* to specify a particular frequency to use. For example, to set the second PLL (at offset 0x20)'s frequency, use LYNX10G_PLLa(1). These are for use only in the device tree, and are not otherwise used by the driver. Signed-off-by: Sean Anderson Acked-by: Rob Herring --- (no changes since v6) Changes in v6: - frequence -> frequency Changes in v5: - Update commit description - Dual id header Changes in v4: - New include/dt-bindings/clock/fsl,lynx-10g.h | 14 ++ 1 file changed, 14 insertions(+) create mode 100644 include/dt-bindings/clock/fsl,lynx-10g.h diff --git a/include/dt-bindings/clock/fsl,lynx-10g.h b/include/dt-bindings/clock/fsl,lynx-10g.h new file mode 100644 index ..15362ae85304 --- /dev/null +++ b/include/dt-bindings/clock/fsl,lynx-10g.h @@ -0,0 +1,14 @@ +/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */ +/* + * Copyright (C) 2022 Sean Anderson + */ + +#ifndef __DT_BINDINGS_CLK_LYNX_10G_H +#define __DT_BINDINGS_CLK_LYNX_10G_H + +#define LYNX10G_CLKS_PER_PLL 2 + +#define LYNX10G_PLLa(a)((a) * LYNX10G_CLKS_PER_PLL) +#define LYNX10G_PLLa_EX_DLY(a) ((a) * LYNX10G_CLKS_PER_PLL + 1) + +#endif /* __DT_BINDINGS_CLK_LYNX_10G_H */ -- 2.35.1.1320.gc452695387.dirty
[PATCH v13 00/15] phy: Add support for Lynx 10G SerDes
This adds support for the Lynx 10G SerDes found on the QorIQ T-series and Layerscape series. Due to limited time and hardware, only support for the LS1046ARDB and LS1088ARDB is added in this initial series. This series is ready for review by the phy maintainers. I have addressed all known feedback and there are no outstanding issues. There are several stand-alone commits in this series. Please feel free to pick them as appropriate. In particular, commits 1, 3, 4, 12, 13, and 14 are all good candidates for picking. Major reconfiguration of baud rate (e.g. 1G->10G) does not work. From my testing, SerDes register settings appear identical. The issue appears to be between the PCS and the MAC. The link itself comes up at both ends, and a mac loopback succeeds. However, a PCS loopback results in dropped packets. Perhaps there is some undocumented register in the PCS? I suspect this driver is around 95% complete, but I don't have the documentation to make it work completely. At the very least it is useful for two cases: - Although this is untested, it should support 2.5G SGMII as well as 1000BASE-KX. The latter needs MAC and PCS support, but the former should work out of the box. - It allows for clock configurations not supported by the RCW. This is very useful if you want to use e.g. SRDS_PRTCL_S1=0x and =0x1133 on the same board. This is because the former setting will use PLL1 as the 1G reference, but the latter will use PLL1 as the 10G reference. Because we can reconfigure the PLLs, it is possible to always use PLL1 as the 1G reference. Changes in v13: - Fix references to brcm,bcm63xx-gpio.yaml (neé brcm,bcm6345-gpio) - Split interrupt changes off from serdes support - Split off SFP addition from serdes support Changes in v12: - Put compatible first - Keep gpio-controller to one line - Add little-endian property - Alphabetize compatibles - Remove some comments - Remove some examples with insufficient novelty Changes in v11: - Keep empty (or almost-empty) properties on a single line - Don't use | unnecessarily - Use gpio as the node name for examples - Rename brcm,bcm6345-gpio.yaml to brcm,bcm63xx-gpio.yaml Changes in v10: - Convert gpio-mmio to yaml - Add compatible for QIXIS - Remove unnecessary inclusion of clk.h - Don't gate clocks in compatibility mode - Fix debugging print with incorrect error variable - Move serdes bindings to SoC dtsi - Add support for all (ethernet) serdes modes - Refer to "nodes" instead of "bindings" - Move compatible/reg first Changes in v9: - Add fsl,unused-lanes-reserved to allow for a gradual transition between firmware and Linux control of the SerDes - Change phy-type back to fsl,type, as I was getting the error '#phy-cells' is a dependency of 'phy-type' - Convert some u32s to unsigned long to match arguments - Switch from round_rate to determine_rate - Drop explicit reference to reference clock - Use .parent_names when requesting parents - Use devm_clk_hw_get_clk to pass clocks back to serdes - Fix indentation - Split off clock "driver" into its own patch to allow for better review. - Add ability to defer lane initialization to phy_init. This allows for easier transitioning between firmware-managed serdes and Linux- managed serdes, as the consumer (such as dpaa2, which knows what the firmware is doing) has the last say on who gets control. - Fix name of phy mode node - Add fsl,unused-lanes-reserved to allow a gradual transition, depending on the mac link type. - Remove unused clocks - Fix some phy mode node names Changes in v8: - Remove unused variable from lynx_ls_mode_init - Rename serdes phy handles to use _A, _B, etc. instead of _0, _1, etc. This should help remind readers that the numbering corresponds to the physical layout of the registers, and not the lane (pin) number. - Prevent PCSs from probing as phys - Rename serdes phy handles like the LS1046A - Add SFP slot binding - Fix incorrect lane ordering (it's backwards on the LS1088A just like it is in the LS1046A). - Fix duplicated lane 2 (it should have been lane 3). - Fix incorrectly-documented value for XFI1. - Remove interrupt for aquantia phy. It never fired for whatever reason, preventing the link from coming up. - Add GPIOs for QIXIS FPGA. - Enable MAC1 PCS - Remove si5341 binding Changes in v7: - Use double quotes everywhere in yaml - Break out call order into generic documentation - Refuse to switch "major" protocols - Update Kconfig to reflect restrictions - Remove set/clear of "pcs reset" bit, since it doesn't seem to fix anything. Changes in v6: - Bump PHY_TYPE_2500BASEX to 13, since PHY_TYPE_USXGMII was added in the meantime - fsl,type -> phy-type - frequence -> frequency - Update MAINTAINERS to include new files - Include bitfield.h and slab.h to allow compilation on non-arm64 arches. - Depend on COMMON_CLK and either layerscape/ppc - XGI.9 -> XFI.9 Changes in v5: - Update commit description - Dual id header - Remove references to PHY_INTERFACE
[PATCH v13 04/15] dt-bindings: gpio-mmio: Add compatible for QIXIS
NXP has a "QIXIS" FPGA on several of their reference design boards. On the LS1088ARDB there are several registers which control GPIOs. These can be modeled with the MMIO GPIO driver. Signed-off-by: Sean Anderson Reviewed-by: Rob Herring --- (no changes since v10) Changes in v10: - New .../devicetree/bindings/gpio/gpio-mmio.yaml| 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml index b394e058256e..5abf3dabcf39 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml @@ -18,10 +18,16 @@ description: properties: compatible: -enum: - - brcm,bcm6345-gpio - - ni,169445-nand-gpio - - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO controller +oneOf: + - enum: + - brcm,bcm6345-gpio + - ni,169445-nand-gpio + - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO controller + - items: + - enum: + - fsl,fpga-qixis-los-stat + - fsl,fpga-qixis-brdcfg9 + - const: ni,169445-nand-gpio big-endian: true -- 2.35.1.1320.gc452695387.dirty
Re: [PATCH v3 2/2] soc: fsl: qbman: Use raw spinlock for cgr_lock
Hi Crystal,
On 4/4/23 12:04, Sean Anderson wrote:
> On 4/4/23 11:33, Crystal Wood wrote:
>> On Tue, 2023-04-04 at 10:55 -0400, Sean Anderson wrote:
>>
>>> @@ -1456,11 +1456,11 @@ static void tqm_congestion_task(struct work_struct
>>> *work)
>>> union qm_mc_result *mcr;
>>> struct qman_cgr *cgr;
>>>
>>> - spin_lock_irq(&p->cgr_lock);
>>> + raw_spin_lock_irq(&p->cgr_lock);
>>> qm_mc_start(&p->p);
>>> qm_mc_commit(&p->p, QM_MCC_VERB_QUERYCONGESTION);
>>> if (!qm_mc_result_timeout(&p->p, &mcr)) {
>>> - spin_unlock_irq(&p->cgr_lock);
>>> + raw_spin_unlock_irq(&p->cgr_lock);
>>
>> qm_mc_result_timeout() spins with a timeout of 10 ms which is very
>> inappropriate for a raw lock. What is the actual expected upper bound?
>
> Hm, maybe we can move this qm_mc stuff outside cgr_lock? In most other
> places they're called without cgr_lock, which implies that its usage
> here is meant to synchronize against some other function.
Do you have any suggestions here? I think this should really be handled
in a follow-up patch. If you think this code is waiting too long in a raw
spinlock, the existing code can wait just as long with IRQs disabled.
This patch doesn't change existing system responsiveness.
--Sean
>>> dev_crit(p->config->dev, "QUERYCONGESTION timeout\n");
>>> qman_p_irqsource_add(p, QM_PIRQ_CSCI);
>>> return;
>>> @@ -1476,7 +1476,7 @@ static void qm_congestion_task(struct work_struct
>>> *work)
>>> list_for_each_entry(cgr, &p->cgr_cbs, node)
>>> if (cgr->cb && qman_cgrs_get(&c, cgr->cgrid))
>>> cgr->cb(p, cgr, qman_cgrs_get(&rr, cgr->cgrid));
>>> - spin_unlock_irq(&p->cgr_lock);
>>> + raw_spin_unlock_irq(&p->cgr_lock);
>>> qman_p_irqsource_add(p, QM_PIRQ_CSCI);
>>> }
>>
>> The callback loop is also a bit concerning...
>
> The callbacks (in .../dpaa/dpaa_eth.c and .../caam/qi.c) look OK. The
> only thing which might take a bit is dpaa_eth_refill_bpools, which
> allocates memory (from the atomic pool).
>
> --Sean
Re: [PATCH v2 0/5] locking: Introduce local{,64}_try_cmpxchg
On 4/11/23 04:35, Mark Rutland wrote: > I agree it'd be nice to have performance figures, but I think those would only > need to demonstrate a lack of a regression rather than a performance > improvement, and I think it's fairly clear from eyeballing the generated > instructions that a regression isn't likely. Thanks for the additional context. I totally agree that there's zero burden here to show a performance increase. If anyone can think of a quick way to do _some_ kind of benchmark on the code being changed and just show that it's free of brown paper bags, it would be appreciated. Nothing crazy, just think of one workload (synthetic or not) that will stress the paths being changed and run it with and without these changes. Make sure there are not surprises. I also agree that it's unlikely to be brown paper bag material.
Re: [PATCH v2 0/5] locking: Introduce local{,64}_try_cmpxchg
On Wed, Apr 05, 2023 at 09:37:04AM -0700, Dave Hansen wrote:
> On 4/5/23 07:17, Uros Bizjak wrote:
> > Add generic and target specific support for local{,64}_try_cmpxchg
> > and wire up support for all targets that use local_t infrastructure.
>
> I feel like I'm missing some context.
>
> What are the actual end user visible effects of this series? Is there a
> measurable decrease in perf overhead? Why go to all this trouble for
> perf? Who else will use local_try_cmpxchg()?
Overall, the theory is that it can generate slightly better code (e.g. by
reusing the flags on x86). In practice, that might be in the noise, but as
demonstrated in prior postings the code generation is no worse than before.
>From my perspective, the more important part is that this aligns local_t with
the other atomic*_t APIs, which all have ${atomictype}_try_cmpxchg(), and for
consistency/legibility/maintainability it's nice to be able to use the same
code patterns, e.g.
${inttype} new, old = ${atomictype}_read(ptr);
do {
...
new = do_something_with(old);
} while (${atomictype}_try_cmpxvhg(ptr, &oldval, newval);
> I'm all for improving things, and perf is an important user. But, if
> the goal here is improving performance, it would be nice to see at least
> a stab at quantifying the performance delta.
IIUC, Steve's original request for local_try_cmpxchg() was a combination of a
theoretical performance benefit and a more general preference to use
try_cmpxchg() for consistency / better structure of the source code:
https://lore.kernel.org/lkml/20230301131831.6c8d4...@gandalf.local.home/
I agree it'd be nice to have performance figures, but I think those would only
need to demonstrate a lack of a regression rather than a performance
improvement, and I think it's fairly clear from eyeballing the generated
instructions that a regression isn't likely.
Thanks,
Mark.
[PATCH v2] soc/fsl/qe: fix usb.c build errors
Fix build errors in soc/fsl/qe/usb.c when QUICC_ENGINE is not set.
This happens when PPC_EP88XC is set, which selects CPM1 & CPM.
When CPM is set, USB_FSL_QE can be set without QUICC_ENGINE
being set. When USB_FSL_QE is set, QE_USB deafults to y, which
causes build errors when QUICC_ENGINE is not set. Making
QE_USB depend on QUICC_ENGINE prevents QE_USB from defaulting to y.
Fixes these build errors:
drivers/soc/fsl/qe/usb.o: in function `qe_usb_clock_set':
usb.c:(.text+0x1e): undefined reference to `qe_immr'
powerpc-linux-ld: usb.c:(.text+0x2a): undefined reference to `qe_immr'
powerpc-linux-ld: usb.c:(.text+0xbc): undefined reference to `qe_setbrg'
powerpc-linux-ld: usb.c:(.text+0xca): undefined reference to `cmxgcr_lock'
powerpc-linux-ld: usb.c:(.text+0xce): undefined reference to `cmxgcr_lock'
Fixes: 5e41486c408e ("powerpc/QE: add support for QE USB clocks routing")
Signed-off-by: Randy Dunlap
Reported-by: kernel test robot
Link: https://lore.kernel.org/all/202301101500.pillnv6r-...@intel.com/
Suggested-by: Michael Ellerman
Cc: Christophe Leroy
Cc: Leo Li
Cc: Masahiro Yamada
Cc: Nicolas Schier
Cc: Qiang Zhao
Cc: linuxppc-dev
Cc: linux-arm-ker...@lists.infradead.org
Cc: Kumar Gala
---
v2: drop Anton Vorontsov ; rebase/resend
drivers/soc/fsl/qe/Kconfig |1 +
1 file changed, 1 insertion(+)
diff -- a/drivers/soc/fsl/qe/Kconfig b/drivers/soc/fsl/qe/Kconfig
--- a/drivers/soc/fsl/qe/Kconfig
+++ b/drivers/soc/fsl/qe/Kconfig
@@ -62,6 +62,7 @@ config QE_TDM
config QE_USB
bool
+ depends on QUICC_ENGINE
default y if USB_FSL_QE
help
QE USB Controller support
Re: [PATCH v2 2/5] locking/generic: Wire up local{,64}_try_cmpxchg
On Wed, Apr 05, 2023 at 04:17:07PM +0200, Uros Bizjak wrote:
> Implement generic support for local{,64}_try_cmpxchg.
>
> Redirect to the atomic_ family of functions when the target
> does not provide its own local.h definitions.
>
> For 64-bit targets, implement local64_try_cmpxchg and
> local64_cmpxchg using typed C wrappers that call local_
> family of functions and provide additional checking
> of their input arguments.
>
> Cc: Arnd Bergmann
> Signed-off-by: Uros Bizjak
Acked-by: Mark Rutland
Mark.
> ---
> include/asm-generic/local.h | 1 +
> include/asm-generic/local64.h | 12 +++-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/include/asm-generic/local.h b/include/asm-generic/local.h
> index fca7f1d84818..7f97018df66f 100644
> --- a/include/asm-generic/local.h
> +++ b/include/asm-generic/local.h
> @@ -42,6 +42,7 @@ typedef struct
> #define local_inc_return(l) atomic_long_inc_return(&(l)->a)
>
> #define local_cmpxchg(l, o, n) atomic_long_cmpxchg((&(l)->a), (o), (n))
> +#define local_try_cmpxchg(l, po, n) atomic_long_try_cmpxchg((&(l)->a), (po),
> (n))
> #define local_xchg(l, n) atomic_long_xchg((&(l)->a), (n))
> #define local_add_unless(l, _a, u) atomic_long_add_unless((&(l)->a), (_a),
> (u))
> #define local_inc_not_zero(l) atomic_long_inc_not_zero(&(l)->a)
> diff --git a/include/asm-generic/local64.h b/include/asm-generic/local64.h
> index 765be0b7d883..14963a7a6253 100644
> --- a/include/asm-generic/local64.h
> +++ b/include/asm-generic/local64.h
> @@ -42,7 +42,16 @@ typedef struct {
> #define local64_sub_return(i, l) local_sub_return((i), (&(l)->a))
> #define local64_inc_return(l)local_inc_return(&(l)->a)
>
> -#define local64_cmpxchg(l, o, n) local_cmpxchg((&(l)->a), (o), (n))
> +static inline s64 local64_cmpxchg(local64_t *l, s64 old, s64 new)
> +{
> + return local_cmpxchg(&l->a, old, new);
> +}
> +
> +static inline bool local64_try_cmpxchg(local64_t *l, s64 *old, s64 new)
> +{
> + return local_try_cmpxchg(&l->a, (long *)old, new);
> +}
> +
> #define local64_xchg(l, n) local_xchg((&(l)->a), (n))
> #define local64_add_unless(l, _a, u) local_add_unless((&(l)->a), (_a), (u))
> #define local64_inc_not_zero(l) local_inc_not_zero(&(l)->a)
> @@ -81,6 +90,7 @@ typedef struct {
> #define local64_inc_return(l)atomic64_inc_return(&(l)->a)
>
> #define local64_cmpxchg(l, o, n) atomic64_cmpxchg((&(l)->a), (o), (n))
> +#define local64_try_cmpxchg(l, po, n) atomic64_try_cmpxchg((&(l)->a), (po),
> (n))
> #define local64_xchg(l, n) atomic64_xchg((&(l)->a), (n))
> #define local64_add_unless(l, _a, u) atomic64_add_unless((&(l)->a), (_a),
> (u))
> #define local64_inc_not_zero(l) atomic64_inc_not_zero(&(l)->a)
> --
> 2.39.2
>
Re: [PATCH v2 1/5] locking/atomic: Add generic try_cmpxchg{,64}_local support
On Wed, Apr 05, 2023 at 04:17:06PM +0200, Uros Bizjak wrote:
> Add generic support for try_cmpxchg{,64}_local and their falbacks.
>
> These provides the generic try_cmpxchg_local family of functions
> from the arch_ prefixed version, also adding explicit instrumentation.
>
> Cc: Will Deacon
> Cc: Peter Zijlstra
> Cc: Boqun Feng
> Cc: Mark Rutland
> Signed-off-by: Uros Bizjak
Acked-by: Mark Rutland
Mark.
> ---
> include/linux/atomic/atomic-arch-fallback.h | 24 -
> include/linux/atomic/atomic-instrumented.h | 20 -
> scripts/atomic/gen-atomic-fallback.sh | 4
> scripts/atomic/gen-atomic-instrumented.sh | 2 +-
> 4 files changed, 47 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/atomic/atomic-arch-fallback.h
> b/include/linux/atomic/atomic-arch-fallback.h
> index 77bc5522e61c..36c92851cdee 100644
> --- a/include/linux/atomic/atomic-arch-fallback.h
> +++ b/include/linux/atomic/atomic-arch-fallback.h
> @@ -217,6 +217,28 @@
>
> #endif /* arch_try_cmpxchg64_relaxed */
>
> +#ifndef arch_try_cmpxchg_local
> +#define arch_try_cmpxchg_local(_ptr, _oldp, _new) \
> +({ \
> + typeof(*(_ptr)) *___op = (_oldp), ___o = *___op, ___r; \
> + ___r = arch_cmpxchg_local((_ptr), ___o, (_new)); \
> + if (unlikely(___r != ___o)) \
> + *___op = ___r; \
> + likely(___r == ___o); \
> +})
> +#endif /* arch_try_cmpxchg_local */
> +
> +#ifndef arch_try_cmpxchg64_local
> +#define arch_try_cmpxchg64_local(_ptr, _oldp, _new) \
> +({ \
> + typeof(*(_ptr)) *___op = (_oldp), ___o = *___op, ___r; \
> + ___r = arch_cmpxchg64_local((_ptr), ___o, (_new)); \
> + if (unlikely(___r != ___o)) \
> + *___op = ___r; \
> + likely(___r == ___o); \
> +})
> +#endif /* arch_try_cmpxchg64_local */
> +
> #ifndef arch_atomic_read_acquire
> static __always_inline int
> arch_atomic_read_acquire(const atomic_t *v)
> @@ -2456,4 +2478,4 @@ arch_atomic64_dec_if_positive(atomic64_t *v)
> #endif
>
> #endif /* _LINUX_ATOMIC_FALLBACK_H */
> -// b5e87bdd5ede61470c29f7a7e4de781af3770f09
> +// 1f49bd4895a4b7a5383906649027205c52ec80ab
> diff --git a/include/linux/atomic/atomic-instrumented.h
> b/include/linux/atomic/atomic-instrumented.h
> index 7a139ec030b0..14a9212cc987 100644
> --- a/include/linux/atomic/atomic-instrumented.h
> +++ b/include/linux/atomic/atomic-instrumented.h
> @@ -2066,6 +2066,24 @@ atomic_long_dec_if_positive(atomic_long_t *v)
> arch_sync_cmpxchg(__ai_ptr, __VA_ARGS__); \
> })
>
> +#define try_cmpxchg_local(ptr, oldp, ...) \
> +({ \
> + typeof(ptr) __ai_ptr = (ptr); \
> + typeof(oldp) __ai_oldp = (oldp); \
> + instrument_atomic_write(__ai_ptr, sizeof(*__ai_ptr)); \
> + instrument_atomic_write(__ai_oldp, sizeof(*__ai_oldp)); \
> + arch_try_cmpxchg_local(__ai_ptr, __ai_oldp, __VA_ARGS__); \
> +})
> +
> +#define try_cmpxchg64_local(ptr, oldp, ...) \
> +({ \
> + typeof(ptr) __ai_ptr = (ptr); \
> + typeof(oldp) __ai_oldp = (oldp); \
> + instrument_atomic_write(__ai_ptr, sizeof(*__ai_ptr)); \
> + instrument_atomic_write(__ai_oldp, sizeof(*__ai_oldp)); \
> + arch_try_cmpxchg64_local(__ai_ptr, __ai_oldp, __VA_ARGS__); \
> +})
> +
> #define cmpxchg_double(ptr, ...) \
> ({ \
> typeof(ptr) __ai_ptr = (ptr); \
> @@ -2083,4 +2101,4 @@ atomic_long_dec_if_positive(atomic_long_t *v)
> })
>
> #endif /* _LINUX_ATOMIC_INSTRUMENTED_H */
> -// 764f741eb77a7ad565dc8d99ce2837d5542e8aee
> +// 456e206c7e4e681126c482e4edcc6f46921ac731
> diff --git a/scripts/atomic/gen-atomic-fallback.sh
> b/scripts/atomic/gen-atomic-fallback.sh
> index 3a07695e3c89..6e853f0dad8d 100755
> --- a/scripts/atomic/gen-atomic-fallback.sh
> +++ b/scripts/atomic/gen-atomic-fallback.sh
> @@ -225,6 +225,10 @@ for cmpxchg in "cmpxchg" "cmpxchg64"; do
> gen_try_cmpxchg_fallbacks "${cmpxchg}"
> done
>
> +for cmpxchg in "cmpxchg_local" "cmpxchg64_local"; do
> + gen_try_cmpxchg_fallback "${cmpxchg}" ""
> +done
> +
> grep '^[a-z]' "$1" | while read name meta args; do
> gen_proto "${meta}" "${name}" "atomic" "int" ${args}
> done
> diff --git a/scripts/atomic/gen-atomic-instrumented.sh
> b/scripts/atomic/gen-atomic-instrumented.sh
> index 77c06526a574..c8165e9431bf 100755
> --- a/scripts/atomic/gen-atomic-instrumented.sh
> +++ b/scripts/atomic/gen-atomic-instrumented.sh
> @@ -173,7 +173,7 @@ for xchg in "xchg" "cmpxchg" "cmpxchg64" "try_cmpxchg"
> "try_cmpxchg64"; do
> done
> done
>
> -for xchg in "cmpxchg_local" "cmpxchg64_local" "sync_cmpxchg"; do
> +for xchg in "cmpxchg_local" "cmpxchg64_local" "sync_cmpxchg"
> "try_cmpxchg_local" "try_cmpxchg64_local" ; do
> gen_xchg "${xchg}" "" ""
> printf "\n"
> done
> --
> 2.39.2
>
[PATCH] powerpc/corenet: Add PPC_QEMU_E500 to corenet configs
Add PPC_QEMU_E500 to corenet_base.config, which is then used to generate corenet64_smp_defconfig and corenet32_smp_defconfig. That then allows both those configs to build kernels that boot in qemu using the ppce500 machine type and respectively -cpu e5500 or -cpu e500mc. The code that is added by PPC_QEMU_E500 just defines another machine with a probe function that recognises qemu, so there should be no change when booting on actual hardware supported by CORENET_GENERIC. The increase in vmlinux size is less than 1KB. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/corenet_base.config | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/configs/corenet_base.config b/arch/powerpc/configs/corenet_base.config index b568d465e59e..1c40de1e764b 100644 --- a/arch/powerpc/configs/corenet_base.config +++ b/arch/powerpc/configs/corenet_base.config @@ -1 +1,2 @@ CONFIG_CORENET_GENERIC=y +CONFIG_PPC_QEMU_E500=y -- 2.39.2
RE: [PATCH v4] Kconfig: introduce HAS_IOPORT option and select it as necessary
From: Geert Uytterhoeven > Sent: 11 April 2023 09:50 > > Hi David, > > On Wed, Apr 5, 2023 at 11:37 PM David Laight wrote: > > From: Linuxppc-dev Arnd Bergmann > > > Sent: 05 April 2023 21:32 > > > > > > On Wed, Apr 5, 2023, at 22:00, H. Peter Anvin wrote: > > > > On April 5, 2023 8:12:38 AM PDT, Niklas Schnelle > > > > wrote: > > > >>On Thu, 2023-03-23 at 17:33 +0100, Niklas Schnelle wrote: > > > >>> We introduce a new HAS_IOPORT Kconfig option to indicate support for > > > >>> I/O > > > >>> Port access. In a future patch HAS_IOPORT=n will disable compilation > > > >>> of > > > >>> the I/O accessor functions inb()/outb() and friends on architectures > > > >>> which can not meaningfully support legacy I/O spaces such as s390. > > > >>> >> > > > >>Gentle ping. As far as I can tell this hasn't been picked to any tree > > > >>sp far but also hasn't seen complains so I'm wondering if I should send > > > >>a new version of the combined series of this patch plus the added > > > >>HAS_IOPORT dependencies per subsystem or wait until this is picked up. > > > > > > > > You need this on a system supporting not just ISA but also PCI. > > > > > > > > Typically on non-x86 architectures this is simply mapped into a memory > > > > window. > > > > > > I'm pretty confident that the list is correct here, as the HAS_IOPORT > > > symbol is enabled exactly for the architectures that have a way to > > > map the I/O space. PCIe generally works fine without I/O space, the > > > only exception are drivers for devices that were around as early PCI. > > > > Isn't there a difference between cpu that have inb()/outb() (probably > > only x86?) and architectures (well computer designs) that can generate > > PCI 'I/O' cycles by some means. > > It isn't even just PCI I/O cycles, I've used an ARM cpu (SA1100) > > that mapped a chuck of physical address space onto PCMCIA I/O cycles. > > > > If the hardware can map a PCI 'IO' bar into normal kernel address > > space then the bar and accesses can be treated exactly like a memory bar. > > This probably leaves x86 as the outlier where you need (IIRC) io_readl() > > and friends that can generate in/out instructions for those accesses. > > > > There are also all the x86 ISA devices which need in/out instructions. > > But (with the likely exception of the UART) they are pretty much > > platform specific. > > > > So, to my mind at least, HAS_IOPORT is just the wrong question. > > Not all PCI controllers support mapping the I/O bar in MMIO space, so > in general you cannot say that CONFIG_PCI=y means CONFIG_HAS_IOPORT=y. But a CONFIG_HAS_PCI_IO=y would imply CONFIG_HAS_IOPORT=y. It is the former that is more interesting for driver support. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH] KVM: PPC: Fix documentation for ppc mmu caps
On Tue, Apr 11, 2023 at 03:44:46PM +0930, Joel Stanley wrote:
> The documentation mentions KVM_CAP_PPC_RADIX_MMU, but the defines in the
> kvm headers spell it KVM_CAP_PPC_MMU_RADIX. Similarly with
> KVM_CAP_PPC_MMU_HASH_V3.
>
> Fixes: c92701322711 ("KVM: PPC: Book3S HV: Add userspace interfaces for
> POWER9 MMU")
> Signed-off-by: Joel Stanley
Acked-by: Paul Mackerras
Re: [PATCH 3/4] cpuidle: pseries: Mark ->enter() functions as __cpuidle
> On 06-Apr-2023, at 8:15 PM, Michael Ellerman wrote:
>
> Code in the idle path is not allowed to be instrumented because RCU is
> disabled, see commit 0e985e9d2286 ("cpuidle: Add comments about
> noinstr/__cpuidle usage").
>
> Mark the cpuidle ->enter() callbacks as __cpuidle and use the
> raw_local_irq_*() routines to ensure that is the case.
>
> Reported-by: Sachin Sant
> Suggested-by: Peter Zijlstra
> Signed-off-by: Michael Ellerman
> ---
Thanks for the patch. With this patch (and others from the series)
applied, I no longer observe the reported kernel warning while running
ftrace selftests.
For this and other patches in the series
Tested-by: Sachin Sant
- Sachin
Re: [PATCH v4] Kconfig: introduce HAS_IOPORT option and select it as necessary
Hi David,
On Wed, Apr 5, 2023 at 11:37 PM David Laight wrote:
> From: Linuxppc-dev Arnd Bergmann
> > Sent: 05 April 2023 21:32
> >
> > On Wed, Apr 5, 2023, at 22:00, H. Peter Anvin wrote:
> > > On April 5, 2023 8:12:38 AM PDT, Niklas Schnelle
> > > wrote:
> > >>On Thu, 2023-03-23 at 17:33 +0100, Niklas Schnelle wrote:
> > >>> We introduce a new HAS_IOPORT Kconfig option to indicate support for I/O
> > >>> Port access. In a future patch HAS_IOPORT=n will disable compilation of
> > >>> the I/O accessor functions inb()/outb() and friends on architectures
> > >>> which can not meaningfully support legacy I/O spaces such as s390.
> > >>> >>
> > >>Gentle ping. As far as I can tell this hasn't been picked to any tree
> > >>sp far but also hasn't seen complains so I'm wondering if I should send
> > >>a new version of the combined series of this patch plus the added
> > >>HAS_IOPORT dependencies per subsystem or wait until this is picked up.
> > >
> > > You need this on a system supporting not just ISA but also PCI.
> > >
> > > Typically on non-x86 architectures this is simply mapped into a memory
> > > window.
> >
> > I'm pretty confident that the list is correct here, as the HAS_IOPORT
> > symbol is enabled exactly for the architectures that have a way to
> > map the I/O space. PCIe generally works fine without I/O space, the
> > only exception are drivers for devices that were around as early PCI.
>
> Isn't there a difference between cpu that have inb()/outb() (probably
> only x86?) and architectures (well computer designs) that can generate
> PCI 'I/O' cycles by some means.
> It isn't even just PCI I/O cycles, I've used an ARM cpu (SA1100)
> that mapped a chuck of physical address space onto PCMCIA I/O cycles.
>
> If the hardware can map a PCI 'IO' bar into normal kernel address
> space then the bar and accesses can be treated exactly like a memory bar.
> This probably leaves x86 as the outlier where you need (IIRC) io_readl()
> and friends that can generate in/out instructions for those accesses.
>
> There are also all the x86 ISA devices which need in/out instructions.
> But (with the likely exception of the UART) they are pretty much
> platform specific.
>
> So, to my mind at least, HAS_IOPORT is just the wrong question.
Not all PCI controllers support mapping the I/O bar in MMIO space, so
in general you cannot say that CONFIG_PCI=y means CONFIG_HAS_IOPORT=y.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 08/19] arch/m68k: Implement with generic helpers
On Thu, Apr 6, 2023 at 4:30 PM Thomas Zimmermann wrote:
> Replace the architecture's fb_is_primary_device() with the generic
> one from . No functional changes.
>
> v2:
> * provide empty fb_pgprotect() on non-MMU systems
>
> Signed-off-by: Thomas Zimmermann
> Cc: Geert Uytterhoeven
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 07/19] arch/m68k: Merge variants of fb_pgprotect() into single function
On Thu, Apr 6, 2023 at 4:30 PM Thomas Zimmermann wrote:
> Merge all variants of fb_pgprotect() into a single function body.
> There are two different cases for MMU systems. For non-MMU systems,
> the function body will be empty. No functional changes, but this
> will help with the switch to .
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Geert Uytterhoeven
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 01/19] fbdev: Prepare generic architecture helpers
Hi Thomas,
On Thu, Apr 6, 2023 at 4:30 PM Thomas Zimmermann wrote:
> Generic implementations of fb_pgprotect() and fb_is_primary_device()
> have been in the source code for a long time. Prepare the header file
> to make use of them.
>
> Improve the code by using an inline function for fb_pgprotect()
> and by removing include statements. The default mode set by
> fb_pgprotect() is now writecombine, which is what most platforms
> want.
>
> Symbols are protected by preprocessor guards. Architectures that
> provide a symbol need to define a preprocessor token of the same
> name and value. Otherwise the header file will provide a generic
> implementation. This pattern has been taken from .
>
> v2:
> * use writecombine mappings by default (Arnd)
>
> Signed-off-by: Thomas Zimmermann
Thanks for your patch!
> --- a/include/asm-generic/fb.h
> +++ b/include/asm-generic/fb.h
> @@ -1,13 +1,32 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> +
> #ifndef __ASM_GENERIC_FB_H_
> #define __ASM_GENERIC_FB_H_
> -#include
>
> -#define fb_pgprotect(...) do {} while (0)
> +/*
> + * Only include this header file from your architecture's .
> + */
> +
> +#include
> +
> +struct fb_info;
> +struct file;
> +
> +#ifndef fb_pgprotect
> +#define fb_pgprotect fb_pgprotect
> +static inline void fb_pgprotect(struct file *file, struct vm_area_struct
> *vma,
> + unsigned long off)
Does this affect any noMMU platforms that relied on fb_pgprotect()
doing nothing before?
Perhaps the body below should be protected by "#ifdef CONFIG_MMU"?
> +{
> + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
Shouldn't this use the pgprot_val() wrapper?
> +}
> +#endif
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
