| Message ID | 20250113082818.345939-1-sergio.paracuellos@gmail.com (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | dt-bindings: clock: add clock definitions for Ralink SoCs | expand |
On 13/01/2025 09:28, Sergio Paracuellos wrote: > Add clock missing definitions for RT2880, RT305X, RT3352, RT3383, RT5350, > MT-7620 and MT-76X8 Ralink SoCs. > > Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> 1. Please use get_maintainers. 2. What is the point of this? We do not add constants when there are no users. Commit msg explains here nothing. > --- > include/dt-bindings/clock/mtmips-clk.h | 130 +++++++++++++++++++++++++ Filename matching compatible. Best regards, Krzysztof
Hi Krzysztof, On Mon, Jan 13, 2025 at 12:18 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On 13/01/2025 09:28, Sergio Paracuellos wrote: > > Add clock missing definitions for RT2880, RT305X, RT3352, RT3383, RT5350, > > MT-7620 and MT-76X8 Ralink SoCs. > > > > Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> > > 1. Please use get_maintainers. I did but from my tree which is tag: v6.12.5, linux-stable/linux-6.12.y. Sorry. > 2. What is the point of this? We do not add constants when there are no > users. Commit msg explains here nothing. All of the old ralink SoCs' dts files which are in the tree are not properly updated. I expect to have them updated somewhere in time merging real base stuff from openwrt dts [0] files. Not having this header with definitions makes very hard to update dts and then checking the driver code becomes a need to see the indexes for the clocks to properly setup a consumer node. Because of this, this file is added here. > > > --- > > include/dt-bindings/clock/mtmips-clk.h | 130 +++++++++++++++++++++++++ > > Filename matching compatible. There are multiple compatibles regarding this, since the driver covers a lot of SoCs. So I preferred to put them all in a single header file. See [1]. Should I add a different file for any single compatible instead? > > Best regards, > Krzysztof Thanks, Sergio Paracuellos [0]: https://github.com/openwrt/openwrt/tree/main/target/linux/ramips/dts [1]: https://elixir.bootlin.com/linux/v6.12.6/source/drivers/clk/ralink/clk-mtmips.c#L996
On 13/01/2025 12:32, Sergio Paracuellos wrote: > Hi Krzysztof, > > On Mon, Jan 13, 2025 at 12:18 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: >> >> On 13/01/2025 09:28, Sergio Paracuellos wrote: >>> Add clock missing definitions for RT2880, RT305X, RT3352, RT3383, RT5350, >>> MT-7620 and MT-76X8 Ralink SoCs. >>> >>> Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> >> >> 1. Please use get_maintainers. > > I did but from my tree which is tag: v6.12.5, linux-stable/linux-6.12.y. Sorry. That's separate problem, but not one I was thinking about. Even on 6.12 stable you would get dt list, which is missing here. This means no testing, although does not matter here, and it does not appear in Patchwork which means does not reach us, except my filter for nagging. > >> 2. What is the point of this? We do not add constants when there are no >> users. Commit msg explains here nothing. > > All of the old ralink SoCs' dts files which are in the tree are not > properly updated. I expect to have them updated somewhere in time > merging real base stuff from openwrt dts [0] files. Not having this > header with definitions makes very hard to update dts and then > checking the driver code becomes a need to see the indexes for the > clocks to properly setup a consumer node. Because of this, this file > is added here. Still there is no point without the users. I do not see any reason why this cannot be combined with fixing driver to use the header. Not combining is an indication this is not a binding in the first place. In any case there should be explanation in commit msg about such choice. > >> >>> --- >>> include/dt-bindings/clock/mtmips-clk.h | 130 +++++++++++++++++++++++++ >> >> Filename matching compatible. > > There are multiple compatibles regarding this, since the driver covers Driver almost does not matter. > a lot of SoCs. So I preferred to put them all in a single header file. > See [1]. Should I add a different file for any single compatible > instead? Well, are all in the same bindings file? If so, can stay but then: filename matching binding, because binding has proper naming scheme. Best regards, Krzysztof
On Mon, Jan 13, 2025 at 1:17 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On 13/01/2025 12:32, Sergio Paracuellos wrote: > > Hi Krzysztof, > > > > On Mon, Jan 13, 2025 at 12:18 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > >> > >> On 13/01/2025 09:28, Sergio Paracuellos wrote: > >>> Add clock missing definitions for RT2880, RT305X, RT3352, RT3383, RT5350, > >>> MT-7620 and MT-76X8 Ralink SoCs. > >>> > >>> Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> > >> > >> 1. Please use get_maintainers. > > > > I did but from my tree which is tag: v6.12.5, linux-stable/linux-6.12.y. Sorry. > > That's separate problem, but not one I was thinking about. Even on 6.12 > stable you would get dt list, which is missing here. > > This means no testing, although does not matter here, and it does not > appear in Patchwork which means does not reach us, except my filter for > nagging. True. You are right. I forgot to add the device tree list to the cc for this patch. Sorry. > > > > >> 2. What is the point of this? We do not add constants when there are no > >> users. Commit msg explains here nothing. > > > > All of the old ralink SoCs' dts files which are in the tree are not > > properly updated. I expect to have them updated somewhere in time > > merging real base stuff from openwrt dts [0] files. Not having this > > header with definitions makes very hard to update dts and then > > checking the driver code becomes a need to see the indexes for the > > clocks to properly setup a consumer node. Because of this, this file > > is added here. > > Still there is no point without the users. I do not see any reason why > this cannot be combined with fixing driver to use the header. Not > combining is an indication this is not a binding in the first place. Driver uses a bunch of arrays for the clocks (base, fixed, factor and peripheral) and they are registered consecutively in order just using the ARRAY_SIZE macro for any of them. Thus, the direct application of these definitions would be for dts consumer nodes, not the driver itself. > > In any case there should be explanation in commit msg about such choice. Sure, will do. > > > > >> > >>> --- > >>> include/dt-bindings/clock/mtmips-clk.h | 130 +++++++++++++++++++++++++ > >> > >> Filename matching compatible. > > > > There are multiple compatibles regarding this, since the driver covers > > Driver almost does not matter. > > > a lot of SoCs. So I preferred to put them all in a single header file. > > See [1]. Should I add a different file for any single compatible > > instead? > > Well, are all in the same bindings file? If so, can stay but then: > filename matching binding, because binding has proper naming scheme. I see. Yes, they are in Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml So I will rename this new header file to 'mediatek,mtmips-sysc.h' then. > > Best regards, > Krzysztof Thanks a lot! Best regards, Sergio Paracuellos
On 13/01/2025 13:29, Sergio Paracuellos wrote: >>> >>>> 2. What is the point of this? We do not add constants when there are no >>>> users. Commit msg explains here nothing. >>> >>> All of the old ralink SoCs' dts files which are in the tree are not >>> properly updated. I expect to have them updated somewhere in time >>> merging real base stuff from openwrt dts [0] files. Not having this >>> header with definitions makes very hard to update dts and then >>> checking the driver code becomes a need to see the indexes for the >>> clocks to properly setup a consumer node. Because of this, this file >>> is added here. >> >> Still there is no point without the users. I do not see any reason why >> this cannot be combined with fixing driver to use the header. Not >> combining is an indication this is not a binding in the first place. > > Driver uses a bunch of arrays for the clocks (base, fixed, factor and > peripheral) and they are registered consecutively in order just using > the ARRAY_SIZE macro for any of them. Thus, the direct application of > these definitions would be for dts consumer nodes, not the driver > itself. So what do you constants here fix? Driver can still reorganize arrays breaking everything. If defining headers for proper ABI, then use that ABI to make everything build-time testable and visible. That's why this is not supposed to be a separate patch from users. Best regards, Krzysztof
On Mon, Jan 13, 2025 at 1:37 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On 13/01/2025 13:29, Sergio Paracuellos wrote: > >>> > >>>> 2. What is the point of this? We do not add constants when there are no > >>>> users. Commit msg explains here nothing. > >>> > >>> All of the old ralink SoCs' dts files which are in the tree are not > >>> properly updated. I expect to have them updated somewhere in time > >>> merging real base stuff from openwrt dts [0] files. Not having this > >>> header with definitions makes very hard to update dts and then > >>> checking the driver code becomes a need to see the indexes for the > >>> clocks to properly setup a consumer node. Because of this, this file > >>> is added here. > >> > >> Still there is no point without the users. I do not see any reason why > >> this cannot be combined with fixing driver to use the header. Not > >> combining is an indication this is not a binding in the first place. > > > > Driver uses a bunch of arrays for the clocks (base, fixed, factor and > > peripheral) and they are registered consecutively in order just using > > the ARRAY_SIZE macro for any of them. Thus, the direct application of > > these definitions would be for dts consumer nodes, not the driver > > itself. > > So what do you constants here fix? Driver can still reorganize arrays > breaking everything. If defining headers for proper ABI, then use that > ABI to make everything build-time testable and visible. That's why this > is not supposed to be a separate patch from users. I understand your point and agree that the driver can do that, but the idea as this driver maintainer is not to do that :). Is adding something like the following in the binding itself with the header addition a possible way to go? --- a/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml +++ b/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml @@ -18,6 +18,12 @@ description: | These SoCs have an XTAL from where the cpu clock is provided as well as derived clocks for the bus and the peripherals. + Each clock is assigned an identifier and client nodes use this identifier + to specify the clock which they consume. + + All these identifiers could be found in: + [1]: <include/dt-bindings/clock/mediatek,mtmips-sysc.h>. + properties: compatible: items: @@ -38,7 +44,8 @@ properties: '#clock-cells': description: - The first cell indicates the clock number. + The first cell indicates the clock number, see [1] for available + clocks. const: 1 @@ -56,6 +63,8 @@ additionalProperties: false examples: - | + #include <dt-bindings/clock/mediatek,mtmips-sysc.h> + syscon@0 { compatible = "ralink,rt5350-sysc", "syscon"; reg = <0x0 0x100>; I don't like the idea of changing the driver code for using these constants since I do believe that it would make code uglier and less maintainable. I just wanted to make things easier for the device tree consumer nodes. So if adding this header is not a possibility with the changes in the yaml file I will forget about this addition and this patch. > > Best regards, > Krzysztof Thanks a lot for clarifications. Best regards, Sergio Paracuellos
On 13/01/2025 13:58, Sergio Paracuellos wrote: > On Mon, Jan 13, 2025 at 1:37 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: >> >> On 13/01/2025 13:29, Sergio Paracuellos wrote: >>>>> >>>>>> 2. What is the point of this? We do not add constants when there are no >>>>>> users. Commit msg explains here nothing. >>>>> >>>>> All of the old ralink SoCs' dts files which are in the tree are not >>>>> properly updated. I expect to have them updated somewhere in time >>>>> merging real base stuff from openwrt dts [0] files. Not having this >>>>> header with definitions makes very hard to update dts and then >>>>> checking the driver code becomes a need to see the indexes for the >>>>> clocks to properly setup a consumer node. Because of this, this file >>>>> is added here. >>>> >>>> Still there is no point without the users. I do not see any reason why >>>> this cannot be combined with fixing driver to use the header. Not >>>> combining is an indication this is not a binding in the first place. >>> >>> Driver uses a bunch of arrays for the clocks (base, fixed, factor and >>> peripheral) and they are registered consecutively in order just using >>> the ARRAY_SIZE macro for any of them. Thus, the direct application of >>> these definitions would be for dts consumer nodes, not the driver >>> itself. >> >> So what do you constants here fix? Driver can still reorganize arrays >> breaking everything. If defining headers for proper ABI, then use that >> ABI to make everything build-time testable and visible. That's why this >> is not supposed to be a separate patch from users. > > I understand your point and agree that the driver can do that, but the > idea as this driver maintainer is not to do that :). > Is adding something like the following in the binding itself with the > header addition a possible way to go? > > --- a/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml > +++ b/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml > @@ -18,6 +18,12 @@ description: | > These SoCs have an XTAL from where the cpu clock is > provided as well as derived clocks for the bus and the peripherals. > > + Each clock is assigned an identifier and client nodes use this identifier > + to specify the clock which they consume. > + > + All these identifiers could be found in: > + [1]: <include/dt-bindings/clock/mediatek,mtmips-sysc.h>. > + > properties: > compatible: > items: > @@ -38,7 +44,8 @@ properties: > > '#clock-cells': > description: > - The first cell indicates the clock number. > + The first cell indicates the clock number, see [1] for available > + clocks. > const: 1 > > @@ -56,6 +63,8 @@ additionalProperties: false > > examples: > - | > + #include <dt-bindings/clock/mediatek,mtmips-sysc.h> > + > syscon@0 { > compatible = "ralink,rt5350-sysc", "syscon"; > reg = <0x0 0x100>; This changes nothing. > > I don't like the idea of changing the driver code for using these > constants since I do believe that it would make code uglier and less > maintainable. I just wanted to make things easier for the device tree Then why having constants in the first place? > consumer nodes. So if adding this header is not a possibility with the > changes in the yaml file I will forget about this addition and this > patch. Header without user is pointless. Driver and the DTS are the expected users. Best regards, Krzysztof
On Tue, Jan 14, 2025 at 8:09 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On 13/01/2025 13:58, Sergio Paracuellos wrote: > > On Mon, Jan 13, 2025 at 1:37 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > >> > >> On 13/01/2025 13:29, Sergio Paracuellos wrote: > >>>>> > >>>>>> 2. What is the point of this? We do not add constants when there are no > >>>>>> users. Commit msg explains here nothing. > >>>>> > >>>>> All of the old ralink SoCs' dts files which are in the tree are not > >>>>> properly updated. I expect to have them updated somewhere in time > >>>>> merging real base stuff from openwrt dts [0] files. Not having this > >>>>> header with definitions makes very hard to update dts and then > >>>>> checking the driver code becomes a need to see the indexes for the > >>>>> clocks to properly setup a consumer node. Because of this, this file > >>>>> is added here. > >>>> > >>>> Still there is no point without the users. I do not see any reason why > >>>> this cannot be combined with fixing driver to use the header. Not > >>>> combining is an indication this is not a binding in the first place. > >>> > >>> Driver uses a bunch of arrays for the clocks (base, fixed, factor and > >>> peripheral) and they are registered consecutively in order just using > >>> the ARRAY_SIZE macro for any of them. Thus, the direct application of > >>> these definitions would be for dts consumer nodes, not the driver > >>> itself. > >> > >> So what do you constants here fix? Driver can still reorganize arrays > >> breaking everything. If defining headers for proper ABI, then use that > >> ABI to make everything build-time testable and visible. That's why this > >> is not supposed to be a separate patch from users. > > > > I understand your point and agree that the driver can do that, but the > > idea as this driver maintainer is not to do that :). > > Is adding something like the following in the binding itself with the > > header addition a possible way to go? > > > > --- a/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml > > +++ b/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml > > @@ -18,6 +18,12 @@ description: | > > These SoCs have an XTAL from where the cpu clock is > > provided as well as derived clocks for the bus and the peripherals. > > > > + Each clock is assigned an identifier and client nodes use this identifier > > + to specify the clock which they consume. > > + > > + All these identifiers could be found in: > > + [1]: <include/dt-bindings/clock/mediatek,mtmips-sysc.h>. > > + > > properties: > > compatible: > > items: > > @@ -38,7 +44,8 @@ properties: > > > > '#clock-cells': > > description: > > - The first cell indicates the clock number. > > + The first cell indicates the clock number, see [1] for available > > + clocks. > > const: 1 > > > > @@ -56,6 +63,8 @@ additionalProperties: false > > > > examples: > > - | > > + #include <dt-bindings/clock/mediatek,mtmips-sysc.h> > > + > > syscon@0 { > > compatible = "ralink,rt5350-sysc", "syscon"; > > reg = <0x0 0x100>; > > This changes nothing. Understood. Thanks for making it clear. > > > > > I don't like the idea of changing the driver code for using these > > constants since I do believe that it would make code uglier and less > > maintainable. I just wanted to make things easier for the device tree > > Then why having constants in the first place? Because I was expecting to have DTS as the only user and make things easier for it. > > > consumer nodes. So if adding this header is not a possibility with the > > changes in the yaml file I will forget about this addition and this > > patch. > > Header without user is pointless. Driver and the DTS are the expected users. Understood. So having only DTSs as users is not a possible way to go. It is clear now. Forget about this patch then. > > > Best regards, > Krzysztof Thanks, Sergio Paracuellos
On 14/01/2025 08:43, Sergio Paracuellos wrote: >> >>> consumer nodes. So if adding this header is not a possibility with the >>> changes in the yaml file I will forget about this addition and this >>> patch. >> >> Header without user is pointless. Driver and the DTS are the expected users. > > Understood. So having only DTSs as users is not a possible way to go. > It is clear now. Forget about this patch then. Only DTS user, with a justification, would go. Then just resend this patch when you have at least DTS user. Best regards, Krzysztof
On Wed, Jan 15, 2025 at 9:27 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On 14/01/2025 08:43, Sergio Paracuellos wrote: > >> > >>> consumer nodes. So if adding this header is not a possibility with the > >>> changes in the yaml file I will forget about this addition and this > >>> patch. > >> > >> Header without user is pointless. Driver and the DTS are the expected users. > > > > Understood. So having only DTSs as users is not a possible way to go. > > It is clear now. Forget about this patch then. > > Only DTS user, with a justification, would go. Then just resend this > patch when you have at least DTS user. Awesome, thanks for letting me know. I will update current arch/mips/boot/dts/ralink DTS files on-tree to reflect at least all of these clock changes before merging and properly update them with openwrt. I will resend with this patch then. > > Best regards, > Krzysztof Thanks, Sergio Paracuellos
diff --git a/include/dt-bindings/clock/mtmips-clk.h b/include/dt-bindings/clock/mtmips-clk.h new file mode 100644 index 000000000000..a03335b0e077 --- /dev/null +++ b/include/dt-bindings/clock/mtmips-clk.h @@ -0,0 +1,130 @@ +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ +/* + * Author: Sergio Paracuellos <sergio.paracuellos@gmail.com> + */ + +#ifndef _DT_BINDINGS_CLK_MTMIPS_H +#define _DT_BINDINGS_CLK_MTMIPS_H + +/* Ralink RT-2880 clocks */ + +#define RT2880_CLK_XTAL 0 +#define RT2880_CLK_CPU 1 +#define RT2880_CLK_BUS 2 +#define RT2880_CLK_TIMER 3 +#define RT2880_CLK_WATCHDOG 4 +#define RT2880_CLK_UART 5 +#define RT2880_CLK_I2C 6 +#define RT2880_CLK_UARTLITE 7 +#define RT2880_CLK_ETHERNET 8 +#define RT2880_CLK_WMAC 9 + +/* Ralink RT-305X clocks */ + +#define RT305X_CLK_XTAL 0 +#define RT305X_CLK_CPU 1 +#define RT305X_CLK_BUS 2 +#define RT305X_CLK_TIMER 3 +#define RT305X_CLK_WATCHDOG 4 +#define RT305X_CLK_UART 5 +#define RT305X_CLK_I2C 6 +#define RT305X_CLK_I2S 7 +#define RT305X_CLK_SPI1 8 +#define RT305X_CLK_SPI2 9 +#define RT305X_CLK_UARTLITE 10 +#define RT305X_CLK_ETHERNET 11 +#define RT305X_CLK_WMAC 12 + +/* Ralink RT-3352 clocks */ + +#define RT3352_CLK_XTAL 0 +#define RT3352_CLK_CPU 1 +#define RT3352_CLK_PERIPH 2 +#define RT3352_CLK_BUS 3 +#define RT3352_CLK_TIMER 4 +#define RT3352_CLK_WATCHDOG 5 +#define RT3352_CLK_UART 6 +#define RT3352_CLK_I2C 7 +#define RT3352_CLK_I2S 8 +#define RT3352_CLK_SPI1 9 +#define RT3352_CLK_SPI2 10 +#define RT3352_CLK_UARTLITE 11 +#define RT3352_CLK_ETHERNET 12 +#define RT3352_CLK_WMAC 13 + +/* Ralink RT-3883 clocks */ + +#define RT3883_CLK_XTAL 0 +#define RT3883_CLK_CPU 1 +#define RT3883_CLK_BUS 2 +#define RT3883_CLK_PERIPH 3 +#define RT3883_CLK_TIMER 4 +#define RT3883_CLK_WATCHDOG 5 +#define RT3883_CLK_UART 6 +#define RT3883_CLK_I2C 7 +#define RT3883_CLK_I2S 8 +#define RT3883_CLK_SPI1 9 +#define RT3883_CLK_SPI2 10 +#define RT3883_CLK_UARTLITE 11 +#define RT3883_CLK_ETHERNET 12 +#define RT3883_CLK_WMAC 13 + +/* Ralink RT-5350 clocks */ + +#define RT5350_CLK_XTAL 0 +#define RT5350_CLK_CPU 1 +#define RT5350_CLK_BUS 2 +#define RT5350_CLK_PERIPH 3 +#define RT5350_CLK_TIMER 4 +#define RT5350_CLK_WATCHDOG 5 +#define RT5350_CLK_UART 6 +#define RT5350_CLK_I2C 7 +#define RT5350_CLK_I2S 8 +#define RT5350_CLK_SPI1 9 +#define RT5350_CLK_SPI2 10 +#define RT5350_CLK_UARTLITE 11 +#define RT5350_CLK_ETHERNET 12 +#define RT5350_CLK_WMAC 13 + +/* Ralink MT-7620 clocks */ + +#define MT7620_CLK_XTAL 0 +#define MT7620_CLK_PLL 1 +#define MT7620_CLK_CPU 2 +#define MT7620_CLK_PERIPH 3 +#define MT7620_CLK_BUS 4 +#define MT7620_CLK_BBPPLL 5 +#define MT7620_CLK_SDHC 6 +#define MT7620_CLK_TIMER 7 +#define MT7620_CLK_WATCHDOG 8 +#define MT7620_CLK_UART 9 +#define MT7620_CLK_I2C 10 +#define MT7620_CLK_I2S 11 +#define MT7620_CLK_SPI1 12 +#define MT7620_CLK_SPI2 13 +#define MT7620_CLK_UARTLITE 14 +#define MT7620_CLK_MMC 15 +#define MT7620_CLK_WMAC 16 + +/* Ralink MT-76X8 clocks */ + +#define MT76X8_CLK_XTAL 0 +#define MT76X8_CLK_CPU 1 +#define MT76X8_CLK_BBPPLL 2 +#define MT76X8_CLK_PCMI2S 3 +#define MT76X8_CLK_PERIPH 4 +#define MT76X8_CLK_BUS 5 +#define MT76X8_CLK_SDHC 6 +#define MT76X8_CLK_TIMER 7 +#define MT76X8_CLK_WATCHDOG 8 +#define MT76X8_CLK_I2C 9 +#define MT76X8_CLK_I2S 10 +#define MT76X8_CLK_SPI1 11 +#define MT76X8_CLK_SPI2 12 +#define MT76X8_CLK_UART0 13 +#define MT76X8_CLK_UART1 14 +#define MT76X8_CLK_UART2 15 +#define MT76X8_CLK_MMC 16 +#define MT76X8_CLK_WMAC 17 + +#endif /* _DT_BINDINGS_CLK_MTMIPS_H */
Add clock missing definitions for RT2880, RT305X, RT3352, RT3383, RT5350, MT-7620 and MT-76X8 Ralink SoCs. Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> --- include/dt-bindings/clock/mtmips-clk.h | 130 +++++++++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 include/dt-bindings/clock/mtmips-clk.h