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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 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.

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, and using MFD I could share lot of code between them. But I still can't see why that's better than having both UB960 and UB9702 in the same driver (and, if the amount of supported devices increases, perhaps dividing some parts to separate files and using function points for a few things).

The benefit would be more obvious if there was some other type of IC that uses the same IP subcomponents. Maybe the display side FPDLink devices are such, but I have never done a deep dive in their documentation. And, even then, I think I still have the question: can we just move to an MFD later when the need comes?

Also, isn't the use or non-use of MFD strictly a driver private thing, 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? ;)

 Tomi




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux