Received: by 2002:a17:90a:1609:0:0:0:0 with SMTP id n9csp2449657pja; Thu, 26 Mar 2020 15:37:24 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuhZeVjj3YzVWBtvQv6Smv4pPFT40GNP47WX+9uEwy3eQO98AhmF4agd1B3iiOjngLGf80y X-Received: by 2002:a9d:220e:: with SMTP id o14mr7883231ota.88.1585262244638; Thu, 26 Mar 2020 15:37:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585262244; cv=none; d=google.com; s=arc-20160816; b=XOKIMhSU+3BVjGy21M7AwmkTGEkKfUNqlT8WexqTIU4FZdHaiXiZCusTZZ0Jh71NlQ 1BAiPuLgcnbBtUwqCBrd9XbNEWPczgXY1dlI0o30DDMr9B5ZClC7N80XQSIvUrzkbmu1 RXExCh+NXONo9p1SA/h2Pxgs6wizBdQ7tUIH0f8SKp3uH6pp5oo+MzLawoDGqMeG5UxS BMo0QdpfMrO8+sbcEtUlx8QU03bAI+/TEfmWkquFDBLvBIRbf08qsBqkOdUGK7Jj5omL NhugWfxmkqUmBapGKsJKyARGYofqrdinqhmAj5RHqyGO4ZqFSIRHWlBEcBakdSyeMahq KnYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:message-id:subject:cc:to:from:date :dkim-signature; bh=XaO5q/6HxmxEQfl1iPwYLPEN7My0PxZ69cVg7HCENJA=; b=qDocgXcVSbL0q0EeUa4r5XQjS/2Z2oafQUp10lh6vUEkMtMpie32GWUD4MKJ5ZN5R7 /PQrhKlqjm+QMbI1ABU+YrXICjr7dnn7MdiENDVAzBUHl+6O0z6ccX5QTEwM0Y7ZXl/t 9C06aejPsaNj2RLr3W5hV4M2t1DfHx9Ra5B9QuSubNVyGOk69Jh8d7lnuxYx6rWwWVrp /FeyABhJxPFmNnbYax0BkPXsbx6uKgwp3Sz2QmWdPy4psl93J4mPiKi0PNhoL7A9Lrnb dhCaWxsDt0ul1Z9z5lp+y1UzK9yBbuxQT3I91PTDQ8Bq//sIfVXtSleh4tzC7baAnujG aSaA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=tsBKZvCW; 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=pass (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 p12si1632362otq.62.2020.03.26.15.37.11; Thu, 26 Mar 2020 15:37:24 -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=pass header.i=@kernel.org header.s=default header.b=tsBKZvCW; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727620AbgCZWgk (ORCPT + 99 others); Thu, 26 Mar 2020 18:36:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:52942 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726067AbgCZWgk (ORCPT ); Thu, 26 Mar 2020 18:36:40 -0400 Received: from localhost (mobile-166-175-186-165.mycingular.net [166.175.186.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 573642077D; Thu, 26 Mar 2020 22:36:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585262199; bh=0DtT905qVdWNBDrBCna0NgQ5Od+cslLqNzlrUIModX8=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=tsBKZvCW4tQGv92f3syNeoLj0fegellrPHn5oyyzz27WysT5sEoVMOjlJdtOvesIG ZTeEWtcDOyoSqORBEaNSRz0SRSisNtNXaspmqixgUCw+L421lOZU+yNKOuyudYUrl+ y9aeDUwoE0p5uWYEswtwhtCKp4a9TXRRfssbIeiw= Date: Thu, 26 Mar 2020 17:36:37 -0500 From: Bjorn Helgaas To: "Kuppuswamy, Sathyanarayanan" Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, ashok.raj@intel.com, Len Brown , "Rafael J. Wysocki" Subject: Re: [PATCH v18 10/11] PCI/DPC: Add Error Disconnect Recover (EDR) support Message-ID: <20200326223637.GA106135@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 24, 2020 at 06:00:31PM -0700, Kuppuswamy, Sathyanarayanan wrote: > Hi Bjorn, > > On 3/24/20 2:37 PM, Bjorn Helgaas wrote: > > This is really ugly. What's the story on this firmware? It sounds > > defective to me. > > I think there is no defined standard for this. I have checked few > _DSM implementations. Some of them return default value and some > don't. But atleast in the test hardware I use, we need this check. I agree that I don't see anything in the ACPI spec v6.3 about what should happen if we supply a Function Index that isn't supported. That looks like a hole in the spec. > > Or is everybody that uses _DSM supposed to check before evaluating it? > > I think its safer to do this check. > > > E.g., > > > > if (!acpi_check_dsm(...)) > > return -EINVAL; > > > > obj = acpi_evaluate_dsm(...); > > > > If everybody is supposed to do this, it seems like the check part > > should be moved into acpi_evaluate_dsm(). So my question, and I guess this is really for Rafael, is that since it seems like *everybody* needs to use acpi_check_dsm() in order to use acpi_evaluate_dsm() safely, why don't we move the check *into* acpi_evaluate_dsm()? It's just error prone if we expect everybody to call both interfaces. Bjorn