lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56E05930.4080805@wwwdotorg.org>
Date:	Wed, 9 Mar 2016 10:11:12 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Laxman Dewangan <ldewangan@...dia.com>
Cc:	linus.walleij@...aro.org, robh+dt@...nel.org, pawel.moll@....com,
	mark.rutland@....com, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
	treding@...dia.com, Benoit Parrot <bparrot@...com>,
	Alexandre Courbot <acourbot@...dia.com>
Subject: Re: [PATCH 3/5] gpio: of: Return error if gpio hog configuration
 failed

On 03/08/2016 05:02 AM, Laxman Dewangan wrote:
> If GPIO hog configuration failed while adding OF based
> gpiochip() then return the error instead of ignoring it.
>
> This helps of properly handling the gpio driver dependency.
>
> When adding the gpio hog nodes for NVIDIA's Tegra210 platforms,
> the gpio_hogd() fails with EPROBE_DEFER because pinctrl is not
> ready at this time and gpio_request() for Tegra GPIO driver
> returns error. The error was not causing the Tegra GPIO driver
> to fail as the error was getting ignored.

> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c

> @@ -218,9 +220,12 @@ static void of_gpiochip_scan_gpios(struct gpio_chip *chip)
>   		if (IS_ERR(desc))
>   			continue;
>
> -		if (gpiod_hog(desc, name, lflags, dflags))
> -			continue;
> +		ret = gpiod_hog(desc, name, lflags, dflags);
> +		if (ret < 0)
> +			return ret;
>   	}
> +
> +	return 0;
>   }

If there are multiple child nodes (which the code above is looping 
over), and the hog for entries 0, 1, 2 succeed and the hog for entry 3 
fails, don't you need to go back and unhog for nodes 0..2 so that the 
next time this function is called, those hogs won't already be in place 
thus preventing them from being hogged the second time around? Or does 
hogging not take ownership of the resource and thus prevent it from 
being acquired again?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ