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]
Date:	Wed, 23 Mar 2016 12:56:43 +0100
From:	Daniel Mack <daniel@...que.org>
To:	Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
Cc:	netdev@...r.kernel.org, f.fainelli@...il.com,
	Daniel Mack <zonque@...il.com>
Subject: Re: [PATCH] at803x: fix reset handling

Hi Sergei,
Hi Uwe,

On 03/23/2016 07:45 AM, Uwe Kleine-König wrote:
> I added the author of 13a56b449325 to Cc.

Thanks for doing that!

> On Wed, Mar 23, 2016 at 12:44:40AM +0300, Sergei Shtylyov wrote:
>> The driver of course "knows" that the chip's reset signal is active low,
>> so  it drives the GPIO to 0  to reset the PHY and to 1 otherwise; however
>> all this will only work iff the GPIO  is  specified as active-high in the
>> device tree!  I think both the driver and the device trees (if there are
>> any -- I was unable to find them) need to be fixed in this case...

Well, the driver asserts the line by setting it to 1, while in fact the
chip itself considers 'low' as 'asserted'. Hence I opted for flipping
the logic in DT rather than in the driver core. IIRC, there was even
some sort of level-shifting inversion going on in our design, but I
don't recall the details.

That said, I don't care much. If the general assumption is to make the
driver calls match the actual output on the peripheral, then fine, let's
turn it around, but that's a matter of interpretation IMO.

>> Fixes: 13a56b449325 ("net: phy: at803x: Add support for hardware reset")
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
>>
>> ---
>> The patch is against DaveM's 'net.git' repo.
> 
> Don't you need to work against net-next for non-urgent stuff? Or do you
> consider this urgent?

It's certainly not :)

> The new variant is better than the old one. The change however breaks
> existing device trees which is not so nice. Given there are no mainline
> users this is probably ok though. So:

Hmm, one idea for DT was to allow for external board support via DTB
files, right? Then again, bindings breaks happen all the time anyway.

As far as I'm concerned, I'm fine with the change. If it lands, I'll
simply give my colleagues a short heads-up so they can flip the bit on
their side too.


Thanks,
Daniel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ