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=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 7E700C2D0DB for ; Fri, 31 Jan 2020 14:47:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 54B52214D8 for ; Fri, 31 Jan 2020 14:47:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1580482067; bh=Pa0QAne+ikfRhcST4dhxQhcKQvjaN3EVPx5vMgOXzVo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=0bJtWRi7oI7FoshcsNMRzU04djrZnN/vKixobNRY2IqTa5WI6qZGGMQAnQy3y1CNp l5EthSjOqbJa9m2ta3OJ//4S7wvQNWIu4OTRtGYFq9iCGgU4nEHOKrXP8b4JL5u1rT iRjgXo++EbXQXjDpkDzUpR1pkezt6stCXh3AyICM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728939AbgAaOrq (ORCPT ); Fri, 31 Jan 2020 09:47:46 -0500 Received: from mail.kernel.org ([198.145.29.99]:53886 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728827AbgAaOrq (ORCPT ); Fri, 31 Jan 2020 09:47:46 -0500 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B5E3C206D5; Fri, 31 Jan 2020 14:47:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1580482066; bh=Pa0QAne+ikfRhcST4dhxQhcKQvjaN3EVPx5vMgOXzVo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=D3UmqQ/pBjmnWl1PtBaM6XfZQzl+sLU+f2jy7YCYWNZLtIrbEIrys0/0Ss5/Xc0lt raWKCH990ysM7rxkXTHv8SnUgWPyGF598DtDtLi+tCyQAYtjlGKnr4B2Eg5USJNfqG DokwLpRCs+Dw9Nz5XRQL4vnFqRCVD2pGmTcn3Qy8= Date: Fri, 31 Jan 2020 14:47:38 +0000 From: Will Deacon To: Andrew Lunn 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: <20200131144737.GA4948@willie-the-truck> References: <1580198925-50411-1-git-send-email-makarand.pawagi@nxp.com> <20200128110916.GA491@e121166-lin.cambridge.arm.com> <12531d6c569c7e14dffe8e288d9f4a0b@kernel.org> <0680c2ce-cff0-d163-6bd9-1eb39be06eee@arm.com> <20200131142906.GG9639@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200131142906.GG9639@lunn.ch> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Fri, Jan 31, 2020 at 03:29:06PM +0100, Andrew Lunn wrote: > > > But by design SFP, SFP+, and QSFP cages are not fixed function network > > > adapters. They are physical and logical devices that can adapt to > > > what is plugged into them. How the devices are exposed should be > > > irrelevant to this conversation it is about the underlying > > > connectivity. > > > > Apologies - I was under the impression that SFP and friends were a > > physical-layer thing and that a MAC in the SoC would still be fixed such > > that its DMA and interrupt configuration could be statically described > > regardless of what transceiver was plugged in (even if some configurations > > might not use every interrupt/stream ID/etc.) If that isn't the case I shall > > go and educate myself further. > > It gets interesting with QSFP cages. The Q is quad, there are 4 SERDES > lanes. You can use them for 1x 40G link, or you can split them into 4x > 10G links. So you either need one MAC or 4 MACs connecting to the > cage, and this can change on the fly when a modules is ejected and > replaced with another module. There are only one set of control pins > for i2c, loss of signal, TX disable, module inserted. So where the > interrupt/stream ID/etc are mapped needs some flexibility. > > There is also to some degree a conflict with hiding all this inside > firmware. This is complex stuff. It is much better to have one core > implementing in Linux plus some per hardware driver support, than > having X firmware blobs, generally closed source, each with there own > bugs which nobody can fix. Devicetree to the rescue! 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? Will