[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121009132847.GC4587@mwanda>
Date: Tue, 9 Oct 2012 16:28:47 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: Ohad Ben-Cohen <ohad@...ery.com>
Cc: Sjur BRENDELAND <sjur.brandeland@...ricsson.com>,
Fengguang Wu <fengguang.wu@...el.com>,
"Linus Walleij (linus.walleij@...aro.org)" <linus.walleij@...aro.org>,
"kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e):
undefined reference to `vring_transport_features'
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.brandeland@...ricsson.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.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists