netdev - Re: Atheros 8035 PHY only works when at803x_config

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <552798CD.70608@zonque.org>
Date:	Fri, 10 Apr 2015 11:33:01 +0200
From:	Daniel Mack <daniel@...que.org>
To:	Mason <slash.tmp@...e.fr>, Florian Fainelli <f.fainelli@...il.com>,
	netdev@...r.kernel.org
CC:	Mugunthan <mugunthanvnm@...com>,
	"David S. Miller" <davem@...emloft.net>,
	Matus Ujhelyi <ujhelyi.m@...il.com>
Subject: Re: Atheros 8035 PHY only works when at803x_config_init() is commented
 out

On 04/09/2015 09:30 PM, Mason wrote:> Am I the only having problems with
the AR8035? :-(
>
> The standard driver works for everyone but me?

A company I used to work with ships various hardware models in
quantities which features this chip, and they're using the unpatched
mainline kernel version of the driver.

> Did you take a look at the data sheet? Do you understand the
> difference between "Hardware Reset" and "Software Reset"?

I did, most notably because I was desperately trying to find a sane way
to conduct a full reset of the PHY to work around a confirmed bug in the
DIE of the chip which causes the internal state machine to lock up on
link loss under certain conditions.

Unfortunately, I failed to find a way to really put the chip into
complete reset state through the registers. Instead, I added a
possibility to let the driver pull the hardware reset (see 13a56b4493).

Other than that, however, I didn't encounter any problems.

> Maybe on my PHY, writing BMCR_RESET to BMCR triggers a SW reset,
> while it triggers a HW reset on other boards?

AFAIK, the chip does not do this, no. But even if it did,

> Also, why do you say the PHY is not working? When I apply the
> patch I proposed, it doesn't malfunction.

You're referring to the one that removes the phy init routine?

I'd still go and check if there's anything in one of the chained
bootloaders that does some magic. One other thing that might give you a
hint is to manually pull the RESET line low for a short time right when
the kernel decompressor is started. That way, the kernel has to deal
with a device that has just seen a hardware reset. Just see if that
makes any difference.

Also, some delays in between the register writes during initialization
might also be worth a try. But that's all just random guessing right
now, sorry.

Daniel
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html