Received-SPF: pass (google.com: domain of linux-kernel+bounces-98890-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Mon, 11 Mar 2024 14:05:37 +0100
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: Serge Semin <fancer.lancer@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Jiaxun Yang <jiaxun.yang@flygoat.com>,
	Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/2] MIPS: Fix missing proto and passing arg warnings
Message-ID: <Ze8BoUxUZ3CL0yG4@alpha.franken.de>
References: <20240226105427.7191-1-fancer.lancer@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20240226105427.7191-1-fancer.lancer@gmail.com>

On Mon, Feb 26, 2024 at 01:54:20PM +0300, Serge Semin wrote:
> After getting my local tree rebased onto the kernel 6.8-rc3 the MIPS32
> kernel build procedure produced a couple of warnings which I suggest to
> fix in the framework of this series.
> 
> A first warning is of the "no previous prototype for `<func>`" type. In
> particular my arch-specific code has the mips_cm_l2sync_phys_base() method
> re-defined, but even though the function is global it' prototype isn't
> declared anywhere. Fix that by moving the __mips_cm_l2sync_phys_base()
> body to a weak implementation of mips_cm_l2sync_phys_base() and adding the
> method prototype declaration to the mips/include/asm/mips-cm.h header
> file. For the sake of unification a similar solution was provided for the
> mips_cm_phys_base()/__mips_cm_phys_base() couple.
> 
> The following text describes the patches which have already merged in at
> v1 stage of the patchset (see changelog v2).
> 
> One more case of the denoted earlier warning I spotted in the
> self-extracting kernel (so called zboot) with the debug printouts enabled.
> In particular there are several putc() method re-definitions available in:
> arch/mips/boot/compressed/uart-prom.c
> arch/mips/boot/compressed/uart-16550.c
> arch/mips/boot/compressed/uart-alchemy.c
> All of these files lacked the prototype declaration what caused having the
> "no previous prototype for ‘putc’" printed on my build with the next
> configs enabled:
> CONFIG_SYS_SUPPORTS_ZBOOT=y
> CONFIG_SYS_SUPPORTS_ZBOOT_UART_PROM=y
> CONFIG_ZBOOT_LOAD_ADDRESS=0x85100000
> CONFIG_DEBUG_ZBOOT=y
> 
> The second warning is of the "passing argument <x> of ‘<func>’ from
> incompatible pointer type" type which I discovered in the
> drivers/tty/mips_ejtag_fdc.c driver. The problem most likely happened due
> to the commit ce7cbd9a6c81 ("tty: mips_ejtag_fdc: use u8 for character
> pointers").
> 
> That's it for today.) Thanks for review in advance. Any tests are very
> welcome.
> 
> Link: https://lore.kernel.org/linux-mips/20240215171740.14550-1-fancer.lancer@gmail.com
> Changelog v2:
> - Drop aleady applied pateches:
>   [PATCH 3/4] mips: zboot: Fix "no previous prototype" build warning
>   [PATCH 4/4] tty: mips_ejtag_fdc: Fix passing incompatible pointer type warning
> - Drop Linux serial mailing list and the respective maintainers from the
>   Cc-list.
> - Covert the underscored versions of the CM2/L2-sync base address
>   getters to being the body of the weakly defined original methods.
> 
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: linux-mips@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> 
> Serge Semin (2):
>   mips: cm: Convert __mips_cm_l2sync_phys_base() to weak function
>   mips: cm: Convert __mips_cm_phys_base() to weak function
> 
>  arch/mips/include/asm/mips-cm.h | 20 ++++++++++++++++----
>  arch/mips/kernel/mips-cm.c      | 10 ++--------
>  2 files changed, 18 insertions(+), 12 deletions(-)
> 
> -- 
> 2.43.0

series applied to mips-next.

Thomas.

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