public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ivan Mironov <mironov.ivan@gmail.com>
To: linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Martin Liu <liumartin@google.com>,
	YueHaibing <yuehaibing@huawei.com>,
	Mathias Nyman <mathias.nyman@linux.intel.com>,
	Nicolas Boichat <drinkcat@chromium.org>,
	Jon Flatley <jflat@chromium.org>,
	Kai-Heng Feng <kai.heng.feng@canonical.com>,
	Benson Leung <bleung@chromium.org>,
	Harry Pan <harry.pan@intel.com>,
	Jack Stocker <jackstocker.93@gmail.com>,
	Danilo Krummrich <danilokrummrich@dk-develop.de>,
	Samuel Sadok <samuel.sadok@bluewin.ch>,
	Ivan Mironov <mironov.ivan@gmail.com>
Subject: [RFC PATCH 0/2] Fix for the internal card reader and suspend on MacBooks
Date: Thu, 14 Feb 2019 02:13:21 +0500	[thread overview]
Message-ID: <20190213211323.6072-1-mironov.ivan@gmail.com> (raw)

Hi all,

There is a known problem on some MacBooks: internal card reader
disappears after the first suspend/resume and all subsequent attempts
to suspend laptop are failing.

This was reported[1][2] and even discussed in the mailing lists[3],
without any real solution. After trying various things[4], including
some existing quirks, I discovered that switching link state to DISABLED
before suspend both fixes the card reader device and allows any subsequent
suspend to succeed.

First patch adds code for this new quirk, and second patch enables this
quirk for card reader device which is used in my macbook.

I'm not really familiar with either USB standards or kernel code to
support them, so this patch series is RFC. I'm especially unsure with the
"resume" part, because I implemented it by trial and error mostly.
However, I'm using kernel with these patches and it works for me.

Also, feel free to suggest other kernel patches or existing quirks or
quirk combinations to fix the same problem.

Oh, and by the way: I've checked schematics of various macbooks available
on the internet. It seems that the actual chip is Genesys Logic GL3219,
probably just with the custom ID. What I found curious, is that USB 2.0
pins of this chip (D+ and D-) are not really connected anywhere, but
instead shorted through the resistor. Could it be possible that this
somehow messes up some logic inside the device, host controller or
linux kernel?

[1] https://bugzilla.kernel.org/show_bug.cgi?id=111201
[2] https://bugzilla.kernel.org/show_bug.cgi?id=202509
[3] https://www.spinics.net/lists/linux-usb/msg164261.html
[4] https://github.com/im-0/investigate-card-reader-suspend-problem-on-mbp11.4

Ivan Mironov (2):
  usb: core: Add support of disabling SS link before system suspend
  usb: quirks: Add quirk to fix card reader and suspend on MacBooks

 drivers/usb/core/driver.c  |  6 +++
 drivers/usb/core/hub.c     | 84 ++++++++++++++++++++++++++++++++++++--
 drivers/usb/core/quirks.c  |  7 ++++
 include/linux/usb.h        |  3 ++
 include/linux/usb/quirks.h |  9 ++++
 5 files changed, 105 insertions(+), 4 deletions(-)

-- 
2.20.1


             reply	other threads:[~2019-02-13 21:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-13 21:13 Ivan Mironov [this message]
2019-02-13 21:13 ` [RFC PATCH 1/2] usb: core: Add support of disabling SS link before system suspend Ivan Mironov
2019-02-13 21:13 ` [RFC PATCH 2/2] usb: quirks: Add quirk to fix card reader and suspend on MacBooks Ivan Mironov
2019-02-14  1:40 ` [RFC PATCH 0/2] Fix for the internal " Ivan Mironov
2019-02-14 17:32   ` Ivan Mironov
2019-02-25 13:52     ` Ivan Mironov
2019-02-14 15:03 ` Mathias Nyman
2019-02-14 17:20   ` Ivan Mironov
2019-02-18 18:50 ` Eric Blau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190213211323.6072-1-mironov.ivan@gmail.com \
    --to=mironov.ivan@gmail.com \
    --cc=bleung@chromium.org \
    --cc=danilokrummrich@dk-develop.de \
    --cc=drinkcat@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=harry.pan@intel.com \
    --cc=jackstocker.93@gmail.com \
    --cc=jflat@chromium.org \
    --cc=kai.heng.feng@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=liumartin@google.com \
    --cc=mathias.nyman@linux.intel.com \
    --cc=samuel.sadok@bluewin.ch \
    --cc=stern@rowland.harvard.edu \
    --cc=yuehaibing@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox