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  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:   Mon, 25 May 2020 16:59:16 -0500
From:   Jeremy Linton <jeremy.linton@....com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, andrew@...n.ch,
        f.fainelli@...il.com, hkallweit1@...il.com,
        madalin.bucur@....nxp.com, calvin.johnson@....nxp.com,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC 01/11] net: phy: Don't report success if devices weren't
 found

Hi,

On 5/25/20 4:07 PM, Russell King - ARM Linux admin wrote:
> On Mon, May 25, 2020 at 04:02:13PM -0500, Jeremy Linton wrote:
>>> So, I think you're going to have to add a work-around to ignore bit 0,
>>> which brings up the question whether this is worth it or not.
>>
>> It does ignore bit 0, it gets turned into the C22 regs flag, and
>> cleared/ignored in the remainder of the code (do to MMD loop indexes
>> starting at 1).
> 
> However, I've already pointed out that that isn't the case in a
> number of functions that I listed in another email, and I suspect
> was glossed over.
> 

Hmm, right, I might not be understanding, I'm still considering your 
comments in 4/11 and a couple others..

OTOH, the mmd 0 logic could be completely removed, as its actually been 
broken for a year or so in linux (AFAIK) because the code triggering it 
was disabled when the C22 sanitation patch was merged. OTOH, this patch 
is still clearing the C22 flag from devices, so anything dependent 
entirely on that should have the same behavior as before.

So, there is a bug in the is_valid_phy/device macro, because I messed it 
up when I converted it to a function because its using a signed val, 
when it should be unsigned. I don't think that is what you were hinting 
in 4/11 though.

Thanks,

Powered by blists - more mailing lists