Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1531012imm; Tue, 10 Jul 2018 03:34:43 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcaED8RLgx8S5YVcSjsGy7kAUJb8xlHb4dk66aDJ2FpgWV2S2Q9cl9seBQA8zM5CxyLIpbv X-Received: by 2002:a17:902:8d96:: with SMTP id v22-v6mr23798489plo.176.1531218883598; Tue, 10 Jul 2018 03:34:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531218883; cv=none; d=google.com; s=arc-20160816; b=c/nVEbfpM6fAg/wmspujuT3MUY3KjHuIz8QbAQy0Zs6s9phUWkyTboQ05wPWhvKVRc uG3YYMER2AmJaC2fQ/h8MP7ugxQEubU1mkyeFTPBVEz9Va3g/gAijlESgHsDTDyqZfCK S8XGkLY1L6A+9igdT9HbXsQhqn5/z2YEDfod7OdF4YBd6XhQXHGD2Kx5XTmf8MSvazPG IeLsHRpDdFjV1oUaXnF3gComTZdZfO9jWp5FMxohsLxQY54LuGFTRDRF7orC2Xo93JA7 yEB9QghOn4n+I4+6CkSdJfMbz/t7Lecjtu11P9pj2/13nppGgl1YD1TMgI2hBFNcYuNf vhtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=khS7D/OkYfdUVcKGmyvawna1j46BuK/HifDdC0ilySE=; b=iCmDAnlDfWF3hY9sak4KlEdgWl0xAkkNlynv4Bjz8bQtlYcQ6mrGQvfPlz3volyj+9 9KdFxR+qTJz0y9PaQyXDNYgooGWtXQB+U4oPZdvbc6XUuWgEci2enLXwnyJTZP5T2YME YGuScJPuuYk3J/CW/8SrSfWiADtZnzbw8IvF8hmyXCt/y0gtrt2Df5Q6KMwhJ9nRHQxL lNvblEH2wkbtzc9z2Gh4DyGGq0hwD17BjyrEDAOHZDClaXBCpe5Wc4p82sxHZuJijyPS IfYPCpGGE3vFHFsTdIaZ6ejTu2/negCiv+uEjIEeotcOuEzz03PcrdS6DFuSOGxuGmIF MiJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=A4bD+sT3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e20-v6si18397833pfm.177.2018.07.10.03.34.28; Tue, 10 Jul 2018 03:34:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=A4bD+sT3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933220AbeGJKcc (ORCPT + 99 others); Tue, 10 Jul 2018 06:32:32 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:40958 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932172AbeGJKc3 (ORCPT ); Tue, 10 Jul 2018 06:32:29 -0400 Received: by mail-oi0-f67.google.com with SMTP id w126-v6so41616467oie.7; Tue, 10 Jul 2018 03:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=khS7D/OkYfdUVcKGmyvawna1j46BuK/HifDdC0ilySE=; b=A4bD+sT3OW8+UjP43+tpEo0fQGzBZScNr+9BafeVNUK2ewyYHUiwGUgHcot1ITuiH6 P2IRwofS0P7OBsjocBFiMT2qRW9SV5XCMOk7zp8XeysqC9W3Zgut3jrZKN73N3akY+TR MaP68G7rsr0XUWWnOyiYAYD01LIxigfkaaEgch/ylHuLNftsrJlMJ5cvRAuq5l/s2j3/ 6jX4JvlqJamee+pIi1m/XSiQCjy1ShazA/j+AYxYFSCjOknhw9HmACyJwpb/5/suMm8Q zvOhWapnKfKbmDhHZpOSUBL8usoJc9oS6wKEnXS/BlcFaxhIP8I8y9NHoMH6kca0/IzZ BZMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=khS7D/OkYfdUVcKGmyvawna1j46BuK/HifDdC0ilySE=; b=oOTxAnLSmndPbnazk/3cHPbpHwvoYCDD+SLsb8Qii9qEKCLxDf/69S6RCrI6WWPcZ6 QvugKYeMiFG/0IYerXh+qfIp1UdgSxwOPa3/h0gQUohvdAV1o0Bw54FxApqbqd2uRJKS xk1XCAd+/6SE1Y2UHPEOTCAoHI4V9qPkafibNdUaQlPO0Mg2XXAp4yDzPuIymKa2+hzF yGWVovdS2ey1nT1sk6lVkOUFXq519Buu2mV1CpRiv4qKDH7POFqqKW2Z9xEpMziiVfUj rMDUN/CvUjOL8cnU46kYwkZ5DCX8i1H2/1UDh/oqGfKOJxS4QQ+FgImml4h1sTupnMGo DeIQ== X-Gm-Message-State: APt69E2XavJqCz4/0pDNgc3Ub5DLh1vqx2gDRzbRheZQWP78er1JOJ1M EVA3g4PSSHy47UpfRNhugU8fPG4+UbpypzLMYoo= X-Received: by 2002:aca:ccc4:: with SMTP id c187-v6mr25299446oig.282.1531218749069; Tue, 10 Jul 2018 03:32:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:63d2:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 03:32:28 -0700 (PDT) In-Reply-To: <5b134ed3-b473-90f3-acc7-5943e1669bb5@ti.com> References: <1530600642-25090-1-git-send-email-kernelfans@gmail.com> <2108146.dv4EAOf6IP@aspire.rjw.lan> <8816662.k3KXbdkA2e@aspire.rjw.lan> <5b134ed3-b473-90f3-acc7-5943e1669bb5@ti.com> From: "Rafael J. Wysocki" Date: Tue, 10 Jul 2018 12:32:28 +0200 X-Google-Sender-Auth: ZuAhyvFm53vRzpkbHG4R0O0lOLQ Message-ID: Subject: Re: [PATCH] driver core: Drop devices_kset_move_last() call from really_probe() To: Kishon Vijay Abraham I Cc: Bjorn Helgaas , "Rafael J. Wysocki" , Mark Brown , Liam Girdwood , "Rafael J. Wysocki" , Greg Kroah-Hartman , Pingfan Liu , Linux Kernel Mailing List , Grygorii Strashko , Christoph Hellwig , Bjorn Helgaas , Dave Young , Linux PCI , Lukas Wunner , Linux PM list Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 10, 2018 at 8:19 AM, Kishon Vijay Abraham I wrote: > +Mark, Liam > > Hi, > > On Tuesday 10 July 2018 03:36 AM, Bjorn Helgaas wrote: >> [+cc Kishon] >> >> On Mon, Jul 9, 2018 at 4:35 PM Rafael J. Wysocki wrote: >>> >>> On Mon, Jul 9, 2018 at 3:57 PM, Bjorn Helgaas wrote: >>>> On Fri, Jul 6, 2018 at 5:01 AM Rafael J. Wysocki wrote: >>>>> >>>>> From: Rafael J. Wysocki >>>>> >>>>> The devices_kset_move_last() call in really_probe() is a mistake >>>>> as it may cause parents to follow children in the devices_kset list >>>>> which then causes system shutdown to fail. Namely, if a device has >>>>> children before really_probe() is called for it (which is not >>>>> uncommon), that call will cause it to be reordered after the children >>>>> in the devices_kset list and the ordering of that list will not >>>>> reflect the correct device shutdown order. >>>>> >>>>> Also it causes the devices_kset list to be constantly reordered >>>>> until all drivers have been probed which is totally pointless >>>>> overhead in the majority of cases. >>>>> >>>>> For that reason, revert the really_probe() modifications made by >>>>> commit 52cdbdd49853. >>>> >>>> I'm sure you've considered this, but I can't figure out whether this >>>> patch will reintroduce the problem that was solved by 52cdbdd49853. >>>> That patch updated two places: (1) really_probe(), the change you're >>>> reverting here, and (2) device_move(). >>>> >>>> device_move() is only called from 4-5 places, none of which look >>>> related to the problem fixed by 52cdbdd49853, so it seems like that >>>> problem was probably resolved by the hunk you're reverting. >>> >>> That's right, but I don't want to revert all of it. The other parts >>> of it are kind of useful as they make the handling of the devices_kset >>> list be consistent with the handling of dpm_list. >>> >>> The hunk I'm reverting, however, is completely off. It not only is >>> incorrect (as per the above), but it also causes the devices_kset list >>> and dpm_list to be handled differently. >> >> If I understand correctly, you are saying: >> >> - the 52cdbdd49853 really_probe() hunk fixed a problem, but >> - that hunk was the wrong fix for it, and >> - this patch removes the wrong fix (and probably reintroduces the problem) >> >> If devices_kset is supposed to be ordered so children follow parents, >> I agree the really_probe() hunk doesn't make much sense because the >> parent/child relation is determined by the circuit design, not by the >> probe order. >> >> It just seems like it's worth being clear that we're reintroducing the >> problem fixed by 52cdbdd49853, so it needs to be solved a different >> way. Ideally that would be done before this patch so there's not a >> regression, and this changelog could mention what's happening. >> >>> It had attempted to fix something, but it failed miserably at that. >> >> If you're saying that 52cdbdd49853 *tried* to fix a DRA7XX_evm reboot >> problem, but in fact, it did not fix that problem, then I guess there >> should be no issue with reverting that hunk. > > It did fix a problem making sure the regulator's shutdown is invoked after the > mmc shutdown. And reverting 52cdbdd49853 reintroduces the problem. But, of course, it didn't prevent regulator suspend from being run before mmc suspend, so it really addressed part of the problem only and while doing that it introduced a regression. This piece of really_probe() is incorrect and it has to go away. Thanks, Rafael