From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F736C433E7 for ; Sat, 17 Oct 2020 18:11:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 68C0F2074A for ; Sat, 17 Oct 2020 18:11:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602958298; bh=wX+lL4WtAuqjsoQQbGH5kcxWF/Isg6XPw3Pf0idG5Ck=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=zNlmXfIlLjkz1xyk7Bv2ABC2+zO2ckLqPHhGA2YdURfnmWSBWeKP1ANqaiqXC0SOD B6wi+7LcvFdl7VI6WwifLEVcIDehA58kvQGqK/Ut14ZEGAlgf8wc3PNh7cndGpKOk1 +tqXo4f5QQFFb9eYcSXtzCHKBFeAjnx/FGKdo0Gk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2438792AbgJQSLh (ORCPT ); Sat, 17 Oct 2020 14:11:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:49710 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2437224AbgJQSLh (ORCPT ); Sat, 17 Oct 2020 14:11:37 -0400 Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com [209.85.167.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 846D82074A for ; Sat, 17 Oct 2020 18:11:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602958296; bh=wX+lL4WtAuqjsoQQbGH5kcxWF/Isg6XPw3Pf0idG5Ck=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=mPqnvWj32XyeuwJ7TxJtqRPijYQDZVpkITheCM1ijRDJaupDQ1xli81XzbWFhL701 C7lFSE/+h1FyQlfsHvmsjGtBzjWd3Kw7Vc4tlyfYNDqMWD/kwwJZT/MMB/LY4g+3ga eYRH9F/Uv+Pb0poZsLDEMiUemnZlk0TeG4IyBurE= Received: by mail-oi1-f177.google.com with SMTP id h10so6827998oie.5 for ; Sat, 17 Oct 2020 11:11:36 -0700 (PDT) X-Gm-Message-State: AOAM533BAk7bTEBmIVXjF2GhXSJzZzdRgsCl7lj45FfghK42NGiq7i/T 5Imez1SxwgyS0REcE0Jl8dAlKH07KX2o/Xpa1is= X-Google-Smtp-Source: ABdhPJzr9gBiD64POJmS0aoSk5pD02KzBv9Dgeoa0sn33SGPfJsyHzwHKVyhF295qKeeOpbR3VFM77xJu4dO4qhxiuI= X-Received: by 2002:aca:4085:: with SMTP id n127mr6440941oia.33.1602958295926; Sat, 17 Oct 2020 11:11:35 -0700 (PDT) MIME-Version: 1.0 References: <20201017144430.GI456889@lunn.ch> <20201017151132.GK456889@lunn.ch> <20201017161435.GA1768480@apalos.home> <20201017180453.GM456889@lunn.ch> In-Reply-To: <20201017180453.GM456889@lunn.ch> From: Ard Biesheuvel Date: Sat, 17 Oct 2020 20:11:24 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: realtek PHY commit bbc4d71d63549 causes regression To: Andrew Lunn Cc: Ilias Apalodimas , "open list:BPF JIT for MIPS (32-BIT AND 64-BIT)" , Willy Liu , "David S. Miller" , Jakub Kicinski , Sasha Levin , Florian Fainelli , Heiner Kallweit , Masahisa Kojima Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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 > 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, and it can be configured to boot either in DT or in ACPI mode. In both cases, it will pass the same, incorrect PHY mode, and in both cases, the firmware will already have configured the PHY correctly. 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. For ACPI boot, you will just need to fix your firmware if you are using a different PHY configuration.