On Wed, Feb 14, 2024 at 09:26:13AM -0800, Kevin Hilman wrote: > Conor Dooley <conor@xxxxxxxxxx> writes: > > On Wed, Feb 14, 2024 at 03:01:06PM +0530, Bhargav Raviprakash wrote: > >> On Fri 2/9/2024 10:41 PM, Conor Dooley wrote: > >> > On Thu, Feb 08, 2024 at 04:23:33PM +0530, Bhargav Raviprakash wrote: > >> > > TPS65224 is a Power Management IC with 4 Buck regulators and 3 LDO > >> > > regulators, it includes additional features like GPIOs, watchdog, ESMs > >> > > (Error Signal Monitor), and PFSM (Pre-configurable Finite State Machine) > >> > > managing the state of the device. > >> > > >> > > TPS6594 and TPS65224 have significant functional overlap. > >> > > >> > What does "significant functional overlap" mean? Does one implement a > >> > compatible subset of the other? I assume the answer is no, given there > >> > seems to be some core looking registers at different addresses. > >> > >> The intention behind “significant functional overlap” was meant to > >> indicate a lot of the features between TPS6594 and TPS65224 overlap, > >> while there are some features specific to TPS65224. > >> There is compatibility between the PMIC register maps, I2C, PFSM, > >> and other drivers even though there are some core registers at > >> different addresses. > >> > >> Would it be more appropriate to say the 2 devices are compatible and have > >> sufficient feature overlap rather than significant functional overlap? > > > > If core registers are at different addresses, then it is unlikely that > > these devices are compatible. > > That's not necessarily true. Hardware designers can sometimes be > creative. :) Hence "unlikely" in my mail :) > > In this context, compatible means that existing software intended for > > the 6594 would run without modification on the 65224, although maybe > > only supporting a subset of features. If that's not the case, then > > the devices are not compatible. > > Compatible is a fuzzy term... so we need to get into the gray area. > > What's going on here is that this new part is derivative in many > signifcant (but not all) ways from an existing similar part. When > writing drivers for new, derivative parts, there's always a choice > between 1) extending the existing driver (using a new compatible string > & match table for the diffs) or 2) creating a new driver which will have > a bunch of duplicated code. > > The first verion of this series[1] took the 2nd approach, but due to the > significant functional (and feature) overlap, the recommendation was > instead to take the "reuse" path to avoid signficant amounts of > duplicated code. > > Of course, it's possible that while going down the "reuse" path, there > may be a point where creating a separate driver for some aspects might > make sense, but that needs to be justified. Based on a quick glance of > what I see in this series so far (I have not done a detailed review), > the differences with the new device look to me like they can be handled > with chip-specific data in a match table. This is all nice information, but not really relevant here - this is a binding patch, not a driver one & the conversation stemmed from me making sure that a fallback compatible was not suitable. Whether or not there are multiple drivers or not is someone else's problem! Thanks, Conor.
Attachment:
signature.asc
Description: PGP signature
