| 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
| ||
|
Date: Mon, 15 Jan 2024 10:52:36 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Yoshinori Sato <ysato@...rs.sourceforge.jp>
Cc: linux-sh@...r.kernel.org, Damien Le Moal <dlemoal@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
Thomas Gleixner <tglx@...utronix.de>, Lorenzo Pieralisi <lpieralisi@...nel.org>,
Krzysztof Wilczyński <kw@...ux.com>,
Bjorn Helgaas <bhelgaas@...gle.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jirislaby@...nel.org>, Magnus Damm <magnus.damm@...il.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>, Rich Felker <dalias@...c.org>,
John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, Lee Jones <lee@...nel.org>,
Helge Deller <deller@....de>, Heiko Stuebner <heiko@...ech.de>,
Jernej Skrabec <jernej.skrabec@...il.com>, Chris Morgan <macromorgan@...mail.com>,
Yang Xiwen <forbidden405@...mail.com>, Sebastian Reichel <sre@...nel.org>,
Linus Walleij <linus.walleij@...aro.org>, Randy Dunlap <rdunlap@...radead.org>,
Arnd Bergmann <arnd@...db.de>, Vlastimil Babka <vbabka@...e.cz>, Hyeonggon Yoo <42.hyeyoo@...il.com>,
David Rientjes <rientjes@...gle.com>, Baoquan He <bhe@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>, Guenter Roeck <linux@...ck-us.net>,
Stephen Rothwell <sfr@...b.auug.org.au>, Azeem Shaikh <azeemshaikh38@...il.com>,
Javier Martinez Canillas <javierm@...hat.com>, Max Filippov <jcmvbkbc@...il.com>,
Palmer Dabbelt <palmer@...osinc.com>, Bin Meng <bmeng@...ylab.org>,
Jonathan Corbet <corbet@....net>, Jacky Huang <ychuang3@...oton.com>,
Lukas Bulwahn <lukas.bulwahn@...il.com>, Biju Das <biju.das.jz@...renesas.com>,
Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
Sam Ravnborg <sam@...nborg.org>, Sergey Shtylyov <s.shtylyov@....ru>,
Michael Karcher <kernel@...rcher.dialup.fu-berlin.de>,
Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>, linux-ide@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-renesas-soc@...r.kernel.org, linux-clk@...r.kernel.org,
dri-devel@...ts.freedesktop.org, linux-pci@...r.kernel.org,
linux-serial@...r.kernel.org, linux-fbdev@...r.kernel.org
Subject: Re: [DO NOT MERGE v6 22/37] dt-bindings: display: smi,sm501: SMI
SM501 binding json-schema
Hi Sato-san,
On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
<ysato@...rs.sourceforge.jp> wrote:
> Signed-off-by: Yoshinori Sato <ysato@...rs.sourceforge.jp>
Thanks for your patch!
> ---
> .../bindings/display/smi,sm501.yaml | 417 ++++++++++++++++++
> 1 file changed, 417 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/smi,sm501.yaml
Surely Documentation/devicetree/bindings/display/sm501fb.txt should
be removed, too?
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/smi,sm501.yaml
> + crt:
> + type: object
> + description: CRT output control
> + properties:
> + edid:
> + $ref: /schemas/types.yaml#/definitions/uint8-array
> + description: |
> + verbatim EDID data block describing attached display.
> + Data from the detailed timing descriptor will be used to
> + program the display controller.
> +
> + smi,flags:
> + $ref: /schemas/types.yaml#/definitions/string-array
> + description: Display control flags.
> + items:
> + anyOf:
> + - const: use-init-done
> + - const: disable-at-exit
> + - const: use-hwcursor
> + - const: use-hwaccel
The "use-*" flags look like software policy, not hardware description,
and thus do not belong in DT?
> + - const: panel-no-fpen
> + - const: panel-no-vbiasen
> + - const: panel-inv-fpen
> + - const: panel-inv-vbiasen
> + maxItems: 8
> +
> + bpp:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: Color depth
> +
> + panel:
> + type: object
> + description: Panel output control
> + properties:
> + edid:
> + $ref: /schemas/types.yaml#/definitions/uint8-array
> + description: |
> + verbatim EDID data block describing attached display.
> + Data from the detailed timing descriptor will be used to
> + program the display controller.
> +
> + smi,flags:
> + $ref: /schemas/types.yaml#/definitions/string-array
> + description: Display control flags.
> + items:
> + anyOf:
> + - const: use-init-done
> + - const: disable-at-exit
> + - const: use-hwcursor
> + - const: use-hwaccel
The "use-*" flags look like software policy, not hardware description,
and thus do not belong in DT?
> + - const: panel-no-fpen
> + - const: panel-no-vbiasen
> + - const: panel-inv-fpen
> + - const: panel-inv-vbiasen
> + maxItems: 8
> +
> + bpp:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: Color depth
> +
> + smi,devices:
> + $ref: /schemas/types.yaml#/definitions/string-array
> + description: Select SM501 device functions.
> + items:
> + anyOf:
> + - const: usb-host
> + - const: usb-slave
> + - const: ssp0
> + - const: ssp1
> + - const: uart0
> + - const: uart1
> + - const: fbaccel
> + - const: ac97
> + - const: i2s
> + - const: gpio
> + minItems: 1
> + maxItems: 10
I think it would be better to have individual subnodes for the sub devices,
with status = "ok"/"disabled".
If you go that route, you do need some fallback code to handle the lack
of subnodes in the existing user in arch/powerpc/boot/dts/charon.dts.
BTW, why can sm501_pci_initdata get away with setting ".devices
= SM501_USE_ALL"? Or, would it hurt to enable all subdevices
unconditionally?
> +
> + smi,mclk:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: mclk frequency.
> +
> + smi,m1xclk:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: m1xclk frequency.
These two should be clock specifiers (i.e. phandles pointing to clock
nodes + optional clock indices).
> +
> + misc-timing:
> + type: object
> + description: Miscellaneous Timing register values.
> + properties:
> + ex:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: Extend bus holding time.
> + enum: [0, 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, 240]
> +
> + xc:
> + $ref: /schemas/types.yaml#/definitions/string
> + description: Xscale clock input select.
> + items:
> + enum:
> + - internal-pll
> + - hclk
> + - gpio33
Software policy instead of hardware description again?
I am not familiar with how the SM501 works, so I cannot comment on
the other properties, but several of them look like they need rework.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68korg
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists