Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp119666imj; Wed, 13 Feb 2019 05:43:47 -0800 (PST) X-Google-Smtp-Source: AHgI3IbEIA7WUDo2BVIGnt037mhzgfA5T/Q7JX7bYDPi5Qm+MvriMSnbLV6Y0p7uV+qg150iN/OU X-Received: by 2002:a62:e086:: with SMTP id d6mr551198pfm.247.1550065427410; Wed, 13 Feb 2019 05:43:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550065427; cv=none; d=google.com; s=arc-20160816; b=GIzvIvl8MztL3P2xEivJYbfpQn5Mmhu2/+3tbx76+uOUs8fsqAOAfs0CjNoebjekG3 5tS63GDgE4e92qLJKKWLzt6ANm1bJRqw8vI5UjgJPfXcSxCmhb748oMmPMlyHedvOSXe SCvZSri6qDhUjKPqX70WXuiCcFSQDMgfBAm+rIxw3lVG+MpMAlami9fTJ9u/rgFxd0W+ ae6zamdR74zE8evZlLf4DGROsCjbYOFiFTYlZGs9rWlDjwdZ8Hq2aH+XffDmEW5EZlK1 B1dKee6PuXQNlxqIYV65nFV7PnfW/4D5vKc6h5K5SuKEjGGyzCwK6d4sI3tSYITFl1Hw r4uw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=wV4DJ5dv6Iu2S+F89RIbFdrpkjkF7MtaG+LMGY/SiZE=; b=juIim3MatnF3AEJzMRfr1ay0rXHW7PJVgUArIgb+kXbGoxLCRudjEsW+gkgoPn98gk 540XcdqJ0dZmfLq80zrmS1+lTQU7H2s+A3X5l+As+GyQFJbxqER1/oyTxl2mLjCf0fsf /pAsrbXQ5lEHtVqH6yrkdkDPXOU1/H39QWpAUW6Gew2IX46ENH5TRuFqNWhAikGxPtc1 Q1dcqP1gwGWct3Bpb5zlKvC74bygd5G60Zmv8EcdRRy/YYSoNPuag5FAaLBvZIuCecFL jJ57kM45dZ8iib1UZb57qNxe4IiBZW1QMq/gbmMB3l+sUYXM4+IPHl2i4fNlV0clayUT 25bg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k26si4254990pgb.72.2019.02.13.05.43.31; Wed, 13 Feb 2019 05:43:47 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387577AbfBMKGV (ORCPT + 99 others); Wed, 13 Feb 2019 05:06:21 -0500 Received: from smtp3-g21.free.fr ([212.27.42.3]:42805 "EHLO smtp3-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727580AbfBMKGV (ORCPT ); Wed, 13 Feb 2019 05:06:21 -0500 Received: from [192.168.108.68] (unknown [213.36.7.13]) (Authenticated sender: marc.w.gonzalez) by smtp3-g21.free.fr (Postfix) with ESMTPSA id 9169513F8F1; Wed, 13 Feb 2019 11:05:28 +0100 (CET) Subject: Re: [PATCH v5 1/2] scsi: ufs: Do not disable vccq in UFSHC driver To: Mark Brown Cc: SCSI , LKML , Jeffrey Hugo , Bjorn Andersson , Evan Green , Douglas Anderson , Alim Akhtar , Avri Altman , Pedro Sousa , Joao Pinto , Liam Girdwood , Rob Herring , Bart Van Assche , Stanislav Nijnikov , Alex Lemberg , Ohad Sharabi , Venkat Gopalakrishnan , Subhash Jadavani , Yaniv Gardi , Raviv Shvili , Hannes Reinecke , Kyuho Choi , Martin Petersen References: <494cd639-89a7-8868-b63a-ea7cdcba9777@free.fr> <20190211172340.GG22391@sirena.org.uk> From: Marc Gonzalez Message-ID: Date: Wed, 13 Feb 2019 11:05:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190211172340.GG22391@sirena.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/02/2019 18:23, Mark Brown wrote: > On Mon, Feb 11, 2019 at 02:32:15PM +0100, Marc Gonzalez wrote: > >> Unfortunately, this optimization breaks UFS on systems where vccq >> powers not only the Flash chip, but the host controller as well, >> such as APQ8098 MEDIABOX or MTP8998. >> >> In my opinion, the rationale for the original patch is questionable. >> If neither the UFSHC, nor the Flash chip, require any load from vccq, >> then that power rail should simply not be specified at all in the DT. > > If the supply is physically connected it should be valid to represent > this in DT regardless of how or if the supply gets used at runtime. > However it does sound like this support needs to be better thought > through to make sure we have represented the supplies to the flash chip > and the controller separately - it seems like right now there's no > tracking of the supplies needed for the controller and the assumption is > that only the flash chip needs managing which is breaking things. As far as I'm aware, the conflation of host controller with their respective storage medium occurs across several techs: UFS, NAND, SDHC, EMMC. There might be room for improvement, but I don't think these considerations should hold up this series, which fixes something that is broken *today*. UFS reviewers (Alim, Avri, Pedro), can I get at least one Acked-by to remove this small power optimization that breaks UFS on my system? Regards.