linux-kernel - Re: [PATCH v2 2/3] irqchip: irq-mips-gic: Provide function to map GIC user section

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:	Mon, 12 Oct 2015 12:16:19 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Marc Zyngier <marc.zyngier@....com>
cc:	Markos Chandras <markos.chandras@...tec.com>,
	linux-mips@...ux-mips.org, Alex Smith <alex.smith@...tec.com>,
	Jason Cooper <jason@...edaemon.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/3] irqchip: irq-mips-gic: Provide function to map
 GIC user section

On Mon, 12 Oct 2015, Marc Zyngier wrote:
> On 12/10/15 10:40, Markos Chandras wrote:
> > From: Alex Smith <alex.smith@...tec.com>
> > 
> > The GIC provides a "user-mode visible" section containing a mirror of
> > the counter registers which can be mapped into user memory. This will
> > be used by the VDSO time function implementations, so provide a
> > function to map it in.

<SNIP>

> 
> This looks much better than the previous version (though I cannot find
> the two other patches on LKML just yet).

Yes, it looks better. But I really have to ask the question why we are
trying to pack the world and somemore into an irq chip driver. We
already have the completely misplaced gic_read_count() there.

While I understand that all of this is in the GIC block at least
according to the documentation, technically it's different hardware
blocks. And logically its different as well.

So why not describe the various blocks (interrupt controller, timer,
shadow timer) as separate entities in the device tree and let each
subsystem look them up on their own. This cross subsystem hackery is
just horrible and does not buy anything except merge dependencies and
other avoidable hassle.

Thoughts?

Thanks,

	tglx

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/