Add FSI master scan conditional
Subsystems (2)
v2 cover Add FSI master scan conditional
Add new optional FSI master device tree property no-scan-on-init to indicate that it should not be scanned at init time. This is necessary in cases where such a scan would interfere with other FSI masters on the bus. For example, Hub FSI masters scanning while Host boot FSI bus operations are in progress causing arbitration errors.
Christopher Bostic (3):
dt-bindings: fsi: Add optional property no-scan-on-init
ARM: dts: fsi: Add optional master property no-scan-on-init
fsi: core: Add check for master property no-scan-on-init
Signature · 1 line
1.8.2.2
PATCH v2 1/3 dt-bindings: fsi: Add optional property no-scan-on-init
Add an optional FSI master property 'no-scan-on-init. This can be specified to indicate that a master should not be automatically scanned at init time. This is required in cases where a scan could interfere with another FSI master on the same bus.
--- Documentation/devicetree/bindings/fsi/fsi.txt | 7 +++++++ 1 file changed, 7 insertions(+)
Documentation/devicetree/bindings/fsi/fsi.txt +7 -0
@@ -56,6 +56,13 @@ addresses (link index and slave ID), and no size: #address-cells = <2>; #size-cells = <0>; +An optional boolean property can be added to indicate that a particular master +should not scan for connected devices at initialization time. This is +necessary in cases where a scan could cause arbitration issues with other +masters that may be present on the bus. + + no-scan-on-init; + FSI slaves ----------
Signature · 1 line
1.8.2.2
PATCH v2 2/3 ARM: dts: fsi: Add optional master property no-scan-on-init
In reply to Christopher BosticAdd new optional master property no-scan-on-init that specifies that at master init time it should not scan for connected devices. This is necessary in cases where a scan could interfere with other connected FSI masters on the same bus.
--- arch/arm/boot/dts/ibm-power9-cfam.dtsi | 2 ++ 1 file changed, 2 insertions(+)
arch/arm/boot/dts/ibm-power9-cfam.dtsi +2 -0
@@ -128,6 +128,8 @@ #address-cells = <2>; #size-cells = <0>; + no-scan-on-init; + cfam@1,0 { reg = <1 0>; #address-cells = <1>;
Signature · 1 line
1.8.2.2
PATCH v2 3/3 fsi: core: Add check for master property no-scan-on-init
In reply to Christopher BosticPrior to scanning a master check if the optional property no-scan-on-init is present. If it is then avoid scanning. This is necessary in cases where a master scan could interfere with another FSI master on the same bus.
---
v2 - Remove changes in hub and gpio masters and make check for device
tree property in the core itself.
--- drivers/fsi/fsi-core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/fsi/fsi-core.c +4 -1
@@ -900,6 +900,7 @@ static ssize_t master_break_store(struct device *dev,int fsi_master_register (struct fsi_master *master) {int rc; +struct device_node *np;if (!master)return -EINVAL ;
@@ -927,7 +928,9 @@ int fsi_master_register(struct fsi_master *master)return rc; } -fsi_master_scan (master); + np =dev_of_node (&master->dev); +if (!of_property_read_bool (np,"no-scan-on-init" )) +fsi_master_scan (master);return 0 ; }
Signature · 1 line
1.8.2.2
Re: [PATCH linux dev-4.10 v2 3/3] fsi: core: Add check for master property no-scan-on-init
Hi Chris,
Quoted 4 lines
Prior to scanning a master check if the optional property no-scan-on-init is present. If it is then avoid scanning. This is necessary in cases where a master scan could interfere with another FSI master on the same bus.
Looks good to me. We may need to be flexible with the property name (based on feedback from the DT folks, when we send to them for review), but that should be fine regardless.
Cheers,
Jeremy
Joel Stanley
AppliedRe: [PATCH linux dev-4.10 v2 3/3] fsi: core: Add check for master property no-scan-on-init
Quoted 7 lines · Jeremy Kerr
Hi Chris,
Quoted 4 lines
Prior to scanning a master check if the optional property no-scan-on-init is present. If it is then avoid scanning. This is necessary in cases where a master scan could interfere with another FSI master on the same bus.
Quoted 5 lines
Looks good to me. We may need to be flexible with the property name (based on feedback from the DT folks, when we send to them for review), but that should be fine regardless.
Acked-by Jeremy Kerr <[email protected]>
I've applied the series to dev-4.10.
Cheers,
Joel