linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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


  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).