From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lunn Subject: Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support Date: Sun, 21 Jan 2018 19:55:59 +0100 Message-ID: <20180121185559.GC9004@lunn.ch> References: <20180109130012.GA27447@lunn.ch> <20180118123141.GA2839@e107981-ln.cambridge.arm.com> <20180118130026.GG32299@lunn.ch> <20180120195246.GC27654@lahna.fi.intel.com> <20180121010840.GB1217@lunn.ch> <20180121102700.GF27654@lahna.fi.intel.com> <20180121161319.GA8017@lunn.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Ard Biesheuvel Cc: Mika Westerberg , Nadav Haklai , Neta Zur Hershkovits , Lorenzo Pieralisi , Russell King - ARM Linux , Grzegorz Jaszczyk , Tomasz Nowicki , "Rafael J. Wysocki" , "linux-acpi@vger.kernel.org" , Ezequiel Garcia , Florian Fainelli , Gregory CLEMENT , Marcin Wojtas , "linux-arm-kernel@lists.infradead.org" , Thomas Petazzoni , Graeme Gregory List-Id: linux-acpi@vger.kernel.org > However interesting as an example, I'm not convinced this is what we > should aim for. > > ACPI is not a replacement for DT, and it is unlikely that people would > be interested in running ACPI-only distros such as RHEL on their > Ethernet switch. DT is excellent at describing this, and there is no > need to replace it. I however do know of somebody who is building an industrial wireless access point, with a Marvell Ethernet switch. They have chosen to use an Intel CPU, and want to run CentOS on it, because that is what they know. So they will be using ACPI whatever, for the basic board support. They then have a choice of either ACPI for the switch, or having device tree as well as ACPI for the switch. And it will be interesting to see how that works. Can DT reference GPIOs and I2C busses in ACPI? > Also, please bear in mind that the ACPI spec is owned by the UEFI/ACPI > forum, and only members (who are all under a contract regarding > reasonable and non-discriminatory (RAND) licensing terms to IP they > own that is covered by the spec) can contribute. Individuals can > become members for free AFAIR, but that doesn't mean individuals are > typically interested in getting involved in a process that is rather > tedious and bureaucratic. And this is a bit what i'm worried about. How you represent MDIO busses, PHYs, Ethernet switches is implemented once in the core Linux code. So i would be interested in knowing what happens if the Linux community defines and implements something, boards start using it, but a year later the tedious and bureaucratic process rejects it, re-writes it, in an incompatible way. Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751405AbeAUS4V (ORCPT ); Sun, 21 Jan 2018 13:56:21 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:57972 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751238AbeAUS4T (ORCPT ); Sun, 21 Jan 2018 13:56:19 -0500 Date: Sun, 21 Jan 2018 19:55:59 +0100 From: Andrew Lunn To: Ard Biesheuvel Cc: Mika Westerberg , Nadav Haklai , Neta Zur Hershkovits , Lorenzo Pieralisi , Russell King - ARM Linux , Grzegorz Jaszczyk , Tomasz Nowicki , "Rafael J. Wysocki" , "linux-acpi@vger.kernel.org" , Ezequiel Garcia , Florian Fainelli , Gregory CLEMENT , Marcin Wojtas , "linux-arm-kernel@lists.infradead.org" , Thomas Petazzoni , Graeme Gregory , "" , Antoine T?nart , "linux-kernel@vger.kernel.org" , Hanjun Guo , Sudeep Holla , "David S. Miller" Subject: Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support Message-ID: <20180121185559.GC9004@lunn.ch> References: <20180109130012.GA27447@lunn.ch> <20180118123141.GA2839@e107981-ln.cambridge.arm.com> <20180118130026.GG32299@lunn.ch> <20180120195246.GC27654@lahna.fi.intel.com> <20180121010840.GB1217@lunn.ch> <20180121102700.GF27654@lahna.fi.intel.com> <20180121161319.GA8017@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > However interesting as an example, I'm not convinced this is what we > should aim for. > > ACPI is not a replacement for DT, and it is unlikely that people would > be interested in running ACPI-only distros such as RHEL on their > Ethernet switch. DT is excellent at describing this, and there is no > need to replace it. I however do know of somebody who is building an industrial wireless access point, with a Marvell Ethernet switch. They have chosen to use an Intel CPU, and want to run CentOS on it, because that is what they know. So they will be using ACPI whatever, for the basic board support. They then have a choice of either ACPI for the switch, or having device tree as well as ACPI for the switch. And it will be interesting to see how that works. Can DT reference GPIOs and I2C busses in ACPI? > Also, please bear in mind that the ACPI spec is owned by the UEFI/ACPI > forum, and only members (who are all under a contract regarding > reasonable and non-discriminatory (RAND) licensing terms to IP they > own that is covered by the spec) can contribute. Individuals can > become members for free AFAIR, but that doesn't mean individuals are > typically interested in getting involved in a process that is rather > tedious and bureaucratic. And this is a bit what i'm worried about. How you represent MDIO busses, PHYs, Ethernet switches is implemented once in the core Linux code. So i would be interested in knowing what happens if the Linux community defines and implements something, boards start using it, but a year later the tedious and bureaucratic process rejects it, re-writes it, in an incompatible way. Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lunn Subject: Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support Date: Sun, 21 Jan 2018 19:55:59 +0100 Message-ID: <20180121185559.GC9004@lunn.ch> References: <20180109130012.GA27447@lunn.ch> <20180118123141.GA2839@e107981-ln.cambridge.arm.com> <20180118130026.GG32299@lunn.ch> <20180120195246.GC27654@lahna.fi.intel.com> <20180121010840.GB1217@lunn.ch> <20180121102700.GF27654@lahna.fi.intel.com> <20180121161319.GA8017@lunn.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Mika Westerberg , Nadav Haklai , Neta Zur Hershkovits , Lorenzo Pieralisi , Russell King - ARM Linux , Grzegorz Jaszczyk , Tomasz Nowicki , "Rafael J. Wysocki" , "linux-acpi@vger.kernel.org" , Ezequiel Garcia , Florian Fainelli , Gregory CLEMENT , Marcin Wojtas , "linux-arm-kernel@lists.infradead.org" , Thomas Petazzoni , Graeme Gregory , To: Ard Biesheuvel Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org > However interesting as an example, I'm not convinced this is what we > should aim for. > > ACPI is not a replacement for DT, and it is unlikely that people would > be interested in running ACPI-only distros such as RHEL on their > Ethernet switch. DT is excellent at describing this, and there is no > need to replace it. I however do know of somebody who is building an industrial wireless access point, with a Marvell Ethernet switch. They have chosen to use an Intel CPU, and want to run CentOS on it, because that is what they know. So they will be using ACPI whatever, for the basic board support. They then have a choice of either ACPI for the switch, or having device tree as well as ACPI for the switch. And it will be interesting to see how that works. Can DT reference GPIOs and I2C busses in ACPI? > Also, please bear in mind that the ACPI spec is owned by the UEFI/ACPI > forum, and only members (who are all under a contract regarding > reasonable and non-discriminatory (RAND) licensing terms to IP they > own that is covered by the spec) can contribute. Individuals can > become members for free AFAIR, but that doesn't mean individuals are > typically interested in getting involved in a process that is rather > tedious and bureaucratic. And this is a bit what i'm worried about. How you represent MDIO busses, PHYs, Ethernet switches is implemented once in the core Linux code. So i would be interested in knowing what happens if the Linux community defines and implements something, boards start using it, but a year later the tedious and bureaucratic process rejects it, re-writes it, in an incompatible way. Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 From: andrew@lunn.ch (Andrew Lunn) Date: Sun, 21 Jan 2018 19:55:59 +0100 Subject: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support In-Reply-To: References: <20180109130012.GA27447@lunn.ch> <20180118123141.GA2839@e107981-ln.cambridge.arm.com> <20180118130026.GG32299@lunn.ch> <20180120195246.GC27654@lahna.fi.intel.com> <20180121010840.GB1217@lunn.ch> <20180121102700.GF27654@lahna.fi.intel.com> <20180121161319.GA8017@lunn.ch> Message-ID: <20180121185559.GC9004@lunn.ch> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org > However interesting as an example, I'm not convinced this is what we > should aim for. > > ACPI is not a replacement for DT, and it is unlikely that people would > be interested in running ACPI-only distros such as RHEL on their > Ethernet switch. DT is excellent at describing this, and there is no > need to replace it. I however do know of somebody who is building an industrial wireless access point, with a Marvell Ethernet switch. They have chosen to use an Intel CPU, and want to run CentOS on it, because that is what they know. So they will be using ACPI whatever, for the basic board support. They then have a choice of either ACPI for the switch, or having device tree as well as ACPI for the switch. And it will be interesting to see how that works. Can DT reference GPIOs and I2C busses in ACPI? > Also, please bear in mind that the ACPI spec is owned by the UEFI/ACPI > forum, and only members (who are all under a contract regarding > reasonable and non-discriminatory (RAND) licensing terms to IP they > own that is covered by the spec) can contribute. Individuals can > become members for free AFAIR, but that doesn't mean individuals are > typically interested in getting involved in a process that is rather > tedious and bureaucratic. And this is a bit what i'm worried about. How you represent MDIO busses, PHYs, Ethernet switches is implemented once in the core Linux code. So i would be interested in knowing what happens if the Linux community defines and implements something, boards start using it, but a year later the tedious and bureaucratic process rejects it, re-writes it, in an incompatible way. Andrew