Comment 174 for bug 1283589

(In reply to Kieran Clancy from comment #149)

Thanks!

> Lastly, I've been thinking about whether this should be more hardware
> specific. While it would be trivial to instead add a sequence of table
> entries such as:
...

> I currently feel that just picking up the system vendor is enough, on the
> basis that:
>
> - this probably affects more Samsung systems than we realise
> - it really shouldn't do any harm on systems without this bug
> - if you look at the other entries in the table, they turn on quirks for
> things like "all ASUS systems", so it's not unprecedented

Yes, actually personally I think it might even be a good idea to always do this. I'm just not sure if the maintainers will agree.

>
> As for adding another boot parameter, my personal opinion is that it's not
> necessary since we have a simple user space program which can be used to
> check if systems are affected. That is, I can't really think of a situation
> where the user space program couldn't work just as well as a stop-gap
> measure until other hardware was added to the table.

Well, the issue with the user space program is currently that the EC status and data ports may have to be adjusted. At least for non-Samsung system I believe they would have to be. On the other hand - shouldn't it be possible to detect them automatically? You're right, a user space program might be a better way to test if this fixes any issues on different systems if we can make it work across different systems.

@San: Yes, that sounds like a good idea. We could use kernel.ubuntu.com/~kernel-ppa/mainline/ (and similar Fedora sources) as a basis and then create a .deb/rpm package for easy testing. Though I think there's already quite compelling evidence that this helps all around and does not cause any issues.

I'm still surprised how many things seem to work better now.