09:35 <geertu> ukleinek: Bummer, torvalds is preempting your patch statistics ;-)

09:52 <geertu> ukleinek: commit e70140ba0d2b1a30 ("Get rid of 'remove_new' relic from platform driver struct")

09:58 <ukleinek> oh, would have been nice if he told me.

09:59 <geertu> ukleinek: Well, I guess you would have found soon during the customary rebase

09:59 <geertu> found out

10:00 <geertu> ukleinek: oops

10:02 <ukleinek> ah, for reasons I decided not to talk about, the patch didn't make it out. Good.

10:08 <mmind00> vkoul: I may just be blind for not finding this, but can you tell me what the concurrency expectation of the phy-layer is? i.e. multiple phy-consumers getting the same phy ... I have been looking for some -EBUSY, but haven't found one yet

14:08 <Forty-Bot> mmind00: afaik there are no checks for this in the phy layer

14:08 <Forty-Bot> (at least the last time I looked at it ~2 years ago)

14:09 <Forty-Bot> so if you want to enforce e.g. "one consumer per phy" you have to do it at the driver level

14:10 <Forty-Bot> which isn't too bad; just stick a "used" variable in your phy and check it in phy_init or whatever

14:12 <mmind00> Forty-Bot: yep ... the question was more aimed at what is the expectation in the phy-layer ... like a phy being used by two separate controllers "at the same time" an expected use-case ... in my mind allowing that would mean chaos, so some usage-checking would be adviced, as you wrote

14:14 <Forty-Bot> so I think there are two use cases

14:14 <Forty-Bot> first, you have a phy that is not supposed to be reused

14:14 <Forty-Bot> in which case, supplying it to two different devices is a firmware bug

14:14 <Forty-Bot> but it's not exactly going to cause further problems

14:15 <Forty-Bot> probably one or both of the devices won't work, but if there's one phy then there's one physical serdes too, so of course this happens

14:16 <Forty-Bot> the other case is that you want to allow two devices to use the same phy at runtime (e.g. say you have a USB3 port and you also want to do displayport)

14:17 <Forty-Bot> so they need to coordinate by releasing the phy (phy_power_down/phy_exit) once they are done

14:17 <Forty-Bot> and this is possible with the current framework, but wouldn't be if exclusive access was enforced at the phy layer

14:20 <mmind00> Forty-Bot: yep ... I get that ... just wanting to make sure I don't suggest wrong stuff in https://lore.kernel.org/linux-rockchip/2342f342-672c-447e-90d8-674b748af6a4@rock-chips.com/T/#mcfc7313444f5d3a0f71421aa9377eeb0dd11dcf0

14:20 <mmind00> i.e. an hdmi+edp phy connected to an dw-hdmi controller and an analogix-dp controller ... it can of course only do one at a time

14:20 <mmind00> right now we're debating the pros and cons of phy_set_mode vs. getting the phy via an phandle argument (which seems to be a somewhat newish idea - at least to me)

14:21 <Forty-Bot> I think phy_set_mode is the Way to Go

14:22 <Forty-Bot> doing things in the phandle is more brittle, since it introduces opportunities for firmware bugs

14:22 <Forty-Bot> e.g. you hook up the phy to a different device but forget to change the mode in the phandle

14:22 <Forty-Bot> and the consuming device should definitely know what phy mode it needs

14:23 <mmind00> recently I read suggestions going the opposite way ;-) ... like for my own DPHY/CPHY driver

14:24 <Forty-Bot> link?

14:25 <mmind00> Forty-Bot: https://lore.kernel.org/lkml/20241113221018.62150-2-heiko@sntech.de/T/#m7af4167b696f56dc8e52e50571b65a31358c5185

14:26 <Forty-Bot> eh, that's just a problem of expectations

14:26 <Forty-Bot> I think the reason for this is that a lot of phys don't support changing the mode at runtime

14:26 <mmind00> where the argument makes sense too ... like you "should" know what type of phy you need when you write the DT ... and of course those phy-links are always on the soc-level itself

14:26 <Forty-Bot> especially some of the older ones

14:26 <mmind00> so the board-dt-writer won't ever come near that

14:26 <Forty-Bot> no, don't make the DT authors think ;)

14:27 <Forty-Bot> it's much nicer to have an interface you can't screw up

14:28 <Forty-Bot> anyway, if you support phy_set_mode, then it's much better to just skip the phy modes IMO

14:28 <Forty-Bot> if you decide you want it later you can always add it

14:28 <Forty-Bot> but you can never remove anything from devicetree