lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 14 Jun 2021 02:08:19 +0200 From: Andrew Lunn <andrew@...n.ch> To: Marcin Wojtas <mw@...ihalf.com> Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, netdev <netdev@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Russell King - ARM Linux <linux@...linux.org.uk>, Grzegorz Jaszczyk <jaz@...ihalf.com>, Grzegorz Bernacki <gjb@...ihalf.com>, upstream@...ihalf.com, Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@....com>, Jon Nettleton <jon@...id-run.com>, Jon Masters <jcm@...hat.com>, rjw@...ysocki.net, lenb@...nel.org Subject: Re: [net-next: PATCH 2/3] net: mvpp2: enable using phylink with ACPI On Mon, Jun 14, 2021 at 01:46:06AM +0200, Marcin Wojtas wrote: > <Adding ACPI Maintainers> > > Hi Andrew, > > niedz., 13 cze 2021 o 23:35 Andrew Lunn <andrew@...n.ch> napisaĆ(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-rules.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 = fwnode_property_read_u32(fixed_node, "speed", &speed); > > phylink.c: if (fwnode_property_read_bool(fixed_node, "full-duplex")) > > phylink.c: if (fwnode_property_read_bool(fixed_node, "pause")) > > phylink.c: if (fwnode_property_read_bool(fixed_node, "asym-pause")) > > phylink.c: ret = fwnode_property_read_u32_array(fwnode, "fixed-link", > > phylink.c: ret = fwnode_property_read_u32_array(fwnode, "fixed-link", > > phylink.c: if (dn || fwnode_property_present(fwnode, "fixed-link")) > > phylink.c: if ((fwnode_property_read_string(fwnode, "managed", &managed) == 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. My real fear is snowflakes. Each ACPI implementation is unique. That is going to be a maintenance nightmare, and it will make it very hard to change the APIs between phylib/phylink and MAC drivers. To avoid that, we need to push are much as possible into the core, document as much as possible, and NACK anything does looks like a snowflake. I actually like what you pointed out above. It makes it possible to say, ACPI for phylink/phylib needs to follow device tree, 1 to 1. It also means we should be able to remove a lot of the if (is_of()) {} else if (is_acpi() {} else return -EINVAL; in drivers, and put it into the core. Andrew
Powered by blists - more mailing lists