From: Erez Geva <ErezGeva2@gmail.com>
Some flash devices need OTP parameters in device tree.
As we can not deduce the parameters based on JEDEC ID or SFDP.
Signed-off-by: Erez Geva <ErezGeva2@gmail.com>
---
.../bindings/mtd/jedec,spi-nor.yaml | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
index 6e3afb42926e..d502b7fab2ce 100644
--- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
+++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
@@ -90,6 +90,43 @@ properties:
the SRWD bit while writing the status register. WP# signal hard strapped to GND
can be a valid use case.
+ opt_n_regions:
+ type: u32
+ description:
+ Some flash devices need OTP parameters in the device tree.
+ As we can not deduce the parameters based on JEDEC ID or SFDP.
+ This parameter indicates the number of OTP regions.
+ The value must be larger than 1 and mandatory for OTP.
+
+ otp_len:
+ type: u32
+ description:
+ Some flash devices need OTP parameters in the device tree.
+ As we can not deduce the parameters based on JEDEC ID or SFDP.
+ This parameter indicates the size (length) in bytes of an OTP region.
+ Currently the driver supports symmetric OTP,
+ which means all regions must use the same size.
+ The value must be positive and mandatory for OTP.
+
+ otp_offset:
+ type: u32
+ description:
+ Some flash devices need OTP parameters in the device tree.
+ As we can not deduce the parameters based on JEDEC ID or SFDP.
+ This parameter indicates the offset in bytes of
+ an OTP region relative to its previous.
+ User can omit it if the offset equals the length.
+ Or in case we have a single OTP region.
+
+ otp_base:
+ type: u32
+ description:
+ Some flash devices need OTP parameters in the device tree.
+ As we can not deduce the parameters based on JEDEC ID or SFDP.
+ This parameter indicates the base in bytes of the first OTP region.
+ User can omit it if the base is zero.
+ I.e. the address of the first OTP region starts from 0.
+
reset-gpios:
description:
A GPIO line connected to the RESET (active low) signal of the device.
--
2.39.5On 17/09/2024 11:49, Erez Geva wrote: > From: Erez Geva <ErezGeva2@gmail.com> > > Some flash devices need OTP parameters in device tree. > As we can not deduce the parameters based on JEDEC ID or SFDP. > > Signed-off-by: Erez Geva <ErezGeva2@gmail.com> > --- > .../bindings/mtd/jedec,spi-nor.yaml | 37 +++++++++++++++++++ > 1 file changed, 37 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > index 6e3afb42926e..d502b7fab2ce 100644 > --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > @@ -90,6 +90,43 @@ properties: > the SRWD bit while writing the status register. WP# signal hard strapped to GND > can be a valid use case. > > + opt_n_regions: No underscores, but hyphens. > + type: u32 It does not look like you tested the bindings, at least after quick look. Please run `make dt_binding_check` (see Documentation/devicetree/bindings/writing-schema.rst for instructions). Maybe you need to update your dtschema and yamllint. Best regards, Krzysztof
On Tue, 17 Sept 2024 at 12:36, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On 17/09/2024 11:49, Erez Geva wrote: > > From: Erez Geva <ErezGeva2@gmail.com> > > > > Some flash devices need OTP parameters in device tree. > > As we can not deduce the parameters based on JEDEC ID or SFDP. > > > > Signed-off-by: Erez Geva <ErezGeva2@gmail.com> > > --- > > .../bindings/mtd/jedec,spi-nor.yaml | 37 +++++++++++++++++++ > > 1 file changed, 37 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > > index 6e3afb42926e..d502b7fab2ce 100644 > > --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > > +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > > @@ -90,6 +90,43 @@ properties: > > the SRWD bit while writing the status register. WP# signal hard strapped to GND > > can be a valid use case. > > > > + opt_n_regions: > > No underscores, but hyphens. I'll fix this. > > > + type: u32 > > It does not look like you tested the bindings, at least after quick > look. Please run `make dt_binding_check` (see I run "make dt_binding_check" on kernel 6.6. > Documentation/devicetree/bindings/writing-schema.rst for instructions). > Maybe you need to update your dtschema and yamllint. > > > > Best regards, > Krzysztof > Thanks for the feedback.
On 17/09/2024 12:42, Erez wrote: > On Tue, 17 Sept 2024 at 12:36, Krzysztof Kozlowski <krzk@kernel.org> wrote: >> >> On 17/09/2024 11:49, Erez Geva wrote: >>> From: Erez Geva <ErezGeva2@gmail.com> >>> >>> Some flash devices need OTP parameters in device tree. >>> As we can not deduce the parameters based on JEDEC ID or SFDP. >>> >>> Signed-off-by: Erez Geva <ErezGeva2@gmail.com> >>> --- >>> .../bindings/mtd/jedec,spi-nor.yaml | 37 +++++++++++++++++++ >>> 1 file changed, 37 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml >>> index 6e3afb42926e..d502b7fab2ce 100644 >>> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml >>> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml >>> @@ -90,6 +90,43 @@ properties: >>> the SRWD bit while writing the status register. WP# signal hard strapped to GND >>> can be a valid use case. >>> >>> + opt_n_regions: >> >> No underscores, but hyphens. > > I'll fix this. > >> >>> + type: u32 >> >> It does not look like you tested the bindings, at least after quick >> look. Please run `make dt_binding_check` (see > > I run "make dt_binding_check" on kernel 6.6. Yeah, we are no on kernel 6.6. You can run it also on kernel v4.1 - still does not matter. Don't develop on ancient code because then you ask us to review same broken stuff we already fixed. Best regards, Krzysztof
On Tue, 17 Sept 2024 at 19:00, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On 17/09/2024 12:42, Erez wrote: > > On Tue, 17 Sept 2024 at 12:36, Krzysztof Kozlowski <krzk@kernel.org> wrote: > >> > >> On 17/09/2024 11:49, Erez Geva wrote: > >>> From: Erez Geva <ErezGeva2@gmail.com> > >>> > >>> Some flash devices need OTP parameters in device tree. > >>> As we can not deduce the parameters based on JEDEC ID or SFDP. > >>> > >>> Signed-off-by: Erez Geva <ErezGeva2@gmail.com> > >>> --- > >>> .../bindings/mtd/jedec,spi-nor.yaml | 37 +++++++++++++++++++ > >>> 1 file changed, 37 insertions(+) > >>> > >>> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > >>> index 6e3afb42926e..d502b7fab2ce 100644 > >>> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > >>> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > >>> @@ -90,6 +90,43 @@ properties: > >>> the SRWD bit while writing the status register. WP# signal hard strapped to GND > >>> can be a valid use case. > >>> > >>> + opt_n_regions: > >> > >> No underscores, but hyphens. > > > > I'll fix this. > > > >> > >>> + type: u32 > >> > >> It does not look like you tested the bindings, at least after quick > >> look. Please run `make dt_binding_check` (see > > > > I run "make dt_binding_check" on kernel 6.6. > > Yeah, we are no on kernel 6.6. You can run it also on kernel v4.1 - > still does not matter. > > Don't develop on ancient code because then you ask us to review same > broken stuff we already fixed. I test with Beaglebone black for testing, it is difficult to run the last vanille version. I did backport the spi-nor driver. As for "make dt_binding_check" on last kernel, it need to upgrade the tools, and I did not think it could change that much. The patches themself are based on vanile kernel commit 6b0f8db921abf0520081d779876d3a41069dab95 (origin/master) Merge: 6b4aa469f049 f50733b45d86 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue Aug 13 16:10:32 2024 -0700 Erez > > Best regards, > Krzysztof >
On 17/09/2024 19:11, Erez wrote: > On Tue, 17 Sept 2024 at 19:00, Krzysztof Kozlowski <krzk@kernel.org> wrote: >> >> On 17/09/2024 12:42, Erez wrote: >>> On Tue, 17 Sept 2024 at 12:36, Krzysztof Kozlowski <krzk@kernel.org> wrote: >>>> >>>> On 17/09/2024 11:49, Erez Geva wrote: >>>>> From: Erez Geva <ErezGeva2@gmail.com> >>>>> >>>>> Some flash devices need OTP parameters in device tree. >>>>> As we can not deduce the parameters based on JEDEC ID or SFDP. >>>>> >>>>> Signed-off-by: Erez Geva <ErezGeva2@gmail.com> >>>>> --- >>>>> .../bindings/mtd/jedec,spi-nor.yaml | 37 +++++++++++++++++++ >>>>> 1 file changed, 37 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml >>>>> index 6e3afb42926e..d502b7fab2ce 100644 >>>>> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml >>>>> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml >>>>> @@ -90,6 +90,43 @@ properties: >>>>> the SRWD bit while writing the status register. WP# signal hard strapped to GND >>>>> can be a valid use case. >>>>> >>>>> + opt_n_regions: >>>> >>>> No underscores, but hyphens. >>> >>> I'll fix this. >>> >>>> >>>>> + type: u32 >>>> >>>> It does not look like you tested the bindings, at least after quick >>>> look. Please run `make dt_binding_check` (see >>> >>> I run "make dt_binding_check" on kernel 6.6. >> >> Yeah, we are no on kernel 6.6. You can run it also on kernel v4.1 - >> still does not matter. >> >> Don't develop on ancient code because then you ask us to review same >> broken stuff we already fixed. > > I test with Beaglebone black for testing, it is difficult to run the > last vanille version. > I did backport the spi-nor driver. > As for "make dt_binding_check" on last kernel, it need to upgrade the tools, > and I did not think it could change that much. > Well, it is possible to build kernel on small embedded board, but that's quite cumbersone, slow and inefficient, considering that it's just easier to cross compile. But anyway, binding check does not even need cross compilation. Sorry, the code is obviously wrong, there is no such thing as u32, so you did not test it. I provided link which explains how to test it. You must do it on latest mainline kernel. Just like you must develop and generate patches on latest mainline kernel, because this is where we apply the patches. We do not apply them to v6.6. Best regards, Krzysztof
On Tue, 17 Sept 2024 at 19:17, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On 17/09/2024 19:11, Erez wrote: > > On Tue, 17 Sept 2024 at 19:00, Krzysztof Kozlowski <krzk@kernel.org> wrote: > >> > >> On 17/09/2024 12:42, Erez wrote: > >>> On Tue, 17 Sept 2024 at 12:36, Krzysztof Kozlowski <krzk@kernel.org> wrote: > >>>> > >>>> On 17/09/2024 11:49, Erez Geva wrote: > >>>>> From: Erez Geva <ErezGeva2@gmail.com> > >>>>> > >>>>> Some flash devices need OTP parameters in device tree. > >>>>> As we can not deduce the parameters based on JEDEC ID or SFDP. > >>>>> > >>>>> Signed-off-by: Erez Geva <ErezGeva2@gmail.com> > >>>>> --- > >>>>> .../bindings/mtd/jedec,spi-nor.yaml | 37 +++++++++++++++++++ > >>>>> 1 file changed, 37 insertions(+) > >>>>> > >>>>> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > >>>>> index 6e3afb42926e..d502b7fab2ce 100644 > >>>>> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > >>>>> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > >>>>> @@ -90,6 +90,43 @@ properties: > >>>>> the SRWD bit while writing the status register. WP# signal hard strapped to GND > >>>>> can be a valid use case. > >>>>> > >>>>> + opt_n_regions: > >>>> > >>>> No underscores, but hyphens. > >>> > >>> I'll fix this. > >>> > >>>> > >>>>> + type: u32 > >>>> > >>>> It does not look like you tested the bindings, at least after quick > >>>> look. Please run `make dt_binding_check` (see > >>> > >>> I run "make dt_binding_check" on kernel 6.6. > >> > >> Yeah, we are no on kernel 6.6. You can run it also on kernel v4.1 - > >> still does not matter. > >> > >> Don't develop on ancient code because then you ask us to review same > >> broken stuff we already fixed. > > > > I test with Beaglebone black for testing, it is difficult to run the > > last vanille version. > > I did backport the spi-nor driver. > > As for "make dt_binding_check" on last kernel, it need to upgrade the tools, > > and I did not think it could change that much. > > > > Well, it is possible to build kernel on small embedded board, but that's > quite cumbersone, slow and inefficient, considering that it's just > easier to cross compile. But anyway, binding check does not even need > cross compilation. > > Sorry, the code is obviously wrong, there is no such thing as u32, so > you did not test it. I provided link which explains how to test it. You > must do it on latest mainline kernel. Just like you must develop and > generate patches on latest mainline kernel, because this is where we > apply the patches. We do not apply them to v6.6. The patches are based on the lastest mainline kernel. I do not understand why you think otherwise. I will run the "make dt_binding_check" on the mainline kernel. Thanks for your feedback. Erez > > Best regards, > Krzysztof >
On 17/09/2024 19:24, Erez wrote: >>>>>> >>>>>> It does not look like you tested the bindings, at least after quick >>>>>> look. Please run `make dt_binding_check` (see >>>>> >>>>> I run "make dt_binding_check" on kernel 6.6. >>>> >>>> Yeah, we are no on kernel 6.6. You can run it also on kernel v4.1 - >>>> still does not matter. >>>> >>>> Don't develop on ancient code because then you ask us to review same >>>> broken stuff we already fixed. >>> >>> I test with Beaglebone black for testing, it is difficult to run the >>> last vanille version. >>> I did backport the spi-nor driver. >>> As for "make dt_binding_check" on last kernel, it need to upgrade the tools, >>> and I did not think it could change that much. >>> >> >> Well, it is possible to build kernel on small embedded board, but that's >> quite cumbersone, slow and inefficient, considering that it's just >> easier to cross compile. But anyway, binding check does not even need >> cross compilation. >> >> Sorry, the code is obviously wrong, there is no such thing as u32, so >> you did not test it. I provided link which explains how to test it. You >> must do it on latest mainline kernel. Just like you must develop and >> generate patches on latest mainline kernel, because this is where we >> apply the patches. We do not apply them to v6.6. > > The patches are based on the lastest mainline kernel. > I do not understand why you think otherwise. Because you wrote: "I run "make dt_binding_check" on kernel 6.6." The command is either part of build process or final check process (static analyzers etc). If you say you did this on v6.6, you got such response. Best regards, Krzysztof
On Tue, 17 Sept 2024 at 19:32, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 17/09/2024 19:24, Erez wrote:
> >>>>>>
> >>>>>> It does not look like you tested the bindings, at least after quick
> >>>>>> look. Please run `make dt_binding_check` (see
> >>>>>
> >>>>> I run "make dt_binding_check" on kernel 6.6.
> >>>>
> >>>> Yeah, we are no on kernel 6.6. You can run it also on kernel v4.1 -
> >>>> still does not matter.
> >>>>
> >>>> Don't develop on ancient code because then you ask us to review same
> >>>> broken stuff we already fixed.
> >>>
> >>> I test with Beaglebone black for testing, it is difficult to run the
> >>> last vanille version.
> >>> I did backport the spi-nor driver.
> >>> As for "make dt_binding_check" on last kernel, it need to upgrade the tools,
> >>> and I did not think it could change that much.
> >>>
> >>
> >> Well, it is possible to build kernel on small embedded board, but that's
> >> quite cumbersone, slow and inefficient, considering that it's just
> >> easier to cross compile. But anyway, binding check does not even need
> >> cross compilation.
> >>
> >> Sorry, the code is obviously wrong, there is no such thing as u32, so
> >> you did not test it. I provided link which explains how to test it. You
> >> must do it on latest mainline kernel. Just like you must develop and
> >> generate patches on latest mainline kernel, because this is where we
> >> apply the patches. We do not apply them to v6.6.
> >
> > The patches are based on the lastest mainline kernel.
> > I do not understand why you think otherwise.
>
> Because you wrote:
> "I run "make dt_binding_check" on kernel 6.6."
>
> The command is either part of build process or final check process
> (static analyzers etc). If you say you did this on v6.6, you got such
> response.
I know you are NOT a service.
The device tree is not the focus of my work.
It should not be broken like that.
I install dt-schema_2023.11-3_all.deb
with Debian trixie
I get:
l
SCHEMA Documentation/devicetree/bindings/processed-schema.json
Traceback (most recent call last):
File "/usr/bin/dt-mk-schema", line 8, in <module>
sys.exit(main())
^^^^^^
File "/usr/lib/python3/dist-packages/dtschema/mk_schema.py", line 28, in main
schemas = dtschema.DTValidator(args.schemas).schemas
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/dtschema/validator.py", line
363, in __init__
self.make_property_type_cache()
File "/usr/lib/python3/dist-packages/dtschema/validator.py", line
420, in make_property_type_cache
self.props, self.pat_props = get_prop_types(self.schemas)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/dtschema/validator.py", line
187, in get_prop_types
del props[r'^[a-z][a-z0-9\-]*$']
~~~~~^^^^^^^^^^^^^^^^^^^^^^^
KeyError: '^[a-z][a-z0-9\\-]*$'
make[2]: *** [Documentation/devicetree/bindings/Makefile:64:
Documentation/devicetree/bindings/processed-schema.json] Error 1
make[2]: *** Deleting file
'Documentation/devicetree/bindings/processed-schema.json'
make[1]: *** [/home/builder/kernel/Makefile:1435: dt_binding_schemas] Error 2
Erez
>
> Best regards,
> Krzysztof
>
On Tue, Sep 17, 2024 at 08:39:48PM +0200, Erez wrote: > On Tue, 17 Sept 2024 at 19:32, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > On 17/09/2024 19:24, Erez wrote: > > >>>>>> > > >>>>>> It does not look like you tested the bindings, at least after quick > > >>>>>> look. Please run `make dt_binding_check` (see > > >>>>> > > >>>>> I run "make dt_binding_check" on kernel 6.6. > > >>>> > > >>>> Yeah, we are no on kernel 6.6. You can run it also on kernel v4.1 - > > >>>> still does not matter. > > >>>> > > >>>> Don't develop on ancient code because then you ask us to review same > > >>>> broken stuff we already fixed. > > >>> > > >>> I test with Beaglebone black for testing, it is difficult to run the > > >>> last vanille version. > > >>> I did backport the spi-nor driver. > > >>> As for "make dt_binding_check" on last kernel, it need to upgrade the tools, > > >>> and I did not think it could change that much. > > >>> > > >> > > >> Well, it is possible to build kernel on small embedded board, but that's > > >> quite cumbersone, slow and inefficient, considering that it's just > > >> easier to cross compile. But anyway, binding check does not even need > > >> cross compilation. > > >> > > >> Sorry, the code is obviously wrong, there is no such thing as u32, so > > >> you did not test it. I provided link which explains how to test it. You > > >> must do it on latest mainline kernel. Just like you must develop and > > >> generate patches on latest mainline kernel, because this is where we > > >> apply the patches. We do not apply them to v6.6. > > > > > > The patches are based on the lastest mainline kernel. > > > I do not understand why you think otherwise. > > > > Because you wrote: > > "I run "make dt_binding_check" on kernel 6.6." > > > > The command is either part of build process or final check process > > (static analyzers etc). If you say you did this on v6.6, you got such > > response. > > I know you are NOT a service. > The device tree is not the focus of my work. > It should not be broken like that. > > I install dt-schema_2023.11-3_all.deb > with Debian trixie > I get: > > l > SCHEMA Documentation/devicetree/bindings/processed-schema.json > Traceback (most recent call last): > File "/usr/bin/dt-mk-schema", line 8, in <module> > sys.exit(main()) > ^^^^^^ > File "/usr/lib/python3/dist-packages/dtschema/mk_schema.py", line 28, in main > schemas = dtschema.DTValidator(args.schemas).schemas > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > File "/usr/lib/python3/dist-packages/dtschema/validator.py", line > 363, in __init__ > self.make_property_type_cache() > File "/usr/lib/python3/dist-packages/dtschema/validator.py", line > 420, in make_property_type_cache > self.props, self.pat_props = get_prop_types(self.schemas) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > File "/usr/lib/python3/dist-packages/dtschema/validator.py", line > 187, in get_prop_types > del props[r'^[a-z][a-z0-9\-]*$'] > ~~~~~^^^^^^^^^^^^^^^^^^^^^^^ > KeyError: '^[a-z][a-z0-9\\-]*$' > make[2]: *** [Documentation/devicetree/bindings/Makefile:64: > Documentation/devicetree/bindings/processed-schema.json] Error 1 > make[2]: *** Deleting file > 'Documentation/devicetree/bindings/processed-schema.json' > make[1]: *** [/home/builder/kernel/Makefile:1435: dt_binding_schemas] Error 2 Have you considered that this might be because of the invalid types you used?
On Tue, 17 Sept 2024 at 22:39, Conor Dooley <conor@kernel.org> wrote: > > On Tue, Sep 17, 2024 at 08:39:48PM +0200, Erez wrote: > > On Tue, 17 Sept 2024 at 19:32, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > > > On 17/09/2024 19:24, Erez wrote: > > > >>>>>> > > > >>>>>> It does not look like you tested the bindings, at least after quick > > > >>>>>> look. Please run `make dt_binding_check` (see > > > >>>>> > > > >>>>> I run "make dt_binding_check" on kernel 6.6. > > > >>>> > > > >>>> Yeah, we are no on kernel 6.6. You can run it also on kernel v4.1 - > > > >>>> still does not matter. > > > >>>> > > > >>>> Don't develop on ancient code because then you ask us to review same > > > >>>> broken stuff we already fixed. > > > >>> > > > >>> I test with Beaglebone black for testing, it is difficult to run the > > > >>> last vanille version. > > > >>> I did backport the spi-nor driver. > > > >>> As for "make dt_binding_check" on last kernel, it need to upgrade the tools, > > > >>> and I did not think it could change that much. > > > >>> > > > >> > > > >> Well, it is possible to build kernel on small embedded board, but that's > > > >> quite cumbersone, slow and inefficient, considering that it's just > > > >> easier to cross compile. But anyway, binding check does not even need > > > >> cross compilation. > > > >> > > > >> Sorry, the code is obviously wrong, there is no such thing as u32, so > > > >> you did not test it. I provided link which explains how to test it. You > > > >> must do it on latest mainline kernel. Just like you must develop and > > > >> generate patches on latest mainline kernel, because this is where we > > > >> apply the patches. We do not apply them to v6.6. > > > > > > > > The patches are based on the lastest mainline kernel. > > > > I do not understand why you think otherwise. > > > > > > Because you wrote: > > > "I run "make dt_binding_check" on kernel 6.6." > > > > > > The command is either part of build process or final check process > > > (static analyzers etc). If you say you did this on v6.6, you got such > > > response. > > > > I know you are NOT a service. > > The device tree is not the focus of my work. > > It should not be broken like that. > > > > I install dt-schema_2023.11-3_all.deb > > with Debian trixie > > I get: > > > > l > > SCHEMA Documentation/devicetree/bindings/processed-schema.json > > Traceback (most recent call last): > > File "/usr/bin/dt-mk-schema", line 8, in <module> > > sys.exit(main()) > > ^^^^^^ > > File "/usr/lib/python3/dist-packages/dtschema/mk_schema.py", line 28, in main > > schemas = dtschema.DTValidator(args.schemas).schemas > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > File "/usr/lib/python3/dist-packages/dtschema/validator.py", line > > 363, in __init__ > > self.make_property_type_cache() > > File "/usr/lib/python3/dist-packages/dtschema/validator.py", line > > 420, in make_property_type_cache > > self.props, self.pat_props = get_prop_types(self.schemas) > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > File "/usr/lib/python3/dist-packages/dtschema/validator.py", line > > 187, in get_prop_types > > del props[r'^[a-z][a-z0-9\-]*$'] > > ~~~~~^^^^^^^^^^^^^^^^^^^^^^^ > > KeyError: '^[a-z][a-z0-9\\-]*$' > > make[2]: *** [Documentation/devicetree/bindings/Makefile:64: > > Documentation/devicetree/bindings/processed-schema.json] Error 1 > > make[2]: *** Deleting file > > 'Documentation/devicetree/bindings/processed-schema.json' > > make[1]: *** [/home/builder/kernel/Makefile:1435: dt_binding_schemas] Error 2 > > Have you considered that this might be because of the invalid types you > used? I remove the types. Anyway, scripts should report on errors, not crash. This is the purpose of syntax scripts, to help us, developers find out errors. Erez :-)
On 17/09/2024 23:29, Erez wrote: >>> >>> I install dt-schema_2023.11-3_all.deb >>> with Debian trixie >>> I get: >>> >>> l >>> SCHEMA Documentation/devicetree/bindings/processed-schema.json >>> Traceback (most recent call last): >>> File "/usr/bin/dt-mk-schema", line 8, in <module> >>> sys.exit(main()) >>> ^^^^^^ >>> File "/usr/lib/python3/dist-packages/dtschema/mk_schema.py", line 28, in main >>> schemas = dtschema.DTValidator(args.schemas).schemas >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> File "/usr/lib/python3/dist-packages/dtschema/validator.py", line >>> 363, in __init__ >>> self.make_property_type_cache() >>> File "/usr/lib/python3/dist-packages/dtschema/validator.py", line >>> 420, in make_property_type_cache >>> self.props, self.pat_props = get_prop_types(self.schemas) >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> File "/usr/lib/python3/dist-packages/dtschema/validator.py", line >>> 187, in get_prop_types >>> del props[r'^[a-z][a-z0-9\-]*$'] >>> ~~~~~^^^^^^^^^^^^^^^^^^^^^^^ >>> KeyError: '^[a-z][a-z0-9\\-]*$' >>> make[2]: *** [Documentation/devicetree/bindings/Makefile:64: >>> Documentation/devicetree/bindings/processed-schema.json] Error 1 >>> make[2]: *** Deleting file >>> 'Documentation/devicetree/bindings/processed-schema.json' >>> make[1]: *** [/home/builder/kernel/Makefile:1435: dt_binding_schemas] Error 2 >> >> Have you considered that this might be because of the invalid types you >> used? > > I remove the types. > Anyway, scripts should report on errors, not crash. > This is the purpose of syntax scripts, to help us, developers find out errors. Yeah, things can be improved. Help in that is always welcomed. The package you installed is very old (almost a year old!). I suggest using pip or pipx (or virtualenv or whatever Python setup you have). Best regards, Krzysztof
On Wed, 18 Sept 2024 at 10:23, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On 17/09/2024 23:29, Erez wrote: > >>> > >>> I install dt-schema_2023.11-3_all.deb > >>> with Debian trixie > >>> I get: > >>> > >>> l > >>> SCHEMA Documentation/devicetree/bindings/processed-schema.json > >>> Traceback (most recent call last): > >>> File "/usr/bin/dt-mk-schema", line 8, in <module> > >>> sys.exit(main()) > >>> ^^^^^^ > >>> File "/usr/lib/python3/dist-packages/dtschema/mk_schema.py", line 28, in main > >>> schemas = dtschema.DTValidator(args.schemas).schemas > >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>> File "/usr/lib/python3/dist-packages/dtschema/validator.py", line > >>> 363, in __init__ > >>> self.make_property_type_cache() > >>> File "/usr/lib/python3/dist-packages/dtschema/validator.py", line > >>> 420, in make_property_type_cache > >>> self.props, self.pat_props = get_prop_types(self.schemas) > >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>> File "/usr/lib/python3/dist-packages/dtschema/validator.py", line > >>> 187, in get_prop_types > >>> del props[r'^[a-z][a-z0-9\-]*$'] > >>> ~~~~~^^^^^^^^^^^^^^^^^^^^^^^ > >>> KeyError: '^[a-z][a-z0-9\\-]*$' > >>> make[2]: *** [Documentation/devicetree/bindings/Makefile:64: > >>> Documentation/devicetree/bindings/processed-schema.json] Error 1 > >>> make[2]: *** Deleting file > >>> 'Documentation/devicetree/bindings/processed-schema.json' > >>> make[1]: *** [/home/builder/kernel/Makefile:1435: dt_binding_schemas] Error 2 > >> > >> Have you considered that this might be because of the invalid types you > >> used? > > > > I remove the types. > > Anyway, scripts should report on errors, not crash. > > This is the purpose of syntax scripts, to help us, developers find out errors. > > Yeah, things can be improved. Help in that is always welcomed. > > The package you installed is very old (almost a year old!). I suggest Debian tend to be old and stable (althguh this packages comes from sid). > using pip or pipx (or virtualenv or whatever Python setup you have). I'll try. Though I am not a python developer. I usually do not use pip. I did see a version checking: $ make dt_binding_check sort: -:2: disorder: 2022.08.2 ERROR: dtschema minimum version is v2023.9 Thanks Erez > > Best regards, > Krzysztof >
On Tue, 17 Sept 2024 at 11:50, Erez Geva <erezgeva@nwtime.org> wrote: > > From: Erez Geva <ErezGeva2@gmail.com> > > Some flash devices need OTP parameters in device tree. > As we can not deduce the parameters based on JEDEC ID or SFDP. > > Signed-off-by: Erez Geva <ErezGeva2@gmail.com> > --- > .../bindings/mtd/jedec,spi-nor.yaml | 37 +++++++++++++++++++ > 1 file changed, 37 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > index 6e3afb42926e..d502b7fab2ce 100644 > --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > @@ -90,6 +90,43 @@ properties: > the SRWD bit while writing the status register. WP# signal hard strapped to GND > can be a valid use case. > > + opt_n_regions: > + type: u32 > + description: > + Some flash devices need OTP parameters in the device tree. > + As we can not deduce the parameters based on JEDEC ID or SFDP. > + This parameter indicates the number of OTP regions. > + The value must be larger than 1 and mandatory for OTP. Sorry: "The value must be larger or equal to 1 and mandatory for OTP. " > + > + otp_len: > + type: u32 > + description: > + Some flash devices need OTP parameters in the device tree. > + As we can not deduce the parameters based on JEDEC ID or SFDP. > + This parameter indicates the size (length) in bytes of an OTP region. > + Currently the driver supports symmetric OTP, > + which means all regions must use the same size. > + The value must be positive and mandatory for OTP. > + > + otp_offset: > + type: u32 > + description: > + Some flash devices need OTP parameters in the device tree. > + As we can not deduce the parameters based on JEDEC ID or SFDP. > + This parameter indicates the offset in bytes of > + an OTP region relative to its previous. > + User can omit it if the offset equals the length. > + Or in case we have a single OTP region. > + > + otp_base: > + type: u32 > + description: > + Some flash devices need OTP parameters in the device tree. > + As we can not deduce the parameters based on JEDEC ID or SFDP. > + This parameter indicates the base in bytes of the first OTP region. > + User can omit it if the base is zero. > + I.e. the address of the first OTP region starts from 0. > + > reset-gpios: > description: > A GPIO line connected to the RESET (active low) signal of the device. > -- > 2.39.5 >
© 2016 - 2024 Red Hat, Inc.