linux-kernel - Re: [PATCH v6 2/2] clocksource: add J-Core timer/clocksource driver

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: <alpine.DEB.2.20.1608250947120.5714@nanos>
Date:   Thu, 25 Aug 2016 10:07:08 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Rich Felker <dalias@...c.org>
cc:     Daniel Lezcano <daniel.lezcano@...aro.org>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-sh@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Marc Zyngier <Marc.Zyngier@....com>
Subject: Re: [PATCH v6 2/2] clocksource: add J-Core timer/clocksource
 driver

Rich,

On Wed, 24 Aug 2016, Rich Felker wrote:
> I don't think that's a correct characterization. Rather the percpu
> infrastructure just means something completely different from what you
> would expect it to mean. It has nothing to do with the hardware but
> rather with kernel-internal choice of whether to do percpu devid
> mapping inside the irq infrastructure, and the choice at the
> irq-requester side of whether to do this is required to match the
> irqchip driver's choice. I explained this better in another email
> which I could dig up if necessary, but the essence is that
> request_percpu_irq is a misnamed and unusably broken API.

I slowly get tired about your permanent ranting about misnamed, misdesigned
and unusable code in the kernel.

The percpu infrastructure was designed explicitely to reflect the hardware and
is not a random kernel internal choice. It's there to handle the situation
where a single interrupt number is actually available on each CPU.

ARM has a very clear distinction between PPI (per processor interrutps) and
SPI (shared peripheral interrupts). So we end up with the following interrupt
space:

IRQ	CPU0	CPU1
0	PPI	PPI
...	...	...
15	PPI	PPI

16	SPI	SPI
...
N	SPI	SPI

The fundamental difference between PPI and SPI is that PPIs originate from the
CPU itself or are injected as IPIs targeted to a particular CPU. Each CPU has
its own interrupt controller to mask/ack/... PPIs.

The SPIs have a shared interrupt controller and therefor are globally shared
between all cpus.

The percpu infrastructure reflects exaclty this scenario and allows us to
handle PPIs with the same irq number (which makes a lot of sense) seperately
on each CPU.

So how does this not reflect the hardware?

If your particular hardware has the old scheme of seperate interrupt numbers
for per cpu interrupts, then you can simply use the normal interrupt scheme
and request a seperate interrupt per cpu.

Just because something does not fit your needs and does not match your SH
blinkered worldview does not make it misnamed, misdesigned and unusable.

If you want to work with this community you really should start to talk
constructive with us and stop this unjustified ranting attitude.

Thanks,

	tglx