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: Thu, 28 Jul 2022 22:18:29 +0200 From: Andrew Lunn <andrew@...n.ch> To: Vladimir Oltean <olteanv@...il.com> Cc: Marcin Wojtas <mw@...ihalf.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, ACPI Devel Maling List <linux-acpi@...r.kernel.org>, netdev <netdev@...r.kernel.org>, "Rafael J. Wysocki" <rafael@...nel.org>, Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Sean Wang <sean.wang@...iatek.com>, Landen Chao <Landen.Chao@...iatek.com>, Linus Walleij <linus.walleij@...aro.org>, Vivien Didelot <vivien.didelot@...il.com>, Florian Fainelli <f.fainelli@...il.com>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Russell King - ARM Linux <linux@...linux.org.uk>, Heiner Kallweit <hkallweit1@...il.com>, Grzegorz Bernacki <gjb@...ihalf.com>, Grzegorz Jaszczyk <jaz@...ihalf.com>, Tomasz Nowicki <tn@...ihalf.com>, Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@....com>, upstream@...ihalf.com Subject: Re: [net-next: PATCH v3 6/8] net: core: switch to fwnode_find_net_device_by_node() > The 'label' thing is actually one of the things that I'm seriously > considering skipping parsing if this is an ACPI system, simply because > best practices are different today than they were when the OF bindings > were created. Agreed. We want the ACPI binding to learn from what has worked and not worked in DT. We should clean up some of the historical mess. And enforce things we don't in DT simply because there is too much history. So a straight one to one conversion is not going to happen. > It can be debated what exactly is at fault there, although one > interpretation can be that the DT bindings themselves are to blame, > for describing a circular dependency between a parent and a child. DT describes hardware. I'm not sure hardware can have a circular dependency. It is more about how software make use of that hardware description that ends up in circular dependencies. Andrew
Powered by blists - more mailing lists