All of lore.kernel.org
 help / color / mirror / Atom feed
From: f.fainelli@gmail.com (Florian Fainelli)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] ARM: zynq: DT: Add Ethernet phys
Date: Mon, 25 Aug 2014 13:21:24 -0700	[thread overview]
Message-ID: <53FB9AC4.8010704@gmail.com> (raw)
In-Reply-To: <20140825174610.GA13737@obsidianresearch.com>

On 08/25/2014 10:46 AM, Jason Gunthorpe wrote:
> On Fri, Aug 22, 2014 at 01:47:09PM -0700, Florian Fainelli wrote:
> 
>>>  - the ID based strings seem to be not needed since, IIUC, the core
>>>    reads the ID from the PHY and uses it, so I just left it out not
>>>    trying to figure out how to obtain the correct ID
>>
>> It is not needed, but it is one way to specify a PHY device if you do
>> not know what compatible string to use instead.
> 
> No, it is a way to specify a PHY device if the kernel can't auto probe
> the Phy ID.
> 
> Last I checked, the kernel doesn't support plain text compatible
> strings for phys - everything is driven on the phy id, either auto
> probed or specified in the DT.

That's right. Some PHY drivers might be relying on specific compatible
strings though, but not the core PHY library that probes and maps a
driver to a PHY node.

> 
>>>  - the marvell compatible strings are used in our vendor tree. They
>>>    aren't used anywhere but in our vendor tree. I though keeping them is
>>>    nice since it identifies the PHY fully. And in case that level of
>>>    detail is needed at some point it is already there.
>>
>> And this is the recommended way to do it in case we ever need to key a
>> software decision based on the hardware.
> 
> All compatible strings need to be documented.
> 
> .. and they need to encode more information than you get from the phy
> id - die revsision, package option, functional options, voltage
> codes. Etc.
> 
> .. and they actually need to be *right*

Agreed.

> 
> An example: The kernel reports 88E1318S for all four chips in that
> family, AFAIK you have to read the package marking to figure out which
> you have (it is the same die, with options switched on/off at
> packaging time). People have already posted patches trying to
> helpfully add a 'marvell,88E1318S' compatible string based on kernel
> output. Except it is wrong, it isn't actually the '8S version in the
> HW.
> 
> Even worse, Marvell has a whole series of socket compatible phys. Just
> because the board the DT author looked at has a '318, doesn't mean
> that every board ever made will. We've actually already been switching
> between the 318 and 318S for production depending on which has part
> availability.
> 
> Basically: don't try to override self-discoverable hardware in DT
> without a really good reason.

I think that's a very good point, at the very least let's use a
compatible string that contains the full 32-bits PHY OUI.

Thanks
--
Florian

WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Jason Gunthorpe
	<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Cc: "Sören Brinkmann"
	<soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>,
	"Mark Rutland" <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Russell King" <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	"Pawel Moll" <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
	"Ian Campbell"
	<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	"Michal Simek"
	<michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Rob Herring" <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"Kumar Gala" <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	"Andreas Färber" <afaerber-l3A5Bk7waGM@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH 3/3] ARM: zynq: DT: Add Ethernet phys
Date: Mon, 25 Aug 2014 13:21:24 -0700	[thread overview]
Message-ID: <53FB9AC4.8010704@gmail.com> (raw)
In-Reply-To: <20140825174610.GA13737-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>

On 08/25/2014 10:46 AM, Jason Gunthorpe wrote:
> On Fri, Aug 22, 2014 at 01:47:09PM -0700, Florian Fainelli wrote:
> 
>>>  - the ID based strings seem to be not needed since, IIUC, the core
>>>    reads the ID from the PHY and uses it, so I just left it out not
>>>    trying to figure out how to obtain the correct ID
>>
>> It is not needed, but it is one way to specify a PHY device if you do
>> not know what compatible string to use instead.
> 
> No, it is a way to specify a PHY device if the kernel can't auto probe
> the Phy ID.
> 
> Last I checked, the kernel doesn't support plain text compatible
> strings for phys - everything is driven on the phy id, either auto
> probed or specified in the DT.

That's right. Some PHY drivers might be relying on specific compatible
strings though, but not the core PHY library that probes and maps a
driver to a PHY node.

> 
>>>  - the marvell compatible strings are used in our vendor tree. They
>>>    aren't used anywhere but in our vendor tree. I though keeping them is
>>>    nice since it identifies the PHY fully. And in case that level of
>>>    detail is needed at some point it is already there.
>>
>> And this is the recommended way to do it in case we ever need to key a
>> software decision based on the hardware.
> 
> All compatible strings need to be documented.
> 
> .. and they need to encode more information than you get from the phy
> id - die revsision, package option, functional options, voltage
> codes. Etc.
> 
> .. and they actually need to be *right*

Agreed.

> 
> An example: The kernel reports 88E1318S for all four chips in that
> family, AFAIK you have to read the package marking to figure out which
> you have (it is the same die, with options switched on/off at
> packaging time). People have already posted patches trying to
> helpfully add a 'marvell,88E1318S' compatible string based on kernel
> output. Except it is wrong, it isn't actually the '8S version in the
> HW.
> 
> Even worse, Marvell has a whole series of socket compatible phys. Just
> because the board the DT author looked at has a '318, doesn't mean
> that every board ever made will. We've actually already been switching
> between the 318 and 318S for production depending on which has part
> availability.
> 
> Basically: don't try to override self-discoverable hardware in DT
> without a really good reason.

I think that's a very good point, at the very least let's use a
compatible string that contains the full 32-bits PHY OUI.

Thanks
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <f.fainelli@gmail.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: "Sören Brinkmann" <soren.brinkmann@xilinx.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"Russell King" <linux@arm.linux.org.uk>,
	"Pawel Moll" <pawel.moll@arm.com>,
	"Ian Campbell" <ijc+devicetree@hellion.org.uk>,
	"Michal Simek" <michal.simek@xilinx.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Kumar Gala" <galak@codeaurora.org>,
	"Andreas Färber" <afaerber@suse.de>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 3/3] ARM: zynq: DT: Add Ethernet phys
Date: Mon, 25 Aug 2014 13:21:24 -0700	[thread overview]
Message-ID: <53FB9AC4.8010704@gmail.com> (raw)
In-Reply-To: <20140825174610.GA13737@obsidianresearch.com>

On 08/25/2014 10:46 AM, Jason Gunthorpe wrote:
> On Fri, Aug 22, 2014 at 01:47:09PM -0700, Florian Fainelli wrote:
> 
>>>  - the ID based strings seem to be not needed since, IIUC, the core
>>>    reads the ID from the PHY and uses it, so I just left it out not
>>>    trying to figure out how to obtain the correct ID
>>
>> It is not needed, but it is one way to specify a PHY device if you do
>> not know what compatible string to use instead.
> 
> No, it is a way to specify a PHY device if the kernel can't auto probe
> the Phy ID.
> 
> Last I checked, the kernel doesn't support plain text compatible
> strings for phys - everything is driven on the phy id, either auto
> probed or specified in the DT.

That's right. Some PHY drivers might be relying on specific compatible
strings though, but not the core PHY library that probes and maps a
driver to a PHY node.

> 
>>>  - the marvell compatible strings are used in our vendor tree. They
>>>    aren't used anywhere but in our vendor tree. I though keeping them is
>>>    nice since it identifies the PHY fully. And in case that level of
>>>    detail is needed at some point it is already there.
>>
>> And this is the recommended way to do it in case we ever need to key a
>> software decision based on the hardware.
> 
> All compatible strings need to be documented.
> 
> .. and they need to encode more information than you get from the phy
> id - die revsision, package option, functional options, voltage
> codes. Etc.
> 
> .. and they actually need to be *right*

Agreed.

> 
> An example: The kernel reports 88E1318S for all four chips in that
> family, AFAIK you have to read the package marking to figure out which
> you have (it is the same die, with options switched on/off at
> packaging time). People have already posted patches trying to
> helpfully add a 'marvell,88E1318S' compatible string based on kernel
> output. Except it is wrong, it isn't actually the '8S version in the
> HW.
> 
> Even worse, Marvell has a whole series of socket compatible phys. Just
> because the board the DT author looked at has a '318, doesn't mean
> that every board ever made will. We've actually already been switching
> between the 318 and 318S for production depending on which has part
> availability.
> 
> Basically: don't try to override self-discoverable hardware in DT
> without a really good reason.

I think that's a very good point, at the very least let's use a
compatible string that contains the full 32-bits PHY OUI.

Thanks
--
Florian

  reply	other threads:[~2014-08-25 20:21 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-20 15:56 [PATCH 1/3] ARM: zynq: DT: Fix Ethernet phy modes Soren Brinkmann
2014-08-20 15:56 ` Soren Brinkmann
2014-08-20 15:56 ` [PATCH 2/3] ARM: zynq: DT: Move size/address properties to dtsi Soren Brinkmann
2014-08-20 15:56   ` Soren Brinkmann
2014-08-20 16:00   ` Andreas Färber
2014-08-20 16:00     ` Andreas Färber
2014-08-21  8:42     ` Michal Simek
2014-08-21  8:42       ` Michal Simek
2014-08-21  8:42       ` Michal Simek
2014-08-20 15:56 ` [PATCH 3/3] ARM: zynq: DT: Add Ethernet phys Soren Brinkmann
2014-08-20 15:56   ` Soren Brinkmann
2014-08-21  8:41   ` Michal Simek
2014-08-21  8:41     ` Michal Simek
2014-08-21  8:41     ` Michal Simek
2014-08-21 11:32     ` Andreas Färber
2014-08-21 11:32       ` Andreas Färber
2014-08-21 15:49       ` Sören Brinkmann
2014-08-21 15:49         ` Sören Brinkmann
2014-08-21 15:49         ` Sören Brinkmann
2014-08-22 16:20         ` Jason Gunthorpe
2014-08-22 16:20           ` Jason Gunthorpe
2014-08-22 16:20           ` Jason Gunthorpe
2014-08-22 16:31           ` Sören Brinkmann
2014-08-22 16:31             ` Sören Brinkmann
2014-08-22 16:48             ` Jason Gunthorpe
2014-08-22 16:48               ` Jason Gunthorpe
2014-08-22 16:48               ` Jason Gunthorpe
2014-08-22 20:47         ` Florian Fainelli
2014-08-22 20:47           ` Florian Fainelli
2014-08-22 20:47           ` Florian Fainelli
2014-08-25 17:46           ` Jason Gunthorpe
2014-08-25 17:46             ` Jason Gunthorpe
2014-08-25 17:46             ` Jason Gunthorpe
2014-08-25 20:21             ` Florian Fainelli [this message]
2014-08-25 20:21               ` Florian Fainelli
2014-08-25 20:21               ` Florian Fainelli
2014-08-29 14:08               ` Michal Simek
2014-08-29 14:08                 ` Michal Simek
2014-08-29 14:08                 ` Michal Simek
2014-08-29 15:18                 ` Andreas Färber
2014-08-29 15:18                   ` Andreas Färber
2014-08-29 15:35                   ` Sören Brinkmann
2014-08-29 15:35                     ` Sören Brinkmann
2014-08-29 15:35                     ` Sören Brinkmann
2014-08-29 15:46                     ` Andreas Färber
2014-08-29 15:46                       ` Andreas Färber
2014-08-29 15:46                       ` Andreas Färber
2014-08-29 17:31                     ` Jason Gunthorpe
2014-08-29 17:31                       ` Jason Gunthorpe
2014-08-29 17:31                       ` Jason Gunthorpe
2014-08-29 18:23                       ` Florian Fainelli
2014-08-29 18:23                         ` Florian Fainelli
2014-08-29 18:23                         ` Florian Fainelli
2014-08-29 23:22                         ` Jason Gunthorpe
2014-08-29 23:22                           ` Jason Gunthorpe
2014-08-30  0:43                           ` Florian Fainelli
2014-08-30  0:43                             ` Florian Fainelli
2014-08-30  0:43                             ` Florian Fainelli
2014-09-01 11:26                             ` Michal Simek
2014-09-01 11:26                               ` Michal Simek
2014-09-01 11:26                               ` Michal Simek
2014-08-22 20:42     ` Florian Fainelli
2014-08-21  8:42 ` [PATCH 1/3] ARM: zynq: DT: Fix Ethernet phy modes Michal Simek
2014-08-21  8:42   ` Michal Simek
2014-08-21  8:42   ` Michal Simek

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=53FB9AC4.8010704@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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 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.