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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2303FC7EE2E for ; Sat, 25 Feb 2023 10:08:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229530AbjBYKIK (ORCPT ); Sat, 25 Feb 2023 05:08:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34538 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229496AbjBYKII (ORCPT ); Sat, 25 Feb 2023 05:08:08 -0500 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A11E6C177 for ; Sat, 25 Feb 2023 02:08:06 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id h14so1595626wru.4 for ; Sat, 25 Feb 2023 02:08:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=bxbj2MIMz+4fiGqGes7y0064FPaBsDmmrMP3IsQqxSs=; b=LvhZaSceahKXLg52CYa4EDK0/dk8k2eAYXSQ6oyqKb/g/tIuX86s3r1Ec0t4zXRLMh gQeM1MoN+PIa1YRWvo2+3XGvTunJx9r8zQ8zTJd+knmLp8/jUib1f2fAGiCMSKwsULOu 1aJKgmHd+ZPcrP36OVhbPPZNlxtpW7akve76tQ7WmEzUq2Uc3YljItrrV5mxq/bvCQvc PkYMGe6xgbGE5DK5trknRz14Y8TzqEe1s/wMy3snFbHadCHoRvAC2KLMgOGRGJNZ2sIK SoJOD7LbVP3WaZuQ5N1YK3IeYdA3gYGtuiLQBROcyihj21rYLbqGdYzaU4AtoplfrDdp h7Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bxbj2MIMz+4fiGqGes7y0064FPaBsDmmrMP3IsQqxSs=; b=rPk9ABwL2dSYM3fe+zsxO7ahsCf3vVSuZMooH9W0nKXKSmly+3dLQ0/wrpkddYyE4B 73XZYtWkSiiJKOfUV1Uwo6nr1mfJdWQcGOfUGhuH8Fqo85n4zeAdpoItFvEg+xk+TRH8 Ap5YbcGgAJlfpnTOPSMOJdOsVArw7HxVgaK15AnqrmtJf1kUcSQWirJVponnLvDm0rjE nSoFknLEcluRTbA0nQoJj2tNL6GrDAJZUzv7bbS6gSf4ovHF/vM+io/DW38sloKFtoX8 AMrxQoX04zO3aSsIw19gi1mpiqgFXp3qNe1iKRcgM212qhj1k/PsMfKy9hVVrh30AHSN 3ITg== X-Gm-Message-State: AO0yUKV9LlaKZ3vwQk4S4g3IwaY6ox81JCTdOHcfMcfk53I2HNumGDcE tvutCocB1xKNI5fUSwWYk0QdsQ== X-Google-Smtp-Source: AK7set8UA3cUhKwWTYb4UtT8vgIRv9+KBNb7EZHNn5ECYbzxkMy8jErfwAjgtpfsqZs6sjBtl6yIvA== X-Received: by 2002:a5d:544d:0:b0:2c7:19c1:5557 with SMTP id w13-20020a5d544d000000b002c719c15557mr5129334wrv.64.1677319685025; Sat, 25 Feb 2023 02:08:05 -0800 (PST) Received: from [192.168.1.20] ([178.197.216.144]) by smtp.gmail.com with ESMTPSA id ja18-20020a05600c557200b003eb0d6f48f3sm5051296wmb.27.2023.02.25.02.08.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Feb 2023 02:08:04 -0800 (PST) Message-ID: <80b17309-ec9c-8942-d901-7121bc936471@linaro.org> Date: Sat, 25 Feb 2023 11:08:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v1 1/2] dt-bindings: PCI: dwc: Add snps,skip-wait-link-up Content-Language: en-US From: Krzysztof Kozlowski To: Sajid Dalvi , Jingoo Han , Gustavo Pimentel , Lorenzo Pieralisi , =?UTF-8?Q?Krzysztof_Wilczy=c5=84ski?= , Rob Herring , Bjorn Helgaas , Krzysztof Kozlowski Cc: kernel-team@android.com, linux-pci@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20230224195749.818282-1-sdalvi@google.com> <20230224195749.818282-2-sdalvi@google.com> <2e4964c1-0831-c156-3372-81a56f8d623e@linaro.org> <28c72c1a-df7d-db05-f32f-23b170b96db5@linaro.org> In-Reply-To: <28c72c1a-df7d-db05-f32f-23b170b96db5@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25/02/2023 11:00, Krzysztof Kozlowski wrote: > On 24/02/2023 23:09, Sajid Dalvi wrote: >> On Fri, Feb 24, 2023 at 3:29 PM Krzysztof Kozlowski >> wrote: >>> >>> On 24/02/2023 22:27, Sajid Dalvi wrote: >>>> On Fri, Feb 24, 2023 at 2:40 PM Krzysztof Kozlowski >>>> wrote: >>>>> >>>>> On 24/02/2023 20:57, Sajid Dalvi wrote: >>>>>> When the Root Complex is probed, the default behavior is to spin in a loop >>>>>> waiting for the link to come up. In some systems the link is not brought up >>>>>> during probe, but later in the context of an end-point turning on. >>>>>> This property will allow the loop to be skipped. >>>>>> >>>>>> Signed-off-by: Sajid Dalvi >>>>>> --- >>>>> >>>>> Thank you for your patch. There is something to discuss/improve. >>>>> >>>>>> Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml | 8 ++++++++ >>>>>> 1 file changed, 8 insertions(+) >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml >>>>>> index 1a83f0f65f19..0b8950a73b7e 100644 >>>>>> --- a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml >>>>>> +++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml >>>>>> @@ -197,6 +197,14 @@ properties: >>>>>> - contains: >>>>>> const: msi >>>>>> >>>>>> + snps,skip-wait-link-up: >>>>>> + $ref: /schemas/types.yaml#/definitions/flag >>>>>> + description: >>>>>> + When the Root Complex is probed, the default behavior is to spin in a >>>>>> + loop waiting for the link to come up. In some systems the link is not >>>>>> + brought up during probe, but later in the context of an end-point turning >>>>>> + on. This property will allow the loop to be skipped. >>>>> >>>>> I fail to see how probe behavior is related to properties of hardware. >>>>> You describe OS behavior, not hardware. This does not look like >>>>> belonging to DT. >>>>> >>>>> >>>>> Best regards, >>>>> Krzysztof >>>> >>>> Thanks for your response Krzysztof. >>>> The hardware configuration of the system determines whether an >>>> endpoint device is available during host init. If it isn't available >>>> on a particular and dedicated pcie interface, we should skip waiting >>>> for the link to be up. For other interfaces, possibly even on the same >>>> system, where a device is present or maybe present we should wait for >>>> the link to come up. >>> >>> Keep discussions public. >>> >>> Your commit and property description mentions probe, which is nothing >>> related to hardware. Why the device would not be available during host >>> init (I understand we do not talk about hotplug as it is already >>> supported by Linux) in a way it is hardware property, not OS? >>> >>> Best regards, >>> Krzysztof >>> >> >> + everyone else I mistakenly didn't reply to earlier >> >> If I understand you correctly, the usage of probe is misleading >> because it doesn't have anything to do with the hardware. >> So your recommendation is to replace probe with device init, in the >> description of the property and the commit message? > > No, I asked there a question for which we need answer. > > device init is also OS task... You need to explain why this is a > property of hardware, not OS behavior. Actually let's be clearer - your cover letter says: "In some systems the link is not brought up during probe, but later in the context of an end-point turning on. (...) to skip this loop." so this is pure Linux OS stuff. You just want to control driver behavior from DT. Not at all DT property. Best regards, Krzysztof