There are (at least) two levels of GPIO naming in Linux. Each GPIO controller provides a number of GPIOs, and the kernel can uniquely refer to any of them using a (controller, gpio index) pair. The kernel takes all the GPIOs from all controllers and assembles them into a flat list, giving each a unique number. It is those numbers that are used by the /sys/class/gpio userspace interface, but Device Tree uses the kernel method.
In Device Tree, the controller is selected using a reference to a label (normally "&gpio" for the BCM2835 GPIO controller). The standard controller uses an extra value to hold a flag indicating whether the polarity is active high (0) or active low (1) - this is backwards, but think of it as 0=normal and 1=inverted.
The mcp23s17 is a device on an SPI bus, but it is also a GPIO controller, and the Device Tree declaration must say so. This is already taken care of by the mcp23s17 overlay. Before I give you a link I should explain that the overlay parameter mechanism is quite limited, so to overcome these limitations the overlay includes all possible variants of controller, bus and chip enable, just activating the required one. Fortunately only the selected parts of the overlay end up in the final DT, otherwise it would get rather crowded.
I'm going to assume that you have an mcp23s017 on spi0.0, which corresponds to fragment 16 of the mcp23s17 overlay
. You need to copy this into your overlay, changing the "__dormant__" to say "__overlay__". This node has a label of "mcp23s17_00", and I'll assume you aren't changing that.
Now you've laid the groundwork, all that remains is to connect the gpio_leds instance to one of the GPIOs provided by the mcp23s17. The "bindings" document (a description of the DT interface presented by a driver) for the MCP is here
. Like the standard controller it wants a flags value, even though it is unused, so your GPIO reference becomes:
where I've guessed that 507 was GPIO 11 of the block based at 496.
By the way - you can remove the compatible string you added at the start of the overlay - it is wrong, but it is also completely ignored.
You might be wondering why we can't use the existing mcp23s17 overlay rather than copy a bit of it. The answer is that the labels defined by the overlay are local to the overlay, and so not available for use by other overlays. It is possible to work around this, but only by modifying the overlay containing the symbol to be exported in a rather ugly way - see the i2c-gpio overlay for an example of this technique.