RE: espressobin device tree with kernel 5.1 RC

["Timothy Krantz" <tkrantz@stahurabrenner.com>]

Miquel,


> -----Original Message-----
> From: Miquel Raynal [mailto:miquel.raynal@bootlin.com]
> Sent: Tuesday, June 18, 2019 11:36 AM
> To: Timothy Krantz <tkrantz@stahurabrenner.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Subject: Re: espressobin device tree with kernel 5.1 RC
> 
> Hi Timothy,
> 
> > > > [    4.203692] cacheinfo: Unable to detect cache hierarchy for CPU 0
> > > > [    4.210192] in mvebu probe
> > > > [    4.212924] check device match
> > > > [    4.216026] device did match
> > > > [    4.219058] check resources
> > > > [    4.221858] resources ok
> > > > [    4.224458] enable resources
> > > > [    4.227405] past enable resources
> > > > [    4.230817] disenable resources
> > > > [    4.234042] past disable resources
> > > > [    4.237536] init host
> > > > [    4.239931] ahci-mvebu d00e0000.sata: AHCI 0001.0300 32 slots 1 ports
> 6
> > > Gbps 0x1 impl platform mode
> > > > [    4.249196] ahci-mvebu d00e0000.sata: flags: ncq sntf led only pmp fbs
> pio
> > > slum part sxs
> > > > [    4.258647] scsi host0: ahci-mvebu
> > > > [    4.262491] ata1: SATA max UDMA/133 mmio [mem 0xd00e0000-
> > > 0xd00e1fff] port 0x100 irq 21
> > > > [    4.270609] past init host
> > > > [    4.273353] past rc check
> > > > [    4.276455] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> > > > [    4.284408] MACsec IEEE 802.1AE
> > > > [    4.287965] libphy: Fixed MDIO Bus: probed
> > > > [snip]
> > > >
> > > > Unfortunately that does not tell me much.  Does it say anything to you?
> > > > I mean I guess        rc = ahci_platform_enable_resources(hpriv); Is
> failing,
> > > should I put some traces in that?
> > >
> > > Yes, in particular around the PHY initialization, until you found
> > > where it fails exactly.
> > >
> > >
> > > Thanks,
> > > Miquèl
> >
> > I have traced it down to phy_init in phy-core.c and have put in the following
> traces:
> >
> > int phy_init(struct phy *phy)
> > {
> >         int ret;
> >
> >         if (!phy)
> >                 return 0;
> >
> >         ret = phy_pm_runtime_get_sync(phy);
> >         if (ret < 0 && ret != -ENOTSUPP)
> >                 return ret;
> >         ret = 0; /* Override possible ret == -ENOTSUPP */
> >
> >         mutex_lock(&phy->mutex);
> > printk(KERN_INFO "in phy init before check\n"); printk(KERN_INFO
> > "phy->init_count %d\n", phy->init_count); printk(KERN_INFO
> > "phy->ops->init %pr\n", phy->ops->init);
> >         if (phy->init_count == 0 && phy->ops->init) { printk(KERN_INFO
> > "in phy init past check\n");
> >                 ret = phy->ops->init(phy);
> >                 if (ret < 0) {
> > printk(KERN_INFO "in phy init  phy->ops->init(phy) failed\n");
> >                         dev_err(&phy->dev, "phy init failed --> %d\n", ret);
> >                         goto out;
> >                 }
> >         }
> >         ++phy->init_count;
> >
> > out:
> >         mutex_unlock(&phy->mutex);
> >         phy_pm_runtime_put(phy);
> >         return ret;
> > }
> >
> > Which produces the following dmesg :
> > [    4.194835] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
> > [    4.205270] cacheinfo: Unable to detect cache hierarchy for CPU 0
> > [    4.211777] in mvebu probe
> > [    4.214508] check device match
> > [    4.217609] device did match
> > [    4.220662] check resources
> > [    4.223455] resources ok
> > [    4.226061] in phy init before check
> > [    4.229718] phy->init_count 0
> > [    4.232774] phy->ops->init (null)
> > [    4.236188] phy phy-d0018300.phy.2: phy poweron failed --> -1
> > [    4.242095] enable resources
> > [    4.245072] ahci-mvebu: probe of d00e0000.sata failed with error -1
> > [    4.251831] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> > [    4.259753] MACsec IEEE 802.1AE
> > [    4.263371] libphy: Fixed MDIO Bus: probed
> > [    4.267777] tun: Universal TUN/TAP device driver, 1.6
> > [    4.273375] libphy: orion_mdio_bus: probed
> >
> > I believe the significant line is [    4.232774] phy->ops->init (null)
> >
> > I'm not sure where that was supposed to have been initialized but it
> apparently was not.
> 
> Something looks wrong in your logs: you have init_count to 0 and
> ops->init() to NULL, how can "(phy->init_count == 0 && phy->ops->init)"
> be evaluated to true?
> 
> Miquèl

My prior assertion that the if did not evaluate true is based on not seeing the :

printk(KERN_INFO "in phy init past check\n");

inside of the if statement.

That being said.  I have 3 espressobins, one from the original kickstart, one bought on amazon and purported to be a v5 board and one v7 board bought from globalscale directly.

All of the testing I have done has been on the v5 board.  Is there any chance that there might be some differences in the various revisions?  Want revision board are you testing on?  If I have one that matches I will test on that one as well.

Tim

p.s. Thank you for your patience.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel