linux-kernel - Re: [PATCH v3 04/12] of: add J-Core timer bindings

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]

Message-ID: <20160623211608.GA10893@brightrain.aerifal.cx>
Date:	Thu, 23 Jun 2016 17:16:08 -0400
From:	Rich Felker <dalias@...c.org>
To:	Rob Herring <robh@...nel.org>
Cc:	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	SH-Linux <linux-sh@...r.kernel.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Mark Rutland <mark.rutland@....com>,
	Pawel Moll <pawel.moll@....com>
Subject: Re: [PATCH v3 04/12] of: add J-Core timer bindings

On Thu, Jun 02, 2016 at 05:44:25PM -0500, Rob Herring wrote:
> > > > In theory it would even be possible to just require a DT node per
> > > > cpulocal timer, but I didn't see a good way to make the bindings
> > > > represent the relationship to cpus or to make the driver handle irqs
> > > > correctly for such a setup, so I'd need a viable proposal for how that
> > > > could be done to even consider such an approach.
> > > 
> > > Yeah, there's not really a standard way to map per cpu blocks to cpus.
> > > We could, but doesn't really seem necessary here.
> > > 
> > > For the irqs, percpu irqs doesn't help you?
> > 
> > What I mean is that, if there were a separate device node and driver
> > instance per cpu, they'd all want to register the same irq just to
> > handle it on their own cpu, so we'd have a lot of spurious handlers
> > running. The right way to model this, I think, would be as a virtual
> > irqchip that's the irq parent of all the timer nodes, and that
> > multiplexes the real irq to one virq per cpu (where the current cpu id
> > becomes the irq number in its irq domain). But that's a lot of virtual
> > infrastructure just for the sake of modelling each percpu timer as its
> > own DT node and I don't think it makes sense to do it that way.
> 
> I would have thought your interrupt controller did all this. On the ARM 
> GIC for example, you have the same irq number but there is a per cpu 
> interface and really N (== # cpus) physical irq lines.

I've looked at the ARM GIC code and bindings and I don't see where the
per-cpu interrupt interfaces are modelled with multiple interrupt
controller nodes or irq domains. It looks to me like it just uses a
single interrupt controller/domain with percpu irq. Does that match
your understanding?

Rich