From: Laurent Pinchart <laurent.pinchart@ideasonboard.com> To: yuji2.ishikawa@toshiba.co.jp Cc: krzysztof.kozlowski@linaro.org, hverkuil@xs4all.nl, mchehab@kernel.org, nobuhiro1.iwamatsu@toshiba.co.jp, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, rafael.j.wysocki@intel.com, broonie@kernel.org, linux-media@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v5 1/6] dt-bindings: media: platform: visconti: Add Toshiba Visconti Video Input Interface bindings Date: Wed, 1 Feb 2023 11:45:57 +0200 [thread overview] Message-ID: <Y9o01ctDujKRXw2J@pendragon.ideasonboard.com> (raw) In-Reply-To: <TYAPR01MB6201BCC60149D17F59AD870E92D39@TYAPR01MB6201.jpnprd01.prod.outlook.com> On Mon, Jan 30, 2023 at 09:06:25AM +0000, yuji2.ishikawa@toshiba.co.jp wrote: > On Monday, January 23, 2023 4:26 AM, Laurent Pinchart wrote: > > On Tue, Jan 17, 2023 at 06:01:27PM +0100, Krzysztof Kozlowski wrote: > > > On 17/01/2023 16:58, Laurent Pinchart wrote: > > > > On Tue, Jan 17, 2023 at 04:42:51PM +0100, Krzysztof Kozlowski wrote: > > > >> On 17/01/2023 16:26, Laurent Pinchart wrote: > > > >>> > > > >>>> + > > > >>>> + clock-lanes: > > > >>>> + description: VIIF supports 1 clock line > > > >>> > > > >>> s/line/lane/ > > Sorry for a late reply. > I'll fix the description. > > > > >>> > > > >>>> + const: 0 > > > >>> > > > >>> I would also add > > > >>> > > > >>> clock-noncontinuous: true > > > >>> link-frequencies: true > > > >>> > > > >>> to indicate that the above two properties are used by this device. > > > >> > > > >> No, these are coming from other schema and there is never need to > > > >> mention some property to indicate it is more used than other case. > > > >> None of the bindings are created such way, so this should not be exception. > > > > > > > > There are some bindings that do so, but that may not be a good > > > > enough reason, as there's a chance I wrote those myself :-) > > > > > > > > I would have sworn that at some point in the past the schema > > > > wouldn't have validated the example with this omitted. I'm not sure > > > > if something changed or if I got this wrong. > > > > > > You probably think about case when using additionalProperties:false, > > > where one has to explicitly list all valid properties. But not for > > > unevaluatedProperties:false. > > > > Possibly, yes. > > > > > > video-interfaces.yaml defines lots of properties applicable to > > > > endpoints. For a given device, those properties should be required > > > > > > required: > > > - foo > > > > > > > (easy, that's defined in the bindings), optional, > > > > > > by default (with unevaluatedProperties:false) or explicitly mention > > > "foo: true (with additionalProperties:false) > > > > > > > or forbidden. How do > > > > > > foo: false (with unevaluatedProperties:false) or by default (with > > > additionalProperties:false) > > > > I think we should default to the latter. video-interfaces.yaml contains lots of > > properties endpoint properties, most bindings will use less than half of them, so > > having to explicitly list all the ones that are not used with "foo: false" would be > > quite inconvenient. Furthermore, I expect more properties to be added to > > video-interfaces.yaml over time, and those shouldn't be accepted by default in > > existing bindings. > > > > I caught up with this discussion after some exercise on JSON schema validator. > I'll remove "unevaluatedProperties: false" at the "endpoint" and add "aditionalProperties: false" instead. > Furthermore, I'll explicitly declare required properties (required: ["foo"]) and optional properties (properties: {foo: true}) for Visconti. > Is this correct understanding? Looks very good to me ! > Are these changes also applied to "port", which is the parent node of > the "endpoint" ? That shouldn't be needed, as the "port" node should only have "endpoint" children and no other properties (except for reg, and possibly #address-cells and #size-cells of course). > > > > we differentiate between the latter two cases ? -- Regards, Laurent Pinchart
WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com> To: yuji2.ishikawa@toshiba.co.jp Cc: krzysztof.kozlowski@linaro.org, hverkuil@xs4all.nl, mchehab@kernel.org, nobuhiro1.iwamatsu@toshiba.co.jp, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, rafael.j.wysocki@intel.com, broonie@kernel.org, linux-media@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v5 1/6] dt-bindings: media: platform: visconti: Add Toshiba Visconti Video Input Interface bindings Date: Wed, 1 Feb 2023 11:45:57 +0200 [thread overview] Message-ID: <Y9o01ctDujKRXw2J@pendragon.ideasonboard.com> (raw) In-Reply-To: <TYAPR01MB6201BCC60149D17F59AD870E92D39@TYAPR01MB6201.jpnprd01.prod.outlook.com> On Mon, Jan 30, 2023 at 09:06:25AM +0000, yuji2.ishikawa@toshiba.co.jp wrote: > On Monday, January 23, 2023 4:26 AM, Laurent Pinchart wrote: > > On Tue, Jan 17, 2023 at 06:01:27PM +0100, Krzysztof Kozlowski wrote: > > > On 17/01/2023 16:58, Laurent Pinchart wrote: > > > > On Tue, Jan 17, 2023 at 04:42:51PM +0100, Krzysztof Kozlowski wrote: > > > >> On 17/01/2023 16:26, Laurent Pinchart wrote: > > > >>> > > > >>>> + > > > >>>> + clock-lanes: > > > >>>> + description: VIIF supports 1 clock line > > > >>> > > > >>> s/line/lane/ > > Sorry for a late reply. > I'll fix the description. > > > > >>> > > > >>>> + const: 0 > > > >>> > > > >>> I would also add > > > >>> > > > >>> clock-noncontinuous: true > > > >>> link-frequencies: true > > > >>> > > > >>> to indicate that the above two properties are used by this device. > > > >> > > > >> No, these are coming from other schema and there is never need to > > > >> mention some property to indicate it is more used than other case. > > > >> None of the bindings are created such way, so this should not be exception. > > > > > > > > There are some bindings that do so, but that may not be a good > > > > enough reason, as there's a chance I wrote those myself :-) > > > > > > > > I would have sworn that at some point in the past the schema > > > > wouldn't have validated the example with this omitted. I'm not sure > > > > if something changed or if I got this wrong. > > > > > > You probably think about case when using additionalProperties:false, > > > where one has to explicitly list all valid properties. But not for > > > unevaluatedProperties:false. > > > > Possibly, yes. > > > > > > video-interfaces.yaml defines lots of properties applicable to > > > > endpoints. For a given device, those properties should be required > > > > > > required: > > > - foo > > > > > > > (easy, that's defined in the bindings), optional, > > > > > > by default (with unevaluatedProperties:false) or explicitly mention > > > "foo: true (with additionalProperties:false) > > > > > > > or forbidden. How do > > > > > > foo: false (with unevaluatedProperties:false) or by default (with > > > additionalProperties:false) > > > > I think we should default to the latter. video-interfaces.yaml contains lots of > > properties endpoint properties, most bindings will use less than half of them, so > > having to explicitly list all the ones that are not used with "foo: false" would be > > quite inconvenient. Furthermore, I expect more properties to be added to > > video-interfaces.yaml over time, and those shouldn't be accepted by default in > > existing bindings. > > > > I caught up with this discussion after some exercise on JSON schema validator. > I'll remove "unevaluatedProperties: false" at the "endpoint" and add "aditionalProperties: false" instead. > Furthermore, I'll explicitly declare required properties (required: ["foo"]) and optional properties (properties: {foo: true}) for Visconti. > Is this correct understanding? Looks very good to me ! > Are these changes also applied to "port", which is the parent node of > the "endpoint" ? That shouldn't be needed, as the "port" node should only have "endpoint" children and no other properties (except for reg, and possibly #address-cells and #size-cells of course). > > > > we differentiate between the latter two cases ? -- Regards, Laurent Pinchart _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-02-01 9:46 UTC|newest] Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-11 2:24 [PATCH v5 0/6] Add Toshiba Visconti Video Input Interface driver Yuji Ishikawa 2023-01-11 2:24 ` Yuji Ishikawa 2023-01-11 2:24 ` [PATCH v5 1/6] dt-bindings: media: platform: visconti: Add Toshiba Visconti Video Input Interface bindings Yuji Ishikawa 2023-01-11 2:24 ` Yuji Ishikawa 2023-01-11 9:19 ` Krzysztof Kozlowski 2023-01-11 9:19 ` Krzysztof Kozlowski 2023-01-11 12:48 ` yuji2.ishikawa 2023-01-11 12:48 ` yuji2.ishikawa 2023-01-17 15:26 ` Laurent Pinchart 2023-01-17 15:26 ` Laurent Pinchart 2023-01-17 15:42 ` Krzysztof Kozlowski 2023-01-17 15:42 ` Krzysztof Kozlowski 2023-01-17 15:58 ` Laurent Pinchart 2023-01-17 15:58 ` Laurent Pinchart 2023-01-17 17:01 ` Krzysztof Kozlowski 2023-01-17 17:01 ` Krzysztof Kozlowski 2023-01-22 19:25 ` Laurent Pinchart 2023-01-22 19:25 ` Laurent Pinchart 2023-01-30 9:06 ` yuji2.ishikawa 2023-01-30 9:06 ` yuji2.ishikawa 2023-02-01 9:45 ` Laurent Pinchart [this message] 2023-02-01 9:45 ` Laurent Pinchart 2023-02-01 11:24 ` yuji2.ishikawa 2023-02-01 11:24 ` yuji2.ishikawa 2023-01-11 2:24 ` [PATCH v5 2/6] media: platform: visconti: Add Toshiba Visconti Video Input Interface driver Yuji Ishikawa 2023-01-11 15:30 ` kernel test robot 2023-01-11 22:55 ` kernel test robot 2023-01-17 10:01 ` Hans Verkuil 2023-01-17 10:01 ` Hans Verkuil 2023-01-25 12:12 ` yuji2.ishikawa 2023-01-17 22:39 ` Sakari Ailus 2023-02-01 2:02 ` yuji2.ishikawa 2023-02-01 9:41 ` Laurent Pinchart 2023-02-01 9:41 ` Laurent Pinchart 2023-02-01 11:22 ` yuji2.ishikawa 2023-02-01 11:22 ` yuji2.ishikawa 2023-01-18 0:52 ` Laurent Pinchart 2023-01-18 0:52 ` Laurent Pinchart 2023-02-02 4:37 ` yuji2.ishikawa 2023-01-11 2:24 ` [PATCH v5 3/6] media: platform: visconti: Add Toshiba Visconti Video Input Interface driver user interace Yuji Ishikawa 2023-01-11 2:24 ` Yuji Ishikawa 2023-01-17 11:47 ` Hans Verkuil 2023-01-17 11:47 ` Hans Verkuil 2023-01-18 1:04 ` Laurent Pinchart 2023-01-18 1:04 ` Laurent Pinchart 2023-01-25 10:20 ` yuji2.ishikawa 2023-01-25 10:20 ` yuji2.ishikawa 2023-01-26 20:49 ` Laurent Pinchart 2023-01-26 20:49 ` Laurent Pinchart 2023-02-02 4:52 ` yuji2.ishikawa 2023-02-02 4:52 ` yuji2.ishikawa 2023-02-02 7:58 ` Laurent Pinchart 2023-02-02 7:58 ` Laurent Pinchart 2023-01-26 1:25 ` yuji2.ishikawa 2023-01-26 8:01 ` Hans Verkuil 2023-01-26 8:01 ` Hans Verkuil 2023-01-27 12:47 ` yuji2.ishikawa 2023-01-27 12:47 ` yuji2.ishikawa 2023-01-11 2:24 ` [PATCH v5 4/6] media: platform: visconti: Add Toshiba Visconti Video Input Interface driver v4l2 controls handler Yuji Ishikawa 2023-01-17 11:19 ` Hans Verkuil 2023-01-26 0:38 ` yuji2.ishikawa 2023-01-26 8:39 ` Hans Verkuil 2023-01-26 8:39 ` Hans Verkuil 2023-01-26 11:35 ` Laurent Pinchart 2023-01-26 11:35 ` Laurent Pinchart 2023-02-03 1:35 ` yuji2.ishikawa 2023-02-03 1:35 ` yuji2.ishikawa 2023-02-02 12:42 ` yuji2.ishikawa 2023-02-02 12:42 ` yuji2.ishikawa 2023-01-11 2:24 ` [PATCH v5 5/6] documentation: media: add documentation for Toshiba Visconti Video Input Interface driver Yuji Ishikawa 2023-01-11 2:24 ` Yuji Ishikawa 2023-01-11 2:24 ` [PATCH v5 6/6] MAINTAINERS: Add entries for Toshiba Visconti Video Input Interface Yuji Ishikawa 2023-01-11 2:24 ` Yuji Ishikawa
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Y9o01ctDujKRXw2J@pendragon.ideasonboard.com \ --to=laurent.pinchart@ideasonboard.com \ --cc=broonie@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=hverkuil@xs4all.nl \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=krzysztof.kozlowski@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=mchehab@kernel.org \ --cc=nobuhiro1.iwamatsu@toshiba.co.jp \ --cc=rafael.j.wysocki@intel.com \ --cc=robh+dt@kernel.org \ --cc=yuji2.ishikawa@toshiba.co.jp \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.