Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp3284055rwb; Fri, 20 Jan 2023 13:54:53 -0800 (PST) X-Google-Smtp-Source: AMrXdXuckL7QB981etH2G7l58e6oNAxe6wZkR4RqQW6Tap/93fpK92kTbQhd+5LhDOigK9Y9aA6r X-Received: by 2002:a17:907:ca85:b0:86f:ae1f:9234 with SMTP id ul5-20020a170907ca8500b0086fae1f9234mr18185545ejc.7.1674251693203; Fri, 20 Jan 2023 13:54:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674251693; cv=none; d=google.com; s=arc-20160816; b=TSReD7b7vq1Az0MkF51XRLRsNpReLoksuoCLaDlYTR5ntCPgjEJu0pQzjCcN1ho01j ku+Jeh05aPsMKg1+rF/1fZ9pcSennBbt9sjCOwe4BEMdAlXEyHeFuG/pQqfTyMLYpQvn vma7M7Z23o8Z8ESWgzoSELodfoRp3ARq9jqcLhTwAefwGJaQPPcCOpTJQ6phnscRWwqk DOyoMpT2U7CXZX/Uma1J0Koc5/2zP2XmJZ4qLN2HLEz0V8Oz9SGPDrhJ+xRTMGVoUjlA bo1dVz6qDJMtJTkBPTDtb1U0KncRhraEW1AdWsyG6RgtNomlb/jmTU7wImNwmk/WxyIW skKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=6fgA9NtWheAk/cGIu/EZjPSn92v+Slq1npUDliMGR/Q=; b=KsVzC6gScf/Ys7lcNAY191LIax6+FTRZOG/9XFlvUZ8c/yZtizF9IwB66WCvI3eVyt yDYtqQRppUuP6tvp3uZQWTyDY52HQZ/du6BMg76pa8/q80ukglbg+Rmf81vkcLPsqffC UVWwZz5JJcM291lSkY+tyIXSNb5SafyqKuPMzruODd142yQF1WlZi02s2xbwTfajz8C2 n/xxXIQzM9BsltJc7HQVpdIF1dE/yGZstqgIQ+Ry4OSqRuqbDyIMPeOut2JhU7WZRH9T 2hTSh7t+2KlCk5ilbyG+sYKaveXZQjW/ZVwVC4E+6UE4DurTHBAtNE09OxzksKNue0Lb gPpw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=acm.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id wg3-20020a17090705c300b00773db351c39si14755456ejb.64.2023.01.20.13.54.40; Fri, 20 Jan 2023 13:54:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=acm.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229866AbjATV1K (ORCPT + 50 others); Fri, 20 Jan 2023 16:27:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44198 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229535AbjATV1J (ORCPT ); Fri, 20 Jan 2023 16:27:09 -0500 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 188866A302; Fri, 20 Jan 2023 13:27:09 -0800 (PST) Received: by mail-pl1-f180.google.com with SMTP id z13so6432974plg.6; Fri, 20 Jan 2023 13:27:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6fgA9NtWheAk/cGIu/EZjPSn92v+Slq1npUDliMGR/Q=; b=xwI0n7cAKR05fpzkkIkXQZ+JdRMoMgtZzvavisOl8koXIPNVG5t9QRUhZ5UYzAhO59 586+0TGvdXrR9Yy32DcwPPo2nwPj57Zw3AOkGEPCY824UNp6TGyJRGI2jLXp5XCBJ7Jt F7DRHkXpzz2KoVw15l8S2uAtstPVw+ULm29KdAKdVss6O0L64TTvXlKmrXooP0qgjoMp Fcq/mELd/IGboh6DOjQTOKHSSdQk9zjMqGy/1V2DqqcqgpsdMFLWpWK8v5lZyBEmWdQN 3k6113tNWN8Shzp3KQJL+7YyvTtIxcReYgP0e1IoRGij+7dOvBPhJhF3ObCvJlJ6LZj6 +TwQ== X-Gm-Message-State: AFqh2koLTH1OJXSAIPdDckOC3PXtF9HCsO7uyuB0zPc0fxguAZVrnkT+ CidD7qcPgksAhmc6Pz6y3cA= X-Received: by 2002:a17:902:c409:b0:194:a854:6274 with SMTP id k9-20020a170902c40900b00194a8546274mr20324720plk.60.1674250028328; Fri, 20 Jan 2023 13:27:08 -0800 (PST) Received: from ?IPV6:2620:15c:211:201:3a65:5ceb:1d3:9e21? ([2620:15c:211:201:3a65:5ceb:1d3:9e21]) by smtp.gmail.com with ESMTPSA id t12-20020a170902e84c00b0019327a6abc2sm7629955plg.44.2023.01.20.13.27.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Jan 2023 13:27:07 -0800 (PST) Message-ID: <9800d704-c436-a924-c2bb-ccdf51e86716@acm.org> Date: Fri, 20 Jan 2023 13:27:05 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH v3 1/1] scsi: ufs: Add hibernation callbacks Content-Language: en-US To: Anjana Hari , agross@kernel.org, andersson@kernel.org, jejb@linux.ibm.com, martin.petersen@oracle.com Cc: alim.akhtar@samsung.com, avri.altman@wdc.com, konrad.dybcio@linaro.org, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, quic_narepall@quicinc.com, quic_nitirawa@quicinc.com, quic_rampraka@quicinc.com References: <20230120113321.30433-1-quic_ahari@quicinc.com> <20230120113321.30433-2-quic_ahari@quicinc.com> From: Bart Van Assche In-Reply-To: <20230120113321.30433-2-quic_ahari@quicinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/20/23 03:33, Anjana Hari wrote: > + /* Make sure that UTRL and UTMRL base address registers > + * are updated with the latest queue addresses. Only after > + * updating these addresses, we can queue the new commands. > + */ Please follow the kernel coding style and start comment blocks with "/*" on a line by its own. > + /* Resuming from hibernate, assume that link was OFF */ > + if (hba->restore) > + ufshcd_set_link_off(hba); Why two successive 'if (hba->restore)' statements? Can these two if-statements be combined into a single if-statement? > +int ufshcd_system_freeze(struct device *dev) > +{ > + > + struct ufs_hba *hba = dev_get_drvdata(dev); > + int ret = 0; > + > + /* > + * Run time resume the controller to make sure > + * the PM work queue threads do not try to resume > + * the child (scsi host), which leads to errors as > + * the controller is not yet resumed. > + */ > + pm_runtime_get_sync(hba->dev); > + ret = ufshcd_system_suspend(dev); > + pm_runtime_put_sync(hba->dev); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(ufshcd_system_freeze); Why does the above function use 'hba->dev' instead of 'dev'? I do not understand the comment in the above function. My understanding is that the power management core serializes hibernation and runtime power management. How could runtime resume be in progress when ufshcd_system_freeze() is called? Additionally, shouldn't ufshcd_system_freeze() skip the UFS controller if it is already runtime suspended instead of runtime resuming it? Some time ago I added the following code in sd_suspend_system() (commit 9131bff6a9f1 ("scsi: core: pm: Only runtime resume if necessary"): if (pm_runtime_suspended(dev)) return 0; Thanks, Bart.