From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Matt Sickler Subject: RE: [PATCH v2 5/9] staging: kpc2000: use atomic_t to assign card numbers. Date: Thu, 16 May 2019 22:14:56 +0000 Message-ID: References: <20190516200411.17715-1-jeremy@azazel.net> <20190516213814.22232-1-jeremy@azazel.net> <20190516213814.22232-6-jeremy@azazel.net> In-Reply-To: <20190516213814.22232-6-jeremy@azazel.net> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 List-ID: To: Jeremy Sowden , Linux Driver Project Developer List Cc: Greg KH >-----Original Message----- >From: devel On Behalf Of >Previously the next card number was assigned from a static int local varia= ble, >which was read and later incremented. This was not thread- safe, so now w= e >use an atomic_t and atomic_fetch_add instead. Switching to atomic_fetch_add is definitely an improvement over what that c= ode was doing prior, but is that the proper solution? How do other parts of th= e kernel handle giving devices unique ID numbers? Honestly, the atomic_t solution might be "good enough". Our PCIe devices g= et 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 may= be a half dozen times per boot, worst case). Even in dev, we've never reconfi= gured 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.