Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933161Ab2EXReN (ORCPT ); Thu, 24 May 2012 13:34:13 -0400 Received: from mail-wg0-f42.google.com ([74.125.82.42]:52967 "EHLO mail-wg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754070Ab2EXReL (ORCPT ); Thu, 24 May 2012 13:34:11 -0400 MIME-Version: 1.0 In-Reply-To: <20120524083216.GD10562@core.coreip.homeip.net> References: <20120524083216.GD10562@core.coreip.homeip.net> From: Linus Torvalds Date: Thu, 24 May 2012 10:33:49 -0700 X-Google-Sender-Auth: fxSn7lAkwNNUpOF7gzpQZF3Eixo Message-ID: Subject: Re: [git pull] Input updates for 3.5-rc0 To: Dmitry Torokhov , Greg Kroah-Hartman Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-input@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1186 Lines: 35 On Thu, May 24, 2012 at 1:32 AM, Dmitry Torokhov wrote: > Hi Linus, > > to receive updates for the input subsystem. You will get: I get an annoying conflict, and the reason I call it annoying is not because it's hard to resolve, it's because doing that shows that you seem to have preferred using dev_dbg(&input->dev.parent, ...) over the much more natural dev_dbg(&input->dev, ...) which would seem to make more sense. Why? Are the input layer device names so bad that using them for debug output is useless? And if so, why *are* they so bad? I'm going to take your version over Greg's more straightforward one, because I assume Greg did things a bit more mindlessly and I think you presumably had a *reason* for your extra (stupid) ".parent" part. But I'm unhappy with it, because I suspect the reason you did that implies that the input layer does something bad. Hmm? Linus -- 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/