From: "Timothy Krantz" <tkrantz@stahurabrenner.com>
To: "'Miquel Raynal'" <miquel.raynal@bootlin.com>
Cc: linux-arm-kernel@lists.infradead.org
Subject: RE: espressobin device tree with kernel 5.1 RC
Date: Tue, 18 Jun 2019 11:42:25 -0400 [thread overview]
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAOBWTR25SONAuESb5loyl/sBAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAD0x6xNgaufTpiiNY/BBdJYAQAAAAA=@stahurabrenner.com> (raw)
In-Reply-To: <20190618173604.4958474c@xps13>
Hi 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
I do not believe it did evaluate true. I believe it fell through to
> ++phy->init_count;
>
> out:
> mutex_unlock(&phy->mutex);
> phy_pm_runtime_put(phy);
> return ret;
> }
Tim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-06-18 15:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <!&!AAAAAAAAAAAuAAAAAAAAAOBWTR25SONAuESb5loyl/sBAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAABB6J1kxOR7T73eMrM92Eq+AQAAAAA=@stahurabrenner.com>
2019-04-29 7:57 ` espressobin device tree with kernel 5.1 RC Miquel Raynal
2019-04-29 15:03 ` Timothy Krantz
2019-04-29 15:25 ` Uwe Kleine-König
2019-04-29 16:07 ` Marc Gonzalez
2019-04-29 18:10 ` Miquel Raynal
[not found] ` <!&!AAAAAAAAAAAuAAAAAAAAAOBWTR25SONAuESb5loyl/sBAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAABdzCVMdZ+R6253dvJGHcXAQAAAAA=@stahurabrenner.com>
2019-06-17 9:38 ` Miquel Raynal
2019-06-17 9:40 ` Miquel Raynal
2019-06-17 17:19 ` Timothy Krantz
2019-06-18 7:58 ` Miquel Raynal
2019-06-18 14:15 ` Timothy Krantz
2019-06-18 14:24 ` Miquel Raynal
2019-06-18 15:28 ` Timothy Krantz
2019-06-18 15:36 ` Miquel Raynal
2019-06-18 15:42 ` Timothy Krantz [this message]
2019-06-18 17:08 ` Timothy Krantz
2019-06-18 17:26 ` Miquel Raynal
2019-06-18 20:07 ` Timothy Krantz
2019-06-19 10:29 ` Miquel Raynal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=''\!'&'\!'AAAAAAAAAAAuAAAAAAAAAOBWTR25SONAuESb5loyl/sBAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAD0x6xNgaufTpiiNY/BBdJYAQAAAAA=@stahurabrenner.com' \
--to=tkrantz@stahurabrenner.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).