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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAhV-H60MKs_gCf4ug3ACkXcDg4cGoYEQ=HchJz8+muFkrsJQA@mail.gmail.com>
Date:   Sat, 18 Sep 2021 12:54:52 +0800
From:   Huacai Chen <chenhuacai@...il.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Huacai Chen <chenhuacai@...ngson.cn>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        David Airlie <airlied@...ux.ie>,
        Jonathan Corbet <corbet@....net>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Xuefeng Li <lixuefeng@...ngson.cn>,
        Yanteng Si <siyanteng@...ngson.cn>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        linux-efi <linux-efi@...r.kernel.org>
Subject: Re: [PATCH V3 09/22] LoongArch: Add boot and setup routines

Hi, Arnd,

On Fri, Sep 17, 2021 at 4:11 PM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Fri, Sep 17, 2021 at 5:57 AM Huacai Chen <chenhuacai@...ngson.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@...nel.org>
> Cc: linux-efi@...r.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