On Thursday 14 January 2016 04:02 AM, Nishanth Menon wrote:
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..
IIRC without configuring the mux mode of gpio234 to msecure mode we were
unable to write to the rtc registers. Hence configured it one time at boot.
--
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
