linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Punit Agrawal <punit.agrawal@arm.com>
To: "Luck\, Tony" <tony.luck@intel.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>, Boris Petkov <bp@suse.de>,
	Tyler Baicar <tbaicar@codeaurora.org>,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ACPI/APEI: Add BERT data driver
Date: Wed, 16 Aug 2017 14:14:12 +0100	[thread overview]
Message-ID: <87a82zpsd7.fsf@e105922-lin.cambridge.arm.com> (raw)
In-Reply-To: <20170815211556.nnnnbtlvorgc3ijh@intel.com> (Tony Luck's message of "Tue, 15 Aug 2017 14:15:57 -0700")

"Luck, Tony" <tony.luck@intel.com> writes:

> On Tue, Aug 15, 2017 at 11:22:06AM +0100, Punit Agrawal wrote:
>> There is already a bert driver which prints the error record. Would it
>> make sense to integrate the character device there instead of creating a
>> new driver?
>
> Like this?  The source code is smaller. But it doesn't offer the option to unload
> the driver and unmap the BERT data region after you have retrieved the error record.

Is there any benefit in being able to unload the driver in real world
usage?

It should be possible to convert the existing driver into a loadable
module - thought that means re-printing the error records to the kernel
log if the module is re-loaded. Not sure if that breaks any existing
usecases.

One thing I missed commenting on in the previous version -

Have you thought of exposing the error records via /sys/firmware/acpi?
The tables are already exposed there and as BERT is part of ACPI
logically that's a better fit compared to a misc device.

>
> Either looks plausible to me (but I'm hardly a disinterested party).
>
> Votes?
>
> -Tony
>
> From cbeabf2d83fe91eebd960cd5cc1b61faaeed1441 Mon Sep 17 00:00:00 2001
> From: Tony Luck <tony.luck@intel.com>
> Date: Tue, 15 Aug 2017 13:48:28 -0700
> Subject: [PATCH] ACPI: APEI: Extend BERT driver to provide a character device
>  to access data
>
> The BERT table simply provides the size and address of the error
> record in BIOS reserved memory. Currently this driver decodes the
> record to the console log. But other users of BERT may want to access
> the full binary record.
>
> In an earlier age we might have used /dev/mem to retrieve this error
> record, but many systems disable /dev/mem for security reasons.
>
> Extend this driver to provide read-only access to the data via a character
> special device "/dev/bert-data".
>
> Cc: Len Brown <lenb@kernel.org>
> Cc: Boris Petkov <bp@suse.de>
> Cc: Tyler Baicar <tbaicar@codeaurora.org>
> Cc: Punit Agrawal <punit.agrawal@arm.com>
> Cc: linux-acpi@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Tony Luck <tony.luck@intel.com>
>
> v2: (suggested by Punit Agrawal) don't make a whole new driver, merge
>     this functionality into the existing BERT driver.
> ---
>  drivers/acpi/apei/bert.c | 45 ++++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 42 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/apei/bert.c b/drivers/acpi/apei/bert.c
> index 12771fcf0417..9bc39b1bffde 100644
> --- a/drivers/acpi/apei/bert.c
> +++ b/drivers/acpi/apei/bert.c
> @@ -26,12 +26,16 @@
>  #include <linux/init.h>
>  #include <linux/acpi.h>
>  #include <linux/io.h>
> +#include <linux/miscdevice.h>
> +#include <linux/uaccess.h>
>  
>  #include "apei-internal.h"
>  
>  #undef pr_fmt
>  #define pr_fmt(fmt) "BERT: " fmt
>  
> +static __iomem void *bert_data;
> +static unsigned int region_len;
>  static int bert_disable;
>  
>  static void __init bert_print_all(struct acpi_bert_region *region,
> @@ -95,12 +99,45 @@ static int __init bert_check_table(struct acpi_table_bert *bert_tab)
>  	return 0;
>  }
>  
> +static int bert_chrdev_open(struct inode *inode, struct file *file)
> +{
> +	if (file->f_flags & (O_WRONLY | O_RDWR))
> +		return -EPERM;
> +	inode->i_size = region_len;
> +	return 0;
> +}
> +
> +static ssize_t bert_chrdev_read(struct file *filp, char __user *ubuf,
> +				size_t usize, loff_t *off)
> +{
> +	if (*off > region_len)
> +		return -EINVAL;
> +	if (*off + usize > region_len)
> +		usize = region_len - *off;
> +	if (copy_to_user(ubuf, bert_data + *off, usize))
> +		return -EFAULT;
> +	*off += usize;
> +	return usize;
> +}
> +
> +static const struct file_operations bert_chrdev_ops = {
> +	.open		= bert_chrdev_open,
> +	.read		= bert_chrdev_read,
> +	.llseek		= default_llseek,
> +};
> +
> +static struct miscdevice bert_chrdev_device = {
> +	.minor		= MISC_DYNAMIC_MINOR,
> +	.name		= "bert-data",
> +	.fops		= &bert_chrdev_ops,
> +	.mode		= 0444,
> +};
> +
>  static int __init bert_init(void)
>  {
> -	struct apei_resources bert_resources;
>  	struct acpi_bert_region *boot_error_region;
> +	struct apei_resources bert_resources;
>  	struct acpi_table_bert *bert_tab;
> -	unsigned int region_len;
>  	acpi_status status;
>  	int rc = 0;
>  
> @@ -139,7 +176,9 @@ static int __init bert_init(void)
>  	boot_error_region = ioremap_cache(bert_tab->address, region_len);
>  	if (boot_error_region) {
>  		bert_print_all(boot_error_region, region_len);
> -		iounmap(boot_error_region);
> +		bert_data = boot_error_region;
> +		if (misc_register(&bert_chrdev_device))
> +			iounmap(boot_error_region);
>  	} else {
>  		rc = -ENOMEM;
>  	}

  reply	other threads:[~2017-08-16 13:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-14 16:56 [PATCH] ACPI/APEI: Add BERT data driver Luck, Tony
2017-08-15 10:22 ` Punit Agrawal
2017-08-15 21:15   ` Luck, Tony
2017-08-16 13:14     ` Punit Agrawal [this message]
2017-08-16 15:22       ` Luck, Tony
2017-08-17 10:25         ` Punit Agrawal
2017-08-17 17:49           ` Luck, Tony
2017-08-17 19:28             ` Rafael J. Wysocki
2017-08-17 20:29               ` Luck, Tony
2017-08-17 20:41                 ` Rafael J. Wysocki
2017-08-17 21:39                   ` [PATCH] ACPI / sysfs: Extend ACPI sysfs to provide access to boot error region Luck, Tony
2017-08-18  0:30                     ` Alan Cox
2017-08-18  2:12                       ` Luck, Tony
2017-08-23 14:56                       ` Luck, Tony
2017-08-29  0:10                         ` Kees Cook
2017-08-29 15:55                           ` Luck, Tony
2017-08-18 17:38                     ` Punit Agrawal
2017-08-18 23:19                       ` [PATCH v4] " Luck, Tony
2017-08-28 20:55                         ` Rafael J. Wysocki

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=87a82zpsd7.fsf@e105922-lin.cambridge.arm.com \
    --to=punit.agrawal@arm.com \
    --cc=bp@suse.de \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=tbaicar@codeaurora.org \
    --cc=tony.luck@intel.com \
    /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).