Re: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e): undefined reference to `vring_transport_features'

Re: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e): undefined reference to `vring_transport_features'

[Ohad Ben-Cohen]

On Mon, Oct 1, 2012 at 4:45 AM, Fengguang Wu <fengguang.wu@intel.com> wrote:
> Hi Ohad,
>
> FYI, kernel build failed on
>
> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git for-next
> head:   bec109a430e8c67bae1743f7e71898283234a77f
> commit: ec4d02d9180f407c41f8310a13b34e473c671fbb [6/9] remoteproc: Add STE modem driver
> config: i386-randconfig-b102 (attached as .config)
>
> It should be an old bug. The commit happen to be the one to trigger
> the errors because it selects CONFIG_EMOTEPROC.

Thanks Fengguang.

This should be fixed by a patch I pushed today to remoteproc's for-next branch.

Though I wonder, Sjur, do we want to limit the architectures/platforms
where the STE modem driver can be selected on ? Is it ARM only perhaps
?

Re: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e): undefined reference to `vring_transport_features'

[Ohad Ben-Cohen]

Hi Sjur,

On Tue, Oct 2, 2012 at 10:24 AM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> On Mon, Oct 1, 2012 at 4:45 AM, Fengguang Wu <fengguang.wu@intel.com> wrote:
>> Hi Ohad,
>>
>> FYI, kernel build failed on
>>
>> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git for-next
>> head:   bec109a430e8c67bae1743f7e71898283234a77f
>> commit: ec4d02d9180f407c41f8310a13b34e473c671fbb [6/9] remoteproc: Add STE modem driver
>> config: i386-randconfig-b102 (attached as .config)
>>
>> It should be an old bug. The commit happen to be the one to trigger
>> the errors because it selects CONFIG_EMOTEPROC.
>
> Thanks Fengguang.
>
> This should be fixed by a patch I pushed today to remoteproc's for-next branch.
>
> Though I wonder, Sjur, do we want to limit the architectures/platforms
> where the STE modem driver can be selected on ? Is it ARM only perhaps ?

Can you please address the above question ?

Thanks,
Ohad.

RE: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e): undefined reference to `vring_transport_features'

[Sjur BRENDELAND]

Hi Ohad,

> On Tue, Oct 2, 2012 at 10:24 AM, Ohad Ben-Cohen <ohad@wizery.com>
> wrote:
> > On Mon, Oct 1, 2012 at 4:45 AM, Fengguang Wu
> <fengguang.wu@intel.com> wrote:
> >> Hi Ohad,
> >>
> >> FYI, kernel build failed on
> >>
> >> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
> for-next
> >> head:   bec109a430e8c67bae1743f7e71898283234a77f
> >> commit: ec4d02d9180f407c41f8310a13b34e473c671fbb [6/9] remoteproc:
> Add STE modem driver
> >> config: i386-randconfig-b102 (attached as .config)
> >>
> >> It should be an old bug. The commit happen to be the one to trigger
> >> the errors because it selects CONFIG_EMOTEPROC.
> >
> > Thanks Fengguang.
> >
> > This should be fixed by a patch I pushed today to remoteproc's for-next
> branch.
> >
> > Though I wonder, Sjur, do we want to limit the architectures/platforms
> > where the STE modem driver can be selected on ? Is it ARM only perhaps ?
> 
> Can you please address the above question ?

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?

Regards,
Sjur

Re: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e): undefined reference to `vring_transport_features'

[Ohad Ben-Cohen]

Hi Sjur,

On Tue, Oct 9, 2012 at 12:30 PM, Sjur BRENDELAND
<sjur.brandeland@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)

Thanks,
Ohad.

Re: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e): undefined reference to `vring_transport_features'

[Dan Carpenter]

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@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.

regards,
dan carpenter

Re: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e): undefined reference to `vring_transport_features'

[Ohad Ben-Cohen]

On Tue, Oct 9, 2012 at 3:28 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Unless there is a good reason why

That's what I'm asking. Is there an inherent coupling with some
platform/architecture ? E.g., OMAP remote processors only go with
OMAP chips.

Re: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e): undefined reference to `vring_transport_features'

[Dan Carpenter]

On Tue, Oct 09, 2012 at 04:15:15PM +0200, Ohad Ben-Cohen wrote:
> On Tue, Oct 9, 2012 at 3:28 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > Unless there is a good reason why
> 
> That's what I'm asking. Is there an inherent coupling with some
> platform/architecture ? E.g., OMAP remote processors only go with
> OMAP chips.

If it already compiles fine on x86 then there is no advantage to
disabling it.

regards,
dan carpenter

Re: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e): undefined reference to `vring_transport_features'

[Ohad Ben-Cohen]

On Tue, Oct 9, 2012 at 4:26 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> If it already compiles fine on x86 then there is no advantage to
> disabling it.

Not really; that's really a hardware question and not a software one.

There are hardware devices that can go with any platform/architecture,
e.g., WLAN chips. OTOH, there are a lot of hardware devices that are
coupled with certain SoC, e.g. OMAP's remote processors.

What I'm trying to understand is whether the STE modem device belongs
to the former or latter group. It sounds like a modem belongs to the
former group, but if it does belong to the latter, then the building
of its driver should be possible only on the relevant
platforms/architectures.

Thanks,
Ohad.

RE: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e): undefined reference to `vring_transport_features'

[Sjur BRENDELAND]

> From: Ohad Ben-Cohen [mailto:ohad@wizery.com] Sent: 9. oktober 2012 16:39
> On Tue, Oct 9, 2012 at 4:26 PM, Dan Carpenter
>
> <dan.carpenter@oracle.com> wrote:
>> If it already compiles fine on x86 then there is no advantage to
>> disabling it.
> 
> Not really; that's really a hardware question and not a software one.
> 
> There are hardware devices that can go with any platform/architecture,
> e.g., WLAN chips. OTOH, there are a lot of hardware devices that are
> coupled with certain SoC, e.g. OMAP's remote processors.
> 
> What I'm trying to understand is whether the STE modem device belongs
> to the former or latter group. It sounds like a modem belongs to the
> former group, but if it does belong to the latter, then the building
> of its driver should be possible only on the relevant
> platforms/architectures.

This driver is intended for NovaThor SoC and for a configuration with
LLI as the shared memory interface between the host and modem.
When using LLI as the shared memory interface the modem could be used
with any platform/architecture with little endian byte sex and a LLI
interface. So I guess this driver belongs in the former group you
mention, and should probably not be dependent on ARM only.

Thanks,
Sjur

Re: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e): undefined reference to `vring_transport_features'

[Ohad Ben-Cohen]

On Thu, Oct 11, 2012 at 8:49 PM, Sjur BRENDELAND
<sjur.brandeland@stericsson.com> wrote:
> This driver is intended for NovaThor SoC and for a configuration with
> LLI as the shared memory interface between the host and modem.
> When using LLI as the shared memory interface the modem could be used
> with any platform/architecture with little endian byte sex and a LLI
> interface. So I guess this driver belongs in the former group you
> mention, and should probably not be dependent on ARM only.

Ok, thanks for the information.

Ohad.