Netdev Archive on lore.kernel.org
 help / color / Atom feed
From: Robert Hancock <hancock@sedsystems.ca>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Andre Przywara <andre.przywara@arm.com>,
	Andrew Lunn <andrew@lunn.ch>,
	netdev@vger.kernel.org,
	Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>,
	Michal Simek <michal.simek@xilinx.com>,
	linux-kernel@vger.kernel.org,
	"David S . Miller" <davem@davemloft.net>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: Xilinx axienet 1000BaseX support
Date: Wed, 22 Apr 2020 10:31:52 -0600
Message-ID: <21ed251b-964f-3f16-1a66-728bbeffa426@sedsystems.ca> (raw)
In-Reply-To: <20200422075124.GJ25745@shell.armlinux.org.uk>

On 2020-04-22 1:51 a.m., Russell King - ARM Linux admin wrote:
> On Tue, Apr 21, 2020 at 07:45:47PM -0600, Robert Hancock wrote:
>> Hi Andre/Russell,
>>
>> Just wondering where things got to with the changes for SGMII on Xilinx
>> axienet that you were discussing (below)? I am looking into our Xilinx setup
>> using 1000BaseX SFP and trying to get it working "properly" with newer
>> kernels. My understanding is that the requirements for 1000BaseX and SGMII
>> are somewhat similar. I gathered that SGMII was working somewhat already,
>> but that not all link modes had been tested. However, it appears 1000BaseX
>> is not yet working in the stock kernel.
>>
>> The way I had this working before with a 4.19-based kernel was basically a
>> hack to phylink to allow the Xilinx PCS/PMA PHY to be configured
>> sufficiently as a PHY for it to work, and mostly ignored the link status of
>> the SFP PHY itself, even though we were using in-band signalling mode with
>> an SFP module. That was using this patch:
>>
>> https://patchwork.ozlabs.org/project/netdev/patch/1559330285-30246-5-git-send-email-hancock@sedsystems.ca/
>>
>> Of course, that's basically just a hack which I suspect mostly worked by
>> luck. I see that there are some helpers that were added to phylink to allow
>> setting PHY advertisements and reading PHY status from clause 22 PHY
>> devices, so I'm guessing that is the way to go in this case? Something like:
>>
>> axienet_mac_config: if using in-band mode, use
>> phylink_mii_c22_pcs_set_advertisement to configure the Xilinx PHY.
>>
>> axienet_mac_pcs_get_state: use phylink_mii_c22_pcs_get_state to get the MAC
>> PCS state from the Xilinx PHY
>>
>> axienet_mac_an_restart: if using in-band mode, use
>> phylink_mii_c22_pcs_an_restart to restart autonegotiation on Xilinx PHY
>>
>> To use those c22 functions, we need to find the mdio_device that's
>> referenced by the phy-handle in the device tree - I guess we can just use
>> some of the guts of of_phy_find_device to do that?
> 
> Please see the code for DPAA2 - it's changed slightly since I sent a
> copy to the netdev mailing list, and it still isn't clear whether this
> is the final approach (DPAA2 has some fun stuff such as several
> different PHYs at address 0.) NXP basically didn't like the approach
> I had in the patches I sent to netdev, we had a call, they presented
> an alternative appraoch, I implemented it, then they decided my
> original approach was the better solution for their situation.
> 
> See http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=cex7
> 
> specifically the patches from:
> 
>    "dpaa2-mac: add 1000BASE-X/SGMII PCS support"
> 
> through to:
> 
>    "net: phylink: add interface to configure clause 22 PCS PHY"
> 
> You may also need some of the patches further down in the net-queue
> branch:
> 
>    "net: phylink: avoid mac_config calls"
> 
> through to:
> 
>    "net: phylink: rejig link state tracking"

Thanks for the info. I've yet to decide whether or how I'm going to 
attempt this task at the moment - it seems like there have been a lot of 
changes to phylink and other related code lately and it appears to be a 
bit of a task to backport them all into a released kernel version, more 
so back to 5.4 which is the latest LTS kernel which we would ideally 
want to use. So I might end up trying to open-code this more inside the 
driver and eventually switching it to use the shared code when it's 
merged, or maybe just deferring the proper fix for this until the 
infrastructure is more in place in mainline.

> 
>> One concern I have is that there may be things that the PHY subsystem would
>> configure on the device that may need to be replicated in order to get it to
>> actually work - things like setting auto-negotiate enable/disable, the
>> BMCR_ISOLATE bit, etc - is that something that belongs in our mac_config or
>> in the phylink core in phylink_mii_c22_pcs_set_advertisement etc?
> 
> I think some of that is addressed in the above patches, except for
> the isolate bit - do your PHYs come up with the isolate bit set?
> Under what circumstances would you need to set it?

I believe it does come up isolated - from the Xilinx PG047 document for 
the PCS/PMA core:

"Start-up Sequencing
IEEE 802.3-2008 clause 22.2.4.1.6 states that by default, a PHY should 
power up in an isolate state (electrically isolated from the GMII).
If you are using the core with the optional management interface, it is 
necessary to write to the PCS Configuration Register 0 to take the core 
out of the isolate state."

Also, in PG138 for the AXI Ethernet core, under Gigabit Ethernet PCS/PMA 
Management Registers, it has this note:

"When using the 1000BASE-X TEMAC core (C_TYPE = 1 and C_PHY_TYPE = 5), 
set the isolate bit to zero (Control register 0 bit 10). The subsystem 
is not operational until this is completed."

> 
> Let me know how you get on.
> 
> Thanks.
> 

-- 
Robert Hancock
Senior Hardware Designer
SED Systems, a division of Calian Ltd.
Email: hancock@sedsystems.ca

  reply index

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-10 11:54 [PATCH 00/14] net: axienet: Error handling, SGMII and 64-bit DMA fixes Andre Przywara
2020-01-10 11:54 ` [PATCH 01/14] net: xilinx: temac: Relax Kconfig dependencies Andre Przywara
2020-01-10 14:19   ` Radhey Shyam Pandey
2020-01-10 11:54 ` [PATCH 02/14] net: axienet: Propagate failure of DMA descriptor setup Andre Przywara
2020-01-10 14:54   ` Radhey Shyam Pandey
2020-01-10 17:53     ` Radhey Shyam Pandey
2020-01-10 11:54 ` [PATCH 03/14] net: axienet: Fix DMA descriptor cleanup path Andre Przywara
2020-01-10 15:14   ` Radhey Shyam Pandey
2020-01-10 15:43     ` Andre Przywara
2020-01-10 17:05       ` Radhey Shyam Pandey
2020-01-16 18:03         ` Andre Przywara
2020-01-20 18:32           ` Radhey Shyam Pandey
2020-01-10 11:54 ` [PATCH 04/14] net: axienet: Improve DMA error handling Andre Przywara
2020-01-10 15:26   ` Radhey Shyam Pandey
2020-01-10 11:54 ` [PATCH 05/14] net: axienet: Factor out TX descriptor chain cleanup Andre Przywara
2020-01-10 18:04   ` Radhey Shyam Pandey
2020-01-10 11:54 ` [PATCH 06/14] net: axienet: Check for DMA mapping errors Andre Przywara
2020-01-13  5:54   ` Radhey Shyam Pandey
2020-01-10 11:54 ` [PATCH 07/14] net: axienet: Fix SGMII support Andre Przywara
2020-01-10 14:04   ` Andrew Lunn
2020-01-10 14:20     ` Andre Przywara
2020-01-10 14:26       ` Andrew Lunn
2020-01-10 15:04       ` Russell King - ARM Linux admin
2020-01-10 15:22         ` Russell King - ARM Linux admin
2020-01-10 17:04           ` Russell King - ARM Linux admin
2020-01-18 11:22             ` Russell King - ARM Linux admin
2020-01-20 14:50               ` Andre Przywara
2020-01-20 15:45                 ` Russell King - ARM Linux admin
2020-01-27 17:04                   ` Andre Przywara
2020-01-27 17:20                     ` Radhey Shyam Pandey
2020-01-27 18:53                     ` Russell King - ARM Linux admin
2020-04-22  1:45                       ` Xilinx axienet 1000BaseX support (was: Re: [PATCH 07/14] net: axienet: Fix SGMII support) Robert Hancock
2020-04-22  7:51                         ` Russell King - ARM Linux admin
2020-04-22 16:31                           ` Robert Hancock [this message]
2020-04-28 21:59                           ` Xilinx axienet 1000BaseX support Robert Hancock
2020-04-28 23:01                             ` Russell King - ARM Linux admin
2020-04-28 23:51                               ` Robert Hancock
2020-04-29  8:21                                 ` Russell King - ARM Linux admin
2020-01-10 14:58   ` [PATCH 07/14] net: axienet: Fix SGMII support Russell King - ARM Linux admin
2020-01-10 17:32     ` Andre Przywara
2020-01-10 18:05       ` Russell King - ARM Linux admin
2020-01-10 19:33         ` Andrew Lunn
2020-01-10 11:54 ` [PATCH 08/14] net: axienet: Drop MDIO interrupt registers from ethtools dump Andre Przywara
2020-01-13  6:02   ` Radhey Shyam Pandey
2020-01-10 11:54 ` [PATCH 09/14] net: axienet: Add mii-tool support Andre Przywara
2020-01-13  6:12   ` Radhey Shyam Pandey
2020-03-12 11:41     ` Andre Przywara
2020-01-10 11:54 ` [PATCH 10/14] net: axienet: Wrap DMA pointer writes to prepare for 64 bit Andre Przywara
2020-01-10 11:54 ` [PATCH 11/14] net: axienet: Upgrade descriptors to hold 64-bit addresses Andre Przywara
2020-01-14 16:35   ` Radhey Shyam Pandey
2020-01-14 17:29     ` Andre Przywara
2020-01-10 11:54 ` [PATCH 12/14] net: axienet: Autodetect 64-bit DMA capability Andre Przywara
2020-01-10 14:08   ` Andrew Lunn
2020-01-10 14:13     ` Andre Przywara
2020-01-10 14:22       ` Andrew Lunn
2020-01-10 15:08         ` Andre Przywara
2020-01-10 15:22           ` Andrew Lunn
2020-01-14 17:03   ` Radhey Shyam Pandey
2020-01-14 17:41     ` Andre Przywara
2020-01-15  6:02       ` Radhey Shyam Pandey
2020-01-10 11:54 ` [PATCH 13/14] net: axienet: Allow DMA to beyond 4GB Andre Przywara
2020-01-10 11:54 ` [PATCH 14/14] net: axienet: Update devicetree binding documentation Andre Przywara
2020-01-21 21:51   ` Rob Herring
2020-01-24 16:29     ` Andre Przywara
2020-01-27  9:28       ` Radhey Shyam Pandey

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=21ed251b-964f-3f16-1a66-728bbeffa426@sedsystems.ca \
    --to=hancock@sedsystems.ca \
    --cc=andre.przywara@arm.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=michal.simek@xilinx.com \
    --cc=netdev@vger.kernel.org \
    --cc=radhey.shyam.pandey@xilinx.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

Netdev Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/netdev/0 netdev/git/0.git
	git clone --mirror https://lore.kernel.org/netdev/1 netdev/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 netdev netdev/ https://lore.kernel.org/netdev \
		netdev@vger.kernel.org
	public-inbox-index netdev

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.netdev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git