lkml.org 
[lkml]   [2013]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/3] Bring SFI support to out-of-tree driver modules on Intel Mid
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


\
 
 \ /
  Last update: 2013-11-15 23:41    [W:0.108 / U:1.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site