linux-kernel - Re: [PATCH 2/4] mfd: max77686: Use module_i2c

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]

Date:	Wed, 17 Feb 2016 18:34:59 +0900
From:	Krzysztof Kozlowski <k.kozlowski@...sung.com>
To:	Marek Szyprowski <m.szyprowski@...sung.com>,
	Javier Martinez Canillas <javier@....samsung.com>,
	linux-kernel@...r.kernel.org
Cc:	Andi Shyti <andi.shyti@...sung.com>,
	linux-samsung-soc@...r.kernel.org,
	Lee Jones <lee.jones@...aro.org>,
	Laxman Dewangan <ldewangan@...dia.com>
Subject: Re: [PATCH 2/4] mfd: max77686: Use module_i2c_driver() instead of
 subsys initcall

On 17.02.2016 18:27, Marek Szyprowski wrote:
> Hello,
> 
> On 2016-02-16 00:20, Krzysztof Kozlowski wrote:
>> On 16.02.2016 00:21, Javier Martinez Canillas wrote:
>>> Hello Krzysztof,
>>>
>>> On 02/15/2016 03:54 AM, Krzysztof Kozlowski wrote:
>>>> On 12.02.2016 13:30, Javier Martinez Canillas wrote:
>>>>> The driver's init and exit function don't do anything besides
>>>>> adding and
>>>>> deleting the I2C driver so the module_i2c_driver() macro could be
>>>>> used.
>>>>>
>>>>> Currently is not being used because the driver is initialized at
>>>>> subsys
>>>>> initcall level, claiming that this is done to allow consumers
>>>>> devices to
>>>>> use the resources provided by this driver. But dependencies should
>>>>> be in
>>>>> the DT and consumers drivers should not rely in the registration
>>>>> order.
>>>>>
>>>>> Signed-off-by: Javier Martinez Canillas <javier@....samsung.com>
>>>>> ---
>>>>>
>>>>>    drivers/mfd/max77686.c | 13 +------------
>>>>>    1 file changed, 1 insertion(+), 12 deletions(-)
>>>>>
>>>> In the past not all dependencies supported deferred probing so such
>>>> ordering was required.
>>>>
>>>> I don't like the "dependencies should be in DT" reason for the
>>>> change...
>>>> because it is kind of wishful thinking. Yeah, the dependencies
>>>> should be
>>>> in DT, but are they?
>>>>
>>>> Instead *please check it* and write:
>>>> "Dependencies are in DT so manual ordering of init calls is not
>>>> necessary any more".
>>>>
>>> For the max77802 I know that's the case since the only two DTS in
>>> mainline
>>> that use it are the Peach Pit and Pi and I'm very familiar with those
>>> two.
>>>
>>> But I wonder how can I check that this is the case for the max77686.
>>> Most
>>> DTS in mainline have nodes that use some clocks and regulators
>>> provided by
>>> the PMIC, only arch/arm/boot/dts/exynos5250-smdk5250.dts doesn't have
>>> one
>>> of the regulators as input supply or clock consumer defined.
>> +Cc Marek Szyprowski, who may know a lot more about dependencies between
>> these.
>>
>> I wouldn't care for drivers not taking references to regulators/clocks.
>> Most of necessary regulators and clocks are turned on by bootloader or
>> by default values in PMIC. This means that later probing of PMIC
>> shouldn't influence drivers which are not using it.
>>
>> The remaining problem was unsupported deferred probing by some of the
>> drivers using regulators/clocks (drivers being consumers of regulators
>> or clocks). AFAIR one of example was USB OTG.
> 
> USB OTG has been recently fixed to finally support deferred probing, see
> commit 855ed04a3758b205e84b269f92d26ab36ed8e2f7 ("usb: gadget: udc-core:
> independent registration of gadgets and gadget drivers").

Thanks for the confirmation!

Best regards,
Krzysztof