Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <f8cbb12c-590b-28a3-e3e9-d3fb0d7e3c90@gmx.com>
Date:   Sat, 1 Oct 2022 10:47:55 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.1
Subject: Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla
 blues"
To:     Greg KH <gregkh@linuxfoundation.org>
Cc:     Thorsten Leemhuis <linux@leemhuis.info>,
        Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
        workflows@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        "regressions@lists.linux.dev" <regressions@lists.linux.dev>,
        ksummit@lists.linux.dev
References: <aa876027-1038-3e4a-b16a-c144f674c0b0@leemhuis.info>
 <05d149a0-e3de-8b09-ecc0-3ea73e080be3@leemhuis.info>
 <9a2fdff8-d0d3-ebba-d344-3c1016237fe5@gmx.com> <YzgY9X/DM9t/ZuJe@kroah.com>
From:   "Artem S. Tashkinov" <aros@gmx.com>
In-Reply-To: <YzgY9X/DM9t/ZuJe@kroah.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On 10/1/22 10:39, Greg KH wrote:
> On Sat, Oct 01, 2022 at 10:30:22AM +0000, Artem S. Tashkinov wrote:
>> Here are two other issues which absolutely suck in terms of dealing wit=
h
>> the kernel.
>>
>> - 1 -
>>
>> I have a 20+ years experience in IT and some kernel issues are just
>> baffling in terms of trying to understand what to do about them.
>>
>> Here's an example: https://bugzilla.kernel.org/show_bug.cgi?id=3D216274
>>
>> What should I do about that? Who's responsible for this? Who should I C=
C?
>
> Input subsystem.

It's great you've replied immediately, what about hundreds or even
thousands of other bug reports where people have no clue who has to be
CC'ed?

>
>> Here's what I'm getting with Linux 5.19.12:
>>
>> platform wdat_wdt: failed to claim resource 5: [mem
>> 0x00000000-0xffffffff7fffffff]
>
> $ find . | grep wdat_wdt
> ./drivers/watchdog/wdat_wdt.c
> $ ./scripts/get_maintainer.pl --file ./drivers/watchdog/wdat_wdt.c
> Wim Van Sebroeck <wim@linux-watchdog.org> (maintainer:WATCHDOG DEVICE DR=
IVERS)
> Guenter Roeck <linux@roeck-us.net> (maintainer:WATCHDOG DEVICE DRIVERS)
> linux-watchdog@vger.kernel.org (open list:WATCHDOG DEVICE DRIVERS)
> linux-kernel@vger.kernel.org (open list)
>
>> ACPI: watchdog: Device creation failed: -16
>> ACPI BIOS Error (bug): Could not resolve symbol
>> [\_SB.PCI0.XHC.RHUB.TPLD], AE_NOT_FOUND (20220331/psargs-330)
>> ACPI Error: Aborting method \_SB.UBTC.CR01._PLD due to previous error
>> (AE_NOT_FOUND) (20220331/psparse-529)
>
> Send to ACPI list as described in the MAINTAINERS file.

The more important question is whether I should even bother anyone in
the first place.

And it's not just ACPI, what about "platform wdat_wdt: failed to claim
resource 5", "platform MSFT0101:00: failed to claim resource 1",
"lis3lv02d: unknown sensor type 0x0"?

I know you can probably identify the related components in a few
seconds, but I'm quite sure you won't be doing that for every bug report.

Should this be addressed?

Best regards,
Artem