mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Quentin Schulz <quentin.schulz@bootlin.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: Mon, 1 Oct 2018 09:29:07 -0700	[thread overview]
Message-ID: <228f9d74-be17-5157-9755-b265a6e234b8@gmail.com> (raw)
In-Reply-To: <20181001094245.cr4hdcechrqkjymq@qschulz>

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.

> 
> [1] https://elixir.bootlin.com/linux/latest/source/arch/mips/boot/dts/mscc/ocelot_pcb123.dts
> 
>>> +		case PHY_INTERFACE_MODE_SGMII:
>>> +			phy_mode = PHY_MODE_SGMII;
>>> +			break;
>>> +		case PHY_INTERFACE_MODE_QSGMII:
>>> +			phy_mode = PHY_MODE_QSGMII;
>>> +			break;
>>> +		default:
>>> +			dev_err(ocelot->dev,
>>> +				"invalid phy mode for port%d, (Q)SGMII only\n",
>>> +				port);
>>> +			return -EINVAL;
>>> +		}
>>> +
>>> +		serdes = devm_of_phy_get(ocelot->dev, portnp, NULL);
>>> +		if (IS_ERR(serdes)) {
>>> +			err = PTR_ERR(serdes);
>>> +			if (err == -EPROBE_DEFER) {
>>
>> This can be simplified into:
>>
>> 			if (err == -EPROBE_DEFER)
>> 				dev_dbg();
>> 			else
>> 				dev_err();
>> 			goto err_probe_ports;
>>
> 
> Indeed, good catch.
> 
> Thanks,
> Quentin
> 


-- 
Florian

  reply	other threads:[~2018-10-01 16:29 UTC|newest]

Thread overview: 29+ 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-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 [this message]
2018-10-04 12:20         ` Quentin Schulz

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=228f9d74-be17-5157-9755-b265a6e234b8@gmail.com \
    --to=f.fainelli@gmail.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=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=quentin.schulz@bootlin.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®