Em Thu, 3 Oct 2019 21:51:35 +0200add module param say 'gonso_hack_vg0022a'
Gonsolo <gonsolo@xxxxxxxxx> escreveu:
I don't know. I was not the one that extracted the firmware. I guess1) The firmware file is likely at the Windows driver for this deviceIf you tell me how I'm willing to do this. :)
(probably using a different format). It should be possible to get
it from there.
Antti did it.
I suspect that there are some comments about that in the past at the
ML. seek at lore.kernel.org.
The one that it is causing the problem. If I understood well, the2) Another possibility would be to add a way to tell the si2168 driverI don't get this. Which firmware, si2168 or si2157?
to not try to load a firmware, using the original one. That would
require adding a field at si2168_config to allow signalizing to it
that it should not try to load a firmware file, and add a quirk at
the af9035 that would set such flag for Logilink VG0022A.
culprit was the si2168 firmware.
I'm still for option 3: If there is a bogus chip revision number it'sThat's a really bad solution. Returning 0xff is what happens when
likely the VG0022A and we can safely set fw to NULL, in which case
everything works.
All already working devices will continue to work as before.
With a low probability there are other devices that will return 0xffff
but a) they didn't work until now and b) they receive a clear message
that they return bogus numbers and this works just for the VG0022A, in
which case this hardware can be tested.
At last, *my* VG0022A will work without a custom kernel which I'm a
big fan of. :))
Are there any counterarguments except that it is not the cleanest
solution in the universe? ;)
things go wrong during I2C transfers. Several problems can cause it,
including device misfunction. Every time someone comes with a patch
trying to ignore it, things go sideways for other devices (existing
or future ones).
Ignoring errors is always a bad idea.