On Wed, Mar 30, 2022 at 10:52 AM Russell King (Oracle) <linux@xxxxxxxxxxxxxxx> wrote: > > On Wed, Mar 16, 2022 at 10:18:55AM +0000, Ioana Ciornei wrote: > > On Wed, Mar 16, 2022 at 09:23:45AM +0100, Krzysztof Kozlowski wrote: > > > On 15/03/2022 20:07, Ioana Ciornei wrote: > > > > On Tue, Mar 15, 2022 at 07:21:59PM +0100, Krzysztof Kozlowski wrote: > > > >> On 15/03/2022 13:33, Ioana Ciornei wrote: > > > >>> Convert the sff,sfp.txt bindings to the DT schema format. > > > >>> > > > >>> Signed-off-by: Ioana Ciornei <ioana.ciornei@xxxxxxx> > > > >>> --- > > > > > > > > (..) > > > > > > > >>> +maintainers: > > > >>> + - Russell King <linux@xxxxxxxxxxxxxxx> > > > >>> + > > > >>> +properties: > > > >>> + compatible: > > > >>> + enum: > > > >>> + - sff,sfp # for SFP modules > > > >>> + - sff,sff # for soldered down SFF modules > > > >>> + > > > >>> + i2c-bus: > > > >> > > > >> Thanks for the conversion. > > > >> > > > >> You need here a type because this does not look like standard property. > > > > > > > > Ok. > > > > > > > >> > > > >>> + description: > > > >>> + phandle of an I2C bus controller for the SFP two wire serial > > > >>> + > > > >>> + maximum-power-milliwatt: > > > >>> + maxItems: 1 > > > >>> + description: > > > >>> + Maximum module power consumption Specifies the maximum power consumption > > > >>> + allowable by a module in the slot, in milli-Watts. Presently, modules can > > > >>> + be up to 1W, 1.5W or 2W. > > > >>> + > > > >>> +patternProperties: > > > >>> + "mod-def0-gpio(s)?": > > > >> > > > >> This should be just "mod-def0-gpios", no need for pattern. The same in > > > >> all other places. > > > >> > > > > > > > > The GPIO subsystem accepts both suffixes: "gpio" and "gpios", see > > > > gpio_suffixes[]. If I just use "mod-def0-gpios" multiple DT files will > > > > fail the check because they are using the "gpio" suffix. > > > > > > > > Why isn't this pattern acceptable? > > > > > > Because original bindings required gpios, so DTS are wrong, and the > > > pattern makes it difficult to grep and read such simple property. > > > > > > The DTSes which do not follow bindings should be corrected. > > > > > > > Russell, do you have any thoughts on this? > > I am asking this because you were the one that added the "-gpios" suffix > > in the dtbinding and the "-gpio" usage in the DT files so I wouldn't > > want this to diverge from your thinking. > > > > Do you have a preference? > > SFP support predated (in my tree) the deprecation of the -gpio suffix, > and despite the SFP binding doc being sent for review, it didn't get > reviewed so the issue was never picked up. Really? https://lore.kernel.org/all/CAL_JsqL_7gG8FSEJDXu=37DFpHjfLhQuUhPFRKcScYTzM4cNyg@xxxxxxxxxxxxxx/ > My understanding is that GPIO will continue to accept either -gpio or > -gpios for ever, so there shouldn't be any issue here - so converting > all instances of -gpio to -gpios should be doable without issue. > > > If it's that unheard of to have a somewhat complete example why are > > there multiple dtschema files submitted even by yourself with this same > > setup? > > As an example for a consumer device being listed in the provider yaml > > file is 'gpio-pca95xx.yaml' and for the reverse (provider described in > > the consumer) I can list 'samsung,s5pv210-clock.yaml', > > 'samsung,exynos5260-clock.yaml' etc. > > My feels are it _is_ useful to show the consumer side in examples. I think having it is fine here as long as the consumer has a schema. This case is a bit different as there's really only 1 provider instance and this is it. It's the 100s of clock, gpio, interrupt, etc. schemas that we don't need showing the consumer side over and over. Rob