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: <fa686aa40906261633y502f0ed2jebc58f9160c683ce@mail.gmail.com>
Date:	Fri, 26 Jun 2009 17:33:26 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Anton Vorontsov <avorontsov@...mvista.com>
Cc:	David Miller <davem@...emloft.net>, Li Yang <leoli@...escale.com>,
	Andy Fleming <afleming@...escale.com>, netdev@...r.kernel.org,
	linuxppc-dev@...abs.org
Subject: Re: [PATCH 1/4] of/mdio: Add fixed link support

On Fri, Jun 26, 2009 at 4:29 PM, Anton
Vorontsov<avorontsov@...mvista.com> wrote:
> Currently the fixed link support is broken for all OF ethernet drivers,
> an "OF MDIO rework" removed most of the support. Instead of re-adding
> fixed-link stuff to the drivers, add the support to a framework, so we
> won't duplicate any code.
>
> With this patch, if a node pointer is NULL, then of_phy_connect() will
> try to find ethernet device's node, then will look for fixed-link
> property, and if specified, it connects PHY as usual, via bus_id (fixed
> link PHYs do not have any device tree nodes associated with them).
>
> Signed-off-by: Anton Vorontsov <avorontsov@...mvista.com>

Ugh.  I do not like this approach.  I did not intend to break fixed
links, but I do not think that this approach is the right fix.  There
are several problems.

I don't like the fixed.c approach of creating a dummy phy to begin
with.  I think it is an abuse of the device model to register a dummy
mii_bus and have dummy devices registered on it.  It is a lot of code
for what should be a very simple thing.  In particular, if a PHY is
not specified, then the driver should use a static link configuration.
 This is trivial to implement in an Ethernet driver and I do not think
the dummy phy adds anything.

It hooks into the initialization path of *all* OF enabled net drivers,
whether it wants it or not.  ie. The MPC5200 FEC driver does not want
it because the fixed-link property is not part of the mpc5200-fec
binding; it uses a current-speed property instead.  'fixed-link' has
not been agreed upon to be applicable to all Ethernet bindings, and
I'm not convinced that the format of it won't need to be changed for
future Ethernet bindings.  A function for parsing fixed-link should be
a library function that a driver can choose to call out to.  It should
not be welded into the init path.

I also think parsing the device tree at device open time (when
of_phy_connect is usually called) is best to be avoided.  fixed-link
parsing should really happen at probe time and the values cached IMHO.
 It's probably not significant, but I'd like to keep device tree reads
constrained in the cold path (driver probe time) as opposed to the hot
(or slightly less cool) device open path.

Instead, I think that each driver should be more graceful about
missing phy pointers and the init path should call out to a fixed-link
parser function that sets the initial link settings.  Probably less
than 5 lines of code per driver.

I'm sorry about breaking it.  It was my fault, and I'd be happy to fix
it if you'd like me to, but I don't think that this patch is the right
approach.

g.

> ---
>  drivers/of/of_mdio.c |   45 +++++++++++++++++++++++++++++++++++++++++----
>  1 files changed, 41 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index aee967d..cfd876a 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -9,6 +9,10 @@
>  * out of the OpenFirmware device tree and using it to populate an mii_bus.
>  */
>
> +#include <linux/kernel.h>
> +#include <linux/device.h>
> +#include <linux/netdevice.h>
> +#include <linux/err.h>
>  #include <linux/phy.h>
>  #include <linux/of.h>
>  #include <linux/of_mdio.h>
> @@ -129,11 +133,44 @@ struct phy_device *of_phy_connect(struct net_device *dev,
>                                  void (*hndlr)(struct net_device *), u32 flags,
>                                  phy_interface_t iface)
>  {
> -       struct phy_device *phy = of_phy_find_device(phy_np);
> +       struct phy_device *phy = NULL;
> +
> +       if (phy_np) {
> +               int ret;
> +
> +               phy = of_phy_find_device(phy_np);
> +               if (!phy)
> +                       return NULL;
> +
> +               ret = phy_connect_direct(dev, phy, hndlr, flags, iface);
> +               if (ret)
> +                       return NULL;
> +       } else if (dev->dev.parent) {
> +               struct device_node *net_np;
> +               const u32 *phy_id;
> +               char *bus_id;
> +               int sz;
> +
> +               net_np = dev_archdata_get_node(&dev->dev.parent->archdata);
> +               if (!net_np)
> +                       return NULL;
> +
> +               phy_id = of_get_property(net_np, "fixed-link", &sz);
> +               if (!phy_id || sz < sizeof(*phy_id))
> +                       return NULL;
> +
> +               bus_id = kasprintf(GFP_KERNEL, PHY_ID_FMT, "0", phy_id[0]);
> +               if (!bus_id) {
> +                       dev_err(&dev->dev, "could not allocate memory\n");
> +                       return NULL;
> +               }
>
> -       if (!phy)
> -               return NULL;
> +               phy = phy_connect(dev, bus_id, hndlr, 0, iface);
> +               kfree(bus_id);
> +               if (IS_ERR(phy))
> +                       return NULL;
> +       }
>
> -       return phy_connect_direct(dev, phy, hndlr, flags, iface) ? NULL : phy;
> +       return phy;
>  }
>  EXPORT_SYMBOL(of_phy_connect);
> --
> 1.6.3.1
>
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ