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