Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp433818pxb; Thu, 19 Nov 2020 05:12:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJynwKXjK3QJmtvjuh6xMt8aMc/u3Nj8Edsme9X3stnDcQhzJCHsbCkn6PO0NCEF/ccwP0it X-Received: by 2002:a50:ff0c:: with SMTP id a12mr11526062edu.79.1605791559870; Thu, 19 Nov 2020 05:12:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605791559; cv=none; d=google.com; s=arc-20160816; b=JjCGgaWvLIIhkYfhsIKdx2iTo12E2ptyhVdL2UkhMWoNa1maTmW9DJFHXPZpFPZAlm 0qBTJUmtsTGr4n6Og2SaFW5NYA+bRRumbeepFy0sIHDYAosfrbbiPKQwejQbdvIYf/bg 7bAb0gctV06m8497BQvBy/spngOkhCLvHwDlNUiIP5+UPfV+CAkW55ywAw0OgTeLzEEo C6bEMo0uCWiiWWdcbPUomjHaNbftUAa4f/kHrAxrOp2kqLswHQ2NcJRhslBYB9y/c064 2U1FXJEMxolHw5Kcc1AR/YRFnlyeCMonPPQ3j75VqSkkJgxEFY+Uz2KD3ID4A8zCSgAc 85WQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=DgJNmb5d39L5sC2K7ZFfhPHNKPV7VNZ5zzYsn5E8uPc=; b=U/8wT8cXwgj3QEb2I2K46LpIKeMnKlSeL6Bgbu/VLxBklRQE4L+aZFrrkelv5W0C3T 7oU4b4UIytqRNjaoVxxpVCWuf2rZlFbnkL2Q1d9Ef42y9fOfr22nDXPwn/QLtUm7C4FL iKn+CYBnmL3epinnWyksxy+i2VZK7c6veuQHTspsgu6opkMcXfQTxxsB6ASDRRpuX7gJ +EA6vejayd2OPPhxs9Zp6OHD4EFu5R+BmE2KP9NtvF9WAowwngaZsfPNxoRlTSXZHBhB sbJL1EevWHgv12dSj8wqEHdItwOcLkUDIZ4pzcyODQnHdPsaCm+JxSeI/B9uEqGwiJ0S 10cg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=OSSDqbZC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d13si17329247ejc.458.2020.11.19.05.12.10; Thu, 19 Nov 2020 05:12:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=OSSDqbZC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727364AbgKSNJe (ORCPT + 99 others); Thu, 19 Nov 2020 08:09:34 -0500 Received: from mail.kernel.org ([198.145.29.99]:34072 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726958AbgKSNJc (ORCPT ); Thu, 19 Nov 2020 08:09:32 -0500 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D41302222A; Thu, 19 Nov 2020 13:09:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1605791371; bh=mKyD0D4431+nPSkk1K26j6VGYlbjIjI6ELP6HkusNrg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OSSDqbZCQ5v7X2wlgIUjU2Riz+C+rxLpL4dHIKhhPWENu18CO82dFxdg8wRr3/w2X U1lHs2UyjN0Il/aNTGwTziobLF636uCxzzjuCjp/tBXlalXMcqomU+aP8USl2gf43w QNYMm1Gfne6Bn9fhq9qG3dCSeFGqPCeMNCXb8NKk= Date: Thu, 19 Nov 2020 14:10:15 +0100 From: Greg Kroah-Hartman To: Aisheng Dong Cc: Saravana Kannan , Sudip Mukherjee , "Rafael J . Wysocki" , linux-kernel , Shawn Guo , Stephen Boyd Subject: Re: [PATCH RESEND] driver core: export device_is_bound() to fix build failure Message-ID: References: <20201109114125.GC1769924@kroah.com> <20201109120512.GB1832201@kroah.com> <20201109124801.GA1890488@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 19, 2020 at 04:13:34AM +0000, Aisheng Dong wrote: > > Long story short, either > > > > * Don't care about the power domain in your clock driver. > > > > Or, > > > > * List the power domain in the clock controller's DT node and then use the > > normal APIs to get the power domain. And defer like any other driver if you > > can't get the power domain. > > > > Yes, I understand those are for normal cases. But our case is a bit different and we don't want > imx_clk_scu() API return PROBE_DEFER which is unnecessary for a hundred of clocks. > Even we want to defer probe, we prefer to defer in imx_clk_scu_init() rather than in imx_clk_scu(). What is wrong with PROBE_DEFER, that is what it is there for. > Maybe the things can be simplified as a simple requirement: > How users can make Driver A (CLK) to be probed after Driver B (PD) without explicit > firmware function dependency description (e.g. phandle in DT)? > > As kernel core does not want to support it, then the left way may be change scu-pd driver > Inicall level or provide a private callback to query the readiness. No, do not mess with that, as it totally breaks when things are built as a module. Rely on the deferred probing, that is what it was designed for, and it should not take very long at all, and it keeps you from having to dig into the driver core in ways that no one else has to. Please just fix up your DT file (sorry I didn't know ordering wouldn't solve this), and you should be fine. thanks, greg k-h