From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 219BFC61D90 for ; Tue, 21 Nov 2023 16:36:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229436AbjKUQgO (ORCPT ); Tue, 21 Nov 2023 11:36:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233556AbjKUQgK (ORCPT ); Tue, 21 Nov 2023 11:36:10 -0500 Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D6882D4D; Tue, 21 Nov 2023 08:36:06 -0800 (PST) Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-5c9ea2ec8deso27201887b3.0; Tue, 21 Nov 2023 08:36:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700584566; x=1701189366; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=opRF3HI9iR1tOh502sQV3zy4KipFZOtaQ8YiI2ePgfU=; b=Bt8xfJCUqmJ4qDLUvdO/UVSLfvdODqyTAgSpdNyNMMiJqncTwaAelTLZcLEE3f5hoy zYhtkVjMEjNpn9+TF9x6EFusZH69B9jus4A3xEJh2Pf/nRUaolR3gPgyBrD1UhY+UfKQ Rwsy3l0FS7BbOa8Om5kaNqq8XdcfOOrS17DmRuYVwjuYYbO+cs363uIoXopsgWbd2UvM rScNYoyr3VYHucU9b7EEZ1dKIqIkKWFD/Crt7cCEfvc6bjfQprEhBXc1wPlcxV2JS8wV svH0tEXSmro7I1R/O3ewxsmpHxxjNKHMFzjXw7854eFWYgW1WqzS/uIEGh7tPIn1LUPd LI+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700584566; x=1701189366; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=opRF3HI9iR1tOh502sQV3zy4KipFZOtaQ8YiI2ePgfU=; b=Kph3HJaB5izxU5D1tl42piTNu4MRQlFzLsaODvtCCdgKD32DGwdW4/ydGoxGIxWZTT xkFIX448FBZXRH26OyuSFXNEoWxafrJAUTXv5sl98+ldLejUTbbBsbjLvq0lHInGbhrZ leh+4pOpev59yrIUagGm8cAP0MWzHdOyX4JY/VK94uA+MgObwW4YFUAahZk5XbVvAWkg JthupfxnPz3k+4/Wq3P9CtR3iIYEZCGcy+UdnDOdoyS47F9BFoJ+raf0l9rPVwJK5YnB epFH1d0VSRie2Qk5sBdqQ3zFM3Yh6h9Jvvdpu4Ygto3WBoraLdfFozONyUBcqymdMPUb +wEg== X-Gm-Message-State: AOJu0Yy7fzOdA0RObqVP/ESIftPEhn8151h2iOcvvMWvK8Ji4ziL7Sum F3sK0flX0Qv8ITgN1QmnD9I= X-Google-Smtp-Source: AGHT+IFNHwwELprTDsHUGjfjGbs5039qmlFSUWH64MnHs1X/fR3tPVjej4du8LTpUEsFqN5XQNpe5A== X-Received: by 2002:a05:690c:884:b0:5ca:e8a:adb1 with SMTP id cd4-20020a05690c088400b005ca0e8aadb1mr8158748ywb.1.1700584565985; Tue, 21 Nov 2023 08:36:05 -0800 (PST) Received: from localhost ([2601:344:8301:57f0:e005:b808:45e:1b60]) by smtp.gmail.com with ESMTPSA id y7-20020a0def07000000b005a247c18403sm3169406ywe.37.2023.11.21.08.36.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Nov 2023 08:36:05 -0800 (PST) Date: Tue, 21 Nov 2023 08:36:04 -0800 From: Yury Norov To: Johannes Berg Cc: linux-kernel@vger.kernel.org, Stanislaw Gruszka , Kalle Valo , Gregory Greenman , Hans de Goede , Kees Cook , Miri Korenblit , linux-wireless@vger.kernel.org, Jan Kara , Mirsad Todorovac , Matthew Wilcox , Rasmus Villemoes , Andy Shevchenko , Maxim Kuvyrkov , Alexey Klimov Subject: Re: [PATCH 12/34] wifi: intel: use atomic find_bit() API where appropriate Message-ID: References: <20231118155105.25678-1-yury.norov@gmail.com> <20231118155105.25678-13-yury.norov@gmail.com> <098e2983ac299cb3b33bd0a8e33aaab8d6235909.camel@sipsolutions.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <098e2983ac299cb3b33bd0a8e33aaab8d6235909.camel@sipsolutions.net> Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Sun, Nov 19, 2023 at 08:58:25PM +0100, Johannes Berg wrote: > On Sat, 2023-11-18 at 07:50 -0800, Yury Norov wrote: > > iwlegacy and iwlwifi code opencodes atomic bit allocation/traversing by > > using loops. > > That's really just due to being lazy though, it could use a non-atomic > __test_and_set_bit() would be just fine in all of this, there's always a > mutex held around it that protects the data. Ok, then I'll drop the patch. > Not that it means that the helper is _wrong_, it's just unnecessary, and > you don't have non-atomic versions of these, do you? Not yet. If atomic find_bit() will get merged, and there will be a set of potential users of non-atomic version, I may need to revisit it and add those non-atomic functions. Thanks, Yury