On Mon, May 27, 2019 at 12:23 AM Ahmad Fatoum <[email protected]> wrote: > > Hello, > > On 27/5/19 08:50, Andrey Smirnov wrote: > > On Sun, May 26, 2019 at 11:29 PM Ahmad Fatoum <[email protected]> > > wrote: > >> > >> Hello Andrey, > >> > >> On 26/5/19 23:55, Andrey Smirnov wrote: > >>> On Tue, May 21, 2019 at 8:56 AM Ahmad Fatoum <[email protected]> > >>> wrote: > >>>> > >>> This particular patch does break a non 6Q+ version of RDU2, but the > >>> follow up ones in the series fix it, so it seems that no action is > >>> really necessary on my part. > >> > >> The reparenting removed in this patch isn't reinstated by the rest of the > >> series. > >> They merely apply parentage expressed in the device tree in a glitch-free > >> manner. > >> > >> As both barebox and kernel imx6qdl-zii-rdu2.dtsi lack the relevant > >> assigned-clock-parents snippet, I am not sure what it is this patch broke > >> that the > >> follow-up ones fixed? > > > > Not sure, will investigate. > > Ok. > > > > >> > >> Generally, affected boards have been broken since day 1, because the LVDS > >> output > >> would've locked up every blue moon or so. If this patch breaks them, > >> they're just > >> more reliably broken. :-) > >> > > > > There's a world of difference between not working every once in a blue > > moon and not working from a first boot. > > Ye, the latter one can be dealt with on-the-spot. The other is much more > costly to > fix. >
Here's a different perspective: If you needed to make an urgent phone call, would you rather you phone didn't work every once in a blue moon or be broken for the get go? Thanks, Andrey Smirnov _______________________________________________ barebox mailing list [email protected] http://lists.infradead.org/mailman/listinfo/barebox
