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: <74d8aa71-1133-537d-3de9-e6efd458025f@fi.rohmeurope.com>
Date:   Mon, 7 Nov 2022 17:47:07 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
        "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>
CC:     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

Evening Tomi,

On 11/7/22 17:37, Tomi Valkeinen wrote:
> Hi Matti,
> 
> On 07/11/2022 16:37, Vaittinen, Matti wrote:
> 
> I only had time to have a brief look at your code, but I have a few 
> quick questions.
> 
>> I think it was Tomi who asked me the benefit of using MFD. In some cases
>> the digital interface towards pinctrl/GPIO or other functional blocks in
>> SER/DES is re-used from other products - or the blocks are re-used on
>> other products. Separating them in own platform-drivers is a nice way to
>> re-use drivers and avoid code duplication.
> 
> Is there anything that prevents us (or makes it difficult) from 
> refactoring a "monolithic" driver into an MFD later? If we see such IP 
> re-use, can we then move to an MFD?

I haven't done such conversion. I think the work for doing the 
conversion at later phase is roughly same it would be now. However, 
synchronizing such change with related subsystem trees might be some 
extra work.

> I admit I have never written an MFD driver (but I have hacked with a few 
> years back). As I see it, the "subcomponents" in FPDLink ICs are more or 
> less tied to the FPDLink. It's not like they're independent. Compare to, 
> for example, a PMIC which provides regulators and GPIOs, and possibly 
> the only shared part between those two features are the pins.

I think that in SerDes driver case the benefit may come from re-use and 
clarity. Smaller drivers tend to be easier to comprehend, although I 
liked the way you had divided the drivers in sections.

> So, I think I'm still wondering about the benefit...
> 
> In the current version I have the deser driver supporting UB960 and 
> UB9702. I guess I could split those into separate drivers,

I wouldn't break the driver per IC. If the ICs are similar enough to be 
nicely handled by same driver, then they probably should.

> 
> The benefit would be more obvious if there was some other type of IC 
> that uses the same IP subcomponents.

Yes. Same or similar subcomponents. This indeed is the benefit I see. I 
don't know if TI could use same - say GPIO - control logic on another 
type of device? Or, maybe separating the logic could guide one to use 
some generic stuff like regmap_gpio driver? And finally, submitting 
small platform drivers via respective subsystems can yield better review ;)

> 
> Also, isn't the use or non-use of MFD strictly a driver private thing, 

I am tempted to say "yes", but when giving it a thought - it's really 
not fully that. Splitting a driver to subdrivers can allow re-use of 
subcomponents by unrelated ICs. OTOH, always stuffing everything in a 
driver "because it is driver internal decision" can lead to code 
duplication and bloat.

> it should not affect any shared parts or shared designs? In other words, 
> if you have your ROHM hat on, why do you care how the UB9xx driver is 
> structured internally? ;)

As I wrote:
 > > Please, do not treat this as a requirement - please treat it as a 
food for thoughts ;)

Eg, I am not trying to tell you how to do the UB9xx drivers. I just 
think that considering another design _might_ result more optimal design 
- but I do leave the decision to you who know this area better than I do.

Yours
	-- Matti

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

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