Received: by 2002:a05:7412:40d:b0:e2:908c:2ebd with SMTP id 13csp985752rdf; Wed, 22 Nov 2023 02:24:39 -0800 (PST) X-Google-Smtp-Source: AGHT+IHnLzwyiGLhKkb9F9iagRqg4AN1fZhYrIxOhhuO7zUcywQyegtjfD1r/grwCEaVR6y32ocz X-Received: by 2002:a54:410f:0:b0:3ad:fdfb:d384 with SMTP id l15-20020a54410f000000b003adfdfbd384mr1873076oic.53.1700648679220; Wed, 22 Nov 2023 02:24:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700648679; cv=none; d=google.com; s=arc-20160816; b=0BsXqpz6EzICmzeDYaeZq7uMZsm0RCh3/460afuSoFgwjcp0eMku5QCHTULXNDhmDT F2VBPKkzewWe71EBC/D0xAX+IQgIHOxsq5x44wR56OjhE7aTX+SErptda/mwwdGY6aSI E0jT03TfvSErQv+HSr7ClsWgQ9IkGeHg49voH7NxCWH7uuEJEuJym6juTWpzX7As3fAK 1MzjK/y3rYacDBe8IaKa8U027qRHv4HY4QDRkAopgQhP9SzgrXqeKf8h2Acluu/fH7gO itM9S8ehYbKZYNM+jT69NNaHhS2sUGysv4K2j/mtc+YtVd+blZGcSYpB4FwJE07VVCtY Ru6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=sQ2fVfxgkX6Wk5xzHJodZFygZCjeGhtOEt8MmgpiBp8=; fh=1ndqQu9TN2NeubMezyPfztUO1hBQ/5jm/0fERnoIcQA=; b=Y9wM60JJQ2zFqCAZX6iaZWHrBwG2Xa5PEgyAsvSeuIWooVPWLHv7sMEcBE3BCrctQj vQ7MjDSZOM1y7yZzOEc4rwDSD7MuBXQ2f+29wnuYGXKOJPOIuD7mcnsPdeCec7k2W6gJ pdFgdy7qT+NsPh5ycAZP4vH/cJbOA2qPjgSDCDb50wDt1a0JSrbYKKajgviVVvYA+FkY tYy3ujXV1pj1frVRZCeuhyDgReuhNnc7oRyxjgowpJAvgihq3uFW+mWd3cY807Pfi4aw dYzVLr2+cz4ZJmlgkPsN3y560vW2HaQOHUpw4L3mVUEZFg0TUq4Q45nCVnqyo+2lC0bT PAiw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=U6Sz6Ql6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id x20-20020a63fe54000000b005b8615b9fe6si12288329pgj.287.2023.11.22.02.24.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Nov 2023 02:24:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=U6Sz6Ql6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 6FB9C81BDBA2; Wed, 22 Nov 2023 02:24:33 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343781AbjKVKYP (ORCPT + 99 others); Wed, 22 Nov 2023 05:24:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235424AbjKVKX7 (ORCPT ); Wed, 22 Nov 2023 05:23:59 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DD586D4A for ; Wed, 22 Nov 2023 02:23:53 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6440FC433CB; Wed, 22 Nov 2023 10:23:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700648633; bh=5JFmWxBStUIwtcpE4a7iMXC7TQRXmaVsmPRCDYfT7Gc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=U6Sz6Ql6Y6J1hurU5+4b3dfhwhormMAILKpthC/KYgI0IRhlo4GJ/avi8kiUR0gkS vDSQNAqNg12AbSZyvpadGUuDu3DjOv/8fFJ76G9JvRJO5Zv1qgaox4HvGO38xo3mxp exhlZgduMJdFgKgInta0zZPOD6zewO8gjYQKclNo1Iqiq+wq6OP8Ie4gdLfQCMrE3n 3/YZgrVngwtyiBdeea45F7w81pyVoRnkP+Km5jdVeE1iZ5R4ohrUJQZcwlgRmmqNpX sj2f5gD5LSan8ocQWwdN71X6bjVBsEmCuggaEC0r/fEx/Ox1RnSEd//aYxrS0682Wx wmZCPMriHyMuw== Received: from johan by xi.lan with local (Exim 4.96.2) (envelope-from ) id 1r5kOt-0008L3-0g; Wed, 22 Nov 2023 11:24:07 +0100 Date: Wed, 22 Nov 2023 11:24:07 +0100 From: Johan Hovold To: Bjorn Andersson Cc: Bjorn Andersson , Konrad Dybcio , Greg Kroah-Hartman , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Wesley Cheng , Thinh Nguyen , Felipe Balbi , Philipp Zabel , linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Krishna Kurapati PSSNV Subject: Re: [PATCH 03/12] usb: dwc3: qcom: Merge resources from urs_usb device Message-ID: References: <20231016-dwc3-refactor-v1-0-ab4a84165470@quicinc.com> <20231016-dwc3-refactor-v1-3-ab4a84165470@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231016-dwc3-refactor-v1-3-ab4a84165470@quicinc.com> X-Spam-Status: No, score=-1.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Wed, 22 Nov 2023 02:24:33 -0800 (PST) On Mon, Oct 16, 2023 at 08:11:11PM -0700, Bjorn Andersson wrote: > With some ACPI DSDT tables, such as the one found in SC8180X devices, > the USB resources are split between the URSn and it's child USBn device > nodes, in particular the interrupts are placed in the child nodes. > > The solution that was chosen for handling this is to allocate a > platform_device from the child node and selectively pick interrupts > from the main platform_device, or from this created child device, when > creating the platform_device for the DWC3 core. > > This does however not work with the upcoming change where the DWC3 core > is instantiated from the same platform_device as the glue, as the DRD > and host code will attempt to resolve their interrupts from the shared > device, and not the child device. > > Work around this by merging the resources of the child device into the > glue device node, to present a single platform_device with all the > resources necessary. Nice approach. An alternative would be to drop ACPI support completely as Konrad suggested. Should simplify both this series and the multiport one. Is anyone really using the ACPI support here anymore? > -static struct platform_device * > -dwc3_qcom_create_urs_usb_platdev(struct device *dev) > +static int dwc3_qcom_acpi_merge_urs_resources(struct platform_device *pdev) > { > + struct device *dev = &pdev->dev; > + struct list_head resource_list; > + struct resource_entry *rentry; > + struct resource *resources; > struct fwnode_handle *fwh; > struct acpi_device *adev; > char name[8]; > + int count; > int ret; > int id; > + int i; > > /* Figure out device id */ > ret = sscanf(fwnode_get_name(dev->fwnode), "URS%d", &id); > if (!ret) > - return NULL; > + return -EINVAL; > > /* Find the child using name */ > snprintf(name, sizeof(name), "USB%d", id); > fwh = fwnode_get_named_child_node(dev->fwnode, name); > if (!fwh) > - return NULL; > + return 0; > > adev = to_acpi_device_node(fwh); > if (!adev) > - return NULL; > + return -EINVAL; This is currently leaking a reference to the fwnode, I fixed that up here: https://lore.kernel.org/linux-usb/20231117173650.21161-4-johan+linaro@kernel.org/ > + INIT_LIST_HEAD(&resource_list); > + > + count = acpi_dev_get_resources(adev, &resource_list, NULL, NULL); > + if (count <= 0) > + return count; > + > + count += pdev->num_resources; > + > + resources = kcalloc(count, sizeof(*resources), GFP_KERNEL); > + if (!resources) { > + acpi_dev_free_resource_list(&resource_list); > + return -ENOMEM; > + } > + > + memcpy(resources, pdev->resource, sizeof(struct resource) * pdev->num_resources); > + count = pdev->num_resources; > + list_for_each_entry(rentry, &resource_list, node) { > + /* Avoid inserting duplicate entries, in case this is called more than once */ Either shorten this one or make it a multiline comment to stay within 80 chars. > + for (i = 0; i < count; i++) { Should this not be pdev->num_resources? > + if (resource_type(&resources[i]) == resource_type(rentry->res) && > + resources[i].start == rentry->res->start && > + resources[i].end == rentry->res->end) > + break; > + } > + > + if (i == count) Same here. > + resources[count++] = *rentry->res; > + } > > - return acpi_create_platform_device(adev, NULL); > + ret = platform_device_add_resources(pdev, resources, count); > + if (ret) > + dev_err(&pdev->dev, "failed to add resources\n"); > + > + acpi_dev_free_resource_list(&resource_list); > + kfree(resources); > + > + return ret; > } > > static int dwc3_qcom_probe(struct platform_device *pdev) > @@ -817,6 +853,12 @@ static int dwc3_qcom_probe(struct platform_device *pdev) > dev_err(&pdev->dev, "no supporting ACPI device data\n"); > return -EINVAL; > } > + > + if (qcom->acpi_pdata->is_urs) { > + ret = dwc3_qcom_acpi_merge_urs_resources(pdev); > + if (ret < 0) > + goto clk_disable; The clocks have not been enabled here, just return ret. > + } > } > > qcom->resets = devm_reset_control_array_get_optional_exclusive(dev); > @@ -857,18 +899,6 @@ static int dwc3_qcom_probe(struct platform_device *pdev) > qcom->acpi_pdata->qscratch_base_offset; > parent_res->end = parent_res->start + > qcom->acpi_pdata->qscratch_base_size; > - > - if (qcom->acpi_pdata->is_urs) { > - qcom->urs_usb = dwc3_qcom_create_urs_usb_platdev(dev); > - if (IS_ERR_OR_NULL(qcom->urs_usb)) { > - dev_err(dev, "failed to create URS USB platdev\n"); > - if (!qcom->urs_usb) > - ret = -ENODEV; > - else > - ret = PTR_ERR(qcom->urs_usb); > - goto clk_disable; > - } > - } > } > > qcom->qscratch_base = devm_ioremap_resource(dev, parent_res); Johan