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

Vaittinen, Matti
2022-11-07T17:48:01Z

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