On Tue, Jan 28, 2025 at 07:47:43PM +0530, subramanian.mohan@xxxxxxxxx wrote:
> From: Subramanian Mohan <subramanian.mohan@xxxxxxxxx>
>
> While adapting pps generator driver(tio generator as an example)to the new
> generator framework, As part of driver registration the pps_gen_device
> pointer is returned from framework. Due to which there is difficulty in
> getting generator driver data back in enable function. we won’t be able
> to use container_of macro as it results in static assert. we might end up
container_of()
Can you be more specific, what exactly happens?
> in using static pointer. To avoid the same and get back the generator
> driver data back we are proposing generic approach to add drv_prv_data
> pointer inside the struct pps_gen_source_info.
> Example TIO structure wrapped with pps_gen_device and usage.
>
> struct pps_tio {
> /* Framework Related * /
> struct pps_gen_source_info pps_tio_source_info
> struct pps_gen_device *pps_gen;
> };
> static int pps_tio_enable(struct pps_gen_device *pps_gen, bool enable) {
>
> /* Getting TIO data back */
> /* Note: drv_prv_data will be initialized in our init routine */
> struct pps_tio *tio = pps_gen->info.drv_prv_data;
So, what's wrong with the container_of() against pps_gen->info?
We have tons of code in the kernel that does it.
> /* Access tio members here to set some of the parameters */
>
> return 0;
> }
Okay, looking into the implementation I see what's the issue (but it doesn't
mean that commit message is good here, you still need to explain better why
you can't get the correct address).
The problem is that info is got fully copied. Perhaps we should rely on
the fact that it always be provided? I dunno any data structure that defines
callbacks and other "info" material should be considered as temporary storage
(on stack), it makes not much sense.
...
> V1 -> V2:
> * Updated reviewers.
Please, use...
> Signed-off-by: Subramanian Mohan <subramanian.mohan@xxxxxxxxx>
> ---
...this place for the comments and changelogs.
...
> + void *drv_prv_data;
If really needed we should probably use a better name, like "private".
--
With Best Regards,
Andy Shevchenko
