From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 99C85EB64D9 for ; Fri, 7 Jul 2023 16:07:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232798AbjGGQHU (ORCPT ); Fri, 7 Jul 2023 12:07:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232729AbjGGQHP (ORCPT ); Fri, 7 Jul 2023 12:07:15 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 314611BF4; Fri, 7 Jul 2023 09:07:14 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BEB46619FE; Fri, 7 Jul 2023 16:07:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 41006C433C7; Fri, 7 Jul 2023 16:07:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1688746033; bh=QEScL6yilSc3ZviTbMvKU7KFSvkrD3Pa7MP8T7mfDDE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dw8avhov4Eg5IA9vDOeqV0k2C7KF/9OYCZ/NfWbqADZgVnuk7e1Q+qtrqkHInKieu tvGNBnJMXGLcRxvePqIWTIV+pX1tgRTddXtXSF5hRW8z/isGnKuWMAyUoa523t0Hge 1q9fnMsp33C1btALoA2WWoJe40x0WwFhtO+rgggRPQNNtskg57ItuvOF8XY2HSg+oc U0Ks0QSYMH2DNGSXPw5HJrAssmc6s7BUOyoVfmnJ+qWTVILdGuYSp105liHsVFhkUM /sQi0y7SQ2hKtAKhEjbJZ4u2Y2uMMpTiNgecMdpeX5jk260C3695Psi/ATOpn/9qAT BFS4WP7c3yAsg== Date: Fri, 7 Jul 2023 17:07:05 +0100 From: Conor Dooley To: =?utf-8?B?6JGb5aOr5bu6?= Cc: Sunil V L , Conor Dooley , ron minnich , Palmer Dabbelt , Ard Biesheuvel , cuiyunhui@bytedance.com, jrtc27@jrtc27.com, kernel@esmil.dk, Paul Walmsley , aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org, Mark Rutland , lpieralisi@kernel.org, rafael@kernel.org, lenb@kernel.org, jdelvare@suse.com, yc.hung@mediatek.com, angelogioacchino.delregno@collabora.com, allen-kh.cheng@mediatek.com, pierre-louis.bossart@linux.intel.com, tinghan.shen@mediatek.com, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, weidong.wd@bytedance.com, Dong Wei Subject: Re: [External] Re: [PATCH v3 0/4] Obtain SMBIOS and ACPI entry from FFI Message-ID: <20230707-gargle-enjoyable-f9f7f87fc7ea@spud> References: <20230707-attach-conjuror-306d967347ce@wendy> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3EWyQYVnHmvcjPCl" Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org --3EWyQYVnHmvcjPCl Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey, On Fri, Jul 07, 2023 at 11:56:48PM +0800, =E8=91=9B=E5=A3=AB=E5=BB=BA wrote: > On Fri, Jul 7, 2023 at 8:55=E2=80=AFPM Sunil V L wrote: >=20 > > On Fri, Jul 07, 2023 at 08:05:48PM +0800, =E8=91=9B=E5=A3=AB=E5=BB=BA w= rote: > > > Hi Sunil, > > > > > > From Sunil: > > > IMO, if the question is generic like "Is UEFI mandatory for RISC-V?", > > > the answer will be solid "no" because we can use DT without UEFI. But= if > > > you ask whether UEFI is mandatory for ACPI support on RISC-V, then the > > > answer will be "yes". > > > ---- Why UEFI is mandatory for ACPI support on RISC-V? As we know, o= n X86, > > > ACPI works well without UEFI. Is there any limitation on RISC-V > > > architecture? > > Yes, the limitation is RISC-V can not use IA-PC BIOS. Please see > > section 5.2.5 and 15 in ACPI spec. > > > > I don't have much to add to Ard's reasons. > > > > https://lore.kernel.org/linux-riscv/CAMj1kXFZren0Q19DimwQaETCLz64D4bZQC= 5B2N=3Di3SAWHygkTQ@mail.gmail.com/ > > > I don't think that's the limitation on RISC-V. BTW, how does OSPM find the > RSDP on ARM systems? Does it meet 5.2.5? >=20 > Here are > 1. Purpose: purpose is to provide another option on Firmware Solution; Our > purpose is NOT to ban UEFI. > 2. Both ARM and RISC-V starts from UBOOT solution, and that's close to > coreboot, so we would like to enable flexible and rich ecosystem. > 3. We don't like to push coreboot and UEFI together, so we don't plan to > enable UEFI in coreboot(maybe from Uboot); because that makes the solution > complex. > 4. I think we should fix the request and problem, banning or protecting > something is NOT the goal of us. >=20 > I think the solution is for both RISC-V and ARM, and also it works on X86 > if it's done. > Let me know what the problem and impact is, please. If you are going to keep arguing this, please stop sending top-posted HTML to the mailing list. It makes it impossible for those not in the CC list to follow along. Thanks, Conor. --3EWyQYVnHmvcjPCl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZKg4KQAKCRB4tDGHoIJi 0lY3AP41L09JSLOtY+QPj1ZlQioIBJzEht6NkN01HubykTSJ/wEAuE3fkJOEDEZ7 OvvPsCFCqhBpUQ5yg6m+6Cgpu/1CCAw= =EfKt -----END PGP SIGNATURE----- --3EWyQYVnHmvcjPCl--