Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp717570ybl; Fri, 31 Jan 2020 06:49:55 -0800 (PST) X-Google-Smtp-Source: APXvYqwBQxIe6G2Tzy6WoXqt68Kq8ahLAJ2ffwKTFX0TG2yar/gtIOKkXnFHq27aWGtwUykbHHRr X-Received: by 2002:a05:6830:140f:: with SMTP id v15mr7990775otp.218.1580482195674; Fri, 31 Jan 2020 06:49:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580482195; cv=none; d=google.com; s=arc-20160816; b=WIfDoI/nTLYBy1aomcHzN2QDdZOJtVAXBBj9TkPIUJfaOLutAEFb+CRklPKSDW831V IIAZW1JIeYMau5HiKVf9kCsK8NEW0q8adUUU6dDe9fz46Vwk3Xlz9fXpiEpNsOOTEkAI 7k90FOcTzUbnSb19AitSb1NF+jy2DQuqOrmdZXzewIyDAyq7sxqfcU9w0kfs+YXYSLrd Pm7oXCrxbquLev/G2+48edUwa4emnUPZv+ZPnLacnxiBQRuYcdMCAaH0Kj+9hVRM0Zwm VGHdkYzBvgsiM7L97T6r9cuUgmVJgjU+AzmvocJXnR0s4TOmMCsCD754bqmAqrxhn2iJ oesA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=IreX0MN08iNYQOACc1fX//DwR7s40Q5PfYlgReJ0w6c=; b=Y97pLB98454R8y4RdVG8JjnwMTNC8nEJJ1/0Zl1FRmN9vE03JtTN0FArjByh8SgVzj DuuD4mhDbzEh0XuIQhbVQV4KHAQR841bP7Db1utCZF0f0lDM+/ituPpOzLgd+EtUussq oxKsjdxf1SFp3/pzKqVB6BmoZmB8bjA27zJxIJmfu27VAxsE5OunfX4L0vT92voSg1Mc b8BZrj5hDZOOFgAPDQme0dHergSNfGwBZSNliFzfTfavzLiXXqMTRjxyMOz9rvSn1CCa nJsZsXPLzjf635BqKqGZLgYOJ2nsJ0j9HKjLU6WLdj7gpKJQBrvW0iibNJWoVIhhL51L UN1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="D3UmqQ/p"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f11si2680737oti.104.2020.01.31.06.49.42; Fri, 31 Jan 2020 06:49:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="D3UmqQ/p"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729062AbgAaOrr (ORCPT + 99 others); Fri, 31 Jan 2020 09:47:47 -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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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