>-----Original Message-----
>From: Rob Herring <robh@xxxxxxxxxx>
>Sent: Saturday, February 23, 2019 1:38 AM
>To: Claudiu Manoil <claudiu.manoil@xxxxxxx>
>Cc: Shawn Guo <shawnguo@xxxxxxxxxx>; Leo Li <leoyang.li@xxxxxxx>; David S .
>Miller <davem@xxxxxxxxxxxxx>; Alexandru Marginean
><alexandru.marginean@xxxxxxx>; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx;
>devicetree@xxxxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; linux-
>kernel@xxxxxxxxxxxxxxx
>Subject: Re: [PATCH net-next v3 4/4] dt-bindings: net: freescale: enetc: Add
>connection bindings for ENETC ethernet nodes
>
>On Fri, Feb 22, 2019 at 05:04:19PM +0200, Claudiu Manoil wrote:
>> Define connection bindings (external PHY connections and internal
>> links) for the ENETC on-chip ethernet controllers.
>>
>> Signed-off-by: Claudiu Manoil <claudiu.manoil@xxxxxxx>
>> ---
>> v3 - added this patch to the set
>>
>> .../devicetree/bindings/net/fsl-enetc.txt | 109 +++++++++++++++++++++
>> 1 file changed, 109 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/net/fsl-enetc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/fsl-enetc.txt
>> b/Documentation/devicetree/bindings/net/fsl-enetc.txt
>> new file mode 100644
>> index 0000000..2fbb998
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/fsl-enetc.txt
>> @@ -0,0 +1,109 @@
>> +* ENETC ethernet nodes - external connection bindings
>> +
>> +The ENETC ethernet controllers are PCIe integrated endpoints (IEPs),
>> +on-chip devices discoverable as standard PCIe endpoints, integrated
>> +into Freescale SoCs. The ENETC devices are self contained, the
>> +information needed for device initialization is available in hardware
>> +(PCIe ECAM area). However, depending on board design, their external
>> +connections are configurable.
>> +As usual for SoCs, device tree nodes may be used to define these
>> +external connections. The rest of the document specifies how
>> +external connections for ENETC ethernet controllers may be defined
>> +via device tree nodes.
>> +
>> +Silicon (SoC) availability (<SoC name>: <SoC DT path/name>)
>> + - LS1028A: [arch/arm64] [...]freescale/fsl-ls1028a.dtsi
>
>This doesn't belong in bindings.
>
>> +
>> +
>> +* ENETC nodes
>> +
>> +Defined in the SoC device tree as "pci" child nodes of the
>> +"pci-host-ecam-generic" compatible "pcie" parent node also known as
>> +the Integrated Endpoint Root Complex (IERC) SoC node.
>
>The host controller attachment is also outside the scope of this binding.
>
>> +
>> +Structure - example (LS1028A):
>> +
>> + pcie@1f0000000 {
>> + compatible = "pci-host-ecam-generic";
>> + device_type = "pci";
>> + ...
>> + enetc_port0: pci@0,0 {
>
>The node name 'pci' is reserved for bridges. This should match the device class if
>possible (ethernet).
>
>> + reg = <0x000000 0 0 0 0>;
>> + };
>> + enetc_port1: pci@0,1 {
>> + reg = <0x000100 0 0 0 0>;
>> + };
>> + ...
>> + }
>> +
>> +Each ENETC node has a device number and a function number (expressed
>> +by its "reg" property and pci node name, i.e. "pci@0,1" represents
>> +device number 0 and functions number 1). Only the standard pci "reg"
>> +property is needed here.
>
>There should be a compatible too.
[...]
Ok to simplifying the text and document strictly the enetc device nodes as
"ethernet" nodes, like "ethernet@<dev_no>,<fcn_no>" (i.e ethernet@0,1).
But what would be the compatible string needed for?
The ethernet device driver doesn't need it, probing is done by the pci system.
Is it ok to use a generic name for the compatible string, like, "fsl,enetc", just
to indicate that the relevant driver is located at ethernet/freescale/enetc/
dir in the source code? (under drivers/net, of course)
Thanks.
Claudiu
