> + ether_addr_copy(eth_dest_addr, dest_addr); /* Marvell broadcast or
> switch MAC */
> + ether_addr_copy(eth_src_addr, dev->dev_addr);
> + dsa_tag[0] = 0x40 | (chip->ds->index & 0x1f); /* From_CPU */
> + dsa_tag[1] = 0xfa;
> + dsa_tag[2] = 0xf;
> + dsa_tag[3] = ++chip->rm
> -static int dp83640_hwtstamp(struct phy_device *phydev, struct ifreq *ifr)
> +static int dp83640_hwtstamp(struct mii_timestamper *mii_ts, struct ifreq
> *ifr)
> {
> - struct dp83640_private *dp83640 = phydev->priv;
> + struct dp83640_private *dp83640 =
> + container_of(mii_t
> +struct mii_timestamper *register_mii_timestamper(struct device_node *node,
> + unsigned int port)
> +{
> + struct mii_timestamper *mii_ts = NULL;
> + struct mii_timestamping_desc *desc;
> + struct list_head *this;
> +
> + mutex_lock(&t
n
Reviewed-by: Andrew Lunn
Andrew
> +struct mii_timestamper *of_find_mii_timestamper(struct device_node *node)
> +{
> + struct of_phandle_args arg;
> + int err;
> +
> + err = of_parse_phandle_with_fixed_args(node, "timestamper", 1, 0, &arg);
> +
> + if (err == -ENOENT)
> + return NULL;
> + else if (e
> +static bool ines_match(struct sk_buff *skb, unsigned int ptp_class,
> +struct ines_timestamp *ts);
> +static int ines_rxfifo_read(struct ines_port *port);
> +static u64 ines_rxts64(struct ines_port *port, unsigned int words);
> +static bool ines_timestamp_expired(struct ines_
On Wed, May 22, 2019 at 10:33:29AM +0200, Benjamin Beckmeyer wrote:
> Hi all,
>
> I'm currently working on a custom board with the imx6ull processor and the
> 6390
> switching chip. This is our hardware setup.
>
> - -MAC
> | i.MX
TJA1101 have ability bits in the extended
status register to indicate they support 100BaseT1. However i've not
been able to verify that these bits are actually part of the 802.3
standard. They are not in the 802.3 2018. So at the moment i assume
they are proprietary.
Andrew Lunn (2):
net: phy
Now that there is a link mode for 100BaseT1, use it in
phy_basic_t1_features so T1 PHY drivers will indicate this mode via
the Ethtool API.
Signed-off-by: Andrew Lunn
---
drivers/net/phy/phy_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy
Add link modes for 100Mbps and 1Gbps over a single pair.
Signed-off-by: Andrew Lunn
---
drivers/net/phy/phy-core.c | 4 +++-
include/uapi/linux/ethtool.h | 2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
index
s were silently converted into
> DP83867_CLK_O_SEL_REF_CLK. Change this so they generate an error.
>
> Cc: Andrew Lunn
> Cc: Florian Fainelli
> Cc: Heiner Kallweit
> Signed-off-by: Trent Piepho
Reviewed-by: Andrew Lunn
Andrew
avior, I've kept it the same and documented
> it. No delay will most likely not work and will break ethernet on any
> board using "rgmii" mode. If the board is strapped to have a delay and
> is configured to use "rgmii" mode a warning is generated that "rg
On Wed, May 22, 2019 at 06:43:24PM +, Trent Piepho wrote:
> The variables used to store u32 DT properties were signed ints. This
> doesn't work properly if the value of the property were to overflow.
> Use unsigned variables so this doesn't happen.
>
> Cc: Andrew Lun
On Wed, May 22, 2019 at 06:43:25PM +, Trent Piepho wrote:
> The driver would only set the IO impedance value when RGMII internal
> delays were enabled. There is no reason for this. Move the IO
> impedance block out of the RGMII delay block.
>
> Cc: Andrew Lunn
> Cc: Flor
On Wed, May 22, 2019 at 06:43:26PM +, Trent Piepho wrote:
> Insure property is in valid range and fail when reading DT if it is not.
> Also add error message for existing failure if required property is not
> present.
>
> Cc: Andrew Lunn
> Cc: Florian Fainelli
>
On Wed, May 22, 2019 at 06:43:27PM +, Trent Piepho wrote:
> This was being done in config the first time the phy was configured.
> Should be in the probe method.
>
> Cc: Andrew Lunn
> Cc: Florian Fainelli
> Cc: Heiner Kallweit
> Signed-off-by: Trent Piepho
Rev
Mark Rutland
> Signed-off-by: Trent Piepho
Reviewed-by: Andrew Lunn
Andrew
be left as is if the property
> is omitted.
>
> Cc: Rob Herring
> Cc: Mark Rutland
> Signed-off-by: Trent Piepho
Reviewed-by: Andrew Lunn
Andrew
On Wed, May 22, 2019 at 09:58:32PM +0200, Heiner Kallweit wrote:
> So far we didn't support mode USXGMII, and in order to not break the
> two Freescale boards mode XGMII was accepted for the AQR107 family
> even though it doesn't support XGMII. Add USXGMII support to the
> Aquantia PHY driver and c
On Wed, May 22, 2019 at 11:48:06PM +0200, Marek Vasut wrote:
> On 5/18/19 4:14 PM, Andrew Lunn wrote:
> > On Sat, May 18, 2019 at 01:51:23AM +0200, Marek Vasut wrote:
> >> Add driver for the NXP TJA1100 and TJA1101 PHYs. These PHYs are special
> >> BroadRReach 100Bas
> thanks for your reply. You're right, both PHYs are 10/100.
>
> I already added a fixed-link like this:
>
> port@0 {
> reg = <0>;
> label = "cpu";
> ethernet = <&fec1>;
>
On Thu, May 23, 2019 at 11:56:45AM +0200, Maxime Ripard wrote:
> The networking PHYs have a number of available device tree properties that
> can be used in their device tree node. Add a YAML schemas for those.
>
> Signed-off-by: Maxime Ripard
> ---
> Documentation/devicetree/bindings/net/ethern
> > +link-gpios:
> > + description:
> > +GPIO to determine if the link is up
>
> Only 1?
Hi Rob
Yes, only one.
Andrew
On Thu, May 23, 2019 at 08:07:56PM +0200, Heiner Kallweit wrote:
> Add new interface mode USXGMII to binding documentation.
>
> Signed-off-by: Heiner Kallweit
Reviewed-by: Andrew Lunn
Andrew
> and warn if XGMII mode is set.
>
> v2:
> - add warning if XGMII mode is set
>
> Signed-off-by: Heiner Kallweit
Reviewed-by: Andrew Lunn
Andrew
On Thu, May 23, 2019 at 01:20:38AM +, Ioana Ciornei wrote:
> A prerequisite for PHYLIB to work in the absence of a struct net_device
> is to not access pointers to it.
>
> Changes are needed in the following areas:
>
> - Printing: In some places netdev_err was replaced with phydev_err.
>
>
> > Hi Ioana
> >
> > Looking at the functions changed here, they seem to be related to
> > phy_attach(),
> > phy_connect(), and phy_detach() etc. Is the intention you can call these
> > functions and pass a NULL pointer for the net_device?
> >
> > Andrew
>
> Hi Andrew,
>
> Yes, the intenti
> Hi Florian,
>
> Yes we could, but since most of the adjust_link -> phylink_mac_ops
> changes appear trivial, and we have the knowledge behind b53 right
> here, can't we just migrate everything in the next patchset and remove
> adjust_link altogether from DSA?
I agree with Florian, we either nee
On Fri, May 24, 2019 at 11:25:03AM +1000, Greg Ungerer wrote:
> Hi Andrew,
>
> I have a problem with a Marvell 6390 switch that I have bisected
> back to commit 7cbbee050c95, "[PATCH] net: dsa: mv88e6xxx: Set correct
> interface mode for CPU/DSA ports".
>
> I have a Marvell 380 SoC based platform
On Fri, May 24, 2019 at 06:20:16PM +0200, Linus Walleij wrote:
> The IXP4xx driver was initializing the MDIO bus before even
> probing, in the callbacks supposed to be used for setting up
> the module itself, and with the side effect of trying to
> register the MDIO bus as soon as this module was l
> @@ -1481,8 +1478,8 @@ static int ixp4xx_eth_probe(struct platform_device
> *pdev)
> if ((err = register_netdev(ndev)))
> goto err_phy_dis;
>
> - printk(KERN_INFO "%s: MII PHY %i on %s\n", ndev->name, plat->phy,
> -npe_name(port->npe));
> + dev_info(dev,
On Fri, May 24, 2019 at 06:20:19PM +0200, Linus Walleij wrote:
> In order to probe this ethernet interface from the device tree
> all physical MMIO regions must be passed as resources. Begin
> this rewrite by first passing the port base address as a
> resource for all platforms using this driver, r
> +description: |
> + The Intel IXP4xx ethernet makes use of the IXP4xx NPE (Network
> + Processing Engine) and the IXP4xx Queue Mangager to process
> + the ethernet frames. It can optionally contain an MDIO bus to
> + talk to PHYs.
Hi Linus
You mention MDIO and PHYs, but the code is not ther
> + /* FIXME: get from MDIO handle */
> + ret = of_property_read_u32(np, "phy", &val);
> + if (ret) {
> + dev_err(dev, "no phy\n");
> + return NULL;
> + }
> + plat->phy = val;
Hi Linus
You might want to work on the MDIO code first. It is O.K. to do
some
> My hardware has the CPU port on 9, and it is SGMII. The existing working
> devicetree setup I used is:
>
>port@9 {
> reg = <9>;
> label = "cpu";
> ethernet = <ð0>;
>
> >> /* Built-in 10/100 Ethernet MAC interfaces */
> >>+static struct resource fsg_eth_npeb_resources[] = {
> >>+ {
> >>+ .start = IXP4XX_EthB_BASE_PHYS,
> >>+ .end= IXP4XX_EthB_BASE_PHYS + 0x0fff,
> >
> >Hi Linus
> >
> >It is a long time since i did reso
On Mon, May 27, 2019 at 10:17:50PM -0700, Richard Cochran wrote:
> On Wed, May 22, 2019 at 02:58:23AM +0200, Andrew Lunn wrote:
> > > -static int dp83640_hwtstamp(struct phy_device *phydev, struct ifreq *ifr)
> > > +static int dp83640_hwtstamp(struct mii_timestamper
gned-off-by: Russell King
Fixes: 20b2af32ff3f ("net: phy: add Marvell Alaska X 88X3310 10Gigabit PHY
support")
Reviewed-by: Andrew Lunn
Andrew
On Tue, May 28, 2019 at 10:57:18AM +0100, Russell King wrote:
> The netdev used in the phylink ioctl emulation is never used, so let's
> remove it.
>
> Signed-off-by: Russell King
Reviewed-by: Andrew Lunn
Andrew
On Tue, May 28, 2019 at 10:57:34AM +0100, Russell King wrote:
> Add attach and detach methods for SFP buses, which will allow us to get
> rid of the netdev storage in sfp-bus.
>
> Signed-off-by: Russell King
Reviewed-by: Andrew Lunn
Andrew
On Tue, May 28, 2019 at 10:57:39AM +0100, Russell King wrote:
> The sfp-bus code now no longer has any use for the network device
> structure, so remove its use.
>
> Signed-off-by: Russell King
Reviewed-by: Andrew Lunn
Andrew
> > Hi Russell,
> >
> > I find the SIOCGMIIREG/SIOCGMIIPHY ioctls useful for C45 just as much
> > as they are for C22, but I think the way they work is a big hack and
> > for that reason they're less than useful when you need them most.
> > These ioctls work by hijacking the MDIO bus driver of a P
ff-by: Ioana Ciornei
> Suggested-by: Andrew Lunn
Reviewed-by: Andrew Lunn
Andrew
ff-by: Ioana Ciornei
> Suggested-by: Andrew Lunn
I should actually say, once you fix the sparse warnings, you can add:
Reviewed-by: Andrew Lunn
Andrew
> One question: are we happy with failing the probe like this, or would it
> be better to allow the probe to suceed?
>
> As has been pointed out in the C45 MII access patch, we need the PHY
> to bind to the network driver for the MII bus to be accessible to
> userspace, so if we're going to have u
sually succeed after all of
> the resources that it requires have been registered.
>
> Signed-off-by: Thierry Reding
Reviewed-by: Andrew Lunn
Andrew
On Tue, May 28, 2019 at 06:43:46PM +0200, Heiner Kallweit wrote:
> MAC on the GBit versions supports 1000/Full only, however the PHY
> partially claims to support 1000/Half. So let's explicitly remove
> this mode.
>
> Signed-off-by: Heiner Kallweit
Reviewed-by: Andrew Lunn
Andrew
> phydev = dsa_port_get_phy_device(dp);
> if (!phydev)
> return 0;
>
> I don't see how this method is sane either.
If i remember correctly, the thinking was, you can get away without
the PHY, at least during bring up of a new switch/board. So don't
consider this a fatal error. N
> @@ -423,18 +434,41 @@ static int dsa_tree_setup_switches(struct
> dsa_switch_tree *dst)
>
> err = dsa_switch_setup(ds);
> if (err)
> - return err;
> + goto setup_switch_err;
Minor nit pick.
All the other labels you add are e
called. This leads to a BUG_ON() complaining about the fact that it's
> trying to free an MDIO bus that's still registered.
>
> Add proper error handling in all functions branching from
> dsa_tree_setup().
>
> Signed-off-by: Ioana Ciornei
> Reported-by: kernel test robot
Reviewed-by: Andrew Lunn
Andrew
> Here's the fuller patch for what I'm suggesting:
>
> drivers/net/phy/marvell10g.c | 25 -
> 1 file changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
> index 754cde873dde..86333d98b384 100644
> --- a/dr
Sync ethtool-copy.h with linux-next from 22/05/2019. This provides
access to the new link modes for 100BaseT1 and 1000BaseT1.
Signed-off-by: Andrew Lunn
---
ethtool-copy.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index
Import the latest ethtool.h and add two new links modes.
Andrew Lunn (2):
ethtool: sync ethtool-copy.h with linux-next from 30/05/2019
ethtool: Add 100BaseT1 and 1000BaseT1 link modes
ethtool-copy.h | 7 ++-
ethtool.c | 6 ++
2 files changed, 12 insertions(+), 1 deletion
The kernel can now indicate if the PHY supports operating over a
single pair at 100Mbps or 1000Mbps.
Signed-off-by: Andrew Lunn
---
ethtool.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/ethtool.c b/ethtool.c
index 66a907edd97b..35158939e04c 100644
--- a/ethtool.c
+++ b/ethtool.c
ture threshold is exceeded. We may be interested in such
> interrupts also if the phylib state machine isn't started.
> Therefore move enabling interrupts to phy_request_interrupt().
>
> v2:
> - patch added to series
>
> Signed-off-by: Heiner Kallweit
Reviewed-by: Andrew Lunn
Andrew
> > @@ -634,10 +636,14 @@ static void dump_link_caps(const char *prefix, const
> > char *an_prefix,
> > "100baseT/Half" },
> > { 1, ETHTOOL_LINK_MODE_100baseT_Full_BIT,
> > "100baseT/Full" },
> > + { 1, ETHTOOL_LINK_MODE_100baseT1_Full_BIT,
> > +
On Fri, May 31, 2019 at 10:47:27AM +0300, Nikita Yushchenko wrote:
> This change allows phytool [1] and similar tools to read and write C45 phy
> registers from userspace.
>
> This is useful for debugging and for porting vendor phy diagnostics tools.
>
> [1] https://github.com/wkz/phytool
Hi Nik
> That's not just theory. The Broadcom BCM54811 PHY supports both
> 100/1000baseT, as well as 100baseT1.
Hi Lucus
There does not appear to be a driver for it, which is why i've not
seen it, nor have we had this conversation before.
Do you have a driver to submit?
Andrew
ac_link_down() always corresponding to a mac_link_up() call for the
> same interface mode.
>
> Signed-off-by: Russell King
Reviewed-by: Andrew Lunn
Andrew
Import the latest ethtool.h and add two new links modes.
v2:
Move the new speeds to the end of the all_advertised_modes_bits[].
Remove the same_line bit for the new moved
Add the new modes to the man page.
Andrew Lunn (2):
ethtool: sync ethtool-copy.h with linux-next from 30/05/2019
ethtool
The kernel can now indicate if the PHY supports operating over a
single pair at 100Mbps or 1000Mbps.
Signed-off-by: Andrew Lunn
---
ethtool.8.in | 2 ++
ethtool.c| 6 ++
2 files changed, 8 insertions(+)
diff --git a/ethtool.8.in b/ethtool.8.in
index 430d11b915af..6af63455c636 100644
Sync ethtool-copy.h with linux-next from 22/05/2019. This provides
access to the new link modes for 100BaseT1 and 1000BaseT1.
Signed-off-by: Andrew Lunn
---
ethtool-copy.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index
> Reviewed-by: Michal Kubecek
>
> BtW, this differs from the file "make headers_install" produces in
> net-next but only in white space so that it doesn't really matter and it
> gets sorted in a future sync.
Yes, there is something odd going on. It looks like two tabs have been
converted to spac
On Fri, May 31, 2019 at 01:15:49PM -0600, Robert Hancock wrote:
> This adds a driver for the PHY device implemented in the Xilinx PCS/PMA
> Core logic. Aside from being a generic gigabit PHY, it includes an
> important register setting to disable the PHY isolation bit, which is
> required for the P
Robert
Please make sure you Cc: PHY patches to the PHY maintainers.
Heiner, this one is for you.
Andrew
On Fri, May 31, 2019 at 01:15:50PM -0600, Robert Hancock wrote:
> It is possible that scheduled work started by the PHY driver is still
> outstanding when phy_device_remove is called
Hi Robert
I think you can split this into three patches, in order to make it
easier to review:
IO accessors
skb in the control block
MDIO changes.
> static inline u32 axienet_ior(struct axienet_local *lp, off_t offset)
> {
> - return in_be32(lp->regs + offset);
> +#ifdef CONFIG_MICROBLAZE
On Fri, May 31, 2019 at 12:15:34PM -0600, Robert Hancock wrote:
> -Allow specifying the MDIO clock divisor explicitly in the device tree,
> rather than always detecting it from the CPU clock which only works on
> the MicroBlaze platform.
>
> -Centralize all MDIO handling in xilinx_axienet_mdio.c
>
Robert Hancock
Reviewed-by: Andrew Lunn
Andrew
On Fri, May 31, 2019 at 05:28:45PM -0600, Robert Hancock wrote:
> On 2019-05-31 3:10 p.m., Andrew Lunn wrote:
> >> static inline u32 axienet_ior(struct axienet_local *lp, off_t offset)
> >> {
> >> - return in_be32(lp->regs + offset);
> >> +#ifdef CONFI
On Fri, May 31, 2019 at 09:22:16PM -0600, [email protected] wrote:
> > On 31.05.2019 22:54, Andrew Lunn wrote:
> >>> It is possible that scheduled work started by the PHY driver is still
> >>> outstanding when phy_device_remove is called if the PHY was ini
On Sat, Jun 01, 2019 at 01:37:34PM +0300, Vladimir Oltean wrote:
> The code in sja1105_adjust_port_config relies on the fact that an
> invalid link speed is detected by sja1105_get_speed_cfg and returned as
> -EINVAL. However storing this into an enum that only has positive
> members will cast it
On Sat, Jun 01, 2019 at 11:30:16PM +0300, Vladimir Oltean wrote:
> On Sat, 1 Jun 2019 at 19:03, Andrew Lunn wrote:
> >
> > On Sat, Jun 01, 2019 at 01:37:34PM +0300, Vladimir Oltean wrote:
> > > The code in sja1105_adjust_port_config relies on the fact that an
> > &g
for NXP SJA1105 5-port L2
> switch")
> Signed-off-by: Vladimir Oltean
> Suggested-by: Andrew Lunn
> ---
> drivers/net/dsa/sja1105/sja1105_main.c | 32 +-
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net
> Hi Andrew,
>
> If I made the change you're suggesting, I would need to replace 0 with
> SPEED_UNKNOWN and thus I would conflict with this net-next change:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=af7cd0366ee994e8b35985d407261dc0ed9dfb4d
>
> I think it's
ds with a NACK and a STOP instead of an acknowledge."
>
> We must avoid breaking a read across a 16-bit quantity in the diagnostic
> page, thankfully all 16-bit quantities in that page are naturally
> aligned.
>
> Signed-off-by: Russell King
Reviewed-by: Andrew Lunn
Andrew
> Any "SmartNIC" vendor has temptation of uAPI-level hand off to the
> firmware (including my employer), we all run pretty beefy processors
> inside "the NIC" after all. The device centric ethtool configuration
> can be implemented by just forwarding the uAPI structures as they are
> to the FW. I
;
Hi Robert
Is the memory for the descriptor non-cachable? I expect so. You may
get slightly better performance if you were to keep an shadow array in
normal RAM. But this is O.K. as well.
Reviewed-by: Andrew Lunn
Andrew
On Mon, Jun 03, 2019 at 03:57:02PM -0600, Robert Hancock wrote:
> The MDIO bus for this driver was being named using the result of
> of_address_to_resource on a node which may not have any resource on it,
> but the return value of that call was not checked so it was using some
> random value in the
On Mon, Jun 03, 2019 at 03:57:03PM -0600, Robert Hancock wrote:
> This driver should now build on (at least) X86 and ARM platforms, so add
> them as supported platforms for the driver in Kconfig.
>
> Signed-off-by: Robert Hancock
Reviewed-by: Andrew Lunn
Andrew
On Mon, Jun 03, 2019 at 03:57:04PM -0600, Robert Hancock wrote:
> This driver was previously always calculating the MDIO clock divisor
> (from AXI bus clock to MDIO bus clock) based on the CPU clock frequency,
> but that simplistic method only works on the MicroBlaze platform. This
> really has to
; Signed-off-by: Robert Hancock
Reviewed-by: Andrew Lunn
Andrew
On Mon, Jun 03, 2019 at 03:57:06PM -0600, Robert Hancock wrote:
> The MDIO clock divisor register setting was only applied on the initial
> startup when the driver was loaded. However, this setting is cleared
> when the device is reset, such as would occur when the interface was
> taken down and br
On Mon, Jun 03, 2019 at 03:57:07PM -0600, Robert Hancock wrote:
> The Xilinx DMA blocks each have their own reset register, but they both
> reset the entire DMA engine, so only one of them needs to be reset.
>
> Also, when stopping the device, we need to not just command the DMA
> blocks to stop,
On Tue, Jun 04, 2019 at 08:10:50AM +0200, Heiner Kallweit wrote:
> We have a Xilinx GBit PHY that doesn't have BMSR_ESTATEN set
> (what violates the Clause 22 standard). Instead of having the PHY
> driver to implement almost identical copies of few generic functions
> let's add a flag for this quir
On Tue, Jun 04, 2019 at 03:07:25PM +0200, Benjamin Beckmeyer wrote:
> Hi all,
>
> I'm working on a custom board with a 88E6321 and an i.MX28. Port 5 is
> directly connected per RMII to the CPU.
> The switch is running in CPU attached mode. On Port 2 and 6 we have 2
> external Micrel KSZ9031 PHY
> So it seems like what is missing is the ability of genphy_config_init to
> detect the bits in the extended status register for 1000Base-X and add
> the corresponding mode flags. It appears bit 15 for 1000Base-X full
> duplex is standardized in 802.3 Clause 22, so I would expect Linux
> should be
> If I remember the Marvell specs correctly, there was some bit to switch the
> complete register set to fibre mode.
Hi Heiner
The Marvell PHY has a second page for Fibre. It mostly mirrors the
normal registers, and you need to look at both pages to determine if
copper or fibre has link, etc. Fib
On Tue, Jun 04, 2019 at 10:58:41PM +0300, Vladimir Oltean wrote:
> Hi,
>
> I've been wondering what is the correct approach to cut the Ethernet link
> when the user requests it to be administratively down (aka ip link set dev
> eth0 down).
> Most of the Ethernet drivers simply call phy_stop or the
> But now the second question: between a phy_connect and a phy_start,
> shouldn't the PHY be suspended too? Experimentally it looks like it
> still isn't.
This is not always clear cut. Doing auto-neg is slow. Some systems
want to get networking going as fast as possible. The PHY can be
strapped so
> For a switch, there are four stages, not two:
Agreed.
> 1. The out-of-reset state, which from what I've seen seems to be to
>behave like a dumb switch.
For the Marvell Switches, there is a pin you can strap to control
this, NO_CPU. If you say there is no CPU, it will power up in dumb
swit
API
> in order to provide support for SFP modules.
>
> Changes since v2:
> -Fixed MDIO bus parent detection as suggested by Andrew Lunn
> -Use clock framework to detect AXI bus clock rather than having to explicitly
> specify MDIO clock divisor
> -Hold MDIO bus lock around dev
rt
Please add this mdio node to the binding documentation as an optional
property.
Reviewed-by: Andrew Lunn
Andrew
On Tue, Jun 04, 2019 at 03:43:32PM -0600, Robert Hancock wrote:
> This driver was previously always calculating the MDIO clock divisor
> (from AXI bus clock to MDIO bus clock) based on the CPU clock frequency,
> assuming that it is the same as the AXI bus frequency, but that
> simplistic method onl
> - axienet_iow(lp, XAE_MDIO_MC_OFFSET,
> - (mdio_mcreg & (~XAE_MDIO_MC_MDIOEN_MASK)));
> + mutex_lock(&lp->mii_bus->mdio_lock);
> + axienet_mdio_disable(lp);
I wonder if it would look better structured if the lock was in
axienet_mdio_disable() and the unlock in axienet
> I got the devicetree from somebody that is why German is in it. But
> first I wanted to get it running before I tidy it up. The switch is
> strapped to single mode (so I can read SMI addresses 0x10-0x16 and
> 0x1b-0x1e directly).
Hi Benjamin
You have miss-understood what reg means.
There are
On Wed, Jun 05, 2019 at 11:43:16AM +0100, Russell King wrote:
> Allow the PHY to probe when there is no firmware, but do not allow the
> link to come up by forcing the PHY state to PHY_HALTED in a similar way
> to phy_error().
>
> Signed-off-by: Russell King
Reviewed-
> Here is my device tree
>
> mdio {
> #address-cells = <1>;
> #size-cells = <0>;
>
> switch0: switch0@0 {
> compatible = "marvell,mv88e6085";
> reg = <0x0>;
> pinctrl-0 = <&lcd
> I removed all phy-handle for the internal ports and in the mdio part
> is only port 2 and 6 by now. But the Serdes ports are still not be
> recognized. So maybe there is still something wrong?
What do you mean by SERDES? Do you mean they are connected to an SFP
cage? If so, you need to add an S
On Thu, Jun 06, 2019 at 08:05:31AM +0200, Heiner Kallweit wrote:
> On 06.06.2019 03:42, David Miller wrote:
> > From: Robert Hancock
> > Date: Tue, 4 Jun 2019 16:15:01 -0600
> >
> >> Add 1000BaseX to the link modes which are detected based on the
> >> MII_ESTATUS register as per 802.3 Clause 22.
> This link notifier change also screws up my long-standing patches
> to add support for SFP for the PHYs on Macchiatobin which I was
> going to post next.
Hi Russell
Is that with the SFP hanging off the Marvell 10G PHY? We are seeing
that sort of chain more often, so it is something i would like
1 - 100 of 7453 matches
Mail list logo
