Received: by 10.213.65.68 with SMTP id h4csp1976940imn; Thu, 5 Apr 2018 07:03:11 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/mLSSiMGodLbHao+BAkmbgQY/aSPBpAEE67pPlXYgeHzSx1o6B8HVzhOdUTqD69CYRScvk X-Received: by 10.99.130.199 with SMTP id w190mr15011318pgd.15.1522936991465; Thu, 05 Apr 2018 07:03:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522936991; cv=none; d=google.com; s=arc-20160816; b=sDKrU+Z9JotFCxamA4BVUJ+xNpdUuoMz1ioA8ZitN2wK0n7hi3LjDG0SovLVupy++x 7XhuCL0yUAYmaxpUHc5c+DPPzKNyXomzF0w0rdSuwq8+l6Vwb4Vxil5HumDPEy9RLFFt 5PzS98Y2H2FGDYhPVxoHtpy/fUB8PtF7W2ferVvcepQGcfdQnwDEORRzLc4rSQazDCtg fUp6wBnwalyrhdyH6XQz+F/us8pJSeT21MzytdZpXsEU9sEAG5uD2YK79EeByH1IEAkP YKbRCTb08vxfpFx+SdM+zvaonCz1VRC/4duLCLA0Efl024zYmux9aGs8mseihZjVwy2i OaSA== 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:arc-authentication-results; bh=5/2oGXveysf7CjpihQaITFNJNf4X3DdO49lHWv/FKL4=; b=rEXJK3Z6BOLjp5TjZIuia2tYMqlCmyxejg0/kvV0sKmttH8D1dXG92NeRpHQJo0dDs QLQSgOKMgjvYV+wABoQQHnMjCGHPDwJS5iKf+/+PnqyIJpUtVJoOuyGIH9tYF7+JvnTS ttHosEORMGo8ODrgGyrZDxPnMOe0ExYObNoiFmZijODN6U3abBqILhlhnus1bKrD6PfS qrVL3UCcau/dFXUcRFzG3zAiqYqbbZ3jbfWft/HQ1dW/1uJztL702/P3Mll/UcUSoVuC pprW6YvbCO/zYleegDvLAHhkuGwq1livDTcNGlqFIx5dcXyMdPK2U7xg9AT0XJZqAf0Y o1wA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g4-v6si5918144plb.522.2018.04.05.07.02.57; Thu, 05 Apr 2018 07:03:11 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751418AbeDEOAS (ORCPT + 99 others); Thu, 5 Apr 2018 10:00:18 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:53536 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750835AbeDEOAQ (ORCPT ); Thu, 5 Apr 2018 10:00:16 -0400 Received: by mail-wm0-f67.google.com with SMTP id p9so5969176wmc.3 for ; Thu, 05 Apr 2018 07:00:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5/2oGXveysf7CjpihQaITFNJNf4X3DdO49lHWv/FKL4=; b=l0bWp4nT9WrjHk6e4JANcz2fjyq4DIYvrncn91tQUAUsPnyVKUE4qzwisIslaKqhsj flO3rM0CLlOuXqLAEi6YHhLjdKRQ3/SKu4Gb5Vc8aEBk6uNjByCq3qXxvr0c+mMMjUkv YcrgQa5FaVHWJPRZno/7qp/ztWr1DyDMBpfKxK7cFKDH3VUQIBw68juocfgvYZGDesE/ Gem50yspG1Ie6EIfWf1NXcj6Q1dKI5OCosBx4TrRbbP7rjVRefvkL5twvqQoplrQoa1E vVNJZoBUvHM/QYx9kH8PeWMgnk7Hqlk/bF6iboJZs1zq9wMWQu5lszsnYtHK+mkr1EoZ vdXg== X-Gm-Message-State: ALQs6tBY7iWTV16PmldJcBwK69IGWpGy19XCNbW5IoT3Gr3q+WC58QXA wsXtemI6vseNCOkmO7vXfiKR3g== X-Received: by 10.80.240.211 with SMTP id a19mr3013563edm.77.1522936814922; Thu, 05 Apr 2018 07:00:14 -0700 (PDT) Received: from shalem.localdomain (546A5441.cm-12-3b.dynamic.ziggo.nl. [84.106.84.65]) by smtp.gmail.com with ESMTPSA id g44sm2888888edc.63.2018.04.05.07.00.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Apr 2018 07:00:14 -0700 (PDT) Subject: Re: [PATCH] ata: ahci-platform: add reset control support To: Thierry Reding Cc: Patrice CHOTARD , Kunihiko Hayashi , Tejun Heo , Matthias Brugger , Rob Herring , Mark Rutland , "linux-ide@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mediatek@lists.infradead.org" References: <1521768653-11824-1-git-send-email-hayashi.kunihiko@socionext.com> <20180405095429.GA7506@ulmo> <1f7d0738-1963-21c5-c293-e46fb0214ecf@redhat.com> <20180405135435.GA10860@ulmo> From: Hans de Goede Message-ID: <6ce60a0b-0409-016a-d29c-91b8b9e2ad07@redhat.com> Date: Thu, 5 Apr 2018 16:00:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180405135435.GA10860@ulmo> Content-Type: text/plain; charset=windows-1252; format=flowed 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 Hi, On 05-04-18 15:54, Thierry Reding wrote: > On Thu, Apr 05, 2018 at 03:27:03PM +0200, Hans de Goede wrote: >> Hi, >> >> On 05-04-18 15:17, Patrice CHOTARD wrote: >>> Hi Thierry >>> >>> On 04/05/2018 11:54 AM, Thierry Reding wrote: >>>> On Fri, Mar 23, 2018 at 10:30:53AM +0900, Kunihiko Hayashi wrote: >>>>> Add support to get and control a list of resets for the device >>>>> as optional and shared. These resets must be kept de-asserted until >>>>> the device is enabled. >>>>> >>>>> This is specified as shared because some SoCs like UniPhier series >>>>> have common reset controls with all ahci controller instances. >>>>> >>>>> Signed-off-by: Kunihiko Hayashi >>>>> --- >>>>> .../devicetree/bindings/ata/ahci-platform.txt | 1 + >>>>> drivers/ata/ahci.h | 1 + >>>>> drivers/ata/libahci_platform.c | 24 +++++++++++++++++++--- >>>>> 3 files changed, 23 insertions(+), 3 deletions(-) >>>> >>>> This causes a regression on Tegra because we explicitly request the >>>> resets after the call to ahci_platform_get_resources(). >>> >>> I confirm, we got exactly the same behavior on STi platform. >>> >>>> >>>> From a quick look, ahci_mtk and ahci_st are in the same boat, adding the >>>> corresponding maintainers to Cc. >>>> >>>> Patrice, Matthias: does SATA still work for you after this patch? This >>>> has been in linux-next since next-20180327. >>> >>> SATA is still working after this patch, but a kernel warning is >>> triggered due to the fact that resets are both requested by >>> libahci_platform and by ahci_st driver. >> >> So in your case you might be able to remove the reset handling >> from the ahci_st driver and rely on the new libahci_platform >> handling instead? If that works that seems like a win to me. >> >> As said elsewhere in this thread I think it makes sense to keep (or re-add >> after a revert) the libahci_platform reset code, but make it conditional >> on a flag passed to ahci_platform_get_resources(). This way we get >> the shared code for most cases and platforms which need special handling >> can opt-out. > > Agreed, although I prefer such helpers to be opt-in, rather than > opt-out. In my experience that tends make the helpers more resilient to > this kind of regression. It also simplifies things because instead of > drivers saying "I want all the helpers except this one and that one", > they can simply say "I want these helpers and that one". In the former > case whenever you add some new (opt-out) feature, you have to update all > drivers and add the exception. In the latter you only need to extend the > drivers that want to make use of the new helper. > > With that in mind, rather than adding a flag to the > ahci_platform_get_resources() function, it might be more flexible to > split the helpers into finer-grained functions. That way drivers can > pick whatever functionality they want from the helpers. Good point, so lets: 1) Revert the patch for now 2) Have a new version of the patch which adds a ahci_platform_get_resets() helper 3) Modify the generic drivers/ata/ahci_platform.c driver to call the new ahci_platform_get_resets() between its ahci_platform_get_resources() and ahci_platform_enable_resources() calls. I think that ahci_platform_enable_resources() should still automatically do the right thing wrt resets if ahci_platform_get_resets() was called (otherwise the resets array will be empty and should be skipped) This should make the generic driver usable for the UniPhier SoCs and maybe some other drivers like the ahci_st driver can also switch to the new ahci_platform_get_resets() functionality to reduce their code a bit. Regards, Hans