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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 C8756C48BDF for ; Sun, 13 Jun 2021 23:46:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A548460FE4 for ; Sun, 13 Jun 2021 23:46:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232237AbhFMXsj (ORCPT ); Sun, 13 Jun 2021 19:48:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232076AbhFMXse (ORCPT ); Sun, 13 Jun 2021 19:48:34 -0400 Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 795B6C061766 for ; Sun, 13 Jun 2021 16:46:19 -0700 (PDT) Received: by mail-qv1-xf35.google.com with SMTP id w4so12146008qvr.11 for ; Sun, 13 Jun 2021 16:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=yLX/ur54moqzu2PisxABzO9lUlcTtlTTvRud0ukIiTk=; b=iJysEGEpYjvUbxf5+O4wQ1DEhhnGeJwGafwWPI9gepZeKQeb7Gn/IENgjQsuPaMrk1 9IjCl9PwgVeaU15y4JXUGCWcU3ROOoA1O1Ky7x0HFWt1uOtieTa7AKY8GLPtDGj0Tgl2 G1ur5vWkCdj6WPCe1PYLkXVZHpGk/DuzIZ7YMHox3J0i1yKDHzwgHsT/G0L2A+wBiuCM NRB+jWVbH30meokSi6YF0eiV0GhziuNpJdX3tfGvFq4VPkuDy/esPKdv37XONc38GxRK pKM4BBOw2p0YAPTH65QJXjI7h/jE8nd/YtIthzvfP3S+fSooCNHfghgeMzGmVhhOvKHA 2EOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=yLX/ur54moqzu2PisxABzO9lUlcTtlTTvRud0ukIiTk=; b=bgzmxxFnJVYbGwNfnsn8HfsisBlapXSD/5r/swNOSIYk/f7VDZQNdG1IrckAc+b3JX QbXIeMKEsPzvLyBlA+RAGKhAMrLNZ+E4QjIYcroSC0VB08oVhKGEaiEqalQ73evQVBDA Eo+nPtXg2VvrN0PxbK3+nWicO/+Wr+jJqNraUByYz6NsSC5tVv/j44Dbta6MRER0cRMf brFyb/ERENcd1LtjHqgMeCHsYPbxLCvygndaSpRRDmQrmj7Jc7IBTEp9NWj4o4gSEK+R SunvfA4V3TAuUqsuBbvjLVxauXh+b54loBjvN0+NQHHgUtz6e4S9uMivYuaIR9ilmuoo HyCg== X-Gm-Message-State: AOAM530KcpAUVda17NyK8vIvQMX1f3rPtBclAzA0avud43VKua2B0JGC Nei7W/t3eWqN+mpmdiS/1uVxR/o2jC5c6+JQB8yBaA== X-Google-Smtp-Source: ABdhPJwVZOm0oZpxf/OFlCWVmNh53+dZLinoQHcz6FQlzXLDzr1idWR0CVdsHuZH4Is3newhFtg94mhPJrdY7YqInig= X-Received: by 2002:ad4:5f0e:: with SMTP id fo14mr3043268qvb.16.1623627978540; Sun, 13 Jun 2021 16:46:18 -0700 (PDT) MIME-Version: 1.0 References: <20210613183520.2247415-1-mw@semihalf.com> <20210613183520.2247415-3-mw@semihalf.com> In-Reply-To: From: Marcin Wojtas Date: Mon, 14 Jun 2021 01:46:06 +0200 Message-ID: Subject: Re: [net-next: PATCH 2/3] net: mvpp2: enable using phylink with ACPI To: Andrew Lunn Cc: Linux Kernel Mailing List , netdev , "David S. Miller" , Jakub Kicinski , Russell King - ARM Linux , Grzegorz Jaszczyk , Grzegorz Bernacki , upstream@semihalf.com, Samer El-Haj-Mahmoud , Jon Nettleton , Jon Masters , rjw@rjwysocki.net, lenb@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andrew, niedz., 13 cze 2021 o 23:35 Andrew Lunn napisa=C5=82(a): > > > True. I picked the port type properties that are interpreted by > > phylink. Basically, I think that everything that's described in: > > devicetree/bindings/net/ethernet-controller.yaml > > is valid for the ACPI as well > > So you are saying ACPI is just DT stuff into tables? Then why bother > with ACPI? Just use DT. Any user is free to use whatever they like, however apparently there must have been valid reasons, why ARM is choosing ACPI as the preferred way of describing the hardware over DT. In such circumstances, we all work to improve adoption and its usability for existing devices. Regarding the properties in _DSD package, please refer to https://www.kernel.org/doc/html/latest/firmware-guide/acpi/DSD-properties-r= ules.html, especially to two fragments: "The _DSD (Device Specific Data) configuration object, introduced in ACPI 5.1, allows any type of device configuration data to be provided via the ACPI namespace. In principle, the format of the data may be arbitrary [...]" "It often is useful to make _DSD return property sets that follow Device Tree bindings." Therefore what I understand is that (within some constraints) simple reusing existing sets of nodes' properties, should not violate ACPI spec. In this patchset no new extension/interfaces/method is introduced. > > Right, O.K. Please document anything which phylink already supports: > > hylink.c: ret =3D fwnode_property_read_u32(fixed_node, "spe= ed", &speed); > phylink.c: if (fwnode_property_read_bool(fixed_node, "full-d= uplex")) > phylink.c: if (fwnode_property_read_bool(fixed_node, "pause"= )) > phylink.c: if (fwnode_property_read_bool(fixed_node, "asym-p= ause")) > phylink.c: ret =3D fwnode_property_read_u32_array(fwnode, "f= ixed-link", > phylink.c: ret =3D fwnode_property_read_u32_array(fwnode, "f= ixed-link", > phylink.c: if (dn || fwnode_property_present(fwnode, "fixed-link")) > phylink.c: if ((fwnode_property_read_string(fwnode, "managed", &mana= ged) =3D=3D 0 && > > If you are adding new properties, please do that In a separate patch, > which needs an ACPI maintainer to ACK it before it gets merged. > Ok, I can extend the documentation. Best regards, Marcin