RE: [PATCH v4 1/4] dt-bindings: mfd: Document RZ/G2L MTU3a bindings

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

 



Hi William Breathitt Gray,

> Subject: Re: [PATCH v4 1/4] dt-bindings: mfd: Document RZ/G2L MTU3a
> bindings
> 
> On Tue, Oct 11, 2022 at 08:31:48PM +0000, Biju Das wrote:
> > > Subject: Re: [PATCH v4 1/4] dt-bindings: mfd: Document RZ/G2L
> MTU3a
> > > bindings
> > >
> > > On 11/10/2022 15:23, Biju Das wrote:
> > > >> Subject: Re: [PATCH v4 1/4] dt-bindings: mfd: Document RZ/G2L
> > > >> MTU3a bindings
> > > >>
> > > >> On 11/10/2022 10:55, Biju Das wrote:
> > > >>>
> > > >>>>>  .../bindings/mfd/renesas,rz-mtu3.yaml         | 305
> > > >>>> ++++++++++++++++++
> > > >>>>>  1 file changed, 305 insertions(+)  create mode 100644
> > > >>>>> Documentation/devicetree/bindings/mfd/renesas,rz-mtu3.yaml
> > > >>>>
> > > >>>> This should not be in MFD. Just because some device has few
> > > >> features,
> > > >>>> does not mean it should go to MFD... Choose either timer or
> pwm.
> > > >>>
> > > >>> MFD is for multifunction device. This IP supports multiple
> > > functions
> > > >>> like timer, pwm, clock source/events. That is the reason I
> have
> > > >> added
> > > >>> here. MFD is core which provides register access for client
> > > devices.
> > > >>>
> > > >>> For me moving it to pwm or counter is not a big problem.
> > > >>> Why do you think it cannot be MFD?
> > > >>
> > > >>
> > > >> Because it makes MFD a dump for everything where author did not
> > > want
> > > >> to think about real device aspects, but instead represented
> > > >> driver design (MFD driver).
> > > >
> > > > Core driver is MFD, just provides resources to child devices and
> > > > is not aware of any real device aspects.
> > > >
> > > >>
> > > >> MFDs are pretty often combining unrelated features, e.g. PMICs
> > > which
> > > >> have wakeup and system power control, regulator, 32 kHz clocks,
> > > >> RTC and some USB connector.
> > > >
> > > > Here also same right? pwm, counter and clock are 3 unrelated
> > > features.
> > > > That is the reason we have separate subsystems for these
> features.
> > >
> > > These are quite similar features of a similar piece of hardware.
> > > Sometimes called timer.
> > >
> > > >
> > > >>
> > > >> Just because you will have clocksource driver, PWM driver and
> > > >> timer driver does not make it a MFD.
> > > >
> > > > MFD is multi function device.
> > >
> > > No. MFD is a Linux subsystem name. Not a device type. The bindings
> > > are located in respective type.
> > >
> > > > So are are you agreeing Clock source, PWM and timer are
> different
> > > > functionalities or not? If not, why do we have 3 subsystems, if
> it
> > > is
> > > > same?
> > >
> > > Linux subsystems? We can have millions of them and it is not
> related
> > > to bindings.
> >
> > OK.
> >
> > >
> > >
> > > > Where do keep these bindings as there is only single "rz_mtu"
> > > bindings for these 3 different functionalities?
> > >
> > > Again, focus on hardware not on Linux drivers. Hardware is called
> > > MTU
> > > - Multi-Function TIMER Unit. Timer.
> >
> > OK
> > >
> > > > pwm or counter or mfd?
> > >
> > > Not MFD. I already proposed where to put it. Other
> Timer/PWM/Counter
> > > units are also in timer.
> > >
> >
> > I guess for counter/pwm maintainers, it is ok to model MTU3 as a
> > single binding "rz-mtu3" in timer that binds against counter and pwm
> > functionalities as well??
> >
> > Cheers,
> > Biju
> 
> I'm okay with putting the MTU3 binding under timer; we already have
> Documentation/devicetree/bindings/timer/renesas,mtu2.yaml there so
> adding a new renesas,mtu3.yaml next to it seems reasonable.

OK.

> 
> Just to reiterate Krzysztof's point, the subsystems in Linux serve as
> a way to group drivers together that utilize the same ABIs, whereas
> the devicetree is a structure for organizing physical hardware. The
> structure of physical hardware types don't necessarily match the
> organization of the ABIs we use to support them. This is why you may
> end up with differing heirarchies between the devicetree and driver
> subsystems.
> 
> To illustrate the point, take for example a hypothetical digital-to-
> analog (DAC) device with a few GPIO lines. Those GPIO input signals
> could be tied to buttons used to indicate to the system that a user
> wants to reset or adjust the DAC output, while the GPIO output signals
> could be status lights or triggers indicating that the DAC is
> operating. The respective driver for this device may utilize the IIO
> subsystem to support the DAC and the GPIO subsystem to support those
> GPIO lines, but it would be incorrect to put this under MFD because
> the purpose of the GPIO lines is to assist in the operation of the
> DAC; in other words, this is primarily a DAC device with some
> auxiliary convenience functionalities, not a MFD with distinct
> unrelated separate components.

OK agreed. Thanks for the explanation.

Cheers,
Biju




[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