<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Aug 10, 2017 3:12 AM, "Andrew Jeffery" <<a href="mailto:andrew@aj.id.au">andrew@aj.id.au</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On Thu, 2017-08-10 at 17:01 +0800, Yong Li wrote:<br>
> thanks for your quick response Andrew!<br>
<br>
</div>No worries!<br>
<div class="quoted-text"><br>
> i will read these info deeply. just a quick question, is it possible<br>
> to enable/disable the pass through dynamically after kernel boots?  how?<br>
<br>
</div>So there is the concept of runtime pinmuxing[1]: It's possible for a<br>
device to have several pinmux states that can be configured/selected<br>
from process context. </blockquote></div></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">On Quanta Q71L, the hardware strap is used to enable pass through so the power button works even if the BMC fails to boot. The BMC firmware is expected to disable the pass through once it is ready to take over. I believe I sent the patch upstream to allow pinmux to modify the strap register for this case. That is, pass through is disabled when the user exports a GPIO to userspace.</div></div>