There's a race with runtime PM getting enabled by userspace:
 - we rescan the PCI bus
 - this creates the new PCI device including its sysfs
   representation
 - udev sees the new device, and the (OS-specific?) scripting
   enables runtime PM by writing to power/control; this can
   happen _before_ the next step - this will runtime-suspend
   the device which saves the config space, including the BAR0
   that wasn't assigned yet
 - the bus rescan assigns resources to the devices and writes
   them to the config space of the device
   (but not the runtime-pm saved copy)
 - the driver binds and this disallows runtime PM, so the device
   is resumed, restoring the (incomplete!) config space
 - the driver cannot work due to BAR0 not being configured

Fixing the actual race is hard and deep in the PCI layer,
though probably should be done for upstream as well; perhaps
runtime PM should only be allowed after resource assignment,
or some other TBD way.

Work around this in the driver for now by simply (re-)assigning
BAR0 when the driver initializes, if it's unset.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230921110726.5f5f782a4e97.I4b7bf5c52ba44a8c7f9878009021689bbfa9c5ef@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>