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