On Tue, Jul 28, 2026 at 10:09:58PM +0000, David Matlack wrote: > Document how driver binding works during a Live Update and what the PCI > core expects of drivers and users. Note that this is only a description > of the current division of responsibilities. These can change in the > future if we decide. > > Reviewed-by: Pasha Tatashin <[email protected]> > Reviewed-by: Pranjal Shrivastava <[email protected]> > Reviewed-by: Samiullah Khawaja <[email protected]> > Signed-off-by: David Matlack <[email protected]> > --- > drivers/pci/liveupdate.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/drivers/pci/liveupdate.c b/drivers/pci/liveupdate.c > index 5ce5f8b36902..0f7a018ddc66 100644 > --- a/drivers/pci/liveupdate.c > +++ b/drivers/pci/liveupdate.c > @@ -71,6 +71,22 @@ > * > * * The device cannot be a Virtual Function (VF). > * * The device cannot be behind a PCI-to-PCI bridge. > + * > + * Driver Binding > + * ============== > + * > + * In the outgoing kernel, it is the driver's responsibility to ensure that > it > + * does not release a device between pci_liveupdate_preserve() and > + * pci_liveupdate_unpreserve().
Possibly "the driver must ensure" or even "the driver must not release ..." Also could apply below. > + * In the incoming kernel, it is the driver's responsibility to ensure that > it > + * does not release a preserved device between probe() and > + * pci_liveupdate_finish(). > + * > + * It is the user's responsibility to ensure that incoming preserved devices > are > + * bound to the correct driver. i.e. The PCI core does not protect against a > + * device getting preserved by driver A in the outgoing kernel and then > getting > + * bound to driver B in the incoming kernel. This may change in the future. Same "i.e." nit. Not sure we need to be reminded that things may change in the future :)
