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 C58827E3 for ; Mon, 26 Dec 2022 10:27:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6701C433EF; Mon, 26 Dec 2022 10:27:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1672050442; bh=hVha1FGsr/BmeLaghWhC0c48RTyAxF2U24ZFLUAgVy8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LEzCXCcvjH80vck2xNc8lJwSRl7Ssq363WQs0RJehi4p1GOTP1f3BS8lvw3BgFB21 MKx65XskwpIedzprYHvmYoTx/LzR5U1KQn3c/6hzl4qqH8IUNWW1HsBbzWAUAlMYz+ HRLQVPVTvfpav5RLlt8Ta57YCl03wnAseVeuM1KQ= Date: Mon, 26 Dec 2022 11:27:19 +0100 From: Greg Kroah-Hartman To: Laurent Pinchart Cc: Stefan Wahren , Umang Jain , linux-staging@lists.linux.dev, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, Florian Fainelli , Adrien Thierry , Dan Carpenter , Nicolas Saenz Julienne , Phil Elwell , Dave Stevenson , Kieran Bingham Subject: Re: [PATCH] staging: vc04_services: vchiq_arm: Create platform_device per device Message-ID: References: <20221220084404.19280-1-umang.jain@ideasonboard.com> <629b3f63-74e4-5cb5-29d1-6d2846bc24c7@i2se.com> Precedence: bulk X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Dec 26, 2022 at 12:06:53PM +0200, Laurent Pinchart wrote: > On Fri, Dec 23, 2022 at 03:48:11PM +0100, Greg Kroah-Hartman wrote: > > On Fri, Dec 23, 2022 at 12:24:22PM +0100, Stefan Wahren wrote: > > > i vaguely remember the discussion how to represent audio and camera > > > interface in the device tree. Representing as child nodes of the VC4 has > > > been rejected on the device tree mailing some years ago, because this > > > doesn't represent the physical (hardware) wiring. It's still possible to > > > access e.g. the camera interface from the ARM. > > > > > > The whole approach with using a separate binding for all the firmware stuff > > > lead to a lot of trouble on the Raspberry Pi platform (ugly dependencies > > > between firmware, DT and kernel). So i would like to avoid this here. In > > > case the current implementation is a no go, how about letting the ARM core > > > discover the available interfaces e.g. via mailbox interface? > > > > > > For more inspiration take a look at this old thread [1] > > > > Yes, that's the proper way to do this please! This should be a bus and > > dynamically add the devices when found, it is NOT a platform device > > anymore. > > I'm fine with making this a bus, but when it comes to dynamically adding > devices, that depends on the firmware exposing an interface to enumerate > those devices. If that's not possible, are you fine with a custom bus > and hardcoded children device instantiation in the VCHIQ driver ? Yes, that is at least a step forward and is not abusing the platform device/driver code. thanks, greg k-h 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D68D7C4167B for ; Mon, 26 Dec 2022 10:28:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=nJwJCFTl4qM6fJyf0yDwbOPfquHCpy6+EVa00z9I5Jo=; b=m+1ocaPwrrcQsc hou40aCKbY3FUJY24ki5vFBpA4VzZT8C5yDmH824U3CE5ZwnMSJ/jo4ZKRo7/Q/0ah7PPmVSMwz2I wY2FMrgf7b1LNyTkdAb3UCcsfit63ljbu/NdmqkPFTPP/Q0QTsoByoJp9YS8ju5udRQvxLSzp2p0g WXP59ylz0uj3kRuLpAJ+9gxIVPGOzfVy7JV/wRsBMoUU3bCzmdjIY1P+6gryCECbySyfIaj8wjWW/ viCd+vEtWbiWM0LPypnDWTBCYltLdPB/h/ujCkKPrcO3IpqL5zyxEbPI7KjM6842bfn5Qw+ayshzD UvXYCdPhAl6WzwSBzc4g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p9khi-003B9a-Aq; Mon, 26 Dec 2022 10:27:34 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p9khc-003B4s-6k; Mon, 26 Dec 2022 10:27:31 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id F263560E15; Mon, 26 Dec 2022 10:27:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6701C433EF; Mon, 26 Dec 2022 10:27:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1672050442; bh=hVha1FGsr/BmeLaghWhC0c48RTyAxF2U24ZFLUAgVy8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LEzCXCcvjH80vck2xNc8lJwSRl7Ssq363WQs0RJehi4p1GOTP1f3BS8lvw3BgFB21 MKx65XskwpIedzprYHvmYoTx/LzR5U1KQn3c/6hzl4qqH8IUNWW1HsBbzWAUAlMYz+ HRLQVPVTvfpav5RLlt8Ta57YCl03wnAseVeuM1KQ= Date: Mon, 26 Dec 2022 11:27:19 +0100 From: Greg Kroah-Hartman To: Laurent Pinchart Cc: Stefan Wahren , Umang Jain , linux-staging@lists.linux.dev, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, Florian Fainelli , Adrien Thierry , Dan Carpenter , Nicolas Saenz Julienne , Phil Elwell , Dave Stevenson , Kieran Bingham Subject: Re: [PATCH] staging: vc04_services: vchiq_arm: Create platform_device per device Message-ID: References: <20221220084404.19280-1-umang.jain@ideasonboard.com> <629b3f63-74e4-5cb5-29d1-6d2846bc24c7@i2se.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221226_022728_586595_1E6A9EE7 X-CRM114-Status: GOOD ( 22.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Dec 26, 2022 at 12:06:53PM +0200, Laurent Pinchart wrote: > On Fri, Dec 23, 2022 at 03:48:11PM +0100, Greg Kroah-Hartman wrote: > > On Fri, Dec 23, 2022 at 12:24:22PM +0100, Stefan Wahren wrote: > > > i vaguely remember the discussion how to represent audio and camera > > > interface in the device tree. Representing as child nodes of the VC4 has > > > been rejected on the device tree mailing some years ago, because this > > > doesn't represent the physical (hardware) wiring. It's still possible to > > > access e.g. the camera interface from the ARM. > > > > > > The whole approach with using a separate binding for all the firmware stuff > > > lead to a lot of trouble on the Raspberry Pi platform (ugly dependencies > > > between firmware, DT and kernel). So i would like to avoid this here. In > > > case the current implementation is a no go, how about letting the ARM core > > > discover the available interfaces e.g. via mailbox interface? > > > > > > For more inspiration take a look at this old thread [1] > > > > Yes, that's the proper way to do this please! This should be a bus and > > dynamically add the devices when found, it is NOT a platform device > > anymore. > > I'm fine with making this a bus, but when it comes to dynamically adding > devices, that depends on the firmware exposing an interface to enumerate > those devices. If that's not possible, are you fine with a custom bus > and hardcoded children device instantiation in the VCHIQ driver ? Yes, that is at least a step forward and is not abusing the platform device/driver code. thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel