devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Michael Walle <michael@walle.cc>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	netdev@vger.kernel.org
Cc: Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH 0/3] net: phy: initialize PHYs via device tree properties
Date: Tue, 29 Oct 2019 10:59:07 -0700	[thread overview]
Message-ID: <519d52d2-cd83-b544-591b-ca9d9bb16dfa@gmail.com> (raw)
In-Reply-To: <20191029174819.3502-1-michael@walle.cc>

On 10/29/19 10:48 AM, Michael Walle wrote:
> I was trying to configure the Atheros PHY for my board. There are fixups
> all over the place, for example to enable the 125MHz clock output in almost
> any i.MX architecture. Instead of adding another fixup in architecture
> specific code, try to provide a generic way to init the PHY registers.
> 
> This patch series tries to pick up the "broadcom,reg-init" and
> "marvell,reg-init" device tree properties idea and make it a more generic
> "reg-init" which is handled by phy_device instead of a particular phy
> driver.

These two examples are actually quite bad and were symptomatic of a few
things at the time:

- rush to get a specific feature/device supported without thinking about
the big picture
- lack of appropriate review on the Device Tree bindings

Fortunately, the last item is now not happening anymore.

The problem with letting that approach go through is that the Device
Tree can now hold a configuration policy which is passed through as-is
from DT to the PHY device, this is bad on so many different levels,
starting with abstraction.

If all you need is to enable a particular clock, introduce device
specific properties that describe the hardware, and make the necessary
change to the local driver that needs to act on those. You can always
define a more generic scope property if you see a recurring pattern.

So just to be clear on the current approach: NACK.

> 
> Michael Walle (3):
>   dt-bindings: net: phy: Add reg-init property
>   net: phy: export __phy_{read|write}_page
>   net: phy: Use device tree properties to initialize any PHYs
> 
>  .../devicetree/bindings/net/ethernet-phy.yaml | 31 ++++++
>  MAINTAINERS                                   |  1 +
>  drivers/net/phy/phy-core.c                    | 24 ++++-
>  drivers/net/phy/phy_device.c                  | 97 ++++++++++++++++++-
>  include/dt-bindings/net/phy.h                 | 18 ++++
>  include/linux/phy.h                           |  2 +
>  6 files changed, 170 insertions(+), 3 deletions(-)
>  create mode 100644 include/dt-bindings/net/phy.h
> 
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Heiner Kallweit <hkallweit1@gmail.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> 


-- 
Florian

  parent reply	other threads:[~2019-10-29 17:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-29 17:48 [PATCH 0/3] net: phy: initialize PHYs via device tree properties Michael Walle
2019-10-29 17:48 ` [PATCH 1/3] dt-bindings: net: phy: Add reg-init property Michael Walle
2019-10-29 17:48 ` [PATCH 2/3] net: phy: export __phy_{read|write}_page Michael Walle
2019-10-29 17:48 ` [PATCH 3/3] net: phy: Use device tree properties to initialize any PHYs Michael Walle
2019-10-29 17:59 ` Florian Fainelli [this message]
2019-10-29 18:25   ` [PATCH 0/3] net: phy: initialize PHYs via device tree properties Andrew Lunn
2019-10-29 20:54   ` Michael Walle
2019-10-29 20:59     ` Florian Fainelli
2019-10-30 13:19       ` Michael Walle

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=519d52d2-cd83-b544-591b-ca9d9bb16dfa@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=hkallweit1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=michael@walle.cc \
    --cc=netdev@vger.kernel.org \
    --cc=robh+dt@kernel.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).