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 3671DC4708E for ; Mon, 28 Nov 2022 14:42:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232593AbiK1OmF (ORCPT ); Mon, 28 Nov 2022 09:42:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34828 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232636AbiK1Olx (ORCPT ); Mon, 28 Nov 2022 09:41:53 -0500 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F0541B7A0; Mon, 28 Nov 2022 06:41:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669646512; x=1701182512; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=yns+R2HE+8EQwUjsmVT40C2yEbZABretYQlqqfAW/0c=; b=Se/4FnUonha0Ujk70F8pZdiJLqT3UNDmFVQ1jBSaF9dKYeRk6Iz5Msy4 XcnMdvXphj1VjQVzP3bPd0g+rp0haDjUlA2EPvg74h5cW1e2jv1+zgruw Q0zuEhYoiYPwhC3xR3WKRkPtSuDBFoIlt8x9sWyqt4rVYbp/b19MWQeKv hkK8/yQJr0VNn6SZPe+0Q4c4Hna6xPdU5LxCJE2dylxC1JVMQ3tjPxnMw bqZNvhdwCMt1SGuN6adRH0j8JoVcggUxwkZxSui/kk9/PHRhwbZ1yv/GE cQUZ3J0pHPJzYPJ4IxpKQ/RpKy/hyKuKSEuNK7elnpA9XsG3UqRbhOUTU Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10545"; a="295232811" X-IronPort-AV: E=Sophos;i="5.96,200,1665471600"; d="scan'208";a="295232811" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2022 06:41:52 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10545"; a="972284888" X-IronPort-AV: E=Sophos;i="5.96,200,1665471600"; d="scan'208";a="972284888" Received: from eliteleevi.tm.intel.com ([10.237.54.20]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2022 06:41:49 -0800 Date: Mon, 28 Nov 2022 16:41:33 +0200 (EET) From: Kai Vehmanen X-X-Sender: kvehmane@eliteleevi.tm.intel.com To: Ricardo Ribalda cc: Liam Girdwood , Pierre-Louis Bossart , Mark Brown , Daniel Baluta , Kai Vehmanen , Peter Ujfalusi , Jaroslav Kysela , Takashi Iwai , Bard Liao , Ranjani Sridharan , Alsa-devel , linux-kernel@vger.kernel.org, stable@vger.kernel.org, sound-open-firmware@alsa-project.org Subject: Re: [PATCH v5] ASoC: SOF: Fix deadlock when shutdown a frozen userspace In-Reply-To: <20221127-snd-freeze-v5-0-4ededeb08ba0@chromium.org> Message-ID: References: <20221127-snd-freeze-v5-0-4ededeb08ba0@chromium.org> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7 02160 Espoo MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Mon, 28 Nov 2022, Ricardo Ribalda wrote: > During kexec(), the userspace is frozen. Therefore we cannot wait for it > to complete. > > Avoid running snd_sof_machine_unregister during shutdown. [...] > /* > - * make sure clients and machine driver(s) are unregistered to force > - * all userspace devices to be closed prior to the DSP shutdown sequence > + * make sure clients are unregistered prior to the DSP shutdown > + * sequence. > */ > sof_unregister_clients(sdev); > > - snd_sof_machine_unregister(sdev, pdata); > - > if (sdev->fw_state == SOF_FW_BOOT_COMPLETE) this is problematic as removing that machine_unregister() call will (at least) bring back an issue on Intel platforms (rare problem hitting S5 on Chromebooks). Not sure how to solve this, but if that call needs to be removed (unsafe to call at shutdown), then we need to rework how SOF does the cleanup. Br, Kai