Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp6177659pxb; Tue, 16 Feb 2021 19:32:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJzuE6dyRhwY3BAdyP9z7+fJoIKdgONQvP1EpW3CpkchTsh7t0UOy9gWqoQRV+lZX8F2i5dp X-Received: by 2002:a50:fe86:: with SMTP id d6mr24305946edt.80.1613532762047; Tue, 16 Feb 2021 19:32:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613532762; cv=none; d=google.com; s=arc-20160816; b=0nq8hQkTZJhnYZjtjKSaeFj4N1sdo3xU4aH2MURdBH5fTrMwYOqkIJVvzGQeagMfum /tcqhG/evCXKzRbeV0xUd0Lyfy9i6NVs2FkfhiS4cC3ooj3FGh0xUotGEOLo7NkQVyDs s5yo58O9AUYFpBO+iK/rh3DQOm9saR6b/cimmDsxyJrmKJryH4RgRWIs/N5WweeiMc4u HWmzG/v8SUUsZ+pv2st2kEtcLHxPNt9zqW6IfVWo804x0Z07ih+mQIQz8dbGTaqc5znO ArV1mVDPH9jf1LgFVoscZNm1shOoQ/BDXzZXLK2MRxmtsQX1qy5SMkITifBKr3d7Snrq Zw5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :dkim-signature; bh=ZebNEJ1lImmmwpebh5XbCXjAhuyB+srcG7Rw7XuCIIs=; b=pybNKh0Uegji+gf7PcFV0aLcv1huu9Qr2Ch4Ly04jVCxbrCHx/m7qW333GeP78OB6u rNlrU4TWoXBL0qy6HaVFpelYw76gOpfJaonf97WpcTcWMUtUpdy5VCrwNRS84FjBFrJK 2GrGOF2vEVxeHLkJiJUXZPt8w4J1C+EryCrYnXWY2l3GKnoRSWUXFC91cn6Ccq+dt73p h35tNI2/GrGlp3w66vR5Yg90TLnCO/rcUBWTOleh4Ow+zF8BmB9rinXpv5Mveip943cM HXCo94Q7zh/Ryg2lFS1qED9vAByGqGsnCD1EJumnFpJNLzDAT6nBoLXKClA0AAzcdKks TAdA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=e23dDm4h; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g10si435999edv.460.2021.02.16.19.32.17; Tue, 16 Feb 2021 19:32:42 -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=@gmail.com header.s=20161025 header.b=e23dDm4h; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230162AbhBQDGa (ORCPT + 99 others); Tue, 16 Feb 2021 22:06:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44112 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229480AbhBQDG0 (ORCPT ); Tue, 16 Feb 2021 22:06:26 -0500 Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37BD5C061574 for ; Tue, 16 Feb 2021 19:05:46 -0800 (PST) Received: by mail-ot1-x32b.google.com with SMTP id e4so10857887ote.5 for ; Tue, 16 Feb 2021 19:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ZebNEJ1lImmmwpebh5XbCXjAhuyB+srcG7Rw7XuCIIs=; b=e23dDm4heQcJYZq/AVTJZGdTFPBlfuFY51puS38KGLDZ0iRD7kMSWnHs31kcmkzOTQ neMqD4GFIEy0+EoR/AuMXyi6sQPdmV096K9FpOc9kc7MvwjdojVUGCAYGno9vrGh7Jta AKkTpeB7wPIP3F9mm1oROk75rboLQ5ABvKuEELgJGzSYyEjRFwPKNKtoWIl6nMP8TfpD TZaGWkLqdxT9uj7+NNj+Ti6GYMDG3ZSrl4GVWKTaE2z7rstPfqZDw+pkRGz0JScaru7t 1eaVdzkMhY1CjOhyLrvVujQ/kI8r88PgNbU+SMzykaa4RK6JNGoQeJ5hsdhHUmzKYE3M kR9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=ZebNEJ1lImmmwpebh5XbCXjAhuyB+srcG7Rw7XuCIIs=; b=oSKU6kE3lWnRxu2cCYrDCLab4CsvHB+A2Q8yy702gCRdsmjggyBGdJddaytVp/LO8d +vDEUZHE6Y84FFgswk2JJqj2zEs4uOkPb+/ITtutNJHpiOogNHSKKDOWAu1IBxbh7+sT oIIvpt9U5hUnuWazKLZhVDy8Ydmlp0WhY+2gdl4JWO37mM8lTG5CN3/6ha6yGKEEkSoB FOvP8MyxkpCJyBMzE4mtx0GazV63jS0+C0b99C5UCcf37MYoAN+a2omymgNmdjsc8esv NY4GDthOtb+jWPLSoEPcYKFe6ErthHsvjORzZAmsWbk5gYqfJGX9Jw8z6z5tdYuiFQW0 hC+Q== X-Gm-Message-State: AOAM5320fUNhLyt/k1Da8zfQI/e7NR29R+Iecii6ETLMm2ei4mAJdDk2 1wtiyOayTh3LW63lIAQy0spb1i8yYz0= X-Received: by 2002:a9d:4d85:: with SMTP id u5mr16671413otk.47.1613531145624; Tue, 16 Feb 2021 19:05:45 -0800 (PST) Received: from localhost ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id 97sm163323oty.48.2021.02.16.19.05.44 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 16 Feb 2021 19:05:44 -0800 (PST) Sender: Guenter Roeck Date: Tue, 16 Feb 2021 19:05:43 -0800 From: Guenter Roeck To: Saravana Kannan Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , Android Kernel Team , LKML , Jisheng Zhang , Kevin Hilman , John Stultz , Nicolas Saenz Julienne , Marc Zyngier Subject: Re: [PATCH v1 5/5] driver core: Set fw_devlink=on by default Message-ID: <20210217030543.GA189612@roeck-us.net> References: <20201218031703.3053753-1-saravanak@google.com> <20201218031703.3053753-6-saravanak@google.com> <20210210055430.GA73123@roeck-us.net> <33f643b9-9f6d-e59a-64e7-2d2b7d3e71a4@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 16, 2021 at 06:39:55PM -0800, Saravana Kannan wrote: > On Wed, Feb 10, 2021 at 1:21 PM Guenter Roeck wrote: > > > > On 2/10/21 12:52 PM, Saravana Kannan wrote: > > > On Wed, Feb 10, 2021 at 7:10 AM Guenter Roeck wrote: > > >> > > >> On 2/10/21 12:20 AM, Saravana Kannan wrote: > > >>> On Tue, Feb 9, 2021 at 9:54 PM Guenter Roeck wrote: > > >>>> > > >>>> On Thu, Dec 17, 2020 at 07:17:03PM -0800, Saravana Kannan wrote: > > >>>>> Cyclic dependencies in some firmware was one of the last remaining > > >>>>> reasons fw_devlink=on couldn't be set by default. Now that cyclic > > >>>>> dependencies don't block probing, set fw_devlink=on by default. > > >>>>> > > >>>>> Setting fw_devlink=on by default brings a bunch of benefits (currently, > > >>>>> only for systems with device tree firmware): > > >>>>> * Significantly cuts down deferred probes. > > >>>>> * Device probe is effectively attempted in graph order. > > >>>>> * Makes it much easier to load drivers as modules without having to > > >>>>> worry about functional dependencies between modules (depmod is still > > >>>>> needed for symbol dependencies). > > >>>>> > > >>>>> If this patch prevents some devices from probing, it's very likely due > > >>>>> to the system having one or more device drivers that "probe"/set up a > > >>>>> device (DT node with compatible property) without creating a struct > > >>>>> device for it. If we hit such cases, the device drivers need to be > > >>>>> fixed so that they populate struct devices and probe them like normal > > >>>>> device drivers so that the driver core is aware of the devices and their > > >>>>> status. See [1] for an example of such a case. > > >>>>> > > >>>>> [1] - https://lore.kernel.org/lkml/CAGETcx9PiX==mLxB9PO8Myyk6u2vhPVwTMsA5NkD-ywH5xhusw@mail.gmail.com/ > > >>>>> Signed-off-by: Saravana Kannan > > >>>> > > >>>> This patch breaks nios2 boot tests in qemu. The system gets stuck when > > >>>> trying to reboot. Reverting this patch fixes the problem. Bisect log > > >>>> is attached. > > >>> > > >>> Thanks for the report Guenter. Can you please try this series? > > >>> https://lore.kernel.org/lkml/20210205222644.2357303-1-saravanak@google.com/ > > >>> > > >> > > >> Not this week. I have lots of reviews to complete before the end of the week, > > >> with the 5.12 commit window coming up. > > > > > > Ok. By next week, all the fixes should be in linux-next too. So it > > > should be easier if you choose to test. > > > > > >> Given the number of problems observed, I personally think that it is way > > >> too early for this patch. We'll have no end of problems if it is applied > > >> to the upstream kernel in the next commit window. Of course, that is just > > >> my personal opinion. > > > > > > You had said "with 115 of 430 boot tests failing in -next" earlier. > > > Just to be sure I understand it right, you are not saying this patch > > > caused them all right? You are just saying that 115 general boot > > > failures that might mask fw_devlink issues in some of them, right? > > > > > > > Correct. > > Is it right to assume [1] fixed all known boot issues due to fw_devlink=on? > [1] - https://lore.kernel.org/lkml/20210215224258.1231449-1-saravanak@google.com/ > I honestly don't know. Current status of -next in my tests is: Build results: total: 149 pass: 144 fail: 5 Qemu test results: total: 432 pass: 371 fail: 61 This is for next-20210216. Newly introduced failures keep popping up. Some of the failures have been persistent for weeks, so it is all but impossible to say if affected platforms experience more than one failure. Also, please keep in mind that my boot tests are very shallow, along the line of "it boots, therefore it works". It only tests hardware which is emulated by qemu and is needed for booting. It tests probably much less than 1% of driver code. It can and should not be used for any useful fw_devlink related test coverage. Thanks, Guenter