linux-kernel - Re: [PATCH 03/12] irqchip: gic: define register_routable_domain

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 04 Dec 2014 14:50:41 +0100
From:	Stefan Agner <stefan@...er.ch>
To:	Marc Zyngier <marc.zyngier@....com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Mark Rutland <Mark.Rutland@....com>,
	devicetree@...r.kernel.org, Nishanth Menon <nm@...com>,
	Russell King <linux@....linux.org.uk>,
	Jason Cooper <jason@...edaemon.net>,
	Arnd Bergmann <arnd@...db.de>, ijc+devicetree@...lion.org.uk,
	daniel.lezcano@...aro.org, LKML <linux-kernel@...r.kernel.org>,
	Sricharan R <r.sricharan@...com>,
	Santosh Shilimkar <ssantosh@...nel.org>, robh+dt@...nel.org,
	Pawel Moll <Pawel.Moll@....com>, kernel@...gutronix.de,
	u.kleine-koenig@...gutronix.de, olof@...om.net,
	galak@...eaurora.org, shawn.guo@...aro.org,
	LAK <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

On 2014-12-04 14:42, Marc Zyngier wrote:
> On 04/12/14 13:35, Stefan Agner wrote:
>> On 2014-12-03 20:04, Marc Zyngier wrote:
>> <snip>
>>>> What do you mean by the shared state in the drawing above? Currently, I
>>>> check whether a interrupt is already used by the other core by reading
>>>> the register (do this configuration register reflect the "shared state"
>>>> in your drawing?).
>>>
>>> I think that is basically it. It should only be the register that
>>> decides on the actual routing. BTW, how do you arbitrate between
>>> concurrent accesses to this register? Or is only the A5 allowed to
>>> change it?
>>
>> No arbitration so far... The whole Vybrid on M4 stuff is quite a hack
>> right now. For instance also the concurrent access to the clock
>> registers is not handled. Currently, I start the M4 from a booted A5
>> Linux. To avoid half of the clocks get turned of by the M4 clock driver,
>> I need to specify clk_ignore_unused. Beside that, peripherals have to be
>> enabled/disabled in a non conflicting manor in the device trees...
>>
>> For the interrupt router in MSCM, it would be nice if the access could
>> be done an atomic way, which would avoid the use of a lock mechanism.
>> But I guess this is not possible, since peripherals only support
>> standard ldr/str...?
>>
>> There is the SEMA4 module which provides hardware semaphores. I'm aware
>> of the hardware spinlock drivers (drivers/hwspinlock/), I started to
>> implement such a driver for Vybrid. But so far a grep through the kernel
>> does not show one usage of that framework... I guess we could add dt
>> support for that, so we can assign the locks to individual drivers.
>>
>> I also plan to have a deeper look into remoteproc/rpmsg, not sure if
>> locking of shared peripherals is part (or planned to be part) of that
>> framework.
>>
>> For the clock stuff, the problem is more complex: I guess the would need
>> some kind of master/slave definition, where we disallow the change of
>> the shared clocks for the slave.
>>
>> If you are aware of patches/solutions, I'm happy to hear it...
> 
> I don't have a real solution for this, but I'd be tempted to generate
> the M4 DT based on the HW the A5 is not using, and only describe that.
> 
> Clearly not ideal, but it gives you the control you need (don't describe
> the HW you don't want to see touched)...
> 

Yeah, that avoids the need for any synchronization for those
peripherals.

However, for some hardware (e.g. clocks and that interrupt controller)
both sides need access... I guess to do it properly, I need to take care
of it...

--
Stefan

--
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/