> -----Original Message----- > From: Russell King - ARM Linux [mailto:linux@xxxxxxxxxxxxxxxx] > Sent: Monday, January 06, 2014 6:56 PM > To: Hiremath, Vaibhav > Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-omap@xxxxxxxxxxxxxxx; Tony > Lindgren > Subject: Re: [RFC] drivers: irq-chip: Enable SGI's for Secure-to-NonSecure > communication use-cases > > On Mon, Jan 06, 2014 at 05:09:04AM +0000, Hiremath, Vaibhav wrote: > > The idea behind this RFC (or rather query) is, to get feedback or > > comments on the use-case of using SGI for secure-to-nonsecure > > communication on non-SMP architecture or SMP architecture with > uniprocessor. > > I understand that, lot of things I need to take care from SMP architecture > perspective. > > Based on the feedback I can spend more time to make below changes more > > generic to handle both uniprocessor and multi-processor architectures > including more validation. > > So it seems that your intention is to use the existing infrastructure for this by > directing SGIs through the normal IRQ processing. > > To that idea, I say no way. > You have any other alternative? > I also think you need to think more about the changes you're making in your > patch - several of them seem to have just been a case of s/32/0/ without any > further thought whether that change is actually appropriate. > Really, I'd suggest reading the GIC documentation, especially the bits about the > first register being banked between each CPU. > > So changing the setup in the distributor initialisation is only going to hit the > register on the CPU it's running on... I completely agree with you and I am willing to spend time to have more generic implementation, which will also handle banked registers. The changes were just to prove the secure-to-nonsecure communication concept which I wanted to introduce here as part of this RFC. I will quote my statement again "I understand that, lot of things I need to take care from SMP architecture perspective. Based on the feedback I can spend more time to make below changes more generic to handle both uniprocessor and multi-processor architectures including more validation." Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
