All of lore.kernel.org
 help / color / mirror / Atom feed
From: Can Guo <cang@codeaurora.org>
To: Bart Van Assche <bvanassche@acm.org>
Cc: "moderated list:ARM/Mediatek SoC support"
	<linux-arm-kernel@lists.infradead.org>,
	rnayak@codeaurora.org, saravanak@google.com,
	linux-scsi@vger.kernel.org,
	open list <linux-kernel@vger.kernel.org>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	nguyenb@codeaurora.org, ziqichen@codeaurora.org,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	salyzyn@google.com,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Stanley Chu <stanley.chu@mediatek.com>,
	kernel-team@android.com, hongwus@codeaurora.org,
	asutoshd@codeaurora.org
Subject: Re: [PATCH RFC v1 1/1] scsi: pm: Leave runtime resume along if block layer PM is enabled
Date: Wed, 18 Nov 2020 16:49:47 +0800	[thread overview]
Message-ID: <3d58c7a1971bbb2895a30122255ed2e1@codeaurora.org> (raw)
In-Reply-To: <6d774277-b055-6924-cf2d-01e874ac3f7b@acm.org>

Hi Bart,

On 2020-11-18 12:38, Bart Van Assche wrote:
> On 11/15/20 5:42 PM, Can Guo wrote:
>> Actually, I am thinking about removing all the pm_runtime_set_active()
>> codes in both scsi_bus_resume_common() and scsi_dev_type_resume() - we
>> don't need to forcibly set the runtime PM status to RPM_ACTIVE for 
>> either
>> SCSI host/target or SCSI devices.
>> 
>> Whenever we access one SCSI device, either block layer or somewhere in
>> the path (e.g. throgh sg IOCTL, sg_open() calls 
>> scsi_autopm_get_device())
>> should runtime resume the device first, and the runtime PM framework 
>> makes
>> sure device's parent (and its parent's parent and so on)gets resumed 
>> as
>> well.
>> Thus, the pm_runtime_set_active() seems redundant. What do you think?
> 
> Hi Can,
> 
> It is not clear to me why the pm_runtime_set_active() calls occur in 
> the
> scsi_pm.c source file since the block layer automatically activates
> block devices if necessary. Maybe these calls are a leftover from a 
> time
> when runtime suspended devices were not resumed automatically by the
> block layer? Anyway, I'm fine with removing these calls.
> 
> Thanks,
> 
> Bart.

Yes, I agree with you. Let me test the new patch (which removes all the
pm_runtime_set_active() calls) first, if no issue found, I will upload
it for review.

Thanks,

Can Guo.

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Can Guo <cang@codeaurora.org>
To: Bart Van Assche <bvanassche@acm.org>
Cc: asutoshd@codeaurora.org, nguyenb@codeaurora.org,
	hongwus@codeaurora.org, ziqichen@codeaurora.org,
	rnayak@codeaurora.org, linux-scsi@vger.kernel.org,
	kernel-team@android.com, saravanak@google.com,
	salyzyn@google.com, Stanley Chu <stanley.chu@mediatek.com>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	open list <linux-kernel@vger.kernel.org>,
	"moderated list:ARM/Mediatek SoC support" 
	<linux-arm-kernel@lists.infradead.org>,
	"moderated list:ARM/Mediatek SoC support" 
	<linux-mediatek@lists.infradead.org>
Subject: Re: [PATCH RFC v1 1/1] scsi: pm: Leave runtime resume along if block layer PM is enabled
Date: Wed, 18 Nov 2020 16:49:47 +0800	[thread overview]
Message-ID: <3d58c7a1971bbb2895a30122255ed2e1@codeaurora.org> (raw)
In-Reply-To: <6d774277-b055-6924-cf2d-01e874ac3f7b@acm.org>

Hi Bart,

On 2020-11-18 12:38, Bart Van Assche wrote:
> On 11/15/20 5:42 PM, Can Guo wrote:
>> Actually, I am thinking about removing all the pm_runtime_set_active()
>> codes in both scsi_bus_resume_common() and scsi_dev_type_resume() - we
>> don't need to forcibly set the runtime PM status to RPM_ACTIVE for 
>> either
>> SCSI host/target or SCSI devices.
>> 
>> Whenever we access one SCSI device, either block layer or somewhere in
>> the path (e.g. throgh sg IOCTL, sg_open() calls 
>> scsi_autopm_get_device())
>> should runtime resume the device first, and the runtime PM framework 
>> makes
>> sure device's parent (and its parent's parent and so on)gets resumed 
>> as
>> well.
>> Thus, the pm_runtime_set_active() seems redundant. What do you think?
> 
> Hi Can,
> 
> It is not clear to me why the pm_runtime_set_active() calls occur in 
> the
> scsi_pm.c source file since the block layer automatically activates
> block devices if necessary. Maybe these calls are a leftover from a 
> time
> when runtime suspended devices were not resumed automatically by the
> block layer? Anyway, I'm fine with removing these calls.
> 
> Thanks,
> 
> Bart.

Yes, I agree with you. Let me test the new patch (which removes all the
pm_runtime_set_active() calls) first, if no issue found, I will upload
it for review.

Thanks,

Can Guo.

  reply	other threads:[~2020-11-18  8:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-13  6:30 [PATCH RFC v1 0/1] scsi: pm: Leave runtime resume along if block layer PM is enabled Can Guo
2020-11-13  6:30 ` [PATCH RFC v1 1/1] " Can Guo
2020-11-13  6:30   ` Can Guo
2020-11-13  6:30   ` Can Guo
2020-11-14 20:57   ` Bart Van Assche
2020-11-14 20:57     ` Bart Van Assche
2020-11-14 20:57     ` Bart Van Assche
2020-11-16  1:19     ` Can Guo
2020-11-16  1:19       ` Can Guo
2020-11-16  1:19       ` Can Guo
2020-11-16  1:42     ` Can Guo
2020-11-16  1:42       ` Can Guo
2020-11-16  1:42       ` Can Guo
2020-11-18  4:38       ` Bart Van Assche
2020-11-18  4:38         ` Bart Van Assche
2020-11-18  4:38         ` Bart Van Assche
2020-11-18  8:49         ` Can Guo [this message]
2020-11-18  8:49           ` Can Guo

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=3d58c7a1971bbb2895a30122255ed2e1@codeaurora.org \
    --to=cang@codeaurora.org \
    --cc=asutoshd@codeaurora.org \
    --cc=bvanassche@acm.org \
    --cc=hongwus@codeaurora.org \
    --cc=jejb@linux.ibm.com \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=matthias.bgg@gmail.com \
    --cc=nguyenb@codeaurora.org \
    --cc=rnayak@codeaurora.org \
    --cc=salyzyn@google.com \
    --cc=saravanak@google.com \
    --cc=stanley.chu@mediatek.com \
    --cc=ziqichen@codeaurora.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.