On Tue, Dec 10, 2024 at 04:15:18PM -0800, Dmitry Torokhov wrote: > On Tue, Mar 26, 2024 at 02:11:06PM +0000, Charles Keepax wrote: > > SPI devices can specify a cs-gpios property to enumerate their > > chip selects. Under device tree, a zero entry in this property can > > be used to specify that a particular chip select is using the SPI > > controllers native chip select, for example: > > > > cs-gpios = <&gpio1 0 0>, <0>; > > > > Here the second chip select is native. However, when using swnodes > > there is currently no way to specify a native chip select. The > > proposal here is to register a swnode_gpio_undefined software node, > > that can be specified to allow the indication of a native chip > > select. For example: > > > > static const struct software_node_ref_args device_cs_refs[] = { > > { > > .node = &device_gpiochip_swnode, > > .nargs = 2, > > .args = { 0, GPIO_ACTIVE_LOW }, > > }, > > { > > .node = &swnode_gpio_undefined, > > .nargs = 0, > > }, > > }; > > I am sorry, I am very late to the party, but wouldn't it all work by > simply setting ".node" to NULL? As far as I can see we have in > software_node_get_reference_args(): > > ... > > if (index * sizeof(*ref) >= prop->length) > return -ENOENT; > > ref_array = prop->pointer; > ref = &ref_array[index]; > > refnode = software_node_fwnode(ref->node); > if (!refnode) > return -ENOENT; > > if ref->node is NULL then software_node_fwnode(ref->node) will return > NULL and we'll get -ENOENT which will bubble up to > gpiod_get_index_optional() in SPI core. > I did definitely try that at the time, and there was definitely some issue with that approach. I think it might have related to something around how the GPIO stuff structures things. Alas, it is long enough ago that the details are escaping me, if I manage to find a spare minute I will try to refresh my memory and report back. Thanks, Charles