Re: [PATCH V3 09/22] LoongArch: Add boot and setup routines

Re: [PATCH V3 09/22] LoongArch: Add boot and setup routines

[Arnd Bergmann]

On Fri, Sep 17, 2021 at 5:57 AM Huacai Chen <chenhuacai@loongson.cn> wrote:
> This patch adds basic boot, setup and reset routines for LoongArch.
> LoongArch uses UEFI-based firmware and uses ACPI as the boot protocol.

This needs to be reviewed by the maintainers for the EFI and ACPI subsystems,
I added them to Cc here. If you add lines like

Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi@vger.kernel.org

in the patch description before your Signed-off-by, then git-send-email will
Cc them automatically without you having to spam them with the entire series.

In particular, I know that Ard previously complained that you did not use the
EFI boot protocol correctly, and I want to make sure that he's happy with the
final version.

> +static ssize_t boardinfo_show(struct kobject *kobj,
> +                             struct kobj_attribute *attr, char *buf)
> +{
> +       return sprintf(buf,
> +               "BIOS Information\n"
> +               "Vendor\t\t\t: %s\n"
> +               "Version\t\t\t: %s\n"
> +               "ROM Size\t\t: %d KB\n"
> +               "Release Date\t\t: %s\n\n"
> +               "Board Information\n"
> +               "Manufacturer\t\t: %s\n"
> +               "Board Name\t\t: %s\n"
> +               "Family\t\t\t: LOONGSON64\n\n",
> +               b_info.bios_vendor, b_info.bios_version,
> +               b_info.bios_size, b_info.bios_release_date,
> +               b_info.board_vendor, b_info.board_name);
> +}
> +
> +static struct kobj_attribute boardinfo_attr = __ATTR(boardinfo, 0444,
> +                                                    boardinfo_show, NULL);
> +
> +static int __init boardinfo_init(void)
> +{
> +       if (!efi_kobj)
> +               return -EINVAL;
> +
> +       return sysfs_create_file(efi_kobj, &boardinfo_attr.attr);
> +}
> +late_initcall(boardinfo_init);

I see you have documented this interface for your mips machines,
but nothing else uses it.

I think some of this information should be part of the soc_device,
either in addition to, or in place of this sysfs file.

Isn't there an existing method to do this on x86/arm/ia64 machines?

> +static int constant_set_state_periodic(struct clock_event_device *evt)
> +{
> +       unsigned long period;
> +       unsigned long timer_config;
> +
> +       raw_spin_lock(&state_lock);
> +
> +       period = const_clock_freq / HZ;
> +       timer_config = period & CSR_TCFG_VAL;
> +       timer_config |= (CSR_TCFG_PERIOD | CSR_TCFG_EN);
> +       csr_writeq(timer_config, LOONGARCH_CSR_TCFG);
> +
> +       raw_spin_unlock(&state_lock);

I see this pattern in a couple of places, using a spinlock or raw_spinlock
to guard MMIO access, but on many architectures a register write is
not serialized by the following spin_unlock, unless you insert another
read from the same address in there. E.g. on PCIe, writes are always
posted and it would not work.

Can you confirm that it works correctly on CSR registers in loongarch?

         Arnd

Re: [PATCH V3 09/22] LoongArch: Add boot and setup routines

[Huacai Chen]

Hi, Arnd,

On Fri, Sep 17, 2021 at 4:11 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Fri, Sep 17, 2021 at 5:57 AM Huacai Chen <chenhuacai@loongson.cn> wrote:
> > This patch adds basic boot, setup and reset routines for LoongArch.
> > LoongArch uses UEFI-based firmware and uses ACPI as the boot protocol.
>
> This needs to be reviewed by the maintainers for the EFI and ACPI subsystems,
> I added them to Cc here. If you add lines like
>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: linux-efi@vger.kernel.org
>
> in the patch description before your Signed-off-by, then git-send-email will
> Cc them automatically without you having to spam them with the entire series.
OK, I will add them.

>
> In particular, I know that Ard previously complained that you did not use the
> EFI boot protocol correctly, and I want to make sure that he's happy with the
> final version.
The Correct way means efistub?  We have investigated for some time and
found that it is very difficult. E.g., our BIOS team said that they
cannot get GOP drivers for graphics cards.

>
> > +static ssize_t boardinfo_show(struct kobject *kobj,
> > +                             struct kobj_attribute *attr, char *buf)
> > +{
> > +       return sprintf(buf,
> > +               "BIOS Information\n"
> > +               "Vendor\t\t\t: %s\n"
> > +               "Version\t\t\t: %s\n"
> > +               "ROM Size\t\t: %d KB\n"
> > +               "Release Date\t\t: %s\n\n"
> > +               "Board Information\n"
> > +               "Manufacturer\t\t: %s\n"
> > +               "Board Name\t\t: %s\n"
> > +               "Family\t\t\t: LOONGSON64\n\n",
> > +               b_info.bios_vendor, b_info.bios_version,
> > +               b_info.bios_size, b_info.bios_release_date,
> > +               b_info.board_vendor, b_info.board_name);
> > +}
> > +
> > +static struct kobj_attribute boardinfo_attr = __ATTR(boardinfo, 0444,
> > +                                                    boardinfo_show, NULL);
> > +
> > +static int __init boardinfo_init(void)
> > +{
> > +       if (!efi_kobj)
> > +               return -EINVAL;
> > +
> > +       return sysfs_create_file(efi_kobj, &boardinfo_attr.attr);
> > +}
> > +late_initcall(boardinfo_init);
>
> I see you have documented this interface for your mips machines,
> but nothing else uses it.
>
> I think some of this information should be part of the soc_device,
> either in addition to, or in place of this sysfs file.
This file list something describe the motherboard, which is different
from SOC. These information are used by some user programs.

>
> Isn't there an existing method to do this on x86/arm/ia64 machines?
>
> > +static int constant_set_state_periodic(struct clock_event_device *evt)
> > +{
> > +       unsigned long period;
> > +       unsigned long timer_config;
> > +
> > +       raw_spin_lock(&state_lock);
> > +
> > +       period = const_clock_freq / HZ;
> > +       timer_config = period & CSR_TCFG_VAL;
> > +       timer_config |= (CSR_TCFG_PERIOD | CSR_TCFG_EN);
> > +       csr_writeq(timer_config, LOONGARCH_CSR_TCFG);
> > +
> > +       raw_spin_unlock(&state_lock);
>
> I see this pattern in a couple of places, using a spinlock or raw_spinlock
> to guard MMIO access, but on many architectures a register write is
> not serialized by the following spin_unlock, unless you insert another
> read from the same address in there. E.g. on PCIe, writes are always
> posted and it would not work.
>
> Can you confirm that it works correctly on CSR registers in loongarch?
CSR on LoongArch doesn't need any barrier or flush operations,
spinlock here is used to protect the whole "read, modify and write".

Huacai
>
>          Arnd

Re: [PATCH V3 18/22] LoongArch: Add PCI controller support

[Arnd Bergmann]

On Fri, Sep 17, 2021 at 5:57 AM Huacai Chen <chenhuacai@loongson.cn> wrote:
>
> Loongson64 based systems are PC-like systems which use PCI/PCIe as its
> I/O bus, This patch adds the PCI host controller support for LoongArch.
>
> Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn>
> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>

As discussed before, I think the PCI support should not be part of the
architecture code or this patch series. The headers are ok, but the pci.c
and acpi.c files have nothing loongarch specific in them, and you clearly
just copied most of this from arm64 or x86.

What I would suggest you do instead is:

- start a separate patch series, addressed to the ACPI, PCI host driver
  and ARM64 maintainers.

- Move all the bits you need from arch/{arm64,ia64,x86} into
  drivers/acpi/pci/pci_root.c, duplicating them with #if/#elif/#else
  where they are too different, making the #else path the
  default that can be shared with loongarch.

- Move the bits from pci_root_info/acpi_pci_root_info that are
  always needed into struct pci_host_bridge, with an
  #ifdef CONFIG_ACPI where appropriate.

- Simplify as much as you can easily do.

        Arnd

Re: [PATCH V3 18/22] LoongArch: Add PCI controller support

[Huacai Chen]

Hi, Arnd,

On Fri, Sep 17, 2021 at 5:02 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Fri, Sep 17, 2021 at 5:57 AM Huacai Chen <chenhuacai@loongson.cn> wrote:
> >
> > Loongson64 based systems are PC-like systems which use PCI/PCIe as its
> > I/O bus, This patch adds the PCI host controller support for LoongArch.
> >
> > Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn>
> > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
>
> As discussed before, I think the PCI support should not be part of the
> architecture code or this patch series. The headers are ok, but the pci.c
> and acpi.c files have nothing loongarch specific in them, and you clearly
> just copied most of this from arm64 or x86.
In V2 part of the PCI code (pci-loongson.c) has moved to
drivers/pci/controllers. For pci.c and acpi.c, I agree that "the thing
should be like that", but have some different ideas about "the way to
arrive at that". In my opinion, we can let this series be merged at
first, and then do another series to "restructure the files and move
common parts to the drivers directory". That way looks more natural to
me (doing the other series at first may block the whole thing).

>
> What I would suggest you do instead is:
>
> - start a separate patch series, addressed to the ACPI, PCI host driver
>   and ARM64 maintainers.
>
> - Move all the bits you need from arch/{arm64,ia64,x86} into
>   drivers/acpi/pci/pci_root.c, duplicating them with #if/#elif/#else
>   where they are too different, making the #else path the
>   default that can be shared with loongarch.
>
> - Move the bits from pci_root_info/acpi_pci_root_info that are
>   always needed into struct pci_host_bridge, with an
>   #ifdef CONFIG_ACPI where appropriate.
>
> - Simplify as much as you can easily do.
>
>         Arnd

Re: [PATCH V3 18/22] LoongArch: Add PCI controller support

[Bjorn Helgaas]

On Sat, Sep 18, 2021 at 03:36:52PM +0800, Huacai Chen wrote:
> On Fri, Sep 17, 2021 at 5:02 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Fri, Sep 17, 2021 at 5:57 AM Huacai Chen <chenhuacai@loongson.cn> wrote:
> > >
> > > Loongson64 based systems are PC-like systems which use PCI/PCIe as its
> > > I/O bus, This patch adds the PCI host controller support for LoongArch.
> > >
> > > Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn>
> > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> >
> > As discussed before, I think the PCI support should not be part of the
> > architecture code or this patch series. The headers are ok, but the pci.c
> > and acpi.c files have nothing loongarch specific in them, and you clearly
> > just copied most of this from arm64 or x86.
>
> In V2 part of the PCI code (pci-loongson.c) has moved to
> drivers/pci/controllers. For pci.c and acpi.c, I agree that "the thing
> should be like that", but have some different ideas about "the way to
> arrive at that". In my opinion, we can let this series be merged at
> first, and then do another series to "restructure the files and move
> common parts to the drivers directory". That way looks more natural to
> me (doing the other series at first may block the whole thing).
> 
> > What I would suggest you do instead is:
> >
> > - start a separate patch series, addressed to the ACPI, PCI host driver
> >   and ARM64 maintainers.
> >
> > - Move all the bits you need from arch/{arm64,ia64,x86} into
> >   drivers/acpi/pci/pci_root.c, duplicating them with #if/#elif/#else
> >   where they are too different, making the #else path the
> >   default that can be shared with loongarch.
> >
> > - Move the bits from pci_root_info/acpi_pci_root_info that are
> >   always needed into struct pci_host_bridge, with an
> >   #ifdef CONFIG_ACPI where appropriate.
> >
> > - Simplify as much as you can easily do.

I would love to see this done.

But we already have this kind of redundant code for arm64/ia64/x86.
Arguably, we should have refactored it for ia64 or arm64.  It's
unfortunate to add loongarch to that list, but why should we penalize
loongarch more than arm64 and ia64?

Bjorn

Re: [PATCH V3 18/22] LoongArch: Add PCI controller support

[Arnd Bergmann]

On Wed, Sep 22, 2021 at 12:36 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Sat, Sep 18, 2021 at 03:36:52PM +0800, Huacai Chen wrote:
> > On Fri, Sep 17, 2021 at 5:02 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Fri, Sep 17, 2021 at 5:57 AM Huacai Chen <chenhuacai@loongson.cn> wrote:
> > > >
> > > > Loongson64 based systems are PC-like systems which use PCI/PCIe as its
> > > > I/O bus, This patch adds the PCI host controller support for LoongArch.
> > > >
> > > > Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn>
> > > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > >
> > > As discussed before, I think the PCI support should not be part of the
> > > architecture code or this patch series. The headers are ok, but the pci.c
> > > and acpi.c files have nothing loongarch specific in them, and you clearly
> > > just copied most of this from arm64 or x86.
> >
> > In V2 part of the PCI code (pci-loongson.c) has moved to
> > drivers/pci/controllers. For pci.c and acpi.c, I agree that "the thing
> > should be like that", but have some different ideas about "the way to
> > arrive at that". In my opinion, we can let this series be merged at
> > first, and then do another series to "restructure the files and move
> > common parts to the drivers directory". That way looks more natural to
> > me (doing the other series at first may block the whole thing).

It should not hold up the current series, but I think you should be able
to do both sides (architecture code and pci support) independently
at the same time.

> > > What I would suggest you do instead is:
> > >
> > > - start a separate patch series, addressed to the ACPI, PCI host driver
> > >   and ARM64 maintainers.
> > >
> > > - Move all the bits you need from arch/{arm64,ia64,x86} into
> > >   drivers/acpi/pci/pci_root.c, duplicating them with #if/#elif/#else
> > >   where they are too different, making the #else path the
> > >   default that can be shared with loongarch.
> > >
> > > - Move the bits from pci_root_info/acpi_pci_root_info that are
> > >   always needed into struct pci_host_bridge, with an
> > >   #ifdef CONFIG_ACPI where appropriate.
> > >
> > > - Simplify as much as you can easily do.
>
> I would love to see this done.
>
> But we already have this kind of redundant code for arm64/ia64/x86.
> Arguably, we should have refactored it for ia64 or arm64.  It's
> unfortunate to add loongarch to that list, but why should we penalize
> loongarch more than arm64 and ia64?

There is usually something like this that comes up when support for a
new architecture gets posted and it duplicates some code from other
architectures.

When I review the port, I try to come to a reasonable balance asking
the submitters to clean up some aspect of the common code base
so they and everyone afterwards is able to use more shared
infrastructure without duplication. This is clearly a different area
every time, but I think the ACPI PCI code is an obvious thing to
ask for cleaning up this time, as there are only three existing users.

We could probably have done a better job for the arm64 version,
but even getting that working was enough of a mess (initially
you had only ACPI or PCI but not both together), and there
were other problems with the architecture port that needed sorting
out at the time.

I can definitely offer to help plan this part a little bit better, but
I actually hope it's not all that much work.

        Arnd