Our product is built on a 3.10.17 kernel. I'm trying to incorporate support for the power-off interrupt using snvs_pwrkey.c driver. This driver was written toward a newer (4.x) kernel using regmap() and other related calls.
Am I on a fool's errand trying to get this driver working on a 3.10 kernel? Right now I'm getting a kernel panic, I think related to the return value from regmap(), in regmap_update_bits
[ 1.504251] snvs_pwrkey 20cc038.snvs-poweroff: Probing...
[ 1.509717] snvs_pwrkey 20cc038.snvs-poweroff: pdata maps to DC353A90
[ 1.516191] snvs_pwrkey 20cc038.snvs-poweroff: pdata->snvs maps to FFFFFDFB
[ 1.531681] snvs_pwrkey 20cc038.snvs-poweroff: Wakeup OK...
[ 1.537285] snvs_pwrkey 20cc038.snvs-poweroff: IRQ OK...
call to regmap_update_bits ( FFFFFDFB 00000038 00000020 00000020)
[ 1.542635] snvs_pwrkey 20cc038.snvs-poweroff: FFFFFDFB 00000038 00000020 00000020
[ 1.550246] Unable to handle kernel paging request at virtual address fffffe1b
[ 1.557494] pgd = c0004000
[ 1.560239] [fffffe1b] *pgd=3f77e821, *pte=00000000, *ppte=00000000
[ 1.566646] Internal error: Oops: 17 [#1] SMP ARM
[ 1.571376] Modules linked in:
[ 1.574497] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.10.17-ts-armv7lts2 #12
[ 1.581749] task: dc08c000 ti: dc08a000 task.ti: dc08a000
[ 1.587192] PC is at regmap_update_bits+0x20/0x64
[ 1.591935] LR is at imx_snvs_pwrkey_probe+0x14c/0x398
[ 1.597103] pc : [<c034163c>] lr : [<c03fcf70>] psr: 60000113
[ 1.597103] sp : dc08bd98 ip : dc08bdc8 fp : dc08bdc4
[ 1.608605] r10: c0821e9c r9 : c080b780 r8 : 00000020
[ 1.613855] r7 : 00000038 r6 : 00000020 r5 : 00000020 r4 : fffffdfb
[ 1.620407] r3 : 00000020 r2 : 00000020 r1 : 00000038 r0 : fffffdfb
[ 1.626962] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 1.634297] Control: 10c5387d Table: 1000404a DAC: 00000015
[ 1.640068] Process swapper/0 (pid: 1, stack limit = 0xdc08a238)
[ 1.646101] Stack: (0xdc08bd98 to 0xdc08c000)
I'm trying to get back into Linux drivers from the relative Stone Age of 2.06. Yes, I should have just stayed immersed...:)
Thanks,
John
