Re: [PATCH 1/3] dt-bindings: net: can: m_can: Add Documentation for stb-gpios

Rob,

On 03/02/20 5:36 pm, Rob Herring wrote:

On Thu, Jan 23, 2020 at 01:09:41PM +0530, Faiz Abbas wrote:

quoted

Hi,

On 22/01/20 8:04 pm, Dan Murphy wrote:

quoted

Sekhar

On 1/22/20 8:24 AM, Sekhar Nori wrote:

quoted

On 22/01/20 7:05 PM, Dan Murphy wrote:

quoted

Faiz

On 1/22/20 2:03 AM, Faiz Abbas wrote:

quoted

The CAN transceiver on some boards has an STB pin which is
used to control its standby mode. Add an optional property
stb-gpios to toggle the same.

Signed-off-by: Faiz Abbas <redacted>
Signed-off-by: Sekhar Nori <redacted>
---
   Documentation/devicetree/bindings/net/can/m_can.txt | 2 ++
   1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/can/m_can.txt

b/Documentation/devicetree/bindings/net/can/m_can.txt
index ed614383af9c..cc8ba3f7a2aa 100644

--- a/Documentation/devicetree/bindings/net/can/m_can.txt
+++ b/Documentation/devicetree/bindings/net/can/m_can.txt

@@ -48,6 +48,8 @@ Optional Subnode:

                 that can be used for CAN/CAN-FD modes. See
               
Documentation/devicetree/bindings/net/can/can-transceiver.txt
                 for details.
+stb-gpios        : gpio node to toggle the STB (standby) signal on
the transceiver
+

The m_can.txt is for the m_can framework.  If this is specific to the
platform then it really does not belong here.

If the platform has specific nodes then maybe we need a
m_can_platform.txt binding for specific platform nodes.  But I leave
that decision to Rob.

Since this is transceiver enable, should this not be in
Documentation/devicetree/bindings/net/can/can-transceiver.txt?

The transceiver node is just a node without an associated device. I had
tried to convert it to a phy implementation but that idea got shot down
here:

https://lore.kernel.org/patchwork/patch/1006238/

Nodes and drivers are not a 1-1 thing. Is the transceiver a separate h/w 
device? If so, then it should be a separate node and properties of that 
device go in its node. 

The transceiver is indeed a separate device.

Also, nothing is stopping you from using the PHY

binding without using the kernel's PHY framework.

The phy framework seemed like the best code reuse to implement it.

As to whether it should be a separate phy driver, I think probably the 
wrong decision was made. We always seem to start out with no PHY on 
these things and the complexity just grows until we need one. 

We should be able to handle two properties (one max-datarate and the
other regulator node) for now. If we have to add more complex parts then
maybe we can think about the driver. I am just adding a xceiver
regulator for now.

Thanks,
Faiz