mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@intel.com>
To: Bean Huo <huobean@gmail.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	"James E . J . Bottomley" <jejb@linux.ibm.com>
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	Alim Akhtar <alim.akhtar@samsung.com>,
	Avri Altman <avri.altman@wdc.com>, Can Guo <cang@codeaurora.org>,
	Stanley Chu <stanley.chu@mediatek.com>
Subject: Re: [PATCH V2] scsi: ufs-debugfs: Add error counters
Date: Fri, 18 Dec 2020 14:17:44 +0200	[thread overview]
Message-ID: <ec6d7b02-759b-2c9d-df6e-129a09fded1b@intel.com> (raw)
In-Reply-To: <fbb752c30a921f251b7df130c942e20548ca0997.camel@gmail.com>

On 18/12/20 12:57 am, Bean Huo wrote:
> On Thu, 2020-12-17 at 11:49 +0200, Adrian Hunter wrote:
>>>
>>> The purpose of patch is acceptable, but I don't know why you choose
>>> using ufshcd_core_* here. 
>>
>> Do you mean you would like a different function name?  'ufshcd_init'
>> is used
>> already.  The module is called ufshcd-core, so ufshcd_core_* seems
>> appropriate.
>>
>>> Also. I don't know if module_init()  is a proper way here.
>>
>> Can you be more specific?  It is normal to do module initialization
>> in
>> module_init().
> 
> Hi Adrian
> My concern that ufs_debugfs_init() is called in module_init(), but your
> another debugfs initialization function ufs_debugfs_hba_init(hba)
> called in the UFS host probe path. 

It is a good question, but module dependencies and initcall ordering means
that won't happen.  It is not unusual for modules to do initialization in
this way, that is completed before dependent modules initialize.

> 
> If these two (module_init() and module_platform_driver())
> initializaiton sequence always as your expectation: ufs_debugfs_init()-
> ->ufs_debugfs_hba_init(), that is fine, otherwise, it is better just
> group them, make it simpler.

Unfortunately, doing it that way, calls to debugsfs_create_dir("ufshcd",
NULL) could race. Losers of the race will get an error, and will not get the
dentry they need to proceed.  Preventing the race would require adding a
mutex.  So the other way is simpler.

      reply	other threads:[~2020-12-18 12:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-16 18:51 Adrian Hunter
2020-12-16 20:16 ` Bean Huo
2020-12-17  9:49   ` Adrian Hunter
2020-12-17 11:06     ` Avri Altman
2020-12-17 22:57     ` Bean Huo
2020-12-18 12:17       ` Adrian Hunter [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=ec6d7b02-759b-2c9d-df6e-129a09fded1b@intel.com \
    --to=adrian.hunter@intel.com \
    --cc=alim.akhtar@samsung.com \
    --cc=avri.altman@wdc.com \
    --cc=cang@codeaurora.org \
    --cc=huobean@gmail.com \
    --cc=jejb@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=stanley.chu@mediatek.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

Powered by JetHome