linux-kernel - RE: [PATCH v4 1/2] dt-bindings: timer: Add bindings for Intel Keem Bay SoC Timer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 15 Jul 2021 08:01:58 +0000
From:   "Sanil, Shruthi" <shruthi.sanil@...el.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Rob Herring <robh@...nel.org>
CC:     Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "kris.pan@...ux.intel.com" <kris.pan@...ux.intel.com>,
        Mark Gross <mgross@...ux.intel.com>,
        "Thokala, Srikanth" <srikanth.thokala@...el.com>,
        "Raja Subramanian, Lakshmi Bai" 
        <lakshmi.bai.raja.subramanian@...el.com>,
        "Sangannavar, Mallikarjunappa" 
        <mallikarjunappa.sangannavar@...el.com>
Subject: RE: [PATCH v4 1/2] dt-bindings: timer: Add bindings for Intel Keem
 Bay SoC Timer

> -----Original Message-----
> From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> Sent: Wednesday, July 14, 2021 7:51 PM
> To: Rob Herring <robh@...nel.org>
> Cc: Sanil, Shruthi <shruthi.sanil@...el.com>; Daniel Lezcano
> <daniel.lezcano@...aro.org>; Thomas Gleixner <tglx@...utronix.de>; linux-
> kernel@...r.kernel.org; devicetree@...r.kernel.org;
> kris.pan@...ux.intel.com; Mark Gross <mgross@...ux.intel.com>; Thokala,
> Srikanth <srikanth.thokala@...el.com>; Raja Subramanian, Lakshmi Bai
> <lakshmi.bai.raja.subramanian@...el.com>; Sangannavar, Mallikarjunappa
> <mallikarjunappa.sangannavar@...el.com>
> Subject: Re: [PATCH v4 1/2] dt-bindings: timer: Add bindings for Intel Keem
> Bay SoC Timer
> 
> On Wed, Jul 14, 2021 at 08:07:44AM -0600, Rob Herring wrote:
> > On Wed, Jul 14, 2021 at 3:04 AM Andy Shevchenko
> > <andriy.shevchenko@...ux.intel.com> wrote:
> > > On Tue, Jul 13, 2021 at 08:47:56PM -0600, Rob Herring wrote:
> > > > On Mon, Jun 28, 2021 at 11:44:09AM +0530, shruthi.sanil@...el.com
> wrote:
> > >
> > > > > +  The parent node represents the common general configuration
> > > > > + details and  the child nodes represents the counter and timers.
> > > >
> > > > I don't think all the child nodes are necessary. Are the counters
> > > > and timers configurable (say on another SoC)? If not, then a
> > > > single node here would suffice.
> > >
> > > If you may notice the children may have different properties that
> > > can't be known ahead, such as IRQ line. On some platforms it may be
> > > this mapping, on another it maybe different.
> >
> > What I noticed is it's all the same clock and 1 interrupt for each
> > timer can be just a single 'interrupts' property with 8 entries.
> 
> This may work.
> 
> > Is there a platform that's different or that's a hypothetical? Because
> > hypothetically, every aspect of every IP could change. But we don't
> > try to parameterize everything in DT. It's a judgement call between
> > implying things from compatible and explicit DT properties.
> >
> > > With all respect for the simplification I think we can't do it here.
> >
> > You can. Any data in DT could be in the kernel. It's a question of
> > balance, not can or can't.
> 
> Not only, it's also matters of what exactly hardware is: 8 timers or timer with
> 8 channels. If it's the former one, I prefer to have DT exactly like originally
> suggested, otherwise I will agree on your proposal.

Yes Andy, its correct, we have 8 timers in the hardware which are independent.
Also the timer framework provides option to parse all the device tree details. In this case we would pass the timer node to the framework and get the base, IRQ and clock. If we go for a single node approach then all these need to be handled in the driver, hence making it complicated.

Regards,
Shruthi

> 
> --
> With Best Regards,
> Andy Shevchenko
>