On Thu, 17 Feb 2022 at 20:47, Atish Patra <atishp@xxxxxxxxxxxxxx> wrote: > > On Thu, Feb 17, 2022 at 2:55 AM Sunil V L <sunilvl@xxxxxxxxxxxxxxxx> 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. > > The patch is fine as it is. I agree that naming is important, but for a helper function that is only used a single time right in the same source file, it doesn't matter that much. I have queued this up now. Thanks, Ard.
