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: <56C69921.4050201@samsung.com>
Date:	Fri, 19 Feb 2016 13:25:05 +0900
From:	Krzysztof Kozlowski <k.kozlowski@...sung.com>
To:	Andi Shyti <andi.shyti@...sung.com>,
	Javier Martinez Canillas <javier@....samsung.com>
Cc:	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Kukjin Kim <kgene@...nel.org>, linux-pm@...r.kernel.org,
	linux-samsung-soc@...r.kernel.org,
	Lukasz Majewski <l.majewski@...sung.com>,
	Zhang Rui <rui.zhang@...el.com>,
	Eduardo Valentin <edubezval@...il.com>
Subject: Re: [PATCH 3/3] thermal: exynos: Defer probe if vtmu is present but
 not registered

On 19.02.2016 13:20, Andi Shyti wrote:
> Hi Javier,
> 
> Just a question...
> 
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
>> index f4f36bba7be9..f3ce94ec73b5 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -1318,6 +1318,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
>>  			return ret;
>>  		}
>>  	} else {
>> +		if (PTR_ERR(data->regulator) == -EPROBE_DEFER)
>> +			return -EPROBE_DEFER;
> 
> shouldn't we return also in case of -ENOMEM? -ENOMEM is a Kernel
> failure, not depending on the regulator itself.

Usually not because that would make this error path quite complicated
and difficult to keep consistent. If you choose this way then you will
have to probably extend the black list (e.g. EINVAL, some other)... or
use a white list.

Additionally the error codes can come from deeper layers. These layer
now can return ESOMETHING but later it might change to EDIFFERENT... you
cannot predict that.

Whatever the reason was (except defer), just ignore the regulator.

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ