Conversation
|
this works fine for me in kernel 6.7.7 but no in 6.7.9 In 6.7.9 have this. Before your fix I have the same in 6.7.7. I have recompile with 6.7.9 kernel when I boot on 6.7.7, I have this after reload mod with : I can access to my camera :) |
I get exactly this already with kernel 6.7.7-200.fc39. |
|
I solve this issue with after deleting the external module you have to rebuild the dep module graph |
Thanks! This got @jwrdegoede 's COPR/ipu6-softisp kernel working for my X1 Carbon Gen 11, but apparently does not help with kernel-6.7.9-200.fc39.x86_64. When I delete all duplicate ljca modules on f39: # find /usr/lib/modules/6.7.9-200.fc39.x86_64/kernel/drivers/ -name "*ljca.ko*" -print -delete
/usr/lib/modules/6.7.9-200.fc39.x86_64/kernel/drivers/gpio/gpio-ljca.ko.xz
/usr/lib/modules/6.7.9-200.fc39.x86_64/kernel/drivers/i2c/busses/i2c-ljca.ko.xz
/usr/lib/modules/6.7.9-200.fc39.x86_64/kernel/drivers/spi/spi-ljca.ko.xz
/usr/lib/modules/6.7.9-200.fc39.x86_64/kernel/drivers/usb/misc/usb-ljca.ko.xz
# depmod -a
# shutdown -r nowI still get: # dmesg |grep GPIO
[ 7.586806] int3472-discrete INT3472:05: cannot find GPIO chip INTC1096:00, deferring
[ 7.593085] int3472-discrete INT3472:06: cannot find GPIO chip INTC1096:00, deferring
[ 7.595558] int3472-discrete INT3472:05: cannot find GPIO chip INTC1096:00, deferring
[ 7.601181] int3472-discrete INT3472:06: cannot find GPIO chip INTC1096:00, deferring
[ 7.604324] int3472-discrete INT3472:05: cannot find GPIO chip INTC1096:00, deferring
[ 7.608102] int3472-discrete INT3472:06: cannot find GPIO chip INTC1096:00, deferringEDIT: but indeed, afterwards, something happens: |
|
Ok looks good : |
|
Fedora kernels don't support /proc/config anymore, but: Should they be selected as modules, or just to avoid clashes with the ipu6-driver modules? |
|
In my case, yes |
It does also work for me on fc39 without the module selection after these steps. However, I often have to reboot to get it working. |
Add error logging to various probe() error paths to make it easier to debug probe() failures. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Calling isys_unregister_subdevices() on errors in isys_register_subdevices() leads to not yet registered subdevs getting unregistered resulting in a NULL pointer deref: [ 143.100638] BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 143.100655] RIP: 0010:__wake_up_common+0x2a/0xa0 ... [ 143.100672] Call Trace: [ 143.100674] <TASK> [ 143.100676] ? __die+0x23/0x70 [ 143.100680] ? page_fault_oops+0x171/0x4e0 [ 143.100684] ? exc_page_fault+0x7f/0x180 [ 143.100687] ? asm_exc_page_fault+0x26/0x30 [ 143.100690] ? __wake_up_common+0x2a/0xa0 [ 143.100692] __wake_up+0x36/0x60 [ 143.100697] __vb2_queue_cancel+0xd2/0x290 [videobuf2_common] [ 143.100706] vb2_core_queue_release+0x22/0x50 [videobuf2_common] [ 143.100714] isys_unregister_subdevices+0x49/0xb0 [intel_ipu6_isys] [ 143.100723] isys_probe+0x59c/0xa30 [intel_ipu6_isys] Fix this by only cleaning up subdevs which have actually been registered. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add a bunch of missing resource cleanups to ipu_isys_probe()'s error exit path. Add a missing mutex_destroy() to isys_remove() and drop the always true "if (isp->ipu_dir)" check before calling debugfs_remove_recursive(). This likely should have checked the debugfs_remove_recursive() argument is not NULL but that is not necessary, debugfs_remove_recursive() checks this itself. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
These patches are still relevant/useful. I'm pushing a new version rebased on the latest master branch now. |
baf00fd to
ab8b8be
Compare
Here is a set of improvements to the ipu6-isys probe() code which I wrote while working on fixing #205