From: Arnd Bergmann <arnd@arndb•de>
To: PERIER Romain <romain.perier@gmail•com>
Cc: davem <davem@davemloft•net>, "Heiko Stübner" <heiko@sntech•de>,
"Tobias Klauser" <tklauser@distanz•ch>,
"Beniamino Galvani" <b.galvani@gmail•com>,
"eric.dumazet" <eric.dumazet@gmail•com>,
yongjun_wei@trendmicro•com.cn,
"Florian Fainelli" <f.fainelli@gmail•com>,
netdev <netdev@vger•kernel.org>
Subject: Re: [PATCH v2] ethernet: arc: Add support for specific SoC glue layer device tree bindings
Date: Tue, 19 Aug 2014 14:13:12 +0200 [thread overview]
Message-ID: <201408191413.12337.arnd@arndb.de> (raw)
In-Reply-To: <CABgxDoL5WZ_r6hDuWF2=LJA6wFB4h6voqXdOEHG1jAbpdPN9ZQ@mail.gmail.com>
On Monday 18 August 2014, PERIER Romain wrote:
> Adding Arnd to the loop, as he was interested by these changes.
>
> 2014-08-17 16:48 GMT+02:00 Romain Perier <romain.perier@gmail•com>:
> > Some platforms have special bank registers which might be used to select
> > the correct clock or the right mode for Media Indepent Interface controllers.
> > Sometimes, it is also required to activate vcc regulators in the right order to supply
> > the ethernet controller at the right time. This patch is a refactoring of the arc-emac
> > device driver, it adds a new software architecture design which allows to add specific
> > platform glue layer. Each platform has now its own module which performs custom initialization
> > and remove for the target and then calls to the core driver.
Looks quite good to me overall, I only have minor stylistic comments
> > +/* Platform data for SoC glue layer device tree bindings */
> > +struct arc_emac_platform_data
> > +{
> > + const char *name;
> > + const char *version;
> > + int interface;
> > + struct clk *clk;
> > + void (*set_mac_speed)(void *priv, unsigned int speed);
> > + void *priv;
> > +};
> > +
> > /**
> > * struct arc_emac_priv - Storage of EMAC's private information.
> > * @dev: Pointer to the current device.
> > * @phy_dev: Pointer to attached PHY device.
> > * @bus: Pointer to the current MII bus.
> > + * @plat_data: Pointer to SoC specific data.
> > * @regs: Base address of EMAC memory-mapped control registers.
> > * @napi: Structure for NAPI.
> > * @rxbd: Pointer to Rx BD ring.
Any reason why these are separate structures? It seems to me you could
just move everything into arc_emac_priv.
While it can make sense to pass a structure containting constant data
(e.g. callback pointers and the name field) as a pointer, for the
rest I don't see an advantage.
The new fields in arc_emac_platform_data should be documented the same
way the fields in arc_emac_priv are.
> > -int arc_mdio_probe(struct platform_device *pdev, struct arc_emac_priv *priv);
> > +int arc_emac_probe(struct device *dev, const struct arc_emac_platform_data *plat_data);
> > +int arc_emac_remove(struct net_device *ndev);
This seems strangely asymmetric: the probe function neither returns a
net_device nor does it get passed one.
You could solve both issues if you move the alloc_etherdev() call into the
front-end, and pass that to both probe() and remove() callbacks.
That way you could also avoid the additional priv pointer if you just
embed the arc_emac_priv structure into the per-frontend structure.
> > +
> > +#define DRV_NAME "emac_arc"
> > +#define DRV_VERSION "1.0"
> > +
> > +static int emac_arc_probe(struct platform_device *pdev)
> > +{
> > + struct arc_emac_platform_data *plat_data = NULL;
> > + struct device *dev = &pdev->dev;
> > +
> > + plat_data = devm_kzalloc(dev, sizeof(*plat_data), GFP_KERNEL);
Remove the "= NULL" above, it is pointless here.
> > + if (!plat_data)
> > + return -ENOMEM;
> > + plat_data->name = DRV_NAME;
> > + plat_data->version = DRV_VERSION;
I don't see much use in having a per-frontend DRV_NAME/DRV_VERSION pased
here and would just leave those as part of the backend library.
> > + plat_data->interface = of_get_phy_mode(dev->of_node);
> > + if (plat_data->interface < 0)
> > + plat_data->interface = PHY_INTERFACE_MODE_MII;
> > +
> > + plat_data->clk = devm_clk_get(dev, "hclk");
> > + if (IS_ERR(plat_data->clk)) {
> > + dev_err(dev, "failed to retrieve host clock from device tree\n");
> > + return PTR_ERR_OR_ZERO(plat_data->clk);
> > + }
devm_clk_get() might return -EPROBE_DEFER, in and in that case you should silently
return that to the caller as well.
> > -static int arc_emac_probe(struct platform_device *pdev)
> > +int arc_emac_probe(struct device *dev, const struct arc_emac_platform_data *plat_data)
> > {
> > struct resource res_regs;
> > struct device_node *phy_node;
I would keep passing a platform_device pointer rather than device. If you think
it's a worthwhile simplification to pass just the device, that could be a separate
patch.
Arnd
next prev parent reply other threads:[~2014-08-19 12:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-17 14:48 [PATCH v2] ethernet: arc: Add support for specific SoC glue layer device tree bindings Romain Perier
2014-08-18 14:32 ` PERIER Romain
2014-08-19 12:13 ` Arnd Bergmann [this message]
2014-08-20 6:39 ` PERIER Romain
2014-08-20 16:43 ` Arnd Bergmann
2014-08-18 19:46 ` Florian Fainelli
2014-08-19 6:50 ` Romain Perier
2014-08-20 7:50 ` Tobias Klauser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201408191413.12337.arnd@arndb.de \
--to=arnd@arndb$(echo .)de \
--cc=b.galvani@gmail$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=f.fainelli@gmail$(echo .)com \
--cc=heiko@sntech$(echo .)de \
--cc=netdev@vger$(echo .)kernel.org \
--cc=romain.perier@gmail$(echo .)com \
--cc=tklauser@distanz$(echo .)ch \
--cc=yongjun_wei@trendmicro$(echo .)com.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox