| Message ID | 154807139502.25511.1919986589060151108.sendpatchset@octo (mailing list archive) |
|---|---|
| Headers | show |
| Series | Remove undocumented IMR-LX4 device nodes | expand |
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
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
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
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.
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.
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
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.
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.
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(-)