On Thu 12 Mar 12:55 PDT 2015, Lina Iyer wrote: > On Thu, Mar 12 2015 at 13:43 -0600, Andy Gross wrote: > >On Thu, Mar 12, 2015 at 01:31:50PM -0600, Lina Iyer wrote: > >> On Fri, Feb 27 2015 at 15:30 -0700, Bjorn Andersson wrote: [..] > >> Also, talking to Jeff it seems like that out of the 32 locks defined > >> only 8 is accessible from Linux. So its unnecessary and probably > >> incorrect to assume that there are 32 locks available. > > > >Out of curiosity, this is a TZ thing? If so, we'd expect issues if someone > >decides to utilize resources that, while technically are present, are unusable > >by that processor. This is not that much different from someone misconfiguring > >an EE on a DMA controller. > > > Per Jeff, the protection unit doesnt generally allow access to locks > 8 > and shouldnt be allowed and in some SoC's where they dont have the > protection, it might still be a bad idea. It would be safer to restrict to > 8, than allow all 32 and hope somebody doesnt do the wrong thing. > You have the same problem with all peripherals that are shared between the various subsystems; e.g. the BLSPs used by the sensor DSP shouldn't be touched by the Linux system. But what if Linux runs on the sensor DSP? The driver should support the hardware and the system configuration (DT) should make sure the valid resources are accessed. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
