Hi Sakari On 20/10/2020 23:49, Sakari Ailus wrote: > Hi Dan, > > On Tue, Oct 20, 2020 at 08:56:07PM +0100, Dan Scally wrote: >> Hi Sakari >> >> On 20/10/2020 13:06, Sakari Ailus wrote: >>> Hi Andy, >>> >>> On Tue, Oct 20, 2020 at 12:19:58PM +0300, Andy Shevchenko wrote: >>>> On Mon, Oct 19, 2020 at 11:59:01PM +0100, Daniel Scally wrote: >>>>> fwnode_graph_get_endpoint_by_id() will optionally parse enabled devices >>>>> only; that status being determined through the .device_is_available() op >>>>> of the device's fwnode. As software_nodes don't have that operation and >>>>> adding it is meaningless, we instead need to check if the device's fwnode >>>>> is a software_node and if so pass the appropriate flag to disable that >>>>> check >>>> Period. >>>> >>>> I'm wondering if actually this can be hidden in fwnode_graph_get_endpoint_by_id(). >>> The device availability test is actually there for a reason. Some firmware >>> implementations put all the potential devices in the tables and only one >>> (of some) of them are available. >>> >>> Could this be implemented so that if the node is a software node, then get >>> its parent and then see if that is available? >>> >>> I guess that could be implemented in software node ops. Any opinions? >> Actually when considering the cio2 device, it seems that >> set_secondary_fwnode() actually overwrites the _primary_, given >> fwnode_is_primary(dev->fwnode) returns false. So in at least some cases, >> this wouldn't work. > Ouch. I wonder when this happens --- have you checked what's the primary > there? I guess it might be if it's a PCI device without the corresponding > ACPI device node? Yes; it's null, and I think that diagnosis is correct. > I remember you had an is_available implementation that just returned true > for software nodes in an early version of the set? I think it would still > be a lesser bad in this case. Yep - I can put that back in and just drop this patch then; fine for me.
