mbox series

[net-next,v2,0/2] net: phy: at803x: paging support

Message ID 20210218185240.23615-1-michael@walle.cc (mailing list archive)
Headers show
Series net: phy: at803x: paging support | expand

Message

Michael Walle Feb. 18, 2021, 6:52 p.m. UTC 
Add paging support to the QCA AR8031/33 PHY. This will be needed if we
add support for the .config_inband_aneg callback, see series [1].

The driver itself already accesses the fiber page (without proper locking).
The former version of this patchset converted the access to
phy_read_paged(), but Vladimir Oltean mentioned that it is dead code.
Therefore, the second patch will just remove it.

changes since v1:
 - second patch will remove at803x_aneg_done() altogether

Michael Walle (2):
  net: phy: at803x: add pages support to AR8031/33
  net: phy: at803x: remove at803x_aneg_done()

 drivers/net/phy/at803x.c | 66 +++++++++++++++++++++-------------------
 1 file changed, 35 insertions(+), 31 deletions(-)

Comments

Vladimir Oltean Feb. 18, 2021, 7:26 p.m. UTC | #1 
On Thu, Feb 18, 2021 at 07:52:38PM +0100, Michael Walle wrote:
> Add paging support to the QCA AR8031/33 PHY. This will be needed if we
> add support for the .config_inband_aneg callback, see series [1].
>
> The driver itself already accesses the fiber page (without proper locking).
> The former version of this patchset converted the access to
> phy_read_paged(), but Vladimir Oltean mentioned that it is dead code.
> Therefore, the second patch will just remove it.
>
> changes since v1:
>  - second patch will remove at803x_aneg_done() altogether

I'm pretty sure net-next is closed now, since David sent the pull
request, and I didn't come to a conclusion yet regarding the final
form of the phy_config_inband_aneg method either.
Michael Walle Feb. 18, 2021, 7:46 p.m. UTC | #2 
Am 2021-02-18 20:26, schrieb Vladimir Oltean:
> On Thu, Feb 18, 2021 at 07:52:38PM +0100, Michael Walle wrote:
>> Add paging support to the QCA AR8031/33 PHY. This will be needed if we
>> add support for the .config_inband_aneg callback, see series [1].
>> 
>> The driver itself already accesses the fiber page (without proper 
>> locking).
>> The former version of this patchset converted the access to
>> phy_read_paged(), but Vladimir Oltean mentioned that it is dead code.
>> Therefore, the second patch will just remove it.
>> 
>> changes since v1:
>>  - second patch will remove at803x_aneg_done() altogether
> 
> I'm pretty sure net-next is closed now, since David sent the pull
> request, and I didn't come to a conclusion yet regarding the final
> form of the phy_config_inband_aneg method either.

Yeah I wasn't sure. http://vger.kernel.org/~davem/net-next.html says
it is still open. But anyway, if not, I'll resend the patch after
the merge window. I've also thought about splitting it into two
individual patches, because they aren't dependent on each other
anymore.

We'll need the page support anyway, even if phy_config_inband_aneg
will change. Ok granted, the cover letter might be misleading then.

-michael
David Miller Feb. 18, 2021, 9:08 p.m. UTC | #3 
From: Michael Walle <michael@walle.cc>
Date: Thu, 18 Feb 2021 20:46:10 +0100

> Am 2021-02-18 20:26, schrieb Vladimir Oltean:
>> On Thu, Feb 18, 2021 at 07:52:38PM +0100, Michael Walle wrote:
>>> Add paging support to the QCA AR8031/33 PHY. This will be needed if we
>>> add support for the .config_inband_aneg callback, see series [1].
>>> The driver itself already accesses the fiber page (without proper
>>> locking).
>>> The former version of this patchset converted the access to
>>> phy_read_paged(), but Vladimir Oltean mentioned that it is dead code.
>>> Therefore, the second patch will just remove it.
>>> changes since v1:
>>>  - second patch will remove at803x_aneg_done() altogether
>> I'm pretty sure net-next is closed now, since David sent the pull
>> request, and I didn't come to a conclusion yet regarding the final
>> form of the phy_config_inband_aneg method either.
> 
> Yeah I wasn't sure. http://vger.kernel.org/~davem/net-next.html says
> it is still open. But anyway, if not, I'll resend the patch after
> the merge window. I've also thought about splitting it into two
> individual patches, because they aren't dependent on each other
> anymore.

It is closed now, so this will have to be deferred.

Thanks.