[GIT PULL] coresight: Fixes for v6.1

[Greg KH]

On Thu, Oct 20, 2022 at 10:41:07AM +0200, Greg KH wrote:
> On Wed, Oct 19, 2022 at 10:31:18PM +0100, Suzuki K Poulose wrote:
> > Greg,
> > 
> > Please find some of the fixes coresight drivers for v6.1.
> > The important ones are a couple for the CTI driver which
> > could cause hangs on a system with tracing.
> > 
> > Please pull,
> >        Suzuki
> > 
> > 
> > The following changes since commit 9abf2313adc1ca1b6180c508c25f22f9395cc780:
> > 
> >   Linux 6.1-rc1 (2022-10-16 15:36:24 -0700)
> > 
> > are available in the Git repository at:
> > 
> >  git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git tags/coresight-fixes-v6.1-1

Nit, this is not a valid URL to pull from.  Please fix for your next
submission.


> > 
> > for you to fetch changes up to 262068519b562dcf73297b2a75fb850342ba99e5:
> > 
> >   coresight: cti: Fix hang in cti_disable_hw() (2022-10-19 15:47:53 +0100)
> > 
> > ----------------------------------------------------------------
> > coresight: Fixes for v6.1
> > 
> > Fixes for coresight drivers for v6.1
> > 
> >   - Fix possible deadlock CTI mutexes (LOCKDEP)
> >   - Fix hang in CTI with runtime power management
> >   - Fix grammars in a comment
> >   - Use sysfs_emit() instead of scnprintf()
> 
> Sorry, but patch 2 here, doing the sysfs_emit() is not allowed.  That
> user has been banned from lore.kernel.org for sending patches through a
> random gmail account with no verification that they really are from ZTE
> at all.  Until we get proof from ZTE that this developer really is who
> they say they are, we can't take patches from them.
> 
> Please do not take any future patches from anyone sending from gmail.com
> that purports to be from ZTE until this is worked out.
> 
> Also, it's not a "fix" at all, and shouldn't be needed for 6.1-final at
> all.
> 
> I'll just drop that patch and regenerate this on my end to get the 3
> other fixes merged in here properly.

I'll also drop the grammer "fix" in here too, that's not needed for
6.1-final.

Also, the two other commits in here, do they need to go to stable trees?
I see no "Fixes:" or "cc: stable" markings on them at all.

How about you just regenerate the pull request with just the 2 patches
here that are valid and put proper Fixes: tags on them, then send me a
fixed up pull request.

thanks,

greg k-h