From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753368AbdJKOoC (ORCPT ); Wed, 11 Oct 2017 10:44:02 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:41062 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751609AbdJKOoA (ORCPT ); Wed, 11 Oct 2017 10:44:00 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org A81C2601D2 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=awallis@codeaurora.org Subject: Re: [PATCH 4.13 077/160] usb: host: xhci-plat: allow sysdev to inherit from ACPI To: Greg Kroah-Hartman , "Thang Q. Nguyen" Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Mathias Nyman References: <20171010190548.690912997@linuxfoundation.org> <20171010190551.823634273@linuxfoundation.org> <20171011115306.GB15099@kroah.com> From: Adam Wallis Message-ID: Date: Wed, 11 Oct 2017 10:43:56 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171011115306.GB15099@kroah.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/11/2017 7:53 AM, Greg Kroah-Hartman wrote: > On Wed, Oct 11, 2017 at 11:19:41AM +0700, Thang Q. Nguyen wrote: >> Hi, >> >> On Wed, Oct 11, 2017 at 2:50 AM, Greg Kroah-Hartman >> wrote: >> >> 4.13-stable review patch.  If anyone has any objections, please let me >> know. >> >> ------------------ >> >> From: Adam Wallis >> >> commit c6b8e79306f515b5483eb11076e0fbfc140434a8 upstream. >> >> Commit 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA configuration") >> updated the method determining DMA for XHCI from sysdev. However, this >> patch broke the ability to enumerate the FWNODE from parent ACPI devices >> from the child plat XHCI device. >> >> Currently, xhci_plat is not set up properly when the parent device is an >> ACPI node. The conditions that xhci_plat_probe should satisfy are >> >> 1. xhci_plat comes from firmware >> 2. xhci_plat is child of a device from firmware (dwc3-plat) >> 3. xhci_plat is grandchild of a pci device (dwc3-pci) >> >> Case 2 is covered when the child is an OF node (by checking >> sysdev->parent->of_node), however, an ACPI parent will return NULL in >> the of_node check and will thus not result in sysdev being set to >> sysdev->parent >> >> [   17.591549] xhci-hcd: probe of xhci-hcd.6.auto failed with error -5 >> >> This change adds a check for ACPI to completely allow for condition 2. >> This is done by first checking if the parent node is of type ACPI (e.g., >> dwc3-plat) and set sysdev to sysdev->parent if either of the two >> following conditions are met: >> >> 1: If fwnode is empty (in the case that platform_device_add_properties >> was not called on the allocated platform device) >> 2: fwnode exists but is not of type ACPI (this would happen if >> platform_device_add_properties was called on the allocated device. >> Instead of type FWNODE_ACPI, you would end up with FWNODE_PDATA) >> >> Fixes: 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA configuration") >> Tested-by: Thang Q. Nguyen >> Signed-off-by: Adam Wallis >> Signed-off-by: Mathias Nyman >> Signed-off-by: Greg Kroah-Hartman >> >> --- >>  drivers/usb/host/xhci-plat.c |   16 ++++++++++------ >>  1 file changed, 10 insertions(+), 6 deletions(-) >> >> --- a/drivers/usb/host/xhci-plat.c >> +++ b/drivers/usb/host/xhci-plat.c >> @@ -186,14 +186,18 @@ static int xhci_plat_probe(struct platfo >>          * 2. xhci_plat is child of a device from firmware (dwc3-plat) >>          * 3. xhci_plat is grandchild of a pci device (dwc3-pci) >>          */ >> -       sysdev = &pdev->dev; >> -       if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node) >> -               sysdev = sysdev->parent; >> +       for (sysdev = &pdev->dev; sysdev; sysdev = sysdev->parent) { >> +               if (is_of_node(sysdev->fwnode) || >> +                       is_acpi_device_node(sysdev->fwnode)) >> +                       break; >>  #ifdef CONFIG_PCI >> -       else if (sysdev->parent && sysdev->parent->parent && >> -                sysdev->parent->parent->bus == &pci_bus_type) >> -               sysdev = sysdev->parent->parent; >> +               else if (sysdev->bus == &pci_bus_type) >> +                       break; >>  #endif >> +       } >> + >> +       if (!sysdev) >> +               sysdev = &pdev->dev; >> >>         /* Try to set 64-bit DMA first */ >>         if (WARN_ON(!sysdev->dma_mask)) >> >> >> >> This patch and Sriram's patches below should come together: >> >> d64ff406e5("usb: dwc3: use bus->sysdev for DMA configuration") >> >> 8c9f2de459("usb: dwc3: Do not set dma coherent mask") >> >> a8c06e407e("usb: separate out sysdev pointer from usb_bus") >> >> aeb78cda51("usb: chipidea: use bus->sysdev for DMA configuration") >> >> 8123e4953f("usb: ehci: fsl: use bus->sysdev for DMA configuration") >> >> 4c39d4b949("usb: xhci: use bus->sysdev for DMA configuration") >> >> Otherwise, the below issue still happen: >> >> [   17.591549] xhci-hcd: probe of xhci-hcd.6.auto failed with error -5 >> >>   >> >> The first 2 above patches are in linux-stable.git/linux-4.11.y. And all above >> Sriram's patches are in linux-stable.git/linux-4.12.y. This means we need the >> followings: >> >> - Apply this patch and 4 missing Sriram's patches into linux-4.11.y. >> >> - Apply this patch into linux-4.12.y > > Huh? As Mathias said, all of the 4.11 and 4.12 patches are in 4.13, > right? We better not have missed them, as that is _not_ how we do > kernel development and version branching. > > Can you please verify this? This patch applies directly on 4.13. All required patches are already in 4.13 as Mathias mentioned > > Also note that 4.11.y and 4.12.y are end-of-life, and we in the > community are not adding any new patches to it. If you have a crazy > vendor that feels they want to maintain one of these kernel versions on > their own, then please go talk to them about it :) > > thanks, > > greg k-h > -- Adam Wallis Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.