[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220614223109.603935fb@kernel.org>
Date: Tue, 14 Jun 2022 22:31:09 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
Vladimir Oltean <olteanv@...il.com>,
Russell King <linux@...linux.org.uk>
Cc: Clément Léger <clement.leger@...tlin.com>,
Vivien Didelot <vivien.didelot@...il.com>,
"David S . Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Magnus Damm <magnus.damm@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Giuseppe Cavallaro <peppe.cavallaro@...com>,
Jose Abreu <joabreu@...opsys.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Herve Codina <herve.codina@...tlin.com>,
Miquèl Raynal <miquel.raynal@...tlin.com>,
Milan Stevanovic <milan.stevanovic@...com>,
Jimmy Lalande <jimmy.lalande@...com>,
Pascal Eberhard <pascal.eberhard@...com>,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
linux-renesas-soc@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH RESEND net-next v7 05/16] net: pcs: add Renesas MII
converter driver
On Fri, 10 Jun 2022 12:37:01 +0200 Clément Léger wrote:
> Subject: [PATCH RESEND net-next v7 05/16] net: pcs: add Renesas MII converter driver
>
> Add a PCS driver for the MII converter that is present on the Renesas
> RZ/N1 SoC. This MII converter is reponsible for converting MII to
> RMII/RGMII or act as a MII pass-trough. Exposing it as a PCS allows to
> reuse it in both the switch driver and the stmmac driver. Currently,
> this driver only allows the PCS to be used by the dual Cortex-A7
> subsystem since the register locking system is not used.
Could someone with MII &| PCS knowledge cast an eye over this code?
All I can do is point out error path issues...
> +struct phylink_pcs *miic_create(struct device *dev, struct device_node *np)
> +{
> + struct platform_device *pdev;
> + struct miic_port *miic_port;
> + struct device_node *pcs_np;
> + struct miic *miic;
> + u32 port;
> +
> + if (!of_device_is_available(np))
> + return ERR_PTR(-ENODEV);
> +
> + if (of_property_read_u32(np, "reg", &port))
> + return ERR_PTR(-EINVAL);
> +
> + if (port > MIIC_MAX_NR_PORTS || port < 1)
> + return ERR_PTR(-EINVAL);
> +
> + /* The PCS pdev is attached to the parent node */
> + pcs_np = of_get_parent(np);
of_get_parent()? ..
> + if (!pcs_np)
> + return ERR_PTR(-ENODEV);
> +
> + if (!of_device_is_available(pcs_np))
> + return ERR_PTR(-ENODEV);
.. more like of_leak_parent()
> + pdev = of_find_device_by_node(pcs_np);
> + if (!pdev || !platform_get_drvdata(pdev))
> + return ERR_PTR(-EPROBE_DEFER);
> +
> + miic_port = kzalloc(sizeof(*miic_port), GFP_KERNEL);
> + if (!miic_port)
> + return ERR_PTR(-ENOMEM);
> +
> + miic = platform_get_drvdata(pdev);
> + device_link_add(dev, miic->dev, DL_FLAG_AUTOREMOVE_CONSUMER);
> +
> + miic_port->miic = miic;
> + miic_port->port = port - 1;
> + miic_port->pcs.ops = &miic_phylink_ops;
> +
> + return &miic_port->pcs;
> +}
> +EXPORT_SYMBOL(miic_create);
> +static int miic_parse_dt(struct device *dev, u32 *mode_cfg)
> +{
> + s8 dt_val[MIIC_MODCTRL_CONF_CONV_NUM];
> + struct device_node *np = dev->of_node;
> + struct device_node *conv;
> + u32 conf;
> + int port;
> +
> + memset(dt_val, MIIC_MODCTRL_CONF_NONE, sizeof(dt_val));
> +
> + of_property_read_u32(np, "renesas,miic-switch-portin", &conf);
> + dt_val[0] = conf;
> +
> + for_each_child_of_node(np, conv) {
> + if (of_property_read_u32(conv, "reg", &port))
> + continue;
> +
> + if (!of_device_is_available(conv))
> + continue;
> +
> + if (of_property_read_u32(conv, "renesas,miic-input", &conf) == 0)
> + dt_val[port] = conf;
> +
> + of_node_put(conv);
Don't these iteration functions put() the current before taking the
next one all by themselves? Or is there supposed to be a "break" here?
> + }
> +
> + return miic_match_dt_conf(dev, dt_val, mode_cfg);
> +}
Powered by blists - more mailing lists