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

Christopher Bostic cbostic at linux.vnet.ibm.com
Fri Aug 4 12:46:00 AEST 2017



On 8/3/17 8:43 PM, Jeremy Kerr wrote:
> 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.
Hi Jeremy,

Ok thanks for the detailed description.  Will get version 2 out shortly.

Thanks,
Chris


> Cheers,
>
>
> Jeremy
>



More information about the openbmc mailing list