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;
Message-ID: <228da3c5-44b1-153c-c6e6-3bc221209bec@ideasonboard.com>
Date:   Mon, 7 Nov 2022 14:12:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Subject: Re: [PATCH v4 0/8] i2c-atr and FPDLink
Content-Language: en-US
To:     Luca Ceresoli <luca.ceresoli@bootlin.com>
Cc:     devicetree@vger.kernel.org, linux-i2c@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
        Hans Verkuil <hverkuil-cisco@xs4all.nl>,
        Jacopo Mondi <jacopo@jmondi.org>,
        Kieran Bingham <kieran.bingham@ideasonboard.com>,
        Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        Luca Ceresoli <luca@lucaceresoli.net>,
        Mark Rutland <mark.rutland@arm.com>,
        Matti Vaittinen <Matti.Vaittinen@fi.rohmeurope.com>,
        Mauro Carvalho Chehab <mchehab@kernel.org>,
        Peter Rosin <peda@axentia.se>,
        Rob Herring <robh+dt@kernel.org>,
        Sakari Ailus <sakari.ailus@linux.intel.com>,
        Vladimir Zapolskiy <vz@mleia.com>,
        Wolfram Sang <wsa@the-dreams.de>,
        satish.nagireddy@getcruise.com
References: <20221101132032.1542416-1-tomi.valkeinen@ideasonboard.com>
 <20221107124814.19b12473@booty>
From:   Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
In-Reply-To: <20221107124814.19b12473@booty>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 07/11/2022 13:48, Luca Ceresoli wrote:

>> In fact, I'm thinking that it might be better to just drop the i2c-atr
>> driver, and add the support directly to the FPDlink drivers. But that
>> could mean possibly duplicating the same code for other deser/ser
>> architectures, so I have kept the i2c-atr driver for now.
> 
> Indeed I think the ROHM serdes chips do have an address translation
> feature that works pretty much like the TI ones, and the ATR should be
> cleanly reusable across the two brands. The ATR code might be
> simplified to just provide helpers for common code maybe, but I'd
> rather avoid code duplication.

I agree. The reason I'm wondering about this is the fact that the i2c 
slave side (deser) is in a different IC and driver than the i2c master 
side and driver (ser). That makes it quite different from the i2c-mux 
(at least how the i2c-mux exists now).

  Tomi