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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83C68C5479D for ; Wed, 4 Jan 2023 13:56:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239346AbjADN4B (ORCPT ); Wed, 4 Jan 2023 08:56:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233373AbjADN4A (ORCPT ); Wed, 4 Jan 2023 08:56:00 -0500 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 118C3260; Wed, 4 Jan 2023 05:55:59 -0800 (PST) Received: from pendragon.ideasonboard.com (213-243-189-158.bb.dnainternet.fi [213.243.189.158]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id F0B1B6F0; Wed, 4 Jan 2023 14:55:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1672840557; bh=upbq8ae2FZJb0op+c7L/iVvpVZ0tuSM70IZxIgj4xxQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Adk7SiicoFw4s0rpd9scAI6FTP/uQw8Qt0zilZLE2i/Pl25jYLs0NzHb+8G1KC0q+ 3b8aNyZ4EPJ88t8t2QIaPAr24jDv17upSMXrcAgBe7lSUwMQKAylJcV1OjcbSNbX8n 38JVUUuB32nRNRWCDEit1hY/rNFC03oLAkFO+6MY= Date: Wed, 4 Jan 2023 15:55:53 +0200 From: Laurent Pinchart To: Tomi Valkeinen Cc: linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org, Rob Herring , Krzysztof Kozlowski , Wolfram Sang , Luca Ceresoli , Andy Shevchenko , Matti Vaittinen , Mauro Carvalho Chehab , Peter Rosin , Liam Girdwood , Mark Brown , Sakari Ailus , Michael Tretter , Shawn Tu , Hans Verkuil , Mike Pagano , Krzysztof =?utf-8?Q?Ha=C5=82asa?= , Marek Vasut Subject: Re: [PATCH v5 7/8] media: i2c: add DS90UB913 driver Message-ID: References: <20221208104006.316606-1-tomi.valkeinen@ideasonboard.com> <20221208104006.316606-8-tomi.valkeinen@ideasonboard.com> <4d349785-ca37-d930-db3c-2581bba9fde0@ideasonboard.com> <7ddd576f-6e8a-7581-178c-2e8575227811@ideasonboard.com> <61729020-0977-521a-6137-3bd89f300652@ideasonboard.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <61729020-0977-521a-6137-3bd89f300652@ideasonboard.com> Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Hi Tomi, On Mon, Dec 26, 2022 at 09:25:34PM +0200, Tomi Valkeinen wrote: > On 26/12/2022 18:56, Laurent Pinchart wrote: > > On Wed, Dec 14, 2022 at 08:36:47AM +0200, Tomi Valkeinen wrote: > >> On 14/12/2022 08:29, Tomi Valkeinen wrote: > >> > >>>> wondering if the struct device of the DS90UB913 could be passed instead > >>>> of the port, to avoid passing the port throught > >>>> ds90ub9xx_platform_data. > >>> > >>> Interesting thought. That would limit the number of remote i2c busses to > >>> one, though. Not a problem for FPD-Link, but I wonder if that's assuming > >>> too much for the future users. Then again, this is an in-kernel API so > >>> we could extend it later if needed. So I'll try this out and see if I > >>> hit any issues. > >> > >> Right, so the issue with this one would be that it would prevent a > >> single device uses. E.g. a single chip which acts as an ATR (similar to > >> i2c-mux chips), i.e. it contains both the main and the remote i2c busses. > > > > I don't think I understand this, sorry. > > What you are suggesting above means that we'd have a separate device for > each port of the ATR. Which is fine in our current case, as the i2c > master busses are behind separate remote devices. > > But if you consider a case similar to i2c-mux, where we have a single > chip with the slave bus and, say, 4 master busses. We would probably > have only a single device for that. Hmmm... Yes you're right, it won't work in that case. Maybe we could have two functions, the existing i2c_atr_add_adapter(), and another one that wraps it ? It would be nice if we could get rid of the platform data for the UB913 and UB953 drivers. -- Regards, Laurent Pinchart