All of lore.kernel.org
 help / color / mirror / Atom feed
From: Quentin Schulz <quentin.schulz@bootlin.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: alexandre.belloni@bootlin.com, ralf@linux-mips.org,
	paul.burton@mips.com, jhogan@kernel.org, robh+dt@kernel.org,
	mark.rutland@arm.com, davem@davemloft.net, kishon@ti.com,
	andrew@lunn.ch, allan.nielsen@microchip.com,
	linux-mips@linux-mips.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	thomas.petazzoni@bootlin.com
Subject: Re: [PATCH net-next v3 11/11] net: mscc: ocelot: make use of SerDes PHYs for handling their configuration
Date: Thu, 4 Oct 2018 14:20:16 +0200	[thread overview]
Message-ID: <20181004122016.udpugy65sam6m2si@qschulz> (raw)
In-Reply-To: <228f9d74-be17-5157-9755-b265a6e234b8@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2948 bytes --]

Hi Florian,

On Mon, Oct 01, 2018 at 09:29:07AM -0700, Florian Fainelli wrote:
> On 10/01/2018 02:42 AM, Quentin Schulz wrote:
> > Hi Florian,
> > 
> > On Sat, Sep 15, 2018 at 02:25:05PM -0700, Florian Fainelli wrote:
> >>
> >>
> >> On 09/14/18 01:16, Quentin Schulz wrote:
> >>> Previously, the SerDes muxing was hardcoded to a given mode in the MAC
> >>> controller driver. Now, the SerDes muxing is configured within the
> >>> Device Tree and is enforced in the MAC controller driver so we can have
> >>> a lot of different SerDes configurations.
> >>>
> >>> Make use of the SerDes PHYs in the MAC controller to set up the SerDes
> >>> according to the SerDes<->switch port mapping and the communication mode
> >>> with the Ethernet PHY.
> >>
> >> This looks good, just a few comments below:
> >>
> >> [snip]
> >>
> >>> +		err = of_get_phy_mode(portnp);
> >>> +		if (err < 0)
> >>> +			ocelot->ports[port]->phy_mode = PHY_INTERFACE_MODE_NA;
> >>> +		else
> >>> +			ocelot->ports[port]->phy_mode = err;
> >>> +
> >>> +		switch (ocelot->ports[port]->phy_mode) {
> >>> +		case PHY_INTERFACE_MODE_NA:
> >>> +			continue;
> >>
> >> Would not you want to issue a message indicating that the Device Tree
> >> must be updated here? AFAICT with your patch series, this should no
> >> longer be a condition that you will hit unless you kept the old DTB
> >> around, right?
> >>
> > 
> > It'll occur for internal PHYs. On the PCB123[1], there are four of them,
> > so we need to be able to give no mode in the DT for those. For the
> > upcoming PCB120, there'll be 4 external PHYs that require a mode in the
> > DT and 4 internal PHYs that do not require any mode. I could put a debug
> > message that says this or that PHY is configured as an internal PHY but
> > I wouldn't put a message that is printed with the default log level.
> > 
> > So I think we should keep it, shouldn't we?
> 
> Internal PHYs either use a standard connection internally (e.g: GMII) or
> they are using a proprietary connection interface, in which case
> phy-mode = "internal" is what we defined to represent those.
> 

Just to let you know that I'll send a new version in a few minutes that
does not contain the requested change. I don't have the information yet,
I know it's MII compatible but nothing more.
I haven't forgotten (yet; so don't hesitate to tell me if I do) your
suggestion.

Two thoughts:
1) Doing what you suggested is rather straightforward once I have the
information so it does not impact the actual overall behaviour of the
driver (reviewable as is),

2) The current behaviour aligns with the behaviour induced by the code
snippet above, so we don't break anything or introduce any change in
behaviour. Once I have an answer, I could always send a small patch for
this if the driver gets merged before, which would also change the DT
(to add the phy-mode property).

Thanks,
Quentin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2018-10-04 12:20 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-14  8:15 [PATCH net-next v3 00/11] mscc: ocelot: add support for SerDes muxing configuration Quentin Schulz
2018-09-14  8:15 ` [PATCH net-next v3 01/11] MIPS: mscc: ocelot: make HSIO registers address range a syscon Quentin Schulz
2018-09-14  8:16 ` [PATCH net-next v3 02/11] dt-bindings: net: ocelot: remove hsio from the list of register address spaces Quentin Schulz
2018-09-14  8:16 ` [PATCH net-next v3 03/11] net: mscc: ocelot: get HSIO regmap from syscon Quentin Schulz
2018-09-15  2:23   ` Florian Fainelli
2018-09-14  8:16 ` [PATCH net-next v3 04/11] net: mscc: ocelot: move the HSIO header to include/soc Quentin Schulz
2018-09-15  2:24   ` Florian Fainelli
2018-09-14  8:16 ` [PATCH net-next v3 05/11] net: mscc: ocelot: simplify register access for PLL5 configuration Quentin Schulz
2018-09-15  2:26   ` Florian Fainelli
2018-09-14  8:16 ` [PATCH net-next v3 06/11] phy: add QSGMII and PCIE modes Quentin Schulz
2018-09-15  2:27   ` Florian Fainelli
2018-09-14  8:16 ` [PATCH net-next v3 07/11] dt-bindings: phy: add DT binding for Microsemi Ocelot SerDes muxing Quentin Schulz
2018-09-15  2:29   ` Florian Fainelli
2018-09-26 21:35   ` Rob Herring
2018-10-01 12:46     ` Quentin Schulz
2018-10-01 17:10       ` Rob Herring
2018-09-14  8:16 ` [PATCH net-next v3 08/11] MIPS: mscc: ocelot: add SerDes mux DT node Quentin Schulz
2018-09-15  2:30   ` Florian Fainelli
2018-09-14  8:16 ` [PATCH net-next v3 09/11] dt-bindings: add constants for Microsemi Ocelot SerDes driver Quentin Schulz
2018-09-15  2:31   ` Florian Fainelli
2018-09-26 21:36   ` Rob Herring
2018-09-26 21:36     ` Rob Herring
2018-09-26 21:36     ` Rob Herring
2018-09-14  8:16 ` [PATCH net-next v3 10/11] phy: add driver for Microsemi Ocelot SerDes muxing Quentin Schulz
2018-09-15 21:20   ` Florian Fainelli
2018-10-01 10:02     ` Quentin Schulz
2018-09-14  8:16 ` [PATCH net-next v3 11/11] net: mscc: ocelot: make use of SerDes PHYs for handling their configuration Quentin Schulz
2018-09-15 21:25   ` Florian Fainelli
2018-10-01  9:42     ` Quentin Schulz
2018-10-01 16:29       ` Florian Fainelli
2018-10-04 12:20         ` Quentin Schulz [this message]

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=20181004122016.udpugy65sam6m2si@qschulz \
    --to=quentin.schulz@bootlin.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=allan.nielsen@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=jhogan@kernel.org \
    --cc=kishon@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=mark.rutland@arm.com \
    --cc=netdev@vger.kernel.org \
    --cc=paul.burton@mips.com \
    --cc=ralf@linux-mips.org \
    --cc=robh+dt@kernel.org \
    --cc=thomas.petazzoni@bootlin.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.