00:52 <Adrian[m]> krzk: hi, has there been any progress on sharing enable gpios? i heard you mention in your talk from last year that modifications to drivers to use the reset framework for enable gpios would not be accepted upstream, is there a solution to that by now or still not?

00:57 <Adrian[m]> some context: i have a device with nxp i2c nfc module that shares its enable gpio with the reset gpio of the nxp amplifier, so from my current understanding this still isn't possible

06:49 <MainudeenSumro[m]> Hi

06:49 <MainudeenSumro[m]> Anyone online

06:59 <krzk> bamse: I tried next like 2 weeks ago and it was crashing somewhere, but many patches are not merged, so I blamed that. But indeed from that point of view fix for RC is not that much of a fix.

07:00 <krzk> Adrian[m]: I did not hear anything new about it but I also did not follow the topic. Your should rather check with brgl.

07:00 <krzk> So your case still won't be easy

07:21 <MainudeenSumro[m]> Has anyone got modem working on sm8550?

07:21 <MainudeenSumro[m]> 8 gen 2?

07:42 <brgl> Adrian[m] I'm not aware of any "sharing enable GPIOs" discussion going on, can you point me in the right direction?

07:42 <brgl> what is your the name of your component and is there a datasheet available?

07:43 <brgl> ah these are two separate ICs that use the same enable-gpio?

07:45 <Adrian[m]> yep, the enable-gpio of one IC is the reset gpio of the other one

07:46 <Adrian[m]> I was watching Krzysztof's talk yesterday (https://youtube.com/watch?v=Yo8lWYm7k1U), and there he mentions that the reset framework isn't going to be accepted upstream as a mechanism for sharing enable GPIOs

07:51 <Adrian[m]> timestamp is around 15:00

08:54 <konradybcio> brgl Adrian cee544a40e44 ("reset: gpio: Add GPIO-based reset controller")

15:30 <bamse> krzk: no concerns about "ignoring" -rc for the platforms which aren't complete enough to be used anyways...but would be nice if linux-next would be somewhat functional, to facilitate the work on the missing pieces

15:44 <krzk> bamse: I would be happy as well, because you wouldn't like to see how my working branch (one which has sm8750 working) looks like and how it is annoying to develop anything :/

15:50 <bamse> krzk: dependencies of your own, or code from qcom engineers that you depend on?

16:47 <krzk> bamse: the second case, so code from qcom - probably now sent to the lists entirely, but earlier not necessarily

16:51 <bamse> krzk: thanks for confirming my understanding, i will add this to a discussion we have on that subject...

17:43 <brgl> Adrian[m] can you drop me an email with more details on this at bartosz.golaszewski@linaro.org? What platform, what ICs, which drivers etc?