Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965086AbdGTKWy (ORCPT ); Thu, 20 Jul 2017 06:22:54 -0400 Received: from mailout3.samsung.com ([203.254.224.33]:42112 "EHLO mailout3.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934926AbdGTKWr (ORCPT ); Thu, 20 Jul 2017 06:22:47 -0400 X-AuditID: b6c32a37-f79c96d000001a44-ab-59708474e5a4 Subject: Re: [PATCH] media: Convert to using %pOF instead of full_name To: Rob Herring , Frank Rowand Cc: "linux-media@vger.kernel.org" , Mauro Carvalho Chehab , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , Kyungmin Park , Andrzej Hajda , "Lad, Prabhakar" , Songjun Wu , Kukjin Kim , Krzysztof Kozlowski , Javier Martinez Canillas , Minghsiu Tsai , Houlong Wei , Andrew-CT Chen , Matthias Brugger , Laurent Pinchart , =?UTF-8?Q?Niklas_S=c3=b6derlund?= , Guennadi Liakhovetski , Hyun Kwon , Michal Simek , =?UTF-8?Q?S=c3=b6ren_Brinkmann?= , "linux-arm-kernel@lists.infradead.org" , "linux-samsung-soc@vger.kernel.org" , linux-mediatek@lists.infradead.org, "open list:MEDIA DRIVERS FOR RENESAS - FCP" , Javi Merino From: Sylwester Nawrocki Message-id: <7b004361-f103-f804-3884-299eb5607648@samsung.com> Date: Thu, 20 Jul 2017 12:22:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-version: 1.0 In-reply-to: Content-type: text/plain; charset="utf-8"; format="flowed" Content-language: en-GB Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+c7ZuThcHTcvL3ZlEGjgrYI+KsKgywkigv5xQZeVJ5N0jk2t RZHmLJvlyi7oTFdhUl5Kp8W0pXnJKZGXDKHy2qCYty5DMirN7Rj43+973+f9nvf5+FhSXkOH somaVEGnUScpaankWWt4RESqUauKdjjC8IfHXRT2OL8T2No2T4UTczT+WlNC4Ny/3QS+kW2i 8Wx5MY0nJisJbHaNk7i7u5rBby5MMPjy9VIG21z9FO5ruEPjK9VP5ymrF+Gn7ikCF3Q3EviC cT0us/0h8JQ7Dhff/kVg5+08CruHH5J4zmFn8L2PzRR+b69lYpfz9ZZBhv/2/RBflFNI8bby yzRfW3qeN3Y2SfiBmQeIrzPPC770/aT5vLpyxHtsK/kXnt+Sff4HpFvihaTEdEEXtfWI9ER7 43GtU3H6nf0lykBvl5qQHwvcBrA2mZDIwdAz9IT2spyzI3A07TUh6Tx7EDxqsDL/B0Ys47TY qEJQMXaXEieGEeTf2mxCLKvgdoLlyzpvOZDjoX/aznj1JPdcCjOj2T43mouBq6/yfCzjtsLo aJHvHgm3Bn7XdPnMgrg4ePazgBY1ATBzY0jiZT9uP+ROfSK8THKb4PNsNiVyCLQPv0cir4La yknSawzcBAv5PS2UdzngVoDtJSmG2Q69HYO0yAoYc9YthAyFTPcoIc6aEXRUZiHxUIBg4NI1 QlRthlZn74LzEpiavrJgIIOci3JRwkNb301GLG8Da0O6+HBGAl5/KiGuodWWRdksi/JYFuWx LMpzF0nKUbCg1ScnCPoY7fpIvTpZn6ZJiDyWkmxDvo+8dqMdVXftaUEci5T+shEhRSWn1Ol6 Q3ILApZUBspkmVqVXBavNpwRdCmHdWlJgr4FLWMlyhBZ8JP+ODmXoE4VTgqCVtD97xKsX2gG MjuX8VBW2uciO+z+14vD1nTO7NC02wxRHefiTbHhKSuN9zOyBl1nVc2p+cSu5ZqDFW3bXQ7c aMnMLRr05ESFKxJ37wg8Kh8OimaGDhaqms0vBqoj3ZDWGdvaqtg1u5qrO+Uqdk+af1UF1NeG /TCgudjpEkNDtLbxJGW131JK9CfUMWtJnV79D6Fpk1/EAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA13Se0hTURzAcc69uw/F5XVmHqSHXTBIkLZp4wRpL7JLJOaj0Mrsqjc13Vzb lB5/ZGWSZlMxomYPpQexpHKrmKaVrjQJXWUIWpa2P8TcquUqQ7O2RiCdvz4Hft8DB340Lukm wuh8lU7QqPhClvQXPZ+1B0XpytTp0o7hUDR0q49Ak90uDF1+4tF5x28SfW6+hKFTv2wYqjtR SaJZ40USOZxNGKq2T+DIZrtDod5jDgpV1F6lkMk+QKD+1gskqrpzz6PjLwG6N/4JQ+dsDzF0 rCwaXTfNYOjTeBq6ePYnhrrP6gk0/v4Gjn63WSjU+KaDQIMWM7V2IddiGKa4L67dXP3J8wRn MlaQnPnqEa6s55GIezt1DXB3qz0DY/0/SE5/1wi4SdNirn1yWrQ1YEf86jyBzxE04YIquygn X5Uby25LjY9CbLiKVwqxbFpUQmoyG17CFxZ7bnLpf2fthq2bUtgVcXvi87oe7lV3Bx94bXkM SsGrwErgR0MmBo4YJkifF8AX72577E9LmJsAtjhGCN9lFMBe4xhVCWg6mImHhjG5N5jPcHDg m4XyzuCM1R8++GAW+YJyDI626v8+SzIyePqpHngtZuLg6Gg94bWIiYDTzX2U1yFMGtQ7+ynf TBCcqnsn8tqPSYHXXQ7ca5xRQPe4lfA5FHa9HwQ+L4HmJideA4IMc3LDnMQwJzHMSRqAyAj8 BbVWmavUytUyE/As0X1rZKIFTPXu7AQMDdgA8YhQlC4h+BLtQWUngDTOzheLj6rTJeIc/uAh QVOUqSkuFLSdYKXnS7V4WEh2kWclVbpMWcwqeYxUoZDJpdEKNlRck+ROkzC5vE4oEAS1oPnX YbRfWCnIWL/cbX2pSd4SHHf49vddS7cdjpRK2juWRTRW6BjboqykCwk1Vpcju+tJ842wZuuV gpQz9qmeCntgScLNvnlJDXxxpK1MA+Hxde6OxixF0+byqjUDyu8ZX11t357tq2tzzu5XtDhv ffzxOJPIykuMXRSaOzxUMIPM7RtLxSS7nRVp83hZJK7R8n8AS3gzS1oDAAA= X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170720102244epcas1p12edb5168ed9d6c9afdb1a6bdc9db2ee9 X-Msg-Generator: CA X-Sender-IP: 182.195.42.79 X-Local-Sender: =?UTF-8?B?U3lsd2VzdGVyIE5hd3JvY2tpG1NSUE9MLUtlcm5lbCAoVFAp?= =?UTF-8?B?G+yCvOyEseyghOyekBtTZW5pb3IgU29mdHdhcmUgRW5naW5lZXI=?= X-Global-Sender: =?UTF-8?B?U3lsd2VzdGVyIE5hd3JvY2tpG1NSUE9MLUtlcm5lbCAoVFAp?= =?UTF-8?B?G1NhbXN1bmcgRWxlY3Ryb25pY3MbU2VuaW9yIFNvZnR3YXJlIEVuZ2luZWVy?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDAyQ0QwMjczOTI=?= CMS-TYPE: 101P X-CMS-RootMailID: 20170718215328epcas2p2e5e1d7df96fcd894e70a961df864abdd X-RootMTR: 20170718215328epcas2p2e5e1d7df96fcd894e70a961df864abdd References: <20170718214339.7774-33-robh@kernel.org> <564a6768-3b23-6dc7-ecb5-cb4f4359b633@samsung.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2456 Lines: 47 On 07/19/2017 06:02 PM, Rob Herring wrote: >>> diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c >>> index 851f128eba22..0a385d1ff28c 100644 >>> --- a/drivers/media/v4l2-core/v4l2-async.c >>> +++ b/drivers/media/v4l2-core/v4l2-async.c >>> @@ -47,9 +47,7 @@ static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd) >>> if (!is_of_node(sd->fwnode) || !is_of_node(asd->match.fwnode.fwnode)) >>> return sd->fwnode == asd->match.fwnode.fwnode; >>> >>> - return !of_node_cmp(of_node_full_name(to_of_node(sd->fwnode)), >>> - of_node_full_name( >>> - to_of_node(asd->match.fwnode.fwnode))); >>> + return to_of_node(sd->fwnode) == to_of_node(asd->match.fwnode.fwnode); >> >> I'm afraid this will not work, please see commit d2180e0cf77dc7a7049671d5d57d >> "[media] v4l: async: make v4l2 coexist with devicetree nodes in a dt overlay" > > Maybe I'm missing something, but how does that work exactly? Before > the overlay is applied, the remote endpoint node (and its parent) > can't be resolved. In the commit example, the endpoint in the > media_bridge would also have to be part of the overlay. If you apply > and un-apply the overlay, then the of_node (and fw_node) in the > overlay is once again invalid. IOW, you should be in the same state as > before the overlay was applied. The node is still around because of > paranoia that actually freeing nodes would break things. It seems this > paranoia is real, so i think we need to do something to prevent this > from spreading. > > Furthermore, it does not appear that any media driver supports > overlays and we have no general way to apply them in mainline yet > (other than an in kernel API). So really this scenario is not one we > have to support yet. Indeed, the motivation of the above mentioned commit was some out of tree driver. I don't know was the exact use case, assuming that the endpoint in the bridge node was also part of the overlay the bridge driver must have not been rescanning device tree after overlay un-apply and apply. Currently there is no other way to do this than to unbind and bind. So the bridge driver must have been referencing an already invalid node as you point out. I haven't been following DT overlays very closely, as Frank explains your change seems to be actually an improvement of current code. -- Thanks, Sylwester