Messages in this thread | | | From | "Vaittinen, Matti" <> | Subject | Re: [PATCH v4 0/8] i2c-atr and FPDLink | Date | Mon, 7 Nov 2022 17:47:07 +0000 |
| |
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! ~~
| |