Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp13291270rwl; Wed, 4 Jan 2023 06:16:11 -0800 (PST) X-Google-Smtp-Source: AMrXdXvdvIIlUgx5/YR5jE76WVUMQlHpMdjP7Oq9jkLvq5Ab6i4DxtIPHbpSPIoh/jEYj7f7XdN6 X-Received: by 2002:a05:6402:345a:b0:484:e097:7ac1 with SMTP id l26-20020a056402345a00b00484e0977ac1mr27319869edc.22.1672841771223; Wed, 04 Jan 2023 06:16:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672841771; cv=none; d=google.com; s=arc-20160816; b=VNQmeuizTpyKQEkBO1sNXQQvATQkGf1mR4iuhDZyKhpoxpng9LfE/YQP76oSxYq/1N fujC58f0jPajsAYlCTESIldKRvL5s+PZFnS7cAmOMOoHB0DicCWH4Nj1W5A8QUZORStQ BBKOzh3bL8LLOLgRd3W7Wwvq2MvbG6qTfd67eu6Yi/MUU/e7QlCSLnqwc8Og1gSzytaJ vnRehPafFTUcuVPoDb5kIhLG5Qw411KycR+9jFKUg8+7QUuSkyJfMqiTPyhO4krqWVgq evN+XQPOXsmup34prswgyF6WDniFaaqzlRUkvWQRltiVmf6iFnt+55faxOdm2MOAO7XQ PXlA== 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=UXOLUCY6Zpr4Rt1VRnjIAJrXqiKaC+wtPdrwh9IcBmo=; b=JawDmTABbGoKnl/HHILQ352weRBsHmG0mtdnrt8Vuin16eGr5w1/XGRRRryU3zR1TY lLjtQ5Ry6FbFctr4EfKxMTpi1gjTqAulgOa+Nn7QUEJRhzE7HuWvWkUfCLX/LcWxxnJ8 PyK5KmXDJ6RzTThB8z8iKzrMuzUF8X+A2q9sMZe2vesUvgb2kNvURdn0E1KQz7hfYVhj ULXtd+kH8oyy4ZnhVMyAEp6CXn2GMr26JFSmOHp6FvkRZqElM+QpmmzJ9pG2z0wQPJWR tCjCNKR+QeY8nBywZbujB3FvJg/96qcuumHpQTAZMkE+tEEwkTPJRAJOjdvZwsH4aODS Kbsg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=Adk7Siic; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v3-20020a056402174300b00461540620f1si27079990edx.169.2023.01.04.06.15.57; Wed, 04 Jan 2023 06:16:11 -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 (test mode) header.i=@ideasonboard.com header.s=mail header.b=Adk7Siic; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239357AbjADN4C (ORCPT + 57 others); Wed, 4 Jan 2023 08:56:02 -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> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,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 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