On Thu, Feb 17, 2022 at 2:55 AM Sunil V L sunilvl@ventanamicro.com wrote:
On Mon, Feb 14, 2022 at 12:09:05PM +0100, Andreas Schwab wrote:
On Feb 14 2022, Heinrich Schuchardt wrote:
On 2/14/22 11:15, Andreas Schwab wrote:
On Feb 14 2022, Heinrich Schuchardt wrote:
set_boot_hartid() implies that the caller can change the boot hart ID. As this is not a case this name obviously would be a misnomer.
initialize_boot_hartid would fit better.
Another misnomer.
But the best fit so far.
Can we use the name init_boot_hartid_from_fdt()? While I understand Heinrich's point, I think since we have "_from_fdt", this may be fine.
init_boot_hartid_from_fdt or parse_boot_hartid_from_fdt
are definitely much better than the current one.
I didn't rename the function since it was not recommended to do multiple things in a "Fix" patch. If we can consider this as not very serious issue which needs a "Fix" patch, then I can combine this patch with the RISCV_EFI_BOOT_PROTOCOL patch series.
IMHO, it is okay to include this in the RISCV_EFI_BOOT_PROTOCOL series as we are not going to have hartid U32_MAX in a few months :)
Hi Ard, let me know your suggestion on how to proceed with this.
Thanks Sunil
-- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."