Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp403937rwr; Thu, 20 Apr 2023 00:42:32 -0700 (PDT) X-Google-Smtp-Source: AKy350bHzXowLTqd7Om5xX9zkX3V3f1VddX0QJBSuov9ZBErteazSLx0dCimFAMSKfLTAzwDtnuU X-Received: by 2002:a05:6a00:1948:b0:634:4f6:86df with SMTP id s8-20020a056a00194800b0063404f686dfmr631125pfk.1.1681976552273; Thu, 20 Apr 2023 00:42:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681976552; cv=none; d=google.com; s=arc-20160816; b=mjRlcl6bwjFr0vpn1C7WS37jgdFI1ZM0/5U4gVan+XMdby/vNe0EkjTPtRUJ0e0EMG 9ZoNWwUXia60RWSWsOfLj+tFRc42Zi4aRc4XvV0ziuyc+16VTTtZ5bDnlVEjAuCf8NCN 1PZDutXH817MpAdlSLY0Wx40iXUgaoQhnqRypUCKkJJohJmnWH4g0cRuuU5pF0ex+P96 2j6s5o71lueX09kJ1s2At49rybeYhKZ06ws8zLvUTujD3CuzpP2kNjaZE2zE+TsMeG2Z L4c6ZZBvDi+RGxXfSimRknvTZhoEbkfHpkriXyQ9JbeH1Etp4F2ZcLOQ1/LKVshBR1sF v5hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:dkim-signature; bh=qp6BNbBpJsFMEYC17dfhKoxtP/WqXuO6fYFIgnuNakI=; b=VZg/lpRF9PbJq50KygA93P+WixsRRPxOYfL70k4W9BduZsAebV0dxcFtLOlQ3nVWa8 ENWsByGZLmNdTSI0ivuLLFbRiLkVhfJgB0Yqk3IFcRTKZys8T4Cvh4ApJoVWIBQ1is8m lFE+Qj+AU+rkfAO9CWUuIxUvIIFc1INISIHTxSZOKsHAmVHKgIHKC3lBM80FTE2ECXi9 IL72fUdfCBT7HBhRFi78caAq4UK7veMI19afW5dQf6QKU7JQ1uyZwuDTl7Rs2/1TApxW XyPSt8ATDcTgdhgsStWYbyfHXsH2MpkijYkmWg/bGKf39s+ePjYEzQwV1pWiy0z2eG/p /nHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=eINLHip+; 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 e14-20020aa7980e000000b0063b7acc199bsi1052360pfl.65.2023.04.20.00.42.20; Thu, 20 Apr 2023 00:42:32 -0700 (PDT) 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=eINLHip+; 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 S234109AbjDTHar (ORCPT + 99 others); Thu, 20 Apr 2023 03:30:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44510 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233819AbjDTHap (ORCPT ); Thu, 20 Apr 2023 03:30:45 -0400 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1C7BC6; Thu, 20 Apr 2023 00:30:26 -0700 (PDT) Received: from [192.168.88.20] (91-154-35-171.elisa-laajakaista.fi [91.154.35.171]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 6A92A75B; Thu, 20 Apr 2023 09:30:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1681975817; bh=LSTUdwSzih54Ne5MHSrVZTV2gSAf73YZM/ix1OR5sSM=; h=Date:Subject:To:References:From:In-Reply-To:From; b=eINLHip+7W7yspC8vrI6Q7upOEFVPAKsa5wFC3BBqLZAiiQvtAnllddOvVgD9oKDu AeDmRW7Ngr4Auw3rvYLCIGkkHTnT7naDl5pMxjxx7ktoLAenkSgqm4OG2gX+FYNJEe uBNocvBtFJAo/N02BDS5hJnB+IA/Q9pWdRLyrT/I= Message-ID: Date: Thu, 20 Apr 2023 10:30:19 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v10 5/8] dt-bindings: media: add TI DS90UB960 FPD-Link III Deserializer To: Wolfram Sang , linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org, Rob Herring , Krzysztof Kozlowski , Luca Ceresoli , Andy Shevchenko , Matti Vaittinen , Laurent Pinchart , Mauro Carvalho Chehab , Peter Rosin , Liam Girdwood , Mark Brown , Sakari Ailus , Michael Tretter , Hans Verkuil , Mike Pagano , =?UTF-8?Q?Krzysztof_Ha=c5=82asa?= , Marek Vasut , Satish Nagireddy , Rob Herring , Laurent Pinchart References: <20230222132907.594690-1-tomi.valkeinen@ideasonboard.com> <20230222132907.594690-6-tomi.valkeinen@ideasonboard.com> Content-Language: en-US From: Tomi Valkeinen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS, SPF_PASS,T_SCC_BODY_TEXT_LINE 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 18/04/2023 16:06, Wolfram Sang wrote: > >> + i2c-alias-pool: >> + $ref: /schemas/types.yaml#/definitions/uint16-array >> + description: >> + I2C alias pool is a pool of I2C addresses on the main I2C bus that can be >> + used to access the remote peripherals on the serializer's I2C bus. The >> + addresses must be available, not used by any other peripheral. Each >> + remote peripheral is assigned an alias from the pool, and transactions to >> + that address will be forwarded to the remote peripheral, with the address >> + translated to the remote peripheral's real address. This property is not >> + needed if there are no I2C addressable remote peripherals. > > After some initial discussion with Tomi on IRC, this question is > probably more for Luca: > > Why is "i2c-alias-pool" in the drivers binding and not a regular i2c Where should be the binding documented? A new Documentation/devicetree/bindings/i2c/i2c-atr.yaml file that only contains the i2c-alias-pool? > binding? Same question for the implementation of the alias-pool > handling. Shouldn't this be in the i2c-atr library? I'd think managing > the list of aliases would look all the same in the drivers otherwise? I think this is fine, but I also think that we need to keep the door open to other kinds of alias management. We only have a single user for this for now. A driver/device might have other requirements for its i2c-atr. Say, a pool per link, or perhaps runtime events may affect the pool. If we dictate the use of i2c-alias-pool property and the i2c-atr will automatically get an alias from that pool, i2c-atr won't be usable for the hypothetical drivers that have other needs. With that in mind the current binding and i2c-atr.c is safe, as the i2c-atr.c isn't even aware of the pool. We can easily re-arrange the code later if and when we get more users and understand their needs. But the bindings are important to get right(-ish) now. So: - Is the "i2c-alias-pool" property a driver property or a common property for all drivers using i2c-atr? - It the property mandatory or optional? It must be optional, as a setup (meaning, e.g., what cameras you happen to connect) might not have any i2c addressable remote devices, in which case the driver doesn't even need i2c-atr (even if it supports i2c-atr). But is it optional even in the case where the driver needs i2c-atr? In other words, do we allow some other way to manage the aliases? How does this sound: - If "i2c-alias-pool" is present in the DT data of the device passed to i2c_atr_new(), i2c_atr_new() will parse the property. i2c-atr.c will export functions to get a new alias and to release a previously reserved alias. The driver can use those functions in attach/detach_client() callbacks. In other words, the alias pool management wouldn't be fully automatic inside the i2c-atr, but it would provide helpers for the driver to do the common work. - If "i2c-alias-pool" is not present, i2c-atr.c will behave as it does now, and expects the driver to manage the aliases. Also, looking at the ub960 code... I don't think this will simplify the attach/detach_client callbacks much. Most of the code in those functions is about managing the UB960's registers related to ATR, not managing the address pool itself. However, it will remove the probe time "i2c-alias-pool" parsing from the driver, which is nice. Tomi