[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