Re: [PATCH V2] scsi: ufs-debugfs: Add error counters

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux