linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Avadhut Naik <avadnaik@amd.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: rafael@kernel.org, lenb@kernel.org, linux-acpi@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, yazen.ghannam@amd.com,
	alexey.kardashevskiy@amd.com, linux-kernel@vger.kernel.org,
	Avadhut Naik <Avadhut.Naik@amd.com>
Subject: [RFC PATCH v3 0/3] Add support for Vendor Defined Error Types in Einj Module
Date: Tue, 13 Jun 2023 17:34:07 -0500	[thread overview]
Message-ID: <f9e8243d-78e2-4aa1-e6f2-5ac2a8c1745d@amd.com> (raw)
In-Reply-To: <2023061341-anything-unlimited-cb62@gregkh>



On 6/13/2023 03:01, Greg KH wrote:
> On Mon, Jun 12, 2023 at 09:51:36PM +0000, Avadhut Naik wrote:
>> This patchset adds support for Vendor Defined Error types in the einj
>> module by exporting a binary blob file in module's debugfs directory.
>> Userspace tools can write OEM Defined Structures into the blob file as
>> part of injecting Vendor defined errors.
>>
>> The first patch refactors available_error_type_show() function to ensure
>> all errors supported by the platform are output through einj module's
>> available_error_type file in debugfs.
>>
>> The second patch adds a write callback for binary blobs created through
>> debugfs_create_blob() API.
>>
>> The third adds the required support i.e. establishing the memory mapping
>> and exporting it through debugfs blob file for Vendor-defined Error types.
>>
>> Changes in v2:
>>  - Split the v1 patch, as was recommended, to have a separate patch for
>> changes in debugfs.
>>  - Refactored available_error_type_show() function into a separate patch.
>>  - Changed file permissions to octal format to remove checkpatch warnings.
>>
>> Changes in v3:
>>  - Use BIT macro for generating error masks instead of hex values since
>> ACPI spec uses bit numbers.
>>  - Handle the corner case of acpi_os_map_iomem() returning NULL through
>> a local variable to a store the size of OEM defined data structure.
>>
>> Avadhut Naik (3):
>>   ACPI: APEI: EINJ: Refactor available_error_type_show()
>>   fs: debugfs: Add write functionality to debugfs blobs
>>   ACPI: APEI: EINJ: Add support for vendor defined error types
>>
>>  drivers/acpi/apei/einj.c | 67 +++++++++++++++++++++++++++-------------
>>  fs/debugfs/file.c        | 28 ++++++++++++++---
>>  2 files changed, 69 insertions(+), 26 deletions(-)
>>
>> -- 
>> 2.34.1
>>
> 
> Why is a RFC series at v3?  What is left to be done with it to make you
> confident that it can be merged?
> 
	Wasn't very confident of the debugfs changes since the binary blobs
created through debugfs_create_blob() have been read-only for a considerable
amount of time. Was wondering if there were some known issues in making them
writable. So, wanted to seek opinion on the changes while also incorporating
the feedback received. Having said that, since you confirmed that you are okay
with the debugfs changes, will remove the RFC tag in subsequent revision.
Apologies for the confusion and inconvenience caused, if any.

> I almost never review RFC patches as obviously the submitter doesn't
> think it is good enough to be reviewed, and hundreds of other patches in
> my review queue are from people who think they are ready to be merged,
> so this puts your stuff always at the bottom of the list...
> 
> When submitting something with "RFC" ask what type of comments you are
> looking for and why you do not think this is ready yet, otherwise we
> have no idea...
>
	Thank you so much for patiently clearing that up! Will surely keep
this in mind for the next time.
 
Thanks,
Avadhut Naik

> thanks,
> 
> greg k-h

-- 


      reply	other threads:[~2023-06-13 22:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-12 21:51 [RFC PATCH v3 0/3] Add support for Vendor Defined Error Types in Einj Module Avadhut Naik
2023-06-12 21:51 ` [RFC PATCH v3 1/3] ACPI: APEI: EINJ: Refactor available_error_type_show() Avadhut Naik
2023-06-12 21:51 ` [RFC PATCH v3 2/3] fs: debugfs: Add write functionality to debugfs blobs Avadhut Naik
2023-06-13  7:59   ` Greg KH
2023-06-13 10:05     ` Alexey Kardashevskiy
2023-06-13 10:22       ` Greg KH
2023-06-13 22:35         ` Avadhut Naik
2023-06-12 21:51 ` [RFC PATCH v3 3/3] ACPI: APEI: EINJ: Add support for vendor defined error types Avadhut Naik
2023-06-13  8:01 ` [RFC PATCH v3 0/3] Add support for Vendor Defined Error Types in Einj Module Greg KH
2023-06-13 22:34   ` Avadhut Naik [this message]

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=f9e8243d-78e2-4aa1-e6f2-5ac2a8c1745d@amd.com \
    --to=avadnaik@amd.com \
    --cc=Avadhut.Naik@amd.com \
    --cc=alexey.kardashevskiy@amd.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=yazen.ghannam@amd.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).