From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754527AbbFRNOz (ORCPT ); Thu, 18 Jun 2015 09:14:55 -0400 Received: from mailout3.w1.samsung.com ([210.118.77.13]:49702 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752869AbbFRNOq (ORCPT ); Thu, 18 Jun 2015 09:14:46 -0400 X-AuditID: cbfec7f5-f794b6d000001495-07-5582c443a6e6 Message-id: <5582C437.4030108@samsung.com> Date: Thu, 18 Jun 2015 15:14:31 +0200 From: Andrzej Hajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-version: 1.0 To: Mark Brown Cc: Tomeu Vizoso , linux-arm-kernel@lists.infradead.org, Alexander Holler , Alexandre Courbot , Arnd Bergmann , Dmitry Torokhov , Grant Likely , Greg Kroah-Hartman , Ian Campbell , Javier Martinez Canillas , Krzysztof Kozlowski , Kumar Gala , Len Brown , Linus Walleij , linux-kernel@vger.kernel.org, Lv Zheng , Mark Rutland , Pawel Moll , "Rafael J. Wysocki" , Robert Moore , Rob Herring , Russell King , Stephen Warren , =?windows-1252?Q?Terje_Bergstr=F6m?= , Thierry Reding Subject: Re: [PATCH 00/13] Discover and probe dependencies References: <1434548543-22949-1-git-send-email-tomeu.vizoso@collabora.com> <55829269.2090309@samsung.com> <20150618103615.GC14071@sirena.org.uk> In-reply-to: <20150618103615.GC14071@sirena.org.uk> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+845O56NRsep9aFItJDKSDMlviRLEORDCkySoj+qpQeVpo5N RcVQXClmmk1LnRdKXTZTNC3UoXjJJnnXoWbmvBROTbtLF3XkHJH//d7nfZ73+edlSNEy5chE RMVw8iiJVEwLqF5zt+GIX1dq8NFUDUIbKr0Nuj/7gUYvyxYAurv8iIcGluYo1L7eBJCyvJZG 5kwdsalpAXq1JkMfFzxQ8+wKjfLWKwlU/36Mhwy6YhpNGoToq6aOhzTjwwTKya+hUF/vCA9p v+VR6FZrlw1a6kijUE+aM/qtK6VQds0I7euIizJSaFxdWg3wTeUdGq/9UQFsyM4i8IZpnMJN UxUAN6unbLC28geNy1sWCVxflUHjd2MtNG4rqbbBDRXJOEv5icbPR9OpQLtLgpOhnDQijpO7 n7oqCO8oaiBl7bbxk8ovIAWsCm8DPgNZL5imL6atvBsOGWs3WcCIWA2Ab1SphHUwAZhrfgos LiHrCgv7G7cSFOsCy0ZGtphmD8GNhoktdmAvwhXDa8Lqt4W/co2Uhe3Z/XD0ZytlOUqy+Qwc N5VvBhjGjvWG2ZkHrGUqAN8arTqf9YQFA04WJFk3OD3sajlDsnthQ/UKmQNY9bYG9X+Xepvr ISCrgAMXGyJTXAuLPOamkEQqYqPC3EKiI+uB9QdWm4BG790JWAaIdwp3CFKDRTxJnCIhshNA hhTbC28825SEoZKERE4efUUeK+UUncCJocR7hIW6z+dFbJgkhrvOcTJO/m9LMHzHFED6zBV9 T5aKPAuMynw9cVitl5yzj6V83PbVBSQOxqtM9ZPAX6Atnpho8+4+4RzUG5jVeG+XzwI/Xhfy IK7M3Gia9pJFRPTz3V9ICxS+p4eU8z0Dxl6jP14UXXbhzz32y3We1waZVWNJg0nTx2c8npQE hs0ERJ9NP9N34eCil5hShEs8XEm5QvIXPNsSJf8CAAA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/18/2015 12:36 PM, Mark Brown wrote: > On Thu, Jun 18, 2015 at 11:42:01AM +0200, Andrzej Hajda wrote: > > There's something really messed up with how your mailer is word wrapping > paragraphs, might want to check it out - it looks like it's making lines > that are longer than 80 columns and then randomly breaking them 80 > columns in rather than reflowing things. > >> 3. Dependencies are mandatory, ie without it driver will not be able to >> successfully finish >> the probe. >> It should be not true. Sometimes device will require given resource >> only in specific >> scenario, or it can still probe successfully and ask for the >> resource later. >> I can also imagine that firmware can describe more information than >> given driver require, >> some resources even if they are present in the dts, will be not >> requested by the driver, it >> can be the case of drivers providing limited functionality, or just >> obsolete bindings. > Well, this isn't clear - the model here seems to be that the > dependencies are those that are explicitly listed for a given platform. > For those our current expectation is that we will try to control them > and will defer probe until the resources that are mapped in on the > platform are present so this doesn't seem like a change. IMO current assumption is that we CAN TRY to control them and we MAY defer probe until resource is present, nothing mandatory. Lets look at more real example: we have HDMI encoder which can use some video and audio resources provided by some video and audio drivers. If we know that our machine will work without sound we can disable audio drivers but we can expect video should still work, ie HDMI driver should successfully probe even if audio resources are not available. I had an impression that in this patchset the device wont be probed until all dependencies are present, but after looking at the code it does not seems to be true - in case dependency cannot be probed warning will be printed but the probe will continue, so it should handle scenario above properly. The only minor issue is that we will see sometimes misleading message about missing dependencies. Regards Andrzej From mboxrd@z Thu Jan 1 00:00:00 1970 From: a.hajda@samsung.com (Andrzej Hajda) Date: Thu, 18 Jun 2015 15:14:31 +0200 Subject: [PATCH 00/13] Discover and probe dependencies In-Reply-To: <20150618103615.GC14071@sirena.org.uk> References: <1434548543-22949-1-git-send-email-tomeu.vizoso@collabora.com> <55829269.2090309@samsung.com> <20150618103615.GC14071@sirena.org.uk> Message-ID: <5582C437.4030108@samsung.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 06/18/2015 12:36 PM, Mark Brown wrote: > On Thu, Jun 18, 2015 at 11:42:01AM +0200, Andrzej Hajda wrote: > > There's something really messed up with how your mailer is word wrapping > paragraphs, might want to check it out - it looks like it's making lines > that are longer than 80 columns and then randomly breaking them 80 > columns in rather than reflowing things. > >> 3. Dependencies are mandatory, ie without it driver will not be able to >> successfully finish >> the probe. >> It should be not true. Sometimes device will require given resource >> only in specific >> scenario, or it can still probe successfully and ask for the >> resource later. >> I can also imagine that firmware can describe more information than >> given driver require, >> some resources even if they are present in the dts, will be not >> requested by the driver, it >> can be the case of drivers providing limited functionality, or just >> obsolete bindings. > Well, this isn't clear - the model here seems to be that the > dependencies are those that are explicitly listed for a given platform. > For those our current expectation is that we will try to control them > and will defer probe until the resources that are mapped in on the > platform are present so this doesn't seem like a change. IMO current assumption is that we CAN TRY to control them and we MAY defer probe until resource is present, nothing mandatory. Lets look at more real example: we have HDMI encoder which can use some video and audio resources provided by some video and audio drivers. If we know that our machine will work without sound we can disable audio drivers but we can expect video should still work, ie HDMI driver should successfully probe even if audio resources are not available. I had an impression that in this patchset the device wont be probed until all dependencies are present, but after looking at the code it does not seems to be true - in case dependency cannot be probed warning will be printed but the probe will continue, so it should handle scenario above properly. The only minor issue is that we will see sometimes misleading message about missing dependencies. Regards Andrzej