Re: Link modes representation in phylib

2018-06-29 Thread Maxime Chevallier
On Fri, 29 Jun 2018 17:34:41 +0200 Andrew Lunn wrote: >> Wow indeed that will help a lot. Just so that we're in sync, do you >> plan to add those helpers, or should I take this branch as a base for >> the conversion and go on ? > >I'm still working on it. I can probably push again in the next f

Re: Link modes representation in phylib

2018-06-29 Thread Andrew Lunn
> Wow indeed that will help a lot. Just so that we're in sync, do you > plan to add those helpers, or should I take this branch as a base for > the conversion and go on ? I'm still working on it. I can probably push again in the next few minutes. But they won't be compile tested, i.e. broken... I

Re: Link modes representation in phylib

2018-06-29 Thread Maxime Chevallier
Hello Andrew, On Fri, 29 Jun 2018 15:43:43 +0200 Andrew Lunn wrote: >> Thanks for the suggestion. I see how this can be done with >> phydrv->supported and phydev->lp_advertising, however I'm not sure how >> we should deal with the fact that ethernet drivers directly access >> fields such as "adv

Re: Link modes representation in phylib

2018-06-29 Thread Andrew Lunn
> Thanks for the suggestion. I see how this can be done with > phydrv->supported and phydev->lp_advertising, however I'm not sure how > we should deal with the fact that ethernet drivers directly access > fields such as "advertising" or "supported". Hi Maxime I started cleaning up some of the MAC

Re: Link modes representation in phylib

2018-06-29 Thread Maxime Chevallier
Hello Andrew, On Tue, 19 Jun 2018 17:21:55 +0200 Andrew Lunn wrote: >> What I propose is that we add 3 link_mode fields in phy_device, and keep >> the legacy fields for now. It would be up to the driver to fill the new >> "supported" field in config_init, kind of like what's done in the >> marve

Re: Link modes representation in phylib

2018-06-19 Thread Andrew Lunn
> What I propose is that we add 3 link_mode fields in phy_device, and keep > the legacy fields for now. It would be up to the driver to fill the new > "supported" field in config_init, kind of like what's done in the > marvell10g driver. Hi Maxime You can do this conversion in the core. If featur

Re: Link modes representation in phylib

2018-06-19 Thread Maxime Chevallier
Hello Andrew, Thanks for your feedback ! >> I'm currently working on adding support for 2.5GBaseT on some Marvell >> PHYs (the marvell10g family, including the 88X3310). >> >> However, phylib doesn't quite support these modes yet. Its stores the >> different supported and advertised modes in u32

Re: Link modes representation in phylib

2018-06-18 Thread Andrew Lunn
On Mon, Jun 18, 2018 at 05:02:24PM +0200, Maxime Chevallier wrote: > Hello everyone, > > I'm currently working on adding support for 2.5GBaseT on some Marvell > PHYs (the marvell10g family, including the 88X3310). > > However, phylib doesn't quite support these modes yet. Its stores the > differe

Link modes representation in phylib

2018-06-18 Thread Maxime Chevallier
Hello everyone, I'm currently working on adding support for 2.5GBaseT on some Marvell PHYs (the marvell10g family, including the 88X3310). However, phylib doesn't quite support these modes yet. Its stores the different supported and advertised modes in u32 fields, which can't contain the relevant