Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp1404554rwb; Fri, 19 Aug 2022 03:09:35 -0700 (PDT) X-Google-Smtp-Source: AA6agR7XfxLF0wTHduZKEZjA3oUMvVzHye3dkY1cVmsSMW7Qa/9m1Cc4ctJZeEzOwGidEZh+pKYn X-Received: by 2002:a17:907:75c1:b0:730:aa62:7f65 with SMTP id jl1-20020a17090775c100b00730aa627f65mr4349390ejc.355.1660903774808; Fri, 19 Aug 2022 03:09:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660903774; cv=none; d=google.com; s=arc-20160816; b=jgfUPYGMoCGJlzIFVRD/5xFEOlURap2z4q/KsSOZOLxGrl6wBQPBfn6jMtVGZ1n1FI kyEnjVnz+sSLjX3KdlW6EA97XjLV491uF6o1tnVhkgyHSe6DdnYwE2H/MGkF6gPt9ryf 2yyEvpQzG0DV9IpgCYbU4gKTS+qlcoOBJxVKyvUDwmsKW4Kw5+0iYgRzPh4ygv8eYt8L SrlmRsbbq6F4fTfnh6C72wqhnivVxo7I18fFPM941l8+AIZZbEviOMOEsIb435M477dE Lsr6HsX+i74ZIUl7WAuV8IuN218rI6KXNiB/NGkrrXc/C3a9v/27KawLgMyQyY7RegG+ 2iwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=94B01Gvctqm4iZb3YaOuzMT52V6OgD2x7D5RRY0ZFzw=; b=PmnJOyIAwh7HK0I/Gmhjmig38x7PAolil62Ip+cUEf1aOhoPK0ydl0Iixip76zawgq wFORSnSbBeEQgS2tOKB9ahSL+ao1JVhZYIjzcyX8Mo4Pbl7B/RcL40odviN+m6kOGifr fTnqwK7SSVrGkqS3XNXexXkQPcxX5+zTqzQMicuVWB1jnaVT+PdsOJPWapBvy9i0s/Yc h9qMOTJI8A4TGTesECv8ZmM1c7hqeRrEtP4W8VUdfPC9zh/KOZTa6sp1h0EUaQ5j3+W2 rT9ELLRssD5/njUq+peE2yUNcm3vhadghICilg6SkP+8WzxrC1sPNcrxoZ7TCxgBGQOL W4Bw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=o1V0XSLJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gv13-20020a1709072bcd00b007316ac034c1si2407676ejc.496.2022.08.19.03.09.08; Fri, 19 Aug 2022 03:09:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=o1V0XSLJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347248AbiHSKAo (ORCPT + 99 others); Fri, 19 Aug 2022 06:00:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37090 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348318AbiHSKAf (ORCPT ); Fri, 19 Aug 2022 06:00:35 -0400 Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 320C9F4C9B; Fri, 19 Aug 2022 03:00:35 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id m5so2931859qkk.1; Fri, 19 Aug 2022 03:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=94B01Gvctqm4iZb3YaOuzMT52V6OgD2x7D5RRY0ZFzw=; b=o1V0XSLJIWh+tpsX9B0VfDB/c4/woloHTVa4Ybbh+/3u2FxigROJrA+XJtfyQGS2E0 MIw7LavzGksRp2yh4sxMocn55skcXS4M00j0vSRlit7DVS7uy7e+ITcSCGowRNUZ1lkX bZz7iOA1eENwi52gl1b9QI51PvEkfiJoRpzhb0vd3SE8/Zn20hHZH23U5OBsq6+4Yhph u1euertaisnMzwHSOy8hcsTs6YNmsXmbRlYoac19igsWFwhmlQQ5qB+4cLBHnr6Cx0Rj 33eswkKqaGcnWDxGdrAWkMPm3wLuy3BJTAF4fBRR42lUDbdFaTHZLLcSvUw+8Fc9ZCqR tMnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=94B01Gvctqm4iZb3YaOuzMT52V6OgD2x7D5RRY0ZFzw=; b=l9X33QUbAa1HXX5fHNor/4jPw5y15RGf5BV/317PNVK8p5v7+yoJZYxJjdT5k0PlIV KynA6zkG9qV8DF3xv3/29SOKnZxqdz6WlroSSrAxuDoZTvV25g9EaSFUB5ZDICqr+ujd Tm9VIo6yFwx/jPjvgIr+3DigpKygdooz3C9pEw404evhiKupCA8lKqpn/hV3fqJdZR4/ iRlzXyhID+3rmjYeicOsDPLh0fOh51HRd9NA6vUAs5lglrMnLs4R8P+YL5zZ1CokNfVt 00PEpIs2JzGa/kBa3MxPI8/7J1GtgahaXA4ETAAMRx54FncL6iqPdY3QSHwiVi+Dl3Ct KLxw== X-Gm-Message-State: ACgBeo1o9vFptQdroe71ntPSmK2xcB+1QCxSvC4mtydxwJ6vF4dO6cYg sM+1TDvyIdkTEarU60gN7xUb4Fs5eT+yafUn2FXiAuNk3agE0g== X-Received: by 2002:ae9:e311:0:b0:6ba:e711:fb27 with SMTP id v17-20020ae9e311000000b006bae711fb27mr4659635qkf.320.1660903234293; Fri, 19 Aug 2022 03:00:34 -0700 (PDT) MIME-Version: 1.0 References: <1660649244-146842-1-git-send-email-john.garry@huawei.com> <1660649244-146842-2-git-send-email-john.garry@huawei.com> <366fd6dd-a37b-c7ec-fdf3-48f8a8024834@huawei.com> In-Reply-To: <366fd6dd-a37b-c7ec-fdf3-48f8a8024834@huawei.com> From: Andy Shevchenko Date: Fri, 19 Aug 2022 12:59:58 +0300 Message-ID: Subject: Re: [PATCH PoC 1/3] ACPI / PNP: Don't add enumeration_by_parent devices To: John Garry Cc: Len Brown , "Rafael J. Wysocki" , ACPI Devel Maling List , Linux Kernel Mailing List , Linuxarm Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 19, 2022 at 11:05 AM John Garry wrote: > > On 18/08/2022 20:31, Andy Shevchenko wrote: > >> For the hisi_lpc driver, for the UART ACPI node we have a binding like: > >> > >> Device (LPC0.CON0) { > >> Name (_HID, "HISI1031") > >> Name (_CID, "PNP0501") > >> Name (LORS, ResourceTemplate() { > >> QWordIO ( > >> > >> We have the compat and hid string. The ACPI/PNP code matches the compat > >> string first, and creates the PNP device. In doing so, the acpi_device > >> created has physical_node_count member set in acpi_bind_one(). > >> > >> The hisi_lpc driver also creates a platform device serial device for uart, > >> which is the actual uart which we want to use - see > >> hisi_lpc_acpi_add_child(). That function does not check > >> physical_node_count value, but acpi_create_platform_device() does check it. > >> So if we were to move hisi_lpc_acpi_add_child() across to use > >> acpi_create_platform_device(), then the change in this patch is required to > >> not create the PNP binding (so that physical_node_count is not set from > >> PNP probe). > > Hmm... The flag, as I interpret it, is equal to "the device in > > question is a peripheral device to the non-discoverable bus, such as > > SPI, I2C or UART". I.o.w. I do not see how PNP suits here. So, from my > > point of view it seems like an abuse of the flag. Not sure the current > > state of affairs in ACPI glue layer regarding this, though. > Sorry, but I'm not following you here. Which flag are you talking about? "enumerated by parent". -- With Best Regards, Andy Shevchenko