[PATCH/RFC 00/02] Remove undocumented IMR-LX4 device nodes

[PATCH/RFC 00/02] Remove undocumented IMR-LX4 device nodes

[Magnus Damm]

Remove undocumented IMR-LX4 device nodes

[PATCH/RFC 01/02] arm64: dts: renesas: r8a7795: Remove IMR-LX4 device nodes
[PATCH/RFC 02/02] arm64: dts: renesas: r8a7796: Remove IMR-LX4 device nodes

These patches take the easy way out and simply remove the undocumented
IMR-LX4 device nodes from the upstream tree. Good or bad, let me know!

So perhaps this is a bit overly aggressive but since the DT bindings seem
undocumented and no driver exists in upstream my gut feeling says these DT
nodes were part of an upstreaming attempt that got suspended half-way through.

In case DT binding documentation is in-flight and queued up somewhere
(ideally together with a driver) then feel free to ignore this series.

Instead of removing nodes we could also document the DT bindings for the
IMR-LX4 devices. It would also make sense to add device nodes to other
more recent SoCs than just H3 and M3-W. But blindly adding more DT nodes
with a DT binding but without a driver seems a bit suboptimal compared to
testing against an actual driver.

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---

 Developed on top of v5.0-rc3

 arch/arm64/boot/dts/renesas/r8a7795.dtsi |   40 ------------------------------
 arch/arm64/boot/dts/renesas/r8a7796.dtsi |   20 ---------------
 2 files changed, 60 deletions(-)

[PATCH/RFC 01/02] arm64: dts: renesas: r8a7795: Remove IMR-LX4 device nodes

[Magnus Damm]

From: Magnus Damm <damm+renesas@opensource.se>

Get rid of undocumented IMR-LX4 device nodes for the r8a7795 SoC.

I would much prefer to have a proper driver with documented DT bindings
in upstream instead. However removing DT nodes seems better than this
current half-way state.

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---

 arch/arm64/boot/dts/renesas/r8a7795.dtsi |   40 ------------------------------
 1 file changed, 40 deletions(-)

--- 0001/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ work/arch/arm64/boot/dts/renesas/r8a7795.dtsi	2019-01-21 17:48:16.337551506 +0900
@@ -2607,46 +2607,6 @@
 			status = "disabled";
 		};
 
-		imr-lx4@fe860000 {
-			compatible = "renesas,r8a7795-imr-lx4",
-				     "renesas,imr-lx4";
-			reg = <0 0xfe860000 0 0x2000>;
-			interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 823>;
-			power-domains = <&sysc R8A7795_PD_A3VC>;
-			resets = <&cpg 823>;
-		};
-
-		imr-lx4@fe870000 {
-			compatible = "renesas,r8a7795-imr-lx4",
-				     "renesas,imr-lx4";
-			reg = <0 0xfe870000 0 0x2000>;
-			interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 822>;
-			power-domains = <&sysc R8A7795_PD_A3VC>;
-			resets = <&cpg 822>;
-		};
-
-		imr-lx4@fe880000 {
-			compatible = "renesas,r8a7795-imr-lx4",
-				     "renesas,imr-lx4";
-			reg = <0 0xfe880000 0 0x2000>;
-			interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 821>;
-			power-domains = <&sysc R8A7795_PD_A3VC>;
-			resets = <&cpg 821>;
-		};
-
-		imr-lx4@fe890000 {
-			compatible = "renesas,r8a7795-imr-lx4",
-				     "renesas,imr-lx4";
-			reg = <0 0xfe890000 0 0x2000>;
-			interrupts = <GIC_SPI 195 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 820>;
-			power-domains = <&sysc R8A7795_PD_A3VC>;
-			resets = <&cpg 820>;
-		};
-
 		fdp1@fe940000 {
 			compatible = "renesas,fdp1";
 			reg = <0 0xfe940000 0 0x2400>;

[PATCH/RFC 02/02] arm64: dts: renesas: r8a7796: Remove IMR-LX4 device nodes

[Magnus Damm]

From: Magnus Damm <damm+renesas@opensource.se>

Get rid of undocumented IMR-LX4 device nodes for the r8a7796 SoC.

I would much prefer to have a proper driver with documented DT bindings
in upstream instead. However removing DT nodes seems better than this
current half-way state.

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---

 arch/arm64/boot/dts/renesas/r8a7796.dtsi |   20 --------------------
 1 file changed, 20 deletions(-)

--- 0001/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ work/arch/arm64/boot/dts/renesas/r8a7796.dtsi	2019-01-21 17:50:26.171358491 +0900
@@ -2470,26 +2470,6 @@
 			status = "disabled";
 		};
 
-		imr-lx4@fe860000 {
-			compatible = "renesas,r8a7796-imr-lx4",
-				     "renesas,imr-lx4";
-			reg = <0 0xfe860000 0 0x2000>;
-			interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 823>;
-			power-domains = <&sysc R8A7796_PD_A3VC>;
-			resets = <&cpg 823>;
-		};
-
-		imr-lx4@fe870000 {
-			compatible = "renesas,r8a7796-imr-lx4",
-				     "renesas,imr-lx4";
-			reg = <0 0xfe870000 0 0x2000>;
-			interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 822>;
-			power-domains = <&sysc R8A7796_PD_A3VC>;
-			resets = <&cpg 822>;
-		};
-
 		fdp1@fe940000 {
 			compatible = "renesas,fdp1";
 			reg = <0 0xfe940000 0 0x2400>;

Re: [PATCH/RFC 00/02] Remove undocumented IMR-LX4 device nodes

[Geert Uytterhoeven]

Hi Magnus,

On Mon, Jan 21, 2019 at 12:49 PM Magnus Damm <magnus.damm@gmail.com> wrote:
> Remove undocumented IMR-LX4 device nodes
>
> [PATCH/RFC 01/02] arm64: dts: renesas: r8a7795: Remove IMR-LX4 device nodes
> [PATCH/RFC 02/02] arm64: dts: renesas: r8a7796: Remove IMR-LX4 device nodes
>
> These patches take the easy way out and simply remove the undocumented
> IMR-LX4 device nodes from the upstream tree. Good or bad, let me know!
>
> So perhaps this is a bit overly aggressive but since the DT bindings seem
> undocumented and no driver exists in upstream my gut feeling says these DT
> nodes were part of an upstreaming attempt that got suspended half-way through.
>
> In case DT binding documentation is in-flight and queued up somewhere
> (ideally together with a driver) then feel free to ignore this series.
>
> Instead of removing nodes we could also document the DT bindings for the
> IMR-LX4 devices. It would also make sense to add device nodes to other
> more recent SoCs than just H3 and M3-W. But blindly adding more DT nodes
> with a DT binding but without a driver seems a bit suboptimal compared to
> testing against an actual driver.

[PATCH v5] media: platform: Renesas IMR driver
https://lore.kernel.org/linux-renesas-soc/20170309200818.786255823@cogentembedded.com/

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH/RFC 00/02] Remove undocumented IMR-LX4 device nodes

[Magnus Damm]

Hi Geert,

On Mon, Jan 21, 2019 at 8:53 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Magnus,
>
> On Mon, Jan 21, 2019 at 12:49 PM Magnus Damm <magnus.damm@gmail.com> wrote:
> > Remove undocumented IMR-LX4 device nodes
> >
> > [PATCH/RFC 01/02] arm64: dts: renesas: r8a7795: Remove IMR-LX4 device nodes
> > [PATCH/RFC 02/02] arm64: dts: renesas: r8a7796: Remove IMR-LX4 device nodes
> >
> > These patches take the easy way out and simply remove the undocumented
> > IMR-LX4 device nodes from the upstream tree. Good or bad, let me know!
> >
> > So perhaps this is a bit overly aggressive but since the DT bindings seem
> > undocumented and no driver exists in upstream my gut feeling says these DT
> > nodes were part of an upstreaming attempt that got suspended half-way through.
> >
> > In case DT binding documentation is in-flight and queued up somewhere
> > (ideally together with a driver) then feel free to ignore this series.
> >
> > Instead of removing nodes we could also document the DT bindings for the
> > IMR-LX4 devices. It would also make sense to add device nodes to other
> > more recent SoCs than just H3 and M3-W. But blindly adding more DT nodes
> > with a DT binding but without a driver seems a bit suboptimal compared to
> > testing against an actual driver.
>
> [PATCH v5] media: platform: Renesas IMR driver
> https://lore.kernel.org/linux-renesas-soc/20170309200818.786255823@cogentembedded.com/

Thanks, but that seems to be from 2017! =)

Cheers,

/ magnus

Re: [PATCH/RFC 01/02] arm64: dts: renesas: r8a7795: Remove IMR-LX4 device nodes

[Simon Horman]

On Mon, Jan 21, 2019 at 08:50:05PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
> 
> Get rid of undocumented IMR-LX4 device nodes for the r8a7795 SoC.
> 
> I would much prefer to have a proper driver with documented DT bindings
> in upstream instead. However removing DT nodes seems better than this
> current half-way state.
> 
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>

I agree, likewise for patch 02/02.

Shall I go ahead and apply this series?

> ---
> 
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi |   40 ------------------------------
>  1 file changed, 40 deletions(-)
> 
> --- 0001/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ work/arch/arm64/boot/dts/renesas/r8a7795.dtsi	2019-01-21 17:48:16.337551506 +0900
> @@ -2607,46 +2607,6 @@
>  			status = "disabled";
>  		};
>  
> -		imr-lx4@fe860000 {
> -			compatible = "renesas,r8a7795-imr-lx4",
> -				     "renesas,imr-lx4";
> -			reg = <0 0xfe860000 0 0x2000>;
> -			interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 823>;
> -			power-domains = <&sysc R8A7795_PD_A3VC>;
> -			resets = <&cpg 823>;
> -		};
> -
> -		imr-lx4@fe870000 {
> -			compatible = "renesas,r8a7795-imr-lx4",
> -				     "renesas,imr-lx4";
> -			reg = <0 0xfe870000 0 0x2000>;
> -			interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 822>;
> -			power-domains = <&sysc R8A7795_PD_A3VC>;
> -			resets = <&cpg 822>;
> -		};
> -
> -		imr-lx4@fe880000 {
> -			compatible = "renesas,r8a7795-imr-lx4",
> -				     "renesas,imr-lx4";
> -			reg = <0 0xfe880000 0 0x2000>;
> -			interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 821>;
> -			power-domains = <&sysc R8A7795_PD_A3VC>;
> -			resets = <&cpg 821>;
> -		};
> -
> -		imr-lx4@fe890000 {
> -			compatible = "renesas,r8a7795-imr-lx4",
> -				     "renesas,imr-lx4";
> -			reg = <0 0xfe890000 0 0x2000>;
> -			interrupts = <GIC_SPI 195 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&cpg CPG_MOD 820>;
> -			power-domains = <&sysc R8A7795_PD_A3VC>;
> -			resets = <&cpg 820>;
> -		};
> -
>  		fdp1@fe940000 {
>  			compatible = "renesas,fdp1";
>  			reg = <0 0xfe940000 0 0x2400>;
> 

Re: [PATCH/RFC 01/02] arm64: dts: renesas: r8a7795: Remove IMR-LX4 device nodes

[Sergei Shtylyov]

On 01/23/2019 12:59 PM, Simon Horman wrote:

>> From: Magnus Damm <damm+renesas@opensource.se>
>>
>> Get rid of undocumented IMR-LX4 device nodes for the r8a7795 SoC.
>>
>> I would much prefer to have a proper driver with documented DT bindings
>> in upstream instead. However removing DT nodes seems better than this
>> current half-way state.
>>
>> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> 
> I agree, likewise for patch 02/02.
> 
> Shall I go ahead and apply this series?

   I will return to the IMR driver after I'm done with V3M/V3H (and I have the HyperFlash
driver to push upstream yet for those). Sorry for dropping the ball here, it wasn't my fault.

MBR, Sergei

Re: [PATCH/RFC 00/02] Remove undocumented IMR-LX4 device nodes

[Sergei Shtylyov]

Hello!

On 01/21/2019 03:01 PM, Magnus Damm wrote:

>> On Mon, Jan 21, 2019 at 12:49 PM Magnus Damm <magnus.damm@gmail.com> wrote:
>>> Remove undocumented IMR-LX4 device nodes
>>>
>>> [PATCH/RFC 01/02] arm64: dts: renesas: r8a7795: Remove IMR-LX4 device nodes
>>> [PATCH/RFC 02/02] arm64: dts: renesas: r8a7796: Remove IMR-LX4 device nodes
>>>
>>> These patches take the easy way out and simply remove the undocumented
>>> IMR-LX4 device nodes from the upstream tree. Good or bad, let me know!
>>>
>>> So perhaps this is a bit overly aggressive but since the DT bindings seem
>>> undocumented and no driver exists in upstream my gut feeling says these DT
>>> nodes were part of an upstreaming attempt that got suspended half-way through.
>>>
>>> In case DT binding documentation is in-flight and queued up somewhere
>>> (ideally together with a driver) then feel free to ignore this series.
>>>
>>> Instead of removing nodes we could also document the DT bindings for the
>>> IMR-LX4 devices. It would also make sense to add device nodes to other
>>> more recent SoCs than just H3 and M3-W. But blindly adding more DT nodes
>>> with a DT binding but without a driver seems a bit suboptimal compared to
>>> testing against an actual driver.
>>
>> [PATCH v5] media: platform: Renesas IMR driver
>> https://lore.kernel.org/linux-renesas-soc/20170309200818.786255823@cogentembedded.com/
> 
> Thanks, but that seems to be from 2017! =)

   I dropped the ball there, as I was tasked with upstreaming V3x support...
The last thing done about the IMR driver was talking to Hans in Prague in 2017.
I'm planning to return to the driver after I'm done with the HyperFlash driver.

> Cheers,
> 
> / magnus

MBR, Sergei

Re: [PATCH/RFC 00/02] Remove undocumented IMR-LX4 device nodes

[Simon Horman]

On Wed, Jan 23, 2019 at 09:19:59PM +0300, Sergei Shtylyov wrote:
> Hello!
> 
> On 01/21/2019 03:01 PM, Magnus Damm wrote:
> 
> >> On Mon, Jan 21, 2019 at 12:49 PM Magnus Damm <magnus.damm@gmail.com> wrote:
> >>> Remove undocumented IMR-LX4 device nodes
> >>>
> >>> [PATCH/RFC 01/02] arm64: dts: renesas: r8a7795: Remove IMR-LX4 device nodes
> >>> [PATCH/RFC 02/02] arm64: dts: renesas: r8a7796: Remove IMR-LX4 device nodes
> >>>
> >>> These patches take the easy way out and simply remove the undocumented
> >>> IMR-LX4 device nodes from the upstream tree. Good or bad, let me know!
> >>>
> >>> So perhaps this is a bit overly aggressive but since the DT bindings seem
> >>> undocumented and no driver exists in upstream my gut feeling says these DT
> >>> nodes were part of an upstreaming attempt that got suspended half-way through.
> >>>
> >>> In case DT binding documentation is in-flight and queued up somewhere
> >>> (ideally together with a driver) then feel free to ignore this series.
> >>>
> >>> Instead of removing nodes we could also document the DT bindings for the
> >>> IMR-LX4 devices. It would also make sense to add device nodes to other
> >>> more recent SoCs than just H3 and M3-W. But blindly adding more DT nodes
> >>> with a DT binding but without a driver seems a bit suboptimal compared to
> >>> testing against an actual driver.
> >>
> >> [PATCH v5] media: platform: Renesas IMR driver
> >> https://lore.kernel.org/linux-renesas-soc/20170309200818.786255823@cogentembedded.com/
> > 
> > Thanks, but that seems to be from 2017! =)
> 
>    I dropped the ball there, as I was tasked with upstreaming V3x support...
> The last thing done about the IMR driver was talking to Hans in Prague in
> 2017.  I'm planning to return to the driver after I'm done with the
> HyperFlash driver.

Hi Sergei,

I appreciate that we are not always in control of our own priorities,
indeed I sympathise with that predicament. However, we shouldn't really
be in a situation where DT is making use of undocumented bindings.

I would like to ask for the bindings to be documented in the upstream
kernel in the near future. And if that is not possible I believe we
should consider temporarily removing their use in DT in the upstream kernel.

Re: [PATCH/RFC 00/02] Remove undocumented IMR-LX4 device nodes

[Simon Horman]

On Mon, Jan 28, 2019 at 01:58:11PM +0100, Simon Horman wrote:
> On Wed, Jan 23, 2019 at 09:19:59PM +0300, Sergei Shtylyov wrote:
> > Hello!
> > 
> > On 01/21/2019 03:01 PM, Magnus Damm wrote:
> > 
> > >> On Mon, Jan 21, 2019 at 12:49 PM Magnus Damm <magnus.damm@gmail.com> wrote:
> > >>> Remove undocumented IMR-LX4 device nodes
> > >>>
> > >>> [PATCH/RFC 01/02] arm64: dts: renesas: r8a7795: Remove IMR-LX4 device nodes
> > >>> [PATCH/RFC 02/02] arm64: dts: renesas: r8a7796: Remove IMR-LX4 device nodes
> > >>>
> > >>> These patches take the easy way out and simply remove the undocumented
> > >>> IMR-LX4 device nodes from the upstream tree. Good or bad, let me know!
> > >>>
> > >>> So perhaps this is a bit overly aggressive but since the DT bindings seem
> > >>> undocumented and no driver exists in upstream my gut feeling says these DT
> > >>> nodes were part of an upstreaming attempt that got suspended half-way through.
> > >>>
> > >>> In case DT binding documentation is in-flight and queued up somewhere
> > >>> (ideally together with a driver) then feel free to ignore this series.
> > >>>
> > >>> Instead of removing nodes we could also document the DT bindings for the
> > >>> IMR-LX4 devices. It would also make sense to add device nodes to other
> > >>> more recent SoCs than just H3 and M3-W. But blindly adding more DT nodes
> > >>> with a DT binding but without a driver seems a bit suboptimal compared to
> > >>> testing against an actual driver.
> > >>
> > >> [PATCH v5] media: platform: Renesas IMR driver
> > >> https://lore.kernel.org/linux-renesas-soc/20170309200818.786255823@cogentembedded.com/
> > > 
> > > Thanks, but that seems to be from 2017! =)
> > 
> >    I dropped the ball there, as I was tasked with upstreaming V3x support...
> > The last thing done about the IMR driver was talking to Hans in Prague in
> > 2017.  I'm planning to return to the driver after I'm done with the
> > HyperFlash driver.
> 
> Hi Sergei,
> 
> I appreciate that we are not always in control of our own priorities,
> indeed I sympathise with that predicament. However, we shouldn't really
> be in a situation where DT is making use of undocumented bindings.
> 
> I would like to ask for the bindings to be documented in the upstream
> kernel in the near future. And if that is not possible I believe we
> should consider temporarily removing their use in DT in the upstream kernel.

Hi Sergei,

about two months have passed since Magnus posted this series.
Do you have a timeline to address the problems? If so I believe
that the way forward should be to apply this series. The topic
can always be readdressed in future.

Re: [PATCH/RFC 00/02] Remove undocumented IMR-LX4 device nodes

[Sergei Shtylyov]

Hello!

On 03/25/2019 02:03 PM, Simon Horman wrote:

>>>>> On Mon, Jan 21, 2019 at 12:49 PM Magnus Damm <magnus.damm@gmail.com> wrote:
>>>>>> Remove undocumented IMR-LX4 device nodes
>>>>>>
>>>>>> [PATCH/RFC 01/02] arm64: dts: renesas: r8a7795: Remove IMR-LX4 device nodes
>>>>>> [PATCH/RFC 02/02] arm64: dts: renesas: r8a7796: Remove IMR-LX4 device nodes
>>>>>>
>>>>>> These patches take the easy way out and simply remove the undocumented
>>>>>> IMR-LX4 device nodes from the upstream tree. Good or bad, let me know!
>>>>>>
>>>>>> So perhaps this is a bit overly aggressive but since the DT bindings seem
>>>>>> undocumented and no driver exists in upstream my gut feeling says these DT
>>>>>> nodes were part of an upstreaming attempt that got suspended half-way through.
>>>>>>
>>>>>> In case DT binding documentation is in-flight and queued up somewhere
>>>>>> (ideally together with a driver) then feel free to ignore this series.
>>>>>>
>>>>>> Instead of removing nodes we could also document the DT bindings for the
>>>>>> IMR-LX4 devices. It would also make sense to add device nodes to other
>>>>>> more recent SoCs than just H3 and M3-W. But blindly adding more DT nodes
>>>>>> with a DT binding but without a driver seems a bit suboptimal compared to
>>>>>> testing against an actual driver.
>>>>>
>>>>> [PATCH v5] media: platform: Renesas IMR driver
>>>>> https://lore.kernel.org/linux-renesas-soc/20170309200818.786255823@cogentembedded.com/
>>>>
>>>> Thanks, but that seems to be from 2017! =)
>>>
>>>    I dropped the ball there, as I was tasked with upstreaming V3x support...
>>> The last thing done about the IMR driver was talking to Hans in Prague in
>>> 2017.  I'm planning to return to the driver after I'm done with the
>>> HyperFlash driver.
>>
>> Hi Sergei,
>>
>> I appreciate that we are not always in control of our own priorities,
>> indeed I sympathise with that predicament. However, we shouldn't really
>> be in a situation where DT is making use of undocumented bindings.
>>
>> I would like to ask for the bindings to be documented in the upstream
>> kernel in the near future. And if that is not possible I believe we
>> should consider temporarily removing their use in DT in the upstream kernel.
> 
> Hi Sergei,
> 
> about two months have passed since Magnus posted this series.

   Time flies...
   Dealing w/ the flash drivers turned into unending nightmare. :-(

> Do you have a timeline to address the problems?

   I'm looking into posting the bindings separately right now.
The patch should be ready today or tomorrow.

> If so I believe> that the way forward should be to apply this series.

   Hm, not sure I understood you correctly. You're going to remove
the device nodes even if I have a timeline?

[...]

MBR, Sergei

Re: [PATCH/RFC 00/02] Remove undocumented IMR-LX4 device nodes

[Simon Horman]

On Mon, Mar 25, 2019 at 06:53:58PM +0300, Sergei Shtylyov wrote:
> Hello!
> 
> On 03/25/2019 02:03 PM, Simon Horman wrote:
> 
> >>>>> On Mon, Jan 21, 2019 at 12:49 PM Magnus Damm <magnus.damm@gmail.com> wrote:
> >>>>>> Remove undocumented IMR-LX4 device nodes
> >>>>>>
> >>>>>> [PATCH/RFC 01/02] arm64: dts: renesas: r8a7795: Remove IMR-LX4 device nodes
> >>>>>> [PATCH/RFC 02/02] arm64: dts: renesas: r8a7796: Remove IMR-LX4 device nodes
> >>>>>>
> >>>>>> These patches take the easy way out and simply remove the undocumented
> >>>>>> IMR-LX4 device nodes from the upstream tree. Good or bad, let me know!
> >>>>>>
> >>>>>> So perhaps this is a bit overly aggressive but since the DT bindings seem
> >>>>>> undocumented and no driver exists in upstream my gut feeling says these DT
> >>>>>> nodes were part of an upstreaming attempt that got suspended half-way through.
> >>>>>>
> >>>>>> In case DT binding documentation is in-flight and queued up somewhere
> >>>>>> (ideally together with a driver) then feel free to ignore this series.
> >>>>>>
> >>>>>> Instead of removing nodes we could also document the DT bindings for the
> >>>>>> IMR-LX4 devices. It would also make sense to add device nodes to other
> >>>>>> more recent SoCs than just H3 and M3-W. But blindly adding more DT nodes
> >>>>>> with a DT binding but without a driver seems a bit suboptimal compared to
> >>>>>> testing against an actual driver.
> >>>>>
> >>>>> [PATCH v5] media: platform: Renesas IMR driver
> >>>>> https://lore.kernel.org/linux-renesas-soc/20170309200818.786255823@cogentembedded.com/
> >>>>
> >>>> Thanks, but that seems to be from 2017! =)
> >>>
> >>>    I dropped the ball there, as I was tasked with upstreaming V3x support...
> >>> The last thing done about the IMR driver was talking to Hans in Prague in
> >>> 2017.  I'm planning to return to the driver after I'm done with the
> >>> HyperFlash driver.
> >>
> >> Hi Sergei,
> >>
> >> I appreciate that we are not always in control of our own priorities,
> >> indeed I sympathise with that predicament. However, we shouldn't really
> >> be in a situation where DT is making use of undocumented bindings.
> >>
> >> I would like to ask for the bindings to be documented in the upstream
> >> kernel in the near future. And if that is not possible I believe we
> >> should consider temporarily removing their use in DT in the upstream kernel.
> > 
> > Hi Sergei,
> > 
> > about two months have passed since Magnus posted this series.
> 
>    Time flies...
>    Dealing w/ the flash drivers turned into unending nightmare. :-(
> 
> > Do you have a timeline to address the problems?
> 
>    I'm looking into posting the bindings separately right now.
> The patch should be ready today or tomorrow.
> 
> > If so I believe> that the way forward should be to apply this series.
> 
>    Hm, not sure I understood you correctly. You're going to remove
> the device nodes even if I have a timeline?

Sorry, there was a typo in the above. Of course not.

Re: [PATCH/RFC 00/02] Remove undocumented IMR-LX4 device nodes

[Simon Horman]

On Wed, Mar 27, 2019 at 01:11:41PM +0100, Simon Horman wrote:
> On Mon, Mar 25, 2019 at 06:53:58PM +0300, Sergei Shtylyov wrote:
> > Hello!
> > 
> > On 03/25/2019 02:03 PM, Simon Horman wrote:
> > 
> > >>>>> On Mon, Jan 21, 2019 at 12:49 PM Magnus Damm <magnus.damm@gmail.com> wrote:
> > >>>>>> Remove undocumented IMR-LX4 device nodes
> > >>>>>>
> > >>>>>> [PATCH/RFC 01/02] arm64: dts: renesas: r8a7795: Remove IMR-LX4 device nodes
> > >>>>>> [PATCH/RFC 02/02] arm64: dts: renesas: r8a7796: Remove IMR-LX4 device nodes
> > >>>>>>
> > >>>>>> These patches take the easy way out and simply remove the undocumented
> > >>>>>> IMR-LX4 device nodes from the upstream tree. Good or bad, let me know!
> > >>>>>>
> > >>>>>> So perhaps this is a bit overly aggressive but since the DT bindings seem
> > >>>>>> undocumented and no driver exists in upstream my gut feeling says these DT
> > >>>>>> nodes were part of an upstreaming attempt that got suspended half-way through.
> > >>>>>>
> > >>>>>> In case DT binding documentation is in-flight and queued up somewhere
> > >>>>>> (ideally together with a driver) then feel free to ignore this series.
> > >>>>>>
> > >>>>>> Instead of removing nodes we could also document the DT bindings for the
> > >>>>>> IMR-LX4 devices. It would also make sense to add device nodes to other
> > >>>>>> more recent SoCs than just H3 and M3-W. But blindly adding more DT nodes
> > >>>>>> with a DT binding but without a driver seems a bit suboptimal compared to
> > >>>>>> testing against an actual driver.
> > >>>>>
> > >>>>> [PATCH v5] media: platform: Renesas IMR driver
> > >>>>> https://lore.kernel.org/linux-renesas-soc/20170309200818.786255823@cogentembedded.com/
> > >>>>
> > >>>> Thanks, but that seems to be from 2017! =)
> > >>>
> > >>>    I dropped the ball there, as I was tasked with upstreaming V3x support...
> > >>> The last thing done about the IMR driver was talking to Hans in Prague in
> > >>> 2017.  I'm planning to return to the driver after I'm done with the
> > >>> HyperFlash driver.
> > >>
> > >> Hi Sergei,
> > >>
> > >> I appreciate that we are not always in control of our own priorities,
> > >> indeed I sympathise with that predicament. However, we shouldn't really
> > >> be in a situation where DT is making use of undocumented bindings.
> > >>
> > >> I would like to ask for the bindings to be documented in the upstream
> > >> kernel in the near future. And if that is not possible I believe we
> > >> should consider temporarily removing their use in DT in the upstream kernel.
> > > 
> > > Hi Sergei,
> > > 
> > > about two months have passed since Magnus posted this series.
> > 
> >    Time flies...
> >    Dealing w/ the flash drivers turned into unending nightmare. :-(
> > 
> > > Do you have a timeline to address the problems?
> > 
> >    I'm looking into posting the bindings separately right now.
> > The patch should be ready today or tomorrow.
> > 
> > > If so I believe> that the way forward should be to apply this series.
> > 
> >    Hm, not sure I understood you correctly. You're going to remove
> > the device nodes even if I have a timeline?
> 
> Sorry, there was a typo in the above. Of course not.

Also, I now see
"[PATCH v2] dt-bindings: media: Renesas R-Car IMR bindings".

Thanks for working on this.