Re: [PATCH 6/8] remoteproc: Move resource table load logic to find

[Bjorn Andersson]

On Thu 14 Dec 03:25 PST 2017, Loic PALLARDY wrote:
> > -----Original Message-----
> > From: linux-remoteproc-owner@xxxxxxxxxxxxxxx [mailto:linux-remoteproc-
> > owner@xxxxxxxxxxxxxxx] On Behalf Of Bjorn Andersson
> > Sent: Wednesday, December 13, 2017 11:41 PM
[..]
> > -struct resource_table *rproc_elf_find_rsc_table(struct rproc *rproc,
> > -						const struct firmware *fw,
> > -						int *tablesz)
> > +int rproc_elf_load_rsc_table(struct rproc *rproc, const struct firmware *fw)
> >  {
> >  	struct elf32_hdr *ehdr;
> >  	struct elf32_shdr *shdr;
> >  	struct device *dev = &rproc->dev;
> >  	struct resource_table *table = NULL;
> >  	const u8 *elf_data = fw->data;
> > +	size_t tablesz;
> > 
> >  	ehdr = (struct elf32_hdr *)elf_data;
> > 
> >  	shdr = find_table(dev, ehdr, fw->size);
> >  	if (!shdr)
> > -		return NULL;
> > +		return -EINVAL;
> > 
> >  	table = (struct resource_table *)(elf_data + shdr->sh_offset);
> > -	*tablesz = shdr->sh_size;
> > +	tablesz = shdr->sh_size;
> > +
> > +	/*
> > +	 * Create a copy of the resource table. When a virtio device starts
> > +	 * and calls vring_new_virtqueue() the address of the allocated vring
> > +	 * will be stored in the cached_table. Before the device is started,
> > +	 * cached_table will be copied into device memory.
> > +	 */
> > +	rproc->cached_table = kmemdup(table, tablesz, GFP_KERNEL);
> > +	if (!rproc->cached_table)
> > +		return -ENOMEM;
> > 
> > -	return table;
> > +	rproc->table_ptr = rproc->cached_table;
> > +	rproc->table_sz = tablesz;
> > +
> > +	return 0;
> >  }
> > -EXPORT_SYMBOL(rproc_elf_find_rsc_table);
> > +EXPORT_SYMBOL(rproc_elf_load_rsc_table);
> [LPA] Hi Bjorn,
> 
> I understand the simplification of the  code, but I would like to keep
> rproc_elf_find_rsc_table function as helper one.  Indeed if a driver
> wants to override the default rproc_elf_load_rsc_table, it may have to
> parse first the elf file to look up for resource table using
> rproc_elf_find_rsc_table as helper.

find_table() finds the .resource_table segment and verifies that this
contains a valid, version 1, resource table.

So AFAICT there are two scenarios here:
1) A driver wants to support custom entries in the resource table, for
which Suman's proposal of adding a way for drivers to implement custom
properties seems like a good solution.

2) A driver wants to support something other than a v1 resource table,
in which case they would need to reimplement find_table() anyways.


It's possible that the part of find_table() that looks up the segment by
name could be exposed for drivers to use this, but half of find_table()
deals with verifying that the content is a proper resource table.

Please let me know if you have a use case beyond these.

Regards,
Bjorn