| Message ID | 20210519160811.183102-1-rasmus.villemoes@prevas.dk |
|---|---|
| State | Accepted |
| Commit | 98c14ff019515ffcb1b40b550e56fe1dfbede51b |
| Delegated to: | Simon Glass |
| Headers | show |
| Series | remove struct uclass_driver::ops | expand |
On Wed, 19 May 2021 at 10:08, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote: > > Each _device_ belonging to a given uclass of course has its own ->ops, > of a type determined by and known to the uclass. > > However, no instance of a uclass_driver seems to populate ->ops, and > the only reference to it in code is this relocation. > > Moreover, it's not really clear what could sensibly be assigned; it > would have to be some "struct uclass_ops *" providing a set of methods > for the core to call on that particular uclass, but should the need > for that ever arise, it would be better to have a member of that > particular type instead of void*. > > Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> > --- > drivers/core/root.c | 3 --- > include/dm/uclass.h | 3 --- > 2 files changed, 6 deletions(-) Reviewed-by: Simon Glass <sjg@chromium.org>
On Wed, 19 May 2021 at 10:08, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote: > > Each _device_ belonging to a given uclass of course has its own ->ops, > of a type determined by and known to the uclass. > > However, no instance of a uclass_driver seems to populate ->ops, and > the only reference to it in code is this relocation. > > Moreover, it's not really clear what could sensibly be assigned; it > would have to be some "struct uclass_ops *" providing a set of methods > for the core to call on that particular uclass, but should the need > for that ever arise, it would be better to have a member of that > particular type instead of void*. > > Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> > --- > drivers/core/root.c | 3 --- > include/dm/uclass.h | 3 --- > 2 files changed, 6 deletions(-) Reviewed-by: Simon Glass <sjg@chromium.org> Applied to u-boot-dm/next, thanks!
diff --git a/drivers/core/root.c b/drivers/core/root.c index fe0562cd6f..a03661bf06 100644 --- a/drivers/core/root.c +++ b/drivers/core/root.c @@ -111,9 +111,6 @@ void fix_uclass(void) entry->init += gd->reloc_off; if (entry->destroy) entry->destroy += gd->reloc_off; - /* FIXME maybe also need to fix these ops */ - if (entry->ops) - entry->ops += gd->reloc_off; } } diff --git a/include/dm/uclass.h b/include/dm/uclass.h index 6752d8ee0b..2778818b52 100644 --- a/include/dm/uclass.h +++ b/include/dm/uclass.h @@ -84,8 +84,6 @@ struct udevice; * its children. If non-zero this is the size of this data, to be allocated * in the child device's parent_plat pointer. This value is only used as * a fallback if this member is 0 in the driver. - * @ops: Uclass operations, providing the consistent interface to devices - * within the uclass. * @flags: Flags for this uclass (DM_UC_...) */ struct uclass_driver { @@ -106,7 +104,6 @@ struct uclass_driver { int per_device_plat_auto; int per_child_auto; int per_child_plat_auto; - const void *ops; uint32_t flags; };
Each _device_ belonging to a given uclass of course has its own ->ops, of a type determined by and known to the uclass. However, no instance of a uclass_driver seems to populate ->ops, and the only reference to it in code is this relocation. Moreover, it's not really clear what could sensibly be assigned; it would have to be some "struct uclass_ops *" providing a set of methods for the core to call on that particular uclass, but should the need for that ever arise, it would be better to have a member of that particular type instead of void*. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> --- drivers/core/root.c | 3 --- include/dm/uclass.h | 3 --- 2 files changed, 6 deletions(-)