| 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
| ||
|
Message-ID: <20240607144154.GD18479@pendragon.ideasonboard.com>
Date: Fri, 7 Jun 2024 17:41:54 +0300
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Julien Stephan <jstephan@...libre.com>,
Louis Kuo <louis.kuo@...iatek.com>,
Phi-Bang Nguyen <pnguyen@...libre.com>,
Andy Hsieh <andy.hsieh@...iatek.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Conor Dooley <conor+dt@...nel.org>, devicetree@...r.kernel.org,
Florian Sylvestre <fsylvestre@...libre.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-mediatek@...ts.infradead.org, linux-media@...r.kernel.org,
Matthias Brugger <matthias.bgg@...il.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Paul Elder <paul.elder@...asonboard.com>,
Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH v4 1/5] dt-bindings: media: add mediatek ISP3.0 sensor
interface
Hi Krzysztof,
On Fri, Jun 07, 2024 at 10:52:33AM +0200, Julien Stephan wrote:
> Le ven. 12 janv. 2024 à 08:32, Krzysztof Kozlowski a écrit :
> > On 10/01/2024 15:14, Julien Stephan wrote:
> > > From: Louis Kuo <louis.kuo@...iatek.com>
> > >
> > > This adds the bindings, for the mediatek ISP3.0 SENINF module embedded in
> > > some Mediatek SoC, such as the mt8365
> > >
> >
> > ...
> >
> > > + clock-names:
> > > + items:
> > > + - const: camsys
> > > + - const: top_mux
> > > +
> > > + phys:
> > > + minItems: 1
> > > + maxItems: 4
> > > + description:
> > > + phandle to the PHYs connected to CSI0/A, CSI1, CSI2 and CSI0B
> > > +
> > > + phy-names:
> > > + minItems: 1
> > > + items:
> > > + - const: csi0
> > > + - const: csi1
> > > + - const: csi2
> > > + - const: csi0b
> >
> > Why one hardware has flexible number of phys?
>
> Hi Krzysztof,
>
> seninf can have multiple port depending on the soc, each requiring its own phy
>
> > > +
> > > + ports:
> > > + $ref: /schemas/graph.yaml#/properties/ports
> > > +
> > > + properties:
> > > + port@0:
> > > + $ref: /schemas/graph.yaml#/$defs/port-base
> > > + unevaluatedProperties: false
> > > + description: CSI0 or CSI0A port
> > > +
> > > + properties:
> > > + endpoint:
> > > + $ref: video-interfaces.yaml#
> > > + unevaluatedProperties: false
> > > +
> > > + properties:
> > > + clock-lanes:
> > > + maxItems: 1
> > > + data-lanes:
> > > + minItems: 1
> > > + maxItems: 4
> > > +
> > > + port@1:
> > > + $ref: /schemas/graph.yaml#/$defs/port-base
> > > + unevaluatedProperties: false
> > > + description: CSI1 port
> > > +
> > > + properties:
> > > + endpoint:
> > > + $ref: video-interfaces.yaml#
> > > + unevaluatedProperties: false
> > > +
> > > + properties:
> > > + clock-lanes:
> > > + maxItems: 1
> > > + data-lanes:
> > > + minItems: 1
> > > + maxItems: 4
> > > +
> > > + port@2:
> > > + $ref: /schemas/graph.yaml#/$defs/port-base
> > > + unevaluatedProperties: false
> > > + description: CSI2 port
> > > +
> > > + properties:
> > > + endpoint:
> > > + $ref: video-interfaces.yaml#
> > > + unevaluatedProperties: false
> > > +
> > > + properties:
> > > + clock-lanes:
> > > + maxItems: 1
> > > + data-lanes:
> > > + minItems: 1
> > > + maxItems: 4
> > > +
> > > + port@3:
> > > + $ref: /schemas/graph.yaml#/$defs/port-base
> > > + unevaluatedProperties: false
> > > + description: CSI0B port
> > > +
> > > + properties:
> > > + endpoint:
> > > + $ref: video-interfaces.yaml#
> > > + unevaluatedProperties: false
> > > +
> > > + properties:
> > > + clock-lanes:
> > > + maxItems: 1
> > > + data-lanes:
> > > + minItems: 1
> > > + maxItems: 2
> > > +
> > > + port@4:
> > > + $ref: /schemas/graph.yaml#/properties/port
> > > + description: connection point for cam0
> > > +
> > > + port@5:
> > > + $ref: /schemas/graph.yaml#/properties/port
> > > + description: connection point for cam1
> > > +
> > > + port@6:
> > > + $ref: /schemas/graph.yaml#/properties/port
> > > + description: connection point for camsv0
> > > +
> > > + port@7:
> > > + $ref: /schemas/graph.yaml#/properties/port
> > > + description: connection point for camsv1
> > > +
> > > + port@8:
> > > + $ref: /schemas/graph.yaml#/properties/port
> > > + description: connection point for camsv2
> > > +
> > > + port@9:
> > > + $ref: /schemas/graph.yaml#/properties/port
> > > + description: connection point for camsv3
> > > +
> > > + required:
> > > + - port@0
> > > + - port@1
> > > + - port@2
> > > + - port@3
> > > + - port@4
> > > + - port@5
> > > + - port@6
> > > + - port@7
> > > + - port@8
> > > + - port@9
> > > +
> > > +required:
> > > + - compatible
> > > + - interrupts
> > > + - clocks
> > > + - clock-names
> > > + - power-domains
> > > + - ports
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > + #include <dt-bindings/clock/mediatek,mt8365-clk.h>
> > > + #include <dt-bindings/interrupt-controller/irq.h>
> > > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > > + #include <dt-bindings/phy/phy.h>
> > > + #include <dt-bindings/power/mediatek,mt8365-power.h>
> > > +
> > > + soc {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> >
> > Use 4 spaces for example indentation.
> >
> > > +
> > > + seninf: seninf@...40000 {
> >
> > Node names should be generic. See also an explanation and list of
> > examples (not exhaustive) in DT specification:
> > https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
The seninf is (mostly) a set of MIPI CSI-2 receivers. Would you prefer
'csi', 'mipi-csi', 'csi-2' or any other name ?
There's also the camsv IP in the same series that needs a generic name.
I really don't know what to propose for it. Could you recommend
something that would make you happy ?
On a side note, that document lacks appropriate generic names for lots
of building blocks found in recent SoCs, it would be nice to get it
updated. You will eventually get better quality DT patches then :-)
> > > + compatible = "mediatek,mt8365-seninf";
> > > + reg = <0 0x15040000 0 0x6000>;
> > > + interrupts = <GIC_SPI 210 IRQ_TYPE_LEVEL_LOW>;
> > > + clocks = <&camsys CLK_CAM_SENIF>,
> > > + <&topckgen CLK_TOP_SENIF_SEL>;
> > > + clock-names = "camsys", "top_mux";
> > > +
> > > + power-domains = <&spm MT8365_POWER_DOMAIN_CAM>;
> > > +
> > > + phys = <&mipi_csi0 PHY_TYPE_DPHY>;
> > > + phy-names = "csi0";
> > > +
> > > + ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + port@0 {
> > > + reg = <0>;
> > > + seninf_in1: endpoint {
> > > + clock-lanes = <2>;
> > > + data-lanes = <1 3 0 4>;
> > > + remote-endpoint = <&isp1_out>;
> > > + };
> > > + };
> > > +
> > > + port@1 {
> > > + reg = <1>;
> > > + };
> > > +
> > > + port@2 {
> > > + reg = <2>;
> > > + };
> > > +
> > > + port@3 {
> > > + reg = <3>;
> > > + };
> > > +
> > > + port@4 {
> > > + reg = <4>;
> > > + seninf_camsv1_endpoint: endpoint {
> > > + remote-endpoint = <&camsv1_endpoint>;
> > > + };
> > > + };
> > > +
> > > + port@5 {
> > > + reg = <5>;
> > > + };
> > > +
> > > + port@6 {
> > > + reg = <6>;
> > > + };
> > > +
> > > + port@7 {
> > > + reg = <7>;
> > > + };
> > > +
> > > + port@8 {
> > > + reg = <8>;
> > > + };
> > > +
> > > + port@9 {
> > > + reg = <9>;
> > > + };
> > > +
> >
> > Stray blank line
> >
> > > + };
--
Regards,
Laurent Pinchart
Powered by blists - more mailing lists