Re: [PATCH v3 2/7] net: pch_gbe: Pull PHY GPIO handling out of Minnow code

[Paul Burton <paul.burton@imgtec.com>]

[-- Attachment #1: Type: text/plain, Size: 3262 bytes --]

Hi Andrew,

On Saturday, 3 June 2017 10:52:00 PDT Andrew Lunn wrote:
> > diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
> > b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c index
> > d38198718005..cb9b904786e4 100644
> > --- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
> > +++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
> > @@ -360,6 +360,16 @@ static void pch_gbe_mac_mar_set(struct pch_gbe_hw
> > *hw, u8 * addr, u32 index)> 
> >  	pch_gbe_wait_clr_bit(&hw->reg->ADDR_MASK, PCH_GBE_BUSY);
> >  
> >  }
> > 
> > +static void pch_gbe_phy_set_reset(struct pch_gbe_hw *hw, int value)
> > +{
> > +	struct pch_gbe_adapter *adapter = pch_gbe_hw_to_adapter(hw);
> > +
> > +	if (!adapter->pdata || !adapter->pdata->phy_reset_gpio)
> > +		return;
> > +
> > +	gpiod_set_value(adapter->pdata->phy_reset_gpio, value);
> 
> Hi Paul
> 
> Since you are using the gpiod_ API, the core will take notice of the
> active low/active high flag when performing this set.

Correct, and as desired.

> >  	ret = devm_gpio_request_one(&pdev->dev, gpio, flags,
> >  	
> >  				    "minnow_phy_reset");
> > 
> > -	if (ret) {
> > +	if (!ret)
> > +		pdata->phy_reset_gpio = gpio_to_desc(gpio);
> 
> Here however, you are using the gpio_ API, which ignores the active
> high/low flag in device tree. And in your binding patch, you give the
> example:
> 
> +               phy-reset-gpios = <&eg20t_gpio 6
> +                                  GPIO_ACTIVE_LOW>;
> 
> This active low is totally ignored.

First of all, this path is for the existing Minnow platform, which doesn't use 
the device tree. That is, this code is the non-DT path so looking at what 
happens to flags in the device tree here makes no sense.

If you want to examine what happens in the DT case then please look at 
pch_gbe_get_priv() which uses devm_gpiod_get() which should honor the flags 
provided by the DT.

> I personally would say this is all messed up, and going to result in
> problems for somebody with a board which actually needs an
> GPIO_ACTIVE_HIGH.

It's a path which only applies to the Minnow board, which is always active 
low. Before patch 1 of this series that was done without the GPIOF_ACTIVE_LOW 
flag by setting GPIO values to reflect the physical GPIO line low/high rather 
than the logical active/not-active. After patch 1 this path began using 
GPIOF_ACTIVE_LOW such that the rest of the code can use logical active/not-
active values which work with either active low or active high GPIOs. In this 
Minnow-specific path GPIOF_ACTIVE_LOW is hardcoded, but again only applies to 
the Minnow board which doesn't take the GPIO value from device tree.

> Please use the gpiod_ API through out and respect the flags in the
> device tree binding.

The gpiod_ API, quite rightly, retrieves GPIOs associated with a device - for 
example via the device tree. The Minnow board, which is what the driver 
already supports in-tree, does not do this but instead hardcodes a GPIO number 
(MINNOW_PHY_RESET_GPIO). I don't own, use or care about the Minnow platform so 
that is not something that I can change. In the path that my patch does add, 
the path which is used with DT, I already do use the gpiod_ API & respect 
flags from the DT.

Thanks,
    Paul

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]