Hi Guenter, On Thu, Sep 08, 2016 at 08:51:46AM -0700, Guenter Roeck wrote: > On Thu, Sep 8, 2016 at 3:29 AM, Heikki Krogerus > <heikki.krogerus@xxxxxxxxxxxxxxx> wrote: > > 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). Don't you have ACPI on your x86 machine? If ACPI is available, you can add _DSD method with the properties. I happy to help you write the ASL if needed. During testing, you can add it for example by modifying the DSDT or by introducing SSDT in initrd, or I think you can even inject AML at runtime. If ACPI or DT are not available, please use build-in properties. You can check for example drivers/usb/dwc3/dwc3-pci.c or drivers/mfd/intel-lpss-pci.c how they are used. And of course always only use the unified device property interface (so instead of using of_property_read... use device_property_read...), so your driver does not need to care about where the properties are coming from. But ideally we always get the properties from the platform without the need for build-in properties. In any case, at least no more platform data. Platform data is evil. Cheers, -- heikki -- 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
