Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752945Ab3C1SF3 (ORCPT ); Thu, 28 Mar 2013 14:05:29 -0400 Received: from mail-la0-f51.google.com ([209.85.215.51]:52967 "EHLO mail-la0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752272Ab3C1SFZ (ORCPT ); Thu, 28 Mar 2013 14:05:25 -0400 MIME-Version: 1.0 In-Reply-To: References: <1364472270-9297-1-git-send-email-mcgrof@do-not-panic.com> <20130328083943.01e61b4b@jbarnes-desktop> From: "Luis R. Rodriguez" Date: Thu, 28 Mar 2013 11:05:03 -0700 X-Google-Sender-Auth: JRXEQtHvVQJMU9rQnQmOihQjkSY Message-ID: Subject: Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch To: Julia Lawall Cc: Jesse Barnes , FlorianSchandinat@gmx.de, linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, "backports@vger.kernel.org" , cocci@systeme.lip6.fr, "linux-kernel@vger.kernel.org" , rodrigo.vivi@gmail.com, Daniel Vetter , rafael.j.wysocki@intel.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1660 Lines: 40 On Thu, Mar 28, 2013 at 9:19 AM, Julia Lawall wrote: > On Thu, 28 Mar 2013, Jesse Barnes wrote: >> > - info->skip_vt_switch = true; >> > + fb_enable_skip_vt_switch(info); >> > >> > So we'd then have to just add this static inline change for each new driver... >> > There may be a way to get SmPL to do this for us... > > @@ > type of info *info; > @@ > > - info->skip_vt_switch = true; > + fb_enable_skip_vt_switch(info); > > for whatever the type of info is. Thanks Julia! I'll be sure to try to add this to compat-drivers if the upstream fb patch is not accepted. If it is accepted we would not need this at all! > Then I guess there would be a similar rule for the false case? Nope, see that's the proactive strategy taken by the static inline and hence the patch. compat would have a static inline for both cases, and for the false case it'd be a no-op. If accepted upstream though then we would not need any changes for this collateral evolution. However *spotting* these collateral evolutions and giving you SmPL for them as a proactive strategy might be good given that if these type of patches are indeed welcomed upstream we'd then be able to address these as secondary steps. If they are not accepted then indeed we'd use them to backport that collateral evolution through both compat (adds the static inlines) and compat-drivers (the SmPL). Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/