12:20 <dvergatal> mmind00: btw. i have in drivers/usb/typec/mux only TYPEC_MUX_PI3USB30532

12:21 <mmind00> dvergatal: I also see intel_pmc_mux.c

12:21 <dvergatal> dvergatal: in 5.4.18 there isn't

12:22 <mmind00> dvergatal: you shouldn't base new development on old kernels

12:22 <dvergatal> mmind00: as i said cypress support wpa3 for stupid broadcom chip up to this kernel version

12:23 <mmind00> dvergatal: i.e. develop against mainline and then if needed cherry-pick commits back to your stable-kernel

12:23 <dvergatal> ok

12:23 <dvergatal> dvergatal: so i should do it on newest mainline?

12:23 <mmind00> dvergatal: yep

12:25 <dvergatal> mmind00: btw. this feature which i would implement for connection between phy_rockchip_typec and dwc3 with the usage of type-c framework should be similar to the code in the muxes?

12:27 <dvergatal> mmind00: because as you said it earlier the code in the muxes should be similar for the phy_rockchip_typec

12:32 <mmind00> dvergatal: essentially yes ... when you look at the muxes you'll see how they configure direction and/or modes ... which is similar to what the typec phy already does ... what you should get out of the muxes is how they interface with the rest of the framework

12:35 <dvergatal> mmind00: ok and add the interface section to phy_rockchip_typec driver

12:35 <dvergatal> ?

12:44 <mmind00> dvergatal: essentially yes ... with the caveat that the "extcon"-variant should also stay working ... aka: if extcon exits, behave like now ... otherwise use typec-framework

12:44 <dvergatal> no extcon is not working at all

12:48 <dvergatal> mmind00: "extcon" variant is the vendor one or am i mistaking something?

12:49 <mmind00> dvergatal: 50% yes ... but also the one, devices with a cros-ec component use right now

12:50 <mmind00> dvergatal: as I explained yesterday, ChromeOS devices already get a bit more functionality right now ... and we need to keep new development backwards compatible

12:50 <dvergatal> ahahahaha

12:50 <dvergatal> sory

12:50 <dvergatal> should be ahaaaa

12:50 <dvergatal> ok now i all get it

12:52 <dvergatal> mmind00: so for example gru uses cros-ec instead of fusb302 and it has already this extcon connection

12:53 <dvergatal> mmind00: actually gru like boards should also move to this type-c connection instead of using extcon?

13:04 <mmind00> dvergatal: in theory yes ... but there is a caveat with DT ... i.e. for the type-c integration you'll need additional stuff in devicetree ... and newer kernels _should always_ work even with older devicetrees ... so you'll need the backwards compatiblity in any case

13:07 <dvergatal> mmind00: ok, if i'm going to clone kernel sources to make changes should i do it on github or kernel.org?

13:08 <mmind00> dvergatal: if you mean to source from, both work ... if you mean to store them, then github or gitlab, as kernel.org probably won't give you an account so easily

13:08 <dvergatal> mmind00: i am asking because i don't know if on github is the same source code as on kernel.org

13:11 <mmind00> dvergatal: https://github.com/torvalds/linux/ is a mirror ... but you can of course also just clone from kernel.org ... it doesn't really matter

13:17 <dvergatal> mmind00: ok thx i will fork it and will try to do some work in the free time, thx to you i know now what is needed to be done, if i will have further questions may i ask you than?

13:17 <mmind00> dvergatal: sure :-)

13:18 <dvergatal> mmind00: thx :-]