On Mon, Oct 19, 2015 at 06:10:39PM +0200, Daniel Vetter wrote: > On Mon, Oct 19, 2015 at 08:13:05AM -0700, Greg KH wrote: > > On Mon, Oct 19, 2015 at 11:02:35AM +0300, Jani Nikula wrote: > > > On Sat, 17 Oct 2015, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Mon, Sep 28, 2015 at 10:09:11PM +0300, ville.syrjala@xxxxxxxxxxxxxxx wrote: > > > >> From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > >> > > > >> commit 58590c14d80defc94e900308a9d8fa55284de6f2 upstream. > > > > > > > > This is not the commit id of the patch below at all, I can't take this, > > > > please be more careful in the future. > > > > > > Greg, the commit message tries (and apparently fails) to explain that we > > > can't really backport all of the commits to fix this properly. > > > > Yeah, it failed at that, as this isn't the same patch, so please don't > > say that in the first line :( > > > > > The referenced upstream commit looks totally different because it > > > prevents us from entering the failing path to begin with. Since we can't > > > do that in stable, Ville was proposing to just the tune down the error > > > message, referencing the commit that gets rid of the error message > > > upstream. > > > > Why can't we do that in the stable tree? I _REALLY_ do not like taking > > patches that are different from what is in Linus's tree. It always > > burns us in the end, no matter how hard we try to prevent it... > > It shuts up a spurious error in dmesg about a feature which isn't even > implemented and took about 20+ patches to get right in Linus tree. Option > B is to waste reporters time if we leave that DRM_ERROR in there with > filing bugs that we'll close right away. There's no way we can backport > DVFS support without breaking the world. Ok, then document the heck out of this, as it is, the changelog text didn't match what was going on at all. greg k-h _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
