From: palmer@sifive.com (Palmer Dabbelt)
To: linux-riscv@lists.infradead.org
Subject: macb: probe of 10090000.ethernet failed with error -110
Date: Wed, 28 Nov 2018 19:01:14 -0800 (PST) [thread overview]
Message-ID: <mhng-0f0b5208-8aac-4563-a2c0-921a0f5d9084@palmer-si-x1c4> (raw)
In-Reply-To: <20181129022858.GG5037@lunn.ch>
On Wed, 28 Nov 2018 18:28:58 PST (-0800), andrew at lunn.ch wrote:
>> This is all fine as long as Linux doesn't go and reset the phy again. Until
>> bafbdd527d56 ("phylib: Add device reset GPIO support") was the case. After
>> that commit I believe phylib is resetting the phy while attempting to enter
>> unmanaged mode, which is now allowed in this particular chip.
>>
>> Since it appears the phy is not usually described by the device tree but is
>> instead discovered by probing a MII-based ID register, it seems the best
>> place to put this is within the phy driver itself. I find it's usually best
>> to describe things with code, so I hacked up something like
>
> Talking to Florian, i was under the impression that you could not even
> discover the device when its reset state what wrong. You could not
> read the ID registers.
>
> Your suggested change assumed you can discover the device. Is this
> true?
Sorry, I can't tell that from reading the code. Since our bootloader resets
the phy into unmanaged mode I think that just deasserting reset should be OK,
but I don't have much confidence in that -- once I run into one unexpected
feature I start to expect more :)
It looks like there's already an expectation that at least the phy ID registers
can be read between falling and rising edges of a reset, as that's how the
fixups are handled. Since the error message that shows up with a single
(single as far as Linux is concerned, triple since a cold boot) reset rising
edge still lists the phy by name I think that probing is working well enough,
but I wouldn't be surprised if there's something in the middle that's gone
wrong. It's possible registering a fixup that does the double reset can get us
through the probing sequence.
Maybe Atish or Paul can help out? I'm a bit embarrassed to admit that I can't
actually figure out how to boot the board any more, it's been a year since it's
been my primary target and since I just to arch/riscv stuff now I rely them to
test on the board...
WARNING: multiple messages have this Message-ID (diff)
From: Palmer Dabbelt <palmer@sifive.com>
To: andrew@lunn.ch, Atish Patra <Atish.Patra@wdc.com>,
Paul Walmsley <paul.walmsley@sifive.com>
Cc: f.fainelli@gmail.com, sergei.shtylyov@cogentembedded.com,
netdev@vger.kernel.org, nicolas.ferre@microchip.com,
linux-kernel@vger.kernel.org, atish.patra@wdc.com,
schwab@suse.de, linux-riscv@lists.infradead.org,
hkallweit1@gmail.com
Subject: Re: macb: probe of 10090000.ethernet failed with error -110
Date: Wed, 28 Nov 2018 19:01:14 -0800 (PST) [thread overview]
Message-ID: <mhng-0f0b5208-8aac-4563-a2c0-921a0f5d9084@palmer-si-x1c4> (raw)
Message-ID: <20181129030114.h34srTWF_cuYL_PzPqyYu5eh3fhBT6DI_1XCYK8gyjY@z> (raw)
In-Reply-To: <20181129022858.GG5037@lunn.ch>
On Wed, 28 Nov 2018 18:28:58 PST (-0800), andrew@lunn.ch wrote:
>> This is all fine as long as Linux doesn't go and reset the phy again. Until
>> bafbdd527d56 ("phylib: Add device reset GPIO support") was the case. After
>> that commit I believe phylib is resetting the phy while attempting to enter
>> unmanaged mode, which is now allowed in this particular chip.
>>
>> Since it appears the phy is not usually described by the device tree but is
>> instead discovered by probing a MII-based ID register, it seems the best
>> place to put this is within the phy driver itself. I find it's usually best
>> to describe things with code, so I hacked up something like
>
> Talking to Florian, i was under the impression that you could not even
> discover the device when its reset state what wrong. You could not
> read the ID registers.
>
> Your suggested change assumed you can discover the device. Is this
> true?
Sorry, I can't tell that from reading the code. Since our bootloader resets
the phy into unmanaged mode I think that just deasserting reset should be OK,
but I don't have much confidence in that -- once I run into one unexpected
feature I start to expect more :)
It looks like there's already an expectation that at least the phy ID registers
can be read between falling and rising edges of a reset, as that's how the
fixups are handled. Since the error message that shows up with a single
(single as far as Linux is concerned, triple since a cold boot) reset rising
edge still lists the phy by name I think that probing is working well enough,
but I wouldn't be surprised if there's something in the middle that's gone
wrong. It's possible registering a fixup that does the double reset can get us
through the probing sequence.
Maybe Atish or Paul can help out? I'm a bit embarrassed to admit that I can't
actually figure out how to boot the board any more, it's been a year since it's
been my primary target and since I just to arch/riscv stuff now I rely them to
test on the board...
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2018-11-29 3:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-28 10:10 macb: probe of 10090000.ethernet failed with error -110 Andreas Schwab
2018-11-28 10:10 ` Andreas Schwab
2018-11-28 18:15 ` Atish Patra
2018-11-28 18:15 ` Atish Patra
2018-11-28 21:33 ` Florian Fainelli
2018-11-28 21:33 ` Florian Fainelli
2018-11-29 2:08 ` Palmer Dabbelt
2018-11-29 2:08 ` Palmer Dabbelt
2018-11-29 2:28 ` Andrew Lunn
2018-11-29 2:28 ` Andrew Lunn
2018-11-29 3:01 ` Palmer Dabbelt [this message]
2018-11-29 3:01 ` Palmer Dabbelt
2018-11-29 5:55 ` Andrew Lunn
2018-11-29 5:55 ` Andrew Lunn
2018-11-29 11:55 ` Andreas Schwab
-- strict thread matches above, loose matches on Subject: below --
2018-08-24 17:18 Atish Patra
2018-09-15 0:07 ` Atish Patra
2019-04-10 9:50 ` Andreas Schwab
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=mhng-0f0b5208-8aac-4563-a2c0-921a0f5d9084@palmer-si-x1c4 \
--to=palmer@sifive.com \
--cc=linux-riscv@lists.infradead.org \
/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).