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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 287DAC05027 for ; Thu, 2 Feb 2023 11:14:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=eUmA0/Mw+NYl8U9m8tbtaJWeSr+5t7bSNIrNDbaMCdU=; b=2QtIVquHP45Zs/ j8NYWaHw5Lm9ptTIiQRDGH20CkBpoQLkWRKZ2v++4w9LpVk2m0YIJSTOAlDlJOBVPgFuI4cgc/4Lj //S+QqiY4BvydFuxGq6hxdKCwQppsm2aDnmCvJPO0AEPkvxcVNp5cx5pn7EYXEJt4crQvljUC37ze NCGzW9aA3NwcUhJ4cP96T4Awd0fgoWC6gPtw1IxZ9Nkqba5nlF6Ur0TbWysG1MdAgnQHsv5ySfQwB B/PxxVqG5taz9s0l4CnXVpq+J4ldbpwAJtIQuQLhydJ/mkfmFJn9kgGlfVWfpS1Zxw2M9BsjZcLGe g5GQqC1NGnaB4NaxdtiQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pNXXD-00FYpU-Ah; Thu, 02 Feb 2023 11:13:43 +0000 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pNXX9-00FYnh-OQ for linux-arm-kernel@lists.infradead.org; Thu, 02 Feb 2023 11:13:41 +0000 Received: by mail-wm1-x32a.google.com with SMTP id t6-20020a1c7706000000b003dfdaa1d998so704679wmi.0 for ; Thu, 02 Feb 2023 03:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=eyViLD6E5jWQUyig/4yWOniALXO9ZkrdBk4rdwCVU3U=; b=DYHClRngcqEE1zDJ0lS0ihNs5fy2CIGpITprFV0BuWpU//9ue4k4yx4vIm4jxJqJsu RIeiasaRH9g8y+pGGIh95QCCJlMI4ycpZ7KlZKUhrBsa9RVDIrXcYhXdUgTUBGpAz4bo JZwuyu0y9FZeBvXdlslShFgdRHvIjEo5G6euQEEw0MseOjNJD1Ue1l3CDm1hVaQgeOBo qRrnlcc+SJ4ET8VQlW9msUD0sfNCixZUZ3mcd/CLJAlIb5WsiNOb9btuwz0797JhprdN vQuEAhyVUm3nfutPmd6AfpPp+GL8qnAuokaV+r9qm0+XbtJ+CrCfmMlI+j1iOwtHPi3u Ct1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eyViLD6E5jWQUyig/4yWOniALXO9ZkrdBk4rdwCVU3U=; b=Kn9bA0PjSnxno13/cfpvCG3yEQRVJg6FgcWN0oxQkue8iimbTjDl7MdyyjNwQjs4j+ +kfv7lUQg+7jfCEPheOu50EoTkFGkJ5RFYrxN8LJM/n3rH0EHrm8eWuH5RMVVclwf3to j4uecMKL+KIFfrOJ1KrkHcdTZ72cQVLMJ5i3jyhEH6EdQVA4GxZXyZkMujm7L8ocJv93 inF++jYiwpCdt4PUMcRTL23i9wtdbHV8ielXriqMX62hvHFDMb2CXwhQ0nimEWQc3xe9 qngcfTpM21JRo8Fb08tc3LinCKK1MlW3TqKCvgrk1rkv/dpZOvrkkzKqINXZRFmE+3P0 NOtg== X-Gm-Message-State: AO0yUKUa4iA+YHCIbwYqHIWDA5gZicsd7560xIrNVIQT759w1keiT2Ce 3k1gyZXt7aUi+TlE28xKqX+qyQ== X-Google-Smtp-Source: AK7set/MyADSM2GxOa7cX3Nl14EN2MXbfx5PvgBCExukm1vrfPZ/qnHvzT1fTuQac1PO0alosodmAg== X-Received: by 2002:a7b:ce11:0:b0:3dd:37a5:dc90 with SMTP id m17-20020a7bce11000000b003dd37a5dc90mr5483376wmc.32.1675336416011; Thu, 02 Feb 2023 03:13:36 -0800 (PST) Received: from [192.168.1.109] ([178.197.216.144]) by smtp.gmail.com with ESMTPSA id u1-20020a05600c00c100b003a3442f1229sm4416676wmm.29.2023.02.02.03.13.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Feb 2023 03:13:35 -0800 (PST) Message-ID: <57dbcbc6-b497-53db-5a45-abce0e4dcf37@linaro.org> Date: Thu, 2 Feb 2023 12:13:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH 00/23] interconnect: fix racy provider registration Content-Language: en-US To: Johan Hovold , Georgi Djakov Cc: Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Andy Gross , Bjorn Andersson , Konrad Dybcio , Sylwester Nawrocki , =?UTF-8?B?QXJ0dXIgxZp3aWdvxYQ=?= , Alim Akhtar , Thierry Reding , Jonathan Hunter , linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org References: <20230201101559.15529-1-johan+linaro@kernel.org> From: Krzysztof Kozlowski In-Reply-To: <20230201101559.15529-1-johan+linaro@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230202_031339_825944_B0EF2629 X-CRM114-Status: GOOD ( 17.12 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 01/02/2023 11:15, Johan Hovold wrote: > The current interconnect provider interface is inherently racy as > providers are expected to be registered before being fully initialised. > > This can specifically cause racing DT lookups to fail as I recently > noticed when the Qualcomm cpufreq driver failed to probe: > > of_icc_xlate_onecell: invalid index 0 > cpu cpu0: error -EINVAL: error finding src node > cpu cpu0: dev_pm_opp_of_find_icc_paths: Unable to get path0: -22 > qcom-cpufreq-hw: probe of 18591000.cpufreq failed with error -22 > > This only happens very rarely, but the bug is easily reproduced by > increasing the race window by adding an msleep() after registering > osm-l3 interconnect provider. > > Note that the Qualcomm cpufreq driver is especially susceptible to this > race as the interconnect path is looked up from the CPU nodes so that > driver core does not guarantee the probe order even when device links > are enabled (which they not always are). > > This series adds a new interconnect provider registration API which is > used to fix up the interconnect drivers before removing the old racy > API. > So is there a dependency or not? Can you make it clear that I shouldn't take memory controller bits? Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel