Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3247046imu; Wed, 7 Nov 2018 07:24:17 -0800 (PST) X-Google-Smtp-Source: AJdET5dEPCmnjOd1RWitt4Sj17M8mfca7jkKRs5XR2AzzdFmCT1LXPN4ZxudQvF6gP3FgLLTFtpL X-Received: by 2002:a62:39d2:: with SMTP id u79-v6mr655393pfj.116.1541604257592; Wed, 07 Nov 2018 07:24:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541604257; cv=none; d=google.com; s=arc-20160816; b=ioZREiN7xkhDF4zgdkcLdfDmO8KwD8pTH7M587DSqzfDf6FNr5B+ruh6ZB4fMHcM8V d0uEXlTbunF7OwtAFscF84tFEfJJu+Oh2uq0RUj6umasq2+0AbONaOc7uSZl/UwY4Bcg Tb+aRV+7NEX6UhalaLMvKcJLca3q2pTe0EALnbVRkMQE8lrPRb5JyaWrdF1EqvrFZGzp EAzIAPR/QfMew4gBDAiQlJnTdirUGFAFF/QJIo0EFH4ZDmm8fSOsRg1xdXPvrNBPXDv/ d2JbxUWEFN8Rmh+StyqybDKOZmu2DNWzUwt5bZ2w8RinvFZtbWwlwGYqVg02eqONreMJ mmeg== 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:mime-version :message-id:in-reply-to:subject:cc:to:from:date; bh=NROdVIexHSNrwyhN94HjTyaLIfprTivGFXhPEjcWkMk=; b=j0s7RRRvMZr2VSpdYbfO0eZfEVbhvrtXfiisjkXh35uo/HXUjyT3a+dz/tGIBGAA2e a7n61YQQTPIgiFRP164UE15YIoFDAyTkr3XFclbMQftm0Gx2pCoM7Nf8xZdLvnof7jmu J2oPaYRombKmI6IFz2/2qc55A7qBWfiC9CcLDr9cDjZaPNQ4X2ACfryV4vL5dzjlwz8Q IC5oMmFR0v1QWdxO7xjdsYVLvuxZgkWX98xaR7Z/W21zbljIwryGuUGKQAJCtUJpa5wx +bbdckm4BOslQB4B7oOL8U+aVO9Ve3Ocrt6EffQ9eW2Lhxvbbir2weoDV5QRPL7IgOTe Oukw== 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 t19-v6si891436plr.334.2018.11.07.07.24.01; Wed, 07 Nov 2018 07:24:17 -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 S1727659AbeKHAyN (ORCPT + 99 others); Wed, 7 Nov 2018 19:54:13 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:47286 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726830AbeKHAyN (ORCPT ); Wed, 7 Nov 2018 19:54:13 -0500 Received: (qmail 1735 invoked by uid 2102); 7 Nov 2018 10:23:23 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Nov 2018 10:23:23 -0500 Date: Wed, 7 Nov 2018 10:23:23 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Florian Fainelli cc: Al Cooper , Al Cooper , , Alban Bedel , Alex Elder , Andrew Morton , Arnd Bergmann , Avi Fishman , , Bjorn Andersson , Chunfeng Yun , "David S. Miller" , , Dmitry Osipenko , Greg Kroah-Hartman , "Gustavo A. R. Silva" , Hans de Goede , James Hogan , Jianguo Sun , Johan Hovold , Kees Cook , , Lu Baolu , Mark Rutland , Martin Blumenstingl , Mathias Nyman , Mathias Nyman , Mauro Carvalho Chehab , Rishabh Bhatnagar , Rob Herring , Roger Quadros Subject: Re: [PATCH V3 4/6] usb: ohci-platform: Add support for Broadcom STB SoC's In-Reply-To: <674c3275-de47-57f4-84aa-58b318aef67b@gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 6 Nov 2018, Florian Fainelli wrote: > On 11/6/18 1:40 PM, Al Cooper wrote: > > On 11/6/18 11:08 AM, Alan Stern wrote: > >> On Mon, 5 Nov 2018, Al Cooper wrote: > >> > >>> Add support for Broadcom STB SoC's to the ohci platform driver. > >>> > >>> Signed-off-by: Al Cooper > >>> --- > >> > >>> @@ -177,6 +189,8 @@ static int ohci_platform_probe(struct > >>> platform_device *dev) > >>>           ohci->flags |= OHCI_QUIRK_FRAME_NO; > >>>       if (pdata->num_ports) > >>>           ohci->num_ports = pdata->num_ports; > >>> +    if (pdata->suspend_without_phy_exit) > >>> +        hcd->suspend_without_phy_exit = 1; > >> > >> Sorry if I missed this in the earlier discussions...  Is there any > >> possibility of adding a DT binding that could express this requirement, > >> instead of putting it in the platform data? > >> > >> Alan Stern > >> > > > > Alan, > > > > That was my original approach but internal review suggested that I use > > pdata instead. Below is my original patch for: > > And the reason for that suggestion was really because it was percevied > as encoding a driver behavior as a Device Tree property as opposed to > describing something that was inherently and strictly a hardware > behavior (therefore suitable for Device Tree). Right. The best way to approach this problem is to identify and characterize the hardware behavior which makes this override necessary. Then _that_ can be added to DT, since it will be a property of the hardware rather than of the driver. > > Add the ability to skip calling the PHY's exit routine on suspend > > and the PHY's init routine on resume. This is to handle a USB PHY > > that should have it's power_off function called on suspend but cannot > > have it's exit function called because on exit it will disable the > > PHY to the point where register accesses to the Host Controllers > > using the PHY will be disabled and the host drivers will crash. What's special about this PHY? Why does the exit function mess the PHY up? Or to put it another way, why doesn't the exit function mess up other PHYs in the same way? For that matter, can we change the code so that suspend doesn't call the exit function for _any_ PHY? Will just calling the power_off function be good enough? If not, then why not? Alan Stern