Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp13684680pxu; Mon, 4 Jan 2021 01:17:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJx3tGCj5nrt+ioO2vE4GnrrTbtjuYogAj4nFT0IumIMBVPpx6/tpi9PxE4rAiu0/klgM3oC X-Received: by 2002:a05:6402:8d9:: with SMTP id d25mr18065316edz.278.1609751843714; Mon, 04 Jan 2021 01:17:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609751843; cv=none; d=google.com; s=arc-20160816; b=s9Qqf52lS19Sm8QM5SUorzVC50dacn7Woopsmqeu4SkeuvhAjw1F/yBU22sNUYXxu9 +KyX3TOuGKbj4edBEr838EmMGakVb3S9Z4YxEk9ZryLcVwvPezqDJOBmgyR9LNOtE4hT bPWMhDBgmGiJBknSaGDSfCNml+ZUbtGI4JWmHvXrutrS/bdX54/RyJ5BHrXq8tXiijA1 NzGgpsuLUdFAbyhYDcUbYmj6l2xexTrRiEtelWRH/Nn0yetqK+IzASsSponC0oFqn/Mn w2G36DsaDkr6f8bRv4PpxxebhAi9QxkE8eQPKmVIiUjBeqi4vjd26uqaljYOgpw8ffna CorA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject:ironport-sdr:ironport-sdr; bh=M0H2zfKzATj3XfMRZ8p5XbwWBeAfn8VtPhRdu9xGQIE=; b=EflkNqzgP70irGzehNdnuhJewJRl3gWqAB8IIiXOmx5KHyp/8MaRIHadqjMGxGzkso TRymrHbINlYtF+djGp9IeqN7Ku1nm5BYkalyKVR8bwkYYx+VO29i4WcU0SoCrwbt30lf Q+qtNUaFInyVpWSesQuNbDB5Zl1gbeTKVOypJpvCXfhBNPw15tPvy6+2GwFQAFaK7ZMf p4s0+r99iTasa3rBNEwaSbILr06K2sH2m69iDyb14J920aXKk162whTScSpXZyP2ib8R qqGUgMKILsvOmaT/UZhi8vxazuFhYxbGaz9YpHNyCJjM15KqsiVul/EXhThu1ExsuBJa Whaw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id by23si29435676ejb.165.2021.01.04.01.16.59; Mon, 04 Jan 2021 01:17:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726499AbhADJQ1 (ORCPT + 99 others); Mon, 4 Jan 2021 04:16:27 -0500 Received: from mga06.intel.com ([134.134.136.31]:20029 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726029AbhADJQ1 (ORCPT ); Mon, 4 Jan 2021 04:16:27 -0500 IronPort-SDR: zHbpo+yy1yx8S6yMJ23uwwiK4ahoATJ+NWZJCmS/wpugeI9ewfnZTHCfXKc2rfrzLlmPPZ7cbT 2kwp6SGDBFZA== X-IronPort-AV: E=McAfee;i="6000,8403,9853"; a="238480473" X-IronPort-AV: E=Sophos;i="5.78,473,1599548400"; d="scan'208";a="238480473" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jan 2021 01:15:45 -0800 IronPort-SDR: b7X9+Jo+qFrJ1FgbRx9pH3NHIwGowsTxAjKIdaJ0mMTFSovdQ5+zqmk7fLyfZbmcMG0sDkIDUa T5szOEwBfyDg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.78,473,1599548400"; d="scan'208";a="349833423" Received: from ahunter-desktop.fi.intel.com (HELO [10.237.72.94]) ([10.237.72.94]) by fmsmga008.fm.intel.com with ESMTP; 04 Jan 2021 01:15:37 -0800 Subject: Re: [PATCH RFC v4 1/1] scsi: ufs: Fix ufs power down/on specs violation To: Ziqi Chen , asutoshd@codeaurora.org, nguyenb@codeaurora.org, cang@codeaurora.org, hongwus@codeaurora.org, rnayak@codeaurora.org, vinholikatti@gmail.com, jejb@linux.vnet.ibm.com, martin.petersen@oracle.com, linux-scsi@vger.kernel.org, kernel-team@android.com, saravanak@google.com, salyzyn@google.com, kwmad.kim@samsung.com, stanley.chu@mediatek.com Cc: Alim Akhtar , Avri Altman , "James E.J. Bottomley" , Andy Gross , Bjorn Andersson , Matthias Brugger , Bean Huo , Bart Van Assche , Satya Tangirala , "moderated list:UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER..." , open list , "open list:ARM/QUALCOMM SUPPORT" , "moderated list:ARM/Mediatek SoC support" References: <1608644981-46267-1-git-send-email-ziqichen@codeaurora.org> From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Message-ID: Date: Mon, 4 Jan 2021 11:15:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <1608644981-46267-1-git-send-email-ziqichen@codeaurora.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22/12/20 3:49 pm, Ziqi Chen wrote: > As per specs, e.g, JESD220E chapter 7.2, while powering > off/on the ufs device, RST_N signal and REF_CLK signal > should be between VSS(Ground) and VCCQ/VCCQ2. > > To flexibly control device reset line, refactor the function > ufschd_vops_device_reset(sturct ufs_hba *hba) to ufshcd_ > vops_device_reset(sturct ufs_hba *hba, bool asserted). The > new parameter "bool asserted" is used to separate device reset > line pulling down from pulling up. This patch assumes the power is controlled by voltage regulators, but for us it is controlled by firmware (ACPI), so it is not correct to change RST_n for all host controllers as you are doing. Also we might need to use a firmware interface for device reset, in which case the 'asserted' value doe not make sense. Can we leave the device reset callback alone, and instead introduce a new variant operation for setting RST_n to match voltage regulator power changes?