linux-kernel - Re: [PATCH v4 0/8] i2c-atr and FPDLink

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <228da3c5-44b1-153c-c6e6-3bc221209bec@ideasonboard.com>
Date:   Mon, 7 Nov 2022 14:12:57 +0200
From:   Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To:     Luca Ceresoli <luca.ceresoli@...tlin.com>
Cc:     devicetree@...r.kernel.org, linux-i2c@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
        Hans Verkuil <hverkuil-cisco@...all.nl>,
        Jacopo Mondi <jacopo@...ndi.org>,
        Kieran Bingham <kieran.bingham@...asonboard.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Luca Ceresoli <luca@...aceresoli.net>,
        Mark Rutland <mark.rutland@....com>,
        Matti Vaittinen <Matti.Vaittinen@...rohmeurope.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Peter Rosin <peda@...ntia.se>,
        Rob Herring <robh+dt@...nel.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Vladimir Zapolskiy <vz@...ia.com>,
        Wolfram Sang <wsa@...-dreams.de>,
        satish.nagireddy@...cruise.com
Subject: Re: [PATCH v4 0/8] i2c-atr and FPDLink

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