Re: [PATCH net 6/8] net: mscc: ocelot: make struct ocelot_stat_layout array indexable

[Colin Foster <colin.foster@in-advantage.com>]

On Wed, Aug 17, 2022 at 10:03:51PM +0000, Vladimir Oltean wrote:
> On Wed, Aug 17, 2022 at 01:47:07PM -0700, Colin Foster wrote:
> > > > Tangentially related: I'm having a heck of a time getting the QSGMII
> > > > connection to the VSC8514 working correctly. I plan to write a tool to
> > > > print out human-readable register names. Am I right to assume this is
> > > > the job of a userspace application, translating the output of
> > > > /sys/kernel/debug/regmap/ reads to their datasheet-friendly names, and
> > > > not something that belongs in some sort of sysfs interface? I took a
> > > > peek at mv88e6xxx_dump but it didn't seem to be what I was looking for.
> > > 
> > > Why is the mv88e6xxx_dump kind of program (using devlink regions) not
> > > what you're looking for?
> > 
> > I suspect the issue I'm seeing is that there's something wrong with the
> > HSIO registers that control the QSGMII interface between the 7512 and
> > the 8514. Possibly something with PLL configuration / calibration? I
> > don't really know yet, and bouncing between the source
> > (ocelot_vsc7514.c, {felix,ocelot-ext}.c, phy-ocelot-serdes.c), the
> > reference design software, and the datasheet is slowing me down quite a
> > bit. Unless I am mistaken, it feels like the problems I'm chasing down
> > are at the register <> datasheet interface and not something exposed
> > through any existing interfaces.
> 
> So you mean you suspect that the HSIO register definitions are somehow
> wrong? You mean the phy-ocelot-serdes.c driver seems to behave strangely
> in a way that could possibly indicate it's accessing the wrong stuff?
> Do you have any indication that this is the case? I'm not familiar at
> all with blocks that weren't instantiated on NXP hardware (we have our
> own SERDES), and I see you're already monitoring the right source files,
> so I'm afraid there isn't much that I can help you with.

So I was crafting my response with an explanation of how I'd gotten to
where I was (starting in the footsteps of ocelot_vsc7512.c). Of course,
while trying to explain that, a couple things jumped out at me to try.

Long story short, phylink_ops wasn't getting invoked by anything. In
ocelot_vsc7512.c they get invoked by the net_device (I think) but in
ocelot-ext, while they were registered to the phylink, only the
felix pcs_config (and other phylink_pcs_ops). I had all the pieces,
but just didn't tie them all together.

So my current status is there's at least some full communication between
the 7512 and the 8514 to the external ports. I'll do some more thorough
testing as well. Now that I have more than 3 ports, I should be able to
run more of the elaborate kernel test scenarios. But also I'll have to
do a lot more validation and testing.


Thanks for the hints Vladimir! And for being helpful in this rubber-duck
debugging session :-)

> 
> > I plan to get some internal support on that front that can hopefully
> > point me in the right direction, or find what I have set up incorrectly.
> > Otherwise it probably doesn't even make sense to send out anything for
> > review until the MFD set gets accepted. Though maybe I'm wrong there.
> 
> IDK, if you have a concrete description of the problem, I suppose the
> contributors to the SERDES driver may be able to come up with a
> suggestion or two?
> 
> I suggest you try to cover all bases; is the HSIO PLL locked and at the
> right frequency for QSGMII? Does the lane acquire CDR lock? Are in-band
> autoneg settings in sync between the PCS and the PHY? Does the PCS
> report link up?
> 
> > I'd also like to try to keep my patch version count down to one nibble
> > next time, so I'm planning on keeping ports 0-3 and ports 4-7+ in
> > separate patch sets :D