On 01/13/2016 01:40 PM, Tony Lindgren wrote: > Anyways, considering what's been discussed, after the minimal RTC fix > we could also add code to allow the TWL driver optionally configure the > GPIO. This way the TWL driver could also check the GPIO state in case > some out-of-our-control mystery software goes tweak the msecure pin > state. I dont even know how that will work: If you are using MSECURE as it is intended to be, then you'd mux it to msecure, which means that GPIO read is just a waste of time - you dont even mux it to external world. Now, some SoCs like DRA7 has input lines always connected. even assuming this is for such a case: a) when you are running linux, you are already in nonsecure - it needs no read of MSECURE GPIO to figure that out. b) when you are in secure world, Linux wont be running either. Reading from GPIO is just misguided in my opinion. firewalls are not reconfigured, and muxes are usually done a single time. Or the RTC driver could just check that the bits really change > after= writing them. Then we would at least know things are not working > right for the TWL related RTC drivers. that is reasonable to check, but just a overhead - anyways, just isolated to palmas-rtc.. fail reason maynot always be issues with MSECURE mux.. it could be very well be 32k clk fail etc.. but yeah - that might give a hint that there is an issue.. -- Regards, Nishanth Menon -- 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
