[ Part 1 ]: MIPS: dec: Only check -msym32 when need compiler

During 'make modules_install', the need-compiler variable becomes
null, so Makefile.compiler isn't included.
    
This results in call cc-option-yn returning nothing.
    
For more technical details on why need-compiler is null during
'make modules_install' and why no compiler invocation is actually
needed at this point, please refer to commit 4fe4a6374c4d ("MIPS:
Only fiddle with CHECKFLAGS if need-compiler") and commit
805b2e1d427a ("kbuild: include Makefile.compiler only when compiler
is needed").
    
Commit a79a404e6c22 ("MIPS: Fix CONFIG_CPU_DADDI_WORKAROUNDS
`modules_install' regression") tried to fix the same issue but it
caused a compile error on clang compiler because it doesn't support
'-msym32'. Then, commit 18ca63a2e23c ("MIPS: Probe toolchain support
of -msym32") fixed it but reintroduced the CONFIG_CPU_DADDI_WORKAROUNDS
`modules_install' regression.

Wrapping this entire code block with #ifdef need-compiler to avoid
all issues is the best solution for now.
    
To get rid of spurious "CONFIG_CPU_DADDI_WORKAROUNDS unsupported
without -msym32" error.

Moreover, I also identified an unnecessary check for KBUILD_SYM32
in this Makefile section. Eliminate it for code simplification.

NOTE:

It is particularly important to note that this code fix does not
imply that we have resolved the problem entirely.

In fact, the entire application of cc-option and its auxiliary
commands within the kernel codebase currently carries significant
risk.

When we execute make modules_install, the Makefile for the
corresponding architecture under arch/subarches/Makefile is
invariably included. Within these files, there are numerous
usages of cc-option and its auxiliary commands, all of which will
return empty strings. The reason other architectures can
successfully complete compilation under these circumstances is
purely because they do not, unlike MIPS, check the return values
of cc-option and its auxiliary commands within their Makefiles
and halt the compilation process when the expected results are
not received.

A feasible approach to remediation might be to encapsulate all
usages of cc-option and its auxiliary commands within conditional
statements across all architecture Makefiles, preventing their
execution entirely during make modules_install.

However, this would lead to a massive number of inelegant
modifications, and these broader implications may require
deliberation by Masahiro Yamada.

Regardless, this does not preclude us from addressing the
issue on MIPS first.

Link: https://lore.kernel.org/all/41107E6D3A125047+20250211135616.1807966-1-wangyuli@uniontech.com/
Link: https://lore.kernel.org/all/F49F5EE9975F29EA+20250214094758.172055-1-wangyuli@uniontech.com/
Link: https://lore.kernel.org/all/8ABBF323414AEF93+20250217142541.48149-1-wangyuli@uniontech.com/


[ Part 2 ]: MIPS: decstation_64_defconfig: Compile the kernel with warnings as errors

Patch ("MIPS: dec: Only check -msym32 when need compiler") allows
us to compile kernel image packages with decstation_64_defconfig.

However, compilation warnings remain during the build.

Address these warnings and enable CONFIG_WERROR for decstation_64_defconfig.

Link: https://lore.kernel.org/all/487CE8AA937621E2+20250218125101.663980-1-wangyuli@uniontech.com/
Link: https://lore.kernel.org/all/EA0AFB15DDCF65C1+20250227141949.1129536-1-wangyuli@uniontech.com/
Link: https://lore.kernel.org/all/303EFD6BFBDAC7C8+20250305033436.31214-1-wangyuli@uniontech.com/


[ Changelog: ]

 *v1->v2: Add Philippe Mathieu-Daudé's "Reviewed-by" tag in patch3.
Link: https://lore.kernel.org/all/11740B01E659CAFF+20250407073158.493183-1-wangyuli@uniontech.com/
Link: https://lore.kernel.org/all/8dcb5c6d-be4f-4891-a999-137d53edfc05@linaro.org/

WangYuli (6):
  MIPS: dec: Only check -msym32 when need compiler
  MIPS: Eliminate Redundant KBUILD_SYM32 Checks
  MIPS: dec: Create reset.h
  MIPS: dec: Remove dec_irq_dispatch()
  MIPS: decstation_64_defconfig: Update configs dependencies
  MIPS: decstation_64_defconfig: Compile the kernel with warnings as
    errors

 arch/mips/Makefile                        |  6 ++--
 arch/mips/configs/decstation_64_defconfig | 43 +++++++++--------------
 arch/mips/dec/int-handler.S               |  2 +-
 arch/mips/dec/prom/init.c                 |  3 +-
 arch/mips/dec/reset.c                     |  2 ++
 arch/mips/dec/setup.c                     | 15 ++------
 arch/mips/include/asm/dec/reset.h         | 20 +++++++++++
 7 files changed, 47 insertions(+), 44 deletions(-)
 create mode 100644 arch/mips/include/asm/dec/reset.h

-- 
2.49.0

Hi all,

This is a gentle ping.

I've addressed all the feedback from previous discussions and tried 
resending multiple times, but haven't received any response


On 2025/4/22 18:18, WangYuli wrote:
> [ Part 1 ]: MIPS: dec: Only check -msym32 when need compiler
>
> During 'make modules_install', the need-compiler variable becomes
> null, so Makefile.compiler isn't included.
>      
> This results in call cc-option-yn returning nothing.
>      
> For more technical details on why need-compiler is null during
> 'make modules_install' and why no compiler invocation is actually
> needed at this point, please refer to commit 4fe4a6374c4d ("MIPS:
> Only fiddle with CHECKFLAGS if need-compiler") and commit
> 805b2e1d427a ("kbuild: include Makefile.compiler only when compiler
> is needed").
>      
> Commit a79a404e6c22 ("MIPS: Fix CONFIG_CPU_DADDI_WORKAROUNDS
> `modules_install' regression") tried to fix the same issue but it
> caused a compile error on clang compiler because it doesn't support
> '-msym32'. Then, commit 18ca63a2e23c ("MIPS: Probe toolchain support
> of -msym32") fixed it but reintroduced the CONFIG_CPU_DADDI_WORKAROUNDS
> `modules_install' regression.
>
> Wrapping this entire code block with #ifdef need-compiler to avoid
> all issues is the best solution for now.
>      
> To get rid of spurious "CONFIG_CPU_DADDI_WORKAROUNDS unsupported
> without -msym32" error.
>
> Moreover, I also identified an unnecessary check for KBUILD_SYM32
> in this Makefile section. Eliminate it for code simplification.
>
> NOTE:
>
> It is particularly important to note that this code fix does not
> imply that we have resolved the problem entirely.
>
> In fact, the entire application of cc-option and its auxiliary
> commands within the kernel codebase currently carries significant
> risk.
>
> When we execute make modules_install, the Makefile for the
> corresponding architecture under arch/subarches/Makefile is
> invariably included. Within these files, there are numerous
> usages of cc-option and its auxiliary commands, all of which will
> return empty strings. The reason other architectures can
> successfully complete compilation under these circumstances is
> purely because they do not, unlike MIPS, check the return values
> of cc-option and its auxiliary commands within their Makefiles
> and halt the compilation process when the expected results are
> not received.
>
> A feasible approach to remediation might be to encapsulate all
> usages of cc-option and its auxiliary commands within conditional
> statements across all architecture Makefiles, preventing their
> execution entirely during make modules_install.
>
> However, this would lead to a massive number of inelegant
> modifications, and these broader implications may require
> deliberation by Masahiro Yamada.
>
> Regardless, this does not preclude us from addressing the
> issue on MIPS first.
>
> Link: https://lore.kernel.org/all/41107E6D3A125047+20250211135616.1807966-1-wangyuli@uniontech.com/
> Link: https://lore.kernel.org/all/F49F5EE9975F29EA+20250214094758.172055-1-wangyuli@uniontech.com/
> Link: https://lore.kernel.org/all/8ABBF323414AEF93+20250217142541.48149-1-wangyuli@uniontech.com/
>
>
> [ Part 2 ]: MIPS: decstation_64_defconfig: Compile the kernel with warnings as errors
>
> Patch ("MIPS: dec: Only check -msym32 when need compiler") allows
> us to compile kernel image packages with decstation_64_defconfig.
>
> However, compilation warnings remain during the build.
>
> Address these warnings and enable CONFIG_WERROR for decstation_64_defconfig.
>
> Link: https://lore.kernel.org/all/487CE8AA937621E2+20250218125101.663980-1-wangyuli@uniontech.com/
> Link: https://lore.kernel.org/all/EA0AFB15DDCF65C1+20250227141949.1129536-1-wangyuli@uniontech.com/
> Link: https://lore.kernel.org/all/303EFD6BFBDAC7C8+20250305033436.31214-1-wangyuli@uniontech.com/
>
>
> [ Changelog: ]
>
>   *v1->v2: Add Philippe Mathieu-Daudé's "Reviewed-by" tag in patch3.
> Link: https://lore.kernel.org/all/11740B01E659CAFF+20250407073158.493183-1-wangyuli@uniontech.com/
> Link: https://lore.kernel.org/all/8dcb5c6d-be4f-4891-a999-137d53edfc05@linaro.org/
>
> WangYuli (6):
>    MIPS: dec: Only check -msym32 when need compiler
>    MIPS: Eliminate Redundant KBUILD_SYM32 Checks
>    MIPS: dec: Create reset.h
>    MIPS: dec: Remove dec_irq_dispatch()
>    MIPS: decstation_64_defconfig: Update configs dependencies
>    MIPS: decstation_64_defconfig: Compile the kernel with warnings as
>      errors
>
>   arch/mips/Makefile                        |  6 ++--
>   arch/mips/configs/decstation_64_defconfig | 43 +++++++++--------------
>   arch/mips/dec/int-handler.S               |  2 +-
>   arch/mips/dec/prom/init.c                 |  3 +-
>   arch/mips/dec/reset.c                     |  2 ++
>   arch/mips/dec/setup.c                     | 15 ++------
>   arch/mips/include/asm/dec/reset.h         | 20 +++++++++++
>   7 files changed, 47 insertions(+), 44 deletions(-)
>   create mode 100644 arch/mips/include/asm/dec/reset.h
>
-- 
WangYuli

Hi WangYuli,

> This is a gentle ping.
> 
> I've addressed all the feedback from previous discussions and tried resending
> multiple times, but haven't received any response

 Thank you for pinging.

 I've tried to verify your changes at run time and it's turned out that a 
generic change to the serial communication subsystem made a while ago has 
caused the port to become unbootable, and it now crashes early on in port 
registration.

 As I'd rather was sure no regression is introduced with your changes I am 
going to put them on hold until the issue with the serial ports has been 
fixed.  I know what to do there and just need to find a time slot to get 
that sorted.

 No worries, I'm not going to lose your changes.  Thank you for patience.

  Maciej

On Mon, Jul 07, 2025 at 03:57:01PM +0100, Maciej W. Rozycki wrote:
> Hi WangYuli,
> 
> > This is a gentle ping.
> > 
> > I've addressed all the feedback from previous discussions and tried resending
> > multiple times, but haven't received any response
> 
>  Thank you for pinging.
> 
>  I've tried to verify your changes at run time and it's turned out that a 
> generic change to the serial communication subsystem made a while ago has 
> caused the port to become unbootable, and it now crashes early on in port 
> registration.

I'm hitting the same issue for IP22, my dirty hack to get serial console
back is

diff --git a/drivers/tty/serial/serial_base_bus.c b/drivers/tty/serial/serial_base_bus.c
index 5d1677f1b651..fccb0f1c3cc5 100644
--- a/drivers/tty/serial/serial_base_bus.c
+++ b/drivers/tty/serial/serial_base_bus.c
@@ -78,12 +78,14 @@ static int serial_base_device_init(struct uart_port *port,
 		return -EPROBE_DEFER;
 	}
 
+#if 0
 	if (type == &serial_ctrl_type)
 		return dev_set_name(dev, "%s:%d", dev_name(port->dev), ctrl_id);
 
 	if (type == &serial_port_type)
 		return dev_set_name(dev, "%s:%d.%d", dev_name(port->dev),
 				    ctrl_id, port_id);
+#endif
 
 	return -EINVAL;
 }

I'm not sure, if port->dev needs to be populated now for every serial
port or if there should be a check for port->dev == NULL in the code above...

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

On Wed, 16 Jul 2025, Thomas Bogendoerfer wrote:

> >  I've tried to verify your changes at run time and it's turned out that a 
> > generic change to the serial communication subsystem made a while ago has 
> > caused the port to become unbootable, and it now crashes early on in port 
> > registration.
> 
> I'm hitting the same issue for IP22, my dirty hack to get serial console
> back is
> 
> diff --git a/drivers/tty/serial/serial_base_bus.c b/drivers/tty/serial/serial_base_bus.c
> index 5d1677f1b651..fccb0f1c3cc5 100644
> --- a/drivers/tty/serial/serial_base_bus.c
> +++ b/drivers/tty/serial/serial_base_bus.c
> @@ -78,12 +78,14 @@ static int serial_base_device_init(struct uart_port *port,
>  		return -EPROBE_DEFER;
>  	}
>  
> +#if 0
>  	if (type == &serial_ctrl_type)
>  		return dev_set_name(dev, "%s:%d", dev_name(port->dev), ctrl_id);
>  
>  	if (type == &serial_port_type)
>  		return dev_set_name(dev, "%s:%d.%d", dev_name(port->dev),
>  				    ctrl_id, port_id);
> +#endif
>  
>  	return -EINVAL;
>  }
> 
> I'm not sure, if port->dev needs to be populated now for every serial
> port or if there should be a check for port->dev == NULL in the code above...

 Thanks for your report.  I don't know what the exact root cause is with 
IP22, but with the DECstation configurations it's clearly a technical debt 
that needs to be paid now, by switching the respective core drivers to use 
platform devices for probing.

 We've had basic infrastructure for a while already, so I just need to 
fill the gaps there.  This will help the reuse of zs.c for the Alpha port 
as well (and dz.c could be reused for the VAX port this way, but I guess 
that won't ever happen as there's too much effort needed and too little 
manpower available to revive it).

 I'm off for a week now and will look into it sometime once I'm back.

  Maciej