On 30.03.22 12:35, Piotr Chmura wrote: > > W dniu 30.03.2022 o 11:55, Thorsten Leemhuis pisze: >> On 29.03.22 21:21, Robert Schlabbach wrote: >>> the patch linked in the bugzilla ticket: >>> https://lore.kernel.org/linux-media/6f84b7f4-3ede-ae55-e99b-a9d4108c80e2@xxxxxxxxx/ >>> >>> should indeed fix the issue. >> Ahh, the comment mentioning it was added shortly after I sent my mail. >> #regzbot monitor: >> https://lore.kernel.org/linux-media/6f84b7f4-3ede-ae55-e99b-a9d4108c80e2@xxxxxxxxx/ >> >> >> Adding Piotr, the patches' author to the CC, who also replied. >> >> BTW: that patch is afaics missing a Fixes tag specifying the culprit and >> a `Cc: stable@xxxxxxxxxxxxxxx # 5.17.x` tag to make sure it's quickly >> backported to the stable tree, as among others explained here: >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/handling-regressions.rst >> > Sorry for my inconvenience. Don't worry, everything fine. In a case like... > I just fixed my device and wanted to share > solution with the "world". I'm not familiar with all kernel development > convention (yet). ...this someone else should point such details out to the submitter and/or add these tags when applying the patch. @Robert: Do you know which commit causes this regression and could tell us for a proper Fixes: tag? Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) P.S.: As the Linux kernel's regression tracker I'm getting a lot of reports on my table. I can only look briefly into most of them and lack knowledge about most of the areas they concern. I thus unfortunately will sometimes get things wrong or miss something important. I hope that's not the case here; if you think it is, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight. >>> The error was that the rom_id and required >>> fields were swapped in the table, so the non-zero rom_id was taken as a >>> "true" required boolean value, thus incorrectly evaluating that the >>> chip requires a firmware file to operate when in fact it does not. >>> I have tested the patch and found it worked for me. But I do not know >>> how to push this further along: >>> https://patchwork.linuxtv.org/project/linux-media/patch/6f84b7f4-3ede-ae55-e99b-a9d4108c80e2@xxxxxxxxx/ >>> >> Mauro, what's up here? The patch fixes a regression and thus afaics >> should quickly find its way towards mainline to get it into the stable >> tree, as explained in the (bran new) document linked above. >> >> Ciao, Thorsten >> >>> Gesendet: Dienstag, 29. März 2022 um 10:33 Uhr >>> Von: "Thorsten Leemhuis" <regressions@xxxxxxxxxxxxx> >>> An: "Antti Palosaari" <crope@xxxxxx>, "Mauro Carvalho Chehab" >>> <mchehab+huawei@xxxxxxxxxx>, "Robert Schlabbach" <robert_s@xxxxxxx> >>> Cc: "regressions@xxxxxxxxxxxxxxx" <regressions@xxxxxxxxxxxxxxx>, >>> az0123456@xxxxxx, "Linux Media Mailing List" >>> <linux-media@xxxxxxxxxxxxxxx>, "Linux Kernel Mailing List" >>> <linux-kernel@xxxxxxxxxxxxxxx> >>> Betreff: Bug 215726 - si2157.c: mention name of the missing firmware >>> file >>> Hi, this is your Linux kernel regression tracker. >>> >>> I noticed a regression report in bugzilla.kernel.org that afaics nobody >>> acted upon since it was reported about a week ago, that's why I decided >>> to forward it to the lists and all people that seemed to be relevant >>> here. To quote from https://bugzilla.kernel.org/show_bug.cgi?id=215726 : >>> >>>> I get the following error messages when trying to use si2157.ko in >>>> linux 5.17: >>>> si2157 13-0060: found a 'Silicon Labs Si2157-A30 ROM 0x50' >>>> si2157 13-0060: Can't continue without a firmware >>>> I did work in linux 5.16.16 without a firmware file. Unfortunately >>>> the driver does not tell me the name of the missing firmware file. >>> Could somebody take a look into this? Or was this discussed somewhere >>> else already? Or even fixed? >>> >>> > >
