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.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=ham 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 285FCC43613 for ; Thu, 20 Jun 2019 03:47:44 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (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 9DEA920B1F for ; Thu, 20 Jun 2019 03:47:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="HyW5DLL4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9DEA920B1F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 45Tnp508zGzDqvP for ; Thu, 20 Jun 2019 13:47:41 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::d43; helo=mail-io1-xd43.google.com; envelope-from=oohall@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="HyW5DLL4"; dkim-atps=neutral Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 45Tnlm03BDzDqsZ for ; Thu, 20 Jun 2019 13:45:39 +1000 (AEST) Received: by mail-io1-xd43.google.com with SMTP id i10so935647iol.13 for ; Wed, 19 Jun 2019 20:45:39 -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=xZPyXbSMMXcl1mLdquv3ab0eaDgC5j4gm7PvbosOLKA=; b=HyW5DLL4sI4Wss/UuyJ241/UF3wliGHa0hUHHArhvOv+WwmyW+UkWN105j+uvwdqlU iELSS1PvJar+xs6w3AeXFwwhwwltuaoXvx5o0U5ShwhCiux9qhyvyiRQqqAbNxLs+vaZ WAQrhUgLLOmcrnhkBn9/F5iVCb2zALAhaQ9k//39QxlxOkEg+EQwFWKmlcISi2aVHHsH DxrGfD02zbYAaz73tNDJ8ZFVmn0pczjuxZode9P1Vwd2Wb5NHBM6ymeFq+Lc5hlkdVKw yONQa7eOKMi0s1BXXYAg7TJzOUHhIYe+ujtEZYJTGxzgC8bWd+iMwY1gXI4Wi8Vlr/Ly hNRQ== 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=xZPyXbSMMXcl1mLdquv3ab0eaDgC5j4gm7PvbosOLKA=; b=Ku6JkvVb0CfM0tEwxs4OPeIbg1iHSvUnj3iRKos/3XExiqSpR0e3ytvxNGFaKUW4Lc /wkgG6Lies5C1fKNvdmt9CdDzi+TAZ55uBWkZQOIp1hZoJlNU8BwdezblczKtAvtEtuv +sGOItnHTBZZgpZZ3BxJG6TcxVT8c1DZ8s+pRVvHlSjje16iu48sg/f7m4fXwTVFM1uD 2Zr5MQxvTPjJj0Efip9SzNA8w6IRI9gbon33q496x72TCdXmPBKKTNVjix0qwTASnXaW MOR2X0WAe36/S0B4rNSyUoaOyNmflEF9fGYpzYmS1zzVdfqHKnl2fS0IUsECN7WGKElC bjQQ== X-Gm-Message-State: APjAAAXPzvSslIi+rhrHnhFAgKHc3q0MBB90sy1eAAQQJfcGQMx/Bg4i cHVlPVB45yRI/Ch+csUZSwlQB947sVBSX6CaBU9Dbg== X-Google-Smtp-Source: APXvYqw127HHQ+AvHwkn5NIKbLlAU1dgI/rwTgmfoojebpJwjwC6KKYnjyLhmrl6AGdWp8TrNbAg3M0vtWBJb9ZDAJc= X-Received: by 2002:a5d:8497:: with SMTP id t23mr16251599iom.298.1561002335703; Wed, 19 Jun 2019 20:45:35 -0700 (PDT) MIME-Version: 1.0 References: <8deaedffad8ed3327f296a561c2a31c930c65f88.1557203383.git.sbobroff@linux.ibm.com> <20190619042706.GA24143@tungsten.ozlabs.ibm.com> In-Reply-To: From: "Oliver O'Halloran" Date: Thu, 20 Jun 2019 13:45:24 +1000 Message-ID: Subject: Re: [PATCH v2 3/6] powerpc/eeh: Improve debug messages around device addition To: Alexey Kardashevskiy Content-Type: text/plain; charset="UTF-8" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sam Bobroff , linuxppc-dev , Tyrel Datwyler Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Thu, Jun 20, 2019 at 12:40 PM Alexey Kardashevskiy wrote: > > On 19/06/2019 14:27, Sam Bobroff wrote: > > On Tue, Jun 11, 2019 at 03:47:58PM +1000, Alexey Kardashevskiy wrote: > >> > >> On 07/05/2019 14:30, Sam Bobroff wrote: > >>> Also remove useless comment. > >>> > >>> Signed-off-by: Sam Bobroff > >>> Reviewed-by: Alexey Kardashevskiy > >>> --- > *snip* > > > > I can see that edev will be non-NULL here, but that pr_debug() pattern > > (using the PDN information to form the PCI address) is quite common > > across the EEH code, so I think rather than changing a couple of > > specific cases, I should do a separate cleanup patch and introduce > > something like pdn_debug(pdn, "...."). What do you think? > > I'd switch them all to already existing dev_dbg/pci_debug rather than > adding pdn_debug as imho it should not have been used in the first place > really... > > > (I don't know exactly when edev->pdev can be NULL.) > > ... and if you switch to dev_dbg/pci_debug, I think quite soon you'll > know if it can or cannot be NULL :) As far as I can tell edev->pdev is NULL in two cases: 1. Before eeh_device_add_late() has been called on the pdev. The late part of the add maps the pdev to an edev and sets the pdev's edev pointer and vis a vis. 2. While recoverying EEH unaware devices. Unaware devices are destroyed and rescanned and the edev->pdev pointer is cleared by pcibios_device_release() In most of these cases it should be safe to use the pci_*() functions rather than making a new one up for printing pdns. In the cases where we might not have a PCI dev i'd make a new set of prints that take an EEH dev rather than a pci_dn since i'd like pci_dn to die sooner rather than later. Oliver