From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751700Ab3KRRh6 (ORCPT ); Mon, 18 Nov 2013 12:37:58 -0500 Received: from mga11.intel.com ([192.55.52.93]:6826 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751297Ab3KRRhw (ORCPT ); Mon, 18 Nov 2013 12:37:52 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.93,725,1378882800"; d="scan'208";a="429744769" Message-ID: <528A4FED.3030709@linux.intel.com> Date: Mon, 18 Nov 2013 09:35:41 -0800 From: David Cohen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: Christoph Hellwig CC: mingo@kernel.org, hpa@zytor.com, tglx@linutronix.de, x86@kernel.org, linux-kernel@vger.kernel.org, lenb@kernel.org Subject: Re: [PATCH v1.1] x86: intel-mid: add test module for sfi_device() References: <1384370961-30847-1-git-send-email-david.a.cohen@linux.intel.com> <1384560558-10462-1-git-send-email-david.a.cohen@linux.intel.com> <20131118152806.GB19649@infradead.org> In-Reply-To: <20131118152806.GB19649@infradead.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/18/2013 07:28 AM, Christoph Hellwig wrote: > On Fri, Nov 15, 2013 at 04:09:18PM -0800, David Cohen wrote: >> This patch adds a test module to validate sfi_device() when used from a >> driver module. > > I don't think this is all that useful. How about you prepeare a few > of the more useful drivers from your tree for submission instead? One of these drivers you can track here: https://patchwork.kernel.org/patch/3109791/ This is necessary to enable serial console on Saltbay (Merrifield based platform). But the driver is still being reworked to be upstreamed. Anyway, upstream those drivers won't work to validate this patch set we're discussion here. All platform codes are bool (can't be module). The real purpose of these patches is to make my internal tree to be equal to upstream. My intention is to upstream *all* internal patches of Intel MID and temporarily move away from arch/x86/platform/intel- mid/device_libs/ the platform code from still-on-staging-state drivers. So, we need a dummy module on upstream to make this code testable. In case this code is not accepted, I'll will have to maintain 2 official public branches: one with these patches and one without them. Br, David