From: Benoit Masson <benoitm@perenite.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Jason Cooper <jason@lakedaemon.net>,
benoitm974 <yahoo@perenite.com>, Rob Herring <robh+dt@kernel.org>,
Pawel Moll <pawel.moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Russell King <linux@arm.linux.org.uk>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Gregory CLEMENT <gregory.clement@free-electrons.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@googlemail.com>
Subject: Re: [PATCH 1/2] Added dts defintion for Lenovo ix4-300d nas
Date: Wed, 23 Jul 2014 23:15:18 +0200 [thread overview]
Message-ID: <9AE6F1AD-9296-47E9-91E2-9E34AA48EBB4@perenite.com> (raw)
In-Reply-To: <20140723164958.GH2856@lunn.ch>
Well after several test with the original BSP driver I found that this is not fully WOL related. It could be that the LED pin is linked to poweron for WOL, yet here the issue is on shutdown pulling up MPP24 should poweroff the deice but only reboots it except is both PHY have some reg written to...
By the way the current nv_neta does not seems to support WOL for 88e1318 and still having them both up is enough to have poweroff to work, which is why I'm putting the WOL as a side track.
Both phy are :
marvell,88e1318
example of a minimal reg write that lead MPP24 to shutdown instead of rebooting on original BSP driver
XXXXX BasicInit
XXXXXXXXXXXXXX phyAdr 0: regOffs: 16 data: 3 caller: mvEthE1310PhyBasicInit+0x2c/0x58
XXXXXXXXXXXXXX phyAdr 0: regOffs: 10 data: 830 caller: mvEthE1310PhyBasicInit+0x3c/0x58
XXXXXXXXXXXXXX phyAdr 0: regOffs: 16 data: 0 caller: mvEthE1310PhyBasicInit+0x4c/0x58
XXXXX BasicInit
XXXXXXXXXXXXXX phyAdr 1: regOffs: 16 data: 3 caller: mvEthE1310PhyBasicInit+0x2c/0x58
XXXXXXXXXXXXXX phyAdr 1: regOffs: 10 data: 830 caller: mvEthE1310PhyBasicInit+0x3c/0x58
XXXXXXXXXXXXXX phyAdr 1: regOffs: 16 data: 0 caller: mvEthE1310PhyBasicInit+0x4c/0x58
I've tried something like:
compatible = "marvell,88e1318";
device_type = "ethernet-phy";
marvell,reg-init =
/* Init led/activity workaround for MP24 shutdown. */
<3 0x10 0 0x830>;
In the dts but without luck
Regards,
Benoit
Le 23 juil. 2014 à 18:49, Andrew Lunn <andrew@lunn.ch> a écrit :
>> Well actually the PHY need to be initialized (at least 1 mII reg
>> written), which from marvel LSP driver always occurs, while it
>> doesn't with mainline PHY driver (drivers/net/phy/marvell.c), so the
>> only simple way I found to have at least one PHY reg on both
>> interface written is to have both eth up at OS config level.
>
> Thanks for the information. This sounds like a wake on LAN feature.
> I've seen other Marvell hardware connect a PHY LED output pin to the
> circuit controlling the main power supply. When the PHY detects the
> magic wake-up packet, it 'blinks' the LED so turning the power back
> on.
>
> My guess is, the register write to the PHY is configuring the LED. Do
> you have the datasheet for the PHY? Can you check this?
>
>> Probably the best option would be to have a reg-init = <reg offset
>> value> on both phy dts definition but the current armada mii doesn't
>> support this dts config...
>
> Once we understand what is going on here, we can consider adding
> support for this.
>
> Andrew
next prev parent reply other threads:[~2014-07-23 21:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-23 12:07 [PATCH 1/2] Added dts defintion for Lenovo ix4-300d nas benoitm974
2014-07-23 12:07 ` [PATCH 2/2] Adding lenovo in vendor benoitm974
2014-07-23 13:47 ` Jason Cooper
2014-07-23 15:10 ` Andrew Lunn
2014-07-23 17:26 ` Jason Cooper
2014-07-23 21:03 ` Benoit Masson
2014-07-23 13:45 ` [PATCH 1/2] Added dts defintion for Lenovo ix4-300d nas Jason Cooper
2014-07-23 14:14 ` Andrew Lunn
2014-07-23 15:52 ` Benoit Masson
2014-07-23 16:49 ` Andrew Lunn
2014-07-23 21:15 ` Benoit Masson [this message]
2014-07-23 22:26 ` Andrew Lunn
2014-07-23 23:26 ` Benoit Masson
2014-07-23 15:45 ` Sebastian Hesselbarth
2014-07-23 13:49 ` Jason Cooper
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=9AE6F1AD-9296-47E9-91E2-9E34AA48EBB4@perenite.com \
--to=benoitm@perenite.com \
--cc=andrew@lunn.ch \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=gregory.clement@free-electrons.com \
--cc=ijc+devicetree@hellion.org.uk \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=sebastian.hesselbarth@googlemail.com \
--cc=yahoo@perenite.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).