Re: [PATCH 1/4] dt-bindings: phy: Add binding for TI TCAN104x CAN transceivers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 13, 2021 at 2:41 AM Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> wrote:
>
> On 12.04.2021 12:49:56, Rob Herring wrote:
> > On Mon, Apr 12, 2021 at 12:19:30PM +0200, Marc Kleine-Budde wrote:
> > > On 4/9/21 3:40 PM, Aswath Govindraju wrote:
> > > > Add binding documentation for TI TCAN104x CAN transceivers.
> > > >
> > > > Signed-off-by: Aswath Govindraju <a-govindraju@xxxxxx>
> > > > ---
> > > >  .../bindings/phy/ti,tcan104x-can.yaml         | 56 +++++++++++++++++++
> > > >  1 file changed, 56 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> > > > new file mode 100644
> > > > index 000000000000..4abfc30a97d0
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> > > > @@ -0,0 +1,56 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: "http://devicetree.org/schemas/phy/ti,tcan104x-can.yaml#";
> > > > +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> > > > +
> > > > +title: TCAN104x CAN TRANSCEIVER PHY
> > > > +
> > > > +maintainers:
> > > > +  - Aswath Govindraju <a-govindraju@xxxxxx>
> > > > +
> > > > +properties:
> > > > +  $nodename:
> > > > +    pattern: "^tcan104x-phy"
> > > > +
> > > > +  compatible:
> > > > +    enum:
> > > > +      - ti,tcan1042
> > > > +      - ti,tcan1043
> > >
> > > Can you create a generic standby only and a generic standby and enable transceiver?
> >
> > As a fallback compatible fine, but no generic binding please. A generic
> > binding can't describe any timing requirements between the 2 GPIO as
> > well as supplies when someone wants to add those (and they will).
>
> Right - that makes sense.
>
> > > > +
> > > > +  '#phy-cells':
> > > > +    const: 0
> > > > +
> > > > +  standby-gpios:
> > > > +    description:
> > > > +      gpio node to toggle standby signal on transceiver
> > > > +    maxItems: 1
> > > > +
> > > > +  enable-gpios:
> > > > +    description:
> > > > +      gpio node to toggle enable signal on transceiver
> > > > +    maxItems: 1
> > > > +
> > > > +  max-bitrate:
> > > > +    $ref: /schemas/types.yaml#/definitions/uint32
> > > > +    description:
> > > > +      max bit rate supported in bps
> >
> > We already have 'max-speed' for serial devices, use that.
>
> There is already the neither Ethernet PHY (PHYLINK/PHYLIB) nor generic
> PHY (GENERIC_PHY) can-transceiver binding
> Documentation/devicetree/bindings/net/can/can-transceiver.yaml which
> specifies max-bitrate. I don't have strong feelings whether to use
> max-bitrate or max-speed.

Okay, max-bitrate is fine.

>
> Speaking about Ethernet PHYs, what are to pros and cons to use the
> generic PHY compared to the Ethernet PHY infrastructure?

For higher speed ethernet, both are used. There's the serdes phy and
the ethernet phy with serdes phy using the generic phy binding. For
CAN, it probably comes down to what's a better fit.

Rob



[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux