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=-1.0 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 69EF4C433E2 for ; Tue, 30 Jun 2020 18:01:52 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 44F8C20768 for ; Tue, 30 Jun 2020 18:01:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="vvFmQ2zU"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="LXxLlaqy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 44F8C20768 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.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=tNFay63M4qiHEBwiGwlWhu9gLpLc+bDA8Cm2UaeLDJ8=; b=vvFmQ2zUPagg9bhSCMTON/ANQ TjGQY349dHDvfDE0iW1HRDc+in+37sY2Z335ZxgOyquabnjDRdTcCTSNlsvfzw7nyQcE63sziEW0X rcjuKTvE7p+qpxq1m69QW1J6dGqUsflGaqtY6AhURV5jHkWC3zZOmtL7xJ4IWRNZdMZDPu66eN+aU /q25FYh0pjl0dC6S4thOL7npD1AEAHf7hoL+2VOx2E4VbgmF4mpM/i71VFH8vpI3gcxaGg4px6NSx 0cWrRoy05trzZ2HY8pesuHh+z44H4ONf3RHl75/ogsXW2pYUs6RmPbsO0izOtBuSSwfgpKQJaQpzE BvhdyGN6w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqKYf-0007km-EM; Tue, 30 Jun 2020 18:00:37 +0000 Received: from mail-il1-x143.google.com ([2607:f8b0:4864:20::143]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqKYd-0007je-Oz for linux-arm-kernel@lists.infradead.org; Tue, 30 Jun 2020 18:00:36 +0000 Received: by mail-il1-x143.google.com with SMTP id q3so7848454ilt.8 for ; Tue, 30 Jun 2020 11:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O7oL8VGd8A63dQhiVKi3PUjT96u+CwH07OR1iL+5qx4=; b=LXxLlaqy8X7luV1H2JLKSLljqApL0A04Nf577TG6L7GJB83ghE594x1YcLOVh8FDVH nSuQC0sjMcndgu5UByNZAeT4oyKGQoHtNjxOhZ+WmCKcVdyUbye3RqazYnnCyLmfwP/Q s+ksI2t5EMUOleIESpSn3+jyUTmwolmprisrKI0rniHWFpDHrL7bWtz6NR8QXz3cLOI1 xtrkNIxMgc18pplFyCBd81sFvXGYk6f1mT3EiQgfUOotg2u+lC981oiFyWRvqNIE9sne 2JXvfhtTQzheVn+GanB5HwVzngV7NjrR1J3tuOH95UPWfNrkyFYPJWteALL2gdG8tncY ziGQ== 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=O7oL8VGd8A63dQhiVKi3PUjT96u+CwH07OR1iL+5qx4=; b=Yf9p0J8VBz9v2S9frpU09JmACTvAJiQM/LelhqxDG8XlO8kxOUbiL09jzFXL9jBrLU mGSeqX0HeLWcx2toVujiaaPFRiIJLqjQxjqEOl9HnB8tPjI4v/eNFiAyZaxdzqN+BbSE kj+vQZwZ074BcANacofqfr9Or4qgXdp6srg/pPUnhw1NsS3Yy5RyXU4F6Q1ll87mAeS/ wqFDjhCZy+gHKFqW2k6MDHwTYcuRajoU+WvnKjANDuXQ2t59UNGfyzpyvqmnjCVXUvhs vCOe8zF2lpLjXndIWBJmStVmz2Cjz6lW2UmFWY04tkrPyY60sto/SHkRLvAbRE8OS2ah OUlg== X-Gm-Message-State: AOAM533sezy2Qv+RUBIEWyW4xDN1xGH1MVixRFxrI4os2uzvRmSrPwjl pMQBO71Gc7AtauUxraxzIBvNT2u6+mIjy+V5suw= X-Google-Smtp-Source: ABdhPJx6lNSWEJoftbLz5gNw9hGNEAozoi4443nPKEgIfccHPGmzI05rQic143M7ShtfqDQkwHVgsssevtWA1CT4g78= X-Received: by 2002:a92:9f96:: with SMTP id z22mr719638ilk.266.1593540032392; Tue, 30 Jun 2020 11:00:32 -0700 (PDT) MIME-Version: 1.0 References: <20200626100103.18879-1-a.hajda@samsung.com> <20200626100103.18879-3-a.hajda@samsung.com> <5f159e00-44fd-515b-dd8c-4db9845dc9e6@ti.com> <7e3c924b-c025-a829-6868-78e2935c70eb@samsung.com> <66faa188-5ef6-d449-07fe-28c8be5e559c@ti.com> <21f5ec9c-2d1d-5f28-5aeb-ac0db144a55e@samsung.com> In-Reply-To: <21f5ec9c-2d1d-5f28-5aeb-ac0db144a55e@samsung.com> From: Dmitry Torokhov Date: Tue, 30 Jun 2020 11:00:21 -0700 Message-ID: Subject: Re: [PATCH v6 2/4] driver core: add deferring probe reason to devices_deferred property To: Andrzej Hajda X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200630_140035_828644_40EB63DC X-CRM114-Status: GOOD ( 23.38 ) 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: Jernej Skrabec , Grygorii Strashko , Bartlomiej Zolnierkiewicz , Greg Kroah-Hartman , Jonas Karlman , Russell King - ARM Linux , "open list:DRM DRIVERS" , lkml , Neil Armstrong , Andy Shevchenko , Mark Brown , Laurent Pinchart , "Rafael J. Wysocki" , linux-arm-kernel , Marek Szyprowski 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 Tue, Jun 30, 2020 at 8:42 AM Andrzej Hajda wrote: > > > On 30.06.2020 10:59, Grygorii Strashko wrote: > > Hi > > > > On 29/06/2020 14:28, Andrzej Hajda wrote: > >> Hi Grygorii, > >> > >> (...) > >> > >>>> /* > >>>> * deferred_devs_show() - Show the devices in the deferred probe > >>>> pending list. > >>>> */ > >>>> @@ -221,7 +241,8 @@ static int deferred_devs_show(struct seq_file *s, > >>>> void *data) > >>>> mutex_lock(&deferred_probe_mutex); > >>>> list_for_each_entry(curr, &deferred_probe_pending_list, > >>>> deferred_probe) > >>>> - seq_printf(s, "%s\n", dev_name(curr->device)); > >>>> + seq_printf(s, "%s\t%s", dev_name(curr->device), > >>>> + curr->device->p->deferred_probe_reason ?: "\n"); > >>>> mutex_unlock(&deferred_probe_mutex); > >>>> > >>> > >>> Sry, may be i missing smth, but shouldn't it be optional > >>> (CONFIG_DEBUG_FS is probably too generic). > >>> > >> > >> I am not sure what exactly are you referring to, but this patch does not > >> add new property, it just extends functionality of existing one. > > > > Sry, needed to be more specific. > > > > You've added device_set_deferred_probe_reson(dev, &vaf); > > which expected to be used on every EPROBE_DEFER in dev_err_probe() in > > combination with > > > > + } else { > > + device_set_deferred_probe_reson(dev, &vaf); > > dev_dbg(dev, "error %d: %pV", err, &vaf); > > > > ^^ dev_dbg() does not add any runtime overhead during boot unless enabled > > + } > > > > But: > > > > +void device_set_deferred_probe_reson(const struct device *dev, struct > > va_format *vaf) > > +{ > > + const char *drv = dev_driver_string(dev); > > + > > + mutex_lock(&deferred_probe_mutex); > > + > > + kfree(dev->p->deferred_probe_reason); > > + dev->p->deferred_probe_reason = kasprintf(GFP_KERNEL, "%s: > > %pV", drv, vaf); > > + > > + mutex_unlock(&deferred_probe_mutex); > > +} > > > > ^^ Adds locking, kfree() and kasprintf() for every deferred probe > > during boot and can't be disabled. > > > > Right? > > > Right, but usually the burden should be insignificant in comparison to > probe time, so I do not think it is worth optimizing. I do not think this is going to take. You are suggesting that we modify pretty much every driver to supply this deferral reason, and I doubt it will happen. Can we put this burden on providers that raise the deferral? I.e. majority of code are using devm API now, so we most likely know the device for which deferral is being raised. We can have a list of deferral reasons and their devices and when in device code once probe is done we could try reconciling it with the deferred devicelist, and this would mean you only need to implement this in gpiolib, regulator core, clocks core, etc. Thanks. -- Dmitry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel