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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 49B0EC35240 for ; Fri, 31 Jan 2020 15:09:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1F67620705 for ; Fri, 31 Jan 2020 15:09:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="VtV9rSnh" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729099AbgAaPJu (ORCPT ); Fri, 31 Jan 2020 10:09:50 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:60146 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729071AbgAaPJu (ORCPT ); Fri, 31 Jan 2020 10:09:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=2diiy8c4y3CQgdL4Lzi01JXwoWYa5nYVCP1kWDev+KA=; b=VtV9rSnhaU0/x3uU0Ks1rPZwoy udAyQG7ZDC0OTihQpPDz/WkVWXMvNN/aqQsxdfKqkoW3c4SQ2yZdFcgUxpNGOvWeOW6fiDxhTMgbr MAw/DzHa16yTES2h6C2kEpkRtp3LtWyVvPX3tDO5U2vDa7SjwSyPDdFS82it+CbcDj1w=; Received: from andrew by vps0.lunn.ch with local (Exim 4.93) (envelope-from ) id 1ixXvF-0007n7-4E; Fri, 31 Jan 2020 16:09:29 +0100 Date: Fri, 31 Jan 2020 16:09:29 +0100 From: Andrew Lunn To: Will Deacon Cc: Robin Murphy , Jon Nettleton , Ard Biesheuvel , Marc Zyngier , Makarand Pawagi , Calvin Johnson , stuyoder@gmail.com, nleeder@codeaurora.org, Ioana Ciornei , Cristi Sovaiala , Hanjun Guo , Lorenzo Pieralisi , Pankaj Bansal , Russell King , ACPI Devel Maling List , Len Brown , Jason Cooper , Andy Wang , Varun Sethi , Thomas Gleixner , linux-arm-kernel , Laurentiu Tudor , Paul Yang , "" , "Rafael J. Wysocki" , Linux Kernel Mailing List , Shameerali Kolothum Thodi , Sudeep Holla Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc Message-ID: <20200131150929.GB13902@lunn.ch> References: <20200128110916.GA491@e121166-lin.cambridge.arm.com> <12531d6c569c7e14dffe8e288d9f4a0b@kernel.org> <0680c2ce-cff0-d163-6bd9-1eb39be06eee@arm.com> <20200131142906.GG9639@lunn.ch> <20200131144737.GA4948@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200131144737.GA4948@willie-the-truck> Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org > Devicetree to the rescue! Yes, exactly. We have good, standardised descriptions for most of this in device tree. And phylink can handle SFP and SFP+. Nobody has worked on QSFP yet, since phylink has mostly been pushed by the embedded world and 40G is not yet popular in the embedded world. > Entertaining the use of ACPI without any firmware abstraction for this > hardware really feels like a square peg / round hole situation, so I'm > assuming somebody's telling you that you need it "FOAR ENTAPRYZE". Who > is it and can you tell them to bog off? The issues here is that SFPs are appearing in more and more server systems, replacing plain old copper Ethernet. If the boxes use off the shelf Mellanox or Intel PCIe cards, it is not an issue. But silicon vendors are integrating this into the SoC in the ARM way of doing things, memory mapped, spread over a number of controllers, not a single PCIe device. Maybe we need hybrid systems. Plain, old, simple, boring things like CPUs, serial ports, SATA, PCIe busses are described in ACPI. Complex interesting things are in DT. The hard thing is the interface between the two. DT having a phandle to an ACPI object, e.g a GPIO, interrupt or an i2c bus. Andrew 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=1.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,URIBL_DBL_ABUSE_MALW 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 B2C96C35240 for ; Fri, 31 Jan 2020 15:09:51 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 88A0620661 for ; Fri, 31 Jan 2020 15:09:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="GLos73xk"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="VtV9rSnh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 88A0620661 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lunn.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wmSiNXIqY78OfKeM58WvB3BFJShuw3KfGpNrc6B/cWg=; b=GLos73xkXYMeZ6 7CDXc2Lr1DcPDWNDkjRdhfAi3+G2BVgL8IrXwRDUsZfvZqckXD2+do8Fo4p0kdS0hf8ZNg7E2+pYs Z3CT6YPNxTtypWAnKiByQj/tUl9YF84u3KQzl5gM/CvrCYO9CJNe1NFXkDvhecucwFhVBeYpDdnIi D8fYwhXFTyE2B7SGCxa2QBiHSihhptdjWPk7NTV9GVWo2rt937IRzdps02z7KmbZzPyQMSqKgWp6u b1CgAUg6BMol0FDlO+yUbBFBkMkWf9kUrhaatrNEuzAmuiPzF6XheX0JCuiXyPN3fzk1VX+ERHZxy +tXCTUIYS94/2NxNOmkQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ixXvY-0000VW-09; Fri, 31 Jan 2020 15:09:48 +0000 Received: from vps0.lunn.ch ([185.16.172.187]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1ixXvV-0000VB-LN for linux-arm-kernel@lists.infradead.org; Fri, 31 Jan 2020 15:09:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=2diiy8c4y3CQgdL4Lzi01JXwoWYa5nYVCP1kWDev+KA=; b=VtV9rSnhaU0/x3uU0Ks1rPZwoy udAyQG7ZDC0OTihQpPDz/WkVWXMvNN/aqQsxdfKqkoW3c4SQ2yZdFcgUxpNGOvWeOW6fiDxhTMgbr MAw/DzHa16yTES2h6C2kEpkRtp3LtWyVvPX3tDO5U2vDa7SjwSyPDdFS82it+CbcDj1w=; Received: from andrew by vps0.lunn.ch with local (Exim 4.93) (envelope-from ) id 1ixXvF-0007n7-4E; Fri, 31 Jan 2020 16:09:29 +0100 Date: Fri, 31 Jan 2020 16:09:29 +0100 From: Andrew Lunn To: Will Deacon Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc Message-ID: <20200131150929.GB13902@lunn.ch> References: <20200128110916.GA491@e121166-lin.cambridge.arm.com> <12531d6c569c7e14dffe8e288d9f4a0b@kernel.org> <0680c2ce-cff0-d163-6bd9-1eb39be06eee@arm.com> <20200131142906.GG9639@lunn.ch> <20200131144737.GA4948@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200131144737.GA4948@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200131_070945_700181_8824CC4A X-CRM114-Status: UNSURE ( 9.35 ) X-CRM114-Notice: Please train this message. X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Calvin Johnson , stuyoder@gmail.com, nleeder@codeaurora.org, Ioana Ciornei , Cristi Sovaiala , Hanjun Guo , Lorenzo Pieralisi , Marc Zyngier , Pankaj Bansal , Jon Nettleton , Russell King , ACPI Devel Maling List , Len Brown , Jason Cooper , Andy Wang , Makarand Pawagi , Varun Sethi , Thomas Gleixner , linux-arm-kernel , Laurentiu Tudor , Paul Yang , Ard Biesheuvel , "" , "Rafael J. Wysocki" , Linux Kernel Mailing List , Shameerali Kolothum Thodi , Sudeep Holla , Robin Murphy Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org > Devicetree to the rescue! Yes, exactly. We have good, standardised descriptions for most of this in device tree. And phylink can handle SFP and SFP+. Nobody has worked on QSFP yet, since phylink has mostly been pushed by the embedded world and 40G is not yet popular in the embedded world. > Entertaining the use of ACPI without any firmware abstraction for this > hardware really feels like a square peg / round hole situation, so I'm > assuming somebody's telling you that you need it "FOAR ENTAPRYZE". Who > is it and can you tell them to bog off? The issues here is that SFPs are appearing in more and more server systems, replacing plain old copper Ethernet. If the boxes use off the shelf Mellanox or Intel PCIe cards, it is not an issue. But silicon vendors are integrating this into the SoC in the ARM way of doing things, memory mapped, spread over a number of controllers, not a single PCIe device. Maybe we need hybrid systems. Plain, old, simple, boring things like CPUs, serial ports, SATA, PCIe busses are described in ACPI. Complex interesting things are in DT. The hard thing is the interface between the two. DT having a phandle to an ACPI object, e.g a GPIO, interrupt or an i2c bus. Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel