Re: [PATCH 1/2] driver core: provide device_match_fwnode_ext()

[Bartosz Golaszewski]

On Fri, 20 Feb 2026 08:42:00 +0100, Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> said:
> On Thu, Feb 19, 2026 at 03:18:24PM -0600, Bartosz Golaszewski wrote:
>> On Thu, 19 Feb 2026 20:27:51 +0100, Andy Shevchenko
>> <andriy.shevchenko@xxxxxxxxxxxxxxx> said:
>> > On Thu, Feb 19, 2026 at 05:55:20PM +0100, Danilo Krummrich wrote:
>> >> On Thu Feb 19, 2026 at 5:39 PM CET, Bartosz Golaszewski wrote:
>
> ...
>
>> >> Also, is there a reason why we need both device_match_fwnode() *and*
>> >> device_match_fwnode_ext()?
>> >
>> > Yes. We don't want (at least for now) to dive into bug hunting in a 2+ years
>> > horizon if something goes wrong with [currently] working drivers that use
>> > device_match_fwnode() against the cases when there are primary and secondary
>> > fwnodes present.
>> >
>> > I won't put my bet that extending device_match_fwnode() won't break anything.
>> > And I don't want to invest (waste?) my time to learn each of the existing cases.
>> >
>> > The proposed way is robust and safest. And for the record, I will be the first
>> > person to push back device_match_fwnode() upgrade without a comprehensive testing
>> > on real (affected) HW.
>>
>> Who's got the final word here? I responded to Danilo's email saying I can fold
>> the new code into the existing function but you are against it.
>
> Of course I am not a maintainer, but as I said, I will be not okay without
> proven tests on the real HW. It's non-trivial change as it may lead to
> a problematic behaviour that one may not observe immediately (it might affect
> 1 out of 100s platforms). So, it will be hidden till unknown point in time
> in the future.
>
> I prefer safest way. And then we can convert case-by-case without hurry, which
> is the usual cause of the subtle bugs.
>

I agree, given how many problem some GPIO patches cause on x86 platforms months
after getting upstream.

Bartosz