On Tue, 2017-04-25 at 12:53 +0200, Jan Kiszka wrote: > On 2017-04-25 11:42, Andy Shevchenko wrote: > > > Where is a good example? Sorry, > > > I still don't see how to make code out of your comments. > > > > Mostly remove those ugly hacks and start over. > > Still not a constructive answer. You just didn't get. Provide a driver without that ugly code and then we may think how to make it work on existing boards without too much intrusion here or there. > > CS is a property of the host controller, not the slave devices. > > > > Once I pointed to Mika's work for Galileo, perhaps you forgot. The > > below is an example how to fix ACPI table using > > > > https://github.com/westeri/meta-acpi/blob/master/recipes-bsp/acpi-ta > > bles/samples/galileo/spi.asl > > > > It's done for SPI1, but you easily can convert it to SPI0 and > > corresponding properties. > > So that information would be picked up by the existing SPI host > controller driver, and we don't need anything beyond basic ACPI > support > in this driver? Correct! > That is indeed appealing. Maybe we can make the board > patch private then, until a firmware update is available. I'll split > that part off. Yes, that is what I meant. > > Btw, we welcome any contribution to meta-acpi repository! > > Shipping own DSDTs is no long-term path: we would be forced to provide > separate images due to a single parameter being different in the DSDTs > of the 2020 and 2040. And you cannot provide any overlay to adjust the > table after boot, i.e. once we know on which board we are. > > The dependency on meta-intel is also suboptimal (we will switch to a > long-term supported kernel source soon), but that would probably be > fixable. Mika, do you have anything to comment on the above? -- Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
