[PATCH] usb: phy: check the return value of ioremap() in usb_otg_start()
From: William Dean
The function ioremap() in usb_otg_start() can fail, so
its return value should be checked.
Fixes: 0807c500a1a6d ("USB: add Freescale USB OTG Transceiver driver")
Reported-by: Hacash Robot
Signed-off-by: William Dean
---
drivers/usb/phy/phy-fsl-usb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index 972704262b02..21b3b2d57358 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -855,6 +855,8 @@ int usb_otg_start(struct platform_device *pdev)
* with host/device */
usb_dr_regs = ioremap(res->start, sizeof(struct usb_dr_mmap));
+ if (!usb_dr_regs)
+ return -ENOMEM;
p_otg->dr_mem_map = (struct usb_dr_mmap *)usb_dr_regs;
pdata->regs = (void *)usb_dr_regs;
--
2.25.1
Re: [PATCH v2] random: handle archrandom in plural words
Hi Jason,
On 17/07/2022 22:03, Jason A. Donenfeld wrote:
> The archrandom interface was originally designed for x86, which supplies
> RDRAND/RDSEED for receiving random words into registers, resulting in
> one function to generate an int and another to generate a long. However,
> other architectures don't follow this.
>
> On arm64, the SMCCC TRNG interface can return between 1 and 3 words. On
> s390, the CPACF TRNG interface can return between 1 and 32 words for the
> same cost as for one word. On UML, the os_getrandom() interface can return
> arbitrary amounts.
>
> So change the api signature to take a "words" parameter designating the
> maximum number of words requested, and then return the number of words
> generated.
Why not changing the API to take bytes instead of words? Sure, at the moment it
looks like all platforms with TRNG support are able to deliver at least one
word, but bytes would be more flexible.
> Since callers need to check this return value and loop anyway, each arch
> implementation does not bother implementing its own loop to try again to
> fill the requested number of words. Additionally, all existing callers
> pass in a constant words parameter. Taken together, these two things
> mean that the codegen doesn't really change much for one-word-at-a-time
> platforms, while performance is greatly improved on platforms such as
> s390.
>
> Cc: Will Deacon
> Cc: Michael Ellerman
> Cc: Alexander Gordeev
> Cc: Thomas Gleixner
> Cc: H. Peter Anvin
> Cc: Catalin Marinas
> Cc: Borislav Petkov
> Cc: Heiko Carstens
> Cc: Johannes Berg
> Cc: Harald Freudenberger
> Signed-off-by: Jason A. Donenfeld
> ---
> arch/arm64/include/asm/archrandom.h | 102 --
> arch/arm64/kernel/kaslr.c | 2 +-
> arch/powerpc/include/asm/archrandom.h | 30 ++--
> arch/powerpc/kvm/book3s_hv.c | 2 +-
> arch/s390/include/asm/archrandom.h| 29 ++--
> arch/um/include/asm/archrandom.h | 21 ++
> arch/x86/include/asm/archrandom.h | 41 +--
> arch/x86/kernel/espfix_64.c | 2 +-
> drivers/char/random.c | 45
> include/asm-generic/archrandom.h | 18 +
> include/linux/random.h| 12 +--
> 11 files changed, 116 insertions(+), 188 deletions(-)
>
> diff --git a/arch/arm64/include/asm/archrandom.h
> b/arch/arm64/include/asm/archrandom.h
> index c3b9fa56af67..7a24fdee3e2f 100644
> --- a/arch/arm64/include/asm/archrandom.h
> +++ b/arch/arm64/include/asm/archrandom.h
> @@ -58,7 +58,7 @@ static inline bool __arm64_rndrrs(unsigned long *v)
> return ok;
> }
>
> -static inline bool __must_check arch_get_random_long(unsigned long *v)
> +static inline size_t __must_check arch_get_random_words(unsigned long *v,
> size_t words)
> {
> /*
>* Only support the generic interface after we have detected
> @@ -66,27 +66,15 @@ static inline bool __must_check
> arch_get_random_long(unsigned long *v)
>* cpufeature code and with potential scheduling between CPUs
>* with and without the feature.
>*/
> - if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndr(v))
> - return true;
> - return false;
> + if (words && cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndr(v))
> + return 1;
> + return 0;
> }
>
> -static inline bool __must_check arch_get_random_int(unsigned int *v)
> +static inline size_t __must_check arch_get_random_seed_words(unsigned long
> *v, size_t words)
> {
> - if (cpus_have_const_cap(ARM64_HAS_RNG)) {
> - unsigned long val;
> -
> - if (__arm64_rndr(&val)) {
> - *v = val;
> - return true;
> - }
> - }
> - return false;
> -}
> -
> -static inline bool __must_check arch_get_random_seed_long(unsigned long *v)
> -{
> - struct arm_smccc_res res;
> + if (!words)
> + return 0;
>
> /*
>* We prefer the SMCCC call, since its semantics (return actual
> @@ -95,10 +83,23 @@ static inline bool __must_check
> arch_get_random_seed_long(unsigned long *v)
>* (the output of a pseudo RNG freshly seeded by a TRNG).
>*/
> if (smccc_trng_available) {
> - arm_smccc_1_1_invoke(ARM_SMCCC_TRNG_RND64, 64, &res);
> + struct arm_smccc_res res;
> +
> + words = min_t(size_t, 3, words);
> + arm_smccc_1_1_invoke(ARM_SMCCC_TRNG_RND64, words * 64, &res);
> if ((int)res.a0 >= 0) {
> - *v = res.a3;
> - return true;
> + switch (words) {
> + case 3:
> + *v++ = res.a1;
> + fallthrough;
> + case 2:
> + *v++ = res.a2;
> + fallthrough;
> + case 1:
> + *v++ = res.a3
Re: [PATCH] cyrpto:delete the rebundant word "block" in comments
shaom Deng wrote: > there is rebundant word "block" in comments, so remove it > > Signed-off-by: shaom Deng > --- > arch/powerpc/crypto/aes-spe-glue.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Regression: Linux v5.15+ does not boot on Freescale P2020
Hello! Trying to boot mainline Linux kernel v5.15+, including current version from master branch, on Freescale P2020 does not work. Kernel does not print anything to serial console, seems that it does not work and after timeout watchdog reset the board. I run git bisect and it found following commit: 9401f4e46cf6965e23738f70e149172344a01eef is the first bad commit commit 9401f4e46cf6965e23738f70e149172344a01eef Author: Christophe Leroy Date: Tue Mar 2 08:48:11 2021 + powerpc: Use lwarx/ldarx directly instead of PPC_LWARX/LDARX macros Force the eh flag at 0 on PPC32. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1fc81f07cabebb875b963e295408cc3dd38c8d85.1614674882.git.christophe.le...@csgroup.eu :04 04 fe6747e45736dfcba74914a9445e5f70f5120600 96358d08b65d3200928a973efb5b969b3d45f2b0 M arch If I revert this commit then kernel boots correctly. It also boots fine if I revert this commit on top of master branch. Freescale P2020 has two 32-bit e500 powerpc cores. Any idea why above commit is causing crash of the kernel? And why it is needed? Could eh flag set to 0 cause deadlock? I have looked into e500 Reference Manual for lwarx instruction (page 562) https://www.nxp.com/files-static/32bit/doc/ref_manual/EREF_RM.pdf and both 0 and 1 values for EH flag should be supported.
Re: [PATCH v3 01/14] perf/hw_breakpoint: Add KUnit test for constraints accounting
On Thu, Jul 21, 2022 at 05:22:07PM +0100, Mark Rutland wrote:
> Hi Marco,
>
> [adding Will]
>
> On Mon, Jul 04, 2022 at 05:05:01PM +0200, Marco Elver wrote:
> > Add KUnit test for hw_breakpoint constraints accounting, with various
> > interesting mixes of breakpoint targets (some care was taken to catch
> > interesting corner cases via bug-injection).
> >
> > The test cannot be built as a module because it requires access to
> > hw_breakpoint_slots(), which is not inlinable or exported on all
> > architectures.
> >
> > Signed-off-by: Marco Elver
>
> As mentioned on IRC, I'm seeing these tests fail on arm64 when applied atop
> v5.19-rc7:
>
> | TAP version 14
> | 1..1
> | # Subtest: hw_breakpoint
> | 1..9
> | ok 1 - test_one_cpu
> | ok 2 - test_many_cpus
> | # test_one_task_on_all_cpus: ASSERTION FAILED at
> kernel/events/hw_breakpoint_test.c:70
> | Expected IS_ERR(bp) to be false, but is true
> | not ok 3 - test_one_task_on_all_cpus
> | # test_two_tasks_on_all_cpus: ASSERTION FAILED at
> kernel/events/hw_breakpoint_test.c:70
> | Expected IS_ERR(bp) to be false, but is true
> | not ok 4 - test_two_tasks_on_all_cpus
> | # test_one_task_on_one_cpu: ASSERTION FAILED at
> kernel/events/hw_breakpoint_test.c:70
> | Expected IS_ERR(bp) to be false, but is true
> | not ok 5 - test_one_task_on_one_cpu
> | # test_one_task_mixed: ASSERTION FAILED at
> kernel/events/hw_breakpoint_test.c:70
> | Expected IS_ERR(bp) to be false, but is true
> | not ok 6 - test_one_task_mixed
> | # test_two_tasks_on_one_cpu: ASSERTION FAILED at
> kernel/events/hw_breakpoint_test.c:70
> | Expected IS_ERR(bp) to be false, but is true
> | not ok 7 - test_two_tasks_on_one_cpu
> | # test_two_tasks_on_one_all_cpus: ASSERTION FAILED at
> kernel/events/hw_breakpoint_test.c:70
> | Expected IS_ERR(bp) to be false, but is true
> | not ok 8 - test_two_tasks_on_one_all_cpus
> | # test_task_on_all_and_one_cpu: ASSERTION FAILED at
> kernel/events/hw_breakpoint_test.c:70
> | Expected IS_ERR(bp) to be false, but is true
> | not ok 9 - test_task_on_all_and_one_cpu
> | # hw_breakpoint: pass:2 fail:7 skip:0 total:9
> | # Totals: pass:2 fail:7 skip:0 total:9
>
> ... which seems to be becasue arm64 currently forbids per-task
> breakpoints/watchpoints in hw_breakpoint_arch_parse(), where we have:
>
> /*
> * Disallow per-task kernel breakpoints since these would
> * complicate the stepping code.
> */
> if (hw->ctrl.privilege == AARCH64_BREAKPOINT_EL1 && bp->hw.target)
> return -EINVAL;
>
> ... which has been the case since day one in commit:
>
> 478fcb2cdb2351dc ("arm64: Debugging support")
>
> I'm not immediately sure what would be necessary to support per-task kernel
> breakpoints, but given a lot of that state is currently per-cpu, I imagine
> it's
> invasive.
I would actually like to remove HW_BREAKPOINT completely for arm64 as it
doesn't really work and causes problems for other interfaces such as ptrace
and kgdb.
Will
[PATCH] soc: fsl: qe: Add check for platform_driver_register
From: William Dean
As platform_driver_register() could fail, it should be better
to deal with the return value in order to maintain the code
consisitency.
Fixes: be7ecbd240b2f ("soc: fsl: qe: convert QE interrupt controller to
platform_device")
Reported-by: Hacash Robot
Signed-off-by: William Dean
---
drivers/soc/fsl/qe/qe_ic.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c
index bbae3d39c7be..f17de6000ff2 100644
--- a/drivers/soc/fsl/qe/qe_ic.c
+++ b/drivers/soc/fsl/qe/qe_ic.c
@@ -481,7 +481,6 @@ static struct platform_driver qe_ic_driver =
static int __init qe_ic_of_init(void)
{
- platform_driver_register(&qe_ic_driver);
- return 0;
+ return platform_driver_register(&qe_ic_driver);
}
subsys_initcall(qe_ic_of_init);
--
2.25.1
Re: [PATCH v3 01/14] perf/hw_breakpoint: Add KUnit test for constraints accounting
On Fri, Jul 22, 2022 at 11:20:25AM +0200, Dmitry Vyukov wrote:
> On Fri, 22 Jul 2022 at 11:10, Will Deacon wrote:
> > > [adding Will]
> > >
> > > On Mon, Jul 04, 2022 at 05:05:01PM +0200, Marco Elver wrote:
> > > > Add KUnit test for hw_breakpoint constraints accounting, with various
> > > > interesting mixes of breakpoint targets (some care was taken to catch
> > > > interesting corner cases via bug-injection).
> > > >
> > > > The test cannot be built as a module because it requires access to
> > > > hw_breakpoint_slots(), which is not inlinable or exported on all
> > > > architectures.
> > > >
> > > > Signed-off-by: Marco Elver
> > >
> > > As mentioned on IRC, I'm seeing these tests fail on arm64 when applied
> > > atop
> > > v5.19-rc7:
> > >
> > > | TAP version 14
> > > | 1..1
> > > | # Subtest: hw_breakpoint
> > > | 1..9
> > > | ok 1 - test_one_cpu
> > > | ok 2 - test_many_cpus
> > > | # test_one_task_on_all_cpus: ASSERTION FAILED at
> > > kernel/events/hw_breakpoint_test.c:70
> > > | Expected IS_ERR(bp) to be false, but is true
> > > | not ok 3 - test_one_task_on_all_cpus
> > > | # test_two_tasks_on_all_cpus: ASSERTION FAILED at
> > > kernel/events/hw_breakpoint_test.c:70
> > > | Expected IS_ERR(bp) to be false, but is true
> > > | not ok 4 - test_two_tasks_on_all_cpus
> > > | # test_one_task_on_one_cpu: ASSERTION FAILED at
> > > kernel/events/hw_breakpoint_test.c:70
> > > | Expected IS_ERR(bp) to be false, but is true
> > > | not ok 5 - test_one_task_on_one_cpu
> > > | # test_one_task_mixed: ASSERTION FAILED at
> > > kernel/events/hw_breakpoint_test.c:70
> > > | Expected IS_ERR(bp) to be false, but is true
> > > | not ok 6 - test_one_task_mixed
> > > | # test_two_tasks_on_one_cpu: ASSERTION FAILED at
> > > kernel/events/hw_breakpoint_test.c:70
> > > | Expected IS_ERR(bp) to be false, but is true
> > > | not ok 7 - test_two_tasks_on_one_cpu
> > > | # test_two_tasks_on_one_all_cpus: ASSERTION FAILED at
> > > kernel/events/hw_breakpoint_test.c:70
> > > | Expected IS_ERR(bp) to be false, but is true
> > > | not ok 8 - test_two_tasks_on_one_all_cpus
> > > | # test_task_on_all_and_one_cpu: ASSERTION FAILED at
> > > kernel/events/hw_breakpoint_test.c:70
> > > | Expected IS_ERR(bp) to be false, but is true
> > > | not ok 9 - test_task_on_all_and_one_cpu
> > > | # hw_breakpoint: pass:2 fail:7 skip:0 total:9
> > > | # Totals: pass:2 fail:7 skip:0 total:9
> > >
> > > ... which seems to be becasue arm64 currently forbids per-task
> > > breakpoints/watchpoints in hw_breakpoint_arch_parse(), where we have:
> > >
> > > /*
> > > * Disallow per-task kernel breakpoints since these would
> > > * complicate the stepping code.
> > > */
> > > if (hw->ctrl.privilege == AARCH64_BREAKPOINT_EL1 && bp->hw.target)
> > > return -EINVAL;
> > >
> > > ... which has been the case since day one in commit:
> > >
> > > 478fcb2cdb2351dc ("arm64: Debugging support")
> > >
> > > I'm not immediately sure what would be necessary to support per-task
> > > kernel
> > > breakpoints, but given a lot of that state is currently per-cpu, I
> > > imagine it's
> > > invasive.
> >
> > I would actually like to remove HW_BREAKPOINT completely for arm64 as it
> > doesn't really work and causes problems for other interfaces such as ptrace
> > and kgdb.
>
> Will it be a localized removal of code that will be easy to revert in
> future? Or will it touch lots of code here and there?
> Let's say we come up with a very important use case for HW_BREAKPOINT
> and will need to make it work on arm64 as well in future.
My (rough) plan is to implement a lower-level abstraction for handling the
underlying hardware resources, so we can layer consumers on top of that
instead of funneling through hw_breakpoint. So if we figure out how to make
bits of hw_breakpoint work on arm64, then it should just go on top.
The main pain point for hw_breakpoint is kernel-side {break,watch}points
and I think there are open design questions about how they should work
on arm64, particularly when considering the interaction with user
watchpoints triggering on uaccess routines and the possibility of hitting
a kernel watchpoint in irq context.
Will
Re: [PATCH v3 01/14] perf/hw_breakpoint: Add KUnit test for constraints accounting
On Fri, Jul 22, 2022 at 12:31:45PM +0200, Dmitry Vyukov wrote:
> On Fri, 22 Jul 2022 at 12:11, Will Deacon wrote:
> > > > > On Mon, Jul 04, 2022 at 05:05:01PM +0200, Marco Elver wrote:
> > > > > I'm not immediately sure what would be necessary to support per-task
> > > > > kernel
> > > > > breakpoints, but given a lot of that state is currently per-cpu, I
> > > > > imagine it's
> > > > > invasive.
> > > >
> > > > I would actually like to remove HW_BREAKPOINT completely for arm64 as it
> > > > doesn't really work and causes problems for other interfaces such as
> > > > ptrace
> > > > and kgdb.
> > >
> > > Will it be a localized removal of code that will be easy to revert in
> > > future? Or will it touch lots of code here and there?
> > > Let's say we come up with a very important use case for HW_BREAKPOINT
> > > and will need to make it work on arm64 as well in future.
> >
> > My (rough) plan is to implement a lower-level abstraction for handling the
> > underlying hardware resources, so we can layer consumers on top of that
> > instead of funneling through hw_breakpoint. So if we figure out how to make
> > bits of hw_breakpoint work on arm64, then it should just go on top.
> >
> > The main pain point for hw_breakpoint is kernel-side {break,watch}points
> > and I think there are open design questions about how they should work
> > on arm64, particularly when considering the interaction with user
> > watchpoints triggering on uaccess routines and the possibility of hitting
> > a kernel watchpoint in irq context.
>
> I see. Our main interest would be break/watchpoints on user addresses
> firing from both user-space and kernel (uaccess), so at least on irqs.
Interesting. Do other architectures report watchpoint hits on user
addresses from kernel uaccess? It feels like this might be surprising to
some users, and it opens up questions about accesses using different virtual
aliases (e.g. via GUP) or from other entities as well (e.g. firmware,
KVM guests, DMA).
Will
Re: [PATCH v3] random: handle archrandom with multiple longs
On Tue, Jul 19, 2022 at 03:02:07PM +0200, Jason A. Donenfeld wrote: > The archrandom interface was originally designed for x86, which supplies > RDRAND/RDSEED for receiving random words into registers, resulting in > one function to generate an int and another to generate a long. However, > other architectures don't follow this. > > On arm64, the SMCCC TRNG interface can return between 1 and 3 longs. On > s390, the CPACF TRNG interface can return arbitrary amounts, with 32 > longs having the same cost as one. On UML, the os_getrandom() interface > can return arbitrary amounts. > > So change the api signature to take a "max_longs" parameter designating > the maximum number of longs requested, and then return the number of > longs generated. > > Since callers need to check this return value and loop anyway, each arch > implementation does not bother implementing its own loop to try again to > fill the maximum number of longs. Additionally, all existing callers > pass in a constant max_longs parameter. Taken together, these two things > mean that the codegen doesn't really change much for one-word-at-a-time > platforms, while performance is greatly improved on platforms such as > s390. > > Cc: Will Deacon > Cc: Alexander Gordeev > Cc: Thomas Gleixner > Cc: H. Peter Anvin > Cc: Catalin Marinas > Cc: Borislav Petkov > Cc: Heiko Carstens > Cc: Johannes Berg > Cc: Mark Rutland > Cc: Harald Freudenberger > Acked-by: Michael Ellerman > Signed-off-by: Jason A. Donenfeld > --- > arch/arm64/include/asm/archrandom.h | 102 -- > arch/arm64/kernel/kaslr.c | 2 +- > arch/powerpc/include/asm/archrandom.h | 30 ++-- > arch/powerpc/kvm/book3s_hv.c | 2 +- > arch/s390/include/asm/archrandom.h| 29 ++-- > arch/um/include/asm/archrandom.h | 21 ++ > arch/x86/include/asm/archrandom.h | 41 +-- > arch/x86/kernel/espfix_64.c | 2 +- > drivers/char/random.c | 45 > include/asm-generic/archrandom.h | 18 + > include/linux/random.h| 12 +-- > 11 files changed, 116 insertions(+), 188 deletions(-) For s390: Acked-by: Heiko Carstens
Re: [PATCH] amdgpu: re-enable DCN for ppc64le
Hi Dan, [ Cc += linuxppc-dev ] Dan Horák writes: > Commit d11219ad53dc disabled the DCN driver for all platforms that > define PPC64 due long build issues during "make allmodconfig" using > cross-compilation. Cross-compilation defaults to the ppc64_defconfig > and thus big-endian toolchain configuration. The ppc64le platform uses a > different ABI and doesn't suffer from the build issues. Unfortunately it's a bit messier than that. The build error occurs when the compiler is built to use a 64-bit long double type. The ppc64le ABI document says that long double should be 128-bits, but there are ppc64le compilers out there that are configured to use 64-bit long double, notably the kernel.org crosstool compilers. So just testing for CPU_LITTLE_ENDIAN means we'll still get build errors on those compilers. But I think we can detect the long double size and key off that. Can you test the patch below works for you? cheers diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 7aa12e88c580..e9f8cd50af99 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -281,6 +281,9 @@ config PPC # Please keep this list sorted alphabetically. # +config PCC_LONG_DOUBLE_128 + def_bool $(success,test "$(shell,echo __LONG_DOUBLE_128__ | $(CC) -E -P -)" = 1) + config PPC_BARRIER_NOSPEC bool default y diff --git a/drivers/gpu/drm/amd/display/Kconfig b/drivers/gpu/drm/amd/display/Kconfig index b4029c0d5d8c..ec6771e87e73 100644 --- a/drivers/gpu/drm/amd/display/Kconfig +++ b/drivers/gpu/drm/amd/display/Kconfig @@ -6,7 +6,7 @@ config DRM_AMD_DC bool "AMD DC - Enable new display engine" default y select SND_HDA_COMPONENT if SND_HDA_CORE - select DRM_AMD_DC_DCN if (X86 || PPC64) && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS) + select DRM_AMD_DC_DCN if (X86 || PPC_LONG_DOUBLE_128) && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS) help Choose this option if you want to use the new display engine support for AMDGPU. This adds required support for Vega and
Re: [PATCH] amdgpu: re-enable DCN for ppc64le
On Fri, 22 Jul 2022 22:32:06 +1000 Michael Ellerman wrote: > Hi Dan, > > [ Cc += linuxppc-dev ] > > Dan Horák writes: > > Commit d11219ad53dc disabled the DCN driver for all platforms that > > define PPC64 due long build issues during "make allmodconfig" using > > cross-compilation. Cross-compilation defaults to the ppc64_defconfig > > and thus big-endian toolchain configuration. The ppc64le platform uses a > > different ABI and doesn't suffer from the build issues. > > Unfortunately it's a bit messier than that. > > The build error occurs when the compiler is built to use a 64-bit long > double type. > > The ppc64le ABI document says that long double should be 128-bits, but > there are ppc64le compilers out there that are configured to use 64-bit > long double, notably the kernel.org crosstool compilers. > > So just testing for CPU_LITTLE_ENDIAN means we'll still get build errors > on those compilers. > > But I think we can detect the long double size and key off that. Can you > test the patch below works for you? > > cheers > > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 7aa12e88c580..e9f8cd50af99 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -281,6 +281,9 @@ config PPC > # Please keep this list sorted alphabetically. > # > > +config PCC_LONG_DOUBLE_128 > + def_bool $(success,test "$(shell,echo __LONG_DOUBLE_128__ | $(CC) -E -P > -)" = 1) ^^^ there is a typo s/PCC/PPC/ :-) with that fixed, it then defines AMD_DC_DCN on Fedora 36 with gcc-12.1.1-1.fc36.ppc64le and we should be OK. Dan > + > config PPC_BARRIER_NOSPEC > bool > default y > diff --git a/drivers/gpu/drm/amd/display/Kconfig > b/drivers/gpu/drm/amd/display/Kconfig > index b4029c0d5d8c..ec6771e87e73 100644 > --- a/drivers/gpu/drm/amd/display/Kconfig > +++ b/drivers/gpu/drm/amd/display/Kconfig > @@ -6,7 +6,7 @@ config DRM_AMD_DC > bool "AMD DC - Enable new display engine" > default y > select SND_HDA_COMPONENT if SND_HDA_CORE > - select DRM_AMD_DC_DCN if (X86 || PPC64) && !(KCOV_INSTRUMENT_ALL && > KCOV_ENABLE_COMPARISONS) > + select DRM_AMD_DC_DCN if (X86 || PPC_LONG_DOUBLE_128) && > !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS) > help > Choose this option if you want to use the new display engine > support for AMDGPU. This adds required support for Vega and
Re: [PATCH] amdgpu: re-enable DCN for ppc64le
On Fri, 22 Jul 2022 22:32:06 +1000 Michael Ellerman wrote: > Hi Dan, > > [ Cc += linuxppc-dev ] > > Dan Horák writes: > > Commit d11219ad53dc disabled the DCN driver for all platforms that > > define PPC64 due long build issues during "make allmodconfig" using > > cross-compilation. Cross-compilation defaults to the ppc64_defconfig > > and thus big-endian toolchain configuration. The ppc64le platform uses a > > different ABI and doesn't suffer from the build issues. > > Unfortunately it's a bit messier than that. yes, seems it is :-) > The build error occurs when the compiler is built to use a 64-bit long > double type. > > The ppc64le ABI document says that long double should be 128-bits, but > there are ppc64le compilers out there that are configured to use 64-bit > long double, notably the kernel.org crosstool compilers. > > So just testing for CPU_LITTLE_ENDIAN means we'll still get build errors > on those compilers. > > But I think we can detect the long double size and key off that. Can you > test the patch below works for you? yes, it does work, meaning it defines AMD_DC_DCN on Fedora/ppc64le (and build is OK) Dan > > cheers > > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 7aa12e88c580..e9f8cd50af99 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -281,6 +281,9 @@ config PPC > # Please keep this list sorted alphabetically. > # > > +config PCC_LONG_DOUBLE_128 > + def_bool $(success,test "$(shell,echo __LONG_DOUBLE_128__ | $(CC) -E -P > -)" = 1) > + > config PPC_BARRIER_NOSPEC > bool > default y > diff --git a/drivers/gpu/drm/amd/display/Kconfig > b/drivers/gpu/drm/amd/display/Kconfig > index b4029c0d5d8c..ec6771e87e73 100644 > --- a/drivers/gpu/drm/amd/display/Kconfig > +++ b/drivers/gpu/drm/amd/display/Kconfig > @@ -6,7 +6,7 @@ config DRM_AMD_DC > bool "AMD DC - Enable new display engine" > default y > select SND_HDA_COMPONENT if SND_HDA_CORE > - select DRM_AMD_DC_DCN if (X86 || PPC64) && !(KCOV_INSTRUMENT_ALL && > KCOV_ENABLE_COMPARISONS) > + select DRM_AMD_DC_DCN if (X86 || PPC_LONG_DOUBLE_128) && > !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS) > help > Choose this option if you want to use the new display engine > support for AMDGPU. This adds required support for Vega and
