From: Heiner Kallweit <hkallweit1@gmail.com>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: No traffic with Marvell switch and latest linux-next
Date: Sun, 24 Feb 2019 16:39:30 +0100 [thread overview]
Message-ID: <bdca070b-53ea-72ab-4864-e5d36048553f@gmail.com> (raw)
In-Reply-To: <20190224153449.gg3c3fyryztdj3vm@shell.armlinux.org.uk>
On 24.02.2019 16:34, Russell King - ARM Linux admin wrote:
> On Sun, Feb 24, 2019 at 04:28:32PM +0100, Heiner Kallweit wrote:
>> On 24.02.2019 16:15, Russell King - ARM Linux admin wrote:
>>> On Sun, Feb 24, 2019 at 04:04:03PM +0100, Andrew Lunn wrote:
>>>>> I think what's not correct is that phydev->autoneg is set
>>>>> (by phy_device_create) for a fixed link.
>>>>
>>>> Fixed-link tries to emulate auto-neg:
>>>>
>>>> bmsr |= BMSR_LSTATUS | BMSR_ANEGCOMPLETE;
>>>>
>>>> Maybe it needs better emulation of auto-neg?
>>>
>>> Or maybe it needs to represent a fixed-speed PHY by clearing bit 1.3
>>> (BMSR_ANEGCAPABLE). In any case, 0.12 (BMCR_ANENABLE) is not set,
>>> so according to 802.3-2015, we should not be setting 1.5
>>> (BMSR_ANEGCOMPLETE).
>>>
>>> However, swphy does try to emulate autonegotiation - we do have cases
>>> where swphy is used in situations where the speed and duplex are not
>>> fixed. It returns an emulated link partner advertisement for the
>>> current speed, which would suggest that we should set BMCR_ANENABLE.
>>>
>> If we emulate auto-neg, then it's not needed to set the speed bits
>> in BMCR. Also what just comes to my mind, certain speeds like 1000BaseT
>> don't support forced mode. So we may have to go with auto-neg.
>
> Sure.
>
>> To avoid the original issue it should be sufficient to copy
>> supported -> advertising at a suited place.
>
Sorry, seems this wasn't clear enough. I don't mean to change
swphy but the user side.
> Why bother - the software PHY emulation is an emulation to allow
> existing userspace that pre-dates the ethtool API to get some link
> parameters. If we augment the PHY emulation in non-standard ways,
> userspace will need to be updated to handle those non-standard
> ways. If userspace needs to be updated, why not just bite the
> bullet and update to ethtool APIs rather than adding more
> complication through an emulation layer?
>
It's not only userspace. Based on my limited knowledge of DSA this
code also uses e.g. genphy_read_status() with a fixed link.
next prev parent reply other threads:[~2019-02-24 15:39 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-17 15:34 No traffic with Marvell switch and latest linux-next Heiner Kallweit
2019-02-17 15:40 ` Russell King - ARM Linux admin
2019-02-17 15:50 ` Heiner Kallweit
2019-02-17 16:40 ` Heiner Kallweit
2019-02-17 16:57 ` Andrew Lunn
2019-02-17 17:06 ` Heiner Kallweit
2019-02-17 17:10 ` Andrew Lunn
2019-02-18 18:16 ` Heiner Kallweit
2019-02-18 18:21 ` Andrew Lunn
2019-02-23 21:48 ` Heiner Kallweit
2019-02-23 23:42 ` Andrew Lunn
2019-02-24 9:10 ` Heiner Kallweit
2019-02-24 15:04 ` Andrew Lunn
2019-02-24 15:15 ` Russell King - ARM Linux admin
2019-02-24 15:28 ` Heiner Kallweit
2019-02-24 15:34 ` Russell King - ARM Linux admin
2019-02-24 15:39 ` Heiner Kallweit [this message]
2019-02-24 15:49 ` Russell King - ARM Linux admin
2019-02-24 16:32 ` Florian Fainelli
2019-02-24 17:04 ` Andrew Lunn
2019-02-24 21:26 ` Florian Fainelli
2019-02-24 21:42 ` Heiner Kallweit
2019-02-24 15:31 ` Russell King - ARM Linux admin
2019-02-24 17:28 ` Andrew Lunn
2019-02-24 19:41 ` Russell King - ARM Linux admin
2019-02-23 23:55 ` Florian Fainelli
2019-02-17 15:45 ` Andrew Lunn
2019-02-17 15:48 ` Heiner Kallweit
2019-02-17 15:57 ` Andrew Lunn
2019-02-17 16:01 ` Heiner Kallweit
2019-02-17 15:51 ` Andrew Lunn
2019-02-17 15:55 ` Heiner Kallweit
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=bdca070b-53ea-72ab-4864-e5d36048553f@gmail.com \
--to=hkallweit1@gmail.com \
--cc=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).