Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp2311966pxu; Fri, 18 Dec 2020 10:06:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJzcTzU42g+Aa3hpkuKS5TlYHOAizIgVHRqY7Bx0SIkzdpKebY8o2ENKHwrki7b4lz/QYV92 X-Received: by 2002:a17:907:2131:: with SMTP id qo17mr5114258ejb.546.1608314777324; Fri, 18 Dec 2020 10:06:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608314777; cv=none; d=google.com; s=arc-20160816; b=zXQTC1OGPL2bjuVRgB+HG6g1RYPqI55Td3pQzpLlO8ul+F3CWsQy0K6Ox7YuZzShb1 O7ZgA1EJ89pgRcp1WGtPTo+Rg647CM2baHM2tyTqWxhFmZWr6/RcFy7mvV3Q9lgCzZQx gq9fhHvO8m1K66X75syK1s+cUlza0begd0yolaY1rgKkswVktnsx2Pq6pCQaA/50Ks8p uMv3QwPY6ajOh6G5m+Lp+D9xUfUqf5i5aObo2HATnp91KEFaBkAHw9zBp2r1O8QX5E+D gvlLDYTgppOq27hC4aPQ3lbQeYjlWdlzpdXpWqxi3fDD9F6n3wtySHPovvaBZXtY3kPQ poWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from :dkim-signature:date; bh=aniDnxwjmntEPrIYIzyJd/G1HY/tZVFI7A15rZGIa44=; b=IKw8D4Qr+eb9EGrmTH2Y0HvT+kbSsEfNewwScd4sKTssd/ByYnBTascjrhMwa7CNCi 6a9jPuBt5Kvn+q/QKlwbBOhb7Yxc5wcTmilCjls6yfMn/vcuDZoF5hsChxzgbGozyMN5 izYoT5PwVb2Kdn+PDrDmi5TMRg6Rwe+CaXZw8HJCcWQBsQYU+gTBobbaYSmTrNRJRBaY pXwIqi9z6bPpOtyBWcIZX9V1mzrySzG3VFhNEvPfRYPn1PrNkAMsN/cjuA9pYJeFL/c8 nO8koiTbV637yatkTR6h4/7cnjxMghU/pugYn7UmSGmM3mMxjIHoRtvX8sNgW0lA8yoC fGoA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=vBlfg0Mw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id 11si7430537edv.53.2020.12.18.10.05.52; Fri, 18 Dec 2020 10:06:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=vBlfg0Mw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1728397AbgLRSEH (ORCPT + 99 others); Fri, 18 Dec 2020 13:04:07 -0500 Received: from mail.kernel.org ([198.145.29.99]:47408 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725766AbgLRSEG (ORCPT ); Fri, 18 Dec 2020 13:04:06 -0500 Date: Fri, 18 Dec 2020 18:03:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1608314605; bh=FkUoSS1XA/fvcfYoGeT7JpiQyIA2Fo3T+sJ2XEZSLaw=; h=From:To:Cc:Subject:References:In-Reply-To:From; b=vBlfg0MwKW270LXGfrZkKmF/HDxuLBQ3qvI+ZLjeS0L/BqO/maY80b990QQIyWH3x GAGvZgjDLAggmWs7x9ExGnAACvu0jyphastaI5fxVpno8mdKP4wk0jHWYOTmbEjjDu e7L+AAfqxItRHVuyllwhleMlWSnYKJRG2zV4/Mz0ixnfVuzEIz6zGV2OWykCzsCFTc IyEcBvmsfCxIWuWxhR9f5z2nmFkwQakYggOhoRhNFhm1S529GZY2dfL62VeZmfe89M d4KuFB3bYT21V9m2KOQYGX/SPMHUwOc5cJD/fasUASfO83K+X7oaIv2bd1P38hiX06 xl7PQzyddmU/g== From: Mark Brown To: Jason Gunthorpe Cc: Greg KH , Alexandre Belloni , Dan Williams , Pierre-Louis Bossart , alsa-devel@alsa-project.org, Kiran Patil , linux-rdma , Shiraz Saleem , Martin Habets , Liam Girdwood , Ranjani Sridharan , Fred Oh , Dave Ertman , Jakub Kicinski , Netdev , Leon Romanovsky , David Miller , Linux Kernel Mailing List , Parav Pandit , lee.jones@linaro.org Subject: Re: [resend/standalone PATCH v4] Add auxiliary bus support Message-ID: <20201218180310.GD5333@sirena.org.uk> References: <160695681289.505290.8978295443574440604.stgit@dwillia2-desk3.amr.corp.intel.com> <20201217211937.GA3177478@piout.net> <20201218131709.GA5333@sirena.org.uk> <20201218140854.GW552508@nvidia.com> <20201218155204.GC5333@sirena.org.uk> <20201218162817.GX552508@nvidia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gE7i1rD7pdK0Ng3j" Content-Disposition: inline In-Reply-To: <20201218162817.GX552508@nvidia.com> X-Cookie: Password: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --gE7i1rD7pdK0Ng3j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 18, 2020 at 12:28:17PM -0400, Jason Gunthorpe wrote: > On Fri, Dec 18, 2020 at 03:52:04PM +0000, Mark Brown wrote: > > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote: > > > I thought the recent LWN article summed it up nicely, auxillary bus is > > > for gluing to subsystems together using a driver specific software API > > > to connect to the HW, MFD is for splitting a physical HW into disjoint > > > regions of HW. > > This conflicts with the statements from Greg about not using the > > platform bus for things that aren't memory mapped or "direct firmware", > > a large proportion of MFD subfunctions are neither at least in so far as > > I can understand what direct firmware means. > I assume MFD will keep existing and it will somehow stop using > platform device for the children it builds. If it's not supposed to use platform devices so I'm assuming that the intention is that it should use aux devices, otherwise presumably it'd be making some new clone of the platform bus but I've not seen anyone suggesting this. > That doesn't mean MFD must use aux device, so I don't see what you > mean by conflicts? I was excluding the possibility that we have to make a third bus which clones platform bus which nobody has been visibly suggesting. > If someone has a PCI device and they want to split it up, they should > choose between aux device and MFD (assuming MFD gets fixed, as Greg > has basically blanket NAK'd adding more of them to MFD as is) It is unclear to me how one is intended to choose between these approaches, especially for systems that have a range of subdevices with a range of characteristics. > > To be honest I don't find the LWN article clarifies things particularly > > here, the rationale appears to involve some misconceptions about what > > MFDs look like. It looks like it assumes that MFD functions have > > physically separate register sets for example which is not a reliable > > feature of MFDs, nor is the assumption that there's no shared > > functionality which appears to be there. It also appears to assume that > I think the MFD cell model is probably the deciding feature. If that > cell description scheme suites the device, and it is very HW focused, > then MFD is probably the answer. > The places I see aux device being used are a terrible fit for the cell > idea. If there are MFD drivers that are awkardly crammed into that > cell description then maybe they should be aux devices? When you say the MFD cell model it's not clear what you mean - I *think* you're referring to the idea of the subdevices getting all the information they need to talk to the hardware from the device resources. That's actually relatively uncommon with I2C/SPI MFDs, usually there's at least some element of just knowing what's going on and the mfd_cells are to some extent just a list of things to register rather than a model of anything. Look at something like wm8994 for example - the subdevices just know which addresses in the device I2C/SPI regmap to work with but some of them have interrupts passed through to them (and could potentially also have separate subdevices for clocks and pinctrl). These subdevices are not memory mapped, not enumerated by firmware and the hardware has indistinct separation of functions in the register map compared to how Linux models the chips. > > > Maybe there is some overlap, but if you want to add HW representations > > > to the general auxillary device then I think you are using it for the > > > wrong thing. > > Even for the narrowest use case for auxiliary devices that I can think > > of I think the assumption that nobody will ever design something which > > can wire an interrupt intended to be serviced by a subfunction is a bit > > optimistic. =20 > mlx5, for example, uses interrupts but an aux device is not assigned > an exclusive MSI interrupt list. > These devices have a very dynamic interrupt scheme, pre-partitioning > the MSI vector table is completely the wrong API. I'm not saying dynamic interrupt schemes or event queues from firmware can't exist, I'm saying not all interrupt schemes are dynamic. --gE7i1rD7pdK0Ng3j Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl/c7t4ACgkQJNaLcl1U h9DZ9ggAhWS2GLzG19WitcNZFN865NLdPy+QPB5dNfJqSEWdIANmNlivsdyHbIae pMP4f/TZReaOIA0LD4bUZuAoDdQobMvxI7Mg1Y7qg1wy5+SA2dGRJYUsYCNaGQs+ clPY3qNsHgcmbUNVbbZjSpxY3sLSpStsSeQb22JGqc9438HQ26c8xAj7/wbiUyjU N8PozJPh+++afQFAP+hgWux0THNNrDTKlAZMZOD7AL1o/2M4Z2EHx5Lu3/XXJXaO ihRdaMWFrQ9p7vCoZkutTw8wnoMhqxnST4EP1ZejtWNQZcXqf5wdTm/hDBTzgKmx fe4rfElBhVvfORw9UTYh3Bjkit+xNQ== =Im3G -----END PGP SIGNATURE----- --gE7i1rD7pdK0Ng3j--