Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The new compatible string 'microchip,mcp2542' is added as a standalone enum item in the binding but lacks corresponding support in the CAN transceiver PHY driver.
--
--- Patch [2]: [PATCH RFC 2/4] dt-bindings: phy: ti,tcan104x-can: Document Microchip MCP2542 ---
commit 43adb87775584a977c1d440864b9e805fba31d0e
Author: Stefan Wahren <[email protected]>
dt-bindings: phy: ti,tcan104x-can: Document Microchip MCP2542
The Microchip MCP2542 High-speed CAN transceiver with Sleep mode is a
pin-compatible alternative for the TI TCAN1042.
> diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> @@ -24,6 +24,7 @@ properties:
> - const: ti,tcan1046
> - const: nxp,tja1048
> - enum:
> + - microchip,mcp2542
[Severity: High]
Since the compatible string is added as a standalone enum item, a device tree
node will not have a fallback string. Looking at the CAN transceiver PHY driver
in drivers/phy/phy-can-transceiver.c, the match table lacks this new string:
static const struct of_device_id can_transceiver_phy_ids[] = {
{
.compatible = "ti,tcan1042",
.data = &tcan1042_drvdata
},
Does this cause the PHY driver to fail to probe for the new device? If this is
a pin-compatible alternative for ti,tcan1042, should the binding require a
fallback compatible string so the existing driver can match it, or does the
driver need to be updated to support the standalone string?
> - ti,tcan1042
> - ti,tcan1043
--
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.