On Mon, Oct 1, 2012 at 4:45 AM, Fengguang Wu <[email protected]> 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
?
Hi Sjur,
On Tue, Oct 2, 2012 at 10:24 AM, Ohad Ben-Cohen <[email protected]> wrote:
> On Mon, Oct 1, 2012 at 4:45 AM, Fengguang Wu <[email protected]> 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.
Hi Ohad,
> On Tue, Oct 2, 2012 at 10:24 AM, Ohad Ben-Cohen <[email protected]>
> wrote:
> > On Mon, Oct 1, 2012 at 4:45 AM, Fengguang Wu
> <[email protected]> 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
Hi Sjur,
On Tue, Oct 9, 2012 at 12:30 PM, Sjur BRENDELAND
<[email protected]> 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.
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
> <[email protected]> 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
On Tue, Oct 9, 2012 at 3:28 PM, Dan Carpenter <[email protected]> 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.
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 <[email protected]> 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
On Tue, Oct 9, 2012 at 4:26 PM, Dan Carpenter <[email protected]> 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.
> From: Ohad Ben-Cohen [mailto:[email protected]] Sent: 9. oktober 2012 16:39
> On Tue, Oct 9, 2012 at 4:26 PM, Dan Carpenter
>
> <[email protected]> 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
On Thu, Oct 11, 2012 at 8:49 PM, Sjur BRENDELAND
<[email protected]> 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.