From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id E5117138350 for ; Mon, 30 Mar 2020 21:49:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2DE15E0AFA; Mon, 30 Mar 2020 21:49:24 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id F0065E0AF6 for ; Mon, 30 Mar 2020 21:49:23 +0000 (UTC) Received: from [192.168.1.13] (c-73-173-172-109.hsd1.md.comcast.net [73.173.172.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: kumba) by smtp.gentoo.org (Postfix) with ESMTPSA id 911C634F06B; Mon, 30 Mar 2020 21:49:22 +0000 (UTC) To: gentoo-kernel@lists.gentoo.org From: Joshua Kinard Subject: [gentoo-kernel] sys-kernel/mips-firmware: thoughts? Openpgp: preference=signencrypt Cc: mips@gentoo.org Message-ID: <4c4a9709-fd2a-26d9-a6a3-947c60839bc9@gentoo.org> Date: Mon, 30 Mar 2020 17:49:20 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-kernel@lists.gentoo.org Reply-to: gentoo-kernel@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: a23e6499-f75e-4b96-9769-4900dd8a8943 X-Archives-Hash: 9ad136626d6efaa473382ea8a7ec1b60 For some time now, I've been trying to maintain a patch that kludges the external firmware loader and specific firmware blobs back into the kernel for sys-kernel/mips-sources. This works fine up until 5.6, which seems to have further changed the way that firmware is loaded that breaks my existing patch in a not-so-obvious way. I am not terribly inclined to keep debugging this, so I think it's time to throw in the towel and use external firmware loading. This brings up the issue that frankly, sys-kernel/linux-firmware is overkill for currently-supported MIPS targets. Speaking for just the SGI systems, MIPS literally needs only 4 firmware blobs (1 is critical, 1 optional, the other two are for the future): - acenic/tg2.bin: optional for ACENIC/Tigon II PCI cards - qlogic/1040.bin: required for QLA1040 on SGI IP27, IP30 - qlogic/1280.bin: future use (maybe on SGI IP35?) - qlogic/12160.bin: future use (maybe on SGI IP35?) I wanted to see if there would be any problem with creating a sys-kernel/mips-firmware package to contain, at least initially, these four firmware files from the linux-firmware repo, and install them to either /lib/firmware-mips or /usr/share/mips-firmware (thinking more the latter to avoid polluting /lib any further). These four blobs have not seen updates in years, so I anticipate there being only a single ebuild for sys-kernel/mips-firmware. It'll be versioned like the virtual packages (mips-firmware-1, -2, -3, etc), rather than by datestamp, as the only times a version bump happens is if the firmware blobs ever change or we add/remove a blob. Thoughts/feedback? -- Joshua Kinard Gentoo/MIPS kumba@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic