| Message ID | 20231113005503.2423-2-jszhang@kernel.org (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | riscv: sophgo: add reset support for cv1800b | expand |
On Mon, Nov 13, 2023 at 08:55:00AM +0800, Jisheng Zhang wrote: > Add devicetree binding for Sophgo CV1800B SoC reset controller. > > Signed-off-by: Jisheng Zhang <jszhang@kernel.org> With the unterminated ifndef that was pointed out by the robots fixed, Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > +/* 0-1 */ > +/* 10 */ > +/* 13 */ > +/* 15 */ > +/* 17 */ > +/* 36-39 */ > +/* 53-57 */ > +/* 59-60 */ > +/* 63-73 */ > +/* 90 */ > +/* 94 */ > +/* 102-292 */ There are quite a lot of gaps here, do you know why that is? Thanks, Conor.
On Mon, Nov 13, 2023 at 01:36:54PM +0000, Conor Dooley wrote: > On Mon, Nov 13, 2023 at 08:55:00AM +0800, Jisheng Zhang wrote: > > Add devicetree binding for Sophgo CV1800B SoC reset controller. > > > > Signed-off-by: Jisheng Zhang <jszhang@kernel.org> > > With the unterminated ifndef that was pointed out by the robots fixed, > Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > > > +/* 0-1 */ > > +/* 10 */ > > +/* 13 */ > > +/* 15 */ > > +/* 17 */ > > +/* 36-39 */ > > +/* 53-57 */ > > +/* 59-60 */ > > +/* 63-73 */ > > +/* 90 */ > > +/* 94 */ > > +/* 102-292 */ > > There are quite a lot of gaps here, do you know why that is? The tail bits are for cpusys, so I guess the SoC designer want to seperate them with guard? I'm not sure. > > Thanks, > Conor.
On 13/11/2023 01:55, Jisheng Zhang wrote: ... > diff --git a/include/dt-bindings/reset/sophgo,cv1800b-reset.h b/include/dt-bindings/reset/sophgo,cv1800b-reset.h > new file mode 100644 > index 000000000000..28dda71369b4 > --- /dev/null > +++ b/include/dt-bindings/reset/sophgo,cv1800b-reset.h > @@ -0,0 +1,96 @@ > +/* SPDX-License-Identifier: GPL-2.0 OR MIT */ > +/* > + * Copyright (C) 2023 Sophgo Technology Inc. All rights reserved. > + * Copyright (C) 2023 Jisheng Zhang <jszhang@kernel.org> > + */ > + > +#ifndef _DT_BINDINGS_CV1800B_RESET_H > +#define _DT_BINDINGS_CV1800B_RESET_H > + > +/* 0-1 */ > +#define RST_DDR 2 > +#define RST_H264C 3 > +#define RST_JPEG 4 > +#define RST_H265C 5 > +#define RST_VIPSYS 6 > +#define RST_TDMA 7 > +#define RST_TPU 8 > +#define RST_TPUSYS 9 > +/* 10 */ Why do you have empty IDs? IDs start at 0 and are incremented by 1. Best regards, Krzysztof
On 13/11/2023 15:00, Jisheng Zhang wrote: > On Mon, Nov 13, 2023 at 01:36:54PM +0000, Conor Dooley wrote: >> On Mon, Nov 13, 2023 at 08:55:00AM +0800, Jisheng Zhang wrote: >>> Add devicetree binding for Sophgo CV1800B SoC reset controller. >>> >>> Signed-off-by: Jisheng Zhang <jszhang@kernel.org> >> >> With the unterminated ifndef that was pointed out by the robots fixed, >> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> >> >>> +/* 0-1 */ >>> +/* 10 */ >>> +/* 13 */ >>> +/* 15 */ >>> +/* 17 */ >>> +/* 36-39 */ >>> +/* 53-57 */ >>> +/* 59-60 */ >>> +/* 63-73 */ >>> +/* 90 */ >>> +/* 94 */ >>> +/* 102-292 */ >> >> There are quite a lot of gaps here, do you know why that is? > > The tail bits are for cpusys, so I guess the SoC designer want to > seperate them with guard? I'm not sure. > There is misunderstanding here. You add here IDs, which are abstract. Any gaps do not make any sense for bindings. Best regards, Krzysztof
On Tue, Nov 14, 2023 at 10:12:35PM +0100, Krzysztof Kozlowski wrote: > On 13/11/2023 01:55, Jisheng Zhang wrote: > ... > > > diff --git a/include/dt-bindings/reset/sophgo,cv1800b-reset.h b/include/dt-bindings/reset/sophgo,cv1800b-reset.h > > new file mode 100644 > > index 000000000000..28dda71369b4 > > --- /dev/null > > +++ b/include/dt-bindings/reset/sophgo,cv1800b-reset.h > > @@ -0,0 +1,96 @@ > > +/* SPDX-License-Identifier: GPL-2.0 OR MIT */ > > +/* > > + * Copyright (C) 2023 Sophgo Technology Inc. All rights reserved. > > + * Copyright (C) 2023 Jisheng Zhang <jszhang@kernel.org> > > + */ > > + > > +#ifndef _DT_BINDINGS_CV1800B_RESET_H > > +#define _DT_BINDINGS_CV1800B_RESET_H > > + > > +/* 0-1 */ > > +#define RST_DDR 2 > > +#define RST_H264C 3 > > +#define RST_JPEG 4 > > +#define RST_H265C 5 > > +#define RST_VIPSYS 6 > > +#define RST_TDMA 7 > > +#define RST_TPU 8 > > +#define RST_TPUSYS 9 > > +/* 10 */ > > Why do you have empty IDs? IDs start at 0 and are incremented by 1. there's 1:1 mapping between the ID and bit. Some bits are reserved, I.E no actions at all. Is "ID start at 0 and increment by 1" documented in some docs? From another side, I also notice some SoCs especially those which make use of reset-simple driver don't strictly follow this rule, for example, amlogic,meson-a1-reset.h and so on. What happened? And I'd like to ask a question here before cooking 2nd version: if the HW programming logic is the same as reset-simple, but some or many bits are reserved, what's the can-be-accepted way to support the reset controller? Use reset-simple? Obviously if we want the "ID start at 0 and increment by 1" rule, then we have to write a custom driver which almost use the reset-simple but with a customized mapping. Thanks
On 2023-11-15 7:27 AM, Jisheng Zhang wrote: > On Tue, Nov 14, 2023 at 10:12:35PM +0100, Krzysztof Kozlowski wrote: >> On 13/11/2023 01:55, Jisheng Zhang wrote: >> ... >> >>> diff --git a/include/dt-bindings/reset/sophgo,cv1800b-reset.h b/include/dt-bindings/reset/sophgo,cv1800b-reset.h >>> new file mode 100644 >>> index 000000000000..28dda71369b4 >>> --- /dev/null >>> +++ b/include/dt-bindings/reset/sophgo,cv1800b-reset.h >>> @@ -0,0 +1,96 @@ >>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */ >>> +/* >>> + * Copyright (C) 2023 Sophgo Technology Inc. All rights reserved. >>> + * Copyright (C) 2023 Jisheng Zhang <jszhang@kernel.org> >>> + */ >>> + >>> +#ifndef _DT_BINDINGS_CV1800B_RESET_H >>> +#define _DT_BINDINGS_CV1800B_RESET_H >>> + >>> +/* 0-1 */ >>> +#define RST_DDR 2 >>> +#define RST_H264C 3 >>> +#define RST_JPEG 4 >>> +#define RST_H265C 5 >>> +#define RST_VIPSYS 6 >>> +#define RST_TDMA 7 >>> +#define RST_TPU 8 >>> +#define RST_TPUSYS 9 >>> +/* 10 */ >> >> Why do you have empty IDs? IDs start at 0 and are incremented by 1. > > there's 1:1 mapping between the ID and bit. Some bits are reserved, I.E > no actions at all. Is "ID start at 0 and increment by 1" documented > in some docs? From another side, I also notice some SoCs especially > those which make use of reset-simple driver don't strictly follow > this rule, for example, amlogic,meson-a1-reset.h and so on. What > happened? > > And I'd like to ask a question here before cooking 2nd version: > if the HW programming logic is the same as reset-simple, but some > or many bits are reserved, what's the can-be-accepted way to support > the reset controller? Use reset-simple? Obviously if we want the > "ID start at 0 and increment by 1" rule, then we have to write > a custom driver which almost use the reset-simple but with a > customized mapping. There are two possible situations. Either the reset specifier maps directly to something in the hardware, or you are inventing some brand new enumeration to use as a specifier. In the first situation, you do not need a header. We assume the user will look to the SoC documentation if they want to know what the numbers mean. (You aren't _creating_ an ABI, since the ABI is already defined by the hardware.) In the second situation, since we are inventing something new, the numbers should be contiguous. This is what Krzysztof's comment was about. For this reset device, the numbers are hardware bit offsets, so you are in the first situation. So I think the recommended solution here is to remove the header entirely and use the bit numbers directly in the SoC devicetree. It's still appropriate to use reset-simple. Adding some new mapping would make things more complicated for no benefit. Regards, Samuel
On Wed, Nov 15, 2023 at 09:56:07AM -0500, Samuel Holland wrote: > On 2023-11-15 7:27 AM, Jisheng Zhang wrote: > > On Tue, Nov 14, 2023 at 10:12:35PM +0100, Krzysztof Kozlowski wrote: > >> On 13/11/2023 01:55, Jisheng Zhang wrote: > >> ... > >> > >>> diff --git a/include/dt-bindings/reset/sophgo,cv1800b-reset.h b/include/dt-bindings/reset/sophgo,cv1800b-reset.h > >>> new file mode 100644 > >>> index 000000000000..28dda71369b4 > >>> --- /dev/null > >>> +++ b/include/dt-bindings/reset/sophgo,cv1800b-reset.h > >>> @@ -0,0 +1,96 @@ > >>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */ > >>> +/* > >>> + * Copyright (C) 2023 Sophgo Technology Inc. All rights reserved. > >>> + * Copyright (C) 2023 Jisheng Zhang <jszhang@kernel.org> > >>> + */ > >>> + > >>> +#ifndef _DT_BINDINGS_CV1800B_RESET_H > >>> +#define _DT_BINDINGS_CV1800B_RESET_H > >>> + > >>> +/* 0-1 */ > >>> +#define RST_DDR 2 > >>> +#define RST_H264C 3 > >>> +#define RST_JPEG 4 > >>> +#define RST_H265C 5 > >>> +#define RST_VIPSYS 6 > >>> +#define RST_TDMA 7 > >>> +#define RST_TPU 8 > >>> +#define RST_TPUSYS 9 > >>> +/* 10 */ > >> > >> Why do you have empty IDs? IDs start at 0 and are incremented by 1. > > > > there's 1:1 mapping between the ID and bit. Some bits are reserved, I.E > > no actions at all. Is "ID start at 0 and increment by 1" documented > > in some docs? From another side, I also notice some SoCs especially > > those which make use of reset-simple driver don't strictly follow > > this rule, for example, amlogic,meson-a1-reset.h and so on. What > > happened? > > > > And I'd like to ask a question here before cooking 2nd version: > > if the HW programming logic is the same as reset-simple, but some > > or many bits are reserved, what's the can-be-accepted way to support > > the reset controller? Use reset-simple? Obviously if we want the > > "ID start at 0 and increment by 1" rule, then we have to write > > a custom driver which almost use the reset-simple but with a > > customized mapping. > > There are two possible situations. Either the reset specifier maps directly to > something in the hardware, or you are inventing some brand new enumeration to > use as a specifier. > > In the first situation, you do not need a header. We assume the user will look > to the SoC documentation if they want to know what the numbers mean. (You aren't > _creating_ an ABI, since the ABI is already defined by the hardware.) > > In the second situation, since we are inventing something new, the numbers > should be contiguous. This is what Krzysztof's comment was about. > > For this reset device, the numbers are hardware bit offsets, so you are in the > first situation. So I think the recommended solution here is to remove the > header entirely and use the bit numbers directly in the SoC devicetree. > > It's still appropriate to use reset-simple. Adding some new mapping would make > things more complicated for no benefit. Further, I think it is fine in that case to have a header, just the header doesn't belong as a binding, and can instead go in the dts directory.
On Wed, Nov 15, 2023 at 03:02:21PM +0000, Conor Dooley wrote: > On Wed, Nov 15, 2023 at 09:56:07AM -0500, Samuel Holland wrote: > > On 2023-11-15 7:27 AM, Jisheng Zhang wrote: > > > On Tue, Nov 14, 2023 at 10:12:35PM +0100, Krzysztof Kozlowski wrote: > > >> On 13/11/2023 01:55, Jisheng Zhang wrote: > > >> ... > > >> > > >>> diff --git a/include/dt-bindings/reset/sophgo,cv1800b-reset.h b/include/dt-bindings/reset/sophgo,cv1800b-reset.h > > >>> new file mode 100644 > > >>> index 000000000000..28dda71369b4 > > >>> --- /dev/null > > >>> +++ b/include/dt-bindings/reset/sophgo,cv1800b-reset.h > > >>> @@ -0,0 +1,96 @@ > > >>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */ > > >>> +/* > > >>> + * Copyright (C) 2023 Sophgo Technology Inc. All rights reserved. > > >>> + * Copyright (C) 2023 Jisheng Zhang <jszhang@kernel.org> > > >>> + */ > > >>> + > > >>> +#ifndef _DT_BINDINGS_CV1800B_RESET_H > > >>> +#define _DT_BINDINGS_CV1800B_RESET_H > > >>> + > > >>> +/* 0-1 */ > > >>> +#define RST_DDR 2 > > >>> +#define RST_H264C 3 > > >>> +#define RST_JPEG 4 > > >>> +#define RST_H265C 5 > > >>> +#define RST_VIPSYS 6 > > >>> +#define RST_TDMA 7 > > >>> +#define RST_TPU 8 > > >>> +#define RST_TPUSYS 9 > > >>> +/* 10 */ > > >> > > >> Why do you have empty IDs? IDs start at 0 and are incremented by 1. > > > > > > there's 1:1 mapping between the ID and bit. Some bits are reserved, I.E > > > no actions at all. Is "ID start at 0 and increment by 1" documented > > > in some docs? From another side, I also notice some SoCs especially > > > those which make use of reset-simple driver don't strictly follow > > > this rule, for example, amlogic,meson-a1-reset.h and so on. What > > > happened? > > > > > > And I'd like to ask a question here before cooking 2nd version: > > > if the HW programming logic is the same as reset-simple, but some > > > or many bits are reserved, what's the can-be-accepted way to support > > > the reset controller? Use reset-simple? Obviously if we want the > > > "ID start at 0 and increment by 1" rule, then we have to write > > > a custom driver which almost use the reset-simple but with a > > > customized mapping. > > > > There are two possible situations. Either the reset specifier maps directly to > > something in the hardware, or you are inventing some brand new enumeration to > > use as a specifier. > > > > In the first situation, you do not need a header. We assume the user will look > > to the SoC documentation if they want to know what the numbers mean. (You aren't > > _creating_ an ABI, since the ABI is already defined by the hardware.) > > > > In the second situation, since we are inventing something new, the numbers > > should be contiguous. This is what Krzysztof's comment was about. > > > > For this reset device, the numbers are hardware bit offsets, so you are in the > > first situation. So I think the recommended solution here is to remove the > > header entirely and use the bit numbers directly in the SoC devicetree. > > > > It's still appropriate to use reset-simple. Adding some new mapping would make > > things more complicated for no benefit. > > Further, I think it is fine in that case to have a header, just the > header doesn't belong as a binding, and can instead go in the dts > directory. Hi Samuel, Conor, thanks a lot for the suggestion! Regards
On 15/11/2023 16:15, Jisheng Zhang wrote: > On Wed, Nov 15, 2023 at 03:02:21PM +0000, Conor Dooley wrote: >> On Wed, Nov 15, 2023 at 09:56:07AM -0500, Samuel Holland wrote: >>> On 2023-11-15 7:27 AM, Jisheng Zhang wrote: >>>> On Tue, Nov 14, 2023 at 10:12:35PM +0100, Krzysztof Kozlowski wrote: >>>>> On 13/11/2023 01:55, Jisheng Zhang wrote: >>>>> ... >>>>> >>>>>> diff --git a/include/dt-bindings/reset/sophgo,cv1800b-reset.h b/include/dt-bindings/reset/sophgo,cv1800b-reset.h >>>>>> new file mode 100644 >>>>>> index 000000000000..28dda71369b4 >>>>>> --- /dev/null >>>>>> +++ b/include/dt-bindings/reset/sophgo,cv1800b-reset.h >>>>>> @@ -0,0 +1,96 @@ >>>>>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */ >>>>>> +/* >>>>>> + * Copyright (C) 2023 Sophgo Technology Inc. All rights reserved. >>>>>> + * Copyright (C) 2023 Jisheng Zhang <jszhang@kernel.org> >>>>>> + */ >>>>>> + >>>>>> +#ifndef _DT_BINDINGS_CV1800B_RESET_H >>>>>> +#define _DT_BINDINGS_CV1800B_RESET_H >>>>>> + >>>>>> +/* 0-1 */ >>>>>> +#define RST_DDR 2 >>>>>> +#define RST_H264C 3 >>>>>> +#define RST_JPEG 4 >>>>>> +#define RST_H265C 5 >>>>>> +#define RST_VIPSYS 6 >>>>>> +#define RST_TDMA 7 >>>>>> +#define RST_TPU 8 >>>>>> +#define RST_TPUSYS 9 >>>>>> +/* 10 */ >>>>> >>>>> Why do you have empty IDs? IDs start at 0 and are incremented by 1. >>>> >>>> there's 1:1 mapping between the ID and bit. Some bits are reserved, I.E >>>> no actions at all. Is "ID start at 0 and increment by 1" documented >>>> in some docs? From another side, I also notice some SoCs especially >>>> those which make use of reset-simple driver don't strictly follow >>>> this rule, for example, amlogic,meson-a1-reset.h and so on. What >>>> happened? >>>> >>>> And I'd like to ask a question here before cooking 2nd version: >>>> if the HW programming logic is the same as reset-simple, but some >>>> or many bits are reserved, what's the can-be-accepted way to support >>>> the reset controller? Use reset-simple? Obviously if we want the >>>> "ID start at 0 and increment by 1" rule, then we have to write >>>> a custom driver which almost use the reset-simple but with a >>>> customized mapping. >>> >>> There are two possible situations. Either the reset specifier maps directly to >>> something in the hardware, or you are inventing some brand new enumeration to >>> use as a specifier. >>> >>> In the first situation, you do not need a header. We assume the user will look >>> to the SoC documentation if they want to know what the numbers mean. (You aren't >>> _creating_ an ABI, since the ABI is already defined by the hardware.) >>> >>> In the second situation, since we are inventing something new, the numbers >>> should be contiguous. This is what Krzysztof's comment was about. >>> >>> For this reset device, the numbers are hardware bit offsets, so you are in the >>> first situation. So I think the recommended solution here is to remove the >>> header entirely and use the bit numbers directly in the SoC devicetree. >>> >>> It's still appropriate to use reset-simple. Adding some new mapping would make >>> things more complicated for no benefit. >> >> Further, I think it is fine in that case to have a header, just the >> header doesn't belong as a binding, and can instead go in the dts >> directory. > > Hi Samuel, Conor, > > thanks a lot for the suggestion! There is actually a thing here I missed. If this is a reset-simple driver with dedicated SoC-specific compatible, you could want to have a binding header to have IDs. This way later you can easily replace the driver with another implementation, which does no rely on 1-1 mapping to reset bits. Therefore the reset-simple could be the exception where reset-bits could have a meaning as binding header. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/reset/sophgo,cv1800b-reset.yaml b/Documentation/devicetree/bindings/reset/sophgo,cv1800b-reset.yaml new file mode 100644 index 000000000000..20a525147490 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/sophgo,cv1800b-reset.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/sophgo,cv1800b-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sophgo CV1800B SoC Reset Controller + +maintainers: + - Jisheng Zhang <jszhang@kernel.org> + +properties: + compatible: + enum: + - sophgo,cv1800b-reset + + reg: + maxItems: 1 + + "#reset-cells": + const: 1 + +required: + - compatible + - reg + - "#reset-cells" + +additionalProperties: false + +examples: + - | + reset-controller@3003000 { + compatible = "sophgo,cv1800b-reset"; + reg = <0x03003000 0x1000>; + #reset-cells = <1>; + }; + +... diff --git a/include/dt-bindings/reset/sophgo,cv1800b-reset.h b/include/dt-bindings/reset/sophgo,cv1800b-reset.h new file mode 100644 index 000000000000..28dda71369b4 --- /dev/null +++ b/include/dt-bindings/reset/sophgo,cv1800b-reset.h @@ -0,0 +1,96 @@ +/* SPDX-License-Identifier: GPL-2.0 OR MIT */ +/* + * Copyright (C) 2023 Sophgo Technology Inc. All rights reserved. + * Copyright (C) 2023 Jisheng Zhang <jszhang@kernel.org> + */ + +#ifndef _DT_BINDINGS_CV1800B_RESET_H +#define _DT_BINDINGS_CV1800B_RESET_H + +/* 0-1 */ +#define RST_DDR 2 +#define RST_H264C 3 +#define RST_JPEG 4 +#define RST_H265C 5 +#define RST_VIPSYS 6 +#define RST_TDMA 7 +#define RST_TPU 8 +#define RST_TPUSYS 9 +/* 10 */ +#define RST_USB 11 +#define RST_ETH0 12 +/* 13 */ +#define RST_NAND 14 +/* 15 */ +#define RST_SD0 16 +/* 17 */ +#define RST_SDMA 18 +#define RST_I2S0 19 +#define RST_I2S1 20 +#define RST_I2S2 21 +#define RST_I2S3 22 +#define RST_UART0 23 +#define RST_UART1 24 +#define RST_UART2 25 +#define RST_UART3 26 +#define RST_I2C0 27 +#define RST_I2C1 28 +#define RST_I2C2 29 +#define RST_I2C3 30 +#define RST_I2C4 31 +#define RST_PWM0 32 +#define RST_PWM1 33 +#define RST_PWM2 34 +#define RST_PWM3 35 +/* 36-39 */ +#define RST_SPI0 40 +#define RST_SPI1 41 +#define RST_SPI2 42 +#define RST_SPI3 43 +#define RST_GPIO0 44 +#define RST_GPIO1 45 +#define RST_GPIO2 46 +#define RST_EFUSE 47 +#define RST_WDT 48 +#define RST_AHBRST_ROM 49 +#define RST_SPIC 50 +#define RST_TEMPSEN 51 +#define RST_SARADC 52 +/* 53-57 */ +#define RST_COMBORST_PHY0 58 +/* 59-60 */ +#define RST_SPIRST_NAND 61 +#define RST_SE 62 +/* 63-73 */ +#define RST_UART4 74 +#define RST_GPIO3 75 +#define RST_SYSTEM 76 +#define RST_TIMER 77 +#define RST_TIMER0 78 +#define RST_TIMER1 79 +#define RST_TIMER2 80 +#define RST_TIMER3 81 +#define RST_TIMER4 82 +#define RST_TIMER5 83 +#define RST_TIMER6 84 +#define RST_TIMER7 85 +#define RST_WGN0 86 +#define RST_WGN1 87 +#define RST_WGN2 88 +#define RST_KEYSCAN 89 +/* 90 */ +#define RST_AUDDAC 91 +#define RST_AUDDACRST_APB 92 +#define RST_AUDADC 93 +/* 94 */ +#define RST_VCSYS 95 +#define RST_ETHPHY 96 +#define RST_ETHPHYRST_APB 97 +#define RST_AUDSRC 98 +#define RST_VIP_CAM0 99 +#define RST_WDT1 100 +#define RST_WDT2 101 +/* 102-292 */ +#define RST_CPUSYS1 293 +#define RST_CPUSYS2 294 +
Add devicetree binding for Sophgo CV1800B SoC reset controller. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> --- .../bindings/reset/sophgo,cv1800b-reset.yaml | 38 ++++++++ .../dt-bindings/reset/sophgo,cv1800b-reset.h | 96 +++++++++++++++++++ 2 files changed, 134 insertions(+) create mode 100644 Documentation/devicetree/bindings/reset/sophgo,cv1800b-reset.yaml create mode 100644 include/dt-bindings/reset/sophgo,cv1800b-reset.h +#endif /* _DT_BINDINGS_CV1800B_RESET_H */