Hi Bjorn, On Fri, Apr 26, 2024 at 4:44 PM Bjorn Andersson <quic_bjorande@xxxxxxxxxxx> wrote: > On Fri, Apr 26, 2024 at 03:08:06PM -0700, Brian Norris wrote: > > Apologies if I broke something here. > > False alarm on the breakage part, I got lost in the software layers. OK! Glad it's not causing a visible problem. > > But I can't tell based on subsequent conversation: are you observing a > > real problem, or is this a theoretical one that only exists if the > > gpiochip driver adds set_config() support? > > > > There is a problem that if a non-ipq4019 device where to be pinconf'ed > for open-drain, the outcome would be unexpected Well as observed elsewhere, that's not permitted in most MSM bindings ;) But still might be nice to remove the landmine. > and I have a concern > that someone one day would implement set_config(). > > So, I'd like to fix this, but my argumentation is at least wrong. Sure. I haven't surveyed the other pinconf types well, but how does this driver handle all that? Are all other types supported uniformly by all qcom pin blocks? It seems a little weird to be treating bit 0 as a NULL choice, but clearly it works for now, with only a single non-zero bit user. > > https://git.kernel.org/linus/99d19f5a48ee6fbc647935de458505e9308078e3 > > Perhaps we could convert that to yaml? Ha, sure, perhaps. I don't have time for that soon, but there's a chance such a patch could materialize in the future. > Thank you for taking a look, Brian. This was valuable input. I will > rework this to have a valid motivation - at least. You're welcome! Glad it's cleared up enough to help move forward. Regards, Brian