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: <20210515170046.GA18069@earth.li>
Date:   Sat, 15 May 2021 18:00:46 +0100
From:   Jonathan McDowell <noodles@...th.li>
To:     Ansuel Smith <ansuelsmth@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        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 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.

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

J.

-- 
One of the nice things about standards is that there are so many of
them.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ