From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 605DA3C061D; Fri, 24 Apr 2026 11:55:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777031722; cv=none; b=LVrUsIKSHRm3hKwObTr87WZhIbUyyKF0fcAiSbLy4dUwSabVkIeAUiFzV1F+HrGHIaOPL+agBVivHQjSDTViWgQPgUwntTVZQg+Nb6hCpi8vJPESLp/crMMnAEU0a98sczD1bp0nydNQ1f3HomM6+kIBCKGiYBK5PZCEQ0bKw8I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777031722; c=relaxed/simple; bh=3sGm0CtNeMyxvoxyTsn9tGTUUQmNik0i9na4gi9/c/E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FzHHKFEaoQznKiX6/bUnDBiTL9S5sy7TVROGHvvSoWPMqRvaZyN17HqC7b0aDzw2gFUUJLj5+Wzfvrx/SpQwcVq3hrxBscqiB8/bLhukbHjMxgg9qaJFbVcR23yaEcROIhWkkzB0P8npUlhKqdmcd1Pph04FzNrvaBFdUrnv0Vg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=emXKArew; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="emXKArew" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86C75C2BCB2; Fri, 24 Apr 2026 11:55:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1777031722; bh=3sGm0CtNeMyxvoxyTsn9tGTUUQmNik0i9na4gi9/c/E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=emXKArew82z8jyq1RECSlihUt6jeOEmAagE+12KYKAcywJi51oKfYF9J40fUJOyof Z5pVFhExBNSatBsbJyRm8w5giaG/n/wqJ5Pj6lAgl1+e72piF+lF1o4UOJ8x7oWrKh iHvt8kArSk81cIUHY6hbL1V8MkyiU9Tj23AclgQI= Date: Fri, 24 Apr 2026 13:55:19 +0200 From: Greg Kroah-Hartman To: Vishnu Reddy Cc: Bryan O'Donoghue , Vikash Garodia , Dikshita Agarwal , Abhinav Kumar , Mauro Carvalho Chehab , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Joerg Roedel , Will Deacon , Robin Murphy , Bjorn Andersson , Konrad Dybcio , Stefan Schmidt , Hans Verkuil , "Rafael J. Wysocki" , Danilo Krummrich , Thierry Reding , Mikko Perttunen , David Airlie , Simona Vetter , Jonathan Hunter , linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, driver-core@lists.linux.dev, dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org, Ekansh Gupta , Dmitry Baryshkov Subject: Re: [PATCH v2 02/13] drivers: base: Add generic dma context bus Message-ID: <2026042428-blemish-helpline-7d8d@gregkh> References: <20260423-glymur-v2-0-0296bccb9f4e@oss.qualcomm.com> <20260423-glymur-v2-2-0296bccb9f4e@oss.qualcomm.com> <2026042346-trustable-register-095a@gregkh> <06c04947-e72e-679b-493b-e112d693f391@oss.qualcomm.com> <2026042422-deem-chemist-8d0f@gregkh> <4c3fa710-f61a-4aad-622d-54909190cb9e@oss.qualcomm.com> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4c3fa710-f61a-4aad-622d-54909190cb9e@oss.qualcomm.com> On Fri, Apr 24, 2026 at 05:15:02PM +0530, Vishnu Reddy wrote: > > On 4/24/2026 4:43 PM, Greg Kroah-Hartman wrote: > > On Fri, Apr 24, 2026 at 04:01:13PM +0530, Vishnu Reddy wrote: > >> On 4/23/2026 7:07 PM, Greg Kroah-Hartman wrote: > >>> On Thu, Apr 23, 2026 at 06:59:31PM +0530, Vishnu Reddy wrote: > >>>> From: Ekansh Gupta > >>>> > >>>> When a driver needs to create virtual device at runtime and map it to > >>>> an IOMMU context for memory isolation, there is no common bus available > >>>> for this purpose. Each driver ends up implementing its own bus type, > >>>> leading to duplicated logic across multiple drivers. > >>>> > >>>> host1x driver implemented its own bus type to attach an IOMMU context to > >>>> a dynamically created device. The Iris VPU driver now has the same > >>>> requirement. Rather than duplicating the same bus logic again, a shared > >>>> bus type is introduced under drivers/base that multiple drivers can use > >>>> directly. > >>>> > >>>> The bus takes care of creating a device and attaching the IOMMU context > >>>> to it based on the client inputs. > >>>> > >>>> Suggested-by: Dmitry Baryshkov > >>>> Signed-off-by: Ekansh Gupta > >>>> Signed-off-by: Vikash Garodia > >>>> Signed-off-by: Vishnu Reddy > >>>> --- > >>>> drivers/base/Kconfig | 3 ++ > >>>> drivers/base/Makefile | 1 + > >>>> drivers/base/dma_context_bus.c | 77 +++++++++++++++++++++++++++++++++++++++++ > >>>> include/linux/dma_context_bus.h | 26 ++++++++++++++ > >>>> 4 files changed, 107 insertions(+) > >>> as you can not have a device on multiple busses at the same time, this > >>> makes no sense to me at all. "dma context" is a bus-specific thing, so > >>> please add it to the bus that you are wanting it for. It can't be a > >>> generic bus as that just doesn't work. > >>> > >>> Or what am I missing here? > >>> > >>> And why is DMA somehow "special" here from any other hardware attribute? > >> Let me give brief information which was discussed, in the initial series, > >> the iris VPU used platform bus for dynamically created devices and we got > >> the comment/suggestion from Robin to implement a proper bus_type with a > >> .dma_configure callback. > >> > >> https://lore.kernel.org/all/02b3d0f5-f94c-43cd-93af-97cfcf7751b1@arm.com/ > >> > >> based on the discussion, implemented the dma_context_bus and used for iris > >> VPU devices instead of platform bus. > > Why not make a irus_vpu_bus where you can do what you want? > Initially iris_vpu_bus was introduced, and it was made generic based on the > discussion, > > https://lore.kernel.org/all/20260227-kaanapali-iris-v2-3-850043ac3933@oss.qualcomm.com/ I don't really see that request here, I see a "make this better and more generic for other busses" but that does not mean "dump it into drivers/bus/ for someone else to maintain" :) > >> Here, the device have only one bus (dma_context_bus), not multiple buses. > >> > >> Regarding the "DMA" naming, the core operation of this bus is its > >> .dma_configure callback, which calls of_dma_configure_id() to map the device > >> to a corresponding IOMMU stream ID. The name "dma_context" reflects this > >> purpose. > >> > >> I am open to suggestions from you or Robin or anyone else, if there is a > >> better or preferred way to achieve this, I am happy to consider it and > >> rework the implementation accordingly. > > As there is only one user, just make this your own bus please and do all > > of the needed bus operations for your devices there (i.e. don't hang an > > "empty" device off of it.) > The reasoning behind to make it generic was to have more users - host1x, > Iris VPU, QDA on the generic context bus, instead of each of them having > their own. Let me know if you suggest to have the iris_vpu_bus. But you did not add such users here, so how would we know this? And still, I have no idea what this bus really is doing. Is it dynamic? Is it self-describing? Why not just use aux-bus? What is it supposed to be doing and used for? still totally confused, greg k-h