netdev - Re: [RFC PATCH net-next v4 01/28] net: mdio: ipq8064: clean whitespaces in define

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:   Sat, 15 May 2021 10:03:03 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Jonathan McDowell <noodles@...th.li>,
        Ansuel Smith <ansuelsmth@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH net-next v4 01/28] net: mdio: ipq8064: clean
 whitespaces in define



On 5/15/2021 10:00 AM, Jonathan McDowell wrote:
> On Sat, May 08, 2021 at 08:05:58PM +0200, Ansuel Smith wrote:
>> On Sat, May 08, 2021 at 08:02:33PM +0200, Andrew Lunn wrote:
>>> On Sat, May 08, 2021 at 02:28:51AM +0200, Ansuel Smith wrote:
>>>> Fix mixed whitespace and tab for define spacing.
>>>
>>> Please add a patch [0/28] which describes the big picture of what
>>> these changes are doing.
>>>
>>> Also, this series is getting big. You might want to split it into two,
>>> One containing the cleanup, and the second adding support for the new
>>> switch.
>>>
>>> 	Andrew
>>
>> There is a 0/28. With all the changes. Could be that I messed the cc?
>> I agree think it's better to split this for the mdio part, the cleanup
>> and the changes needed for the internal phy.
> 
> FWIW I didn't see the 0/28 mail either.I tried these out on my RB3011
> today. I currently use the GPIO MDIO driver because I saw issues with
> the IPQ8064 driver in the past, and sticking with the GPIO driver I see
> both QCA8337 devices and traffic flows as expected, so no obvious
> regressions from your changes.

The cover letter somehow appeared as the final patch in the submission
instead of having all patches in-reply-to it as one would expect.

Russell had some additional feedback that came in during or after the
patches being applied so it would be nice to address that.

> 
> I also tried switching to the IPQ8064 MDIO driver for my first device
> (which is on the MDIO0 bus), but it's still not happy:
> 
> qca8k 37000000.mdio-mii:10: Switch id detected 0 but expected 13

If you do repeated reads of the revision register to you eventually get
13 as intended?
-- 
Florian