public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lu Baolu <baolu.lu@linux.intel.com>
To: "Mehta, Sohil" <sohil.mehta@intel.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>
Cc: "Yu, Fenghua" <fenghua.yu@intel.com>,
	"Shankar, Ravi V" <ravi.v.shankar@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Kammela, Gayatri" <gayatri.kammela@intel.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>,
	"Shevchenko, Andriy" <andriy.shevchenko@intel.com>
Subject: Re: [PATCH v3 2/6] iommu/vt-d: Add Intel IOMMU debugfs to show context internals
Date: Wed, 13 Dec 2017 10:28:45 +0800	[thread overview]
Message-ID: <5A30905D.9000303@linux.intel.com> (raw)
In-Reply-To: <1512678006.120652.17.camel@intel.com>

Hi,

Sorry for late reply.

On 12/08/2017 04:19 AM, Mehta, Sohil wrote:
> On Wed, 2017-12-06 at 16:16 +0800, Lu Baolu wrote:
>> Hi,
>>
>> On 12/06/2017 11:43 AM, Sohil Mehta wrote:
>>> From: Gayatri Kammela <gayatri.kammela@intel.com>
>>>
>>>  
>>> +	seq_printf(m, "%s Context table entries for Bus: %d\n",
>>> +		   ext ? "Lower" : "", bus);
>>> +	seq_printf(m, "[entry]\tDID :B :D .F\tLow\t\tHigh\n");
>> WARNING: Prefer seq_puts to seq_printf
>> #119: FILE: drivers/iommu/intel-iommu-debug.c:59:
>> +    seq_printf(m, "[entry]\tDID :B :D .F\tLow\t\tHigh\n");
>>
>> (caught by checkpatch.pl)
>>
> Hi Lu,
>
> We'll fix this and the other checkpatch.pl warnings.
>
>
>>> +
>>> +static void root_tbl_entry_show(struct seq_file *m, void *unused,
>> Why do you define the "unused" parameter which will never been used?
>> The same questions to other show functions.
>>
> Some functions in our code that are registered with seq_file needed to
> have an unused parameter since seq_file.h defines the show function as:
> 	int (*show) (struct seq_file *m, void *v);
>
> But a lot of other functions including the one you pointed don't need
> to have the unused parameter. We'll remove it from those.
>
>
>>> +void __init intel_iommu_debugfs_init(void)
>>> +{
>>> +	struct dentry *iommu_debug_root;
>>> +
>>> +	iommu_debug_root = debugfs_create_dir("intel_iommu",
>>> NULL);
>>> +
>>> +	if (!iommu_debug_root) {
>>> +		pr_err("can't create debugfs dir\n");
>> I don't think we need a pr_err() here. System works well even
>> debugfs_create_dir() returns NULL.
>>
>> This is same to all pr_err() in this file.
>>
> Would the recommendation be to use pr_warn instead of pr_err or should
> we entirely skip the message altogether?

Greg ever educated me about the use of debugfs_ functions in
this thread.

https://spinics.net/lists/linux-usb/msg159384.html

At least we should avoid the warning/error messages here.

Best regards,
Lu Baolu

  reply	other threads:[~2017-12-13  2:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-06  3:43 [PATCH v3 0/6] Intel IOMMU debugfs support Sohil Mehta
2017-12-06  3:43 ` [PATCH v3 1/6] iommu/vt-d: Add debugfs support for Intel IOMMU internals Sohil Mehta
2017-12-06  3:43 ` [PATCH v3 2/6] iommu/vt-d: Add Intel IOMMU debugfs to show context internals Sohil Mehta
2017-12-06  8:16   ` Lu Baolu
2017-12-07 20:19     ` Mehta, Sohil
2017-12-13  2:28       ` Lu Baolu [this message]
2017-12-13  4:30         ` Mehta, Sohil
2017-12-06  3:43 ` [PATCH v3 3/6] iommu/vt-d: Add Intel IOMMU debugfs to show extended " Sohil Mehta
2017-12-06  8:17   ` Lu Baolu
2017-12-07 20:30     ` Mehta, Sohil
2017-12-06  8:17   ` Lu Baolu
2017-12-06  3:43 ` [PATCH v3 4/6] iommu/vt-d: Add debugfs extension to show register contents Sohil Mehta
2017-12-06  3:43 ` [PATCH v3 5/6] iommu/vt-d: Add debugfs extension to show Pasid table contents Sohil Mehta
2017-12-06  3:43 ` [PATCH v3 6/6] iommu/vt-d: Add debugfs support for Intel IOMMU Interrupt remapping Sohil Mehta

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=5A30905D.9000303@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=andriy.shevchenko@intel.com \
    --cc=dwmw2@infradead.org \
    --cc=fenghua.yu@intel.com \
    --cc=gayatri.kammela@intel.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ravi.v.shankar@intel.com \
    --cc=sohil.mehta@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