From: Ard Biesheuvel <email@example.com> To: Andrew Lunn <firstname.lastname@example.org> Cc: Ilias Apalodimas <email@example.com>, "open list:BPF JIT for MIPS (32-BIT AND 64-BIT)" <firstname.lastname@example.org>, Willy Liu <email@example.com>, "David S. Miller" <firstname.lastname@example.org>, Jakub Kicinski <email@example.com>, Sasha Levin <firstname.lastname@example.org>, Florian Fainelli <email@example.com>, Heiner Kallweit <firstname.lastname@example.org>, Masahisa Kojima <email@example.com> Subject: Re: realtek PHY commit bbc4d71d63549 causes regression Date: Sat, 17 Oct 2020 20:55:26 +0200 Message-ID: <CAMj1kXHwYkd0L63K3+e_iwfoSYEUOmYdWf_cKv90_qVXSxEesg@mail.gmail.com> (raw) In-Reply-To: <20201017182738.GN456889@lunn.ch> On Sat, 17 Oct 2020 at 20:27, Andrew Lunn <firstname.lastname@example.org> wrote: > > On Sat, Oct 17, 2020 at 08:11:24PM +0200, Ard Biesheuvel wrote: > > On Sat, 17 Oct 2020 at 20:04, Andrew Lunn <email@example.com> 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 > > > will need to revert your proposed change in order to make the MAC > > > driver work as it should, rather than work around the broken firmware. > > > > > > > What do you mean by 'pure' DT system? Only EDK2 based firmware exists > > for this platform > > Currently, only EDK2 based firmware exists. Is there anything stopping > somebody using u-boot? ACPI is aimed for server class systems, on > ARM. If anybody wants to use this SoC in am embedded setting, not > server, then they are more likely to use DT, especially when you need > a complex network, eg. an Ethernet switch. It seems like ACPI is too > simple to support complex network hardware found in some embedded > systems. > > > So what I propose to do is drop the handling of the [mandatory] > > phy-mode device property from the netsec driver (which is really only > > used by this board). As we don't really need a phy-mode to begin with, > > and given that firmware exists in the field that passes the wrong > > value, the only option I see for passing a value here is to use a > > different, *optional* DT property (force-phy-mode or > > phy-mode-override) that takes the place of phy-mode. > > No, sorry, this is an ACPI problem, not a DT problem. I don't want to > accept DT hacks because of broken ACPI. > > We have been through this before, when the Atheros PHY fixed is RGMII > delay support, and lots of platforms broke. Everybody just updated > their DT and were happy. I see no reason why ACPI should be different. > I don't understand why you insist on framing this as a ACPI vs DT issue. AFAICT, the only meaningful distinction here is between firmware that configures the PHY and firmware that doesn't. Broken firmware exists for this platform, and it provides incorrect DT data as well as incorrect ACPI data, but it does configure the PHY. Fixing that firmware involves fixing both, and it is easily updatable on this platform, so it is almost as simple as dropping a new DT file in your /boot partition. But you still need to do that. So we can fix this firmware by just setting phy-mode to the empty string, right? So the only question is how we deal with broken firmware. Again, I don't see much point in distinguishing between DT and ACPI here, as in both cases, the same action is required on the part of the user to change something on their system before they can upgrade their kernel.
next prev parent reply index Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-17 14:20 Ard Biesheuvel 2020-10-17 14:44 ` Andrew Lunn 2020-10-17 14:46 ` Ard Biesheuvel 2020-10-17 15:11 ` Andrew Lunn 2020-10-17 15:18 ` Ard Biesheuvel 2020-10-17 16:14 ` Ilias Apalodimas 2020-10-17 16:17 ` Ard Biesheuvel 2020-10-17 16:21 ` Ilias Apalodimas 2020-10-17 18:04 ` Andrew Lunn 2020-10-17 18:11 ` Ard Biesheuvel 2020-10-17 18:17 ` Ard Biesheuvel 2020-10-17 18:27 ` Andrew Lunn 2020-10-17 18:55 ` Ard Biesheuvel [this message] 2020-10-17 19:49 ` Andrew Lunn 2020-10-17 22:19 ` Ard Biesheuvel 2020-10-17 23:02 ` Andrew Lunn 2020-10-18 10:35 ` Ard Biesheuvel 2020-10-18 10:56 ` Ard Biesheuvel 2020-10-18 15:45 ` Andrew Lunn 2020-10-25 14:16 ` Ard Biesheuvel 2020-10-25 14:28 ` Andrew Lunn 2020-10-25 14:34 ` Ard Biesheuvel 2020-10-25 14:42 ` Andrew Lunn 2020-10-29 14:21 ` Ilias Apalodimas 2020-10-29 14:39 ` Andrew Lunn 2020-10-29 14:42 ` Ard Biesheuvel 2020-10-29 14:50 ` Andrew Lunn 2020-10-29 14:46 ` Ilias Apalodimas 2020-11-05 17:31 ` Jernej Škrabec 2020-11-13 13:50 ` Arnd Bergmann 2020-11-13 14:44 ` Andrew Lunn 2020-11-13 15:33 ` Arnd Bergmann 2020-11-13 16:56 ` Andrew Lunn 2020-11-13 21:26 ` Arnd Bergmann 2020-11-13 22:43 ` Andrew Lunn 2020-11-13 22:49 ` Ard Biesheuvel 2020-11-14 0:40 ` Andrew Lunn 2020-11-14 10:09 ` Ard Biesheuvel 2020-10-18 15:38 ` Andrew Lunn 2020-10-18 14:20 ` Masami Hiramatsu 2020-10-17 18:01 ` Andrew Lunn
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAMj1kXHwYkd0L63K3+e_iwfoSYEUOmYdWf_cKv90_qVXSxEesg@mail.gmail.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Netdev Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/netdev/0 netdev/git/0.git git clone --mirror https://lore.kernel.org/netdev/1 netdev/git/1.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 netdev netdev/ https://lore.kernel.org/netdev \ email@example.com public-inbox-index netdev Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.netdev AGPL code for this site: git clone https://public-inbox.org/public-inbox.git