>-----Original Message----- >From: devel <driverdev-devel-bounces@xxxxxxxxxxxxxxxxxxxxxx> On Behalf Of >Previously the next card number was assigned from a static int local variable, >which was read and later incremented. This was not thread- safe, so now we >use an atomic_t and atomic_fetch_add instead. Switching to atomic_fetch_add is definitely an improvement over what that code was doing prior, but is that the proper solution? How do other parts of the kernel handle giving devices unique ID numbers? Honestly, the atomic_t solution might be "good enough". Our PCIe devices get removed and reprobed at least once per boot. We do this so they boot into a "bootloader" program so we can verify that the "production" image stored in the on-board flash is the correct type/version. We then tell the card to reconfigure itself while we remove the PCIe device and then rescan the PCIe bus for the "new" device. That ends up increasing this card count more. This would never be a problem in production (given that we only do this maybe a half dozen times per boot, worst case). Even in dev, we've never reconfigured enough times for this counter to overflow. That was maybe rambling a bit, just wanted to point it out in case there's a "proper" way we should be doing this. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
