netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Marek Vasut <marex@denx.de>
Cc: netdev@vger.kernel.org, f.fainelli@gmail.com
Subject: Re: [PATCH] net: phy: tja11xx: Add TJA11xx PHY driver
Date: Fri, 14 Dec 2018 09:23:13 +0100	[thread overview]
Message-ID: <20181214082313.GA3703@lunn.ch> (raw)
In-Reply-To: <9a2f978a-eee9-e617-da5e-3c4cab55198b@denx.de>

> Hi,
> 
> > Hopefully the config_aneg callback is not called if you don't list
> > autoneg to the .features. The microchip_t1 driver just uses
> > genphy_config_aneg, but if a NULL works, i would prefer that.
> 
> Without the custom config_aneg which sets speed and duplex, I get a
> report claiming the link is at 10/Half , while the link is at 100/Full.
> If I force this in the custom config_aneg, the communication works fine.
> Do you have a hint for me ?

I can make some guesses, but i've never used a PHY which does not have
auto-neg.

If the config_aneg function is being called, i wonder if
AUTONEG_DISABLE == phydev->autoneg is true? 

Is the read_status function doing the right thing? Does it set the
speed, duplex and link up? I'm not sure that is needed, it looks like
phy_sanitize_settings() should do that. 

> Oh, nice. Shouldn't this be basic_t1 , which is already supported ?

I'm getting the various T mixed up. Yes, basic_t1.

> > We also need to think about what we do with the PHY_BASIC_T1_FEATURES
> > macro. Ideally we want to swap that to also make use of a new
> > ethtool_link_mode_bit_indices, but i've no idea at the moment if that
> > will break something.
> 
> Do you mind if I skip this part for now , until I get the driver into
> better shape ?

For the moment, we can postpone that. Lets get the basics working.
What i'm slightly worried about is this could be an ABI change, and
break older systems. If things work correctly such that T1 is selected
without userspace being involved, no need to set the link parameters,
then we are probably safe. We can also ask Microchip to test there T1
driver to make sure it still works.

       Andrew

  reply	other threads:[~2018-12-14  8:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-13  2:01 [PATCH] net: phy: tja11xx: Add TJA11xx PHY driver Marek Vasut
2018-12-13  3:49 ` Yunsheng Lin
2018-12-13  4:06   ` Marek Vasut
2018-12-13  8:38 ` Andrew Lunn
2018-12-13 13:27   ` Marek Vasut
2018-12-13 14:33     ` Andrew Lunn
2018-12-13 16:43       ` Marek Vasut
2018-12-14  8:23         ` Andrew Lunn [this message]
2018-12-14 15:44           ` Marek Vasut
2018-12-14 20:19             ` Andrew Lunn
2018-12-14 20:46               ` Marek Vasut
2018-12-13 18:53 ` Florian Fainelli
2018-12-14 15:26   ` Marek Vasut

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=20181214082313.GA3703@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=f.fainelli@gmail.com \
    --cc=marex@denx.de \
    --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).