From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0127CC433E0 for ; Fri, 31 Jul 2020 15:08:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CCA2821744 for ; Fri, 31 Jul 2020 15:08:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728927AbgGaPIb (ORCPT ); Fri, 31 Jul 2020 11:08:31 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:37060 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728697AbgGaPIb (ORCPT ); Fri, 31 Jul 2020 11:08:31 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1k1Wdz-007iHg-2n; Fri, 31 Jul 2020 17:08:23 +0200 Date: Fri, 31 Jul 2020 17:08:23 +0200 From: Andrew Lunn To: "Rafael J. Wysocki" Cc: Sudeep Holla , Jeremy Linton , Calvin Johnson , Russell King - ARM Linux admin , Jon , Cristi Sovaiala , Ioana Ciornei , Andy Shevchenko , Florian Fainelli , Madalin Bucur , netdev , linux.cj@gmail.com, ACPI Devel Maling List , Vikas Singh Subject: Re: [net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO PHY Message-ID: <20200731150823.GH1712415@lunn.ch> References: <20200715090400.4733-1-calvin.johnson@oss.nxp.com> <20200715090400.4733-2-calvin.johnson@oss.nxp.com> <1a031e62-1e87-fdc1-b672-e3ccf3530fda@arm.com> <20200724133931.GF1472201@lunn.ch> <97973095-5458-8ac2-890c-667f4ea6cd0e@arm.com> <20200724191436.GH1594328@lunn.ch> <20200727172136.GC8003@bogus> <20200728203437.GB1748118@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org > However, if those properties are never going to be supplied via ACPI > on any production systems, the code added in order to be able to > process them will turn out to be useless and I don't think anyone > wants useless code in the kernel. > > So the real question is whether or not there will be production > systems in which those properties will be supplied via ACPI and I > cannot answer that question. Hi Rafael I suspect we are going to have a lot of newbie ACPI questions over the next few weeks/months as vendors and the PHY maintainers get up to speed on all this. In the device tree world, we would expect a patch as part of the patchset to a device tree file somewhere under arch/*/boot/dts to make use of any new property added. We then know it is used. How does this work in the ACPI world? How does somebody show they are supplying the property in a production system? > Basically, the interested vendors need to agree on how exactly they > want ACPI to be used and come up with a specification setting the > rules to be followed by the platform firmware on the one side and by > the code in the kernel on the other side. ... > Besides, you really should be asking for a spec the work is based on, > IMO, instead of asking for an ACPI maintainer ACK which is not going > to be sufficient if the former is missing anyway. Could you point us towards real world example specs? Giving us a good best practice example would likely help us to do this work. And reduce the amount of work you need to do keeping the process going in the correct direction. Thanks Andrew