mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Michael Walle <michael@walle.cc>,
	Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Horatiu Vultur <horatiu.vultur@microchip.com>
Subject: Re: fwnode_for_each_child_node() and OF backend discrepancy
Date: Tue, 28 Jun 2022 15:51:00 +0200	[thread overview]
Message-ID: <3ab8afab-b6b7-46aa-06d4-6740cee422d7@linaro.org> (raw)
In-Reply-To: <9e58f421c27121977d11381530757a6e@walle.cc>

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 <michael@walle.cc> 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

  reply	other threads:[~2022-06-28 13:51 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-27 12:49 Michael Walle
2022-06-27 13:08 ` Krzysztof Kozlowski
2022-06-27 13:33   ` Rafael J. Wysocki
2022-06-28 10:32     ` Krzysztof Kozlowski
2022-06-28 14:41       ` Sakari Ailus
2022-06-29 10:50       ` Rafael J. Wysocki
2022-06-29 13:01         ` Grant Likely
2022-06-28 11:10 ` Andy Shevchenko
2022-06-28 11:36   ` Michael Walle
2022-06-28 13:11     ` Andy Shevchenko
2022-06-28 13:23       ` Michael Walle
2022-06-28 13:29         ` Andy Shevchenko
2022-06-28 13:47           ` Michael Walle
2022-06-28 13:51             ` Krzysztof Kozlowski [this message]
2022-06-28 14:22               ` Michael Walle
2022-06-28 14:36                 ` Krzysztof Kozlowski
2022-06-28 15:09                   ` Michael Walle
2022-06-28 15:17                     ` Krzysztof Kozlowski
2022-06-28 20:28                       ` Andy Shevchenko
2022-06-28 20:52                         ` Horatiu Vultur
2022-06-28 21:07                           ` Michael Walle
2022-06-30 20:16                             ` Horatiu Vultur
2022-06-30 21:00                               ` Michael Walle
2022-06-30 21:21                                 ` Vladimir Oltean
2022-06-30 21:32                                   ` Michael Walle
2022-06-28 21:59             ` Vladimir Oltean

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3ab8afab-b6b7-46aa-06d4-6740cee422d7@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=horatiu.vultur@microchip.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael@walle.cc \
    --cc=rafael@kernel.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®