[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZyHq4FJ0ubQVGREo@standask-GA-A55M-S2HP>
Date: Wed, 30 Oct 2024 09:14:24 +0100
From: Stanislav Jakubek <stano.jakubek@...il.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Lee Jones <lee@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Orson Zhai <orsonzhai@...il.com>,
Baolin Wang <baolin.wang@...ux.alibaba.com>,
Chunyan Zhang <zhang.lyra@...il.com>,
Jonathan Cameron <jic23@...nel.org>,
Lars-Peter Clausen <lars@...afoo.de>, Pavel Machek <pavel@....cz>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
Sebastian Reichel <sre@...nel.org>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
devicetree@...r.kernel.org, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-leds@...r.kernel.org,
linux-pm@...r.kernel.org, linux-rtc@...r.kernel.org
Subject: Re: [PATCH v2] dt-bindings: mfd: sprd,sc2731: convert to YAML
On Wed, Oct 30, 2024 at 08:48:25AM +0100, Krzysztof Kozlowski wrote:
> On 30/10/2024 08:42, Stanislav Jakubek wrote:
> >>
> >>> +
> >>> + '#address-cells':
> >>> + const: 1
> >>> +
> >>> + '#interrupt-cells':
> >>> + const: 1
> >>> +
> >>> + '#size-cells':
> >>> + const: 0
> >>> +
> >>> + regulators:
> >>> + type: object
> >>> + $ref: /schemas/regulator/sprd,sc2731-regulator.yaml#
> >>> +
> >>> +patternProperties:
> >>> + "^adc@[0-9a-f]+$":
> >>> + type: object
> >>> + $ref: /schemas/iio/adc/sprd,sc2720-adc.yaml#
> >>> +
> >>> + "^charger@[0-9a-f]+$":
> >>> + type: object
> >>> + $ref: /schemas/power/supply/sc2731-charger.yaml#
> >>> +
> >>> + "^efuse@[0-9a-f]+$":
> >>> + type: object
> >>> + $ref: /schemas/nvmem/sprd,sc2731-efuse.yaml#
> >>
> >> I don't think this was merged. You still have dependency.
> >
> > This is in next-20241029, which this patch is based on.
>
> Try what I wrote below and see if this works...
I assume you meant the MFD maintainers' tree here.
Yes, that tree doesn't have the nvmem patch this depends on.
Would the approach with listing the compatibles and additionalProperties:
true be considered a temporary workaround?
If so, should I split this into 2 patches?
- 1st patch with the nvmem workaround above
- 2nd with adding the nvmem $ref back (which would get merged later)
Regards,
Stanislav
>
> Best regards,
> Krzysztof
>
Powered by blists - more mailing lists