lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OS0PR01MB5922969554D0FA70D2F323D886BE9@OS0PR01MB5922.jpnprd01.prod.outlook.com>
Date:   Mon, 4 Jul 2022 09:26:28 +0000
From:   Biju Das <biju.das.jz@...renesas.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Wolfgang Grandegger <wg@...ndegger.com>,
        Marc Kleine-Budde <mkl@...gutronix.de>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>
CC:     "linux-can@...r.kernel.org" <linux-can@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Chris Paterson <Chris.Paterson2@...esas.com>,
        Biju Das <biju.das@...renesas.com>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>
Subject: RE: [PATCH v3 1/6] dt-bindings: can: sja1000: Convert to json-schema

Hi Krzysztof,

Thanks for the feedback.

> Subject: Re: [PATCH v3 1/6] dt-bindings: can: sja1000: Convert to json-
> schema
> 
> On 04/07/2022 11:03, Biju Das wrote:
> > Hi Krystof,
> >
> > Thanks for the feedback.
> >
> >> Subject: Re: [PATCH v3 1/6] dt-bindings: can: sja1000: Convert to
> >> json- schema
> >>
> >> On 04/07/2022 09:50, Biju Das wrote:
> >>> Convert the NXP SJA1000 CAN Controller Device Tree binding
> >>> documentation to json-schema.
> >>>
> >>> Update the example to match reality.
> >>>
> >>> Signed-off-by: Biju Das <biju.das.jz@...renesas.com>
> >>> ---
> >>> v2->v3:
> >>>  * Added reg-io-width is a required property for technologic,sja1000
> >>>  * Removed enum type from nxp,tx-output-config and updated the
> >> description
> >>>    for combination of TX0 and TX1.
> >>>  * Updated the example
> >>> v1->v2:
> >>>  * Moved $ref: can-controller.yaml# to top along with if conditional
> >>> to
> >>>    avoid multiple mapping issues with the if conditional in the
> >> subsequent
> >>>    patch.
> >>> ---
> >>>  .../bindings/net/can/nxp,sja1000.yaml         | 103
> ++++++++++++++++++
> >>>  .../devicetree/bindings/net/can/sja1000.txt   |  58 ----------
> >>>  2 files changed, 103 insertions(+), 58 deletions(-)  create mode
> >>> 100644 Documentation/devicetree/bindings/net/can/nxp,sja1000.yaml
> >>>  delete mode 100644
> >>> Documentation/devicetree/bindings/net/can/sja1000.txt
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/net/can/nxp,sja1000.yaml
> >>> b/Documentation/devicetree/bindings/net/can/nxp,sja1000.yaml
> >>> new file mode 100644
> >>> index 000000000000..d34060226e4e
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/net/can/nxp,sja1000.yaml
> >>> @@ -0,0 +1,103 @@
> >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> >>> +---
> >>> +$id:
> >>> +
> >>> +title: Memory mapped SJA1000 CAN controller from NXP (formerly
> >>> +Philips)
> >>> +
> >>> +maintainers:
> >>> +  - Wolfgang Grandegger <wg@...ndegger.com>
> >>> +
> >>> +allOf:
> >>> +  - $ref: can-controller.yaml#
> >>> +  - if:
> >>
> >> The advice of moving it up was not correct. The allOf containing ref
> >> and if:then goes to place like in example-schema, so before
> >> additional/unevaluatedProperties at the bottom.
> >>
> >> Please do not introduce some inconsistent style.
> >
> > There are some examples like[1], where allOf is at the top.
> > [1]
=Mw4Fhkri5BLK1Cqg8Wd1EKkbe0xDg%2Fnbl0JSd5j6Kmo%3D&amp;reser
> > ved=0
> 
> And they are wrong. There is always some incorrect code in the kernel,
> but that's not argument to do it in incorrect way. The coding style is
> here expressed in example-schema, so use this as an argument.

OK. Will stick to example-schema as coding style.

Cheers,
Biju

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ