an.hesselba...@gmail.com; thomas.petazzoni@free-
> electrons.com; Nadav Haklai <nad...@marvell.com>; li...@armlinux.org.uk;
> m...@semihalf.com; Stefan Chulski <stef...@marvell.com>;
> netdev@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: [EXT] Re: [PATCH net-next 0
> In order to safely read/write the PHY, you need to hold the PHY mutex.
> Unless the hardware is very smart, please don't enable this. Let the phylib
> and
> the appropriate PHY driver do the work.
>
>Andrew
Hi Andrew,
This feature work only for Out-of-Band Auto-Negotiation in SGMII
om; gregory.clem...@free-electrons.com;
> thomas.petazz...@free-electrons.com; Nadav Haklai <nad...@marvell.com>;
> li...@armlinux.org.uk; linux-ker...@vger.kernel.org; m...@semihalf.com;
> Stefan Chulski <stef...@marvell.com>; miquel.ray...@free-electrons.com;
> netdev@vger.kern
> > .--- RJ45
> > MVPP2 - 88x3310 PHY
> > `--- SFP+
>
> And the "MVPP2" part can be expended to:
>
> .-- GoP #0 --.
> MVPP2 - GoP #1 Comphy lane #X -- 88x3310
> `-- GoP #2 --'
>
> Thanks!
> Antoine
One more point,
> > Imagine phylib is using the copper Ethernet PHY, but the MAC is using
> > the SFP port. Somebody pulls out the copper cable, phylib says the
> > link is down, turns the carrier off and calls the callback. Not good,
> > since your SFP cable is still plugged in... Ethtool is
> >
> So maybe one confusion was to name them PHY_MODE_10GKR and
> PHY_MODE_SGMII. It could be PHY_MODE_10G and PHY_MODE_1G instead.
1G can be RGMII...
Regards,
Stefan.
> When the cable is connected (there is signal) and the serdes is in sync and AN
> succeeded.
>
> > With SFF/SFP ports, you generally need a gpio line the fibre module
> > can use to indicate if it has link. Fixed-phy has such support, and
> > your link_change function will get called when the
> -Original Message-
> From: Miquel RAYNAL [mailto:miquel.ray...@free-electrons.com]
> Sent: Tuesday, November 07, 2017 12:45 AM
> To: Stefan Chulski <stef...@marvell.com>
> Cc: Thomas Petazzoni <thomas.petazz...@free-electrons.com>; Antoine Tenart
> <
.@ti.com; gregory.clem...@free-electrons.com;
> li...@armlinux.org.uk; m...@semihalf.com; Stefan Chulski
> <stef...@marvell.com>; Yan Markman <ymark...@marvell.com>;
> thomas.petazz...@free-electrons.com; miquel.ray...@free-electrons.com;
> Nadav Haklai <nad...@marvell.com&
rg.uk; m...@semihalf.com; Stefan Chulski
> <stef...@marvell.com>; Yan Markman <ymark...@marvell.com>;
> thomas.petazz...@free-electrons.com; miquel.ray...@free-electrons.com;
> Nadav Haklai <nad...@marvell.com>; netdev@vger.kernel.org; linux-
> ker...@vger.kernel
> > > -Original Message-
> > > Hi Russell,
> > >
> > > Indeed. RGMII MAC behaves same way, although it shouldn't be named
> > > as 'in- band' to be on par with the specifications. Anyway - this
> > > one is rather a stub for being able to work with ACPI, so once the
> > > MDIO bus works
> -Original Message-
> From: Marcin Wojtas [mailto:m...@semihalf.com]
> Sent: Monday, January 01, 2018 12:18 PM
> To: Russell King - ARM Linux <li...@armlinux.org.uk>
> Cc: Stefan Chulski <stef...@marvell.com>; Thomas Petazzoni
> <thomas.petazz...
> Sorry, I find this very confusing.
>
> It seems we have some people telling me that when there's no PHY described
> in DT, we use this link interrupt, and have a functional network interface
> (presumably at whatever speed.)
I give you couple of examples when we have functional network
> > > There is no inband negotiation like there is with 802.3z or SGMII,
> > > so this makes no sense.
> >
> > Oh, that's what I feared. I read some docs but probably will need more
> > :)
> >
> > Anyway, the reason to use in-band negotiation was also to avoid using
> > fixed-link. It would work
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Monday, March 19, 2018 3:08 PM
> To: Stefan Chulski <stef...@marvell.com>
> Cc: Antoine Tenart <antoine.ten...@bootlin.com>; Russell King - ARM Linux
> <li...@armlinux.org.uk>
gory.clem...@bootlin.com;
> ja...@lakedaemon.net; sebastian.hesselba...@gmail.com;
> netdev@vger.kernel.org; linux-ker...@vger.kernel.org;
> thomas.petazz...@bootlin.com; maxime.chevall...@bootlin.com;
> miquel.ray...@bootlin.com; Nadav Haklai <nad...@marvell.com>; Stefan
>
> Hello,
>
> On Fri, 2 Mar 2018 16:40:40 +0100, Antoine Tenart wrote:
> > +static struct {
> > + int pkt_size;
> > + int buf_num;
> > +} mvpp2_pools[MVPP2_BM_POOLS_NUM];
>
> Any reason for not doing:
>
> } mvpp2_pools[MVPP2_BM_POOLS_NUM] = {
> [MVPP2_BM_SHORT] = {
>
> > netdev_err(port->dev, "Invalid pool %d\n", pool);
> > return NULL;
> > }
> > @@ -4596,11 +4604,24 @@ mvpp2_bm_pool_use(struct mvpp2_port
> *port, int
> > pool, int pkt_size) static int mvpp2_swf_bm_pool_init(struct
> > mvpp2_port *port) {
> > int rxq;
> > +
> -Original Message-
> From: Thomas Petazzoni [mailto:thomas.petazz...@bootlin.com]
> Sent: Sunday, March 04, 2018 11:25 AM
> To: Stefan Chulski <stef...@marvell.com>
> Cc: Antoine Tenart <antoine.ten...@bootlin.com>; da...@davemloft.net;
> Yan Markman
> On Fri, 2 Mar 2018 16:40:42 +0100, Antoine Tenart wrote:
>
> > -/* Initialize Tx FIFO's */
> > +/* Initialize Tx FIFO's
> > + * The CP110's total tx-fifo size is 19kB.
> > + * Use large-size 10kB for fast port but 3kB for others.
> > + */
>
> Is there a reason to hardcode 10KB for port 0,
> > To perform checksum in HW, HW obviously should work in store and
> forward mode. Store all frame in TX FIFO and then check checksum.
> > If mtu 1500B, everything fine and all port can do this.
> >
> > If mtu is 9KB and 9KB frame transmitted, Port 0 still can do HW checksum.
> But ports 1 and 2
21 matches
Mail list logo
