[lkml]   [2012]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 7/7] remoteproc: Add custom STE-modem firmware loader.
Hi Sjur,

On Wed, Jun 6, 2012 at 4:38 PM, <> wrote:
> From: Sjur Brændeland <>
> Add custom firmware loader for STE firmware. This plugin adds
> functions for extracting the resource table and loading the
> firmware image into shared memory.
> Signed-off-by: Sjur Brændeland <>

Nice patch!

> +struct rproc_fw_ops rproc_ste_modem_fw_ops = {
> +       .load = ste_load_segments,
> +       .find_rsc_table = ste_find_rsc_table
> +};
> +EXPORT_SYMBOL(rproc_ste_modem_fw_ops);

After you told me there's no simple & robust way to dynamically probe
the STE binary format, I agree it'd make sense to allow low-lever
drivers to statically impose it.

I'm just still not sure we want to publicly export those fw_ops
symbols throughout the kernel.

Alternatively, we can do something like how i2c algos are determined:
expose a rproc_set_ste_modem_fw() function, which takes an rproc
struct, and then sets the fw_ops to rproc_ste_modem_fw_ops. Then call
it from your driver after rproc_alloc() but before rproc_register().

This way only statically-format-imposing drivers will call those
functions, and all others, who use generic and detectable formats,
will just follow the current registration scheme (so no extra param
needed to rproc_alloc either). In the long term those generic formats
will be dynamically detected, but meanwhile, we can just set ELF as
the default.

What do you think?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2012-06-10 20:01    [W:0.137 / U:2.924 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site