From: Michal Simek <michal.simek@amd.com>
To: Atul Kumar Pant <atulpant.linux@gmail.com>,
<shubhrajyoti.datta@amd.com>, <sai.krishna.potthuri@amd.com>,
<bp@alien8.de>, <tony.luck@intel.com>, <james.morse@arm.com>,
<mchehab@kernel.org>, <rric@kernel.org>
Cc: <linux-edac@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>, <shuah@kernel.org>
Subject: Re: [PATCH v1] drivers: edac: Drop unnecessary error check for debugfs_create_dir
Date: Fri, 25 Aug 2023 09:31:54 +0200 [thread overview]
Message-ID: <723e803b-6f8b-ceb3-e987-4a6f83d89222@amd.com> (raw)
In-Reply-To: <20230815203826.51792-1-atulpant.linux@gmail.com>
On 8/15/23 22:38, Atul Kumar Pant wrote:
> This patch removes the error checking for debugfs_create_dir.
Avoid using "This patch".
> Even if we get an error from this function, other debugfs APIs will
> handle the error value and doesn't crash in that case. Hence caller can
> safely ignore the errors that occur during the creation of debugfs nodes.
First of all which issue do you have? Did you see that folder is not created?
I am not quite sure if this is the right behavior.
In the code there is
135 if (!parent)
136 parent = edac_debugfs;
It means you are right that if creating ocm folder can fail and properties will
be still created under edac_debugfs but is this the right behavior?
altera_edac/armada_xp_edac/i10nm/i5100/igen6/others are checking return value
that's why I can't see any reason to remove this checking from one driver.
If you want to fix all please send patch for all but I don't think it will
improve situation and it will just hide different issue if creating folder fails.
And debugfs will be disabled in production system anyway.
Thanks,
Michal
next prev parent reply other threads:[~2023-08-25 7:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-15 20:38 [PATCH v1] drivers: edac: Drop unnecessary error check for debugfs_create_dir Atul Kumar Pant
2023-08-25 7:31 ` Michal Simek [this message]
2023-08-28 13:35 ` Atul Kumar Pant
2023-08-28 14:00 ` Michal Simek
2023-08-31 4:20 ` Atul Kumar Pant
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=723e803b-6f8b-ceb3-e987-4a6f83d89222@amd.com \
--to=michal.simek@amd.com \
--cc=atulpant.linux@gmail.com \
--cc=bp@alien8.de \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=rric@kernel.org \
--cc=sai.krishna.potthuri@amd.com \
--cc=shuah@kernel.org \
--cc=shubhrajyoti.datta@amd.com \
--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