All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
To: Alexander Holler <holler@ahsoftware.de>,
	Florian Fainelli <f.fainelli@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	Michal Simek <michal.simek@xilinx.com>,
	stable <stable@vger.kernel.org>
Subject: Re: [PATCH regression] net: phy: fix initialization (config_init) for Marvel 88E1116R PHYs
Date: Thu, 03 Apr 2014 17:45:11 +0200	[thread overview]
Message-ID: <533D8207.2050108@gmail.com> (raw)
In-Reply-To: <533D790C.5000104@ahsoftware.de>

On 04/03/2014 05:06 PM, Alexander Holler wrote:
> Am 03.04.2014 10:49, schrieb Sebastian Hesselbarth:
>> On 04/03/2014 09:17 AM, Alexander Holler wrote:
>>> Am 03.04.2014 00:27, schrieb Sebastian Hesselbarth:
>>>> On 04/03/2014 12:12 AM, Alexander Holler wrote:
>>>>>> I am curious, how you determined above commit to be the cause of the
>>>>>> regression you are seeing. Can you bisect, if you didn't already?
>>>>>
>>>>> There was no bisecting necessary. I've just looked at what changed in
>>>>> mv643xx_eth since 3.13 and the first commit I've reverted was
>>>>> already a
>>>>> hit. Reading a bit source revealed the differences between the old
>>>>> reset
>>>>> and the newly used one and ended up with my patch (first try) and
>>>>> was a
>>>>> hit too.
>>>>
>>>> Honestly, your own fix changes a different driver than mv643xx_eth.
>>>
>>> It changes stuff which now (through the mentioned commit) gets used
>>> through the change in mv643xx_eth.
>>
>> Sigh. You have proven youself that the commit isn't the root cause
>> of the issue you are seeing. Nor is "fixing" 88e1116r init sequence
>> a reasonable fix.
>
> Sorry, continuing this discussion doesn't make sense. You have the same
> hw, so just try enabling netconsole with 3.14 and use dhcpcd from
> userland (this does the final reset here which hangs.
>
> But don't suggest me (or insist on) a time consuming and totally useless
> bisect when I already know what makes the problem to appear (100%
> reliable here).

I _suggest_ to use bisect, I don't _insist_. But for a patch that 
tackles an issue, knowing the offending patch is really good.

Now that you revealed more input, it becomes more clear to me what is
happening (although I have no clue, what netconsole really does to the
eth/phy):

- u-boot powers on the PHY
- netconsole picks up the eth device and the PHY, drops it later
- the PHY state machine powers off the now unused PHY (also introduced
   in between v3.13 and v3.14).
- dhcp client ifup's the device and tries to reset the powered down PHY

I already made a comment about the set POWERDOWN bit before, which you
silently ignored.

I will try to reproduce it and if I hit it, will do a bisect to find
(and fix) the offending patch.

> I have better ways to waste my time.

Like writing workarounds instead of fixing bugs?

Sebastian


  parent reply	other threads:[~2014-04-03 15:45 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-01 23:55 [PATCH regression] net: phy: fix initialization (config_init) for Marvel 88E1116R PHYs Alexander Holler
2014-04-02  0:00 ` Florian Fainelli
2014-04-02  0:57 ` Florian Fainelli
2014-04-02  9:09   ` Alexander Holler
2014-04-02 10:54     ` Alexander Holler
2014-04-02 19:01     ` Florian Fainelli
2014-04-02 20:25       ` Sebastian Hesselbarth
2014-04-02 22:12         ` Alexander Holler
2014-04-02 22:20           ` Florian Fainelli
2014-04-02 22:27           ` Sebastian Hesselbarth
2014-04-03  7:17             ` Alexander Holler
2014-04-03  8:49               ` Sebastian Hesselbarth
2014-04-03 15:06                 ` Alexander Holler
2014-04-03 15:14                   ` David Miller
2014-04-03 15:45                     ` Alexander Holler
2014-04-03 15:45                   ` Sebastian Hesselbarth [this message]
2014-04-03 15:58                     ` Alexander Holler
2014-04-03 17:58                       ` Bug(s) with netconsole (using mv643xx_eth on Kirkwood) Alexander Holler
2014-04-03 18:21                         ` Sebastian Hesselbarth
2014-04-03 18:23                           ` Alexander Holler
2014-04-03 18:39                           ` Alexander Holler
2014-04-03 18:44                             ` Florian Fainelli
2014-04-04 11:36                               ` Alexander Holler
2014-04-03 17:44                   ` [PATCH regression] net: phy: fix initialization (config_init) for Marvel 88E1116R PHYs Sebastian Hesselbarth
2014-04-03 18:20                     ` Alexander Holler
2014-04-02 22:30     ` Sebastian Hesselbarth
2014-04-02 11:51 ` Sergei Shtylyov
2014-04-02 12:07   ` Sergei Shtylyov
2014-04-02 14:35     ` Alexander Holler

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=533D8207.2050108@gmail.com \
    --to=sebastian.hesselbarth@gmail.com \
    --cc=f.fainelli@gmail.com \
    --cc=holler@ahsoftware.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.simek@xilinx.com \
    --cc=netdev@vger.kernel.org \
    --cc=stable@vger.kernel.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 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.