linux-kernel - Re: [PATCH net] net: macb: Properly handle phylink on at91rm9200

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: <20200217174244.GD3316@piout.net>
Date:   Mon, 17 Feb 2020 18:42:44 +0100
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Antoine Ténart <antoine.tenart@...tlin.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH net] net: macb: Properly handle phylink on at91rm9200

On 17/02/2020 16:56:44+0000, Russell King - ARM Linux admin wrote:
> On Mon, Feb 17, 2020 at 11:43:48AM +0100, Alexandre Belloni wrote:
> > at91ether_init was handling the phy mode and speed but since the switch to
> > phylink, the NCFGR register got overwritten by macb_mac_config().
> 
> I don't think this actually explains anything - or at least I can't
> make sense of it with respect to your patch.
> 
> You claim that the NCFGR register gets overwritten in macb_mac_config(),
> but I see that the NCFGR register is read-modify-write in there,
> whereas your new implementation below doesn't bother reading the
> present value.
> 
> I think the issue you're referring to is the clearing of the PAE bit,
> which is also the RM9200_RMII for at91rm9200?
> 

This is the issue, I'll rework the commit message.

> Next, there's some duplication of code introduced here - it seems
> that the tail end of macb_mac_link_down() and at91ether_mac_link_down()
> are identical, as are the tail end of macb_mac_link_up() and
> at91ether_mac_link_up().
> 

I was split between having a new phylink_mac_ops instance or
differentiating in the various callbacks. If your preference is the
latter, I'm fine with that.

> > Add new phylink callbacks to handle emac and at91rm9200 properly.
> > 
> > Fixes: 7897b071ac3b ("net: macb: convert to phylink")
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@...tlin.com>
> > ---
> 
> I posted a heads-up message last week about updates to phylink that
> I'll be submitting soon (most of the prerequisits have now been sent
> for review) which touch every phylink_mac_ops-using piece of code in
> the tree.  Unfortunately, this patch introduces a new instance that
> likely isn't going to get my attention, so it's going to create a
> subtle merge conflict between net-next and net trees unless we work
> out some way to deal with it.
> 
> I'm just mentioning that so that some thought can be applied now
> rather than when it actually happens - especially as I've no way to
> test the changes that will be necessary for this driver.
> 

Does that help if I change the callbacks instead of adding a new
phylink_mac_ops instance? I can also wait for your work and rebase on
top of that but that would mean that the fix will not get backported.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com