On Sat, 14 Nov 2020 at 01:40, Andrew Lunn wrote:
>
> > One question that still has not been answered is how many actual
> > platforms were fixed by backporting Realtek's follow up fix to
> > -stable. My suspicion is none. That by itself should be enough
> > justification to revert the backport of
> One question that still has not been answered is how many actual
> platforms were fixed by backporting Realtek's follow up fix to
> -stable. My suspicion is none. That by itself should be enough
> justification to revert the backport of that change.
I think i've already said that would be a goo
On Fri, 13 Nov 2020 at 23:43, Andrew Lunn wrote:
>
> Hi Arnd
>
> > Something of that sort. I also see a similar patch in KSZ9031
> > now, see 7dd8f0ba88fc ("arm: dts: imx6qdl-udoo: fix rgmii phy-mode
> > for ksz9031 phy")
> >
> > As this exact mismatch between rgmii and rgmii-id mode is apparently
Hi Arnd
> Something of that sort. I also see a similar patch in KSZ9031
> now, see 7dd8f0ba88fc ("arm: dts: imx6qdl-udoo: fix rgmii phy-mode
> for ksz9031 phy")
>
> As this exact mismatch between rgmii and rgmii-id mode is apparently
> a more widespread problem, the best workaround I can think of
On Fri, Nov 13, 2020 at 5:57 PM Andrew Lunn wrote:
>
> > > Hi Arnd
> > >
> > > This PHY driver bug hiding DT bug is always hard to handle. We have
> > > been though it once before with the Atheros PHY. All the buggy DT
> > > files were fixed in about one cycle.
> >
> > Do you have a link to the pr
> > Hi Arnd
> >
> > This PHY driver bug hiding DT bug is always hard to handle. We have
> > been though it once before with the Atheros PHY. All the buggy DT
> > files were fixed in about one cycle.
>
> Do you have a link to the problem for the Atheros PHY?
commit cd28d1d6e52e740130745429b3ff0af7
On Fri, Nov 13, 2020 at 3:45 PM Andrew Lunn wrote:
>
> > > Sadly, there is one board - Pine64 Plus - where HW settings are wrong and
> > > it
> > > actually needs SW override. Until this Realtek PHY driver fix was merged,
> > > it
> > > was unclear what magic value provided by Realtek to board m
> > Sadly, there is one board - Pine64 Plus - where HW settings are wrong and it
> > actually needs SW override. Until this Realtek PHY driver fix was merged, it
> > was unclear what magic value provided by Realtek to board manufacturer does.
> >
> > Reference:
> > https://lore.kernel.org/netdev/20
On Thu, Nov 5, 2020 at 6:28 PM Jernej Škrabec wrote:
> Dne četrtek, 29. oktober 2020 ob 15:46:44 CET je Ilias Apalodimas napisal(a):
> > On Thu, Oct 29, 2020 at 03:39:34PM +0100, Andrew Lunn wrote:
> > > > What about reverting the realtek PHY commit from stable?
> > > > As Ard said it doesn't real
Hi!
Dne četrtek, 29. oktober 2020 ob 15:46:44 CET je Ilias Apalodimas napisal(a):
> On Thu, Oct 29, 2020 at 03:39:34PM +0100, Andrew Lunn wrote:
> > > What about reverting the realtek PHY commit from stable?
> > > As Ard said it doesn't really fix anything (usage wise) and causes a
bunch of
> > >
> IIRC there is no public documentation for this PHY, right? So most
> people that are affected by this are not actually able to implement
> this workaround, even if they wanted to.
The information you need is in the mailing list, where a realtek
person describes what the bits do.
Andrew
On Thu, Oct 29, 2020 at 03:39:34PM +0100, Andrew Lunn wrote:
> > What about reverting the realtek PHY commit from stable?
> > As Ard said it doesn't really fix anything (usage wise) and causes a bunch
> > of
> > problems.
> >
> > If I understand correctly we have 3 options:
> > 1. 'Hack' the dri
On Thu, 29 Oct 2020 at 15:39, Andrew Lunn wrote:
>
> > What about reverting the realtek PHY commit from stable?
> > As Ard said it doesn't really fix anything (usage wise) and causes a bunch
> > of
> > problems.
> >
> > If I understand correctly we have 3 options:
> > 1. 'Hack' the drivers in st
> What about reverting the realtek PHY commit from stable?
> As Ard said it doesn't really fix anything (usage wise) and causes a bunch of
> problems.
>
> If I understand correctly we have 3 options:
> 1. 'Hack' the drivers in stable to fix it (and most of those hacks will take
>a long time
Hi Andrew
On Sun, Oct 25, 2020 at 03:42:58PM +0100, Andrew Lunn wrote:
> On Sun, Oct 25, 2020 at 03:34:06PM +0100, Ard Biesheuvel wrote:
> > On Sun, 25 Oct 2020 at 15:29, Andrew Lunn wrote:
> > >
> > > On Sun, Oct 25, 2020 at 03:16:36PM +0100, Ard Biesheuvel wrote:
> > > > On Sun, 18 Oct 2020 at
On Sun, Oct 25, 2020 at 03:34:06PM +0100, Ard Biesheuvel wrote:
> On Sun, 25 Oct 2020 at 15:29, Andrew Lunn wrote:
> >
> > On Sun, Oct 25, 2020 at 03:16:36PM +0100, Ard Biesheuvel wrote:
> > > On Sun, 18 Oct 2020 at 17:45, Andrew Lunn wrote:
> > > >
> > > > > However, that leaves the question why
On Sun, 25 Oct 2020 at 15:29, Andrew Lunn wrote:
>
> On Sun, Oct 25, 2020 at 03:16:36PM +0100, Ard Biesheuvel wrote:
> > On Sun, 18 Oct 2020 at 17:45, Andrew Lunn wrote:
> > >
> > > > However, that leaves the question why bbc4d71d63549bcd was backported,
> > > > although I understand why the disc
On Sun, Oct 25, 2020 at 03:16:36PM +0100, Ard Biesheuvel wrote:
> On Sun, 18 Oct 2020 at 17:45, Andrew Lunn wrote:
> >
> > > However, that leaves the question why bbc4d71d63549bcd was backported,
> > > although I understand why the discussion is a bit trickier there. But
> > > if it did not fix a
On Sun, 18 Oct 2020 at 17:45, Andrew Lunn wrote:
>
> > However, that leaves the question why bbc4d71d63549bcd was backported,
> > although I understand why the discussion is a bit trickier there. But
> > if it did not fix a regression, only broken code that never worked in
> > the first place, I a
> However, that leaves the question why bbc4d71d63549bcd was backported,
> although I understand why the discussion is a bit trickier there. But
> if it did not fix a regression, only broken code that never worked in
> the first place, I am not convinced it belongs in -stable.
Please ask Serge Sem
> > Thanks for reporting back on that. It probably needs to be something
> > we always recommend for ACPI systems, either use "", or preferably no
> > phy-mode at all, and let the driver default to NA. ACPI and networking
> > is at a very early stage at the moment, since UEFA says nothing about
> >
On Sun, 18 Oct 2020 00:19:25 +0200
Ard Biesheuvel wrote:
> (cc'ing some folks who may care about functional networking on SynQuacer)
>
> On Sat, 17 Oct 2020 at 21:49, Andrew Lunn wrote:
> >
> > > So we can fix this firmware by just setting phy-mode to the empty
> > > string, right?
> >
> > I've
On Sun, 18 Oct 2020 at 12:35, Ard Biesheuvel wrote:
>
> On Sun, 18 Oct 2020 at 01:02, Andrew Lunn wrote:
> >
> > On Sun, Oct 18, 2020 at 12:19:25AM +0200, Ard Biesheuvel wrote:
> > > (cc'ing some folks who may care about functional networking on SynQuacer)
> > >
> > > On Sat, 17 Oct 2020 at 21:49
On Sun, 18 Oct 2020 at 01:02, Andrew Lunn wrote:
>
> On Sun, Oct 18, 2020 at 12:19:25AM +0200, Ard Biesheuvel wrote:
> > (cc'ing some folks who may care about functional networking on SynQuacer)
> >
> > On Sat, 17 Oct 2020 at 21:49, Andrew Lunn wrote:
> > >
> > > > So we can fix this firmware by
On Sun, Oct 18, 2020 at 12:19:25AM +0200, Ard Biesheuvel wrote:
> (cc'ing some folks who may care about functional networking on SynQuacer)
>
> On Sat, 17 Oct 2020 at 21:49, Andrew Lunn wrote:
> >
> > > So we can fix this firmware by just setting phy-mode to the empty
> > > string, right?
> >
> >
(cc'ing some folks who may care about functional networking on SynQuacer)
On Sat, 17 Oct 2020 at 21:49, Andrew Lunn wrote:
>
> > So we can fix this firmware by just setting phy-mode to the empty
> > string, right?
>
> I've never actually tried it, but i think so. There are no DT files
> actually
> So we can fix this firmware by just setting phy-mode to the empty
> string, right?
I've never actually tried it, but i think so. There are no DT files
actually doing that, so you really do need to test it and see. And
there might be some differences between device_get_phy_mode() and
of_get_phy_m
On Sat, 17 Oct 2020 at 20:27, Andrew Lunn wrote:
>
> On Sat, Oct 17, 2020 at 08:11:24PM +0200, Ard Biesheuvel wrote:
> > On Sat, 17 Oct 2020 at 20:04, Andrew Lunn wrote:
> > >
> > > > I have tried this, and it seems to fix the issue. I will send out a
> > > > patch against the netsec driver.
> >
On Sat, Oct 17, 2020 at 08:11:24PM +0200, Ard Biesheuvel wrote:
> On Sat, 17 Oct 2020 at 20:04, Andrew Lunn wrote:
> >
> > > I have tried this, and it seems to fix the issue. I will send out a
> > > patch against the netsec driver.
> >
> > Please also fix the firmware so it does not pass rgmii.
>
On Sat, 17 Oct 2020 at 20:11, Ard Biesheuvel wrote:
>
> On Sat, 17 Oct 2020 at 20:04, Andrew Lunn wrote:
> >
> > > I have tried this, and it seems to fix the issue. I will send out a
> > > patch against the netsec driver.
> >
> > Please also fix the firmware so it does not pass rgmii.
> >
> > If
On Sat, 17 Oct 2020 at 20:04, Andrew Lunn wrote:
>
> > I have tried this, and it seems to fix the issue. I will send out a
> > patch against the netsec driver.
>
> Please also fix the firmware so it does not pass rgmii.
>
> If there are pure DT systems, which do require phy-mode to be used, we
> w
> I have tried this, and it seems to fix the issue. I will send out a
> patch against the netsec driver.
Please also fix the firmware so it does not pass rgmii.
If there are pure DT systems, which do require phy-mode to be used, we
will need to revert your proposed change in order to make the MAC
> Would EDK2 take care of the RGMII Rx/Tx delays even when configured to
> use a DT instead of ACPI?
But what about those users using u-boot and DT, not EDK2?
Andrew
Hi Ard,
[...]
> > > > You can also use '' as the phy-mode, which results in
> > > > PHY_INTERFACE_MODE_NA, which effectively means, don't touch the PHY
> > > > mode, something else has already set it up. This might actually be the
> > > > correct way to go for ACPI. In the DT world, we tend to ass
On Sat, 17 Oct 2020 at 18:14, Ilias Apalodimas
wrote:
>
> Hi Ard,
>
> On Sat, Oct 17, 2020 at 05:18:16PM +0200, Ard Biesheuvel wrote:
> > On Sat, 17 Oct 2020 at 17:11, Andrew Lunn wrote:
> > >
> > > On Sat, Oct 17, 2020 at 04:46:23PM +0200, Ard Biesheuvel wrote:
> > > > On Sat, 17 Oct 2020 at 16:
Hi Ard,
On Sat, Oct 17, 2020 at 05:18:16PM +0200, Ard Biesheuvel wrote:
> On Sat, 17 Oct 2020 at 17:11, Andrew Lunn wrote:
> >
> > On Sat, Oct 17, 2020 at 04:46:23PM +0200, Ard Biesheuvel wrote:
> > > On Sat, 17 Oct 2020 at 16:44, Andrew Lunn wrote:
> > > >
> > > > On Sat, Oct 17, 2020 at 04:20
On Sat, 17 Oct 2020 at 17:11, Andrew Lunn wrote:
>
> On Sat, Oct 17, 2020 at 04:46:23PM +0200, Ard Biesheuvel wrote:
> > On Sat, 17 Oct 2020 at 16:44, Andrew Lunn wrote:
> > >
> > > On Sat, Oct 17, 2020 at 04:20:36PM +0200, Ard Biesheuvel wrote:
> > > > Hello all,
> > > >
> > > > I just upgraded
On Sat, Oct 17, 2020 at 04:46:23PM +0200, Ard Biesheuvel wrote:
> On Sat, 17 Oct 2020 at 16:44, Andrew Lunn wrote:
> >
> > On Sat, Oct 17, 2020 at 04:20:36PM +0200, Ard Biesheuvel wrote:
> > > Hello all,
> > >
> > > I just upgraded my arm64 SynQuacer box to 5.8.16 and lost all network
> > > connec
On Sat, 17 Oct 2020 at 16:44, Andrew Lunn wrote:
>
> On Sat, Oct 17, 2020 at 04:20:36PM +0200, Ard Biesheuvel wrote:
> > Hello all,
> >
> > I just upgraded my arm64 SynQuacer box to 5.8.16 and lost all network
> > connectivity.
>
> Hi Ard
>
> Please could you point me at the DT files.
>
> > This b
On Sat, Oct 17, 2020 at 04:20:36PM +0200, Ard Biesheuvel wrote:
> Hello all,
>
> I just upgraded my arm64 SynQuacer box to 5.8.16 and lost all network
> connectivity.
Hi Ard
Please could you point me at the DT files.
> This box has a on-SoC socionext 'netsec' network controller wired to
> a Rea
Hello all,
I just upgraded my arm64 SynQuacer box to 5.8.16 and lost all network
connectivity. This box has a on-SoC socionext 'netsec' network
controller wired to a Realtek 80211e PHY, and this was working without
problems until the following commit was merged
commit bbc4d71d63549bcd003a430de18a
41 matches
Mail list logo
