[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1373920870.3475.200.camel@envy.home>
Date: Mon, 15 Jul 2013 13:41:10 -0700
From: Darren Hart <dvhart@...ux.intel.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Waskiewicz <peter.p.waskiewicz.jr@...el.com>,
netdev@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH 3/3] pch_gbe: Add MinnowBoard support
On Mon, 2013-07-15 at 11:34 +0300, Andy Shevchenko wrote:
> On Fri, 2013-07-12 at 17:58 -0700, Darren Hart wrote:
...
> > +/* The AR803X PHY on the MinnowBoard requires a physical pin to be toggled to
> > + * ensure it is awake for probe and init. Request the line and reset the PHY.
> > + */
> > +static int pch_gbe_minnow_platform_init(struct pci_dev *pdev)
> > +{
> > + int ret = 0;
> > + int flags = GPIOF_DIR_OUT | GPIOF_INIT_HIGH | GPIOF_EXPORT;
> > + int gpio = MINNOW_PHY_RESET_GPIO;
> > +
> > + ret = gpio_request_one(gpio, flags, "minnow_phy_reset");
> > + if (ret){
> > + dev_err(&pdev->dev,
> > + "ERR: Can't request PHY reset GPIO line '%d'\n", gpio);
> > + return ret;
> > + }
> > +
> > + gpio_set_value(gpio, 0);
> > + usleep_range(1250, 1500);
> > + gpio_set_value(gpio, 1);
> > + usleep_range(1250, 1500);
>
> First of all, who is going to release gpio? Perhaps
> devm_gpio_request_one?
Thanks for the pointer, this works and appears to be the best way to
handle this.
...
> > + */
> > +int pch_gbe_phy_tx_clk_delay(struct pch_gbe_hw *hw)
> > +{
> > + /* The RGMII interface requires a ~2ns TX clock delay. This is typically
> > + * done in layout with a longer trace or via PHY strapping, but can also
> > + * be done via PHY configuration registers.
> > + */
> > + struct pch_gbe_adapter *adapter = pch_gbe_hw_to_adapter(hw);
> > + u16 mii_reg;
> > + int ret = 0;
>
> No need to assign. Are you trying to shut (sparse?) warning?
On this point, I did find one instance where I initialized init only to
have my first line of executable code assign to ret, that's obviously
silly, so I fixed that one.
Here, where the first assignment is nested inside case statements or
skipped altogether with explicit returns of error codes, I prefer to
assign it explicitly. A quick survey lists 4k initialized "int ret;"
lines and 16k uninitialized. The latter appears to be the more common,
but there is certainly precedent for the former.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
--
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