From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 016C5C433E0 for ; Wed, 10 Mar 2021 16:28:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CF08864FCE for ; Wed, 10 Mar 2021 16:28:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232330AbhCJQ1t (ORCPT ); Wed, 10 Mar 2021 11:27:49 -0500 Received: from netrider.rowland.org ([192.131.102.5]:57763 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S229790AbhCJQ1b (ORCPT ); Wed, 10 Mar 2021 11:27:31 -0500 Received: (qmail 223764 invoked by uid 1000); 10 Mar 2021 11:27:30 -0500 Date: Wed, 10 Mar 2021 11:27:30 -0500 From: Alan Stern To: "Asutosh Das \(asd\)" Cc: Bart Van Assche , Adrian Hunter , "Rafael J. Wysocki" , cang@codeaurora.org, "Martin K. Petersen" , "open list:TARGET SUBSYSTEM" , linux-arm-msm , Alim Akhtar , Avri Altman , "James E.J. Bottomley" , Krzysztof Kozlowski , Stanley Chu , Andy Gross , Bjorn Andersson , Steven Rostedt , Ingo Molnar , Matthias Brugger , Kiwoong Kim , Bean Huo , Lee Jones , Wei Yongjun , Dinghao Liu , "Gustavo A. R. Silva" , Tomas Winkler , Jaegeuk Kim , Satya Tangirala , open list , "moderated list:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES" , "open list:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES" , "moderated list:UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER..." , Linux-PM mailing list Subject: Re: [PATCH v10 1/2] scsi: ufs: Enable power management for wlun Message-ID: <20210310162730.GB221857@rowland.harvard.edu> References: <0576d6eae15486740c25767e2d8805f7e94eb79d.1614725302.git.asutoshd@codeaurora.org> <85086647-7292-b0a2-d842-290818bd2858@intel.com> <6e98724d-2e75-d1fe-188f-a7010f86c509@codeaurora.org> <20210306161616.GC74411@rowland.harvard.edu> <2bd90336-18a9-9acd-5abb-5b52b27fc535@codeaurora.org> <20210310031438.GB203516@rowland.harvard.edu> <6b985880-f23a-adb3-8b7a-7ee1b56e6fa7@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6b985880-f23a-adb3-8b7a-7ee1b56e6fa7@codeaurora.org> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Tue, Mar 09, 2021 at 08:04:53PM -0800, Asutosh Das (asd) wrote: > On 3/9/2021 7:14 PM, Alan Stern wrote: > > On Tue, Mar 09, 2021 at 07:04:34PM -0800, Asutosh Das (asd) wrote: > > > Hello > > > I & Can (thanks CanG) debugged this further: > > > > > > Looks like this issue can occur if the sd probe is asynchronous. > > > > > > Essentially, the sd_probe() is done asynchronously and driver_probe_device() > > > invokes pm_runtime_get_suppliers() before invoking sd_probe(). > > > > > > But scsi_probe_and_add_lun() runs in a separate context. > > > So the scsi_autopm_put_device() invoked from scsi_scan_host() context > > > reduces the link->rpm_active to 1. And sd_probe() invokes > > > scsi_autopm_put_device() and starts a timer. And then driver_probe_device() > > > invoked from __device_attach_async_helper context reduces the > > > link->rpm_active to 1 thus enabling the supplier to suspend before the > > > consumer suspends. > > > > > I don't see a way around this. Please let me know if you > > > (@Alan/@Bart/@Adrian) have any thoughts on this. > > > > How about changing the SCSI core so that it does a runtime_get before > > starting an async probe, and the async probe routine does a > > runtime_put when it is finished? In other words, don't allow a device > > to go into runtime suspend while it is waiting to be probed. > > > > I don't think that would be too intrusive. > > > > Alan Stern > > > > Hi Alan > Thanks for the suggestion. > > Am trying to understand: > > Do you mean something like this: > > int scsi_sysfs_add_sdev(struct scsi_device *sdev) > { > > scsi_autopm_get_device(sdev); > pm_runtime_get_noresume(&sdev->sdev_gendev); > [...] > scsi_autopm_put_device(sdev); > [...] > } > > static int sd_probe(struct device *dev) > { > [...] > pm_runtime_put_noidle(dev); > scsi_autopm_put_device(sdp); > [...] > } > > This may work (I'm limited by my imagination in scsi layer :) ). I'm not sure about this. To be honest, I did not read the entirety of your last message; it had way too much detail. THere's a time and place for that, but when you're brainstorming to figure out the underlying cause of a problem and come up with a strategy to fix it, you want to concentrate on the overall picture, not the details. As I understand the situation, you've get a SCSI target with multiple logical units, let's say A and B, and you need to make sure that A never goes into runtime suspend unless B is already suspended. In other words, B always has to suspend before A and resume after A. To do this, you register a device link with A as the supplier and B as the consumer. Then the PM core takes care of the ordering for you. But I don't understand when you set up the device link. If the timing is wrong then, thanks to async SCSI probing, you may have a situation where A is registered before B and before the link is set up. Then there's temporarily nothing to stop A from suspending before B. You also need to prevent each device from suspending before it is probed. That's the easy part I was trying to address before (although it may not be so easy if the drivers are in loadable modules and not present in the kernel). You need to think through these issues before proposing actual changes. > But the pm_runtime_put_noidle() would have to be added to all registered > scsi_driver{}, perhaps? Or may be I can check for sdp->type? Like this; it's too early to worry about this sort of thing. Alan Stern From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F81BC433DB for ; Wed, 10 Mar 2021 16:28:01 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2786F64FC1 for ; Wed, 10 Mar 2021 16:28:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2786F64FC1 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=rowland.harvard.edu Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=z4NzmWArFU4vudDhur7hSQUbDWWiHZ6j81P3QHeJU/4=; b=cz2OxwvLiMYsxWk+4F9VrNp8D vxgtqbo7bDhNeEhn9u+EybP/nndfsMm41Jdgb1rRatd1wXOVL2JTIAXDDkxPly+mjMbg1ZxQh8GGH 3NCVYKpoDlitXyVH49wKE+9XYh9EWZmJeX7UYWJ0I4rbFE9toQw8pjImo5EJdJEN027M7Z85JVfMx 0rfMbOSVqXMtULZEHuU7CRRMZjbTHGK0Nr8dhje/3pUvL1hQQpNJR8Nxsd0eTGxaSoM930uhKIpo/ XY6PQokLbXmm6U0YOBA/f7VLPZFcDuRuLkNz5EuvjV0N6/VxrIRFCi4t9VxyC+KvPafws1n+kdDYx Im5F283BA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lK1gW-007Ety-KK; Wed, 10 Mar 2021 16:27:44 +0000 Received: from netrider.rowland.org ([192.131.102.5]) by desiato.infradead.org with smtp (Exim 4.94 #2 (Red Hat Linux)) id 1lK1gL-007EsY-Cn for linux-mediatek@lists.infradead.org; Wed, 10 Mar 2021 16:27:35 +0000 Received: (qmail 223764 invoked by uid 1000); 10 Mar 2021 11:27:30 -0500 Date: Wed, 10 Mar 2021 11:27:30 -0500 From: Alan Stern To: "Asutosh Das \(asd\)" Cc: Bart Van Assche , Adrian Hunter , "Rafael J. Wysocki" , cang@codeaurora.org, "Martin K. Petersen" , "open list:TARGET SUBSYSTEM" , linux-arm-msm , Alim Akhtar , Avri Altman , "James E.J. Bottomley" , Krzysztof Kozlowski , Stanley Chu , Andy Gross , Bjorn Andersson , Steven Rostedt , Ingo Molnar , Matthias Brugger , Kiwoong Kim , Bean Huo , Lee Jones , Wei Yongjun , Dinghao Liu , "Gustavo A. R. Silva" , Tomas Winkler , Jaegeuk Kim , Satya Tangirala , open list , "moderated list:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES" , "open list:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES" , "moderated list:UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER..." , Linux-PM mailing list Subject: Re: [PATCH v10 1/2] scsi: ufs: Enable power management for wlun Message-ID: <20210310162730.GB221857@rowland.harvard.edu> References: <0576d6eae15486740c25767e2d8805f7e94eb79d.1614725302.git.asutoshd@codeaurora.org> <85086647-7292-b0a2-d842-290818bd2858@intel.com> <6e98724d-2e75-d1fe-188f-a7010f86c509@codeaurora.org> <20210306161616.GC74411@rowland.harvard.edu> <2bd90336-18a9-9acd-5abb-5b52b27fc535@codeaurora.org> <20210310031438.GB203516@rowland.harvard.edu> <6b985880-f23a-adb3-8b7a-7ee1b56e6fa7@codeaurora.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <6b985880-f23a-adb3-8b7a-7ee1b56e6fa7@codeaurora.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210310_162733_714478_B2CC51BA X-CRM114-Status: GOOD ( 35.05 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Tue, Mar 09, 2021 at 08:04:53PM -0800, Asutosh Das (asd) wrote: > On 3/9/2021 7:14 PM, Alan Stern wrote: > > On Tue, Mar 09, 2021 at 07:04:34PM -0800, Asutosh Das (asd) wrote: > > > Hello > > > I & Can (thanks CanG) debugged this further: > > > > > > Looks like this issue can occur if the sd probe is asynchronous. > > > > > > Essentially, the sd_probe() is done asynchronously and driver_probe_device() > > > invokes pm_runtime_get_suppliers() before invoking sd_probe(). > > > > > > But scsi_probe_and_add_lun() runs in a separate context. > > > So the scsi_autopm_put_device() invoked from scsi_scan_host() context > > > reduces the link->rpm_active to 1. And sd_probe() invokes > > > scsi_autopm_put_device() and starts a timer. And then driver_probe_device() > > > invoked from __device_attach_async_helper context reduces the > > > link->rpm_active to 1 thus enabling the supplier to suspend before the > > > consumer suspends. > > > > > I don't see a way around this. Please let me know if you > > > (@Alan/@Bart/@Adrian) have any thoughts on this. > > > > How about changing the SCSI core so that it does a runtime_get before > > starting an async probe, and the async probe routine does a > > runtime_put when it is finished? In other words, don't allow a device > > to go into runtime suspend while it is waiting to be probed. > > > > I don't think that would be too intrusive. > > > > Alan Stern > > > > Hi Alan > Thanks for the suggestion. > > Am trying to understand: > > Do you mean something like this: > > int scsi_sysfs_add_sdev(struct scsi_device *sdev) > { > > scsi_autopm_get_device(sdev); > pm_runtime_get_noresume(&sdev->sdev_gendev); > [...] > scsi_autopm_put_device(sdev); > [...] > } > > static int sd_probe(struct device *dev) > { > [...] > pm_runtime_put_noidle(dev); > scsi_autopm_put_device(sdp); > [...] > } > > This may work (I'm limited by my imagination in scsi layer :) ). I'm not sure about this. To be honest, I did not read the entirety of your last message; it had way too much detail. THere's a time and place for that, but when you're brainstorming to figure out the underlying cause of a problem and come up with a strategy to fix it, you want to concentrate on the overall picture, not the details. As I understand the situation, you've get a SCSI target with multiple logical units, let's say A and B, and you need to make sure that A never goes into runtime suspend unless B is already suspended. In other words, B always has to suspend before A and resume after A. To do this, you register a device link with A as the supplier and B as the consumer. Then the PM core takes care of the ordering for you. But I don't understand when you set up the device link. If the timing is wrong then, thanks to async SCSI probing, you may have a situation where A is registered before B and before the link is set up. Then there's temporarily nothing to stop A from suspending before B. You also need to prevent each device from suspending before it is probed. That's the easy part I was trying to address before (although it may not be so easy if the drivers are in loadable modules and not present in the kernel). You need to think through these issues before proposing actual changes. > But the pm_runtime_put_noidle() would have to be added to all registered > scsi_driver{}, perhaps? Or may be I can check for sdp->type? Like this; it's too early to worry about this sort of thing. Alan Stern _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4FE7DC433E0 for ; Wed, 10 Mar 2021 16:28:47 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DAFA264F4E for ; Wed, 10 Mar 2021 16:28:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DAFA264F4E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=rowland.harvard.edu Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=SOo8iua1QUFOWe3aycm1XgGl/3bXTP3dtZ7w/X4DJ5M=; b=U0tPIV6S6ceDoMczrf2aTZdG3 6Vk3xJlrfRkD6df9HWhepn5vLyoDSaeR3Tc4ibqy0xRFnt4C+4b4Wz6BhlYIEiRIF2JlZXS88irut tfdmfQMCNnwuCT1U9inMhg6CuTKfpmYeC6w9HQQChtZtsw87iNVGhhqIL9kLaS9yQt+yfLGTMTPMa 25mJu8gPZ3FsWx4oHwPqSM27UnxiUMRtVo2tVMuUygUDYLBBJMYkW0rm1iYnH2dwK29o0Hvxk7bTQ ArxiIkqp406XngIENi+oSLKat3m3c5EEP5I/MjQ1l6FNl4goTp+Zk0/luonmkWCJSwpw0v69ZB6Ff 2wNqgcwBg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lK1gQ-007EtV-7P; Wed, 10 Mar 2021 16:27:38 +0000 Received: from netrider.rowland.org ([192.131.102.5]) by desiato.infradead.org with smtp (Exim 4.94 #2 (Red Hat Linux)) id 1lK1gL-007EsX-Cq for linux-arm-kernel@lists.infradead.org; Wed, 10 Mar 2021 16:27:35 +0000 Received: (qmail 223764 invoked by uid 1000); 10 Mar 2021 11:27:30 -0500 Date: Wed, 10 Mar 2021 11:27:30 -0500 From: Alan Stern To: "Asutosh Das \(asd\)" Cc: Bart Van Assche , Adrian Hunter , "Rafael J. Wysocki" , cang@codeaurora.org, "Martin K. Petersen" , "open list:TARGET SUBSYSTEM" , linux-arm-msm , Alim Akhtar , Avri Altman , "James E.J. Bottomley" , Krzysztof Kozlowski , Stanley Chu , Andy Gross , Bjorn Andersson , Steven Rostedt , Ingo Molnar , Matthias Brugger , Kiwoong Kim , Bean Huo , Lee Jones , Wei Yongjun , Dinghao Liu , "Gustavo A. R. Silva" , Tomas Winkler , Jaegeuk Kim , Satya Tangirala , open list , "moderated list:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES" , "open list:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES" , "moderated list:UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER..." , Linux-PM mailing list Subject: Re: [PATCH v10 1/2] scsi: ufs: Enable power management for wlun Message-ID: <20210310162730.GB221857@rowland.harvard.edu> References: <0576d6eae15486740c25767e2d8805f7e94eb79d.1614725302.git.asutoshd@codeaurora.org> <85086647-7292-b0a2-d842-290818bd2858@intel.com> <6e98724d-2e75-d1fe-188f-a7010f86c509@codeaurora.org> <20210306161616.GC74411@rowland.harvard.edu> <2bd90336-18a9-9acd-5abb-5b52b27fc535@codeaurora.org> <20210310031438.GB203516@rowland.harvard.edu> <6b985880-f23a-adb3-8b7a-7ee1b56e6fa7@codeaurora.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <6b985880-f23a-adb3-8b7a-7ee1b56e6fa7@codeaurora.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210310_162733_725363_75295174 X-CRM114-Status: GOOD ( 35.87 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Mar 09, 2021 at 08:04:53PM -0800, Asutosh Das (asd) wrote: > On 3/9/2021 7:14 PM, Alan Stern wrote: > > On Tue, Mar 09, 2021 at 07:04:34PM -0800, Asutosh Das (asd) wrote: > > > Hello > > > I & Can (thanks CanG) debugged this further: > > > > > > Looks like this issue can occur if the sd probe is asynchronous. > > > > > > Essentially, the sd_probe() is done asynchronously and driver_probe_device() > > > invokes pm_runtime_get_suppliers() before invoking sd_probe(). > > > > > > But scsi_probe_and_add_lun() runs in a separate context. > > > So the scsi_autopm_put_device() invoked from scsi_scan_host() context > > > reduces the link->rpm_active to 1. And sd_probe() invokes > > > scsi_autopm_put_device() and starts a timer. And then driver_probe_device() > > > invoked from __device_attach_async_helper context reduces the > > > link->rpm_active to 1 thus enabling the supplier to suspend before the > > > consumer suspends. > > > > > I don't see a way around this. Please let me know if you > > > (@Alan/@Bart/@Adrian) have any thoughts on this. > > > > How about changing the SCSI core so that it does a runtime_get before > > starting an async probe, and the async probe routine does a > > runtime_put when it is finished? In other words, don't allow a device > > to go into runtime suspend while it is waiting to be probed. > > > > I don't think that would be too intrusive. > > > > Alan Stern > > > > Hi Alan > Thanks for the suggestion. > > Am trying to understand: > > Do you mean something like this: > > int scsi_sysfs_add_sdev(struct scsi_device *sdev) > { > > scsi_autopm_get_device(sdev); > pm_runtime_get_noresume(&sdev->sdev_gendev); > [...] > scsi_autopm_put_device(sdev); > [...] > } > > static int sd_probe(struct device *dev) > { > [...] > pm_runtime_put_noidle(dev); > scsi_autopm_put_device(sdp); > [...] > } > > This may work (I'm limited by my imagination in scsi layer :) ). I'm not sure about this. To be honest, I did not read the entirety of your last message; it had way too much detail. THere's a time and place for that, but when you're brainstorming to figure out the underlying cause of a problem and come up with a strategy to fix it, you want to concentrate on the overall picture, not the details. As I understand the situation, you've get a SCSI target with multiple logical units, let's say A and B, and you need to make sure that A never goes into runtime suspend unless B is already suspended. In other words, B always has to suspend before A and resume after A. To do this, you register a device link with A as the supplier and B as the consumer. Then the PM core takes care of the ordering for you. But I don't understand when you set up the device link. If the timing is wrong then, thanks to async SCSI probing, you may have a situation where A is registered before B and before the link is set up. Then there's temporarily nothing to stop A from suspending before B. You also need to prevent each device from suspending before it is probed. That's the easy part I was trying to address before (although it may not be so easy if the drivers are in loadable modules and not present in the kernel). You need to think through these issues before proposing actual changes. > But the pm_runtime_put_noidle() would have to be added to all registered > scsi_driver{}, perhaps? Or may be I can check for sdp->type? Like this; it's too early to worry about this sort of thing. Alan Stern _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel