On Thu, Sep 8, 2016 at 3:29 AM, Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx> wrote: > Hi Steve, > > On Wed, Sep 07, 2016 at 10:00:28PM -0400, Steve Schefter wrote: >> Hi Heikki. >> >> I'm seeing an issue with the USB-C TCPCI driver. On startup, I get a panic >> with the following error and stack dump. >> >> Unable to handle kernel NULL pointer dereference at virtual address 0000002c >> >> [<ffffffc0006e88a8>] tcpm_register_port+0x228/0x3b0 >> [<ffffffc0006ea4f8>] tcpci_probe+0x1c8/0x1fc >> [<ffffffc000718260>] i2c_device_probe+0x12c/0x160 >> >> The problem seems to stem from the fact that tcpci->tcpc.config is not >> initialized in the TCPCI driver. It is NULL due to tcpci being allocated >> using devm_kzalloc(). This causes a problem when tcpm_register_port() >> attempts to access port->tcpc->config->type. >> >> Am I missing something? I understand that this is a work in progress, but >> it looks like this should happen for everyone. Some I'm wondering if I'm >> missing something dumb. > > I believe you are trying Guenter's (CCd) Type-C Port Manager series. > He is the correct best person to answer questions about that. But that > series is RFC, so you can't really expect everything to be in place. > It is more like proof of concept at this point. > I think (hope) I did mention that the tcpci patch was compile tested only. Apologies if not. I'll try to get to it today and send a fix, though it will obviously only be a workaround (config data is platform specific). I also hope I can send a Reviewed-by: for Heikki's series today. Sorry for being late on that one. > But we probable need to talk about how to extract the platform > specific details needed for the config in any case (and also what > exactly is needed) at one point. I think we can get all of them with > device properties regardless of the system (ACPI/DT/whatever), so > we would just need to agree on the what the properties are. > Yes, we'll definitely need that. I've used platform data and DMI internally for x86, but that seems so out of date. I'll also see if it makes sense to attach the test driver I used to test the tcpm code. Note that we also have a driver for fusb302 as client of tcpm in the works, plus an extcon based driver connected to the EC on chromebooks (and ties directly into the Type-C infrastructure). Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
