From: Anju T Sudhakar <anju@linux.vnet.ibm.com>
To: "Oliver O'Halloran" <oohall@gmail.com>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH] platform/powernv: Avoid re-registration of imc debugfs directory
Date: Wed, 21 Aug 2019 11:07:14 +0530 [thread overview]
Message-ID: <94672ed1-59fc-3a51-658d-364481418d8c@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAOSf1CGj1k3nmfBYp9-TWo+V4sbLRXBcFzrbq25hm2YWtW4MWA@mail.gmail.com>
Hi,
On 8/21/19 10:16 AM, Oliver O'Halloran wrote:
> On Wed, Aug 21, 2019 at 2:10 PM Anju T Sudhakar <anju@linux.vnet.ibm.com> wrote:
>> export_imc_mode_and_cmd() function which creates the debugfs interface for
>> imc-mode and imc-command, is invoked when each nest pmu units is
>> registered.
>> When the first nest pmu unit is registered, export_imc_mode_and_cmd()
>> creates 'imc' directory under `/debug/powerpc`. In the subsequent
>> invocations debugfs_create_dir() function returns, since the directory
>> already exists.
>>
>> The recent commit <c33d442328f55> (debugfs: make error message a bit more
>> verbose), throws a warning if we try to invoke `debugfs_create_dir()`
>> with an already existing directory name.
>>
>> Address this warning by lookup for an existing 'imc' directory,
>> and do not invoke debugfs_create_dir(), if the debugfs interface for
>> imc already exists.
>>
>> This patch is based on:
>> https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-July/192979.html
>>
>> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
>> Tested-by: Nageswara R Sastry <rnsastry@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/platforms/powernv/opal-imc.c | 13 +++++++++----
>> 1 file changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/powernv/opal-imc.c b/arch/powerpc/platforms/powernv/opal-imc.c
>> index e04b20625cb9..fc2f0e60a44d 100644
>> --- a/arch/powerpc/platforms/powernv/opal-imc.c
>> +++ b/arch/powerpc/platforms/powernv/opal-imc.c
>> @@ -55,14 +55,19 @@ static void export_imc_mode_and_cmd(struct device_node *node,
>> static u64 loc, *imc_mode_addr, *imc_cmd_addr;
>> char mode[16], cmd[16];
>> u32 cb_offset;
>> + struct dentry *dir = NULL;
>> struct imc_mem_info *ptr = pmu_ptr->mem_info;
>>
>> +
>> + /* Return, if 'imc' interface already exists */
>> + dir = debugfs_lookup("imc", powerpc_debugfs_root);
>> + if (dir) {
>> + dput(dir);
>> + return;
>> + }
>> imc_debugfs_parent = debugfs_create_dir("imc", powerpc_debugfs_root);
> Is there a reason why we create the debugfs directory here and not in
> opal_imc_counters_probe()? There's logic to remove the debugfs
> directory in _probe() already so it seems like a more natural place to
> it.
>
Good point. But we can only create the parent directory,
i.e 'imc' directory in `_probe()` function and the entries can be
created only here. The reason is, this debugfs entries are only for
IMC nest units. So, to get the imc mode and command values from
the nest memory region we need the relevant offsets from the control
block structure.
Since imc_get_mem_addr_nest() function reads this address
for each chip, we invoke the function to create the debugfs
entries after this values are populated(i.e export_imc_mode_and_cmd() in
invoked by
imc_get_mem_addr_nest()).
Also, if we create the parent directory in `_probe()` function,
we need to track whether the entries(i.e imc_cmd and imc_mode) are
created or not.
Regards,
Anju
next prev parent reply other threads:[~2019-08-21 5:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-21 4:09 [PATCH] platform/powernv: Avoid re-registration of imc debugfs directory Anju T Sudhakar
2019-08-21 4:46 ` Oliver O'Halloran
2019-08-21 5:37 ` Anju T Sudhakar [this message]
2019-08-21 6:08 ` Oliver O'Halloran
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=94672ed1-59fc-3a51-658d-364481418d8c@linux.vnet.ibm.com \
--to=anju@linux.vnet.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=oohall@gmail.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).