On 16/12/20 10:16 pm, Bean Huo wrote:
> On Wed, 2020-12-16 at 20:51 +0200, Adrian Hunter wrote:
>> ufshcd_variant_hba_exit(hba);
>> ufshcd_setup_vreg(hba, false);
>> ufshcd_suspend_clkscaling(hba);
>> @@ -9436,6 +9441,20 @@ int ufshcd_init(struct ufs_hba *hba, void
>> __iomem *mmio_base, unsigned int irq)
>> }
>> EXPORT_SYMBOL_GPL(ufshcd_init);
>>
>> +static int __init ufshcd_core_init(void)
>> +{
>> + ufs_debugfs_init();
>> + return 0;
>> +}
>> +
>> +static void __exit ufshcd_core_exit(void)
>> +{
>> + ufs_debugfs_exit();
>> +}
>
> Hi, Adrian
Thanks for looking at the patch.
>
> 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().
However I do see a problem. When builtin, initcalls are ordered according
to link order, but the Makefile does not have ufshcd-core at the top i.e.
$ cat drivers/scsi/ufs/Makefile
# SPDX-License-Identifier: GPL-2.0
# UFSHCD makefile
obj-$(CONFIG_SCSI_UFS_DWC_TC_PCI) += tc-dwc-g210-pci.o ufshcd-dwc.o
tc-dwc-g210.o
obj-$(CONFIG_SCSI_UFS_DWC_TC_PLATFORM) += tc-dwc-g210-pltfrm.o ufshcd-dwc.o
tc-dwc-g210.o
obj-$(CONFIG_SCSI_UFS_CDNS_PLATFORM) += cdns-pltfrm.o
obj-$(CONFIG_SCSI_UFS_QCOM) += ufs_qcom.o
ufs_qcom-y += ufs-qcom.o
ufs_qcom-$(CONFIG_SCSI_UFS_CRYPTO) += ufs-qcom-ice.o
obj-$(CONFIG_SCSI_UFS_EXYNOS) += ufs-exynos.o
obj-$(CONFIG_SCSI_UFSHCD) += ufshcd-core.o
ufshcd-core-y += ufshcd.o ufs-sysfs.o
ufshcd-core-$(CONFIG_DEBUG_FS) += ufs-debugfs.o
ufshcd-core-$(CONFIG_SCSI_UFS_BSG) += ufs_bsg.o
ufshcd-core-$(CONFIG_SCSI_UFS_CRYPTO) += ufshcd-crypto.o
obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
obj-$(CONFIG_SCSI_UFS_HISI) += ufs-hisi.o
obj-$(CONFIG_SCSI_UFS_MEDIATEK) += ufs-mediatek.o
obj-$(CONFIG_SCSI_UFS_TI_J721E) += ti-j721e-ufs.o
Should be:
# SPDX-License-Identifier: GPL-2.0
# UFSHCD makefile
# Order here is important. ufshcd-core must initialize first.
ufshcd-core-y += ufshcd.o ufs-sysfs.o
ufshcd-core-$(CONFIG_DEBUG_FS) += ufs-debugfs.o
ufshcd-core-$(CONFIG_SCSI_UFS_BSG) += ufs_bsg.o
ufshcd-core-$(CONFIG_SCSI_UFS_CRYPTO) += ufshcd-crypto.o
obj-$(CONFIG_SCSI_UFS_DWC_TC_PCI) += tc-dwc-g210-pci.o ufshcd-dwc.o
tc-dwc-g210.o
obj-$(CONFIG_SCSI_UFS_DWC_TC_PLATFORM) += tc-dwc-g210-pltfrm.o ufshcd-dwc.o
tc-dwc-g210.o
obj-$(CONFIG_SCSI_UFS_CDNS_PLATFORM) += cdns-pltfrm.o
obj-$(CONFIG_SCSI_UFS_QCOM) += ufs_qcom.o
ufs_qcom-y += ufs-qcom.o
ufs_qcom-$(CONFIG_SCSI_UFS_CRYPTO) += ufs-qcom-ice.o
obj-$(CONFIG_SCSI_UFS_EXYNOS) += ufs-exynos.o
obj-$(CONFIG_SCSI_UFSHCD) += ufshcd-core.o
obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
obj-$(CONFIG_SCSI_UFS_HISI) += ufs-hisi.o
obj-$(CONFIG_SCSI_UFS_MEDIATEK) += ufs-mediatek.o
obj-$(CONFIG_SCSI_UFS_TI_J721E) += ti-j721e-ufs.o
What do you think?
>
> thanks,
> Bean
>
>>
>> n
>> +
>> +module_init(ufshcd_core_init);
>> +module_exit(ufshcd_core_exit)
>
Please add my reviewed-by once you fix that.
Thanks,
Avri
> However I do see a problem. When builtin, initcalls are ordered according
> to link order, but the Makefile does not have ufshcd-core at the top i.e.
>
> $ cat drivers/scsi/ufs/Makefile
> # SPDX-License-Identifier: GPL-2.0
> # UFSHCD makefile
> obj-$(CONFIG_SCSI_UFS_DWC_TC_PCI) += tc-dwc-g210-pci.o ufshcd-dwc.o
> tc-dwc-g210.o
> obj-$(CONFIG_SCSI_UFS_DWC_TC_PLATFORM) += tc-dwc-g210-pltfrm.o
> ufshcd-dwc.o
> tc-dwc-g210.o
> obj-$(CONFIG_SCSI_UFS_CDNS_PLATFORM) += cdns-pltfrm.o
> obj-$(CONFIG_SCSI_UFS_QCOM) += ufs_qcom.o
> ufs_qcom-y += ufs-qcom.o
> ufs_qcom-$(CONFIG_SCSI_UFS_CRYPTO) += ufs-qcom-ice.o
> obj-$(CONFIG_SCSI_UFS_EXYNOS) += ufs-exynos.o
> obj-$(CONFIG_SCSI_UFSHCD) += ufshcd-core.o
> ufshcd-core-y += ufshcd.o ufs-sysfs.o
> ufshcd-core-$(CONFIG_DEBUG_FS) += ufs-debugfs.o
> ufshcd-core-$(CONFIG_SCSI_UFS_BSG) += ufs_bsg.o
> ufshcd-core-$(CONFIG_SCSI_UFS_CRYPTO) += ufshcd-crypto.o
> obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
> obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
> obj-$(CONFIG_SCSI_UFS_HISI) += ufs-hisi.o
> obj-$(CONFIG_SCSI_UFS_MEDIATEK) += ufs-mediatek.o
> obj-$(CONFIG_SCSI_UFS_TI_J721E) += ti-j721e-ufs.o
>
> Should be:
>
> # SPDX-License-Identifier: GPL-2.0
> # UFSHCD makefile
> # Order here is important. ufshcd-core must initialize first.
> ufshcd-core-y += ufshcd.o ufs-sysfs.o
> ufshcd-core-$(CONFIG_DEBUG_FS) += ufs-debugfs.o
> ufshcd-core-$(CONFIG_SCSI_UFS_BSG) += ufs_bsg.o
> ufshcd-core-$(CONFIG_SCSI_UFS_CRYPTO) += ufshcd-crypto.o
> obj-$(CONFIG_SCSI_UFS_DWC_TC_PCI) += tc-dwc-g210-pci.o ufshcd-dwc.o
> tc-dwc-g210.o
> obj-$(CONFIG_SCSI_UFS_DWC_TC_PLATFORM) += tc-dwc-g210-pltfrm.o
> ufshcd-dwc.o
> tc-dwc-g210.o
> obj-$(CONFIG_SCSI_UFS_CDNS_PLATFORM) += cdns-pltfrm.o
> obj-$(CONFIG_SCSI_UFS_QCOM) += ufs_qcom.o
> ufs_qcom-y += ufs-qcom.o
> ufs_qcom-$(CONFIG_SCSI_UFS_CRYPTO) += ufs-qcom-ice.o
> obj-$(CONFIG_SCSI_UFS_EXYNOS) += ufs-exynos.o
> obj-$(CONFIG_SCSI_UFSHCD) += ufshcd-core.o
> obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
> obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
> obj-$(CONFIG_SCSI_UFS_HISI) += ufs-hisi.o
> obj-$(CONFIG_SCSI_UFS_MEDIATEK) += ufs-mediatek.o
> obj-$(CONFIG_SCSI_UFS_TI_J721E) += ti-j721e-ufs.o
>
> What do you think?
>
> >
> > thanks,
> > Bean
> >
> >>
> >> n
> >> +
> >> +module_init(ufshcd_core_init);
> >> +module_exit(ufshcd_core_exit)
> >
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.
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.
Thanks,
Bean
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.