Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No interrupts on MCP23017 following changes from #3207 #3449

Closed
ggiraudon opened this issue Feb 4, 2020 · 3 comments
Closed

No interrupts on MCP23017 following changes from #3207 #3449

ggiraudon opened this issue Feb 4, 2020 · 3 comments

Comments

@ggiraudon
Copy link

Describe the bug
With the latest device tree overlay for the MCP23017 on kernel 4.19, loading the overlay as specified in the documentation only partially works.
The device is present and shows up in /sys/class/gpio but exporting a pin yields an entry with no edge detection.
Kernel logs also indicate a failure upon boot.
[ 3.487510] i2c i2c-1: of_i2c: modalias failure on /soc/i2c@7e804000/mcp@20 [ 3.487526] i2c i2c-1: Failed to create I2C device for /soc/i2c@7e804000/mcp@20
Replacing the overlay with the one from kernel 4.14 (prior to the changes from #3207) , the error goes away and interrupts work again.

To reproduce

You will require an MCP2307 connected to the i2c bus and a interrupt line connected to a GPIO pin.
In my case, the MCP is at address 0x25 and is connected to gpiopin 27 for interrupts
Install Raspbian buster (or any raspberry pi linux distribution) with kernel 4.19
Modify the config.txt file to load the mcp23017 overlay (dtoverlay=mcp23017,gpiopin=27,addr=0x25)

Expected behaviour
Running "dmesg | grep mcp" should show no failure message regarding the mcp23017 module
Exporting a gpio pin from the MCP with ' echo "488" > /sys/class/gpio/export ' will yield an entry with interrupt handling (edge) :
root@raspberrypi:~# ls /sys/class/gpio/gpio488/ active_low device direction edge power subsystem uevent value

And interrupt should be registered for the BCM's GPIO pin
`
root@raspberrypi:~# cat /proc/interrupts
...
56: 1 0 0 0 pinctrl-bcm2835 9 Edge gpio-ir-recv-irq

57: 0 0 0 0 pinctrl-bcm2835 27 Level 1-0025
...
`

Actual behaviour
Running "dmesg | grep mcp" will show
[ 3.487510] i2c i2c-1: of_i2c: modalias failure on /soc/i2c@7e804000/mcp@20 [ 3.487526] i2c i2c-1: Failed to create I2C device for /soc/i2c@7e804000/mcp@20

Tryint to export a gpio pin from the MCP with ' echo "488" > /sys/class/gpio/export ' will yield an entry with no interrupt handling
root@raspberrypi:~# ls /sys/class/gpio/gpio488/ active_low device direction power subsystem uevent value

And no interrupt is registered for the GPIO pin on the BCM

root@raspberrypi:~# cat /proc/interrupts ... 56: 1 0 0 0 pinctrl-bcm2835 9 Edge gpio-ir-recv-irq ...

System

  • Which model of Raspberry Pi? Pi4B

  • Which OS and version (cat /etc/rpi-issue)?
    Raspberry Pi reference 2019-09-26
    Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 80d486687ea77d31fc3fc13cf3a2f8b464e129be, stage2

  • Which firmware version (vcgencmd version)?
    Jan 10 2020 16:52:04
    Copyright (c) 2012 Broadcom
    version fdb5c37e330e7cb3027ac4fcc5b1cd5f244b351f (clean) (release) (start)

  • Which kernel version (uname -a)?
    Linux raspberrypi 4.19.93-v7l+ __DWC_DMA_FREE warning in dwc_otg (kernel 4.4) #1290 SMP Fri Jan 10 16:45:11 GMT 2020 armv7l GNU/Linux

Workaround
Pulling the dts from prior the changes in #3207 and compiling it yields a dtb that fixes the issue (or at least bypasses it).
The dts used was
https://github.com/raspberrypi/linux/blob/34ae8ccc3d4c72b95aae68f2bd150246e44d6a5d/arch/arm/boot/dts/overlays/mcp23017-overlay.dts

Additional context
I suspect there might be an issue between the kernel driver and the dtbo ?

pelwell added a commit that referenced this issue Feb 4, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
@pelwell
Copy link
Contributor

pelwell commented Feb 4, 2020

The bug was introduced in the second commit of #3211, the part that made interrupt support optional. Splitting the DT node in two, as this does, then requires that any renaming is done to both parts otherwise one comes adrift from the other - which is what causes the error message (the kernel is basically complaining that the I2C device has no compatible string). The simple fix is to add &mcp23017_irq>,"reg:0"; to the addr parameter declaration.

However, that ignores another problem with this overlay that prevents it from being loaded at runtime. The kernel's dynamic overlay application logic won't permit an overlay to overwrite an existing node; it can overwrite all the properties within a node, but not the node itself. This means that fragment four is breaking the rules. It would be nice if the fragment could actually be made to add to the node already created by fragment 2, and you can.

The technique is already used by fragment 3 to patch the compatible string, and we could modify fragment 4 to work the same way by changing the target to &mcp23017 and removing the mcp@20 { wrapper node. Unfortunately this method doesn't work with runtime loading either:

$ pi@raspberrypi:~ $ sudo dtoverlay mcp23017 mcp23008
* Failed to apply overlay '0_mcp23017' (kernel)
pi@raspberrypi:~ $ dmesg | tail
...
[  231.530328] OF: overlay: find target, node: /fragment@3, phandle 0xc9 not found
[  231.530337] OF: overlay: init_overlay_changeset() failed, ret = -22

One solution would be to embed multiple versions of the overlay and select the required variant (interrupts on or off, mcp23008 on or off), but this is ugly. There are some new overlay syntax features that could probably be used to make this overlay universally applicable without bloating it, but the result would be ugly. Instead, the overlay application logic needs to be improved to take care of the "in-overlay" fragments before applying the remainder to the base DTB. I'm sure there will be gotchas in the implementation but it ought to be possible and would solve the runtime problems - I'll add it to the To Do list.

In the meantime I've pushed 11ef396 which should fix this issue.

@ggiraudon
Copy link
Author

Thank you for the update.
I can confirm the commit fixes the issue.

@pelwell
Copy link
Contributor

pelwell commented Feb 5, 2020

Thanks - I'm going to close this issue, but the runtime overlay change is on the list.

@pelwell pelwell closed this as completed Feb 5, 2020
pelwell added a commit that referenced this issue Feb 5, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
pelwell added a commit that referenced this issue Feb 5, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Feb 6, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Feb 6, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix added a commit to raspberrypi/firmware that referenced this issue Feb 6, 2020
kernel: configs: Add NFS 4.2 support
See: raspberrypi/linux#3397

kernel: overlays: dwc2: Increase RX FIFO size
See: raspberrypi/linux#3447

kernel: overlays: Fix mcp23017's addr parameter
See: raspberrypi/linux#3449

kernel: Fix a sh1106-spi, ssd1306-spi, ssd1351-spi overlays
See: raspberrypi/linux#3451

kernel: overlays: add hdmi-backlight-hwhack-gpio-overlay
See: raspberrypi/linux#3453

kernel: Revert brcmfmac: Disable power management
kernel: brcmfmac: Increase power saving delay to 2s

firmware: platform: 2711: Support overclocking gpu frequencies
See: #1290
popcornmix added a commit to Hexxeh/rpi-firmware that referenced this issue Feb 6, 2020
kernel: configs: Add NFS 4.2 support
See: raspberrypi/linux#3397

kernel: overlays: dwc2: Increase RX FIFO size
See: raspberrypi/linux#3447

kernel: overlays: Fix mcp23017's addr parameter
See: raspberrypi/linux#3449

kernel: Fix a sh1106-spi, ssd1306-spi, ssd1351-spi overlays
See: raspberrypi/linux#3451

kernel: overlays: add hdmi-backlight-hwhack-gpio-overlay
See: raspberrypi/linux#3453

kernel: Revert brcmfmac: Disable power management
kernel: brcmfmac: Increase power saving delay to 2s

firmware: platform: 2711: Support overclocking gpu frequencies
See: raspberrypi/firmware#1290
popcornmix pushed a commit that referenced this issue Feb 20, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Feb 20, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Feb 25, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Feb 25, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Mar 6, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Mar 10, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Mar 23, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Mar 23, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Mar 27, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Mar 27, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Apr 1, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Apr 1, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Apr 7, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Apr 16, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Apr 16, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Apr 27, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue May 4, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue May 11, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue May 20, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue May 20, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Jun 3, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/linux-mvista that referenced this issue Jun 8, 2020
Source: kernel.org
MR: 103889
Type: Enhancement
Disposition: Merged from https://github.com/raspberrypi/linux.git rpi-5.4.y
ChangeID: 050892f8b5c8f24706b7d6535087e7f0a57ca505
Description:

The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: raspberrypi/linux#3449

Signed-off-by: Phil Elwell <[email protected]>
Signed-off-by: Corey Minyard <[email protected]>
popcornmix pushed a commit that referenced this issue Jun 10, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Jun 17, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Jun 26, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Jul 1, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
popcornmix pushed a commit that referenced this issue Jul 13, 2020
The addr parameter of the mcp23017 overlay was broken by the addition
of the noints parameter; splitting the mcp node in two without also
modifying the second half from the addr parameter would cause the two
halves to separate. Change the implementation strategy to patch
fragment 2 (as was originally proposed). This will prevent the
overlay from being applied at runtime until the "dtoverlay" command
is improved, but the overlay already has this restriction due to
fragment 3 so this isn't a step backwards.

See: #3449

Signed-off-by: Phil Elwell <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants