Bug#723177: linux-image-3.10-3-kirkwood: please build with CONFIG_MARVELL_PHY=m
On Mon, Nov 11, 2013 at 11:37:53AM -0800, Martin Michlmayr wrote:
> > > I want to enable Wake On Lan on my qnap TS-119P II. In order to do this,
> > > the kernel needs to use code that is specific to the marvell PHY,
> > > m88e1318_get_wol and m88e1318_set_wol from drivers/net/phy/marvell.c to
> > > be specific. This code can be built as a module when the
> > > CONFIG_MARVELL_PHY option is set to “m”.
> > >
> > > Therefore, could you please set CONFIG_MARVELL_PHY=m for the kirkwood
> > > kernel builds?
> > Martin, I see that you disabled CONFIG_MARVELL_PHY in
> > http://anonscm.debian.org/viewvc/kernel?view=revision&revision=14178
> > four years ago.
> >
> > Is that still relevant at all? If so, what options do we have here?
> > Could the users of affected devices blacklist the module on their
> > machines? Could the kernel driver be fixed upstream to not be active on
> > devices that will be broken?
>
> Unfortunately I cannot remember (and I cannot even read the commit
> messages right now because Alioth is done). IIRC I disabled it based
> on a recommendation from Lennert Buytenhek. Lennert, do you remember?
The problem here was that the Marvell PHY driver at some point supported
one or two specific Marvell ethernet PHY models, and people then started
blindly adding new PHY IDs to it without checking whether the already
supported PHYs and the PHYs for which support was being added had common
register layouts (and they didn't).
The result is that on some of the very common Marvell PHYs that this
driver claims to support, the driver does sequences of register writes
that have entirely different effects than the intended ones, causing
various unintended side effects, including complete link failure, and
e.g. on the quad ethernet PHY on some of the mv78xx0 development
boards, having the Marvell PHY driver enabled causes link to flap on
the other three ports if you plug/unplug one of the ports because the
driver thinks it's a good idea to hard reset the whole chip under
these circumstances...
What needs to be done is that someone with access to the relevant
Marvell datasheets fix the driver to behave according to which chip
it's being used on. It's quite a bit of work to sort out this mess,
easily several tens of hours -- I started looking into it when I was
still at Marvell, but didn't get it done before leaving.
Reply to: