Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 13 Apr 2018 12:34:00 +0530
User-Agent: K-9 Mail for Android
In-Reply-To: <20180413062128.GA22147@kroah.com>
References: <20180413002951.155762-1-ghackmann@google.com> <F4A1736F-B00A-4EA6-94CD-BCD6CC7758C3@gmail.com> <20180413062128.GA22147@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PATCH] Revert "xhci: plat: Register shutdown for xhci_plat"
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC:     Greg Hackmann <ghackmann@google.com>,
        Adam Wallis <awallis@codeaurora.org>,
        Mathias Nyman <mathias.nyman@intel.com>,
        Badhri Jagan Sridharan <badhri@google.com>,
        linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
        stable@vger.kernel.org
From:   Harsh Shandilya <msfjarvis@gmail.com>
Message-ID: <663D81E0-C7F1-42BC-950C-803E508BD4ED@gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 13 April 2018 11:51:28 AM IST, Greg Kroah-Hartman <gregkh@linuxfoundatio=
n=2Eorg> wrote:
>On Fri, Apr 13, 2018 at 08:12:31AM +0530, Harsh Shandilya wrote:
>> On 13 April 2018 5:59:51 AM IST, Greg Hackmann <ghackmann@google=2Ecom>
>wrote:
>> >Pixel 2 field testers reported that when they tried to reboot their
>> >phones with some USB devices plugged in, the reboot would get wedged
>> >and
>> >eventually trigger watchdog reset=2E  Once the Pixel kernel team found
>a
>> >reliable repro case, they narrowed it down to this commit's 4=2E4=2Ey
>> >backport=2E  Reverting the change made the issue go away=2E
>>=20
>> Are you allowed to make the repro steps public? I'm writing this from
>> a walleye and would be grateful if I could test for this in the
>> modifed tree I'm running atm=2E  --=20
>
>I was told the steps are pretty simple:
>	- reboot the phone a lot
>eventually it will hang=2E  There's a fix in the code aurora kernel tree
>for this that they never sent upstream for some odd reason (they sent
>the first patch, why not the second?)
>
>I'll go revert this for now, thanks for the patch!
>
>greg k-h

That'd make sense, I only tried rebooting like five times before I had to =
run for a class=2E

As far as CAF is concerned, I feel the not submitting upstream, working ex=
tra to write patches which have usually better variants already upstream, s=
eems to be common=2E All USB changes were dropped when they merged kernel-c=
ommon into msm-3=2E18 with no real explanation which has been an annoyance =
more than once during merging -stable in my fork of msm-3=2E18=2E While I u=
nderstand their situation of maintaining upwards of 5 million lines of code=
 not upstream, it still feels sloppy to not merge stable updates and do ext=
ra work instead=2E /* End rant */
--=20
Harsh Shandilya, PRJKT Development LLC