From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6313E326937 for ; Sun, 25 Jan 2026 16:43:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769359420; cv=none; b=BWxTSX0OpC+LVnghhNdoVZ+goahctq7fuQmR/CSd11N9TDGAsRrFmsqj8wVKt0Rg3hC5MAp+TP5+XN6igsl+M7sNgaXjS/ftx7HWeuLUuIPkhLn6UlBIE5ZcGFYYP/NaU0vZ2SFfX7gRrC09n7VuFsdBUGz0XrFgoQijomSNXTQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769359420; c=relaxed/simple; bh=oiMqEqVzpbE6p4wS4Kx4lMgFfYQx7fgX7TXIekKzhmg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=vExrAzkzMeHVZT2orYoCDlydVg+MVkMhTo6BrXJL29T64E5P3EjwHjw1+8sGQkp86n/fp38WE+hGi+U+7bvC0eH3IM0pBSl9JHrCXto0vGV0oz0Up2ZancK4mWRe7XA4l4G7hWdp3rui9CBhEFwSIV75stDBf0eQsoJ7U6i8LVY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KxDvP0J0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KxDvP0J0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 77336C4CEF1; Sun, 25 Jan 2026 16:43:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769359419; bh=oiMqEqVzpbE6p4wS4Kx4lMgFfYQx7fgX7TXIekKzhmg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KxDvP0J0HUBkf1Ax0mhdlWC81t8aOCNRgPqQGNEZfN63Xy3fy6c8cpeTBts++Wia/ h1mN/e+6RaGEc7levlO6ZkbiiAiMPrfglk/C1P4nn6CFDkAzQf7erNi/yNvnKD2S3r tqIKFcmadtVhiZJt1pKsr+kM+dWjYzV3ijFDZrX4M01HIt4QCoAchEg4B0X93VSmZS oWQwC6qSsBKmJOrzlpEQ9NceXDAhKlkf5y4tusDwpWb3sdO95DpD8uktoHHiwj/Kte 2+oqEs77bLcL1oGHYv3cdZoMjp2H7XwiyKO9etV/6RS9h1W9P3j9DXFUANFkkasfcF MlNSQc54T+a6w== Date: Sun, 25 Jan 2026 18:43:35 +0200 From: Leon Romanovsky To: Pavan Chebbi Cc: jgg@ziepe.ca, michael.chan@broadcom.com, linux-kernel@vger.kernel.org, dave.jiang@intel.com, saeedm@nvidia.com, Jonathan.Cameron@huawei.com, gospo@broadcom.com, selvin.xavier@broadcom.com, kalesh-anakkur.purayil@broadcom.com Subject: Re: [PATCH fwctl 2/5] fwctl/bnxt_en: Refactor aux bus functions to be more generic Message-ID: <20260125164335.GG13967@unreal> References: <20260118123401.3188438-1-pavan.chebbi@broadcom.com> <20260118123401.3188438-3-pavan.chebbi@broadcom.com> <20260125130910.GB13967@unreal> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sun, Jan 25, 2026 at 07:20:28PM +0530, Pavan Chebbi wrote: > > > + int auxdev_id; > > > + atomic_t auxdev_state[__BNXT_AUXDEV_MAX]; > > > +#define BNXT_ADEV_STATE_NONE 0 > > > +#define BNXT_ADEV_STATE_INIT 1 > > > +#define BNXT_ADEV_STATE_ADD 2 > > > > This is indeed an incorrect use of atomic_t. This type only ensures that > > individual arithmetic operations are performed atomically. It does not > > eliminate the need for the locks that were removed. > > Thanks for your review. Since the individual bp's auxdev state is > going to be set only during probe(), and is read-only elsewhere, > atomic operations are enough, no? No. You can change the state of a specific auxdev by unbinding its driver. You must hold the appropriate lock whenever you read or depend on auxdev_state, and an atomic_t is not required for this case. Thanks