From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from elvis.franken.de (elvis.franken.de [193.175.24.41]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 96B56360AD; Thu, 21 Dec 2023 14:55:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=alpha.franken.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=alpha.franken.de Received: from uucp by elvis.franken.de with local-rmail (Exim 3.36 #1) id 1rGKSq-0002PR-00; Thu, 21 Dec 2023 15:55:56 +0100 Received: by alpha.franken.de (Postfix, from userid 1000) id D7761C0A1E; Thu, 21 Dec 2023 15:55:43 +0100 (CET) Date: Thu, 21 Dec 2023 15:55:43 +0100 From: Thomas Bogendoerfer To: Gregory CLEMENT Cc: Paul Burton , linux-mips@vger.kernel.org, Jiaxun Yang , Rob Herring , Krzysztof Kozlowski , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Vladimir Kondratiev , Tawfik Bayouk , Alexandre Belloni , =?iso-8859-1?Q?Th=E9o?= Lebrun , Thomas Petazzoni Subject: Re: [PATCH v5 00/22] Add support for the Mobileye EyeQ5 SoC Message-ID: References: <20231212163459.1923041-1-gregory.clement@bootlin.com> <878r5vctdg.fsf@BL-laptop> <87frzwasxo.fsf@BL-laptop> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87frzwasxo.fsf@BL-laptop> On Thu, Dec 21, 2023 at 08:57:55AM +0100, Gregory CLEMENT wrote: > I do not oppose the addition of a new platform, even though, like > Jiaxun, I would prefer to avoid duplicating code. The only thing > preventing the use of the same kernel for EyeQ5 and other platforms is > the starting address. there shouldn't be code duplication. My rough idea would be something like diff --git a/arch/mips/Kbuild b/arch/mips/Kbuild index af2967bffb73..d683993ed331 100644 --- a/arch/mips/Kbuild +++ b/arch/mips/Kbuild @@ -17,6 +17,7 @@ obj- := $(platform-y) # mips object files # The object files are linked as core-y files would be linked +obj-y += generic/ obj-y += kernel/ obj-y += mm/ obj-y += net/ diff --git a/arch/mips/generic/Makefile b/arch/mips/generic/Makefile index e37a59bae0a6..56011d738441 100644 --- a/arch/mips/generic/Makefile +++ b/arch/mips/generic/Makefile @@ -4,9 +4,9 @@ # Author: Paul Burton # -obj-y += init.o -obj-y += irq.o -obj-y += proc.o +obj-$(CONFIG_MACH_GENERIC_CORE) += init.o +obj-$(CONFIG_MACH_GENERIC_CORE) += irq.o +obj-$(CONFIG_MACH_GENERIC_CORE) += proc.o obj-$(CONFIG_YAMON_DT_SHIM) += yamon-dt.o obj-$(CONFIG_LEGACY_BOARD_SEAD3) += board-sead3.o so everyboady needing these parts of a generic kernel is able to take it. > Therefore, if it were possible to have a relocatable kernel, this > issue would disappear. yes. There is support for relocatable kernel, so what are we missing there ? Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]