The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Jeremy Linton <jeremy.linton@arm.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org, opendmb@gmail.com, davem@davemloft.net,
	bcm-kernel-feedback-list@broadcom.com,
	linux-kernel@vger.kernel.org, wahrenst@gmx.net,
	hkallweit1@gmail.com
Subject: Re: [PATCH 2/6] net: bcmgenet: refactor phy mode configuration
Date: Mon, 3 Feb 2020 10:55:02 -0800	[thread overview]
Message-ID: <fdb6d522-f207-f002-5d71-8fa541bd745e@gmail.com> (raw)
In-Reply-To: <0d743b51-fd77-db8c-1910-c725c4b2e7b9@arm.com>

On 2/3/20 10:46 AM, Jeremy Linton wrote:
> Hi,
> 
> On 2/2/20 9:24 PM, Florian Fainelli wrote:
>>
>>
>> On 2/2/2020 5:17 PM, Andrew Lunn wrote:
>>> On Sat, Feb 01, 2020 at 08:24:14AM -0800, Florian Fainelli wrote:
>>>>
>>>>
>>>> On 1/31/2020 11:46 PM, Jeremy Linton wrote:
>>>>> The DT phy mode is similar to what we want for ACPI
>>>>> lets factor it out of the of path, and change the
>>>>> of_ call to device_. Further if the phy-mode property
>>>>> cannot be found instead of failing the driver load lets
>>>>> just default it to RGMII.
>>>>
>>>> Humm no please do not provide a fallback, if we cannot find a valid
>>>> 'phy-mode' property we error out. This controller can be used with a
>>>> variety of configurations (internal EPHY/GPHY, MoCA, external
>>>> MII/Reverse MII/RGMII) and from a support perspective it is much easier
>>>> for us if the driver errors out if one of those essential properties
>>>> are
>>>> omitted.
>>>
>>> Hi Florian
>>>
>>> Does any of the silicon variants have two or more MACs sharing one
>>> MDIO bus? I'm thinking about the next patch in the series.
>>
>> Have not come across a customer doing that, but the hardware
>> definitively permits it, and so does the top-level chip pinmuxing.
>>
> 
> Does the genet driver?
> 
> I might be missing something in the driver, but it looks like the whole
> thing is 1:1:1:1 with platform dev:mdio:phy:netdev at the moment. Given
> the way bcmgenet_mii_register is throwing a bcmgenet MII bus for every
> device _probe().

Andrew's question was hypothetical, and I answered it the best way I
could. I did not say this was a *currently* supported combination from a
software perspective or that it would work today, but the hardware would
allow it. This question probably belongs to patch #3 which is about
using (or not phy_find_first).
-- 
Florian

  reply	other threads:[~2020-02-03 18:55 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-01  7:46 [PATCH 0/6] Add ACPI bindings to the genet Jeremy Linton
2020-02-01  7:46 ` [PATCH 1/6] mdio_bus: Add generic mdio_find_bus() Jeremy Linton
2020-02-01  7:46 ` [PATCH 2/6] net: bcmgenet: refactor phy mode configuration Jeremy Linton
2020-02-01 16:24   ` Florian Fainelli
2020-02-01 19:10     ` Jeremy Linton
2020-02-03  1:17     ` Andrew Lunn
2020-02-03  3:24       ` Florian Fainelli
2020-02-03 18:46         ` Jeremy Linton
2020-02-03 18:55           ` Florian Fainelli [this message]
2020-02-05 21:05   ` kbuild test robot
2020-02-01  7:46 ` [PATCH 3/6] net: bcmgenet: enable automatic phy discovery Jeremy Linton
2020-02-01 15:25   ` Andrew Lunn
2020-02-01 19:07     ` Jeremy Linton
2020-02-03 20:55       ` Florian Fainelli
2020-02-03 21:21         ` Andrew Lunn
2020-02-01 20:02     ` Jeremy Linton
2020-02-03  1:15       ` Andrew Lunn
2020-02-03 21:10         ` Jeremy Linton
2020-02-01  7:46 ` [PATCH 4/6] net: bcmgenet: Initial bcmgenet ACPI support Jeremy Linton
2020-02-01 15:33   ` Andrew Lunn
2020-02-01 19:09     ` Jeremy Linton
2020-02-01  7:46 ` [PATCH 5/6] net: bcmgenet: Fetch MAC address from the adapter Jeremy Linton
2020-02-01 15:37   ` Andrew Lunn
2020-02-01 19:20     ` Jeremy Linton
2020-02-01  7:46 ` [PATCH 6/6] net: bcmgenet: reduce severity of missing clock warnings Jeremy Linton
2020-02-01 16:18   ` Florian Fainelli
2020-02-01 16:44   ` Stefan Wahren
2020-02-01 19:27     ` Jeremy Linton
2020-02-03 18:36       ` Nicolas Saenz Julienne
2020-02-03 19:08         ` Stefan Wahren
2020-02-03 21:21           ` Florian Fainelli
2020-02-05 18:42             ` Stefan Wahren

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=fdb6d522-f207-f002-5d71-8fa541bd745e@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=hkallweit1@gmail.com \
    --cc=jeremy.linton@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=opendmb@gmail.com \
    --cc=wahrenst@gmx.net \
    /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