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 79E27C433EF for ; Tue, 28 Jun 2022 13:51:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239560AbiF1NvG (ORCPT ); Tue, 28 Jun 2022 09:51:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56450 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239109AbiF1NvE (ORCPT ); Tue, 28 Jun 2022 09:51:04 -0400 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4FC1C1F62B for ; Tue, 28 Jun 2022 06:51:03 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id i1so13313927wrb.11 for ; Tue, 28 Jun 2022 06:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=CuCbBwkvPnJNnIdbwpSf7SFi7ylwDdTKSQ4thFgSXMQ=; b=jobcASpV9i7JAhttUMV5Qfwdjs4GAg+t7XuLGiCS3dZ0qTRZeDHlFwNyjDX7BC3VTS AroWtyAGMcY5qngbW0OneRSAd85GlXJSCSDWbZ9gTvkqcpUvW0rflbm6IBCBnxyeEJ5Q 3pOADyf6RUyQrw4W85auTePIZCceM+VYNOY32NJL0BPenAK6vYg2X3CDrltNnYfdTI0L gEZxqRiELzwhhoUCeEZWdBE6qya+gEj7UvgYWhKDxqq1TxJvh4UWaw1+EXzt7QCc35eN xBQj+Sgf8WQUKdaJYOj5p2fC1rfk/8D1/+015yQJDuilu5L5fNOx4F+FyjanYJPCuoQ+ a+tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=CuCbBwkvPnJNnIdbwpSf7SFi7ylwDdTKSQ4thFgSXMQ=; b=IbqNa8K2UiROXHO3ZHGavP1CJBFWXWow2sZ8/nH5/ZJcsjJaVvfcMfJkbwkZxbNjZw bvRGaXMYlZjPwdR/LLe3lVaZMxMVm3C27hFR2d34cqoa1AOd/eHyaDSfGVqw5BLVA/c0 Pycyr/eihw/cXlM/NBkeR6NIFvFooiiHmErKSPKH2a/rz8ejufY+2gc/157rQSuUXnhU 3+Om7JCnhQTv+au5/BYDVnLKDMBUdomtQEzRa5jP9putY65jOnYhr5Q87Cb1qRPEqzYV DXaqUHZ6IrOpufRAffJj+ZIesFMoivheoCxazncPpYJY0ZDctpqiVlcrexDp0wpKD/nT BX+w== X-Gm-Message-State: AJIora+fx8GdENeRG6zE3b291uFjY2Lmo5BOj/w4RExjrmRxpH7zbqSY 9an5bKFUUaMoTWwA1Ntr1GaVdQ== X-Google-Smtp-Source: AGRyM1vO42CnUgwJEKE3lPzV1mTghn8QpMp5Icmi8ZY5d2az84r+c2xdR5hmJcVfB+ceOdgJZWDqtg== X-Received: by 2002:a5d:430d:0:b0:210:2ce0:e2a9 with SMTP id h13-20020a5d430d000000b002102ce0e2a9mr17668939wrq.627.1656424261847; Tue, 28 Jun 2022 06:51:01 -0700 (PDT) Received: from [192.168.0.254] (xdsl-188-155-176-92.adslplus.ch. [188.155.176.92]) by smtp.gmail.com with ESMTPSA id v6-20020a5d6106000000b00213ba0cab3asm14014874wrt.44.2022.06.28.06.51.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jun 2022 06:51:01 -0700 (PDT) Message-ID: <3ab8afab-b6b7-46aa-06d4-6740cee422d7@linaro.org> Date: Tue, 28 Jun 2022 15:51:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: fwnode_for_each_child_node() and OF backend discrepancy Content-Language: en-US To: Michael Walle , Andy Shevchenko Cc: Andy Shevchenko , "Rafael J. Wysocki" , Rob Herring , Krzysztof Kozlowski , ACPI Devel Maling List , devicetree , Linux Kernel Mailing List , Horatiu Vultur References: <4e1d5db9dea68d82c94336a1d6aac404@walle.cc> <2f2d7685e0e43194270a310034004970@walle.cc> <9e58f421c27121977d11381530757a6e@walle.cc> From: Krzysztof Kozlowski In-Reply-To: <9e58f421c27121977d11381530757a6e@walle.cc> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 28/06/2022 15:47, Michael Walle wrote: > [adding Horatiu Vultur, because we now digress to the bug > in the switch, rather than that odd OF behavior] > > Am 2022-06-28 15:29, schrieb Andy Shevchenko: >> On Tue, Jun 28, 2022 at 3:23 PM Michael Walle wrote: >>> >>>>> I was trying to fix the lan966x driver [1] which doesn't work if there >>>>> are disabled nodes in between. >>>> >>>> Can you elaborate what's wrong now in the behaviour of the driver? In >>>> the code it uses twice the _available variant. >>> >>> Imagine the following device tree snippet: >>> port0 { >>> reg = <0>; >>> status = "okay"; >>> } >>> port1 { >>> reg = <1>; >>> status = "disabled"; >>> } >>> port@2 { >>> reg = <2>; >>> status = "okay"; >>> } >>> >>> The driver will set num_phys_ports to 2. When port@2 is probed, it >>> will have the (correct!) physical port number 2. That will then >>> trigger various EINVAL checks with "port_num >= num_phys_ports" or >>> WARN()s. >> >> It means the above mentioned condition is wrong: it should be >> >> "port_idx >= num_phys_ports" (if the port_idx doesn't exists, that's >> the bug in the first place) > > I can't follow you here. Please note, that you need the actual > physical port number. It's not a made up number, but corresponds > to a physical port on that ethernet switch. So you can't just skip > the disabled ones. port@2 must have port number 2. The number "2" you get from the reg property, so where is exactly the problem? If you want to validate it against some maximum number of ports, based on DTS, it makes no sense... One can supply a DTS with port number 10000 and 10000 nodes, or with specific property "maximum-port-number=10000". It would make sense if you validate it against driver-hard-coded values (which you later mentioned in your reply). Best regards, Krzysztof