| Message ID | 20210726194603.14671-3-gerhard@engleder-embedded.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | TSN endpoint Ethernet MAC driver | expand |
| Context | Check | Description |
|---|---|---|
| netdev/cover_letter | success | Link |
| netdev/fixes_present | success | Link |
| netdev/patch_count | success | Link |
| netdev/tree_selection | success | Clearly marked for net-next |
| netdev/subject_prefix | success | Link |
| netdev/cc_maintainers | success | CCed 6 of 6 maintainers |
| netdev/source_inline | success | Was 0 now: 0 |
| netdev/verify_signedoff | success | Link |
| netdev/module_param | success | Was 0 now: 0 |
| netdev/build_32bit | success | Errors and warnings before: 0 this patch: 0 |
| netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| netdev/verify_fixes | success | Link |
| netdev/checkpatch | warning | WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? |
| netdev/build_allmodconfig_warn | success | Errors and warnings before: 0 this patch: 0 |
| netdev/header_inline | success | Link |
On Mon, Jul 26, 2021 at 1:46 PM Gerhard Engleder <gerhard@engleder-embedded.com> wrote: > > The TSN endpoint Ethernet MAC is a FPGA based network device for > real-time communication. > > It is integrated as normal Ethernet controller with > ethernet-controller.yaml and ethernet-phy.yaml. > > Signed-off-by: Gerhard Engleder <gerhard@engleder-embedded.com> > --- > .../bindings/net/engleder,tsnep.yaml | 77 +++++++++++++++++++ > 1 file changed, 77 insertions(+) > create mode 100644 Documentation/devicetree/bindings/net/engleder,tsnep.yaml > > diff --git a/Documentation/devicetree/bindings/net/engleder,tsnep.yaml b/Documentation/devicetree/bindings/net/engleder,tsnep.yaml > new file mode 100644 > index 000000000000..ef2ca45d36a0 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/engleder,tsnep.yaml > @@ -0,0 +1,77 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/net/engleder,tsnep.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: TSN endpoint Ethernet MAC binding > + > +maintainers: > + - Gerhard Engleder <gerhard@engleder-embedded.com> > + > +allOf: > + - $ref: ethernet-controller.yaml# > + > +properties: > + compatible: > + oneOf: Don't need oneOf when there is only one entry. > + - enum: > + - engleder,tsnep tsnep is pretty generic. Only 1 version ever? Or differences are/will be discoverable by other means. > + > + reg: true How many? And what is each entry if more than 1. > + interrupts: true How many? > + > + local-mac-address: true > + mac-address: true > + nvmem-cells: true How many? > + nvmem-cells-names: true Need to define the names. > + > + phy-connection-type: true > + phy-mode: true All the modes the generic binding support are supported by this device? > + > + phy-handle: true > + > + '#address-cells': > + description: Number of address cells for the MDIO bus. No need to re-describe common properties unless you have something special to say. Anyway, put an MDIO bus under an 'mdio' node. > + const: 1 > + > + '#size-cells': > + description: Number of size cells on the MDIO bus. > + const: 0 > + > +patternProperties: > + "^ethernet-phy@[0-9a-f]$": > + type: object > + $ref: ethernet-phy.yaml# Referencing mdio.yaml will do all this. > + > +required: > + - compatible > + - reg > + - interrupts > + - phy-mode > + - phy-handle > + - '#address-cells' > + - '#size-cells' > + > +additionalProperties: false > + > +examples: > + - | > + axi { > + #address-cells = <2>; > + #size-cells = <2>; > + tnsep0: ethernet@a0000000 { > + compatible = "engleder,tsnep"; > + reg = <0x0 0xa0000000 0x0 0x10000>; > + interrupts = <0 89 1>; > + interrupt-parent = <&gic>; > + local-mac-address = [00 00 00 00 00 00]; > + phy-mode = "rgmii"; > + phy-handle = <&phy0>; > + #address-cells = <1>; > + #size-cells = <0>; > + phy0: ethernet-phy@1 { > + reg = <1>; > + }; > + }; > + }; > -- > 2.20.1 >
On Tue, Jul 27, 2021 at 1:35 AM Rob Herring <robh+dt@kernel.org> wrote: > > +properties: > > + compatible: > > + oneOf: > > Don't need oneOf when there is only one entry. I will fix that. > > + - enum: > > + - engleder,tsnep > > tsnep is pretty generic. Only 1 version ever? Or differences are/will > be discoverable by other means. Differences shall be detected by flags in the registers; e.g., a flag for gate control support. Anyway a version may make sense. Can you point to a good reference binding with versions? I did not find a network controller binding with versions. > > + reg: true > > How many? And what is each entry if more than 1. Only one. I will fix that. > > + interrupts: true > > How many? Only one. I will fix that. > > + > > + local-mac-address: true > > + mac-address: true > > + nvmem-cells: true > > How many? Is that not inherited from ethernet-controller.yaml? nvmem-cells: maxItems: 1 > > + nvmem-cells-names: true > > Need to define the names. Is that not inherited from ethernet-controller.yaml? nvmem-cell-names: const: mac-address > > + phy-connection-type: true > > + phy-mode: true > > All the modes the generic binding support are supported by this device? Only GMII and RGMII are supported. I will fix that. > > + phy-handle: true > > + > > + '#address-cells': > > + description: Number of address cells for the MDIO bus. > > No need to re-describe common properties unless you have something > special to say. > > Anyway, put an MDIO bus under an 'mdio' node. > > > + const: 1 > > + > > + '#size-cells': > > + description: Number of size cells on the MDIO bus. > > + const: 0 > > + > > +patternProperties: > > + "^ethernet-phy@[0-9a-f]$": > > + type: object > > + $ref: ethernet-phy.yaml# > > Referencing mdio.yaml will do all this. I will reference mdio.yaml.
On Tue, Jul 27, 2021 at 12:35 PM Gerhard Engleder <gerhard@engleder-embedded.com> wrote: > > On Tue, Jul 27, 2021 at 1:35 AM Rob Herring <robh+dt@kernel.org> wrote: > > > +properties: > > > + compatible: > > > + oneOf: > > > > Don't need oneOf when there is only one entry. > > I will fix that. > > > > + - enum: > > > + - engleder,tsnep > > > > tsnep is pretty generic. Only 1 version ever? Or differences are/will > > be discoverable by other means. > > Differences shall be detected by flags in the registers; e.g., a flag for > gate control support. Anyway a version may make sense. Can you > point to a good reference binding with versions? I did not find a > network controller binding with versions. Some of the SiFive IP blocks have versions. Version numbers are the exception though. Ideally they would correspond to some version of your FPGA image. I just don't want to see 'v1' because that sounds made up. The above string can mean 'v1' or whatever version you want. I'm fine if you just add some description here about feature flag registers. > > > > + reg: true > > > > How many? And what is each entry if more than 1. > > Only one. I will fix that. > > > > + interrupts: true > > > > How many? > > Only one. I will fix that. > > > > + > > > + local-mac-address: true > > > + mac-address: true > > > + nvmem-cells: true > > > > How many? > > Is that not inherited from ethernet-controller.yaml? > nvmem-cells: > maxItems: 1 Ah, right. > > > + nvmem-cells-names: true > > > > Need to define the names. > > Is that not inherited from ethernet-controller.yaml? > nvmem-cell-names: > const: mac-address Yes. Rob
On Tue, Jul 27, 2021 at 10:25 PM Rob Herring <robh+dt@kernel.org> wrote: > > > tsnep is pretty generic. Only 1 version ever? Or differences are/will > > > be discoverable by other means. > > > > Differences shall be detected by flags in the registers; e.g., a flag for > > gate control support. Anyway a version may make sense. Can you > > point to a good reference binding with versions? I did not find a > > network controller binding with versions. > > Some of the SiFive IP blocks have versions. Version numbers are the > exception though. Ideally they would correspond to some version of > your FPGA image. I just don't want to see 'v1' because that sounds > made up. The above string can mean 'v1' or whatever version you want. > I'm fine if you just add some description here about feature flag > registers. I will do that. Gerhard
On 7/27/21 10:25 PM, Rob Herring wrote: > On Tue, Jul 27, 2021 at 12:35 PM Gerhard Engleder > <gerhard@engleder-embedded.com> wrote: >> >> On Tue, Jul 27, 2021 at 1:35 AM Rob Herring <robh+dt@kernel.org> wrote: >>>> +properties: >>>> + compatible: >>>> + oneOf: >>> >>> Don't need oneOf when there is only one entry. >> >> I will fix that. >> >>>> + - enum: >>>> + - engleder,tsnep >>> >>> tsnep is pretty generic. Only 1 version ever? Or differences are/will >>> be discoverable by other means. >> >> Differences shall be detected by flags in the registers; e.g., a flag for >> gate control support. Anyway a version may make sense. Can you >> point to a good reference binding with versions? I did not find a >> network controller binding with versions. > > Some of the SiFive IP blocks have versions. Version numbers are the > exception though. Ideally they would correspond to some version of > your FPGA image. I just don't want to see 'v1' because that sounds > made up. The above string can mean 'v1' or whatever version you want. > I'm fine if you just add some description here about feature flag > registers. Don't Xilinx design tool (vivado) force you to use IP version? Normally all Xilinx IPs have certain version because that's the only way how to manage it. Thanks, Michal
On Wed, Jul 28, 2021 at 7:13 AM Michal Simek <michal.simek@xilinx.com> wrote: > On 7/27/21 10:25 PM, Rob Herring wrote: > > On Tue, Jul 27, 2021 at 12:35 PM Gerhard Engleder > > <gerhard@engleder-embedded.com> wrote: > >> > >> On Tue, Jul 27, 2021 at 1:35 AM Rob Herring <robh+dt@kernel.org> wrote: > >>>> +properties: > >>>> + compatible: > >>>> + oneOf: > >>> > >>> Don't need oneOf when there is only one entry. > >> > >> I will fix that. > >> > >>>> + - enum: > >>>> + - engleder,tsnep > >>> > >>> tsnep is pretty generic. Only 1 version ever? Or differences are/will > >>> be discoverable by other means. > >> > >> Differences shall be detected by flags in the registers; e.g., a flag for > >> gate control support. Anyway a version may make sense. Can you > >> point to a good reference binding with versions? I did not find a > >> network controller binding with versions. > > > > Some of the SiFive IP blocks have versions. Version numbers are the > > exception though. Ideally they would correspond to some version of > > your FPGA image. I just don't want to see 'v1' because that sounds > > made up. The above string can mean 'v1' or whatever version you want. > > I'm fine if you just add some description here about feature flag > > registers. > > Don't Xilinx design tool (vivado) force you to use IP version? > Normally all Xilinx IPs have certain version because that's the only way > how to manage it. Yes I use an IP version in the Xilinx design tool. I use it as a version of the VHDL code itself. In my case this version is not related to the hardware software interface. The goal is to keep the hardware software interface compatible, so the IP version should not be relevant. Gerhard
On 7/28/21 9:44 AM, Gerhard Engleder wrote: > On Wed, Jul 28, 2021 at 7:13 AM Michal Simek <michal.simek@xilinx.com> wrote: >> On 7/27/21 10:25 PM, Rob Herring wrote: >>> On Tue, Jul 27, 2021 at 12:35 PM Gerhard Engleder >>> <gerhard@engleder-embedded.com> wrote: >>>> >>>> On Tue, Jul 27, 2021 at 1:35 AM Rob Herring <robh+dt@kernel.org> wrote: >>>>>> +properties: >>>>>> + compatible: >>>>>> + oneOf: >>>>> >>>>> Don't need oneOf when there is only one entry. >>>> >>>> I will fix that. >>>> >>>>>> + - enum: >>>>>> + - engleder,tsnep >>>>> >>>>> tsnep is pretty generic. Only 1 version ever? Or differences are/will >>>>> be discoverable by other means. >>>> >>>> Differences shall be detected by flags in the registers; e.g., a flag for >>>> gate control support. Anyway a version may make sense. Can you >>>> point to a good reference binding with versions? I did not find a >>>> network controller binding with versions. >>> >>> Some of the SiFive IP blocks have versions. Version numbers are the >>> exception though. Ideally they would correspond to some version of >>> your FPGA image. I just don't want to see 'v1' because that sounds >>> made up. The above string can mean 'v1' or whatever version you want. >>> I'm fine if you just add some description here about feature flag >>> registers. >> >> Don't Xilinx design tool (vivado) force you to use IP version? >> Normally all Xilinx IPs have certain version because that's the only way >> how to manage it. > > Yes I use an IP version in the Xilinx design tool. I use it as a version of the > VHDL code itself. In my case this version is not related to the > hardware software > interface. The goal is to keep the hardware software interface compatible, so > the IP version should not be relevant. I expect this is goal for everybody but it fails over time. We normally compose compatible string for PL based IP with IP version which is used. And it is quite common that couple of HW version are SW compatible to each other. It means use the same HW version as you use now. When you reach the point when your HW IP needs to be upgraded and will require SW alignment you have versions around which can be used directly. Thanks, Michal
On Wed, Jul 28, 2021 at 12:55 PM Michal Simek <michal.simek@xilinx.com> wrote: > >>>>>> + - enum: > >>>>>> + - engleder,tsnep > >>>>> > >>>>> tsnep is pretty generic. Only 1 version ever? Or differences are/will > >>>>> be discoverable by other means. > >>>> > >>>> Differences shall be detected by flags in the registers; e.g., a flag for > >>>> gate control support. Anyway a version may make sense. Can you > >>>> point to a good reference binding with versions? I did not find a > >>>> network controller binding with versions. > >>> > >>> Some of the SiFive IP blocks have versions. Version numbers are the > >>> exception though. Ideally they would correspond to some version of > >>> your FPGA image. I just don't want to see 'v1' because that sounds > >>> made up. The above string can mean 'v1' or whatever version you want. > >>> I'm fine if you just add some description here about feature flag > >>> registers. > >> > >> Don't Xilinx design tool (vivado) force you to use IP version? > >> Normally all Xilinx IPs have certain version because that's the only way > >> how to manage it. > > > > Yes I use an IP version in the Xilinx design tool. I use it as a version of the > > VHDL code itself. In my case this version is not related to the > > hardware software > > interface. The goal is to keep the hardware software interface compatible, so > > the IP version should not be relevant. > > I expect this is goal for everybody but it fails over time. We normally > compose compatible string for PL based IP with IP version which is used. > And it is quite common that couple of HW version are SW compatible to > each other. > It means use the same HW version as you use now. When you reach the > point when your HW IP needs to be upgraded and will require SW alignment > you have versions around which can be used directly. I would like to follow the argument from Rob: "The above string can mean 'v1' or whatever version you want." If there ever is an incompatible new IP version, then a new compatible string can be added which means 'v2'. E.g. for 128bit physical address support I would choose the compatible string 'engleder,tsnep128'. I don't see an advantage in adding a version number to the compatible string. This IP will be used in products where compatible hardware is a must. An IP upgrade which requires SW alignment will result in heavy complaints from the customers. Such an IP upgrade would result in a new IP. Like for shared libraries, an incompatible API change is similar to a new library. Gerhard
On 7/28/21 10:14 PM, Gerhard Engleder wrote: > On Wed, Jul 28, 2021 at 12:55 PM Michal Simek <michal.simek@xilinx.com> wrote: >>>>>>>> + - enum: >>>>>>>> + - engleder,tsnep >>>>>>> >>>>>>> tsnep is pretty generic. Only 1 version ever? Or differences are/will >>>>>>> be discoverable by other means. >>>>>> >>>>>> Differences shall be detected by flags in the registers; e.g., a flag for >>>>>> gate control support. Anyway a version may make sense. Can you >>>>>> point to a good reference binding with versions? I did not find a >>>>>> network controller binding with versions. >>>>> >>>>> Some of the SiFive IP blocks have versions. Version numbers are the >>>>> exception though. Ideally they would correspond to some version of >>>>> your FPGA image. I just don't want to see 'v1' because that sounds >>>>> made up. The above string can mean 'v1' or whatever version you want. >>>>> I'm fine if you just add some description here about feature flag >>>>> registers. >>>> >>>> Don't Xilinx design tool (vivado) force you to use IP version? >>>> Normally all Xilinx IPs have certain version because that's the only way >>>> how to manage it. >>> >>> Yes I use an IP version in the Xilinx design tool. I use it as a version of the >>> VHDL code itself. In my case this version is not related to the >>> hardware software >>> interface. The goal is to keep the hardware software interface compatible, so >>> the IP version should not be relevant. >> >> I expect this is goal for everybody but it fails over time. We normally >> compose compatible string for PL based IP with IP version which is used. >> And it is quite common that couple of HW version are SW compatible to >> each other. >> It means use the same HW version as you use now. When you reach the >> point when your HW IP needs to be upgraded and will require SW alignment >> you have versions around which can be used directly. > > I would like to follow the argument from Rob: > "The above string can mean 'v1' or whatever version you want." > If there ever is an incompatible new IP version, then a new compatible string > can be added which means 'v2'. E.g. for 128bit physical address support I > would choose the compatible string 'engleder,tsnep128'. I don't see an > advantage in adding a version number to the compatible string. > > This IP will be used in products where compatible hardware is a must. > An IP upgrade which requires SW alignment will result in heavy complaints > from the customers. Such an IP upgrade would result in a new IP. > Like for shared libraries, an incompatible API change is similar to a new > library. From my point of view where I expect the most of customers are using Xilinx DTG (device tree generator) compatible string is composed with IP name and version used in design tool. This is unique combination which properly describes your HW. And choosing different compatible string or string without version is breaking this connection between hw design tool and sw. From my perspective it is much simpler to understand that your HW ip called ABC-rev1 requires DT node which is your_company,ABC-rev1 instead of any made name. But up2you - you will be talking to your customers. Thanks, Michal
On Thu, Jul 29, 2021 at 7:07 AM Michal Simek <michal.simek@xilinx.com> wrote: > On 7/28/21 10:14 PM, Gerhard Engleder wrote: > > On Wed, Jul 28, 2021 at 12:55 PM Michal Simek <michal.simek@xilinx.com> wrote: > >>>>>>>> + - enum: > >>>>>>>> + - engleder,tsnep > >>>>>>> > >>>>>>> tsnep is pretty generic. Only 1 version ever? Or differences are/will > >>>>>>> be discoverable by other means. > >>>>>> > >>>>>> Differences shall be detected by flags in the registers; e.g., a flag for > >>>>>> gate control support. Anyway a version may make sense. Can you > >>>>>> point to a good reference binding with versions? I did not find a > >>>>>> network controller binding with versions. > >>>>> > >>>>> Some of the SiFive IP blocks have versions. Version numbers are the > >>>>> exception though. Ideally they would correspond to some version of > >>>>> your FPGA image. I just don't want to see 'v1' because that sounds > >>>>> made up. The above string can mean 'v1' or whatever version you want. > >>>>> I'm fine if you just add some description here about feature flag > >>>>> registers. > >>>> > >>>> Don't Xilinx design tool (vivado) force you to use IP version? > >>>> Normally all Xilinx IPs have certain version because that's the only way > >>>> how to manage it. > >>> > >>> Yes I use an IP version in the Xilinx design tool. I use it as a version of the > >>> VHDL code itself. In my case this version is not related to the > >>> hardware software > >>> interface. The goal is to keep the hardware software interface compatible, so > >>> the IP version should not be relevant. > >> > >> I expect this is goal for everybody but it fails over time. We normally > >> compose compatible string for PL based IP with IP version which is used. > >> And it is quite common that couple of HW version are SW compatible to > >> each other. > >> It means use the same HW version as you use now. When you reach the > >> point when your HW IP needs to be upgraded and will require SW alignment > >> you have versions around which can be used directly. > > > > I would like to follow the argument from Rob: > > "The above string can mean 'v1' or whatever version you want." > > If there ever is an incompatible new IP version, then a new compatible string > > can be added which means 'v2'. E.g. for 128bit physical address support I > > would choose the compatible string 'engleder,tsnep128'. I don't see an > > advantage in adding a version number to the compatible string. > > > > This IP will be used in products where compatible hardware is a must. > > An IP upgrade which requires SW alignment will result in heavy complaints > > from the customers. Such an IP upgrade would result in a new IP. > > Like for shared libraries, an incompatible API change is similar to a new > > library. > > From my point of view where I expect the most of customers are using > Xilinx DTG (device tree generator) compatible string is composed with IP > name and version used in design tool. This is unique combination which > properly describes your HW. > And choosing different compatible string or string without version is > breaking this connection between hw design tool and sw. > > From my perspective it is much simpler to understand that your HW ip > called ABC-rev1 requires DT node which is your_company,ABC-rev1 instead > of any made name. > But up2you - you will be talking to your customers. Thanks for explaining your point of view. From my side I don't expect that Xilinx DTG is used. The few people I know who are working with Zynq/ZynqMP are using the Xilinx tools only to generate the bitstream. This way you are able to do software development for the Zynq/ZynqMP like for any other hardware platform. Thanks for your Feedback! Gerhard
On 7/29/21 9:07 AM, Gerhard Engleder wrote: > On Thu, Jul 29, 2021 at 7:07 AM Michal Simek <michal.simek@xilinx.com> wrote: >> On 7/28/21 10:14 PM, Gerhard Engleder wrote: >>> On Wed, Jul 28, 2021 at 12:55 PM Michal Simek <michal.simek@xilinx.com> wrote: >>>>>>>>>> + - enum: >>>>>>>>>> + - engleder,tsnep >>>>>>>>> >>>>>>>>> tsnep is pretty generic. Only 1 version ever? Or differences are/will >>>>>>>>> be discoverable by other means. >>>>>>>> >>>>>>>> Differences shall be detected by flags in the registers; e.g., a flag for >>>>>>>> gate control support. Anyway a version may make sense. Can you >>>>>>>> point to a good reference binding with versions? I did not find a >>>>>>>> network controller binding with versions. >>>>>>> >>>>>>> Some of the SiFive IP blocks have versions. Version numbers are the >>>>>>> exception though. Ideally they would correspond to some version of >>>>>>> your FPGA image. I just don't want to see 'v1' because that sounds >>>>>>> made up. The above string can mean 'v1' or whatever version you want. >>>>>>> I'm fine if you just add some description here about feature flag >>>>>>> registers. >>>>>> >>>>>> Don't Xilinx design tool (vivado) force you to use IP version? >>>>>> Normally all Xilinx IPs have certain version because that's the only way >>>>>> how to manage it. >>>>> >>>>> Yes I use an IP version in the Xilinx design tool. I use it as a version of the >>>>> VHDL code itself. In my case this version is not related to the >>>>> hardware software >>>>> interface. The goal is to keep the hardware software interface compatible, so >>>>> the IP version should not be relevant. >>>> >>>> I expect this is goal for everybody but it fails over time. We normally >>>> compose compatible string for PL based IP with IP version which is used. >>>> And it is quite common that couple of HW version are SW compatible to >>>> each other. >>>> It means use the same HW version as you use now. When you reach the >>>> point when your HW IP needs to be upgraded and will require SW alignment >>>> you have versions around which can be used directly. >>> >>> I would like to follow the argument from Rob: >>> "The above string can mean 'v1' or whatever version you want." >>> If there ever is an incompatible new IP version, then a new compatible string >>> can be added which means 'v2'. E.g. for 128bit physical address support I >>> would choose the compatible string 'engleder,tsnep128'. I don't see an >>> advantage in adding a version number to the compatible string. >>> >>> This IP will be used in products where compatible hardware is a must. >>> An IP upgrade which requires SW alignment will result in heavy complaints >>> from the customers. Such an IP upgrade would result in a new IP. >>> Like for shared libraries, an incompatible API change is similar to a new >>> library. >> >> From my point of view where I expect the most of customers are using >> Xilinx DTG (device tree generator) compatible string is composed with IP >> name and version used in design tool. This is unique combination which >> properly describes your HW. >> And choosing different compatible string or string without version is >> breaking this connection between hw design tool and sw. >> >> From my perspective it is much simpler to understand that your HW ip >> called ABC-rev1 requires DT node which is your_company,ABC-rev1 instead >> of any made name. >> But up2you - you will be talking to your customers. > > Thanks for explaining your point of view. From my side I don't expect that > Xilinx DTG is used. The few people I know who are working with Zynq/ZynqMP > are using the Xilinx tools only to generate the bitstream. This way you are able > to do software development for the Zynq/ZynqMP like for any other hardware > platform. Definitely possible but when you have 20 soft IPs if you are not using DTG you have big issue to have proper IRQ ids, memory maps and make sense to use DTG to give you that initial description which you can tune by hand. But it is decent starting point. Maybe in your TSN case you are dealing just with small number of IPs that's this is easy to do by hand. Thanks, Michal
diff --git a/Documentation/devicetree/bindings/net/engleder,tsnep.yaml b/Documentation/devicetree/bindings/net/engleder,tsnep.yaml new file mode 100644 index 000000000000..ef2ca45d36a0 --- /dev/null +++ b/Documentation/devicetree/bindings/net/engleder,tsnep.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/engleder,tsnep.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TSN endpoint Ethernet MAC binding + +maintainers: + - Gerhard Engleder <gerhard@engleder-embedded.com> + +allOf: + - $ref: ethernet-controller.yaml# + +properties: + compatible: + oneOf: + - enum: + - engleder,tsnep + + reg: true + interrupts: true + + local-mac-address: true + mac-address: true + nvmem-cells: true + nvmem-cells-names: true + + phy-connection-type: true + phy-mode: true + + phy-handle: true + + '#address-cells': + description: Number of address cells for the MDIO bus. + const: 1 + + '#size-cells': + description: Number of size cells on the MDIO bus. + const: 0 + +patternProperties: + "^ethernet-phy@[0-9a-f]$": + type: object + $ref: ethernet-phy.yaml# + +required: + - compatible + - reg + - interrupts + - phy-mode + - phy-handle + - '#address-cells' + - '#size-cells' + +additionalProperties: false + +examples: + - | + axi { + #address-cells = <2>; + #size-cells = <2>; + tnsep0: ethernet@a0000000 { + compatible = "engleder,tsnep"; + reg = <0x0 0xa0000000 0x0 0x10000>; + interrupts = <0 89 1>; + interrupt-parent = <&gic>; + local-mac-address = [00 00 00 00 00 00]; + phy-mode = "rgmii"; + phy-handle = <&phy0>; + #address-cells = <1>; + #size-cells = <0>; + phy0: ethernet-phy@1 { + reg = <1>; + }; + }; + };
The TSN endpoint Ethernet MAC is a FPGA based network device for real-time communication. It is integrated as normal Ethernet controller with ethernet-controller.yaml and ethernet-phy.yaml. Signed-off-by: Gerhard Engleder <gerhard@engleder-embedded.com> --- .../bindings/net/engleder,tsnep.yaml | 77 +++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/engleder,tsnep.yaml