Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp2206234pxu; Fri, 18 Dec 2020 07:53:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJxn6CwKHB8hYApzwTMITPuJOYN4q8iMD/Dr+XfBmHhPXJ2f8GWe/J9g8wL3Tr58r8XJbOKl X-Received: by 2002:a05:6402:3049:: with SMTP id bu9mr5032071edb.127.1608306831304; Fri, 18 Dec 2020 07:53:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608306831; cv=none; d=google.com; s=arc-20160816; b=Gpof4Y01lk9w9Kl4JFjVElFqFzoGJBiIxHwC5LuowrlqxtxQG23Zx/Z1HIZB0pNrRB HbWjQWRr6JAE41LVAjhSH7Pq32LUM0KnE87YG1lBQCBb5c+qQ6fOmeZp1EqfGzo5Dmyc D3ZDaiocmM5HPdWJgEjkDumc1EpNqu2TjgcUy2V69OcHQ1funQqdwQ7ITN4kIZSy+v5g lNPydgp3xMsjdcqs2YFwtEcjrFoZQ55a2Lnt2NJIuHhtWhnJb/f1pFMQdA3QiMNW/ks+ VlOXtn6u51ZAEsXUOdXJdWo1RPEBwtV5dsysohC9l9vyUlP0F4Nits70Xf7nAkFP2L77 jqzQ== 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=IL1p3KFSIhZF55j6mZIcYthVaeCfv9z202PB93JzKSQ=; b=DFV7SqzM1vdZ/eX3kRydps4shbE0roT6Qcaq/pIaj3kpIWDnvuh/NfBO40UBqNE1U6 372xySyByLi95cz3EgcNbU+B+PB1P7CE/XPA7RVkbY+122VnMEOPh2YQ9JM17bIT3hi0 2FYzLlCwqw7fHxr1l7PyJ9HmbBpvIwiLM6OU1+QgeukUJG+Un1skkhsGrpj1xO8UMFSN 4UQudsrHzMLfuo7K21RbsHQeQRPrjSKBTuOVyY9S5B3p8SurbXe0LJeUGkdSpoxd0b4F Is3zRaDQqbF3/tEEm8RJhe7oFYf7Tl7OGTqMmHDWBhJM85s3pV9gQ2Xb5B6jvDuTQ+Qy mxgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=UyU1MPj7; 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 f11si4825035eje.349.2020.12.18.07.53.27; Fri, 18 Dec 2020 07:53:51 -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=UyU1MPj7; 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 S1729128AbgLRPw7 (ORCPT + 99 others); Fri, 18 Dec 2020 10:52:59 -0500 Received: from mail.kernel.org ([198.145.29.99]:37252 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725949AbgLRPw7 (ORCPT ); Fri, 18 Dec 2020 10:52:59 -0500 Date: Fri, 18 Dec 2020 15:52:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1608306738; bh=hh6kmTaYw7S1ycwZ4+Gi2lG2vKviQu4KRDfzNgRJMMs=; h=From:To:Cc:Subject:References:In-Reply-To:From; b=UyU1MPj7dIcBqLmjerLEZsmEzC9n1onWw7rJnwndCFVtu521SPmOch8eA090w9V2H ebUvciuQh2tgliNsbPhJ+d7famGJ5HrWsYQXOFYFawsqG7YFaYaENY1wZ3I+lQvhM3 sBTMAP+TWsAs/Y2hGXv08Pw61G+jsbNEjrvVOliXG1QnXFRMS7pL33FrykEC15cAbc 2EPJnk8WkKwkraXP8CJjbdl6y+P9OpU1+fs8usTsCYpva/XnIg5e4tdCor3867HRms tVOavWiyg+wnpW7nD1Pb2LmOxcN9bu82ySjirX3es0l64KZmVFEC9qMU+j+GVrqdxQ J63Ghc7zBNX5A== 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: <20201218155204.GC5333@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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ABTtc+pdwF7KHXCz" Content-Disposition: inline In-Reply-To: <20201218140854.GW552508@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 --ABTtc+pdwF7KHXCz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote: > On Fri, Dec 18, 2020 at 01:17:09PM +0000, Mark Brown wrote: > > As previously discussed this will need the auxilliary bus extending to > > support at least interrupts and possibly also general resources. > 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. 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 MFD subfunctions can clearly be described by ACPI (where it would be unidiomatic, we just don't see this happening for the MFDs that appear on ACPI systems and I'm not sure bindings exist within ACPI) or DT (where even where subfunctions are individually described it's rarely doing more than enumerating that things exist). > 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. If Greg's statements about not using platform buses for MMIO or direct firmware devices are accurate then those cases already exist, if nothing else a common subfunction for MFDs is an interrupt controller. --ABTtc+pdwF7KHXCz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl/c0CMACgkQJNaLcl1U h9AEzwf+O76Uw7BDG33tM6xhLOwoq847RdyVqkI6RrFlyIlLsFlIt49fbXRIuXTF Pviz3SUZ268ihxH3NrtuGLDtkdVL70oKo26hEppOtp877dhmkjK/BCnnkqIiERro 4Hpxo/eoIjqT0lnx+ah2ge9q5cDhT9s1mMH8vkvdOSGa2a9z71uYEzOARmvUbXy9 LK4/z9VmLS0wmO6YPxwc4Nq6afaa0m/yGhGFxu2aKT9aKfzbBIywl6WFllPz1Y1H G+ZxfgLJ6sZON36FToD7/FEDUuZxBUGjA5d2txOX0xpx/ZsnvapoRypEvotufObZ ZVX/PBjkUnHdClRckKl3LHCok9Xw1w== =lhpS -----END PGP SIGNATURE----- --ABTtc+pdwF7KHXCz--