mbox series

[0/2] Add device tree binding support to TI's DP83640

Message ID 20240130085935.33722-1-bastien.curutchet@bootlin.com
Headers show
Series Add device tree binding support to TI's DP83640 | expand

Message

Bastien Curutchet Jan. 30, 2024, 8:59 a.m. UTC 
Hi everyone,

This short patch series adds a device-tree binding support to the TI's PHY
DP83640. The goal is to be able to enable or disable the following features
through the device tree:
   - Energy Detect Mode
   - PHY Control Frames
   - LED Configuration
   - Fiber Mode

Bastien Curutchet (2):
  dt-bindings: net: Add TI DP83640
  net: phy: Add some configuration from device-tree

 .../devicetree/bindings/net/ti,dp83640.yaml   | 113 +++++++++++++++
 drivers/net/phy/dp83640.c                     | 131 +++++++++++++++++-
 drivers/net/phy/dp83640_reg.h                 |  21 ++-
 include/dt-bindings/net/ti-dp83640.h          |  18 +++
 4 files changed, 281 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/ti,dp83640.yaml
 create mode 100644 include/dt-bindings/net/ti-dp83640.h

Comments

Rob Herring Jan. 31, 2024, 9:05 p.m. UTC | #1 
On Tue, Jan 30, 2024 at 05:56:37PM +0000, Conor Dooley wrote:
> Hey,
> 
> On Tue, Jan 30, 2024 at 09:59:34AM +0100, Bastien Curutchet wrote:
> > +description: |
> > +  The DP83640 Precision PHYTER device delivers the highest level of precision
> 
> This is not a marketing document.
> 
> > +  clock synchronization for real time industrial connectivity based on the
> > +  IEEE 1588 standard. The DP83640 has deterministic, low latency and allows
> > +  choice of microcontroller with no hardware customization required
> > +
> > +  This device interfaces directly to the MAC layer through the
> > +  IEEE 802.3 Standard Media Independent Interface (MII), or Reduced MII (RMII).
> > +
> > +  Specifications about the Ethernet PHY can be found at:
> > +    https://www.ti.com/lit/gpn/dp83640
> > +
> > +properties:
> > +  reg:
> > +    maxItems: 1
> > +
> > +  ti,clk-output:
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    enum: [0, 1]
> > +    description: |
> > +      If present, enables or disables the CLK_OUT pin.
> > +      CLK_OUT pin disabling can also be strapped. If the strap pin is not set
> > +      correctly or not set at all then this can be used to configure it.
> > +       - 0     = CLK_OUT pin disabled
> > +       - 1     = CLK_OUT pin enabled
> > +       - unset = Configured by straps
> 
> If you are providing a clock, why is there no clock-controller property
> here? I don't think the 3-way nature of this property is needed, if you
> make this a "real" clock controller.
> 
> > +  ti,fiber-mode:
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    enum: [0, 1]
> > +    description: |
> > +      If present, enables or disables the FX Fiber Mode.
> > +      Fiber mode support can also be strapped. If the strap pin is not set
> > +      correctly or not set at all then this can be used to configure it.
> > +       - 0     = FX Fiber Mode disabled
> > +       - 1     = FX Fiber Mode enabled
> > +       - unset = Configured by straps
> 
> I don't like these properties that map meanings onto numbers. We can
> have enums of strings in bindings that allow you to use something more
> meaningful than "0" or "1".

Tristate properties are fairly common pattern where we need 
on/off/default. I've thought about making it a type. I don't think we 
need defines for it.

Rob