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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <55279F65.9090202@free.fr>
Date:	Fri, 10 Apr 2015 12:01:09 +0200
From:	Mason <slash.tmp@...e.fr>
To:	Daniel Mack <daniel@...que.org>, netdev@...r.kernel.org
CC:	Florian Fainelli <f.fainelli@...il.com>,
	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

Daniel Mack wrote:

> 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.

It seems something was done differently on my SoC.
I'll keep looking.

>> 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.

I wonder what value the CONTROL register was set to on your SoC
after a SW reset. Maybe the "retain value" jiggery-pokery is just
a red herring.

>> 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,

Did you forget to finish that sentence? :-)


>> 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?

No, the RMW of the CONTROL register for when triggering reset.

> 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.

I'd force a HW reset by jiggling the appropriate GPIO pin?
Like you did in the at803x.c driver?

> 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.

Thanks for your help, by the way (and Fabio too).

Regards.

--
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