From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f177.google.com (mail-dy1-f177.google.com [74.125.82.177]) (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 2119B36E483 for ; Tue, 24 Mar 2026 11:13:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774350787; cv=none; b=jDg/sIhN9Ih29vfiP7cdlBR4ANEfoxGmCobr9BneTWujFo4PO3Hy1SBTJ+u9rvHzNKPj0uCOXqKjQQb7f/KQ9q02obzCygXfR/fhXVIP5/+m31WNGYxAXQcHwP/FCAY3JtxVz/zPj+UWOjFYTc3ttGS3oTWKel4z4mX1fY4E1xY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774350787; c=relaxed/simple; bh=XLBjDdo6A6F1D0HM9nREF1ojvBHwPFAqF4vFIUFByq4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Wye4hd7Ge9nJS9HISUwjzCOPhQDvuA9O7/eZ4o99klfPhYA0bLt13PUV02Dnm76KvLUyonPVQyl3bcAbcI8I++7ITinx6VT2C602fArUFCScCFu2RzEGnc2KScr1wiwyNaCCtSCEwF3hb0EkM1P0AgJEDANtmVWx/Cp74gHAwdM= 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=foLXXnWL; arc=none smtp.client-ip=74.125.82.177 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="foLXXnWL" Received: by mail-dy1-f177.google.com with SMTP id 5a478bee46e88-2c107ef474fso2650080eec.0 for ; Tue, 24 Mar 2026 04:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774350785; x=1774955585; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=rlr0EBhETDVXxYhev/vowRNn4txadi487PR9lj+/9AQ=; b=foLXXnWLanxwmV8eyxVg5cVgrBjbCkkq9t1W3sofv7pFJGNeiq+2AtyyRoHjyeARSQ LX2ibU8n8UnBXKhO+278TD7TgHzAFNoeMQHbziLDVj1BPpiKG/NaCi0hAUlw5l5xX60q Ak7VdkWtUmtQzteRrR/wUaDQakYr3mgbRmqeiet3IRrnVIbPU5G0aezN/KZNRpC1SRmT PmvJD0bVbqMHsYKMuHl41NPiB/WpOWCmH+74G7z4+9SVTDzkieZ5HLA2MUajL4/aNkna N32NytITFh5sy/yUIyjFpCSNAvVJhMPgwJjPpkAxNBhwtwJTpd7YxzKMlg8LNZbKYFdd MM1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774350785; x=1774955585; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rlr0EBhETDVXxYhev/vowRNn4txadi487PR9lj+/9AQ=; b=iIBD8xr6zfQzQdMrVV3pL1wQSVSQU+IIU/ZF6O98Jrpt/FJ3HqM+wmQJ/r3q9YE+Lt w/ezc+HfIua1WyMvVWEkfcQerpSx323LXdOx0s7Q8Y45lJsBVkygACY1BIlj/ddgvswd WNhzUE5KWne5x3+NNiKhmtwGOOGP608Jwa/M1zzzzmSRfCgqJbbwD50Ly+d14Yr0marW 4Es9XUcDB6WLQd5AKCXkNJoTR1xv75taj1U+0Fq9iC94Ztu8bvfKbTKXcsoik2u6K3Ll bNagQv2Kpo6dGSDae4GnJUE1lXwfHhmSiWh/Yu842gL4x+iGOUa7fyqM+w43jqFOaOTA y9Cg== X-Forwarded-Encrypted: i=1; AJvYcCWtBLHn923Q/tM+n6b2/bQbbN/UKIzsc0bJ06duDe8mkAoq1l+yW8Tl+4LwDGFvWYYmk2jq81x6WeWzPuQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxYFuwwdxwqo+xsFeRKaKk0VUvkAybOd5ATq4Fzs9lZd+7HR+3t sI+qFC6ZLclm7gMN15DHJC4fDdUJWOKkjCN2uCgMUb+svZnogu7BO+2b X-Gm-Gg: ATEYQzyKvjEsBhlREBi2dfq/DokPYHbHK3J7fvhZ/MtpFT/oglwWTL4hswAalfppRWr GJHIVzq8HMcpIoD8ySUkk/KxI3qOrOHSRQTFroeeebSqnoYjYXYKznBtC55qE1VPbdiq+2RM6/J Ez7+BIozpXI+hzZdRLEA9xlvsPCPrzaoBwN4IpE9cQIEx6Kk5FsepAAImxBhFEABC2vRb+iFxro 5HyndAiuW48uSphsk8KdWArc4w8aLN8bslJnmg9FN0l51v5nuWnmYTxQhYHxOUpipMOeJ2l1V/K 5LEWACK78IqweDMlsf2iejX8Uo1XYIUfgDTy1Cr6Cp31WPXjJ5IXHe6h7DZQcp6mF8TR96E4qtk 0Pd0zcAiXdMv9P6agawLWvm3smGOi9AbRKfBbEzPW4Z+JR3TaFBK2Nilkj4trnIdsY7QNF4fQJm R6yVseHcACx7sNjZxvRbA7uyBZEL8fUwoYwIFtS1OmwJ/82Lvtf5P+eOGTuwSzIuct7+IEbA== X-Received: by 2002:a05:7300:3c05:b0:2be:140c:bc4a with SMTP id 5a478bee46e88-2c1095d7855mr8442227eec.3.1774350784989; Tue, 24 Mar 2026 04:13:04 -0700 (PDT) Received: from localhost (177-4-160-195.user3p.v-tal.net.br. [177.4.160.195]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2c1536aa870sm1187186eec.2.2026.03.24.04.13.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Mar 2026 04:13:04 -0700 (PDT) Date: Tue, 24 Mar 2026 08:13:01 -0300 From: =?utf-8?Q?C=C3=A1ssio?= Gabriel To: Charles Keepax Cc: Maciej Strozek , Bard Liao , Pierre-Louis Bossart , Jaroslav Kysela , Takashi Iwai , Liam Girdwood , Mark Brown , linux-sound@vger.kernel.org, patches@opensource.cirrus.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ASoC: SDCA: Write init table on function status IRQ Message-ID: References: <20260324-sdca-function-status-init-irq-v1-1-bba49417a4e0@gmail.com> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Mar 24, 2026 at 09:20:38AM +0000, Charles Keepax wrote: > On Tue, Mar 24, 2026 at 12:03:59AM -0300, Cássio Gabriel wrote: > > The function status IRQ handler currently acknowledges > > SDCA_CTL_ENTITY_0_FUNCTION_NEEDS_INITIALIZATION but does > > not perform the function initialization writes. Since the > > handler clears the function status register afterwards, > > the request is lost. > > > > Use sdca_regmap_write_init() when the initialization status > > bit is reported and apply the writes through the device regmap > > stored in the IRQ data, matching the existing class-function > > boot and resume paths. > > Generally speaking the init writes should have happened as part > of the device boot. What are the circumstances where you are > encountering this? > > Thanks, > Charles Hi Charles, This was found by inspection rather than from a concrete hardware reproducer. What drew my attention was that the current class-function boot and resume paths already handle FUNCTION_NEEDS_INITIALIZATION by replaying the init table, while the function-status IRQ handler would just acknowledge and clear the same bit. My concern was that, if the bit can legitimately appear in the normal IRQ path, it would be dropped without taking the same initialization action. I do not currently have hardware evidence showing that this case is actually reachable, so I will drop the patch for now. Thanks, Cássio