On Mon, Mar 03, 2025 at 05:19:05PM +0100, Stefano Garzarella wrote: > On Fri, Feb 28, 2025 at 08:28:19PM -0400, Jason Gunthorpe wrote: > > On Fri, Feb 28, 2025 at 06:07:19PM +0100, Stefano Garzarella wrote: > > > +/* > > > + * tpm_svsm_remove() lives in .exit.text. For drivers registered via > > > + * module_platform_driver_probe() this is ok because they cannot get > > > unbound > > > + * at runtime. So mark the driver struct with __refdata to prevent > > > modpost > > > + * triggering a section mismatch warning. > > > + */ > > > > ??? Is that really true? I didn't know that > > I initially followed drivers/virt/coco/sev-guest/sev-guest.c to figure out > how to clean a driver registered with module_platform_driver_probe(), then I > saw that pattern with the same comment is used in several other drivers. > > > > > I thought you could unbind anything using /sys/../unbind? > > I can't see `unbind` for this driver: > > $ ls /sys/bus/platform/drivers/tpm-svsm/ > module tpm-svsm uevent > > While I can see it for example for others like fw_cfg:
Wow, I didn't know that could be done > BTW I can unload the `tpm-svsm` module. Unload the module and implicitly unbound the driver But not manually unbind the driver?? Huh? That seems pretty wrong.. > Loading it again will cause issues if I don't have a remove function > that calls tpm_chip_unregister(). You definately need the remove function call doing what you have, it is just surprising to me that there is a case where you can statically know it is not callable.. Jason
