linux-kernel - Re: [PATCH RFC] media: i2c: ds90ub960: Enable second i2c interface

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] [day] [month] [year] [list]

Message-ID: <0e9cef43-0f15-497c-9781-d31e5cd0adb7@ideasonboard.com>
Date: Wed, 2 Apr 2025 14:27:57 +0300
From: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To: Yemike Abhilash Chandra <y-abhilashchandra@...com>
Cc: linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
 vaishnav.a@...com, u-kumar1@...com, r-donadkar@...com, mchehab@...nel.org
Subject: Re: [PATCH RFC] media: i2c: ds90ub960: Enable second i2c interface

Hi,

On 20/03/2025 12:36, Yemike Abhilash Chandra wrote:
> Hi Tomi
> 
> On 18/03/25 20:16, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 05/03/2025 14:17, Yemike Abhilash Chandra wrote:
>>> The DS90UB960-Q1 includes a second I2C interface for independent control
>>> of the deserializer and remote devices. However, the current driver does
>>> not utilize it, thus restricting users to either CSI TX0 or CSI TX1 on
>>> the primary I2C interface. Enable the second I2C interface, allowing
>>> flexible routing where CSI TX0 can be used on the primary and CSI TX1 on
>>> the secondary, or vice versa by enabling appropriate ports in DT. To
>>> achieve the same only modify the bits relevant to the enabled RX and TX
>>> ports of that interface and during probe and enable_streams call, few
>>> registers were being reset to HW reset state, these operations are not
>>> necessary for functionality and resets the state when secondary I2C
>>> interface is probed, thus drop them.
>>
>> I'm a bit confused about the description. My recollection is that both 
>> CSI TX0 and TX1 can be programmed just fine from the first I2C 
>> interface. Is that not so?
>>
> 
> I apologize for not giving the entire context while sending the RFC.
> The purpose of this patch is not only to enable secondary I2C interface
> but also to overcome the v4l2 framework limitation by doing that.
> 
>> Also, even if the driver supports both CSI TXes, at the moment v4l2 
>> framework doesn't work with it, at least in many cases. E.g. if you 
>> connect one TX to a CSIRX, the other TX to another CSIRX, and those 
>> CSIRXes are independent, have their own media graphs, it's not going 
>> to work at all.
>>
> 
> Lets say that the overlay applied is as shown in [1]
> 
> [1]: https://gist.github.com/Yemike-Abhilash- 
> Chandra/5c53a5f3a77954b28c5bd4c27cd336a5

Ok. No, we can't merge anything like that. You're creating two linux 
devices for a single HW device, without any specific support for such. 
If it works for you, it's just by luck.

  Tomi