All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Atish Patra <atishp@atishpatra.org>,
	Abner Chang <abner.chang@hpe.com>,
	Jessica Clarke <jrtc27@jrtc27.com>,
	Anup Patel <anup@brainfault.org>,
	Palmer Dabbelt <palmer@rivosinc.com>,
	sunil.vl@gmail.com, linux-riscv <linux-riscv@lists.infradead.org>,
	Sunil V L <sunilvl@ventanamicro.com>
Subject: Re: Question regarding "boot-hartid" DT node
Date: Thu, 2 Dec 2021 17:53:46 +0100	[thread overview]
Message-ID: <89d42547-ec36-5f84-88d1-fd65d891488c@canonical.com> (raw)
In-Reply-To: <CAMj1kXGJtMmcXLjHEG8xX0sSFNfdjj4A2_4DPcviEJ3=MARh+w@mail.gmail.com>

On 12/2/21 17:20, Ard Biesheuvel wrote:
> On Thu, 2 Dec 2021 at 16:05, Sunil V L <sunilvl@ventanamicro.com> wrote:
>>
>> Hi All,
>>     I am starting this thread to discuss about the "boot-hartid" DT node
>>     that is being used in RISC-V Linux EFI stub.
>>
>>     As you know, the boot Hart ID is passed in a0 register to the kernel
>>     and hence there is actually no need to pass it via DT. However, since
>>     EFI stub follows EFI application calling conventions, it needs to
>>     know the boot Hart ID so that it can pass it to the proper kernel via
>>     a0. For this issue, the solution was to add "/chosen/boot-hartid" in
>>     DT. Both EDK2 and u-boot append this node in DT.
>>
> 
> I think this was a mistake tbh
> 
>>     But above approach causes issue for ACPI since ACPI initialization
>>     happens late in the proper kernel. Same is true even if we pass this
>>     information via SMBIOS.
>>
> 
> It would be better to define a RISCV specific EFI protocol that the
> stub can call to discover the boot-hartid value. That wat, it can pass
> it directly, without having to rely on firmware tables.

As discovering the current process' hartid is not a UEFI specific task 
SBI would be a better fit.

Best regards

Heinrich

> 
> Note that you don't need any spec changes for this on the ACPI or UEFI side.
> 
>>     Do you have any suggestions what can be done in ACPI case? Can we use
>>     a UEFI variable with RVI specific GUID to pass this information? This
>>     will have the advantage that it can work with either DT or ACPI.
>>     Also, we may not need any UEFI spec update. Do you see any issue with
>>     this approach? Your inputs will be very helpful.
>>
>> Thanks!
>> Sunil


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2021-12-02 16:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-02 15:05 Question regarding "boot-hartid" DT node Sunil V L
2021-12-02 15:09 ` Heinrich Schuchardt
2021-12-02 15:17   ` Sunil V L
2021-12-02 15:52     ` Heinrich Schuchardt
2021-12-02 16:20 ` Ard Biesheuvel
2021-12-02 16:53   ` Heinrich Schuchardt [this message]
2021-12-02 16:58     ` Ard Biesheuvel
2021-12-02 17:04       ` Heinrich Schuchardt
2021-12-02 17:10         ` Ard Biesheuvel
2021-12-02 19:29         ` Atish Patra
2021-12-03 10:13           ` Ard Biesheuvel
2021-12-03 10:53             ` Heinrich Schuchardt
2021-12-03 18:45               ` Heinrich Schuchardt
2021-12-04  0:44                 ` Atish Patra
2021-12-04  1:47                   ` Heinrich Schuchardt
2021-12-04  4:24                     ` Anup Patel
2021-12-04  8:38                       ` Heinrich Schuchardt
2021-12-04 14:00                         ` Anup Patel
2021-12-04 18:34                       ` Atish Patra
2021-12-04 19:03                         ` Heinrich Schuchardt
2021-12-04 19:13                           ` Ard Biesheuvel
2022-01-13  9:44                             ` Sunil V L
2022-01-13  9:50                               ` Ard Biesheuvel
2022-01-13  9:59                                 ` Sunil V L
2022-01-13 10:01                                   ` Ard Biesheuvel
2022-01-18  4:47                                     ` Sunil V L
2021-12-05 13:39                         ` Sunil V L
2021-12-05 15:54                           ` Jessica Clarke
2021-12-05 16:37                             ` Sunil V L
     [not found]                               ` <CAOnJCUJ1jmwj4jrWsL2UnV8Wit_-w2KVnqUxy3gsvzE4ZugHBQ@mail.gmail.com>
2021-12-06  4:26                                 ` Sunil V L

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=89d42547-ec36-5f84-88d1-fd65d891488c@canonical.com \
    --to=heinrich.schuchardt@canonical.com \
    --cc=abner.chang@hpe.com \
    --cc=anup@brainfault.org \
    --cc=ardb@kernel.org \
    --cc=atishp@atishpatra.org \
    --cc=jrtc27@jrtc27.com \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@rivosinc.com \
    --cc=sunil.vl@gmail.com \
    --cc=sunilvl@ventanamicro.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.