From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ACBF72EDD40 for ; Thu, 18 Jun 2026 19:18:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781810310; cv=none; b=cLCZ19y4QQbit72nZx3fHGdJSaTEA6z0si+k/x67Ssv8eqY/hkkk1W5NMLEuukqL0xKmsOtirrVGSM9aEc7VPjdH7RUcNvyG9T01KzVKmhGw3zuqAlNpPETWZZAAHfIHSb3Wt3pGFO2/AFYWahoH4Nx2CXJrfYi7oGAswyRVbyI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781810310; c=relaxed/simple; bh=P9S/ro0jLovo+hTyzTjQmckWVQ5guKeABPZquxPYww4=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=rdsmsSuP3msYm006kDqWS1hYlQbIBY/3KIukvCz+u33PaIfLfS3X6lPh/VPhbxm2uKOYwXziM08e38l8zsXAWcS/wkch4PMXesvSQ5uxNAksAUh87WjDVBPWYSRzHVhaJZWhbVT8Jro6e5hqNfTbqn4DsW/7vmEQDaEiSjkMk9I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=A16mBf4C; arc=none smtp.client-ip=209.85.210.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="A16mBf4C" Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-842307472d4so609733b3a.0 for ; Thu, 18 Jun 2026 12:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781810309; x=1782415109; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=43N4w0QFi8owa3jf2IaG5CDpaZZD0IGgzUSSpl41OlI=; b=A16mBf4CyhrLRAHKZBidFABoXEF9x1T5eoV2D7GVw/Gi70BFGe03Rv/2N4Eui0KW/T eVUl2BtyHjrh/E5xzQq4R/QcJncEfmq7Db52M8X9zwVqnZAxCDAStoHSb+XbEa0QQHX7 2H6cZFztkJBWyFdPDBSnP+R95Cm1nuSpBbVY/IqnSNIjPYvdkvHDBoIEgi/76AooIA9V tau2Po+1N+25Pe/cLaDSKIbgyZVzqEIZ6wYQpYtEOoZwKi8pQ0OsDb1pZORMNweoGkfJ xIz/kldYe0kJjOb6IXDeqEhDiPrOq1T0bH4zlox3j12SUp46SsasilZNmkj7cD0ghM+0 wIxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781810309; x=1782415109; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=43N4w0QFi8owa3jf2IaG5CDpaZZD0IGgzUSSpl41OlI=; b=QG66MPCDOVLSMs/ORKE9/eDjSzY60xmfe/DRjJtj199hsREitfCtpVojSObz5UNghA Ffgkt/phD9SiWslvYWuOHoCFnosjhsndxXVMYsOo1TeDlT1EyGojgywCGNSkuUIWpqet Kp0SydJPL9IxFw/6WAgsxFkUjE/khecznM38j9eXmqf8hX5zGqpKuQJwoa0TnubpAnyg h1cSKwqakKm/NXVK78p4/6lBYdo5mCHMcMHjWS3QP709t1L7B+ncJJ9JUnjoxghedJGA LxXQxY2yngr8JI13fRg2tXwav0i9+/dZ2n+VbFxmh9etvKyV0ijo81DVFqwHcU9dzsj1 FCaQ== X-Gm-Message-State: AOJu0YxaAPfyDsFsfkSMU0SrVBQTG0V5qf2+dX7qj9qYWh/3hAf49vmr ehthX75F2akTQo8/CJpnC6cT/orMVAnkMZX6RllLNl061v0/UdcIauQq X-Gm-Gg: AfdE7cmkd9vUsowo2LXuEWCHqsjFN23AAooWPg3/VyUm4vZopl0Lja1IdzV/o8RV3aQ 59efm/Gp/P/NGUstSdNRcDS39bBUhv7I/PDSm3wajmJH2Oo//i9MQj7RT5xJYn/kny8ETQUoQR0 B59u6ez/ghz2GsaTzhz7xi4Rj+v+KWGWBmj/mJ1D9ji0GhPXOXOMXehCnhNZ7lcXYJiCia6kVlF wMWe6/ckmwesF2pivLzCvqSvPPV8wBoTbFw8K9VvSO01J2QMz+BNFBhM0b9jS58uLSiiUNEPHNy odVg136G87KJ+fHgt8uwd3Hy9VlqTUmmbTh2NMtvYE7YxsTtzY2l5DJIKc77SA7tVkaaArWq+Mw dyiu3GrsEzJt7mSTakFb78XhaaHcgMkBXOs3ksW39T4if+infZsnz2FCPb8XO7dXFnFijBqR25S AXTlcmj95r++42DfH0Iyfmk3jqUh85JjoYzGnUJTVsu/jaHDXus6C2W4iPfWC0Ay4dOpYHDaKJx lHIUW6zRqesiyf9R4/07+KBiKESNSlVFmr4ZLwT X-Received: by 2002:a05:6a00:1a8f:b0:845:3ffb:ac2c with SMTP id d2e1a72fcca58-845508d71bcmr229586b3a.46.1781810309055; Thu, 18 Jun 2026 12:18:29 -0700 (PDT) Received: from localhost ([2601:644:8000:5b5d:b427:6f9f:eb5f:94ef]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8434acd96d8sm24450477b3a.19.2026.06.18.12.18.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Jun 2026 12:18:28 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 18 Jun 2026 12:18:27 -0700 Message-Id: Cc: "open list" Subject: Re: [PATCH ath-next] wifi: ath9k: drop static from local pdadc and vpdTable arrays From: "Rosen Penev" To: =?utf-8?q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , "Rosen Penev" , X-Mailer: aerc 0.21.0-0-g5549850facc2 References: <20260616030828.655310-1-rosenp@gmail.com> <87se6kfa9b.fsf@toke.dk> In-Reply-To: <87se6kfa9b.fsf@toke.dk> On Thu Jun 18, 2026 at 2:50 AM PDT, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Rosen Penev writes: > >> Remove the static qualifier from mutable local arrays in three EEPROM >> power-calibration functions. These arrays are written to during normal >> operation, so static storage is both unnecessary and misleading: it >> implies sharing across calls when no such sharing is intended, and it >> makes the code subtly non-reentrant. The sibling function in >> eeprom_9287.c already uses an automatic (stack-local) pdadcValues, >> confirming this is the correct pattern. >> >> This keeps ~1 KB of data off the static data section at the cost of >> stack usage, consistent with the rest of the driver's coding style. > > As pointed out by the test robot, putting this much data on the stack is > a bad idea. Pretty sure it's static for exactly this reason in the first > place. Sashiko points out the opposite: This is a pre-existing issue, but by declaring vpdTableL and vpdTableR as static local variables, doesn't this create thread-unsafe global state? If a system contains multiple ath9k wireless adapters, or if operations like background scans trigger ath9k_hw_reset() concurrently, threads could race to read and write these shared arrays. Could this potentially corrupt the EEPROM calibration data and PDADC hardware configurations across device= s? > > -Toke