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
--
You're more amazing than you think!
