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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6833BC83003 for ; Wed, 29 Apr 2020 07:33:50 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 3A967206D9 for ; Wed, 29 Apr 2020 07:33:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="CU5qFWVB"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="pdoTOIrw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3A967206D9 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4SSJcHCaM8Xi695dJBQEi55O+4QjYDP3Qdh+dJ+b5Ro=; b=CU5qFWVB1Yi2Ys e2WlDkFlft1MKz30zIHE6nqMdfQHIGWOG+m6w/lDuXnYp0lFPk52tmTEVxe7PyWoN/b5soxS/mz7+ +5L0CFQCN8X76R9LH858sLy47KxUMCHXrasGUkfYdNuspLXvuTwiOvwRMRplmJ0m8oDmnWUcYotkf Q0/ZpItv5AdTTXHwJizKMBHNnZEc8ttAobfUNYwCEX/Yzz+kZP3alsS9qpVAwl+J4Zi6/XOa6sR3b fM4TlBahB1dG7J/QchO9C4w1gnpoM8n9YV7ISS+8jFKcyJZoV9427x7yWuaLlI4pxOXtU/hzORIJa sAlEZ4RLBBMzOXqexyFQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jThE5-0005FB-Rc; Wed, 29 Apr 2020 07:33:49 +0000 Received: from mail-oi1-x244.google.com ([2607:f8b0:4864:20::244]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jThE2-0005Ec-Bq for linux-arm-kernel@lists.infradead.org; Wed, 29 Apr 2020 07:33:48 +0000 Received: by mail-oi1-x244.google.com with SMTP id o24so1004253oic.0 for ; Wed, 29 Apr 2020 00:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IcXQ08t2W8c/2dEBG4FRM5sIS4gP2ylI5VKbzNwowo0=; b=pdoTOIrw610Yqb9QtrA+nZF4Kva/D5G2N3zjYWZXMdkAUfrUlm7sOlp5U0uF3XGpER zPRGwW0FMnLgx2soQnoByHaaL5Drp8C1wf/UdvvSl6Z4gq+PZpE1R2ET/1NOFEVh7e0Q lC7214F2D663aUmf188X+MY7XQBPK/1SDwNwFfqHx17klMxLBgUgZ9dOK4ekIrTOChlR fnoN2LkoIDaUZd933bK3jbd/2IIBek6Sids97bMeoGYjLPh5vVw2JDcLFe4UVIbsHamp A6JY5UFAoPIlCL9xvK4JXC4YTpNMLoc00AouoAh04oHGmg0vGCAXVctyhQCGoQ+3aFZQ jlvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IcXQ08t2W8c/2dEBG4FRM5sIS4gP2ylI5VKbzNwowo0=; b=FUykj8xPse3DgMdgfvsh7iVQu9ungKmD4ujJIxWkKYuuOTPcSUYa6hgEfWKkS0Efcd NSg9fuTVG8WQ02pjNvLnesHsiuTZ7W/X6vn49mvvoEE83GGyVukHV8TwF+OhecBZvTT+ 1dO/ATSJqK5cQ9f8LFg9HrstPZhRBBUuq3clAJl1BX/85N1XUnjUTeUoVaVOqMure4br T3IZ5IoenFCi7EG77piL3m1NKwwVgFDWwiZYYmjbh/kFWeOFJVWD0+u5oe2hMOoi2atO YjADCksAvBzxPqtJs755NcpAgAVbH5uvKKqrdJbQdeOmewfUGd3fXytYegkX/I3XXat0 ydbw== X-Gm-Message-State: AGi0PuZHbuWqr9cCV0Ja6vg1GSCL+JIewCdGUwspY+mymluuRvBs73vG 90im/IrETXQSEtRsSD61n9izevj4ytmzjLd5KtGt7Q== X-Google-Smtp-Source: APiQypLG6uX3M+GgB0+qSb8maqG9spFZnfD3y/vDtToEl6eDzvx9bqPxJdSbx+jt1HartzSaX5MX7al9DuZmyY0Dox0= X-Received: by 2002:aca:abc6:: with SMTP id u189mr813007oie.30.1588145620794; Wed, 29 Apr 2020 00:33:40 -0700 (PDT) MIME-Version: 1.0 References: <20200427212514.11219-1-robh@kernel.org> <733e20b1-9592-6941-766b-9f321ad2ace5@samsung.com> In-Reply-To: <733e20b1-9592-6941-766b-9f321ad2ace5@samsung.com> From: Saravana Kannan Date: Wed, 29 Apr 2020 00:33:04 -0700 Message-ID: Subject: Re: [PATCH] amba: Retry adding deferred devices at late_initcall To: Marek Szyprowski X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200429_003346_433490_EB538A4A X-CRM114-Status: GOOD ( 24.27 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rob Herring , Geert Uytterhoeven , Linus Walleij , Russell King , John Stultz , Linux ARM , Sudeep Holla , Nicolas Saenz Julienne Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Apr 28, 2020 at 11:06 PM Marek Szyprowski wrote: > > Hi Linus, > > On 28.04.2020 22:39, Linus Walleij wrote: > > On Mon, Apr 27, 2020 at 11:25 PM Rob Herring wrote: > >> If amba bus devices defer when adding, the amba bus code simply retries > >> adding the devices every 5 seconds. This doesn't work well as it > >> completely unsynchronized with starting the init process which can > >> happen in less than 5 secs. Add a retry during late_initcall. If the > >> amba devices are added, then deferred probe takes over. If the > >> dependencies have not probed at this point, then there's no improvement > >> over previous behavior. To completely solve this, we'd need to retry > >> after every successful probe as deferred probe does. > >> > >> The list_empty() check now happens outside the mutex, but the mutex > >> wasn't necessary in the first place. > >> > >> This needed to use deferred probe instead of fragile initcall ordering > >> on 32-bit VExpress systems where the apb_pclk has a number of probe > >> dependencies (vexpress-sysregs, vexpress-config). > >> > >> Cc: John Stultz > >> Cc: Saravana Kannan > >> Cc: Linus Walleij > >> Cc: Sudeep Holla > >> Cc: Nicolas Saenz Julienne > >> Cc: Geert Uytterhoeven > >> Cc: Russell King > >> Signed-off-by: Rob Herring > > Makes sense to me, and the same approach is found > > in the generic code in drivers/base/dd.c so > > Reviewed-by: Linus Walleij > > > > The timer-based re-probe was added by Marek Szyprowski > > in commit a41980f2a3eb33ed7a2636e83498b47e95ceb05b > > do deal with power domains. I guess it mimics dd.c > > deferred probe at this point? > > > > There are a bit of other differences that have piled up, > > should we take a quick look at dd.c so there is not something > > else we're missing? I see some PM code for example. > > Well, late initcall based approach is what earlier version of my patch did: > > https://lkml.org/lkml/2016/4/12/414 > > but then it has been requested to solve the issue 'properly': > > https://lkml.org/lkml/2016/4/12/455 > > https://lkml.org/lkml/2016/4/14/875 > > For me it is fine to get back to late initcall based solution, though. > I haven't really dealt with a platform with AMBA devices and am not too familiar with it, so apologies in advance if any of my suggestions are silly. This whole "don't add a device before the clocks/resources needed to read the PID/CID" seems like something that can be solved by having a dummy device that "probes" when those resources are available. And during its probe, it adds the real amba device. That should avoid all the reinvention of deferred probing that amba/bus.c seems to be attempting. Any reason to not do something like that? I'd think that should clean up a whole lot of this code. Also, if we are primarily dealing with AMBA devices created from DT, then we might even be able to massage the fw_devlink feature to optimize this even more when fw_devlink=on. Just my 2 cents. -Saravana _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel