On 4/21/2024 3:14 PM, Wren Turkal wrote: > On 4/18/24 3:42 PM, Bartosz Golaszewski wrote: >>> 1) do you meet the case that EPROBE_DEFER is returned ? >>> >> It doesn't matter. It's about correct usage of a programming interface. > > In case you are not aware, this apparent correct usage of the > programming interface breaks real hardware. As a kernel user with this > problem, I am just wondering if we expect a fix to land before v6.9 lands. > > If we can't find the a fix that has "correct usage of the programming > interface" before 6.9 closes out, would we be able to revert this change > considering that it causes a real userspace regression in that the BT on > some laptops simply don't work now? I guess I am asking if this > theoretical correction more important than breaking actual currently > supported hardware? > > Real users like me are hurt by this. In my case, I am using a laptop > that was shipped in 2020 with Linux by Dell that included working BT > support. I now have broken BT hardware that is barely usable at all. > > And as a kernel user, I thought the kernel had a no regression policy. > Granted, I don't know the specific details of how it works. Does that > policy include support of widely deployed hardware? > > Just so you know, I am just trying to understand what to expect. > > Also, I want to offer help. Is there anything I can do to help y'all > reach a resolution? > > Thanks, > wt per QCA6390. we have correct usage of a programming interface. as my reply at below link, we don't need to take care bout Bartosz's question since it is not relevant with this issue. https://lore.kernel.org/all/01677a26-ea91-47cc-bdc4-283cf313d8e4@xxxxxxxxxxx/
