On 20/12/2023 12:03, wsa@xxxxxxxxxx wrote: > >>>>> I personally would like to see it accepted but it seems there are >>>>> objections to this approach. I've yet to come up with anything better to >>>>> offer as an alternative. >>>> >>>> I see. Thanks for the heads up! >>> >>> I'm also inclined to have this merged. A real fix might take >>> time. >> >> NAK >> >> If you intend to merge it, then please carry: > > No worries. If this is "abusing" DT, then it is not going to be merged > by me. I am sorry for Chris, but sometimes simple problems create quite > some fuzz because Linux hardware abstractions has not foreseen certain > use cases. Or the APIs dealing with them didn't forsee that. We have > been there a lot of times :/ I need the same solution for WSA884x speaker, for which Mark rejected simple shared GPIO (even though it would work there), so I am trying to solve it. It's basically the same case. Now, I am waiting on answer from Sean Anderson whether he continued his work on reset-gpios controller from two years ago. Rob wanted handling reset-gpios by generic reset framework, which would solve these simple cases, here and mine, nicely. Best regards, Krzysztof
