Pin configuration conflict and NULL pointer dereference on RPi 3

[Stefan Wahren]

Hi Gerd,

> Gerd Hoffmann <kraxel at redhat.com> hat am 2. Juni 2016 um 18:07 geschrieben:
> 
> 
> On Do, 2016-06-02 at 11:31 +0200, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > > > Patches 20-32 are for the wifi.  Mostly from Eric's bcm2837-wireless
> > > > branch.  They clearly need some more love, but do the job for now.
> > > 
> > > I just came up with a fix that should replace patch #29, which means
> > > I'll trust the expander stuff a lot more.  With the expander working,
> > > you should be able to use pin 4 on it for HDMI hotplug detect, at which
> > > point graphics should work.
> > 
> > Tried that.  i2c not working.  There seems to be a disagreement who owns
> > gpio pin 45:
> > 
> > [root at pi-three linux]# dmesg | grep i2c
> > [    2.354380] i2c /dev entries driver
> > [    3.496734] pinctrl-bcm2835 3f200000.gpio: pin gpio45 already
> > requested by 3f20c000.pwm; cannot claim for 3f205000.i2c
> > [    3.512506] pinctrl-bcm2835 3f200000.gpio: pin-45 (3f205000.i2c)
> > status -22
> > [    3.540488] i2c-bcm2835 3f205000.i2c: Error applying setting, reverse
> > things back
> > [    4.551683] i2c-bcm2835 3f205000.i2c: i2c transfer timed out
> > [    4.574599] i2c-bcm2835 3f805000.i2c: Could not read clock-frequency
> > property
> 
> Tried to disable pwm in dt:
> 
>    -       status = "okay";
>    +       status = "disabled";
> 
> Now i2c is happy, and fxl6408 seems to work too:
> 
>    [root at pi-two ~]# dmesg | grep -i FXL6408
>    [    3.580660] fxl6408 0-0043: FXL6408 probe returned DID: 0x87
> 

i stumbled yesterday on this patch [1] which is related to this (still open) issue. I wrote to the patch author and he said that sometimes the i2c-bcm2835 on his RPi 3 (Aarch64 Kernel) crashed with a NULL pointer dereference. He also said that the random I2C timeouts like above

i2c-bcm2835 3f805000.i2c: i2c transfer timed out

still occurs. Also reported here [2].

Can you confirm any of these issues (requires PWM_BCM2835 and I2C_BCM2835 enabled)?

I've the suspicion that the unexpected interrupts are triggered by the pin muxing conflict at pin 45. Please refer to the firmware DT blob [3].

In order to fix the NULL pointer dereference i suggest the following:

------------------------------------>8------------------------------------------------
--- a/drivers/i2c/busses/i2c-bcm2835.c
+++ b/drivers/i2c/busses/i2c-bcm2835.c
@@ -195,7 +195,9 @@ static irqreturn_t bcm2835_i2c_isr(int this_irq, void *data)
        }
 
        if (val & BCM2835_I2C_S_DONE) {
-               if (i2c_dev->curr_msg->flags & I2C_M_RD) {
+               if (!i2c_dev->curr_msg) {
+                       WARN(1, "Got interrupt, but curr_msg is NULL\n");
+               } else if (i2c_dev->curr_msg->flags & I2C_M_RD) {
                        bcm2835_drain_rxfifo(i2c_dev);
                        val = bcm2835_i2c_readl(i2c_dev, BCM2835_I2C_S);
                }
------------------------------------>8------------------------------------------------

After that we can address pwm / i2c pin muxing conflict by moving those pin configurations out of bcm2835-rpi.dtsi.

[1] - https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-aarch64-rc/0002-i2c-bcm2835-prevent-null-pointer-dereference.patch
[2] - http://raspberrypi.stackexchange.com/questions/60084/i2c-transfer-failed-flooding-the-logs
[3] - https://github.com/raspberrypi/firmware/blob/master/extra/dt-blob.dts#L1011