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 (
Date:Oct 9, 2012 6:28:47 am

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 <> wrote:

Sorry for not responding sooner, but I thought this issue was solved with your patch "remoteproc: fix (again) the virtio-related build breakage" (

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.

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.