linux-kernel - Re: [RFCv3 0/6] TI camera serdes and I2C address translation (Was: [RFCv3 0/6] Hi,)

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:   Tue, 8 Feb 2022 09:36:17 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
        Luca Ceresoli <luca@...aceresoli.net>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
CC:     "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Wolfram Sang <wsa@...-dreams.de>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Hans Verkuil <hverkuil-cisco@...all.nl>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Kieran Bingham <kieran.bingham@...asonboard.com>,
        Jacopo Mondi <jacopo@...ndi.org>,
        Vladimir Zapolskiy <vz@...ia.com>,
        Peter Rosin <peda@...ntia.se>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Lee Jones <lee.jones@...aro.org>
Subject: Re: [RFCv3 0/6] TI camera serdes and I2C address translation (Was:
 [RFCv3 0/6] Hi,)

On 2/8/22 10:28, Tomi Valkeinen wrote:
> I'm curious, why do you think using MFDs makes the driver so much 
> cleaner? The current fpdlink driver is in one file, but, say, if we 
> split it to multiple files, based on the function, while still keeping 
> it as a single driver, would that be so much different from an MFD 
> solution? Is there something in the MFD approach that makes the code 
> simpler?

Fair question.

I personally have two reasons - one technical which I could just throw 
here and hope everyone buys it :) But I think the main reason for me to 
initially think of MFD is not a technical one.

Last few years I've spent working with PMICs/chargers - which were MFD 
to the bone. Before that I worked on a proprietary clocking/all-purpose 
FPGA as well as with ASIC routing RP3/RP301 links + providing timing 
facilities / clocks. Those were also MFD devices - and one of those used 
MFD drivers, the other didn't although it really should have.

So the non technical reason for me is that I am used to seeing 
multi-function devices implemented as MFD devices - hence I immediately 
saw the SERDES as one too.

One the technical benefit from MFD is that it (in many cases) allows one 
to use standard way to re-use code. Eg, it's not a rare case that same 
HW blocks are used in many projects. One can for example see three 
different PMICs, all having same RTC and clk blocks, while different 
regulators and GPIOs - or some just omitting one of those.

MFD allows 'collecting' these IP blocks under different umbrellas by 
kicking same subdevices alive via different MFD devices in a standard 
way. The IP block (say GPIO controller) we are driving can be 
implemented on SER connected by FPDLINK III to DES - or it can be 
implemented in PMIC - the absolutely same standrd (mfd sub) platform 
GPIO driver can be used in both cases.

Other than that, the use of MFD allows one to write pinctrl/gpio driver 
as any pinctrl/gpio platform device driver. It will be looking familiar 
to anyone who has worked with pinctrl/gpio - even if he has never seen 
media/v4l2 ;) This is where my thought of clarity came from.

Rest is slightly offtopic - you can stop reading.

I am not sure how TI does this and if you know whether same blocks can 
be used in other devices. I just have learned never to trust it when a 
HW engineer (in Nokia, Rohm or other company) tells me "this is the last 
IC using this technology". It may be my problem though as nor do I buy 
it if someone says me: "the next version will be just same to this 
previous - there is no software impact" :rolleyes: I for example once 
heard that when the "next product" maintained same register offsets for 
some functions - but did add new ones - and changed the registers from 
16bit => 32bit and connecting bus from PCIe => I2C... I remember that 
project with a nicknames 're-estimate' 'reschedule' and 'panic-button' :)

Yours
	-- Matti

-- 
The Linux Kernel guy at ROHM Semiconductors

Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND

~~ this year is the year of a signature writers block ~~