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

["Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>]

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! ~~