[Buildroot] [PATCH] [RFC] platform: update galileo to 3.14 kernel

[Andy Shevchenko]

On Mon, 2016-08-29 at 10:20 +0000, Connolly, Padraig wrote:
> Hi Thomas,
> 
> Currently there is support for the Quark X1000 SoC itself in the
> upstream Linux Kernel 
> but support for the Galileo Gen 1/2 is not fully upstream, there is a
> Galileo platform driver that is not upstream.
> There is also some fixes that affect the USB behavior that are not
> upstream either.
> 
> This means anything supported by the platform driver will not work
> with the upstream kernel, 
> for example GPIO, I2C, and SPI. 

What is the "Galileo platform driver"? I'm pretty sure everything listed
above is working in upstream and you are actually talking about
_external_ (to Quark SoC) pinctrl driver which is indeed absent as any
means of pinmuxing run-time in upstream.

I have no idea if it goes to category "reasonable support", though mention issue is applied to all similar boards (UP, Edison/Arduino, ...).


Comments below are not exactly related to Buildroot.

>  USB device support is also less reliable without the fix.

Is the fix going to be upstreamed?

> 
> You can find the platform driver in our GitHub repo here : 
> https://github.com/padraigconnolly/Linux-
> x1000/tree/master/drivers/platform/x86/intel-quark

Looking into this I can say the driver is not for upstream. The upstream
drivers should utilize ACPI as much as possible, besides that fact I
mentioned about pinctrl.


On Mon, 2016-08-29 at 12:15 +0100, Kinsella, Ray wrote:
> Specifically the use of the platform driver was a result of broken
> ACPI 
> support on the Galileo platforms. The DSDT table doesn't accurately 
> describe the platform devices on these platforms, breaking the GPIO
> etc.

I do understand that.

> 
> Once the platform was in the wild with the DSDT broken table, the
> only 
> way to be sure that any given platform would work correctly was to
> use 
> the platform driver.

Nope. There are two mechanisms now to override and upgrade the ACPI
table(s). Somewhere (Ostro?) I saw a direction to a right way.

> 
> 
> Thanks,
> Padraig Connolly
> 
> -----Original Message-----
> 
> Hello,
> 
> On Tue, 23 Aug 2016 08:05:15 +0000, Connolly, Padraig wrote:
> 
> > 
> > Could you elaborate on this preference please, in the previous
> > version 
> > for the Galileo the defconfig pulled the kernel in a similar way I 
> > have done.  The future plan is once everything is approved, we will 
> > update R. Kinsella's repo with the 3.14 kernel and the defconfig
> > will 
> > pull from there instead of mine as it did before.  I'm only using
> > my 
> > repo as a temp for working on.
> 
> It's pretty simple:
> 
>  - If a platform has reasonable support in the mainline Linux kernel,
>    then we prefer if our defconfigs use the mainline Linux kernel. By
>    "reasonable" support, I mean support with sufficient features for
>    the platform to actually be useful.
> 
>  - If a platform doesn't have reasonable support in the mainline Linux
>    kernel, then we accept defconfigs that use other Linux kernel trees
>    (from vendors, or community maintained, etc.).


-- 
Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Intel Finland Oy