mbox series

[v6,00/14] dt-bindings: arm: freescale: Switch fsl,scu from txt to yaml

Message ID 20220629164414.301813-1-viorel.suman@oss.nxp.com (mailing list archive)
Headers show
Series dt-bindings: arm: freescale: Switch fsl,scu from txt to yaml | expand

Message

Viorel Suman (OSS) June 29, 2022, 4:44 p.m. UTC
From: Viorel Suman <viorel.suman@nxp.com>

Changes since v5: https://lore.kernel.org/lkml/20220616164303.790379-1-viorel.suman@nxp.com/
  * Updated according to Krzysztof Kozlowski comments

Changes since v4: https://lore.kernel.org/lkml/20220615105834.743045-1-viorel.suman@nxp.com/
  * Missing SoB added

Changes since v3: https://lore.kernel.org/lkml/20220609143423.2839186-1-abel.vesa@nxp.com/
  * Examples included
  * Included Abel's patches fixing thermal zone, keys and power controller names.

Abel Vesa (13):
  dt-bindings: clk: imx: Add fsl,scu-clk yaml file
  dt-bindings: pinctrl: imx: Add fsl,scu-iomux yaml file
  dt-bindings: input: Add fsl,scu-key yaml file
  dt-bindings: nvmem: Add fsl,scu-ocotp yaml file
  dt-bindings: power: Add fsl,scu-pd yaml file
  dt-bindings: rtc: Add fsl,scu-rtc yaml file
  dt-bindings: thermal: Add fsl,scu-thermal yaml file
  dt-bindings: watchdog: Add fsl,scu-wdt yaml file
  dt-bindings: firmware: Add fsl,scu yaml file
  arm64: dts: freescale: imx8: Fix power controller name
  arm64: dts: freescale: imx8qxp: Add fallback compatible for clock
    controller
  arm64: dts: freescale: imx8qxp: Fix the keys node name
  dt-bindings: arm: freescale: Remove fsl,scu txt file

Viorel Suman (1):
  arm64: dts: freescale: imx8qxp: Remove unnecessary clock related
    entries

 .../bindings/arm/freescale/fsl,scu.txt        | 271 ------------------
 .../bindings/clock/fsl,scu-clk.yaml           |  43 +++
 .../devicetree/bindings/firmware/fsl,scu.yaml | 160 +++++++++++
 .../bindings/input/fsl,scu-key.yaml           |  40 +++
 .../bindings/nvmem/fsl,scu-ocotp.yaml         |  57 ++++
 .../bindings/pinctrl/fsl,scu-pinctrl.yaml     |  68 +++++
 .../devicetree/bindings/power/fsl,scu-pd.yaml |  41 +++
 .../devicetree/bindings/rtc/fsl,scu-rtc.yaml  |  31 ++
 .../bindings/thermal/fsl,scu-thermal.yaml     |  38 +++
 .../bindings/watchdog/fsl,scu-wdt.yaml        |  34 +++
 arch/arm64/boot/dts/freescale/imx8qm.dtsi     |   2 +-
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi    |   8 +-
 12 files changed, 516 insertions(+), 277 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
 create mode 100644 Documentation/devicetree/bindings/clock/fsl,scu-clk.yaml
 create mode 100644 Documentation/devicetree/bindings/firmware/fsl,scu.yaml
 create mode 100644 Documentation/devicetree/bindings/input/fsl,scu-key.yaml
 create mode 100644 Documentation/devicetree/bindings/nvmem/fsl,scu-ocotp.yaml
 create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,scu-pinctrl.yaml
 create mode 100644 Documentation/devicetree/bindings/power/fsl,scu-pd.yaml
 create mode 100644 Documentation/devicetree/bindings/rtc/fsl,scu-rtc.yaml
 create mode 100644 Documentation/devicetree/bindings/thermal/fsl,scu-thermal.yaml
 create mode 100644 Documentation/devicetree/bindings/watchdog/fsl,scu-wdt.yaml

Comments

Krzysztof Kozlowski June 29, 2022, 5:51 p.m. UTC | #1
On 29/06/2022 18:44, Viorel Suman (OSS) wrote:
> From: Viorel Suman <viorel.suman@nxp.com>
> 
> Changes since v5: https://lore.kernel.org/lkml/20220616164303.790379-1-viorel.suman@nxp.com/
>   * Updated according to Krzysztof Kozlowski comments
> 

My comment a about removal of each part of TXT bindings in each patch,
was not addressed. Your approach makes it more difficult to read patches
and makes sense only if each subsystem maintainer will take the patches
(separately). If the patches are going through one tree, then better to
remove the TXT gradually.

So the question - who is going to take each of the patches?

Best regards,
Krzysztof
Viorel Suman (OSS) June 30, 2022, 12:13 p.m. UTC | #2
On 22-06-29 19:51:06, Krzysztof Kozlowski wrote:
> On 29/06/2022 18:44, Viorel Suman (OSS) wrote:
> > From: Viorel Suman <viorel.suman@nxp.com>
> > 
> > Changes since v5: https://lore.kernel.org/lkml/20220616164303.790379-1-viorel.suman@nxp.com/
> >   * Updated according to Krzysztof Kozlowski comments
> > 
> 
> My comment a about removal of each part of TXT bindings in each patch,
> was not addressed. Your approach makes it more difficult to read patches
> and makes sense only if each subsystem maintainer will take the patches
> (separately). If the patches are going through one tree, then better to
> remove the TXT gradually.
> 
> So the question - who is going to take each of the patches?

Hi Krzysztof,

I just understood the context of your comment, will do it in the next version.

Assuming TXT is removed from aggregating TXT - fsl,scu.txt - gradually, do you expect the
removed to be added into the aggregating YAML - fsl,scu.yaml - also gradually within the
same patch ?

Thank you,
Viorel
Krzysztof Kozlowski June 30, 2022, 6:03 p.m. UTC | #3
On 30/06/2022 14:13, Viorel Suman (OSS) wrote:
> On 22-06-29 19:51:06, Krzysztof Kozlowski wrote:
>> On 29/06/2022 18:44, Viorel Suman (OSS) wrote:
>>> From: Viorel Suman <viorel.suman@nxp.com>
>>>
>>> Changes since v5: https://lore.kernel.org/lkml/20220616164303.790379-1-viorel.suman@nxp.com/
>>>   * Updated according to Krzysztof Kozlowski comments
>>>
>>
>> My comment a about removal of each part of TXT bindings in each patch,
>> was not addressed. Your approach makes it more difficult to read patches
>> and makes sense only if each subsystem maintainer will take the patches
>> (separately). If the patches are going through one tree, then better to
>> remove the TXT gradually.
>>
>> So the question - who is going to take each of the patches?
> 
> Hi Krzysztof,
> 
> I just understood the context of your comment, will do it in the next version.
> 
> Assuming TXT is removed from aggregating TXT - fsl,scu.txt - gradually, do you expect the
> removed to be added into the aggregating YAML - fsl,scu.yaml - also gradually within the
> same patch ?

Each patch making the conversion should remove the piece being
converted. Then finally the patch adding fsl,scu.yaml should remove the
last pieces (remaining ones).

Best regards,
Krzysztof
Viorel Suman (OSS) June 30, 2022, 6:11 p.m. UTC | #4
On 22-06-30 20:03:07, Krzysztof Kozlowski wrote:
> On 30/06/2022 14:13, Viorel Suman (OSS) wrote:
> > On 22-06-29 19:51:06, Krzysztof Kozlowski wrote:
> >> On 29/06/2022 18:44, Viorel Suman (OSS) wrote:
> >>> From: Viorel Suman <viorel.suman@nxp.com>
> >>>
> >>> Changes since v5: https://lore.kernel.org/lkml/20220616164303.790379-1-viorel.suman@nxp.com/
> >>>   * Updated according to Krzysztof Kozlowski comments
> >>>
> >>
> >> My comment a about removal of each part of TXT bindings in each patch,
> >> was not addressed. Your approach makes it more difficult to read patches
> >> and makes sense only if each subsystem maintainer will take the patches
> >> (separately). If the patches are going through one tree, then better to
> >> remove the TXT gradually.
> >>
> >> So the question - who is going to take each of the patches?
> > 
> > Hi Krzysztof,
> > 
> > I just understood the context of your comment, will do it in the next version.
> > 
> > Assuming TXT is removed from aggregating TXT - fsl,scu.txt - gradually, do you expect the
> > removed to be added into the aggregating YAML - fsl,scu.yaml - also gradually within the
> > same patch ?
> 
> Each patch making the conversion should remove the piece being
> converted. Then finally the patch adding fsl,scu.yaml should remove the
> last pieces (remaining ones).

Thank you for clarification, will follow this approach in the next version.

Regards,
Viorel
Shawn Guo July 5, 2022, 12:39 a.m. UTC | #5
On Wed, Jun 29, 2022 at 07:51:06PM +0200, Krzysztof Kozlowski wrote:
> On 29/06/2022 18:44, Viorel Suman (OSS) wrote:
> > From: Viorel Suman <viorel.suman@nxp.com>
> > 
> > Changes since v5: https://lore.kernel.org/lkml/20220616164303.790379-1-viorel.suman@nxp.com/
> >   * Updated according to Krzysztof Kozlowski comments
> > 
> 
> My comment a about removal of each part of TXT bindings in each patch,
> was not addressed. Your approach makes it more difficult to read patches
> and makes sense only if each subsystem maintainer will take the patches
> (separately). If the patches are going through one tree, then better to
> remove the TXT gradually.
> 
> So the question - who is going to take each of the patches?

I can take the series through IMX tree if that makes the most sense.

Shawn
Krzysztof Kozlowski July 5, 2022, 7:28 a.m. UTC | #6
On 05/07/2022 02:39, Shawn Guo wrote:
> On Wed, Jun 29, 2022 at 07:51:06PM +0200, Krzysztof Kozlowski wrote:
>> On 29/06/2022 18:44, Viorel Suman (OSS) wrote:
>>> From: Viorel Suman <viorel.suman@nxp.com>
>>>
>>> Changes since v5: https://lore.kernel.org/lkml/20220616164303.790379-1-viorel.suman@nxp.com/
>>>   * Updated according to Krzysztof Kozlowski comments
>>>
>>
>> My comment a about removal of each part of TXT bindings in each patch,
>> was not addressed. Your approach makes it more difficult to read patches
>> and makes sense only if each subsystem maintainer will take the patches
>> (separately). If the patches are going through one tree, then better to
>> remove the TXT gradually.
>>
>> So the question - who is going to take each of the patches?
> 
> I can take the series through IMX tree if that makes the most sense.

Sounds fine to me. Then however each piece of TXT file should be removed
in each commit doing that piece conversion.

Best regards,
Krzysztof
Viorel Suman (OSS) July 5, 2022, 8:07 a.m. UTC | #7
On 22-07-05 09:28:24, Krzysztof Kozlowski wrote:
> On 05/07/2022 02:39, Shawn Guo wrote:
> > On Wed, Jun 29, 2022 at 07:51:06PM +0200, Krzysztof Kozlowski wrote:
> >> On 29/06/2022 18:44, Viorel Suman (OSS) wrote:
> >>> From: Viorel Suman <viorel.suman@nxp.com>
> >>>
> >>> Changes since v5: https://lore.kernel.org/lkml/20220616164303.790379-1-viorel.suman@nxp.com/
> >>>   * Updated according to Krzysztof Kozlowski comments
> >>>
> >>
> >> My comment a about removal of each part of TXT bindings in each patch,
> >> was not addressed. Your approach makes it more difficult to read patches
> >> and makes sense only if each subsystem maintainer will take the patches
> >> (separately). If the patches are going through one tree, then better to
> >> remove the TXT gradually.
> >>
> >> So the question - who is going to take each of the patches?
> > 
> > I can take the series through IMX tree if that makes the most sense.
> 
> Sounds fine to me. Then however each piece of TXT file should be removed
> in each commit doing that piece conversion.
> 
> Best regards,
> Krzysztof

Just sent v7 which removes TXT in each commit which does the conversion.

Regards,
Viorel