From: Bartosz Golaszewski <brgl@bgdev.pl>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Mark Brown <broonie@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
"David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
Vladimir Oltean <vladimir.oltean@nxp.com>,
Claudiu Manoil <claudiu.manoil@nxp.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Vivien Didelot <vivien.didelot@gmail.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Jassi Brar <jaswinder.singh@linaro.org>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Iyappan Subramanian <iyappan@os.amperecomputing.com>,
Keyur Chudgar <keyur@os.amperecomputing.com>,
Quan Nguyen <quan@os.amperecomputing.com>,
Frank Rowand <frowand.list@gmail.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
Liam Girdwood <lgirdwood@gmail.com>,
netdev <netdev@vger.kernel.org>,
devicetree <devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"moderated list:ARM/Mediatek SoC..."
<linux-mediatek@lists.infradead.org>,
Fabien Parent <fparent@baylibre.com>,
Stephane Le Provost <stephane.leprovost@mediatek.com>,
Pedro Tsai <pedro.tsai@mediatek.com>,
Andrew Perepech <andrew.perepech@mediatek.com>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>
Subject: Re: [PATCH 09/15] net: phy: delay PHY driver probe until PHY registration
Date: Wed, 24 Jun 2020 18:35:37 +0200 [thread overview]
Message-ID: <CAMRc=MfQFgrJC3nvuJgZobixa6MLeMw-tdg_3e1yNDityU5XSw@mail.gmail.com> (raw)
In-Reply-To: <f806586d-a6d7-99af-bba4-d1e7d28be192@gmail.com>
On Wed, Jun 24, 2020 at 6:06 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
[snip!]
> >
> > This has evolved into several new concepts being proposed vs my
> > use-case which is relatively simple. The former will probably take
> > several months of development, reviews and discussions and it will
> > block supporting the phy supply on pumpkin boards upstream. I would
> > prefer not to redo what other MAC drivers do (phy-supply property on
> > the MAC node, controlling it from the MAC driver itself) if we've
> > already established it's wrong.
>
> You are not new to Linux development, so none of this should come as a
> surprise to you. Your proposed solution has clearly short comings and is
> a hack, especially around the PHY_ID_NONE business to get a phy_device
> only then to have the real PHY device ID. You should also now that "I
> need it now because my product deliverable depends on it" has never been
> received as a valid argument to coerce people into accepting a solution
> for which there are at review time known deficiencies to the proposed
> approach.
>
Don't get me wrong, I understand that full well. On the other hand a
couple years ago I put a significant amount of work into the concept
of early platform device drivers for linux clocksource, clock and
interrupt drivers. Every reviewer had his own preferred approach and
after something like three completely different submissions and
several conversations at conferences I simply gave up due to all the
bikeshedding. It just wasn't moving forward and frankly: I expect any
changes to the core driver model to follow a similar path of most
resistance.
I will give it a shot but at some point getting the job done is better
than not getting it done just because the solution isn't perfect. IMO
this approach is still slightly more correct than controlling the
PHY's supply from the MAC driver.
Bartosz
WARNING: multiple messages have this Message-ID (diff)
From: Bartosz Golaszewski <brgl@bgdev.pl>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
devicetree <devicetree@vger.kernel.org>,
Vladimir Oltean <vladimir.oltean@nxp.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Fabien Parent <fparent@baylibre.com>,
Iyappan Subramanian <iyappan@os.amperecomputing.com>,
Quan Nguyen <quan@os.amperecomputing.com>,
Frank Rowand <frowand.list@gmail.com>,
Russell King <linux@armlinux.org.uk>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Jakub Kicinski <kuba@kernel.org>,
Vivien Didelot <vivien.didelot@gmail.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Andrew Perepech <andrew.perepech@mediatek.com>,
Stephane Le Provost <stephane.leprovost@mediatek.com>,
Keyur Chudgar <keyur@os.amperecomputing.com>,
Jassi Brar <jaswinder.singh@linaro.org>,
Claudiu Manoil <claudiu.manoil@nxp.com>,
Rob Herring <robh+dt@kernel.org>,
"moderated list:ARM/Mediatek SoC..."
<linux-mediatek@lists.infradead.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
netdev <netdev@vger.kernel.org>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
Mark Brown <broonie@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Pedro Tsai <pedro.tsai@mediatek.com>,
"David S . Miller" <davem@davemloft.net>,
Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH 09/15] net: phy: delay PHY driver probe until PHY registration
Date: Wed, 24 Jun 2020 18:35:37 +0200 [thread overview]
Message-ID: <CAMRc=MfQFgrJC3nvuJgZobixa6MLeMw-tdg_3e1yNDityU5XSw@mail.gmail.com> (raw)
In-Reply-To: <f806586d-a6d7-99af-bba4-d1e7d28be192@gmail.com>
On Wed, Jun 24, 2020 at 6:06 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
[snip!]
> >
> > This has evolved into several new concepts being proposed vs my
> > use-case which is relatively simple. The former will probably take
> > several months of development, reviews and discussions and it will
> > block supporting the phy supply on pumpkin boards upstream. I would
> > prefer not to redo what other MAC drivers do (phy-supply property on
> > the MAC node, controlling it from the MAC driver itself) if we've
> > already established it's wrong.
>
> You are not new to Linux development, so none of this should come as a
> surprise to you. Your proposed solution has clearly short comings and is
> a hack, especially around the PHY_ID_NONE business to get a phy_device
> only then to have the real PHY device ID. You should also now that "I
> need it now because my product deliverable depends on it" has never been
> received as a valid argument to coerce people into accepting a solution
> for which there are at review time known deficiencies to the proposed
> approach.
>
Don't get me wrong, I understand that full well. On the other hand a
couple years ago I put a significant amount of work into the concept
of early platform device drivers for linux clocksource, clock and
interrupt drivers. Every reviewer had his own preferred approach and
after something like three completely different submissions and
several conversations at conferences I simply gave up due to all the
bikeshedding. It just wasn't moving forward and frankly: I expect any
changes to the core driver model to follow a similar path of most
resistance.
I will give it a shot but at some point getting the job done is better
than not getting it done just because the solution isn't perfect. IMO
this approach is still slightly more correct than controlling the
PHY's supply from the MAC driver.
Bartosz
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: Bartosz Golaszewski <brgl@bgdev.pl>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
devicetree <devicetree@vger.kernel.org>,
Vladimir Oltean <vladimir.oltean@nxp.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Fabien Parent <fparent@baylibre.com>,
Iyappan Subramanian <iyappan@os.amperecomputing.com>,
Quan Nguyen <quan@os.amperecomputing.com>,
Frank Rowand <frowand.list@gmail.com>,
Russell King <linux@armlinux.org.uk>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Jakub Kicinski <kuba@kernel.org>,
Vivien Didelot <vivien.didelot@gmail.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Andrew Perepech <andrew.perepech@mediatek.com>,
Stephane Le Provost <stephane.leprovost@mediatek.com>,
Keyur Chudgar <keyur@os.amperecomputing.com>,
Jassi Brar <jaswinder.singh@linaro.org>,
Claudiu Manoil <claudiu.manoil@nxp.com>,
Rob Herring <robh+dt@kernel.org>,
"moderated list:ARM/Mediatek SoC..."
<linux-mediatek@lists.infradead.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
netdev <netdev@vger.kernel.org>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
Mark Brown <broonie@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Pedro Tsai <pedro.tsai@mediatek.com>,
"David S . Miller" <davem@davemloft.net>,
Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH 09/15] net: phy: delay PHY driver probe until PHY registration
Date: Wed, 24 Jun 2020 18:35:37 +0200 [thread overview]
Message-ID: <CAMRc=MfQFgrJC3nvuJgZobixa6MLeMw-tdg_3e1yNDityU5XSw@mail.gmail.com> (raw)
In-Reply-To: <f806586d-a6d7-99af-bba4-d1e7d28be192@gmail.com>
On Wed, Jun 24, 2020 at 6:06 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
[snip!]
> >
> > This has evolved into several new concepts being proposed vs my
> > use-case which is relatively simple. The former will probably take
> > several months of development, reviews and discussions and it will
> > block supporting the phy supply on pumpkin boards upstream. I would
> > prefer not to redo what other MAC drivers do (phy-supply property on
> > the MAC node, controlling it from the MAC driver itself) if we've
> > already established it's wrong.
>
> You are not new to Linux development, so none of this should come as a
> surprise to you. Your proposed solution has clearly short comings and is
> a hack, especially around the PHY_ID_NONE business to get a phy_device
> only then to have the real PHY device ID. You should also now that "I
> need it now because my product deliverable depends on it" has never been
> received as a valid argument to coerce people into accepting a solution
> for which there are at review time known deficiencies to the proposed
> approach.
>
Don't get me wrong, I understand that full well. On the other hand a
couple years ago I put a significant amount of work into the concept
of early platform device drivers for linux clocksource, clock and
interrupt drivers. Every reviewer had his own preferred approach and
after something like three completely different submissions and
several conversations at conferences I simply gave up due to all the
bikeshedding. It just wasn't moving forward and frankly: I expect any
changes to the core driver model to follow a similar path of most
resistance.
I will give it a shot but at some point getting the job done is better
than not getting it done just because the solution isn't perfect. IMO
this approach is still slightly more correct than controlling the
PHY's supply from the MAC driver.
Bartosz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-06-24 16:35 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-22 9:37 [PATCH 00/15] net: phy: correctly model the PHY voltage supply in DT Bartosz Golaszewski
2020-06-22 9:37 ` [PATCH 01/15] net: phy: arrange headers in mdio_bus.c alphabetically Bartosz Golaszewski
2020-06-22 13:12 ` Andrew Lunn
2020-06-23 18:54 ` Florian Fainelli
2020-06-23 18:54 ` Florian Fainelli
2020-06-23 18:54 ` Florian Fainelli
2020-06-22 9:37 ` [PATCH 02/15] net: phy: arrange headers in mdio_device.c alphabetically Bartosz Golaszewski
2020-06-22 13:12 ` Andrew Lunn
2020-06-23 18:56 ` Florian Fainelli
2020-06-23 18:56 ` Florian Fainelli
2020-06-23 18:56 ` Florian Fainelli
2020-06-22 9:37 ` [PATCH 03/15] net: phy: arrange headers in phy_device.c alphabetically Bartosz Golaszewski
2020-06-22 13:12 ` Andrew Lunn
2020-06-23 18:57 ` Florian Fainelli
2020-06-23 18:57 ` Florian Fainelli
2020-06-23 18:57 ` Florian Fainelli
2020-06-22 9:37 ` [PATCH 04/15] net: mdio: add a forward declaration for reset_control to mdio.h Bartosz Golaszewski
2020-06-22 13:13 ` Andrew Lunn
2020-06-23 18:59 ` Florian Fainelli
2020-06-23 18:59 ` Florian Fainelli
2020-06-23 18:59 ` Florian Fainelli
2020-06-22 9:37 ` [PATCH 05/15] net: phy: reset the PHY even if probe() is not implemented Bartosz Golaszewski
2020-06-22 13:16 ` Andrew Lunn
2020-06-23 19:14 ` Florian Fainelli
2020-06-23 19:14 ` Florian Fainelli
2020-06-23 19:14 ` Florian Fainelli
2020-06-24 16:22 ` Bartosz Golaszewski
2020-06-24 16:22 ` Bartosz Golaszewski
2020-06-24 16:22 ` Bartosz Golaszewski
2020-06-22 9:37 ` [PATCH 06/15] net: phy: mdio: reset MDIO devices " Bartosz Golaszewski
2020-06-22 13:18 ` Andrew Lunn
2020-06-23 19:16 ` Florian Fainelli
2020-06-23 19:16 ` Florian Fainelli
2020-06-23 19:16 ` Florian Fainelli
2020-06-22 9:37 ` [PATCH 07/15] net: phy: split out the PHY driver request out of phy_device_create() Bartosz Golaszewski
2020-06-22 9:37 ` [PATCH 08/15] net: phy: check the PHY presence in get_phy_id() Bartosz Golaszewski
2020-06-22 9:37 ` [PATCH 09/15] net: phy: delay PHY driver probe until PHY registration Bartosz Golaszewski
2020-06-22 13:39 ` Andrew Lunn
2020-06-22 13:51 ` Mark Brown
2020-06-23 19:49 ` Florian Fainelli
2020-06-23 19:49 ` Florian Fainelli
2020-06-23 19:49 ` Florian Fainelli
2020-06-24 9:43 ` Mark Brown
2020-06-24 9:43 ` Mark Brown
2020-06-24 9:43 ` Mark Brown
2020-06-24 13:48 ` Bartosz Golaszewski
2020-06-24 13:48 ` Bartosz Golaszewski
2020-06-24 13:48 ` Bartosz Golaszewski
2020-06-24 16:06 ` Florian Fainelli
2020-06-24 16:06 ` Florian Fainelli
2020-06-24 16:06 ` Florian Fainelli
2020-06-24 16:35 ` Bartosz Golaszewski [this message]
2020-06-24 16:35 ` Bartosz Golaszewski
2020-06-24 16:35 ` Bartosz Golaszewski
2020-06-24 16:50 ` Russell King - ARM Linux admin
2020-06-24 16:50 ` Russell King - ARM Linux admin
2020-06-24 16:50 ` Russell King - ARM Linux admin
2020-06-24 18:59 ` Robin Murphy
2020-06-24 18:59 ` Robin Murphy
2020-06-24 18:59 ` Robin Murphy
2020-06-22 9:37 ` [PATCH 10/15] net: phy: simplify phy_device_create() Bartosz Golaszewski
2020-06-22 9:37 ` [PATCH 11/15] net: phy: drop get_phy_device() Bartosz Golaszewski
2020-06-22 19:29 ` kernel test robot
2020-06-22 9:37 ` [PATCH 12/15] dt-bindings: mdio: add phy-supply property to ethernet phy node Bartosz Golaszewski
2020-06-23 19:39 ` Florian Fainelli
2020-06-23 19:39 ` Florian Fainelli
2020-06-23 19:39 ` Florian Fainelli
2020-06-22 9:37 ` [PATCH 13/15] net: phy: mdio: add support for PHY supply regulator Bartosz Golaszewski
2020-06-22 13:25 ` Russell King - ARM Linux admin
2020-06-23 9:30 ` Bartosz Golaszewski
2020-06-22 9:37 ` [PATCH 14/15] net: phy: add PHY regulator support Bartosz Golaszewski
2020-06-22 13:29 ` Russell King - ARM Linux admin
2020-06-23 9:41 ` Bartosz Golaszewski
2020-06-23 9:42 ` Russell King - ARM Linux admin
2020-06-23 9:46 ` Bartosz Golaszewski
2020-06-23 9:56 ` Russell King - ARM Linux admin
2020-06-23 16:27 ` Bartosz Golaszewski
2020-06-23 16:27 ` Bartosz Golaszewski
2020-06-23 16:27 ` Bartosz Golaszewski
2020-06-24 16:57 ` Russell King - ARM Linux admin
2020-06-24 16:57 ` Russell King - ARM Linux admin
2020-06-24 16:57 ` Russell King - ARM Linux admin
2020-06-24 18:12 ` Russell King - ARM Linux admin
2020-06-24 18:12 ` Russell King - ARM Linux admin
2020-06-24 18:12 ` Russell King - ARM Linux admin
2020-06-22 9:37 ` [PATCH 15/15] ARM64: dts: mediatek: add a phy regulator to pumpkin-common.dtsi Bartosz Golaszewski
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='CAMRc=MfQFgrJC3nvuJgZobixa6MLeMw-tdg_3e1yNDityU5XSw@mail.gmail.com' \
--to=brgl@bgdev.pl \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=andrew.perepech@mediatek.com \
--cc=andrew@lunn.ch \
--cc=bgolaszewski@baylibre.com \
--cc=broonie@kernel.org \
--cc=claudiu.manoil@nxp.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=fparent@baylibre.com \
--cc=frowand.list@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=ilias.apalodimas@linaro.org \
--cc=iyappan@os.amperecomputing.com \
--cc=jaswinder.singh@linaro.org \
--cc=keyur@os.amperecomputing.com \
--cc=kuba@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=pedro.tsai@mediatek.com \
--cc=quan@os.amperecomputing.com \
--cc=robh+dt@kernel.org \
--cc=stephane.leprovost@mediatek.com \
--cc=thomas.lendacky@amd.com \
--cc=vivien.didelot@gmail.com \
--cc=vladimir.oltean@nxp.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.