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]

Date:   Mon, 7 Nov 2022 12:12:29 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     Luca Ceresoli <luca.ceresoli@...tlin.com>,
        Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
CC:     "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-media@...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>,
        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" <satish.nagireddy@...cruise.com>
Subject: Re: [PATCH v4 0/8] i2c-atr and FPDLink

On 11/7/22 13:48, Luca Ceresoli wrote:
> Hi Tomi, All,
> 
> On Tue,  1 Nov 2022 15:20:24 +0200
> Tomi Valkeinen <tomi.valkeinen@...asonboard.com> wrote:
>>
>> 2)
>> If I suggested adding an i2c-bus fwnode parameter to
>> i2c_mux_add_adapter(), and the i2c-bus might be under some other device,
>> I think the reception could be quite negative (and I would agree). For
>> this reason I'm not very happy with the i2c-atr and using it with
>> FPDLink.
>>
>> 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 tend to agree with Luca on keeping the I2C-atr a re-usable generic 
code. The reason why I did not (yet) bring this (or other concerns) up 
is that currently I don't have a permission to upstream my work for ROHM 
SerDes Linux drivers :( I still do discuss the decision but to be 
honest, I believe the chances to get my drivers upstream are getting 
slim. Hence I did not see it reasonable to try pushing Tomi's / Luca's 
work to any direction.

Yet, after that being said - these SerDes devices which can combine I2C 
buses from multiple remote devices to one local I2C controller do bring 
a real need for a solution like the address translation. Thus, I would 
not be surprized if we saw new devices with this kind of feature. 
Potentially also from other vendors. So, regardless what happens with 
ROHM SERDESes - I (too) think we should keep the ATR as independently 
reusable component.

Yours,
	-- Matti Vaittinen

-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~