From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756962AbcBQJfK (ORCPT ); Wed, 17 Feb 2016 04:35:10 -0500 Received: from mailout1.w1.samsung.com ([210.118.77.11]:52394 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755662AbcBQJfG (ORCPT ); Wed, 17 Feb 2016 04:35:06 -0500 X-AuditID: cbfec7f4-f79026d00000418a-c3-56c43ec899e4 Subject: Re: [PATCH 2/4] mfd: max77686: Use module_i2c_driver() instead of subsys initcall To: Marek Szyprowski , Javier Martinez Canillas , linux-kernel@vger.kernel.org References: <1455251419-8919-1-git-send-email-javier@osg.samsung.com> <1455251419-8919-3-git-send-email-javier@osg.samsung.com> <56C1762E.9040208@samsung.com> <56C1ED07.6090008@osg.samsung.com> <56C25D55.5040208@samsung.com> <56C43D1A.2000206@samsung.com> Cc: Andi Shyti , linux-samsung-soc@vger.kernel.org, Lee Jones , Laxman Dewangan From: Krzysztof Kozlowski Message-id: <56C43EC3.6040301@samsung.com> Date: Wed, 17 Feb 2016 18:34:59 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-version: 1.0 In-reply-to: <56C43D1A.2000206@samsung.com> Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsVy+t/xy7on7I6EGWz+x2ex/cgzVos3b9cw Wbx+YWixdN9qFov7X48yWlzeNYfNYsb5fUwWa4/cZXfg8LhzbQ+bR2/zOzaPLf132T36tqxi 9Pi8SS6ANYrLJiU1J7MstUjfLoErY8pjo4IlYhUfr/s1MPYJdTFyckgImEhMP7iGGcIWk7hw bz1bFyMXh5DAUkaJZStaWSGcp4wS5w63sXQxcnAIC8RIvOp2BImLCDQxSpy8doAVpFtIoJVJ Yup1DpAEs8A0Romrcy8xgiTYBIwlNi9fwgZi8wpoSZy+P5EJxGYRUJXY8bwJbLWoQITE4c4u dogaQYkfk++xgNicAtoSaxp62EEWMwuoS0yZkgsSZhaQl9i85i3zBEaBWUg6ZiFUzUJStYCR eRWjaGppckFxUnquoV5xYm5xaV66XnJ+7iZGSKB/2cG4+JjVIUYBDkYlHt6AjMNhQqyJZcWV uYcYJTiYlUR4i/WOhAnxpiRWVqUW5ccXleakFh9ilOZgURLnnbvrfYiQQHpiSWp2ampBahFM lomDU6qBMbxwjtmTzbNKVdyuXThq+6qlvvS6yuQfOUWftq3ZdWHq6oM+rubVc17faF2Y+++w o9rBzJDaFzYLl+YwfDgsoeVcnzDzL28ke+nJDDavNLtdE8z91U5ZWyl0WtxgM9LNvXqhqK43 lJtvzVKNF3unNTCU1nxJnjV7IVdxifrzuW/+eJpN/c5zSomlOCPRUIu5qDgRANrw1KtwAgAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >>>>> --- >>>>> >>>>> 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