| Message ID | ef1d220cf792c74ae278e0200ca4763f9ab62d3e.1508938927.git.joabreu@synopsys.com |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | net: stmmac: Support DWMAC5 and TSN | expand |
On 10/25/2017 07:04 AM, Jose Abreu wrote: > This adds the documentation for TSN feature EST and FP. > > Signed-off-by: Jose Abreu <joabreu@synopsys.com> > Cc: David S. Miller <davem@davemloft.net> > Cc: Joao Pinto <jpinto@synopsys.com> > Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> > Cc: Alexandre Torgue <alexandre.torgue@st.com> > Cc: Rob Herring <robh+dt@kernel.org> > --- > Documentation/devicetree/bindings/net/stmmac.txt | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt > index c3a7be6..6359df6 100644 > --- a/Documentation/devicetree/bindings/net/stmmac.txt > +++ b/Documentation/devicetree/bindings/net/stmmac.txt > @@ -114,6 +114,16 @@ Optional properties: > - snps,high_credit: max write outstanding req. limit > - snps,low_credit: max read outstanding req. limit > - snps,priority: TX queue priority (Range: 0x0 to 0xF) > +- TSN parameters: below the list of all the parameters to configure TSN > + features (only applicable for IP version >= 5.00) > + - snps,est: Enable EST algorithm > + - If EST enabled provide these parameters: > + - snps,btr: Array size of 2 with BTR value for EST algorithm > + - snps,ctr: Array size of 2 with CTR value for EST algorithm > + - snps,ter: TER value for EST algorithm > + - snps,gcl: Variable size array with GCL table entries. > + - snps,fp: Enable FP feature. This needs EST enabled. You are using Device Tree as a configuration interface, that does not sound right at all. > + > Examples: > > stmmac_axi_setup: stmmac-axi-config { > @@ -151,6 +161,15 @@ Examples: > }; > }; > > + tsn_setup: tsn-config { > + snps,est; > + snps,btr = <0x00000000 0x00000001>; > + snps,ctr = <0x00000000 0x10000000>; > + snps,ter = <0x00000000>; > + snps,gcl = <0x00000001 0x00000002 0x00000003>; > + snps,fp; > + }; > + > gmac0: ethernet@e0800000 { > compatible = "st,spear600-gmac"; > reg = <0xe0800000 0x8000>; > @@ -176,4 +195,5 @@ Examples: > }; > snps,mtl-rx-config = <&mtl_rx_setup>; > snps,mtl-tx-config = <&mtl_tx_setup>; > + snps,tsn-config = <&tsn_setup>; Yes, this is definitively using Device Tree as a configuration interface, don't do that please.
Hi Florian, On 25-10-2017 20:34, Florian Fainelli wrote: > On 10/25/2017 07:04 AM, Jose Abreu wrote: >> This adds the documentation for TSN feature EST and FP. >> >> Signed-off-by: Jose Abreu <joabreu@synopsys.com> >> Cc: David S. Miller <davem@davemloft.net> >> Cc: Joao Pinto <jpinto@synopsys.com> >> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> >> Cc: Alexandre Torgue <alexandre.torgue@st.com> >> Cc: Rob Herring <robh+dt@kernel.org> >> --- >> Documentation/devicetree/bindings/net/stmmac.txt | 20 ++++++++++++++++++++ >> 1 file changed, 20 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt >> index c3a7be6..6359df6 100644 >> --- a/Documentation/devicetree/bindings/net/stmmac.txt >> +++ b/Documentation/devicetree/bindings/net/stmmac.txt >> @@ -114,6 +114,16 @@ Optional properties: >> - snps,high_credit: max write outstanding req. limit >> - snps,low_credit: max read outstanding req. limit >> - snps,priority: TX queue priority (Range: 0x0 to 0xF) >> +- TSN parameters: below the list of all the parameters to configure TSN >> + features (only applicable for IP version >= 5.00) >> + - snps,est: Enable EST algorithm >> + - If EST enabled provide these parameters: >> + - snps,btr: Array size of 2 with BTR value for EST algorithm >> + - snps,ctr: Array size of 2 with CTR value for EST algorithm >> + - snps,ter: TER value for EST algorithm >> + - snps,gcl: Variable size array with GCL table entries. >> + - snps,fp: Enable FP feature. This needs EST enabled. > You are using Device Tree as a configuration interface, that does not > sound right at all. > >> + >> Examples: >> >> stmmac_axi_setup: stmmac-axi-config { >> @@ -151,6 +161,15 @@ Examples: >> }; >> }; >> >> + tsn_setup: tsn-config { >> + snps,est; >> + snps,btr = <0x00000000 0x00000001>; >> + snps,ctr = <0x00000000 0x10000000>; >> + snps,ter = <0x00000000>; >> + snps,gcl = <0x00000001 0x00000002 0x00000003>; >> + snps,fp; >> + }; >> + >> gmac0: ethernet@e0800000 { >> compatible = "st,spear600-gmac"; >> reg = <0xe0800000 0x8000>; >> @@ -176,4 +195,5 @@ Examples: >> }; >> snps,mtl-rx-config = <&mtl_rx_setup>; >> snps,mtl-tx-config = <&mtl_tx_setup>; >> + snps,tsn-config = <&tsn_setup>; > Yes, this is definitively using Device Tree as a configuration > interface, don't do that please. I understand your concern here and I know DT bindings should only describe the HW but note that this is already done in mtl-rx-config and mtl-tx-config. These parameters may also need to change in runtime depending on the scheduled traffic. Unfortunately, net subsystem does not yet support TSN so this will have to wait and for now we will use fixed parameters. Anyway, what do you suggest here instead? Platform data? Best regards, Jose Miguel Abreu -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> These parameters may also need to change in runtime depending on > the scheduled traffic. Unfortunately, net subsystem does not yet > support TSN so this will have to wait and for now we will use > fixed parameters. Hi Jose what you should do is help Linux get support for TSN. Please take part in this discussion: https://patchwork.ozlabs.org/cover/808504/ Test the RFC, make sure the concepts will work for your hardware. Make you hardware work with these RFC patches. Help drive TSN forward. Once the core TSN code lands, then you can post patches for your driver. Andrew -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Andrew, On 26-10-2017 10:03, Andrew Lunn wrote: >> These parameters may also need to change in runtime depending on >> the scheduled traffic. Unfortunately, net subsystem does not yet >> support TSN so this will have to wait and for now we will use >> fixed parameters. > Hi Jose > > what you should do is help Linux get support for TSN. Please take part > in this discussion: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_cover_808504_&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=8yzdm5iHyWm9cVsYIYUtQNul5WnLO4nLnIxb3WDu-WU&s=6UJ2YJm5jXq6vTWpNRwRzNEuukPboceO61DQgDIpSj0&e= Seems like I don't have this thread saved here. Can you please add me in the thread? Thanks and best regards, Jose Miguel Abreu > > Test the RFC, make sure the concepts will work for your hardware. Make > you hardware work with these RFC patches. Help drive TSN forward. Once > the core TSN code lands, then you can post patches for your driver. > > Andrew -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Andrew, On 26-10-2017 10:03, Andrew Lunn wrote: >> These parameters may also need to change in runtime depending on >> the scheduled traffic. Unfortunately, net subsystem does not yet >> support TSN so this will have to wait and for now we will use >> fixed parameters. > Hi Jose > > what you should do is help Linux get support for TSN. Please take part > in this discussion: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_cover_808504_&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=8yzdm5iHyWm9cVsYIYUtQNul5WnLO4nLnIxb3WDu-WU&s=6UJ2YJm5jXq6vTWpNRwRzNEuukPboceO61DQgDIpSj0&e= > > Test the RFC, make sure the concepts will work for your hardware. Make > you hardware work with these RFC patches. Help drive TSN forward. Once > the core TSN code lands, then you can post patches for your driver. After reading more carefully the RFC I noticed that for now it only supports CBS. CBS is already supported by stmmac since: "net: stmmac: configuration of CBS in case of a TX AVB queue" [1]. My main objective now is to add support for EST and FP features in stmmac. As I am a recent contributor to net subsytem I am afraid my expertise won't be of much value for now as far as the RFC goes. About my patches, what I think would be better now would be to drop the configuration by DT and integrate the remaining configuration, letting the EST parameters be populated by SoC specific wrappers. I will then integrate this with the RFC patches once they get in and I also intend to contribute with the discussion once a new version is sent. I need also to say that this was fully tested and its working as expected so, there is no real setback in integrating this now and it will save us time in the future because then we will only need to implement the callbacks. Best regards, Jose Miguel Abreu [1] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/drivers/net/ethernet/stmicro/stmmac?id=19d9187317979cf0c25f67017d2676149abc46b2 > > Andrew -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Jose, On 10/26/2017 03:08 AM, Jose Abreu wrote: > Hi Andrew, > > On 26-10-2017 10:03, Andrew Lunn wrote: >>> These parameters may also need to change in runtime depending on >>> the scheduled traffic. Unfortunately, net subsystem does not yet >>> support TSN so this will have to wait and for now we will use >>> fixed parameters. >> Hi Jose >> >> what you should do is help Linux get support for TSN. Please take part >> in this discussion: >> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_cover_808504_&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=8yzdm5iHyWm9cVsYIYUtQNul5WnLO4nLnIxb3WDu-WU&s=6UJ2YJm5jXq6vTWpNRwRzNEuukPboceO61DQgDIpSj0&e= >> >> Test the RFC, make sure the concepts will work for your hardware. Make >> you hardware work with these RFC patches. Help drive TSN forward. Once >> the core TSN code lands, then you can post patches for your driver. > > After reading more carefully the RFC I noticed that for now it > only supports CBS. CBS is already supported by stmmac since: > "net: stmmac: configuration of CBS in case of a TX AVB queue" > [1]. My main objective now is to add support for EST and FP > features in stmmac. > > As I am a recent contributor to net subsystem I am afraid my > expertise won't be of much value for now as far as the RFC goes. > Please note that our RFC covered more than CBS. We've only provided patches for the cbs qdisc so far, but we've shared ideas of another qdisc we've designed and prototyped for EST and FP: taprio. It was a quite extensive thread, so I recommend reading it all so you can have a better picture of how the ideas were received back then [1]. In addition to our RFC, there is also the related discussion about SO_TXTIME proposed by Richard Cochran [2], which I believe might also be of interest to you. > > About my patches, what I think would be better now would be to > drop the configuration by DT and integrate the remaining > configuration, letting the EST parameters be populated by SoC > specific wrappers. I will then integrate this with the RFC > patches once they get in and I also intend to contribute with the > discussion once a new version is sent. The CBS qdisc patchset is ready to be merged, and based on previous feedback should go in anytime now. > > I need also to say that this was fully tested and its working as > expected so, there is no real setback in integrating this now and > it will save us time in the future because then we will only need > to implement the callbacks. Which is great, sure. I believe the point others are making here is just that there have been some discussions recently that you should take part of. The goal is getting the *standard* interfaces into the kernel so we can then provide device driver implementations through them. Thanks, Jesus [1] https://www.mail-archive.com/netdev@vger.kernel.org/msg186431.html [2] https://www.mail-archive.com/netdev@vger.kernel.org/msg188385.html > > Best regards, > Jose Miguel Abreu > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/drivers/net/ethernet/stmicro/stmmac?id=19d9187317979cf0c25f67017d2676149abc46b2 > >> >> Andrew > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> About my patches, what I think would be better now would be to > drop the configuration by DT and integrate the remaining > configuration, letting the EST parameters be populated by SoC > specific wrappers. Hi Jose The problem with SoC specific wrappers is that you are going to have to remove them once the real interface is defined. Anybody who uses your SoC specific wrappers is going to have to re-write their code, when it all gets ripped out. You generally don't add device SoC specific wrappers. Imagine if everybody did that. Lots of different ways of doing the same thing. My suggesting is to keep your patches out for the moment, waiting for generic support to be added. Andrew -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Jesus, On 26-10-2017 17:23, Jesus Sanchez-Palencia wrote: > Hi Jose, > > > On 10/26/2017 03:08 AM, Jose Abreu wrote: >> Hi Andrew, >> >> On 26-10-2017 10:03, Andrew Lunn wrote: >>>> These parameters may also need to change in runtime depending on >>>> the scheduled traffic. Unfortunately, net subsystem does not yet >>>> support TSN so this will have to wait and for now we will use >>>> fixed parameters. >>> Hi Jose >>> >>> what you should do is help Linux get support for TSN. Please take part >>> in this discussion: >>> >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_cover_808504_&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=8yzdm5iHyWm9cVsYIYUtQNul5WnLO4nLnIxb3WDu-WU&s=6UJ2YJm5jXq6vTWpNRwRzNEuukPboceO61DQgDIpSj0&e= >>> >>> Test the RFC, make sure the concepts will work for your hardware. Make >>> you hardware work with these RFC patches. Help drive TSN forward. Once >>> the core TSN code lands, then you can post patches for your driver. >> After reading more carefully the RFC I noticed that for now it >> only supports CBS. CBS is already supported by stmmac since: >> "net: stmmac: configuration of CBS in case of a TX AVB queue" >> [1]. My main objective now is to add support for EST and FP >> features in stmmac. >> >> As I am a recent contributor to net subsystem I am afraid my >> expertise won't be of much value for now as far as the RFC goes. >> > > Please note that our RFC covered more than CBS. We've only provided > patches for the cbs qdisc so far, but we've shared ideas of another > qdisc we've designed and prototyped for EST and FP: taprio. It was a > quite extensive thread, so I recommend reading it all so you can have > a better picture of how the ideas were received back then [1]. > > In addition to our RFC, there is also the related discussion about > SO_TXTIME proposed by Richard Cochran [2], which I believe might > also be of interest to you. Thanks for this info! I guess I have a lot to read this weekend :) > > >> About my patches, what I think would be better now would be to >> drop the configuration by DT and integrate the remaining >> configuration, letting the EST parameters be populated by SoC >> specific wrappers. I will then integrate this with the RFC >> patches once they get in and I also intend to contribute with the >> discussion once a new version is sent. > > The CBS qdisc patchset is ready to be merged, and based on previous > feedback should go in anytime now. Nice! I will start studying the integration of this in stmmac. > > >> I need also to say that this was fully tested and its working as >> expected so, there is no real setback in integrating this now and >> it will save us time in the future because then we will only need >> to implement the callbacks. > > Which is great, sure. I believe the point others are making here is > just that there have been some discussions recently that you should > take part of. The goal is getting the *standard* interfaces into > the kernel so we can then provide device driver implementations > through them. And we are all in favor about making this a standard interface. I was just mentioning that my expertise in the net subsystem is very low but I will review the threads. If you could add me in cc for the relevant threads it would be nice because I don't have them saved here. Thanks and Best Regards, Jose Miguel Abreu > > Thanks, > Jesus > > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mail-2Darchive.com_netdev-40vger.kernel.org_msg186431.html&d=DwIC-g&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=9feTUzfFG49lrNpaBinz8J4S1cKj1qEZur1JlzfQdWU&s=zjR6UPefwbqwHVbaTrepj_ZQnxBMGKDlTq4obkLlfkk&e= > [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mail-2Darchive.com_netdev-40vger.kernel.org_msg188385.html&d=DwIC-g&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=9feTUzfFG49lrNpaBinz8J4S1cKj1qEZur1JlzfQdWU&s=6aZXBf8OndxVnh1cl3UvvfDqWp1Xa6ql_cCVB3xAQa8&e= > > >> Best regards, >> Jose Miguel Abreu >> >> [1] >> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_davem_net-2Dnext.git_commit_drivers_net_ethernet_stmicro_stmmac-3Fid-3D19d9187317979cf0c25f67017d2676149abc46b2&d=DwIC-g&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=9feTUzfFG49lrNpaBinz8J4S1cKj1qEZur1JlzfQdWU&s=kN0fG9BlqONAd9z6vji-mnCxaVpJ-oX-Bv4c6DXNhaQ&e= >> >>> Andrew -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Andrew, On 26-10-2017 22:56, Andrew Lunn wrote: >> About my patches, what I think would be better now would be to >> drop the configuration by DT and integrate the remaining >> configuration, letting the EST parameters be populated by SoC >> specific wrappers. > Hi Jose > > The problem with SoC specific wrappers is that you are going to have > to remove them once the real interface is defined. Anybody who uses > your SoC specific wrappers is going to have to re-write their code, > when it all gets ripped out. Yeah, I agree. But what about just merge the implementation and then construct the interface? I mean just creating the internal parameters in stmmac and then the configuration functions. > > You generally don't add device SoC specific wrappers. Imagine if > everybody did that. Lots of different ways of doing the same thing. > My suggesting is to keep your patches out for the moment, waiting for > generic support to be added. I think we should take advantage of the fact that this is working and ready to be merged. Its just HW configuration but maybe it can serve as momentum for other drivers to also integrate this? Best Regards, Jose Miguel Abreu > > Andrew -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello On 10/27/2017 11:05 AM, Jose Abreu wrote: > I think we should take advantage of the fact that this is working > and ready to be merged. Its just HW configuration but maybe it > can serve as momentum for other drivers to also integrate this? Let me propose to have it now in the next-next. This support is for dwmac 5.x so no disturb for the common driver APIs and there is no risk to have regressions, IMO. IIUC, you already tested it on a real environment that sounds to be very good progress. Regards Peppe > Best Regards, > Jose Miguel Abreu -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Peppe, On 27-10-2017 13:29, Giuseppe CAVALLARO wrote: > Hello > > On 10/27/2017 11:05 AM, Jose Abreu wrote: >> I think we should take advantage of the fact that this is working >> and ready to be merged. Its just HW configuration but maybe it >> can serve as momentum for other drivers to also integrate this? > > Let me propose to have it now in the next-next. > > This support is for dwmac 5.x so no disturb for the common > driver APIs and there is no risk to have regressions, IMO. > > IIUC, you already tested it on a real environment that > sounds to be very good progress. Ok, I will drop this documentation patch and the DT parsing and send a new version. Best Regards, Jose Miguel Abreu > > Regards > Peppe > >> Best Regards, >> Jose Miguel Abreu > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 27, 2017 at 02:50:05PM +0100, Jose Abreu wrote: > Ok, I will drop this documentation patch and the DT parsing and > send a new version. Please put me and the other interested parties (see the TSN threads on LKML) onto CC. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt index c3a7be6..6359df6 100644 --- a/Documentation/devicetree/bindings/net/stmmac.txt +++ b/Documentation/devicetree/bindings/net/stmmac.txt @@ -114,6 +114,16 @@ Optional properties: - snps,high_credit: max write outstanding req. limit - snps,low_credit: max read outstanding req. limit - snps,priority: TX queue priority (Range: 0x0 to 0xF) +- TSN parameters: below the list of all the parameters to configure TSN + features (only applicable for IP version >= 5.00) + - snps,est: Enable EST algorithm + - If EST enabled provide these parameters: + - snps,btr: Array size of 2 with BTR value for EST algorithm + - snps,ctr: Array size of 2 with CTR value for EST algorithm + - snps,ter: TER value for EST algorithm + - snps,gcl: Variable size array with GCL table entries. + - snps,fp: Enable FP feature. This needs EST enabled. + Examples: stmmac_axi_setup: stmmac-axi-config { @@ -151,6 +161,15 @@ Examples: }; }; + tsn_setup: tsn-config { + snps,est; + snps,btr = <0x00000000 0x00000001>; + snps,ctr = <0x00000000 0x10000000>; + snps,ter = <0x00000000>; + snps,gcl = <0x00000001 0x00000002 0x00000003>; + snps,fp; + }; + gmac0: ethernet@e0800000 { compatible = "st,spear600-gmac"; reg = <0xe0800000 0x8000>; @@ -176,4 +195,5 @@ Examples: }; snps,mtl-rx-config = <&mtl_rx_setup>; snps,mtl-tx-config = <&mtl_tx_setup>; + snps,tsn-config = <&tsn_setup>; };
This adds the documentation for TSN feature EST and FP. Signed-off-by: Jose Abreu <joabreu@synopsys.com> Cc: David S. Miller <davem@davemloft.net> Cc: Joao Pinto <jpinto@synopsys.com> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Rob Herring <robh+dt@kernel.org> --- Documentation/devicetree/bindings/net/stmmac.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)