atom feed11 messages in org.kernel.vger.kernel-janitorsRe: [remoteproc:for-next 6/9] remotep...
FromSent OnAttachments
Fengguang WuSep 30, 2012 7:45 pm.config
Ohad Ben-CohenOct 2, 2012 1:24 am 
Ohad Ben-CohenOct 9, 2012 2:56 am 
Sjur BRENDELANDOct 9, 2012 3:29 am 
Ohad Ben-CohenOct 9, 2012 4:52 am 
Dan CarpenterOct 9, 2012 6:28 am 
Ohad Ben-CohenOct 9, 2012 7:15 am 
Dan CarpenterOct 9, 2012 7:26 am 
Ohad Ben-CohenOct 9, 2012 7:38 am 
Sjur BRENDELANDOct 11, 2012 11:49 am 
Ohad Ben-CohenOct 11, 2012 2:08 pm 
Subject:Re: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e): undefined reference to `vring_transport_features'
From:Dan Carpenter (dan.@oracle.com)
Date:Oct 9, 2012 6:28:47 am
List:org.kernel.vger.kernel-janitors

On Tue, Oct 09, 2012 at 01:52:49PM +0200, Ohad Ben-Cohen wrote:

Hi Sjur,

On Tue, Oct 9, 2012 at 12:30 PM, Sjur BRENDELAND <sjur@stericsson.com> wrote:

Sorry for not responding sooner, but I thought this issue was solved with your patch "remoteproc: fix (again) the virtio-related build breakage" (https://lkml.org/lkml/2012/10/6/85).

I'm not sure I understand why you would want to add a dependency to ARM. But if you're uncomfortable by having STE_MODEM_RPROC directly selectable, perhaps we could let it be selected by arch specific Kconfig files, e.g.
mach-ux500?

I would just like the Kconfig dependencies to reflect the "real world":

E.g., if there's no chance the STE modem is going to be used on x86, then let's not ask x86 folks about it.

Does limiting the STE modem to certain platform/architectures make sense ? (if not, that's ok)

Unless there is a good reason why then we shouldn't put arbitrary limits like that. If we leave it in people at least run static analyzers on it and try modprobing it.