Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp1644628rwl; Mon, 26 Dec 2022 02:35:19 -0800 (PST) X-Google-Smtp-Source: AMrXdXt1JmCrZo9hT+HGeK6TGMd5YWTRyIPhQjYyPaRbLb47RIJIkPHNmTs7MIDkx/Ox0b03hkI6 X-Received: by 2002:aa7:8043:0:b0:573:487d:e852 with SMTP id y3-20020aa78043000000b00573487de852mr22004470pfm.4.1672050919151; Mon, 26 Dec 2022 02:35:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672050919; cv=none; d=google.com; s=arc-20160816; b=YmJTlhcb/U15LJm7AUXgS+w8mqk81qGGmleNgLQUr23q+20fSG8jLaa84r8kD/opcM +DtWwiB7pyDhQcvZiNSye94uIT6mVwbZJia+Cl+FGE2z2iQZx4KfGzE8VPf45zm6srrZ GOSdiQTSHpBA1qS1Wgi5m8mfz29NcX90s7q8dRJHbG6DlM00tWlMeweyyEvn1xxTAXej cZCXoTDyGflTDnqapaluER1bUPyFvXDgBf7H+PkwAdfQz+6Z4176M5Szx1D2OmyGhxbn YnnVyPspRKj7Mc3rzkAvkr/G12ejcP4y8o4VpGm6+E7YwbI0o99WLKYhX6AR4ey9E7oF JTJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=aQ08Ka/L64zbDdoTJaSYUsfIsqvDFfmqijk5Gy6d7v8=; b=CR00UEf7q32+a7szCEXZ3U/ukINKHk0f9UGy2Q2aZn3svjYWDptmq8g8k8shb0aVXO tdFIaYMlnaTo7gpCfHeLNbwh3scdPDhDIvRqODkKfp4DQ7Cbhx0K+ZcwNipeb2zMfF3n BX5xZjbTwOj0IK/BBQ3UN2qIhGZFnaXGubcQAX0xXjTguVMNWL0YqN+ebsrxbOUt9c1/ LBN7ueylOuOQGYpA27x3nOP2aHrbJof+ud2EKVpRW0tXXok84mM7F3vg5K6PLlh7rNZq zFxzXMPdSt8Wwp5SSq82RhKcRsuUqUYYf+6b3qnLgfM/+EUxCZABSVfDAkC+1j3zUr6N SoRw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=LEzCXCcv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b14-20020a056a000cce00b0057513273bb7si11472481pfv.132.2022.12.26.02.35.08; Mon, 26 Dec 2022 02:35:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=LEzCXCcv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231782AbiLZK1a (ORCPT + 66 others); Mon, 26 Dec 2022 05:27:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45330 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229500AbiLZK11 (ORCPT ); Mon, 26 Dec 2022 05:27:27 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 189235FD1; Mon, 26 Dec 2022 02:27:25 -0800 (PST) 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 ams.source.kernel.org (Postfix) with ESMTPS id A96D8B80D11; Mon, 26 Dec 2022 10:27:23 +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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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