All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Vladimir Yerilov <openmindead@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>, linux-usb@vger.kernel.org
Subject: Re: kernel NULL pointer dereference, ucsi bug
Date: Wed, 12 Jun 2019 17:05:34 +0300	[thread overview]
Message-ID: <20190612140534.GA2467@kuha.fi.intel.com> (raw)
In-Reply-To: <CAB31r6UkueG0wFz5genq=z0xNZNwymkxrxG4YXSWXH--VvEU2g@mail.gmail.com>

On Wed, Jun 12, 2019 at 10:57:35PM +1000, Vladimir Yerilov wrote:
> Oh, you are right. I meant... You know what I meant :)
> I hope the fix will get there eventually in one way or another. Should
> you need any further tests from my side, just ask and I will make my
> faulty machine work on it.
> 
> Thank you guys again for your kind assistance.

The patch I gave you does not fix the root cause, but instead just
works around it. The change it brings is however useful, so I'm going
to send the patch to the linux-usb ml as a fix for this issue.

I think the root problem in this case is that the firmware is
reporting the alternate modes in a customized way. The problem is
actually not with the firmware itself. The problem is with UCSI
specification. The UCSI spec does not explain how exactly the
alternate modes should be handled, so every platform does it a bit
differently (a major operating system does not seem to care about the
alternate modes).

The ucsi driver we have in kernel already considers a number of
different ways the alternate modes could be handled, but clearly not
the way Kaby Lakes handle them. I'm going to continue debugging this
with a Kaby Lake board, and once/if I figure out how to manage the
alternate modes on it, I'll send the final fix. But for now, let's
workaround the problem.


thanks,

-- 
heikki

      reply	other threads:[~2019-06-12 14:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-02 11:24 kernel NULL pointer dereference, ucsi bug Vladimir Yerilov
2019-06-03 13:12 ` Greg KH
2019-06-03 14:58   ` Vladimir Yerilov
2019-06-04  5:40     ` Greg KH
2019-06-05  6:36       ` Vladimir Yerilov
2019-06-05 16:58         ` Greg KH
2019-06-06  9:36           ` Vladimir Yerilov
2019-06-06 16:58           ` Vladimir Yerilov
2019-06-10  3:48             ` Vladimir Yerilov
2019-06-10 14:32             ` Greg KH
2019-06-10 14:57               ` Vladimir Yerilov
2019-06-11  7:06               ` Heikki Krogerus
2019-06-11  7:54 ` Heikki Krogerus
     [not found]   ` <CAB31r6V+PYppYJz29u_hfpiL6xqhhe+-2xZTRpqOmpLrtCdh8Q@mail.gmail.com>
2019-06-12  9:55     ` Heikki Krogerus
2019-06-12 12:23       ` Vladimir Yerilov
2019-06-12 12:32         ` Greg KH
2019-06-12 12:57           ` Vladimir Yerilov
2019-06-12 14:05             ` Heikki Krogerus [this message]

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=20190612140534.GA2467@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=openmindead@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.