On Fri, Apr 09, 2021 at 12:44:04AM CDT, Zev Weiss wrote: >On Fri, Apr 09, 2021 at 12:33:10AM CDT, Andrew Jeffery wrote: >> >> >>On Fri, 9 Apr 2021, at 14:45, Zev Weiss wrote: >>>On Fri, Mar 19, 2021 at 01:27:48AM CDT, Andrew Jeffery wrote: >>>>Given the deprecated binding, improve the ability to detect issues in >>>>the platform devicetrees. Further, a subsequent patch will introduce a >>>>new interrupts property for specifying SerIRQ behaviour, so convert >>>>before we do any further additions. >>>> >>>>Signed-off-by: Andrew Jeffery <andrew@xxxxxxxx> >>>>--- >>>> .../bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml | 92 +++++++++++++++++++ >>>> .../bindings/ipmi/aspeed-kcs-bmc.txt | 33 ------- >>>> 2 files changed, 92 insertions(+), 33 deletions(-) >>>> create mode 100644 Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml >>>> delete mode 100644 Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt >>>> >>>>diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml >>>>new file mode 100644 >>>>index 000000000000..697ca575454f >>>>--- /dev/null >>>>+++ b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml >>>>@@ -0,0 +1,92 @@ >>>>+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>>+%YAML 1.2 >>>>+--- >>>>+$id: http://devicetree.org/schemas/ipmi/aspeed,ast2400-kcs-bmc.yaml >>>>+$schema: http://devicetree.org/meta-schemas/core.yaml >>>>+ >>>>+title: ASPEED BMC KCS Devices >>>>+ >>>>+maintainers: >>>>+ - Andrew Jeffery <andrew@xxxxxxxx> >>>>+ >>>>+description: | >>>>+ The Aspeed BMC SoCs typically use the Keyboard-Controller-Style (KCS) >>>>+ interfaces on the LPC bus for in-band IPMI communication with their host. >>>>+ >>>>+properties: >>>>+ compatible: >>>>+ oneOf: >>>>+ - description: Channel ID derived from reg >>>>+ items: >>>>+ enum: >>>>+ - aspeed,ast2400-kcs-bmc-v2 >>>>+ - aspeed,ast2500-kcs-bmc-v2 >>>>+ - aspeed,ast2600-kcs-bmc >>> >>>Should this have a "-v2" suffix? >> >>Well, that was kind of a matter of perspective. The 2600 compatible was >>added after we'd done the v2 of the binding for the 2400 and 2500 so it >>never needed correcting. But it is a case of "don't use the deprecated >>properties with the 2600 compatible". >> >>I don't think a change is necessary? >> > >It just looked inconsistent with the corresponding string in the >ast_kcs_bmc_match[] table; perhaps that should be changed instead then? > ...except I realize now I only saw the 2600 v2 string in the match table because I put it there myself in the process of resolving a conflict when applying your series to the openbmc dev-5.10 branch for testing purposes. So nevermind on this. Reviewed-by: Zev Weiss <zweiss@xxxxxxxxxxx>
