...
yes I've just noticed Russell's patch mentioning mvneta,
and found the phylink patches to mvneta in net-next (until then I'd
been reading the vanilla, where they haven't landed yet).
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tre
e/drivers/net/ethernet/marvell/mvneta.c
> Looking at the i2c dumps, and some past dumps from the igb driver,
> it's dawning on me on me that the igb driver, without much hacking,
> would try to read the PHY ID from the DMI/DDM block - a case which
> the drivers/net/phy/mdio-i2c.c specifically avoids :-)
It avoids if for a very good r
> I was also wondering if someone has written any kernel-space support
> for the SFP's. Sure enough, I've found lots of code by Russell King
> under drivers/net/phy. I started reading from sfp.c, went on to
> sfp-bus.c, next the phylink stuff... Answers lots of my questions.
> Clearly someone h
On 21 Mar 2018 at 11:47, Andrew Lunn , net...@vger.ker wrote:
> Another question is, how to write the driver's initialization
> sequence, for it to correctly decide if the SFP is SERDES or SGMII or
> what. I could just follow the config obtained from the i210 EEPROM.
> Alternatively, or somehow c
Just another follow-up:
With specs on SFP MSA, DDM/DMI and MII in hand, I have determined:
0x50 (a.k.a. 0xA0 in SFP MSA spec) = the module's SPD "EEPROM"
0x51 (a.k.a. 0xA2 in SFP MSA spec) = diagnostics (DMI/DDM)
0x56 = MII management access over i2C
Using eeprog (reading each offset twice to get
On 20 Mar 2018 at 13:09, Andrew Lunn wrote:
> > i2cdetect has found three i2c slaves (identical layout in both SFP's)
> > at addresses 0x50, 0x51 and 0x56.
> > What are they? EEPROM, DDM and "MDIO over i2c" ?
> > The SFP's likely lack a proper SFP MSA data structure.
>
> 0x50 and 0x51 are EEPROM
> i2cdetect has found three i2c slaves (identical layout in both SFP's)
> at addresses 0x50, 0x51 and 0x56.
> What are they? EEPROM, DDM and "MDIO over i2c" ?
> The SFP's likely lack a proper SFP MSA data structure.
0x50 and 0x51 are EEPROM like. See drivers/net/phy/sfp.c. The standard
at24 EEPRO
I've taken a look inside the two SFP's.
http://support.fccps.cz/download/adv/frr/ptp/inside_sfps.zip
The uglier, bigger and likely older model (my SFP#2) contains two
PCB's sandwiched, and the key chips are inside the sandwich.
Thus, the photoes don't show much.
The sexier SFP#1 = the one with t
> I'm not getting an ACK from the SFP, probably because I've got the
> address and offset wrong and because I'd better use indirect access.
> There's some more work awaiting me...
Try address 0x50.
i2detect will probe all addresses for you, if you have a standard
Linux i2c bus.
Andrew
> > > Right now I've modded igb_init_i2c() to engage the bit-banging
> > > i2c driver for the i210 too
> >
> > I don't think that will work. The datasheet for the i210 talks about
> > two registers for I2C/MDIO which are not bit-banging. Only the i350
> > uses bit-banging.
> >
> From the i210 dat
On 17 Mar 2018 at 15:50, Andrew Lunn wrote:
> On Sat, Mar 17, 2018 at 08:39:00AM +0100, Frantisek Rysanek wrote:
> > On 16 Mar 2018 at 22:02, Andrew Lunn wrote:
> > >
> > > Does ethtool -m show anything useful?
> > >
> >
> > Not much. "unsupported".
>
> static int igb_get_module_info(struct net
On Sat, Mar 17, 2018 at 08:39:00AM +0100, Frantisek Rysanek wrote:
> On 16 Mar 2018 at 22:02, Andrew Lunn wrote:
> >
> > Does ethtool -m show anything useful?
> >
>
> Not much. "unsupported".
static int igb_get_module_info(struct net_device *netdev,
struct ethtool
On 16 Mar 2018 at 22:02, Andrew Lunn wrote:
>
> Does ethtool -m show anything useful?
>
Not much. "unsupported".
Probably the ioctl() is not implemented or something, I haven't
investigated. Maybe I should.
Right now I've modded igb_init_i2c() to engage the bit-banging
i2c driver for the i210
> The DeLock board is this beauty:
> http://www.delock.de/produkte/G_89481/merkmale.html?setLanguage=en
> DeLock techsupport were so kind as to provide me with a schematic
> snippet, showing the wiring of the i210 fiber SKU's dedicated
> I2C/MDIO pins to the SFP socket's standard I2C pins. There
On 16 Mar 2018 at 19:42, Andrew Lunn wrote:
> Hi Frantisek
>
> This seems a bit odd. The SFP cage only has i2c, not MDIO. It is
> possible to carry MDIO over i2c, which is what is done when the SFP
> module is copper, not fibre. But you are doing 100Base-FX, so fibre.
>
> The BCM5461 is a copper
On Fri, Mar 16, 2018 at 05:48:20PM +0100, Frantisek Rysanek wrote:
> Dear polite inhabitants of the "netdev" mailing list,
>
> this is for a skunkworks project at the fringe of my job...
> More of a DIY hobby thing :-) I'm tinkering and having fun.
>
> The wizards from linux-ptp have taught me ho
Dear polite inhabitants of the "netdev" mailing list,
this is for a skunkworks project at the fringe of my job...
More of a DIY hobby thing :-) I'm tinkering and having fun.
The wizards from linux-ptp have taught me how to use the i210 for
precise timestamping, which works fine at all copper spe
17 matches
Mail list logo
