From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta-65-129.flowmailer.net (mta-65-129.flowmailer.net [185.136.65.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 53BE420C461 for ; Tue, 19 May 2026 10:30:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.136.65.129 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779186622; cv=none; b=T+Z5AALHz2U/BpGUpOJstrIfFBRI69sljVCqcl3awUljwOjkYaXvfyw4wtC4HcTeYwgp2mYMaLN5gD1U8BvzvXn7e0sHZs3t6o2E4FyFYCCgEuEH9/GRNJ6oYQkIBGGKPCWe1rdT5XKWqKExYYKRHvE6tS04LTdHGPqaBixhj2g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779186622; c=relaxed/simple; bh=FMylFNF2LBIsDQTt92IHLCTEBM4Uc4LrYwy7HvJjx8M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cqZG83RNVUghJTCbT5aB1yFpSgo+hPvnXuYbk1fd2VlmUPR+GIbXwu0dkDzxp24B/Gcd7zIAz5TscWG3BzovT5lgBSLy39XiUIuqdiC+yHLdN/jL6Dzzus8kikWuGs8s6GxctkTt6saXJwR25ZIRtNlWQq2Vi0yj1X7oYOU3zsg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=siemens-energy.com; spf=pass smtp.mailfrom=errorhandling.siemens-energy.com; dkim=pass (1024-bit key) header.d=flowmailer.net header.i=@flowmailer.net header.b=EZaazZKd; dkim=pass (2048-bit key) header.d=siemens-energy.com header.i=schuster.simon@siemens-energy.com header.b=Te2jAfZD; arc=none smtp.client-ip=185.136.65.129 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=siemens-energy.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=errorhandling.siemens-energy.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=flowmailer.net header.i=@flowmailer.net header.b="EZaazZKd"; dkim=pass (2048-bit key) header.d=siemens-energy.com header.i=schuster.simon@siemens-energy.com header.b="Te2jAfZD" Received: by mta-65-129.flowmailer.net with ESMTPSA id 202605191030159390c198150019fda8 for ; Tue, 19 May 2026 12:30:15 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=s1; d=flowmailer.net; h=from:from:sender:to:to:cc:cc:subject:subject:content-type:content-type:content-transfer-encoding:References:In-Reply-To:Date:Message-ID:MIME-Version; bh=VQcumpK/VH7AMVe3D9QfBdm875bqYNSA1S/WhQcMd50=; b=EZaazZKd3ZONXRq4GpMzuNQLKWTjDM3BCDcJN1Zro5Jf4shP6ldQEZRd/JpK1AZ4rlK0YF /Aa7cioXIloqt5aLEMZp2zhOmX1/9l/6y1VhiFuSN27YZpJ0WrZoxkmuTSB8KOR9mJccLgIF U5YZLq88tEC65edr76mfk0J41cOEg=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=fm3; d=siemens-energy.com; i=schuster.simon@siemens-energy.com; h=from:from:sender:to:to:cc:cc:subject:subject:content-type:content-type:content-transfer-encoding:References:In-Reply-To:Date:Message-ID:MIME-Version; bh=VQcumpK/VH7AMVe3D9QfBdm875bqYNSA1S/WhQcMd50=; b=Te2jAfZD7hDN23NQ3+54hePl7vopCgSM3JMxLh/fm7xcDVL3oowG/1GukwfDalvkw/93pk r1edcvtKHS8aMq6NRNiOadutVoT+ObgjmyLqPfqBF0IzKI4s/3l4Ljo3Ns0e8129/XbiB/f0 eILgqZumYF4wXN2RrKqjT6iJT48jJyha8qiB1Ms2c7YCYUsoOaUZYeqchP96MjjkD2jP9Tnp Bup5ZCH2E2PIWkx0GqjYc7NY1+ofQc4JMbJbK42rmOgM8diRAjnGGhXNzlSI65tykwA8DWj2 tjMUFpTA0awNupV3gXQUmo6aF83iBjTdaCqUN4ZyrwUBouDMkjB7zheA==; Date: Tue, 19 May 2026 12:30:12 +0200 From: Simon Schuster To: Ethan Nelson-Moore , Wolfram Sang Cc: Peter Zijlstra , Arnd Bergmann , Dinh Nguyen , linux-doc@vger.kernel.org, devicetree@vger.kernel.org, workflows@vger.kernel.org, Linux-Arch , dmaengine@vger.kernel.org, linux-i2c@vger.kernel.org, linux-iio@vger.kernel.org, Netdev , linux-pci@vger.kernel.org, linux-pwm@vger.kernel.org, linux-hardening@vger.kernel.org, linux-kbuild@vger.kernel.org, "linux-csky@vger.kernel.org" , Jonathan Corbet , Shuah Khan , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Daniel Lezcano , Thomas Gleixner , Alex Shi , Yanteng Si , Dongliang Mu , Hu Haowen <2023002089@link.tyut.edu.cn>, Kees Cook , Oleg Nesterov , Will Deacon , "Aneesh Kumar K.V (Arm)" , Andrew Morton , Nicholas Piggin , Vinod Koul , Frank Li , Dave Penkler , Andi Shyti , Jonathan Cameron , David Lechner , =?ISO-8859-1?Q?Nuno_S=E1?= , Andy Shevchenko , Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Lorenzo Pieralisi , Krzysztof WilczyDski , Andreas Oetken Subject: Re: [PATCH] nios2: remove the architecture Message-ID: <20260519103012.blot4bssgiqfer6p@dev-vm-schuster> References: <20260518042833.272221-1-enelsonmoore@gmail.com> <20260518105735.GW3126523@noisy.programming.kicks-ass.net> <20260518172444.zyd47mcagrcwu7wt@dev-vm-schuster> Precedence: bulk X-Mailing-List: linux-doc@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: Hi Ethan, hi Wolfram, Thank you for your thoughtful responses. On Mon, May 18, 2026 at 05:13:58PM -0700, Ethan Nelson-Moore wrote: > Your reasoning makes complete sense. However, there is an alternative > to maintaining the architecture in mainline. > > The Civil Infrastructure Platform project maintains super-LTS kernels > (and a set of base Debian packages) for 10 years. They are intended to > be used for exactly these kinds of devices. > See here: https://wiki.linuxfoundation.org/civilinfrastructureplatform/start#kernel_maintainership > and here: https://cip-project.org/about/linux-kernel-core-packages > > CIP will maintain kernel 6.12 until 2035. Is this long enough for your > lifecycle? What kernel are you currently using? If it's newer than > 6.12, we can easily wait until the next CIP SLTS release to remove > Nios II support to avoid a downgrade. This depends. For released/maintained firmware revisions we already track CIP SLTS versions (candidates) to be prepared, the majority of which is currently still running 6.1.x with 6.12.x up-and-coming. But for the reasons outlined by you regarding architectural and feature support in CIP SLTS, we do not, however, use the extended support duration SLTS releases in production, and instead upgrade with the kernel.org LTS branch release schedule and track these internally alongside mainline to prevent major obstacles during version jumps. 2035 is still a rather tight timeframe for our typical support/phase-out period (we would hope to get close to 2040 with the SLTS extensions), which is also the reason for our targeted 'lifetime extension' for the nios2 architecture for approximately 5 years, or more precisely ~2-3 SLTS kernels assuming the usual cadence of 2 years between SLTS versions (+ some safety margin). > Also, CIP focuses on architectures used by CIP members - currently I > think they are x86 (32 and 64-bit), ARM (32 and 64-bit) and RISC-V. > Since Siemens is already a CIP member, you can simply ask them to add > Nios II to the list, and you can assist them with testing and directly > submit patches to them once the standard 6.12 LTS period ends. We have already been in contact with the CIP team (even though the contact has unfortunately lapsed a bit, mostly our fault), but adding an additional architecture seemed to be a more substantial effort. N.B.: Due to past circumstances, we are a completely distinct business entity from Siemens AG that merely shares the trademark and a common history; but of course this should not hinder us from getting directly involved in CIP (quite the opposite!). But this also requires some setup time. On Mon, May 18, 2026 at 10:46:55PM +0200, Wolfram Sang wrote: > > If desired, we also would be happy to intensify our support regarding > > reviews or testing to share the maintnance burden if it helps to keep > > nios2 in mainline a bit longer. > > ... but given this, you might want to get added in MAINTAINERS as > reviewer (or even maintainer) for nios2? Besides that your efforts are > already worth it in my book, it would also ensure you get CCed on > patches like this. Then, you are not depending on people like Arnd > putting you in the loop manually. Sure, I'd be glad to do so, but so far I refrained from it as I was a bit unsure about the netiquette (can I simply do so by self-proclamation? At least the git history seems to suggest so...). Best regards, Simon