| Message ID | 20190218143629.28392-1-peter.ujfalusi@ti.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ARM: dts: am335x-evm/evmsk: Fix PHY mode for ethernet | expand |
* Peter Ujfalusi <peter.ujfalusi@ti.com> [190218 14:36]: > Hi, > > cd28d1d6e52e: ("net: phy: at803x: Disable phy delay for RGMII mode") broke the > ethernet networking on evmsk (and most likely on the evm as well): > https://patchwork.ozlabs.org/patch/1028527/ > > v1 patch to fix the situation: > https://patchwork.ozlabs.org/patch/1040617/ > > It turned out that the at803x driver is actually broken and need to be fixed > along with the DT data. > > The following series is proposed to fix the driver: > https://patchwork.ozlabs.org/project/netdev/list/?series=92611 > > but the PHT mode needs to be switched to rgmii-id from rgmii-txid: > The rx delay is enabled by default and the driver never disabled it so when > asking rgmii-txid it actually got rgmii-id. > > The patch can be backported to stable, I have tested that it is not causing > regression with the old, broken driver. Can the dts changes be merged before the driver changes or does it cause the phy to stop working? Regards, Tony
On 18/02/2019 16.44, Tony Lindgren wrote: > * Peter Ujfalusi <peter.ujfalusi@ti.com> [190218 14:36]: >> Hi, >> >> cd28d1d6e52e: ("net: phy: at803x: Disable phy delay for RGMII mode") broke the >> ethernet networking on evmsk (and most likely on the evm as well): >> https://patchwork.ozlabs.org/patch/1028527/ >> >> v1 patch to fix the situation: >> https://patchwork.ozlabs.org/patch/1040617/ >> >> It turned out that the at803x driver is actually broken and need to be fixed >> along with the DT data. >> >> The following series is proposed to fix the driver: >> https://patchwork.ozlabs.org/project/netdev/list/?series=92611 >> >> but the PHT mode needs to be switched to rgmii-id from rgmii-txid: >> The rx delay is enabled by default and the driver never disabled it so when >> asking rgmii-txid it actually got rgmii-id. >> >> The patch can be backported to stable, I have tested that it is not causing >> regression with the old, broken driver. > > Can the dts changes be merged before the driver changes or > does it cause the phy to stop working? The phy is not working atm, but this change will not cause regression even if it is merged first. > > Regards, > > Tony > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
* Peter Ujfalusi <peter.ujfalusi@ti.com> [190218 16:22]: > > > On 18/02/2019 16.44, Tony Lindgren wrote: > > * Peter Ujfalusi <peter.ujfalusi@ti.com> [190218 14:36]: > >> Hi, > >> > >> cd28d1d6e52e: ("net: phy: at803x: Disable phy delay for RGMII mode") broke the > >> ethernet networking on evmsk (and most likely on the evm as well): > >> https://patchwork.ozlabs.org/patch/1028527/ > >> > >> v1 patch to fix the situation: > >> https://patchwork.ozlabs.org/patch/1040617/ > >> > >> It turned out that the at803x driver is actually broken and need to be fixed > >> along with the DT data. > >> > >> The following series is proposed to fix the driver: > >> https://patchwork.ozlabs.org/project/netdev/list/?series=92611 > >> > >> but the PHT mode needs to be switched to rgmii-id from rgmii-txid: > >> The rx delay is enabled by default and the driver never disabled it so when > >> asking rgmii-txid it actually got rgmii-id. > >> > >> The patch can be backported to stable, I have tested that it is not causing > >> regression with the old, broken driver. > > > > Can the dts changes be merged before the driver changes or > > does it cause the phy to stop working? > > The phy is not working atm, but this change will not cause regression > even if it is merged first. OK so sounds like these are OK to wait for v5.1 merge window then as the dts changes alone won't fix anything? Regards, Tony
Hi Tony, On 18/02/2019 18.26, Tony Lindgren wrote: > * Peter Ujfalusi <peter.ujfalusi@ti.com> [190218 16:22]: >> >> >> On 18/02/2019 16.44, Tony Lindgren wrote: >>> * Peter Ujfalusi <peter.ujfalusi@ti.com> [190218 14:36]: >>>> Hi, >>>> >>>> cd28d1d6e52e: ("net: phy: at803x: Disable phy delay for RGMII mode") broke the >>>> ethernet networking on evmsk (and most likely on the evm as well): >>>> https://patchwork.ozlabs.org/patch/1028527/ >>>> >>>> v1 patch to fix the situation: >>>> https://patchwork.ozlabs.org/patch/1040617/ >>>> >>>> It turned out that the at803x driver is actually broken and need to be fixed >>>> along with the DT data. >>>> >>>> The following series is proposed to fix the driver: >>>> https://patchwork.ozlabs.org/project/netdev/list/?series=92611 >>>> >>>> but the PHT mode needs to be switched to rgmii-id from rgmii-txid: >>>> The rx delay is enabled by default and the driver never disabled it so when >>>> asking rgmii-txid it actually got rgmii-id. >>>> >>>> The patch can be backported to stable, I have tested that it is not causing >>>> regression with the old, broken driver. >>> >>> Can the dts changes be merged before the driver changes or >>> does it cause the phy to stop working? >> >> The phy is not working atm, but this change will not cause regression >> even if it is merged first. > > OK so sounds like these are OK to wait for v5.1 merge window > then as the dts changes alone won't fix anything? I think it would be better to send these to 5.0 to avoid the regression siting in linux-next. The patches are actually doing to the correct thing (we need rgmii-id, not rmgii-txid for these boards). It was just a matter of luck that it worked with rgmii-txid as the driver was broken and did not disabled the rxid when it should have. Tested the patch on top of mainline (b5372fe5dc84235dbe04998efdede3c4daa866a9) was the topmost commit after the rc7 tag. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
* Peter Ujfalusi <peter.ujfalusi@ti.com> [190219 08:02]: > On 18/02/2019 18.26, Tony Lindgren wrote: > > OK so sounds like these are OK to wait for v5.1 merge window > > then as the dts changes alone won't fix anything? > > I think it would be better to send these to 5.0 to avoid the regression > siting in linux-next. > > The patches are actually doing to the correct thing (we need rgmii-id, > not rmgii-txid for these boards). > It was just a matter of luck that it worked with rgmii-txid as the > driver was broken and did not disabled the rxid when it should have. OK applying into omap-for-v5.0/fixes-v2. I'll send a pull request on Thursday most likely then, let's see if it makes it for v5.0. Regards, Tony
Hi Tony, On 19/02/2019 18.52, Tony Lindgren wrote: > * Peter Ujfalusi <peter.ujfalusi@ti.com> [190219 08:02]: >> On 18/02/2019 18.26, Tony Lindgren wrote: >>> OK so sounds like these are OK to wait for v5.1 merge window >>> then as the dts changes alone won't fix anything? >> >> I think it would be better to send these to 5.0 to avoid the regression >> siting in linux-next. >> >> The patches are actually doing to the correct thing (we need rgmii-id, >> not rmgii-txid for these boards). >> It was just a matter of luck that it worked with rgmii-txid as the >> driver was broken and did not disabled the rxid when it should have. > > OK applying into omap-for-v5.0/fixes-v2. I'll send a pull > request on Thursday most likely then, let's see if it makes > it for v5.0. Thank you! - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Hi, cd28d1d6e52e: ("net: phy: at803x: Disable phy delay for RGMII mode") broke the ethernet networking on evmsk (and most likely on the evm as well): https://patchwork.ozlabs.org/patch/1028527/ v1 patch to fix the situation: https://patchwork.ozlabs.org/patch/1040617/ It turned out that the at803x driver is actually broken and need to be fixed along with the DT data. The following series is proposed to fix the driver: https://patchwork.ozlabs.org/project/netdev/list/?series=92611 but the PHT mode needs to be switched to rgmii-id from rgmii-txid: The rx delay is enabled by default and the driver never disabled it so when asking rgmii-txid it actually got rgmii-id. The patch can be backported to stable, I have tested that it is not causing regression with the old, broken driver. Regards, Peter --- Peter Ujfalusi (2): ARM: dts: am335x-evmsk: Fix PHY mode for ethernet ARM: dts: am335x-evm: Fix PHY mode for ethernet arch/arm/boot/dts/am335x-evm.dts | 2 +- arch/arm/boot/dts/am335x-evmsk.dts | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)