Re: [PATCH v3 2/2] Input: synaptics-rmi4 - add support for F34 device reflash

[Nick Dyer]

On Thu, Oct 13, 2016 at 03:52:45PM +0200, Benjamin Tissoires wrote:
> > > You could basically export rmi_fn_reset() which would call
> > > rmi_free_function_list(), rmi_scan_pdt (if initial reset),
> > > rmi_probe_interrupts() and rmi_init_functions, and this would allow you
> > > to have all this in f34.
> > 
> > I see what you mean, and I do agree that it would be neater to have all
> > of this in the f34 code.
> > 
> > However, the problem is that when you call rmi_free_function_list(), the
> > f34 driver and all the context information attached to it (struct
> > rmi_function, struct f34_data, and any sysfs attributes in the f34
> > directory) gets torn down, so you're kind of left without the branch you
> > were sitting on.
> > 
> > To get around that, I'd have to make f34 a special case anyway. Taking
> > that into account, the current solution seemed neater to me. I could
> > possibly cram a little more of it into rmi_f34.c, but I think the
> > context has to be "struct rmi_driver_data".
> 
> If I understand correctly, rmi_firmware_update() is only called through
> the sysfs. So how about you export the required functions from core you
> are using and export 2 functions from rmi_f34 that will be a special
> case: rmi_f34_create_sysfs() and rmi_f34_remove_sysfs() (or any better
> names). You could just put your code in rmi_f34, provide noops
> declarations if RMI_F34 is not set, and core will have only 2 calls to
> rmi_f34.

OK: I will have a go at achieving this over the next few days. I also
have some changes almost ready to add F34 bootloader V7 support.

> BTW, I am thinking at carrying in my next RMI4 series your 1/2 patch. I
> also want to take Bjorn and Andrew left patches so that we have a common
> tree at some point. Any objections? 
> Of course, if you resubmit before me, feel free to carry over 1/2.

Sounds like a good idea, it will reduce merging difficulty later.

N