From mboxrd@z Thu Jan 1 00:00:00 1970 From: Akinobu Mita Subject: Re: [PATCH v2 4/4] scsi: ufs: probe and init of variant driver from the platform device Date: Mon, 8 Jun 2015 23:47:36 +0900 Message-ID: References: <1433324255-27510-1-git-send-email-ygardi@codeaurora.org> <1433324255-27510-5-git-send-email-ygardi@codeaurora.org> <763dbc7b708b5d5b18ce0b5adcc41016.squirrel@www.codeaurora.org> <68c91f08f2be6c84055a303ca8aa3fe0.squirrel@www.codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from mail-vn0-f53.google.com ([209.85.216.53]:39849 "EHLO mail-vn0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751737AbbFHOrh (ORCPT ); Mon, 8 Jun 2015 10:47:37 -0400 In-Reply-To: <68c91f08f2be6c84055a303ca8aa3fe0.squirrel@www.codeaurora.org> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Yaniv Gardi Cc: merez@qti.qualcomm.com, dovl@qti.qualcomm.com, Jej B , LKML , "linux-scsi@vger.kernel.org" , linux-arm-msm@vger.kernel.org, Santosh Y , linux-scsi-owner@vger.kernel.org, Subhash Jadavani , Paul Bolle , Gilad Broner , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Vinayak Holikatti , "James E.J. Bottomley" , Dolev Raviv , Christoph Hellwig , Sujit Reddy Thumma , Raviv Shvili , Sahitya Tummala 2015-06-08 0:32 GMT+09:00 : > 1) > If ufshcd-pltfrm driver is loaded before ufs-qcom, (what actually happens > always), then the calling to of_platform_populate() which is added, > guarantees that ufs-qcom probe will be called and finish, before > ufshcd_pltfrm probe continues. I'm worrying the case ufshcd_pltfrm_probe() is called when ufshcd-pltfrm module is installed but ufs-qcom module is _not_ installed yet, where ufshcd-pltfrm and ufs-qcom are both built as loadable modules. In this case, of_platform_populate() in ufshcd_pltfrm_probe() doesn't invoke ufs-qcom probe, does it? So I suggested using deferred probe infrastructure by returning -EPROBE_DEFER. > so ufs_variant device is always there, and ready. > I think it means we are safe - since either way, we make sure ufs-qcom > probe will be called and finish before dealing with ufs_variant device in > ufshcd_pltfrm probe. > > 2) you are right. the fix added as you suggested. Thanks for fixing it. But a little more work is needed in v3, I'll leave a comment to v3.