Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Kernel panic: gpioctl list + odroid-c1



> On May 10, 2022, at 8:46 PM, Brook Milligan <brook%nmsu.edu@localhost> wrote:
> 
> One more piece of information.
> 
> src/sys/arch/arm/amlogic/meson8b_pinctrl.c includes the following code:
> 
> static const struct meson_pinctrl_gpio meson8b_cbus_gpios[] = {
> 
> 	… < deleted sections > …
> 
> 	/* GPIODV */
> 	CBUS_GPIO(GPIODV_24, 6, 24, 0, 24),
> 	CBUS_GPIO(GPIODV_25, 6, 25, 0, 25),
> 	CBUS_GPIO(GPIODV_26, 6, 26, 0, 26),
> 	CBUS_GPIO(GPIODV_27, 6, 27, 0, 27),
> 	CBUS_GPIO(GPIODV_28, 6, 28, 0, 28),
> 	CBUS_GPIO(GPIODV_29, 6, 29, 0, 29),
> 
> It seems that GPIODV_9 does not occur in the second list; I would have expected it to the be first entry.  Is there a reason for it to be missing?
> 
> Could this be the cause of the panic?

Further along: the short answer is yes.  The following patch fixes the immediate problem of the panic, although I have no idea if the data here are correct; I’m just following the pattern of the other entries.

Index: meson8b_pinctrl.c
===================================================================
RCS file: /cvsroot/src/sys/arch/arm/amlogic/meson8b_pinctrl.c,v
retrieving revision 1.2
diff -u -r1.2 meson8b_pinctrl.c
--- meson8b_pinctrl.c	14 Aug 2019 09:50:20 -0000	1.2
+++ meson8b_pinctrl.c	11 May 2022 13:08:29 -0000
@@ -226,6 +226,7 @@
 	CBUS_GPIO(GPIOY_14, 3, 14, 3, 14),
 
 	/* GPIODV */
+	CBUS_GPIO(GPIODV_9, 6, 9, 0, 9),
 	CBUS_GPIO(GPIODV_24, 6, 24, 0, 24),
 	CBUS_GPIO(GPIODV_25, 6, 25, 0, 25),
 	CBUS_GPIO(GPIODV_26, 6, 26, 0, 26),

I would appreciate confirmation that the data this patch adds to the lookup table is correct.

Clearly, however, there is a hidden problem somewhere else in the code.  This is a lookup table; the pin number (or potentially name) is the key.  Almost certainly, the problem was a missing entry causing the lookup to not match anything.  The presumably bogus information returned led to the panic.  This means that somewhere else in the code is lookup logic that is not detecting the “missing key” case, which means that there are potential panics lurking in the future whenever a table like this is incomplete.  Unfortunately, I have no idea where that lookup code is; ideas?

Unless I hear otherwise, I will commit this patch sometime soon.  In the meantime, I would appreciate feedback.

Thanks a lot.

Cheers,
Brook



Home | Main Index | Thread Index | Old Index