Hi Marek, > From: Marek Behún, Sent: Tuesday, January 31, 2023 1:59 AM > > On Mon, 30 Jan 2023 16:48:02 +0000 > "Russell King (Oracle)" <linux@xxxxxxxxxxxxxxx> wrote: > > > On Mon, Jan 30, 2023 at 05:30:48PM +0100, Marek Behún wrote: > > > But rswitch already uses phylink, so should Yoshihiro convert it whole > > > back to phylib? (I am not sure how much phylink API is used, maybe it > > > can stay that way and the new phylib function as proposed in Yoshihiro's > > > previous proposal can just be added.) > > > > In terms of "how much phylink API is used"... well, all the phylink > > ops functions are currently entirely empty. So, phylink in this case > > is just being nothing more than a shim between the driver and the > > corresponding phylib functions. > > > > Yoshihiro, sorry for this. No warries! > If not for my complaints, your proposal could > already be merged (maybe). Anyway, I think the best solution would be > to implement phylink properly, even for cases that are not relevant for > your board*, but this would take a non-trivial amount of time, so > I will understand if you want to stick with phylib. > > * Altough you don't use fixed-link or SFP on your board, I think it > should be possible to test it somehow if you implemented it... > For example, I have tested fixed-link between SOC and switch SerDes > by configuring it in device-tree on both sides. Thank you very much for your comments! For now I'm intending to use phylib instead, because I'm thinking that I cannot implement the in-band mode of phylink on my board. # As you mentioned, fixed-link can be implemented, I guess. Best regards, Yoshihiro Shimoda > Marek
