Re: [RFC PATCH 0/4] Remove some e500/MPC85xx evaluation platforms
Li Yang writes: > On Tue, Feb 21, 2023 at 1:52 PM Paul Gortmaker > wrote: >> >> [This RFC is proposed for v6.4 and hence is based off linux-next.] >> >> In a similar theme to the e300/MPC83xx evaluation platform removal[1], >> this targets removal of some 13 --> 21 year old e500/MPC85xx evaluation >> boards that were produced in limited numbers and primarily made available >> to hardware/software developers to shape their own boards and BSPs. > > These e500 platforms are similar to the e300 platforms that they are > still being shipped, the targeting market probably caused it to have a > longer life cycle. > ... > > The difference here from the e300 platforms is that MPC8540ADS, > MPC8560ADS, MPC8548CDS, MPC8568-MDS are the only reference platforms > supplied by us for these SoCs. We don't have a separation of > evaluation platforms vs product-like platforms like we did later. > That probably means even if they don't look like "hobbyist" friendly > they are more likely to be still in use. OK. But what is the chance anyone is booting upstream kernels on them? I assume no one at NXP is testing upstream on those boards? cheers
[powerpc:next-test] BUILD SUCCESS 89954837dc0de437d780a687da646b6e3983b071
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test branch HEAD: 89954837dc0de437d780a687da646b6e3983b071 powerpc: drop MPC832x_MDS platform support elapsed time: 734m configs tested: 86 configs skipped: 7 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 defconfig gcc arc randconfig-r043-20230409 gcc arc randconfig-r043-20230410 gcc arc randconfig-r043-20230412 gcc arm allmodconfig gcc arm allyesconfig gcc arm defconfig gcc arm64allyesconfig gcc arm64 defconfig gcc arm64randconfig-r001-20230410 clang arm64randconfig-r023-20230410 gcc arm64randconfig-r026-20230409 gcc cskydefconfig gcc csky randconfig-r021-20230409 gcc csky randconfig-r024-20230410 gcc hexagon randconfig-r005-20230410 clang hexagon randconfig-r015-20230409 clang i386 allyesconfig gcc i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-a012 gcc i386 randconfig-a014 gcc i386 randconfig-a016 gcc ia64 allmodconfig gcc ia64 buildonly-randconfig-r005-20230409 gcc ia64defconfig gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchbuildonly-randconfig-r006-20230413 gcc loongarch defconfig gcc m68k allmodconfig gcc m68kdefconfig gcc mips allmodconfig gcc mips allyesconfig gcc nios2 defconfig gcc openrisc buildonly-randconfig-r002-20230413 gcc openrisc buildonly-randconfig-r004-20230409 gcc parisc defconfig gcc parisc randconfig-r024-20230409 gcc parisc64defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc powerpc buildonly-randconfig-r002-20230410 gcc powerpc buildonly-randconfig-r006-20230409 gcc powerpc randconfig-r006-20230409 clang powerpc randconfig-r021-20230410 gcc powerpc randconfig-r025-20230409 gcc riscvallmodconfig gcc riscv allnoconfig gcc riscv defconfig gcc riscvrandconfig-r001-20230409 clang riscvrandconfig-r003-20230410 clang riscvrandconfig-r004-20230409 clang riscvrandconfig-r022-20230409 gcc riscvrandconfig-r026-20230410 gcc riscvrandconfig-r042-20230409 gcc riscvrandconfig-r042-20230410 gcc riscvrandconfig-r042-20230412 gcc riscv rv32_defconfig gcc s390 allmodconfig gcc s390 allyesconfig gcc s390 buildonly-randconfig-r002-20230409 gcc s390defconfig gcc s390 randconfig-r025-20230410 gcc s390 randconfig-r044-20230409 gcc s390 randconfig-r044-20230410 gcc s390 randconfig-r044-20230412 gcc sh allmodconfig gcc sh randconfig-r023-20230409 gcc sparc defconfig gcc um i386_defconfig gcc um x86_64_defconfig gcc x86_64allnoconfig gcc x86_64 allyesconfig gcc x86_64 defconfig gcc x86_64 kexec gcc x86_64randconfig-a001 clang x86_64randconfig-a003 clang x86_64randconfig-a005 clang x86_64 randconfig-r006-20230410 clang x86_64 randconfig-r022-20230410 gcc x86_64 rhel-8.3 gcc xtensa buildonly
Re: [PATCH 1/2] start_kernel: add no_stack_protector fn attr
ndesaulni...@google.com writes:
> Back during the discussion of
> commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")
> we discussed the need for a function attribute to control the omission
> of stack protectors on a per-function basis; at the time Clang had
> support for no_stack_protector but GCC did not. This was fixed in
> gcc-11. Now that the function attribute is available, let's start using
> it.
>
> Callers of boot_init_stack_canary need to use this function attribute
> unless they're compiled with -fno-stack-protector, otherwise the canary
> stored in the stack slot of the caller will differ upon the call to
> boot_init_stack_canary. This will lead to a call to __stack_chk_fail
> then panic.
>
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94722
> Link:
> https://lore.kernel.org/all/20200316130414.gc12...@hirez.programming.kicks-ass.net/
> Signed-off-by: Nick Desaulniers
> ---
> arch/powerpc/kernel/smp.c | 1 +
> include/linux/compiler_attributes.h | 12
> init/main.c | 3 ++-
> 3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 6b90f10a6c81..7d4c12b1abb7 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -1603,6 +1603,7 @@ static void add_cpu_to_masks(int cpu)
> }
>
> /* Activate a secondary processor. */
> +__no_stack_protector
> void start_secondary(void *unused)
> {
> unsigned int cpu = raw_smp_processor_id();
start_secondary() doesn't return, so it won't actually crash, but it
obviously makes sense for it to be marked with __no_stack_protector.
There's quite a few other places we could add __no_stack_protector
annotations in powerpc code, and then make the changes to CFLAGS to
disable stack protector conditional on GCC < 11.
So I guess this patch is fine, but there's more that could be done.
Acked-by: Michael Ellerman (powerpc)
cheers
Re: [PATCH v3 6/6] PCI/AER: Unmask RCEC internal errors to enable RCH downstream port error handling
Jonathan Cameron wrote:
> On Wed, 12 Apr 2023 16:29:01 -0500
> Bjorn Helgaas wrote:
>
> > On Tue, Apr 11, 2023 at 01:03:02PM -0500, Terry Bowman wrote:
> > > From: Robert Richter
> > >
> > > RCEC AER corrected and uncorrectable internal errors (CIE/UIE) are
> > > disabled by default.
> >
> > "Disabled by default" just means "the power-up state of CIE/UIC is
> > that they are masked", right? It doesn't mean that Linux normally
> > masks them.
> >
> > > [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, _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)
> > > + */
> >
> > Unmasking internal errors doesn't have anything specific to do with
> > CXL, so I don't think it should have "cxl" in the function name.
> > Maybe something like "pci_aer_unmask_internal_errors()".
>
> This reminds me. Not sure we resolved earlier discussion on changing
> the system wide policy to turn these on
> https://lore.kernel.org/linux-cxl/20221229172731.GA611562@bhelgaas/
> which needs pretty much the same thing.
>
> Ira, I think you were picking this one up?
> https://lore.kernel.org/linux-cxl/63e5fb533f304_13244829412@iweiny-mobl.notmuch/
After this discussion I posted an RFC to enable those errors.
https://lore.kernel.org/all/20230209-cxl-pci-aer-v1-1-f9a817fa4...@intel.com/
Unfortunately the prevailing opinion was that this was unsafe. And no one
piped up with a reason to pursue the alternative of a pci core call to enable
them as needed.
So I abandoned the work.
I think the direction things where headed was to have a call like:
int pci_enable_pci_internal_errors(struct pci_dev *dev)
{
int pos_cap_err;
u32 reg;
if (!pcie_aer_is_native(dev))
return -EIO;
pos_cap_err = dev->aer_cap;
/* Unmask correctable and uncorrectable (non-fatal) internal errors */
pci_read_config_dword(dev, pos_cap_err + PCI_ERR_COR_MASK, );
reg &= ~PCI_ERR_COR_INTERNAL;
pci_write_config_dword(dev, pos_cap_err + PCI_ERR_COR_MASK, reg);
pci_read_config_dword(dev, pos_cap_err + PCI_ERR_UNCOR_SEVER, );
reg &= ~PCI_ERR_UNC_INTN;
pci_write_config_dword(dev, pos_cap_err + PCI_ERR_UNCOR_SEVER, reg);
pci_read_config_dword(dev, pos_cap_err + PCI_ERR_UNCOR_MASK, );
reg &= ~PCI_ERR_UNC_INTN;
pci_write_config_dword(dev, pos_cap_err + PCI_ERR_UNCOR_MASK, reg);
return 0;
}
... and call this from the cxl code where it is needed.
Is this an acceptable direction? Terry is welcome to steal the above from my
patch and throw it into the PCI core.
Looking at the current state of things I think cxl_pci_ras_unmask() may
actually be broken now without calling something like the above. For that I
dropped the ball.
[PATCH v2 2/2] Move Power10 feature, PPC_MODULE_FEATURE_P10.
Move Power10 feature, PPC_MODULE_FEATURE_P10, definition to be in arch/powerpc/include/asm/cpufeature.h. Signed-off-by: Danny Tsen --- arch/powerpc/crypto/aes-gcm-p10-glue.c | 1 - arch/powerpc/include/asm/cpufeature.h | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/crypto/aes-gcm-p10-glue.c b/arch/powerpc/crypto/aes-gcm-p10-glue.c index 1533c8cdd26f..bd3475f5348d 100644 --- a/arch/powerpc/crypto/aes-gcm-p10-glue.c +++ b/arch/powerpc/crypto/aes-gcm-p10-glue.c @@ -22,7 +22,6 @@ #include #include -#define PPC_MODULE_FEATURE_P10 (32 + ilog2(PPC_FEATURE2_ARCH_3_1)) #definePPC_ALIGN 16 #define GCM_IV_SIZE12 diff --git a/arch/powerpc/include/asm/cpufeature.h b/arch/powerpc/include/asm/cpufeature.h index f6f790a90367..2dcc66225e7f 100644 --- a/arch/powerpc/include/asm/cpufeature.h +++ b/arch/powerpc/include/asm/cpufeature.h @@ -22,6 +22,7 @@ */ #define PPC_MODULE_FEATURE_VEC_CRYPTO (32 + ilog2(PPC_FEATURE2_VEC_CRYPTO)) +#define PPC_MODULE_FEATURE_P10 (32 + ilog2(PPC_FEATURE2_ARCH_3_1)) #define cpu_feature(x) (x) -- 2.31.1
[PATCH v2 0/2] Remove POWER10_CPU dependency and move PPC_MODULE_FEATURE_P10.
Remove Power10 dependency in Kconfig and detect Power10 feature at runtime. Move PPC_MODULE_FEATURE_P10 definition to be in arch/powerpc/include/asm/cpufeature.h. Signed-off-by: Danny Tsen Danny Tsen (2): Kconfig: Remove POWER10_CPU dependency. aes-gcm-p10-glue.c, cpufeature.h: Move Power10 feature, PPC_MODULE_FEATURE_P10. arch/powerpc/crypto/Kconfig| 2 +- arch/powerpc/crypto/aes-gcm-p10-glue.c | 1 - arch/powerpc/include/asm/cpufeature.h | 1 + 3 files changed, 2 insertions(+), 2 deletions(-) -- 2.31.1
[PATCH v2 1/2] Remove POWER10_CPU dependency.
Remove Power10 dependency in Kconfig and detect Power10 feature at runtime. Signed-off-by: Danny Tsen --- arch/powerpc/crypto/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/crypto/Kconfig b/arch/powerpc/crypto/Kconfig index 1f8f02b494e1..7113f9355165 100644 --- a/arch/powerpc/crypto/Kconfig +++ b/arch/powerpc/crypto/Kconfig @@ -96,7 +96,7 @@ config CRYPTO_AES_PPC_SPE config CRYPTO_AES_GCM_P10 tristate "Stitched AES/GCM acceleration support on P10 or later CPU (PPC)" - depends on PPC64 && POWER10_CPU && CPU_LITTLE_ENDIAN + depends on PPC64 && CPU_LITTLE_ENDIAN select CRYPTO_LIB_AES select CRYPTO_ALGAPI select CRYPTO_AEAD -- 2.31.1
Re: [PATCH] Remove POWER10_CPU dependency and move PPC_MODULE_FEATURE_P10.
On 4/13/23 8:18 AM, Danny Tsen wrote: Hi Michael, If I do separate patch for moving PPC_MODULE_FEATURE_P10, this will break the build since it is currently defined in aes-gcm-p10-glue.c. And the p10 will be detected when loading the module in module_cpu_feature_match(PPC_MODULE_FEATURE_P10, p10_init); so it won't load if it's not P10. Thanks. -Danny On 4/13/23 8:12 AM, Michael Ellerman wrote: Danny Tsen writes: Remove Power10 dependency in Kconfig and detect Power10 feature at runtime. Move PPC_MODULE_FEATURE_P10 definition to be in arch/powerpc/include/asm/cpufeature.h. This should be two patches, one for the Kconfig change and one moving the feature flag. I think I misunderstood. I can do two patches one for Kconfig change and one moving the feature flag. I'll fix it. Thanks. -Danny Also don't you need a cpu feature check in p10_init()? Otherwise the driver can be loaded on non-P10 CPUs, either by being built-in, or manually. cheers Signed-off-by: Danny Tsen --- arch/powerpc/crypto/Kconfig | 2 +- arch/powerpc/crypto/aes-gcm-p10-glue.c | 1 - arch/powerpc/include/asm/cpufeature.h | 1 + 3 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/crypto/Kconfig b/arch/powerpc/crypto/Kconfig index 1f8f02b494e1..7113f9355165 100644 --- a/arch/powerpc/crypto/Kconfig +++ b/arch/powerpc/crypto/Kconfig @@ -96,7 +96,7 @@ config CRYPTO_AES_PPC_SPE config CRYPTO_AES_GCM_P10 tristate "Stitched AES/GCM acceleration support on P10 or later CPU (PPC)" - depends on PPC64 && POWER10_CPU && CPU_LITTLE_ENDIAN + depends on PPC64 && CPU_LITTLE_ENDIAN select CRYPTO_LIB_AES select CRYPTO_ALGAPI select CRYPTO_AEAD diff --git a/arch/powerpc/crypto/aes-gcm-p10-glue.c b/arch/powerpc/crypto/aes-gcm-p10-glue.c index 1533c8cdd26f..bd3475f5348d 100644 --- a/arch/powerpc/crypto/aes-gcm-p10-glue.c +++ b/arch/powerpc/crypto/aes-gcm-p10-glue.c @@ -22,7 +22,6 @@ #include #include -#define PPC_MODULE_FEATURE_P10 (32 + ilog2(PPC_FEATURE2_ARCH_3_1)) #define PPC_ALIGN 16 #define GCM_IV_SIZE 12 diff --git a/arch/powerpc/include/asm/cpufeature.h b/arch/powerpc/include/asm/cpufeature.h index f6f790a90367..2dcc66225e7f 100644 --- a/arch/powerpc/include/asm/cpufeature.h +++ b/arch/powerpc/include/asm/cpufeature.h @@ -22,6 +22,7 @@ */ #define PPC_MODULE_FEATURE_VEC_CRYPTO (32 + ilog2(PPC_FEATURE2_VEC_CRYPTO)) +#define PPC_MODULE_FEATURE_P10 (32 + ilog2(PPC_FEATURE2_ARCH_3_1)) #define cpu_feature(x) (x) -- 2.31.1
Re: [PATCH] Remove POWER10_CPU dependency and move PPC_MODULE_FEATURE_P10.
Hi Michael, If I do separate patch for moving PPC_MODULE_FEATURE_P10, this will break the build since it is currently defined in aes-gcm-p10-glue.c. And the p10 will be detected when loading the module in module_cpu_feature_match(PPC_MODULE_FEATURE_P10, p10_init); so it won't load if it's not P10. Thanks. -Danny On 4/13/23 8:12 AM, Michael Ellerman wrote: Danny Tsen writes: Remove Power10 dependency in Kconfig and detect Power10 feature at runtime. Move PPC_MODULE_FEATURE_P10 definition to be in arch/powerpc/include/asm/cpufeature.h. This should be two patches, one for the Kconfig change and one moving the feature flag. Also don't you need a cpu feature check in p10_init()? Otherwise the driver can be loaded on non-P10 CPUs, either by being built-in, or manually. cheers Signed-off-by: Danny Tsen --- arch/powerpc/crypto/Kconfig| 2 +- arch/powerpc/crypto/aes-gcm-p10-glue.c | 1 - arch/powerpc/include/asm/cpufeature.h | 1 + 3 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/crypto/Kconfig b/arch/powerpc/crypto/Kconfig index 1f8f02b494e1..7113f9355165 100644 --- a/arch/powerpc/crypto/Kconfig +++ b/arch/powerpc/crypto/Kconfig @@ -96,7 +96,7 @@ config CRYPTO_AES_PPC_SPE config CRYPTO_AES_GCM_P10 tristate "Stitched AES/GCM acceleration support on P10 or later CPU (PPC)" - depends on PPC64 && POWER10_CPU && CPU_LITTLE_ENDIAN + depends on PPC64 && CPU_LITTLE_ENDIAN select CRYPTO_LIB_AES select CRYPTO_ALGAPI select CRYPTO_AEAD diff --git a/arch/powerpc/crypto/aes-gcm-p10-glue.c b/arch/powerpc/crypto/aes-gcm-p10-glue.c index 1533c8cdd26f..bd3475f5348d 100644 --- a/arch/powerpc/crypto/aes-gcm-p10-glue.c +++ b/arch/powerpc/crypto/aes-gcm-p10-glue.c @@ -22,7 +22,6 @@ #include #include -#define PPC_MODULE_FEATURE_P10 (32 + ilog2(PPC_FEATURE2_ARCH_3_1)) #define PPC_ALIGN 16 #define GCM_IV_SIZE 12 diff --git a/arch/powerpc/include/asm/cpufeature.h b/arch/powerpc/include/asm/cpufeature.h index f6f790a90367..2dcc66225e7f 100644 --- a/arch/powerpc/include/asm/cpufeature.h +++ b/arch/powerpc/include/asm/cpufeature.h @@ -22,6 +22,7 @@ */ #define PPC_MODULE_FEATURE_VEC_CRYPTO (32 + ilog2(PPC_FEATURE2_VEC_CRYPTO)) +#define PPC_MODULE_FEATURE_P10 (32 + ilog2(PPC_FEATURE2_ARCH_3_1)) #define cpu_feature(x) (x) -- 2.31.1
RE: [PATCH 21/21] dma-mapping: replace custom code with generic implementation
Hi all, FYI, this patch breaks on RZ/G2L SMARC EVK board and Arnd will send V2 for fixing this issue. [10:53] [3.384408] Unable to handle kernel paging request at virtual address 4afb0080 [10:53] [3.392755] Mem abort info: [10:53] [3.395883] ESR = 0x96000144 [10:53] [3.399957] EC = 0x25: DABT (current EL), IL = 32 bits [10:53] [3.405674] SET = 0, FnV = 0 [10:53] [3.408978] EA = 0, S1PTW = 0 [10:53] [3.412442] FSC = 0x04: level 0 translation fault [10:53] [3.417825] Data abort info: [10:53] [3.420959] ISV = 0, ISS = 0x0144 [10:53] [3.425115] CM = 1, WnR = 1 [10:53] [3.428521] [4afb0080] user address but active_mm is swapper [10:53] [3.435135] Internal error: Oops: 96000144 [#1] PREEMPT SMP [10:53] [3.441501] Modules linked in: [10:53] [3.444644] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc6-next-20230412-g2936e9299572 #712 [10:53] [3.453537] Hardware name: Renesas SMARC EVK based on r9a07g054l2 (DT) [10:53] [3.460130] pstate: 6045 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [10:53] [3.467184] pc : dcache_clean_poc+0x20/0x38 [10:53] [3.471488] lr : arch_sync_dma_for_device+0x1c/0x2c [10:53] [3.476463] sp : 8a70b970 [10:53] [3.479834] x29: 8a70b970 x28: x27: 0aef7c10 [10:53] [3.487118] x26: 0afb0080 x25: 0b71 x24: 0b710a40 [10:53] [3.494397] x23: 2000 x22: x21: 0002 [10:53] [3.501670] x20: 0aef7c10 x19: 4afb0080 x18: [10:53] [3.508943] x17: 0100 x16: fc0001efc008 x15: [10:53] [3.516216] x14: 0100 x13: 0068 x12: 7fc0aa50 [10:54] [3.523488] x11: 7fc0a9c0 x10: x9 : 0aef7f08 [10:54] [3.530761] x8 : x7 : fc2bec00 x6 : [10:54] [3.538028] x5 : x4 : 0002 x3 : 003f [10:54] [3.545297] x2 : 0040 x1 : 4afb2080 x0 : 4afb0080 [10:54] [3.552569] Call trace: [10:54] [3.555074] dcache_clean_poc+0x20/0x38 [10:54] [3.559014] dma_map_page_attrs+0x1b4/0x248 [10:54] [3.563289] ravb_rx_ring_format_gbeth+0xd8/0x198 [10:54] [3.568095] ravb_ring_format+0x5c/0x108 [10:54] [3.572108] ravb_dmac_init_gbeth+0x30/0xe4 [10:54] [3.576382] ravb_dmac_init+0x80/0x104 [10:54] [3.580222] ravb_open+0x84/0x78c [10:54] [3.583626] __dev_open+0xec/0x1d8 [10:54] [3.587138] __dev_change_flags+0x190/0x208 [10:54] [3.591406] dev_change_flags+0x24/0x6c [10:54] [3.595324] ip_auto_config+0x248/0x10ac [10:54] [3.599345] do_one_initcall+0x6c/0x1b0 [10:54] [3.603268] kernel_init_freeable+0x1c0/0x294 Cheers, Biju > -Original Message- > From: linux-arm-kernel On > Behalf Of Arnd Bergmann > Sent: Monday, March 27, 2023 1:13 PM > To: linux-ker...@vger.kernel.org > Cc: Arnd Bergmann ; Vineet Gupta ; Russell > King ; Neil Armstrong ; > Linus Walleij ; Catalin Marinas > ; Will Deacon ; Guo Ren > ; Brian Cain ; Geert Uytterhoeven > ; Michal Simek ; Thomas Bogendoerfer > ; Dinh Nguyen ; Stafford > Horne ; Helge Deller ; Michael Ellerman > ; Christophe Leroy ; Paul > Walmsley ; Palmer Dabbelt ; > Rich Felker ; John Paul Adrian Glaubitz > ; David S. Miller ; Max > Filippov ; Christoph Hellwig ; Robin Murphy > ; Prabhakar Mahadev Lad lad...@bp.renesas.com>; Conor Dooley ; linux- > snps-...@lists.infradead.org; linux-arm-ker...@lists.infradead.org; linux- > ox...@groups.io; linux-c...@vger.kernel.org; linux-hexa...@vger.kernel.org; > linux-m...@lists.linux-m68k.org; linux-m...@vger.kernel.org; linux- > openr...@vger.kernel.org; linux-par...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org; linux-ri...@lists.infradead.org; linux- > s...@vger.kernel.org; sparcli...@vger.kernel.org; linux-xtensa@linux- > xtensa.org > Subject: [PATCH 21/21] dma-mapping: replace custom code with generic > implementation > > From: Arnd Bergmann > > Now that all of these have consistent behavior, replace them with a single > shared implementation of arch_sync_dma_for_device() and > arch_sync_dma_for_cpu() and three parameters to pick how they should > operate: > > - If the CPU has speculative prefetching, then the cache >has to be invalidated after a transfer from the device. >On the rarer CPUs without prefetching, this can be skipped, >with all cache management happening before the transfer. >This flag can be runtime detected, but is usually fixed >per architecture. > > - Some architectures currently clean the caches before DMA >from a device, while others invalidate it. There has not >been a conclusion regarding whether we should change all >architectures to use clean instead, so this adds an >
[PATCH] Remove POWER10_CPU dependency and move PPC_MODULE_FEATURE_P10.
Remove Power10 dependency in Kconfig and detect Power10 feature at runtime. Move PPC_MODULE_FEATURE_P10 definition to be in arch/powerpc/include/asm/cpufeature.h. Signed-off-by: Danny Tsen --- arch/powerpc/crypto/Kconfig| 2 +- arch/powerpc/crypto/aes-gcm-p10-glue.c | 1 - arch/powerpc/include/asm/cpufeature.h | 1 + 3 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/crypto/Kconfig b/arch/powerpc/crypto/Kconfig index 1f8f02b494e1..7113f9355165 100644 --- a/arch/powerpc/crypto/Kconfig +++ b/arch/powerpc/crypto/Kconfig @@ -96,7 +96,7 @@ config CRYPTO_AES_PPC_SPE config CRYPTO_AES_GCM_P10 tristate "Stitched AES/GCM acceleration support on P10 or later CPU (PPC)" - depends on PPC64 && POWER10_CPU && CPU_LITTLE_ENDIAN + depends on PPC64 && CPU_LITTLE_ENDIAN select CRYPTO_LIB_AES select CRYPTO_ALGAPI select CRYPTO_AEAD diff --git a/arch/powerpc/crypto/aes-gcm-p10-glue.c b/arch/powerpc/crypto/aes-gcm-p10-glue.c index 1533c8cdd26f..bd3475f5348d 100644 --- a/arch/powerpc/crypto/aes-gcm-p10-glue.c +++ b/arch/powerpc/crypto/aes-gcm-p10-glue.c @@ -22,7 +22,6 @@ #include #include -#define PPC_MODULE_FEATURE_P10 (32 + ilog2(PPC_FEATURE2_ARCH_3_1)) #definePPC_ALIGN 16 #define GCM_IV_SIZE12 diff --git a/arch/powerpc/include/asm/cpufeature.h b/arch/powerpc/include/asm/cpufeature.h index f6f790a90367..2dcc66225e7f 100644 --- a/arch/powerpc/include/asm/cpufeature.h +++ b/arch/powerpc/include/asm/cpufeature.h @@ -22,6 +22,7 @@ */ #define PPC_MODULE_FEATURE_VEC_CRYPTO (32 + ilog2(PPC_FEATURE2_VEC_CRYPTO)) +#define PPC_MODULE_FEATURE_P10 (32 + ilog2(PPC_FEATURE2_ARCH_3_1)) #define cpu_feature(x) (x) -- 2.31.1
Re: linux-next: manual merge of the drm tree with the powerpc tree
Hi Mark,
On Wed, Apr 12, 2023 at 11:22:13AM +1000, Stephen Rothwell wrote:
> 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.
This resolution is not quite right on next-20230412 and next-20230413,
as the drm tree's rename was not taken into account on the conflicting
line. In other words, I need this diff for everything to work properly.
diff --git a/drivers/gpu/drm/amd/display/Kconfig
b/drivers/gpu/drm/amd/display/Kconfig
index b990ef80d686..2d8e55e29637 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -8,7 +8,7 @@ config DRM_AMD_DC
depends on BROKEN || !CC_IS_CLANG || X86_64 || SPARC64 || ARM64
select SND_HDA_COMPONENT if SND_HDA_CORE
# !CC_IS_CLANG: https://github.com/ClangBuiltLinux/linux/issues/1752
- select DRM_AMD_DC_DCN if (X86 || (PPC64 && ALTIVEC) || (ARM64 &&
KERNEL_MODE_NEON && !CC_IS_CLANG))
+ select DRM_AMD_DC_FP if (X86 || (PPC64 && ALTIVEC) || (ARM64 &&
KERNEL_MODE_NEON && !CC_IS_CLANG))
help
Choose this option if you want to use the new display engine
support for AMDGPU. This adds required support for Vega and
Please consider resolving this in a future -next update, I was rather
surprised that my AMD test machine's graphical output was not working
until I noticed the configuration difference :)
Cheers,
Nathan
Re: [PATCH v3 6/6] PCI/AER: Unmask RCEC internal errors to enable RCH downstream port error handling
On Wed, 12 Apr 2023 16:29:01 -0500
Bjorn Helgaas wrote:
> On Tue, Apr 11, 2023 at 01:03:02PM -0500, Terry Bowman wrote:
> > From: Robert Richter
> >
> > RCEC AER corrected and uncorrectable internal errors (CIE/UIE) are
> > disabled by default.
>
> "Disabled by default" just means "the power-up state of CIE/UIC is
> that they are masked", right? It doesn't mean that Linux normally
> masks them.
>
> > [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, _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)
> > +*/
>
> Unmasking internal errors doesn't have anything specific to do with
> CXL, so I don't think it should have "cxl" in the function name.
> Maybe something like "pci_aer_unmask_internal_errors()".
This reminds me. Not sure we resolved earlier discussion on changing
the system wide policy to turn these on
https://lore.kernel.org/linux-cxl/20221229172731.GA611562@bhelgaas/
which needs pretty much the same thing.
Ira, I think you were picking this one up?
https://lore.kernel.org/linux-cxl/63e5fb533f304_13244829412@iweiny-mobl.notmuch/
Thanks,
Jonathan
>
> This also has nothing special to do with RCECs, so I think we should
> refer to the device as "dev" as is typical in this file.
>
> I think this needs to check pcie_aer_is_native() as is done by
> pci_aer_clear_nonfatal_status() and other functions that write the AER
> Capability.
>
> With the exception of this function, this patch looks like all CXL
> code that maybe could be with other CXL code. Would require making
> pcie_walk_rcec() available outside drivers/pci, I guess.
>
> > + aer = rcec->aer_cap;
> > + rc = pci_read_config_dword(rcec, aer + PCI_ERR_UNCOR_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, );
> > + 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(>dev, "cxl: Failed to unmask internal errors");
> > + else
> > + dev_dbg(>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;
> > }
> >
> > +
Re: [PATCH v3 6/6] PCI/AER: Unmask RCEC internal errors to enable RCH downstream port error handling
On Thu, 13 Apr 2023 15:38:07 +0200
Robert Richter wrote:
> On 12.04.23 16:29:01, Bjorn Helgaas wrote:
> > On Tue, Apr 11, 2023 at 01:03:02PM -0500, Terry Bowman wrote:
> > > From: Robert Richter
> > >
> > > RCEC AER corrected and uncorrectable internal errors (CIE/UIE) are
> > > disabled by default.
> >
> > "Disabled by default" just means "the power-up state of CIE/UIC is
> > that they are masked", right? It doesn't mean that Linux normally
> > masks them.
>
> Yes, will change the wording here.
>
> > > [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, _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)
> > > + */
> >
> > Unmasking internal errors doesn't have anything specific to do with
> > CXL, so I don't think it should have "cxl" in the function name.
> > Maybe something like "pci_aer_unmask_internal_errors()".
>
> Since it is static I renamed it to aer_unmask_internal_errors() and
> also moved it to the beginning of the #ifdef block for easier later
> reuse.
>
> >
> > This also has nothing special to do with RCECs, so I think we should
> > refer to the device as "dev" as is typical in this file.
>
> Changed.
>
> >
> > I think this needs to check pcie_aer_is_native() as is done by
> > pci_aer_clear_nonfatal_status() and other functions that write the AER
> > Capability.
>
> Also added the check to aer_unmask_internal_errors(). There was a
> check for native_* in handles_cxl_errors() already, but only for the
> pci devs of the RCEC. I added a check of the RCEC there too.
>
> >
> > With the exception of this function, this patch looks like all CXL
> > code that maybe could be with other CXL code. Would require making
> > pcie_walk_rcec() available outside drivers/pci, I guess.
>
> Even this is CXL code, it implements AER support and fits better here
> around AER code. Export of pcie_walk_rcec() (and others?) is not the
> main issue here. CXL drivers can come as modules and would need to
> register a hook at the aer handler. This would add even more
> complexity here. In contrast, current solution just adds two functions
> for enablement and handling which are empty stubs if code is disabled.
>
> I could move that code to aer_cxl.c similar to aer_inject.c. Since the
> CXL part is small compared to the remaining aer code I left it in
> aer.c. Also, it is guarded by #ifdef which additionally encapsulates
> it.
>
To throw another option in there (what Bjorn suggested IIRC for the more
general case..)
Just enable internal errors always. No need to know if they are CXL
or something else.
There will/might be fallout and it will be fun.
Jonathan
> >
> > > + aer = rcec->aer_cap;
> > > + rc = pci_read_config_dword(rcec, aer + PCI_ERR_UNCOR_MASK, );
> > > + if (rc)
> > > +
[PATCH v14 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 v14 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
---
(no changes since v13)
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 = <_i2c>;
@@ -27,16 +39,26 @@ sfp_slot: sfp {
};
};
+ {
+ clocks = <_100mhz>, <_156mhz>;
+ clock-names = "ref0", "ref1";
+ fsl,unused-lanes-reserved;
+ status = "okay";
+};
+
{
managed = "in-band-status";
pcs-handle = <>;
+ phys = <_C>;
sfp = <_slot>;
};
{
phy-handle = <_aquantia_phy>;
phy-connection-type = "10gbase-r";
+ managed = "in-band-status";
pcs-handle = <>;
+ phys = <_D>;
};
{
@@ -44,6 +66,7 @@ {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <_0>;
+ phys = <_A>;
};
{
@@ -51,6 +74,7 @@ {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <_1>;
+ phys = <_A>;
};
{
@@ -58,6 +82,7 @@ {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <_2>;
+ phys = <_A>;
};
{
@@ -65,6 +90,7 @@ {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <_3>;
+ phys = <_A>;
};
{
@@ -72,6 +98,7 @@ {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <_0>;
+ phys = <_B>;
};
{
@@ -79,6 +106,7 @@ {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <_1>;
+ phys = <_B>;
};
{
@@ -86,6 +114,7 @@ {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <_2>;
+ phys = <_B>;
};
{
@@ -93,6 +122,7 @@ {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <_3>;
+ phys = <_B>;
};
{
--
2.35.1.1320.gc452695387.dirty
[PATCH v14 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
---
(no changes since v13)
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 = <_i2c>;
+ los-gpios = <_stat 5 GPIO_ACTIVE_HIGH>;
+ tx-fault-gpios = <_stat 4 GPIO_ACTIVE_HIGH>;
+ tx-disable-gpios = < 4 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+ {
+ managed = "in-band-status";
+ pcs-handle = <>;
+ sfp = <_slot>;
};
{
@@ -170,6 +186,12 @@ rtc@51 {
interrupts-extended = < 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 @@ {
status = "okay";
};
+_mdio1 {
+ status = "okay";
+};
+
_mdio2 {
status = "okay";
};
--
2.35.1.1320.gc452695387.dirty
[PATCH v14 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." Note that while I have used FIELD_GET/FIELD_PREP where possible, these macros require const values for the field. This is incompatible with dynamicly-generated fields, such as when the field is determined by a variable. In these cases, I have used traditional shift/mask techniques. Signed-off-by: Sean Anderson --- Changes in v14: - Add note about (lack of) use of FIELD_GET/PREP 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
[PATCH v14 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
---
(no changes since v13)
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 @@ {
mdio2_aquantia_phy: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c45";
- interrupts-extended = < 2 IRQ_TYPE_LEVEL_LOW>;
reg = <0x0>;
};
};
--
2.35.1.1320.gc452695387.dirty
[PATCH v14 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 v14 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 |
[PATCH v14 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 v14 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>;
+ };
+};
+
+ {
+ clocks = <_100mhz>, <_156mhz>;
+ clock-names = "ref0", "ref1";
+ status = "okay";
};
{
@@ -140,21 +158,29 @@ ethernet@e6000 {
ethernet@e8000 {
phy-handle = <_phy1>;
phy-connection-type = "sgmii";
+ phys = <_B>;
+ phy-names = "serdes";
};
ethernet@ea000 {
phy-handle = <_phy2>;
phy-connection-type = "sgmii";
+ phys = <_A>;
+ phy-names = "serdes";
};
ethernet@f { /* 10GEC1 */
phy-handle = <_phy>;
phy-connection-type = "xgmii";
+ phys = <_D>;
+ phy-names = "serdes";
};
ethernet@f2000 { /* 10GEC2 */
phy-connection-type = "10gbase-r";
managed = "in-band-status";
+ phys = <_C>;
+ phy-names = "serdes";
};
mdio@fc000 {
--
2.35.1.1320.gc452695387.dirty
[PATCH v14 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 v14 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 v14 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 v14:
- Fix incorrect $id
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} | 18 +--
.../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, 131 insertions(+), 104 deletions(-)
rename Documentation/devicetree/bindings/gpio/{brcm,bcm6345-gpio.yaml =>
brcm,bcm63xx-gpio.yaml} (75%)
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 75%
rename from Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
rename to Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml
index 4d69f79df859..62fcc2bd5d80 100644
--- a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
-$id: http://devicetree.org/schemas/gpio/brcm,bcm6345-gpio.yaml#
+$id: http://devicetree.org/schemas/gpio/brcm,bcm63xx-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.
+
[PATCH v14 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
[PATCH v14 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 v14: - Fix incorrect $id - Add note about (lack of) use of FIELD_GET/PREP 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
[PATCH v14 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 v14 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
Re: [PATCH v13 03/15] dt-bindings: Convert gpio-mmio to yaml
On 4/12/23 04:04, Krzysztof Kozlowski wrote: > On 11/04/2023 20:43, 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) > > You got some of the same errors as last time. These are different errors. > Test your patches before sending. I typically run dt_bindings_check with DT_SCHEMA_FILES=... because running the whole thing takes longer than compiling a kernel from scratch. It seems I neglected to run it on the affected schemas. --Sean
Re: [PATCH 1/2] pseries/smp: export the smt level in the SYS FS.
On 13/04/2023 15:37:59, Michael Ellerman wrote:
> Hi Laurent,
>
> Laurent Dufour writes:
>> There is no SMT level recorded in the kernel neither in user space.
>> Indeed there is no real constraint about that and mixed SMT levels are
>> allowed and system is working fine this way.
>>
>> However when new CPU are added, the kernel is onlining all the threads
>> which is leading to mixed SMT levels and confuse end user a bit.
>>
>> To prevent this exports a SMT level from the kernel so user space
>> application like the energy daemon, could read it to adjust their settings.
>> There is no action unless recording the value when a SMT value is written
>> into the new sysfs entry. User space applications like ppc64_cpu should
>> update the sysfs when changing the SMT level to keep the system consistent.
>>
>> Suggested-by: Srikar Dronamraju
>> Signed-off-by: Laurent Dufour
>> ---
>> arch/powerpc/platforms/pseries/pseries.h | 3 ++
>> arch/powerpc/platforms/pseries/smp.c | 39
>> 2 files changed, 42 insertions(+)
>
> There is a generic sysfs interface for smt in /sys/devices/system/cpu/smt
>
> I think we should be enabling that on powerpc and then adapting it to
> our needs, rather than adding a pseries specific file.
Thanks Michael, I was not aware of this sysfs interface.
> Currently the generic code is only aware of SMT on/off, so it would need
> to be taught about SMT4 and 8 at least.
Do you think we should limit our support to SMT4 and SMT8 only?
> There are already hooks in the generic code to check the SMT level when
> bringing CPUs up, see cpu_smt_allowed(), they may work for the pseries
> hotplug case too, though maybe we need some additional logic.
>
> Wiring up the basic support is pretty straight forward, something like
> the diff below.
I'll look into how to wire this up.
Thanks a lot!
> cheers
>
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 0f123f1f62a1..a48576f1c579 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -260,6 +260,7 @@ config PPC
> select HAVE_SYSCALL_TRACEPOINTS
> select HAVE_VIRT_CPU_ACCOUNTING
> select HAVE_VIRT_CPU_ACCOUNTING_GEN
> + select HOTPLUG_SMT if HOTPLUG_CPU
> select HUGETLB_PAGE_SIZE_VARIABLE if PPC_BOOK3S_64 && HUGETLB_PAGE
> select IOMMU_HELPER if PPC64
> select IRQ_DOMAIN
> diff --git a/arch/powerpc/include/asm/topology.h
> b/arch/powerpc/include/asm/topology.h
> index 8a4d4f4d9749..bd23ba716d23 100644
> --- a/arch/powerpc/include/asm/topology.h
> +++ b/arch/powerpc/include/asm/topology.h
> @@ -143,5 +143,8 @@ static inline int cpu_to_coregroup_id(int cpu)
> #endif
> #endif
>
> +bool topology_is_primary_thread(unsigned int cpu);
> +bool topology_smt_supported(void);
> +
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_TOPOLOGY_H */
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 265801a3e94c..8619609809d5 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -1769,4 +1769,20 @@ void __noreturn arch_cpu_idle_dead(void)
> start_secondary_resume();
> }
>
> +/**
> + * topology_is_primary_thread - Check whether CPU is the primary SMT thread
> + * @cpu: CPU to check
> + */
> +bool topology_is_primary_thread(unsigned int cpu)
> +{
> + return cpu == cpu_first_thread_sibling(cpu);
> +}
> +
> +/**
> + * topology_smt_supported - Check whether SMT is supported by the CPUs
> + */
> +bool topology_smt_supported(void)
> +{
> + return threads_per_core > 1;
> +}
> #endif
Re: [PATCH v3 6/6] PCI/AER: Unmask RCEC internal errors to enable RCH downstream port error handling
On 12.04.23 16:29:01, Bjorn Helgaas wrote:
> On Tue, Apr 11, 2023 at 01:03:02PM -0500, Terry Bowman wrote:
> > From: Robert Richter
> >
> > RCEC AER corrected and uncorrectable internal errors (CIE/UIE) are
> > disabled by default.
>
> "Disabled by default" just means "the power-up state of CIE/UIC is
> that they are masked", right? It doesn't mean that Linux normally
> masks them.
Yes, will change the wording here.
> > [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, _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)
> > +*/
>
> Unmasking internal errors doesn't have anything specific to do with
> CXL, so I don't think it should have "cxl" in the function name.
> Maybe something like "pci_aer_unmask_internal_errors()".
Since it is static I renamed it to aer_unmask_internal_errors() and
also moved it to the beginning of the #ifdef block for easier later
reuse.
>
> This also has nothing special to do with RCECs, so I think we should
> refer to the device as "dev" as is typical in this file.
Changed.
>
> I think this needs to check pcie_aer_is_native() as is done by
> pci_aer_clear_nonfatal_status() and other functions that write the AER
> Capability.
Also added the check to aer_unmask_internal_errors(). There was a
check for native_* in handles_cxl_errors() already, but only for the
pci devs of the RCEC. I added a check of the RCEC there too.
>
> With the exception of this function, this patch looks like all CXL
> code that maybe could be with other CXL code. Would require making
> pcie_walk_rcec() available outside drivers/pci, I guess.
Even this is CXL code, it implements AER support and fits better here
around AER code. Export of pcie_walk_rcec() (and others?) is not the
main issue here. CXL drivers can come as modules and would need to
register a hook at the aer handler. This would add even more
complexity here. In contrast, current solution just adds two functions
for enablement and handling which are empty stubs if code is disabled.
I could move that code to aer_cxl.c similar to aer_inject.c. Since the
CXL part is small compared to the remaining aer code I left it in
aer.c. Also, it is guarded by #ifdef which additionally encapsulates
it.
>
> > + aer = rcec->aer_cap;
> > + rc = pci_read_config_dword(rcec, aer + PCI_ERR_UNCOR_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, );
> > + 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)
Also renaming this to
Re: [PATCH 1/2] pseries/smp: export the smt level in the SYS FS.
Hi Laurent,
Laurent Dufour writes:
> There is no SMT level recorded in the kernel neither in user space.
> Indeed there is no real constraint about that and mixed SMT levels are
> allowed and system is working fine this way.
>
> However when new CPU are added, the kernel is onlining all the threads
> which is leading to mixed SMT levels and confuse end user a bit.
>
> To prevent this exports a SMT level from the kernel so user space
> application like the energy daemon, could read it to adjust their settings.
> There is no action unless recording the value when a SMT value is written
> into the new sysfs entry. User space applications like ppc64_cpu should
> update the sysfs when changing the SMT level to keep the system consistent.
>
> Suggested-by: Srikar Dronamraju
> Signed-off-by: Laurent Dufour
> ---
> arch/powerpc/platforms/pseries/pseries.h | 3 ++
> arch/powerpc/platforms/pseries/smp.c | 39
> 2 files changed, 42 insertions(+)
There is a generic sysfs interface for smt in /sys/devices/system/cpu/smt
I think we should be enabling that on powerpc and then adapting it to
our needs, rather than adding a pseries specific file.
Currently the generic code is only aware of SMT on/off, so it would need
to be taught about SMT4 and 8 at least.
There are already hooks in the generic code to check the SMT level when
bringing CPUs up, see cpu_smt_allowed(), they may work for the pseries
hotplug case too, though maybe we need some additional logic.
Wiring up the basic support is pretty straight forward, something like
the diff below.
cheers
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 0f123f1f62a1..a48576f1c579 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -260,6 +260,7 @@ config PPC
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_VIRT_CPU_ACCOUNTING
select HAVE_VIRT_CPU_ACCOUNTING_GEN
+ select HOTPLUG_SMT if HOTPLUG_CPU
select HUGETLB_PAGE_SIZE_VARIABLE if PPC_BOOK3S_64 && HUGETLB_PAGE
select IOMMU_HELPER if PPC64
select IRQ_DOMAIN
diff --git a/arch/powerpc/include/asm/topology.h
b/arch/powerpc/include/asm/topology.h
index 8a4d4f4d9749..bd23ba716d23 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -143,5 +143,8 @@ static inline int cpu_to_coregroup_id(int cpu)
#endif
#endif
+bool topology_is_primary_thread(unsigned int cpu);
+bool topology_smt_supported(void);
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_TOPOLOGY_H */
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 265801a3e94c..8619609809d5 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -1769,4 +1769,20 @@ void __noreturn arch_cpu_idle_dead(void)
start_secondary_resume();
}
+/**
+ * topology_is_primary_thread - Check whether CPU is the primary SMT thread
+ * @cpu: CPU to check
+ */
+bool topology_is_primary_thread(unsigned int cpu)
+{
+ return cpu == cpu_first_thread_sibling(cpu);
+}
+
+/**
+ * topology_smt_supported - Check whether SMT is supported by the CPUs
+ */
+bool topology_smt_supported(void)
+{
+ return threads_per_core > 1;
+}
#endif
Re: [PATCH] Remove POWER10_CPU dependency and move PPC_MODULE_FEATURE_P10.
Danny Tsen writes: > Remove Power10 dependency in Kconfig and detect Power10 feature at runtime. > Move PPC_MODULE_FEATURE_P10 definition to be in > arch/powerpc/include/asm/cpufeature.h. This should be two patches, one for the Kconfig change and one moving the feature flag. Also don't you need a cpu feature check in p10_init()? Otherwise the driver can be loaded on non-P10 CPUs, either by being built-in, or manually. cheers > Signed-off-by: Danny Tsen > --- > arch/powerpc/crypto/Kconfig| 2 +- > arch/powerpc/crypto/aes-gcm-p10-glue.c | 1 - > arch/powerpc/include/asm/cpufeature.h | 1 + > 3 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/crypto/Kconfig b/arch/powerpc/crypto/Kconfig > index 1f8f02b494e1..7113f9355165 100644 > --- a/arch/powerpc/crypto/Kconfig > +++ b/arch/powerpc/crypto/Kconfig > @@ -96,7 +96,7 @@ config CRYPTO_AES_PPC_SPE > > config CRYPTO_AES_GCM_P10 > tristate "Stitched AES/GCM acceleration support on P10 or later CPU > (PPC)" > - depends on PPC64 && POWER10_CPU && CPU_LITTLE_ENDIAN > + depends on PPC64 && CPU_LITTLE_ENDIAN > select CRYPTO_LIB_AES > select CRYPTO_ALGAPI > select CRYPTO_AEAD > diff --git a/arch/powerpc/crypto/aes-gcm-p10-glue.c > b/arch/powerpc/crypto/aes-gcm-p10-glue.c > index 1533c8cdd26f..bd3475f5348d 100644 > --- a/arch/powerpc/crypto/aes-gcm-p10-glue.c > +++ b/arch/powerpc/crypto/aes-gcm-p10-glue.c > @@ -22,7 +22,6 @@ > #include > #include > > -#define PPC_MODULE_FEATURE_P10 (32 + ilog2(PPC_FEATURE2_ARCH_3_1)) > #define PPC_ALIGN 16 > #define GCM_IV_SIZE 12 > > diff --git a/arch/powerpc/include/asm/cpufeature.h > b/arch/powerpc/include/asm/cpufeature.h > index f6f790a90367..2dcc66225e7f 100644 > --- a/arch/powerpc/include/asm/cpufeature.h > +++ b/arch/powerpc/include/asm/cpufeature.h > @@ -22,6 +22,7 @@ > */ > > #define PPC_MODULE_FEATURE_VEC_CRYPTO(32 + > ilog2(PPC_FEATURE2_VEC_CRYPTO)) > +#define PPC_MODULE_FEATURE_P10 (32 + > ilog2(PPC_FEATURE2_ARCH_3_1)) > > #define cpu_feature(x) (x) > > -- > 2.31.1
Re: [PATCH 21/21] dma-mapping: replace custom code with generic implementation
On Thu, Apr 13, 2023, at 14:13, Biju Das wrote: > Hi all, > > FYI, this patch breaks on RZ/G2L SMARC EVK board and Arnd will send V2 > for fixing this issue. > > [10:53] [3.384408] Unable to handle kernel paging request at > virtual address 4afb0080 Right, sorry about this, I accidentally removed the 'phys_to_virt()' conversion on arm64. Arnd
Re: Probing nvme disks fails on Upstream kernels on powerpc Maxconfig
On 05/04/2023 15:45, Michael Ellerman wrote:
"Linux regression tracking (Thorsten Leemhuis)"
writes:
[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]
On 23.03.23 10:53, Srikar Dronamraju wrote:
I am unable to boot upstream kernels from v5.16 to the latest upstream
kernel on a maxconfig system. (Machine config details given below)
At boot, we see a series of messages like the below.
dracut-initqueue[13917]: Warning: dracut-initqueue: timeout, still waiting for
following initqueue hooks:
dracut-initqueue[13917]: Warning:
/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2f93dc0767-18aa-467f-afa7-5b4e9c13108a.sh:
"if ! grep -q After=remote-fs-pre.target
/run/systemd/generator/systemd-cryptsetup@*.service 2>/dev/null; then
dracut-initqueue[13917]: [ -e
"/dev/disk/by-uuid/93dc0767-18aa-467f-afa7-5b4e9c13108a" ]
dracut-initqueue[13917]: fi"
Alexey, did you look into this? This is apparently caused by a commit of
yours (see quoted part below) that Michael applied. Looks like it fell
through the cracks from here, but maybe I'm missing something.
Unfortunately Alexey is not working at IBM any more, so he won't have
access to any hardware to debug/test this.
Srikar are you debugging this? If not we'll have to find someone else to
look at it.
Has this been fixed and I missed cc:? Anyway, without the full log, I
still see it is a huge guest so chances are the guest could not map all
RAM so instead it uses the biggest possible DDW with 2M pages. If that's
the case, this might help it:
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 614af78b3695..996acf245ae5 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -906,7 +906,7 @@ void *iommu_alloc_coherent(struct device *dev,
struct iommu_table *tbl,
unsigned int nio_pages, io_order;
struct page *page;
- size = PAGE_ALIGN(size);
+ size = _ALIGN(size, IOMMU_PAGE_SIZE(tbl));
order = get_order(size);
/*
@@ -949,10 +949,9 @@ void iommu_free_coherent(struct iommu_table *tbl,
size_t size,
if (tbl) {
unsigned int nio_pages;
- size = PAGE_ALIGN(size);
+ size = _ALIGN(size, IOMMU_PAGE_SIZE(tbl));
nio_pages = size >> tbl->it_page_shift;
iommu_free(tbl, dma_handle, nio_pages);
- size = PAGE_ALIGN(size);
free_pages((unsigned long)vaddr, get_order(size));
}
And there may be other places where PAGE_SIZE is used instead of
IOMMU_PAGE_SIZE(tbl). Thanks,
--
Alexey
Re: [PATCH v3 5/6] PCI/AER: Forward RCH downstream port-detected errors to the CXL.mem dev handler
Bjorn, thanks for your detailed review. On 12.04.23 17:02:33, Bjorn Helgaas wrote: > On Tue, Apr 11, 2023 at 01:03:01PM -0500, Terry Bowman wrote: > > 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, > > Capitalize "device" and "Function" the same way (also appears in > comment below). Changed that. > > > 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 > > "AER external capabilities" -- is that referring to the "AER > *Extended* capability"? If so, we usually don't bother including the > "extended" part because it's usually not relevant. But if you intended > "external", I don't know what it means. Right, "extended" is meant here, but I will drop it to also fit with the 'CXL RAS capability'. > > > 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. > > Can you make this more concrete with an example topology so we can > work through how this all works? Correct me when I go off the rails > here: Let's assume just a simple CXL RCH topology: PCI hierarchy: - | ACPI0016 | Host bridge (CXL host) | - CEDT| | -| - RCRB base | | |- : | | | | |--- - || RCiEP |.| RCEC | Endpoint (CXL dev) || - BDF | | - BDF | || | - PCIe AER | - || | - CXL dvsec | || | (v2: reg loc) | || | - Comp regs | || | - CXL RAS | || --- :: CXL hierarchy: :: :-- | || CXL root port |<-- ||| |--->| - dport RCRB |<-- || - PCIe AER | | || - Comp regs | | || - CXL RAS | | |-- | |: | || -- | |--->| CXL endpoint |--- || (v1: RCRB) | >| - uport RCRB | | - Comp regs | | - CXL RAS | -- Dport detected errors are reported using PCIe AER and CXL RAS caps in the dports RCRB. Uport detected errors are reported using RCiEP's PCIe AER cap and either the uport's RCRB RAS cap or the RAS cap of the comp regs located using CXL DVSEC register locator. In all cases the RCEC is used with either the RCEC (dport errors) or the
Re: [PATCH v3 00/17] powerpc: alternate queued spinlock implementation
On 11/26/22 3:29 PM, Nicholas Piggin wrote: > This replaces the generic queued spinlock code (like s390 does) with > our own implementation. There is an extra shim patch 1a to get the > series to apply. > > Generic PV qspinlock code is causing latency / starvation regressions on > large systems that are resulting in hard lockups reported (mostly in > pathoogical cases). The generic qspinlock code has a number of issues > important for powerpc hardware and hypervisors that aren't easily solved > without changing code that would impact other architectures. Follow > s390's lead and implement our own for now. > > Issues for powerpc using generic qspinlocks: > - The previous lock value should not be loaded with simple loads, and > need not be passed around from previous loads or cmpxchg results, > because powerpc uses ll/sc-style atomics which can perform more > complex operations that do not require this. powerpc implementations > tend to prefer loads use larx for improved coherency performance. > - The queueing process should absolutely minimise the number of stores > to the lock word to reduce exclusive coherency probes, important for > large system scalability. The pending logic is counter productive > here. > - Non-atomic unlock for paravirt locks is important (atomic instructions > tend to still be more expensive than x86 CPUs). > - Yielding to the lock owner is important in the oversubscribed paravirt > case, which requires storing the owner CPU in the lock word. > - More control of lock stealing for the paravirt case is important to > keep latency down on large systems. > - The lock acquisition operation should always be made with a special > variant of atomic instructions with the lock hint bit set, including > (especially) in the queueing paths. This is more a matter of adding > more arch lock helpers so not an insurmountable problem for generic > code. > > Thanks, > Nick > > Since v2: > - Rebase the series on upstream and remove the 1a shim patch. > - Squash in the RFC patches that avoid a few more cmpxchg patterns in > favour of more optimal larx/stcx implementations and allows the > non-stealing queueing case to be removed, significantly reducing > the queuing code. > - Reword some changelogs. > > Since v1: > - Change most 'if (cond) return 1 ; return 0;' > - Bug fix: was testing count == MAX, but reentrant NMIs could bring that > > MAX and crash. > - Fix missing memory barrier lost in asm conversion patch. > - Seperate the release barrier in publish_tail from the acquire barrier > in get_tail_qnode. > - Moving a few minor things into their logically correct change. > - Make encode_tail_cpu take a cpu argument to match get_tail_cpu. > - Rename get_tail_cpu to decode_tail_cpu to match encode_tail_cpu. > - Rename lock_set_locked to set_locked. > - IS_ENABLED(x) ? 1 : 0 -> IS_ENABLED(x) > - Fix some comments inside inline asm. > - Change tunable names to lowercase. > - Consolidate asm for trylock_clear_tail_cpu and trylock_with_tail_cpu > - Restructure steal/wait loops to be more readable > - Count a failed cmpxchg as an iteration in steal/wait loops to avoid > theoretical livelock/latency concern. > > Nicholas Piggin (17): > powerpc/qspinlock: add mcs queueing for contended waiters > powerpc/qspinlock: use a half-word store to unlock to avoid larx/stcx. > powerpc/qspinlock: convert atomic operations to assembly > powerpc/qspinlock: allow new waiters to steal the lock before queueing > powerpc/qspinlock: theft prevention to control latency > powerpc/qspinlock: store owner CPU in lock word > powerpc/qspinlock: paravirt yield to lock owner > powerpc/qspinlock: implement option to yield to previous node > powerpc/qspinlock: allow stealing when head of queue yields > powerpc/qspinlock: allow propagation of yield CPU down the queue > powerpc/qspinlock: add ability to prod new queue head CPU > powerpc/qspinlock: allow lock stealing in trylock and lock fastpath > powerpc/qspinlock: use spin_begin/end API > powerpc/qspinlock: reduce remote node steal spins > powerpc/qspinlock: allow indefinite spinning on a preempted owner > powerpc/qspinlock: provide accounting and options for sleepy locks > powerpc/qspinlock: add compile-time tuning adjustments > > arch/powerpc/include/asm/qspinlock.h | 130 ++- > arch/powerpc/include/asm/qspinlock_types.h | 63 +- > arch/powerpc/lib/qspinlock.c | 985 - > 3 files changed, 1167 insertions(+), 11 deletions(-) > Hi. we are observing hardlockup problems with queued spinlock on powerVM Shared Processor LPAR's(SPLPAR) LPAR is configured with 320vcpu/160cpu. It is over-committed. Scenario: Bring up the system. create a CPU cgroup with 50% or 5% CPU bandwidth. Run strss-ng with 160 CPU stressor. Issue is hit consistently on 5% CPU bandwidth allocation. Issue happens sometime with 50%. Issue was not observed when stress-ng is run without any
Re: [PATCH 0/2] start_kernel: omit stack canary
On Wed, Apr 12, 2023 at 11:32:11AM -0700, ndesaulni...@google.com wrote: > Nick Desaulniers (2): > start_kernel: add no_stack_protector fn attr > start_kernel: omit prevent_tail_call_optimization for newer toolchains > Your second patch has a vile comment style :-) Other than that, Acked-by: Peter Zijlstra (Intel)
[PATCH] powerpc: Drop MPC5200 LocalPlus bus FIFO driver
While mpc5200b.dtsi contains a device that this driver can bind to, the
only purpose of a bound device is to be used by the four exported functions
mpc52xx_lpbfifo_submit(), mpc52xx_lpbfifo_abort(), mpc52xx_lpbfifo_poll()
and mpc52xx_lpbfifo_start_xfer(). However there are no callers to this
function and so the driver is effectively superfluous and can be deleted.
Also drop some defines and a struct from that are unused
now together with the declarations of the four mentioned functions.
Signed-off-by: Uwe Kleine-König
---
Hello Michael,
On Thu, Apr 13, 2023 at 10:11:25AM +1000, Michael Ellerman wrote:
> Uwe Kleine-König writes:
> > On Wed, Dec 28, 2022 at 03:51:29PM +0100, Uwe Kleine-König wrote:
> >> The four exported functions mpc52xx_lpbfifo_submit(),
> >> mpc52xx_lpbfifo_abort(), mpc52xx_lpbfifo_poll(), and
> >> mpc52xx_lpbfifo_start_xfer() are not used. So they can be dropped and the
> >> definitions needed to call them can be moved into the driver file.
> >>
> >> Signed-off-by: Uwe Kleine-König
> >
> > I never got feedback about this driver and it has not appeared in next
> > up to now. Did it fell through the cracks?
>
> Yeah. I was hoping someone would explain what's going on with the
> driver.
>
> Presumably there are some out-of-tree drivers that use the routines
> provided by this driver?
I googled for the function names but the only related hits were
references to this thread :-)
> I think rather than merging this patch, which keeps the code but makes
> it completely useless, do you mind sending a patch to remove the whole
> driver? Maybe that will get someone's attention.
fair enough, here it is.
Best regards
Uwe
arch/powerpc/include/asm/mpc52xx.h| 41 --
arch/powerpc/platforms/52xx/Kconfig | 5 -
arch/powerpc/platforms/52xx/Makefile | 2 -
arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c | 594 --
4 files changed, 642 deletions(-)
delete mode 100644 arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
diff --git a/arch/powerpc/include/asm/mpc52xx.h
b/arch/powerpc/include/asm/mpc52xx.h
index 5ea16a71c2f0..01ae6c351e50 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -285,47 +285,6 @@ extern int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv
*gpt, u64 period,
extern u64 mpc52xx_gpt_timer_period(struct mpc52xx_gpt_priv *gpt);
extern int mpc52xx_gpt_stop_timer(struct mpc52xx_gpt_priv *gpt);
-/* mpc52xx_lpbfifo.c */
-#define MPC52XX_LPBFIFO_FLAG_READ (0)
-#define MPC52XX_LPBFIFO_FLAG_WRITE (1<<0)
-#define MPC52XX_LPBFIFO_FLAG_NO_INCREMENT (1<<1)
-#define MPC52XX_LPBFIFO_FLAG_NO_DMA(1<<2)
-#define MPC52XX_LPBFIFO_FLAG_POLL_DMA (1<<3)
-
-struct mpc52xx_lpbfifo_request {
- struct list_head list;
-
- /* localplus bus address */
- unsigned int cs;
- size_t offset;
-
- /* Memory address */
- void *data;
- phys_addr_t data_phys;
-
- /* Details of transfer */
- size_t size;
- size_t pos; /* current position of transfer */
- int flags;
- int defer_xfer_start;
-
- /* What to do when finished */
- void (*callback)(struct mpc52xx_lpbfifo_request *);
-
- void *priv; /* Driver private data */
-
- /* statistics */
- int irq_count;
- int irq_ticks;
- u8 last_byte;
- int buffer_not_done_cnt;
-};
-
-extern int mpc52xx_lpbfifo_submit(struct mpc52xx_lpbfifo_request *req);
-extern void mpc52xx_lpbfifo_abort(struct mpc52xx_lpbfifo_request *req);
-extern void mpc52xx_lpbfifo_poll(void);
-extern int mpc52xx_lpbfifo_start_xfer(struct mpc52xx_lpbfifo_request *req);
-
/* mpc52xx_pic.c */
extern void mpc52xx_init_irq(void);
extern unsigned int mpc52xx_get_irq(void);
diff --git a/arch/powerpc/platforms/52xx/Kconfig
b/arch/powerpc/platforms/52xx/Kconfig
index b72ed2950ca8..384e4bef2c28 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -54,8 +54,3 @@ config PPC_MPC5200_BUGFIX
for MPC5200B based boards.
It is safe to say 'Y' here
-
-config PPC_MPC5200_LPBFIFO
- tristate "MPC5200 LocalPlus bus FIFO driver"
- depends on PPC_MPC52xx && PPC_BESTCOMM
- select PPC_BESTCOMM_GEN_BD
diff --git a/arch/powerpc/platforms/52xx/Makefile
b/arch/powerpc/platforms/52xx/Makefile
index f40d48eab779..1b1f72d83342 100644
--- a/arch/powerpc/platforms/52xx/Makefile
+++ b/arch/powerpc/platforms/52xx/Makefile
@@ -14,5 +14,3 @@ obj-$(CONFIG_PM) += mpc52xx_sleep.o mpc52xx_pm.o
ifdef CONFIG_PPC_LITE5200
obj-$(CONFIG_PM)+= lite5200_sleep.o lite5200_pm.o
endif
-
-obj-$(CONFIG_PPC_MPC5200_LPBFIFO) += mpc52xx_lpbfifo.o
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
deleted file mode 100644
index 6d1dd6e87478..
--- a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
+++
Re: [PATCH 0/6] bus: fsl-mc: Make remove function return void
Hello Leo, On Wed, Apr 12, 2023 at 09:30:05PM +, Leo Li wrote: > > On Fri, Mar 10, 2023 at 11:41:22PM +0100, Uwe Kleine-König wrote: > > > Hello, > > > > > > many bus remove functions return an integer which is a historic > > > misdesign that makes driver authors assume that there is some kind of > > > error handling in the upper layers. This is wrong however and > > > returning and error code only yields an error message. > > > > > > This series improves the fsl-mc bus by changing the remove callback to > > > return no value instead. As a preparation all drivers are changed to > > > return zero before so that they don't trigger the error message. > > > > Who is supposed to pick up this patch series (or point out a good reason for > > not taking it)? > > Previously Greg KH picked up MC bus patches. > > If no one is picking up them this time, I probably can take it through > the fsl soc tree. I guess Greg won't pick up this series as he didn't get a copy of it :-) Browsing through the history of drivers/bus/fsl-mc there is no consistent maintainer to see. So if you can take it, that's very appreciated. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
