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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
