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,
PaulAttachment:
signature.asc
Description: This is a digitally signed message part.
