netdev - Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5AACC614.18709.335BD813@Frantisek.Rysanek.post.cz>
Date:   Sat, 17 Mar 2018 08:39:00 +0100
From:   "Frantisek Rysanek" <Frantisek.Rysanek@...t.cz>
To:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

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 too, if SGMII active and external MDIO off.
Which gets me a /dev/i2c-8 created (with modprobe i2c-dev),
and I'm trying an 8bit read transaction on slave addresses from 0 to 
127, which yields no responses.
Maybe the 8bit transaction is not the right way to do it,
maybe I should use indirect access, I'm just a little scared of that,
I'd hate to reprogram the SFP inadvertently :-)

I know that I'd have to pipe this bit-banging stuff into the Ethtool 
ioctl handling stuff, to get it to work via ethtool -m. 

The way I have hacked the driver, I've noticed that if I enable the 
BB mode in I2CPARAMS, the driver won't load completely,
because the HW-based I2C controller is defunct, and the driver gets 
nothing at all when trying to read the PHY_ID.
But if I first leave I2CPARAMS configured for HW-driven I2C,
load the driver, and then switch I2CPARAMS to BB mode,
I get the bit-banged I2C device loaded and the bit-twiddling
callbacks in igb.ko do get called.

I'm currently using devmem2 to tweak I2CPARAMS:
devmem2 0xF750102C w 0x00007646
devmem2 0xF750102C w 0x00007746
I should probably decide which way to go, HW i2c or SW i2c :-)
and mod the driver accordingly.

I'm currently looking at the bb i2c callbacks in igb.ko with some 
suspicion... they seem a little too coarse to me. I'd expect some 
finer timing around "tri-state the pin, wait a few us and only then 
read the input". E.g. when checking for an ACK from the slave.

I'm not sure if I should "take the i210 HW semaphore" while
bit-banging the i2c stuff. Currently the BB code doesn't do that.
Not sure if this prevents the bits from getting in and out
at the PCB traces. Will have to check on monday.

I've also noticed the drivers/net/phy/mdio-i2c.c .
Maybe I should engage this instead or on top of the generic I2C 
bit-banging framework :-)

=> I haven't tried all my ideas yet and will have to stop tweaking 
for now... I'm playing with this remotely at home via SSH, 
so I don't see the 'scope (if anything happens on the bus in the BB 
mode). And it's time for breakfast :-)

Frank