[PATCH linux dev-4.10 1/2] drivers/fsi: Defer hub master scan on probe

[Jeremy Kerr]

Hi Chris,

> Prevent hub master from scanning its connected links/slaves
> at probe time.  Needed to keep from creating arbitration
> conflicts on the hub connected links during host boot
> FSI bus accesses.

This change doesn't need to be specific to the hub code - this just
makes it more complex.

As I mentioned yesterday, this can be done entirely in the fsi core.
When a master is registered, it has a reference to the of_node; just
check that. This way, we don't need to a) assume behaviour of different
master types, or 2) implement this logic in every master.

So, the basis of the change will just be something like:

    diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
    --- a/drivers/fsi/fsi-core.c
    +++ b/drivers/fsi/fsi-core.c
    @@ -927,7 +927,9 @@ int fsi_master_register(struct fsi_master *master)
     		return rc;
     	}

    -	fsi_master_scan(master);
    +	np = dev_of_node(&master->dev);
    +	if (!np || !of_property_read_bool(np, "no-scan-on-init"))
    +		fsi_master_scan(master);

     	return 0;
     }

This way, the no-scan-on-init (or whatever would be a better name)
node applies to the core, rather than every master implementation.
Consequently, this property is related to compatible = fsi-master and
not fsi-master-gpio or fsi-master-whatever-else.

[Also, don't forget to add this to the binding doc; it'd go in fsi.txt,
under the "FSI Masters" section].

Regarding names, I wouldn't use "probe" in the property name, as it's a
linux implementation detail. Some ideas:

 - no-scan-on-init
 - explicit-scan
 - arbitration-required
 - multiple-access

 : the latter two indicating that other entities can access the device, so
 we need to be careful when scanning, and scan explicitly. Or, anything
 else that you think is appropriate (but doesn't imply any specific OS
 implementation.

Cheers,


Jeremy