Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1737726

Re: [PATCH net-next 2/4] net: dsa: remove phy arg from port enable/disable

From Florian Fainelli <f.fainelli@gmail.com>
Newsgroups linux.kernel
Subject Re: [PATCH net-next 2/4] net: dsa: remove phy arg from port enable/disable
Date 2017-09-22 20:30 +0200
Message-ID <usAS5-ZW-3@gated-at.bofh.it> (permalink)
References <usyZY-8kh-3@gated-at.bofh.it> <usyZZ-8kh-27@gated-at.bofh.it> <uszMl-oq-7@gated-at.bofh.it> <usAIq-WQ-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 09/22/2017 11:12 AM, Vivien Didelot wrote:
> Hi Florian,
> 
> Florian Fainelli <f.fainelli@gmail.com> writes:
> 
>> On 09/22/2017 09:17 AM, Vivien Didelot wrote:
>>> The .port_enable and .port_disable functions are meant to deal with the
>>> switch ports only, and no driver is using the phy argument anyway.
>>> Remove it.
>>
>> I don't think this makes sense, there are perfectly legit reasons why a
>> switch driver may have something to do with the PHY device attached to
>> its per-port network interface, we should definitively keep that around,
>> unless you think we should be accessing the PHY within the switch
>> drivers by doing:
>>
>> struct phy_device *phydev = ds->ports[port].netdev->phydev?
> 
> bcm_sf2 is the only user for this phy argument right now. The reason I'm
> doing this is because I prefer to discourage switch drivers to dig into
> the phy device themselves while as you said there must be a cleaner
> solution. This must be handled somehow elsewhere in the stack.

The current approach of passing the phy_device reference as an argument
is certainly a cleaner way then. The port_enable caller can provide the
correct phy_device and that lifts the switch driver from having to dig
it itself from its per-port netdev.

> 
> In the meantime, moving the PHY device up to the dsa_port structure is a
> good solution, in order not to expose it in switch ops, but still make
> it available to more complex drivers.
> 
> Do you know if netdev->phydev is usable? Why do DSA has its own copy in
> dsa_slave_priv then?

Historical reasons mostly. Considering the complexity of
dsa_slave_phy_setup(), I would certainly be extremely careful in
changing any of this, the potential for breakage is pretty big. At first
glance, I would say that this is a safe conversion to do, and I can test
this on the HW I have here anyway.
-- 
Florian

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH net-next 0/4] net: dsa: simplify port enabling Vivien Didelot <vivien.didelot@savoirfairelinux.com> - 2017-09-22 18:30 +0200
  [PATCH net-next 2/4] net: dsa: remove phy arg from port enable/disable Vivien Didelot <vivien.didelot@savoirfairelinux.com> - 2017-09-22 18:30 +0200
    Re: [PATCH net-next 2/4] net: dsa: remove phy arg from port  enable/disable Florian Fainelli <f.fainelli@gmail.com> - 2017-09-22 19:20 +0200
      Re: [PATCH net-next 2/4] net: dsa: remove phy arg from port enable/disable Vivien Didelot <vivien.didelot@savoirfairelinux.com> - 2017-09-22 20:20 +0200
        Re: [PATCH net-next 2/4] net: dsa: remove phy arg from port  enable/disable Florian Fainelli <f.fainelli@gmail.com> - 2017-09-22 20:30 +0200
          Re: [PATCH net-next 2/4] net: dsa: remove phy arg from port  enable/disable Andrew Lunn <andrew@lunn.ch> - 2017-09-22 21:20 +0200
  [PATCH net-next 3/4] net: dsa: make slave close symmetrical to open Vivien Didelot <vivien.didelot@savoirfairelinux.com> - 2017-09-22 18:30 +0200
    Re: [PATCH net-next 3/4] net: dsa: make slave close symmetrical to  open Andrew Lunn <andrew@lunn.ch> - 2017-09-22 18:40 +0200
    Re: [PATCH net-next 3/4] net: dsa: make slave close symmetrical to  open Florian Fainelli <f.fainelli@gmail.com> - 2017-09-22 19:20 +0200

csiph-web