linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Huacai Chen <chenhuacai@loongson.cn>
Cc: Arnd Bergmann <arnd@arndb.de>, Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Airlie <airlied@linux.ie>, Jonathan Corbet <corbet@lwn.net>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Xuefeng Li <lixuefeng@loongson.cn>,
	Yanteng Si <siyanteng@loongson.cn>,
	Huacai Chen <chenhuacai@gmail.com>,
	Jiaxun Yang <jiaxun.yang@flygoat.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	linux-efi <linux-efi@vger.kernel.org>
Subject: Re: [PATCH V3 09/22] LoongArch: Add boot and setup routines
Date: Fri, 17 Sep 2021 10:11:24 +0200	[thread overview]
Message-ID: <CAK8P3a0BkYBoBh37YyZ1HU4f1thL6ckJR0MZhbkhpKanVK1WcQ@mail.gmail.com> (raw)
In-Reply-To: <20210917035736.3934017-10-chenhuacai@loongson.cn>

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

       reply	other threads:[~2021-09-17  8:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210917035736.3934017-1-chenhuacai@loongson.cn>
     [not found] ` <20210917035736.3934017-10-chenhuacai@loongson.cn>
2021-09-17  8:11   ` Arnd Bergmann [this message]
2021-09-18  4:54     ` [PATCH V3 09/22] LoongArch: Add boot and setup routines Huacai Chen

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=CAK8P3a0BkYBoBh37YyZ1HU4f1thL6ckJR0MZhbkhpKanVK1WcQ@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=airlied@linux.ie \
    --cc=akpm@linux-foundation.org \
    --cc=ardb@kernel.org \
    --cc=chenhuacai@gmail.com \
    --cc=chenhuacai@loongson.cn \
    --cc=corbet@lwn.net \
    --cc=jiaxun.yang@flygoat.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lixuefeng@loongson.cn \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=siyanteng@loongson.cn \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).