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 DE9D4C433E0 for ; Fri, 24 Jul 2020 19:20:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C89AA2065E for ; Fri, 24 Jul 2020 19:20:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726553AbgGXTUP (ORCPT ); Fri, 24 Jul 2020 15:20:15 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:54246 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726411AbgGXTUP (ORCPT ); Fri, 24 Jul 2020 15:20:15 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1jz3En-006iai-0R; Fri, 24 Jul 2020 21:20:09 +0200 Date: Fri, 24 Jul 2020 21:20:08 +0200 From: Andrew Lunn To: Florian Fainelli Cc: Jeremy Linton , Calvin Johnson , Russell King - ARM Linux admin , Jon , Cristi Sovaiala , Ioana Ciornei , Andy Shevchenko , Madalin Bucur , netdev@vger.kernel.org, linux.cj@gmail.com, linux-acpi@vger.kernel.org Subject: Re: [net-next PATCH v7 1/6] Documentation: ACPI: DSD: Document MDIO PHY Message-ID: <20200724192008.GI1594328@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > We are at v7 of this patch series, and no authoritative ACPI Linux > maintainer appears to have reviewed this, so there is no clear sign of > this converging anywhere. This is looking a lot like busy work for > nothing. Given that the representation appears to be wildly > misunderstood and no one seems to come up with something that reaches > community agreement, what exactly is the plan here? I think we need to NACK all attempts to add ACPI support to phylib and phylink until an authoritative ACPI Linux maintainer makes an appearance and actively steers the work. And not just this patchset, but all patchsets in the networking domain which have an ACPI component. Andrew