From: David Cohen <david.a.cohen@linux.intel.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
x86@kernel.org, linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [PATCH 0/3] Bring SFI support to out-of-tree driver modules on Intel Mid
Date: Fri, 15 Nov 2013 14:25:02 -0800 [thread overview]
Message-ID: <52869F3E.30702@linux.intel.com> (raw)
In-Reply-To: <20131113081445.GA19388@infradead.org>
On 11/13/2013 12:14 AM, Christoph Hellwig wrote:
> On Tue, Nov 12, 2013 at 02:13:37PM -0800, David Cohen wrote:
>> Hi,
Hi Christoph,
>>
>> This patchset extends sfi_device() macro support to driver modules.
>> The main use case is to allow external driver modules to be enumerated by SFI
>> on Intel Mid platforms.
>
> How about you merge those module again? Remember code added to the
> kernel without users isn't testable, and out of tree modules do not
> bring us any value add.
I got your point.
Here's the testable user:
https://patchwork.kernel.org/patch/3179381/
By simply 'make ARCH=i386 allyesconfig' it will be selected.
But I think there is a misunderstanding here :)
My main target is to sync Intel MID codes from our internal tree to
upstream. These patches I am sending are useful to protect Intel MID
from drivers I don't own and not ready for upstreaming.
My main intention is to upstream more Intel MID codes in a faster and
more reliably way (if internal tree == upstream my tests will be
better).
Since Intel MID users are too sensitive to time to market (sorry to
bring this scenario but we can't run from it on embedded world) I can't
prevent drivers not ready yet for upstreaming to use sfi_device() macro.
So, given my intention is to increase upstreamed codes, do you think it
makes sense to have this sfi_device() modularization support?
Br, David Cohen
next prev parent reply other threads:[~2013-11-15 22:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-12 22:13 [PATCH 0/3] Bring SFI support to out-of-tree driver modules on Intel Mid David Cohen
2013-11-12 22:13 ` [PATCH 1/3] sfi: add private data to sfi_parse_table() David Cohen
2013-11-12 22:13 ` [PATCH 2/3] x86: intel-mid: struct devs_id.name should have 'SFI_NAME_LEN' length David Cohen
2013-11-12 22:13 ` [PATCH 3/3] x86: intel-mid: allow sfi_device() to be used by modules David Cohen
2013-11-13 8:14 ` [PATCH 0/3] Bring SFI support to out-of-tree driver modules on Intel Mid Christoph Hellwig
2013-11-13 11:19 ` Ingo Molnar
2013-11-13 18:10 ` David Cohen
2013-11-15 22:25 ` David Cohen [this message]
2013-11-13 19:29 ` [PATCH] x86: intel-mid: add test module for sfi_device() David Cohen
2013-11-13 19:31 ` David Cohen
2013-11-16 0:09 ` [PATCH v1.1] " David Cohen
2013-11-18 15:28 ` Christoph Hellwig
2013-11-18 17:35 ` David Cohen
2013-11-18 17:37 ` David Cohen
2013-11-21 18:25 ` David Cohen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52869F3E.30702@linux.intel.com \
--to=david.a.cohen@linux.intel.com \
--cc=hch@infradead.org \
--cc=hpa@zytor.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).