Messages in this thread | | | From | Ohad Ben-Cohen <> | Date | Sun, 10 Jun 2012 20:25:51 +0300 | Subject | Re: [PATCH 7/7] remoteproc: Add custom STE-modem firmware loader. |
| |
Hi Sjur,
On Wed, Jun 6, 2012 at 4:38 PM, <sjur.brandeland@stericsson.com> wrote: > From: Sjur Brændeland <sjur.brandeland@stericsson.com> > > 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 <sjur.brandeland@stericsson.com>
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?
Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |