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,
atish.patra@wdc.com, schwab@suse.de, nicolas.ferre@microchip.com,
netdev@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.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)
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...
WARNING: multiple messages have this Message-ID (diff)
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: 26+ 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 10:10 ` Andreas Schwab
2018-11-28 18:15 ` Atish Patra
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-28 21:33 ` Florian Fainelli
2018-11-29 2:08 ` Palmer Dabbelt
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 2:28 ` Andrew Lunn
2018-11-29 3:01 ` Palmer Dabbelt [this message]
2018-11-29 3:01 ` Palmer Dabbelt
2018-11-29 3:01 ` Palmer Dabbelt
2018-11-29 5:55 ` Andrew Lunn
2018-11-29 5:55 ` Andrew Lunn
2018-11-29 5:55 ` Andrew Lunn
2018-11-29 11:55 ` Andreas Schwab
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=Atish.Patra@wdc.com \
--cc=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=netdev@vger.kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=paul.walmsley@sifive.com \
--cc=schwab@suse.de \
--cc=sergei.shtylyov@cogentembedded.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.