From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751932AbaEZXsP (ORCPT ); Mon, 26 May 2014 19:48:15 -0400 Received: from mail.active-venture.com ([67.228.131.205]:57633 "EHLO mail.active-venture.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751482AbaEZXsN (ORCPT ); Mon, 26 May 2014 19:48:13 -0400 X-Originating-IP: 108.223.40.66 Message-ID: <5383D2AD.2050605@roeck-us.net> Date: Mon, 26 May 2014 16:47:57 -0700 From: Guenter Roeck User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Geert Uytterhoeven , Grant Likely CC: Pantelis Antoniou , Rob Herring , Stephen Warren , Matt Porter , Koen Kooi , Alison Chaiken , Dinh Nguyen , Jan Lubbe , Alexander Sverdlin , Michael Stickel , Dirk Behme , Alan Tull , Sascha Hauer , Michael Bohan , Ionut Nicu , Michal Simek , Matt Ranostay , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Pete Popov , Dan Malek , Georgi Vlaev Subject: Re: [PATCH v4 2/8] OF: Introduce DT overlay support. References: <1396615441-29630-1-git-send-email-pantelis.antoniou@konsulko.com> <1396615441-29630-3-git-send-email-pantelis.antoniou@konsulko.com> <20140514100856.5198DC4153D@trevor.secretlab.ca> <20140516105814.3EA3FC403C2@trevor.secretlab.ca> <20140520055026.E3A98C412DA@trevor.secretlab.ca> <20140526104824.63F13C42129@trevor.secretlab.ca> <20140526112348.907B7C421A5@trevor.secretlab.ca> <20140526213303.C1C73C40E11@trevor.secretlab.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/26/2014 02:44 PM, Geert Uytterhoeven wrote: > Hi Grant, > > On Mon, May 26, 2014 at 11:33 PM, Grant Likely > wrote: >> After thinking about it more, I think it is very likely that removing >> all the overlays is the correct thing to do in the kexec use-case. When >> kexec-ing, it makes sense that we'd want the exact same behaviour from >> the kexec'ed kernel. That means we want the device drivers to do the >> same thing including loading whatever overlays they depend on. > > Are the device drivers loading the overlays? > That sounds a bit backwards to me. > Depends on what you mean with 'device driver'. In our case we have a driver dedicated to handle card status. Quite similar to what the connector subsystem does but with significantly more functionality (including devicetree overlay management). Guenter