On Thu, Sep 7, 2017 at 11:39 PM, Florian Fainelli wrote:
> I think it means CONFIG_GPIOLIB=n in the kernel because it's not needed,
> yet you run code (like drivers/net/phy/mdio_bus.c) that unconditionally
> calls into GPIOLIB and attempts to configure a given GPIO if available.
> This thread is
> >> I think it means CONFIG_GPIOLIB=n in the kernel because it's not needed,
> >> yet you run code (like drivers/net/phy/mdio_bus.c) that unconditionally
> >> calls into GPIOLIB and attempts to configure a given GPIO if available.
> > Yes. I'm facing issue on PC which won't need GPIOLIB as default
On 09/07/2017 02:51 PM, woojung@microchip.com wrote:
> If someone is using GPIO descriptors with GPIO disabled, i.e. calling
> gpiod_get() and friends, this is very likely to be a bug, and what
> the driver wants to do is:
>
> depends on GPIOLIB
>
> or
>
>
> >>> If someone is using GPIO descriptors with GPIO disabled, i.e. calling
> >>> gpiod_get() and friends, this is very likely to be a bug, and what
> >>> the driver wants to do is:
> >>>
> >>> depends on GPIOLIB
> >>>
> >>> or
> >>>
> >>> select GPIOLIB
> >>>
> >>> in Kconfig. The whole optional
On 09/07/2017 02:33 PM, Linus Walleij wrote:
> On Thu, Sep 7, 2017 at 11:30 PM, wrote:
>>> If someone is using GPIO descriptors with GPIO disabled, i.e. calling
>>> gpiod_get() and friends, this is very likely to be a bug, and what
>>> the driver wants to do is:
>>>
>>> depends on GPIOLIB
>>>
>>
On Thu, Sep 7, 2017 at 11:30 PM, wrote:
>> If someone is using GPIO descriptors with GPIO disabled, i.e. calling
>> gpiod_get() and friends, this is very likely to be a bug, and what
>> the driver wants to do is:
>>
>> depends on GPIOLIB
>>
>> or
>>
>> select GPIOLIB
>>
>> in Kconfig. The whole
> If someone is using GPIO descriptors with GPIO disabled, i.e. calling
> gpiod_get() and friends, this is very likely to be a bug, and what
> the driver wants to do is:
>
> depends on GPIOLIB
>
> or
>
> select GPIOLIB
>
> in Kconfig. The whole optional thing is mainly a leftover from when it
On Tue, Jul 18, 2017 at 3:32 PM, Andrew Lunn wrote:
> On Tue, Jul 18, 2017 at 09:52:51AM -0300, Fabio Estevam wrote:
>> On Tue, Jul 18, 2017 at 9:48 AM, Sergei Shtylyov
>> wrote:
>> > On 07/18/2017 03:39 PM, Fabio Estevam wrote:
>> >
>> >>>Won't this result in kernel WARNING when GPIO is disa
Hi Andrew,
On Tue, Jul 18, 2017 at 10:32 AM, Andrew Lunn wrote:
> http://elixir.free-electrons.com/linux/latest/source/include/linux/gpio/consumer.h#L345
> static inline void gpiod_set_value_cansleep(struct gpio_desc *desc, int value)
> {
> /* GPIO can never have been requested */
>
On Tue, Jul 18, 2017 at 09:52:51AM -0300, Fabio Estevam wrote:
> On Tue, Jul 18, 2017 at 9:48 AM, Sergei Shtylyov
> wrote:
> > On 07/18/2017 03:39 PM, Fabio Estevam wrote:
> >
> >>>Won't this result in kernel WARNING when GPIO is disabled?
> >
> >
> >GPIO support, I was going to type...
>
On 07/18/2017 04:09 PM, Fabio Estevam wrote:
No, it does -- devm_gpiod_get_optinal() will return NULL in that case,
bus->reset_gpio will remanin NULL, and you're removing the NULL checks
around the gpiod_set_value_cansleep() calls. Perhaps it's the problem in the
GPIO support though...
It i
On Tue, Jul 18, 2017 at 10:02 AM, Sergei Shtylyov
wrote:
>No, it does -- devm_gpiod_get_optinal() will return NULL in that case,
> bus->reset_gpio will remanin NULL, and you're removing the NULL checks
> around the gpiod_set_value_cansleep() calls. Perhaps it's the problem in the
> GPIO suppo
On 07/18/2017 03:52 PM, Fabio Estevam wrote:
Won't this result in kernel WARNING when GPIO is disabled?
GPIO support, I was going to type...
Not sure if I understood your point, but gpiod_set_value_cansleep() is
a no-op when the gpiod is NULL.
Look at the stub in , it has WARN_O
On Tue, Jul 18, 2017 at 9:48 AM, Sergei Shtylyov
wrote:
> On 07/18/2017 03:39 PM, Fabio Estevam wrote:
>
>>>Won't this result in kernel WARNING when GPIO is disabled?
>
>
>GPIO support, I was going to type...
>
>> Not sure if I understood your point, but gpiod_set_value_cansleep() is
>> a
On 07/18/2017 03:39 PM, Fabio Estevam wrote:
Won't this result in kernel WARNING when GPIO is disabled?
GPIO support, I was going to type...
Not sure if I understood your point, but gpiod_set_value_cansleep() is
a no-op when the gpiod is NULL.
Look at the stub in , it has WARN_ON(
On Tue, Jul 18, 2017 at 6:56 AM, Sergei Shtylyov
wrote:
>Won't this result in kernel WARNING when GPIO is disabled?
Not sure if I understood your point, but gpiod_set_value_cansleep() is
a no-op when the gpiod is NULL.
Hello!
On 7/18/2017 12:09 AM, Fabio Estevam wrote:
From: Fabio Estevam
The gpiod API checks for NULL descriptors, so there is no need to
duplicate the check in the driver.
Won't this result in kernel WARNING when GPIO is disabled?
Signed-off-by: Fabio Estevam
[...]
MBR, Sergei
From: Fabio Estevam
Date: Mon, 17 Jul 2017 18:09:09 -0300
> From: Fabio Estevam
>
> The gpiod API checks for NULL descriptors, so there is no need to
> duplicate the check in the driver.
>
> Signed-off-by: Fabio Estevam
Applied, thanks.
On Mon, Jul 17, 2017 at 06:09:09PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> The gpiod API checks for NULL descriptors, so there is no need to
> duplicate the check in the driver.
> Signed-off-by: Fabio Estevam
VALIDATE_DESC is ugly. But:
Reviewed-by: Andrew Lunn
Andrew
From: Fabio Estevam
The gpiod API checks for NULL descriptors, so there is no need to
duplicate the check in the driver.
Signed-off-by: Fabio Estevam
---
drivers/net/phy/mdio_bus.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/ne
20 matches
Mail list logo
