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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx/ > > > > > > 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.
