[linux-yocto] LTSI for 3.10 - Standard Practice

Bruce Ashfield bruce.ashfield at windriver.com
Tue Feb 11 21:22:38 PST 2014


On 2/11/2014, 7:38 PM, Hart, Darren wrote:
> On 2/11/14, 16:32, "Bruce Ashfield" <bruce.ashfield at windriver.com> wrote:
>
>> On 2/11/2014, 7:26 PM, Hart, Darren wrote:
>>> On 2/11/14, 16:11, "Bruce Ashfield" <bruce.ashfield at windriver.com>
>>> wrote:
>>>
>>>> On 2/11/2014, 7:06 PM, Hart, Darren wrote:
>>>>> On 2/11/14, 16:04, "Bruce Ashfield" <bruce.ashfield at gmail.com> wrote:
>>>>>
>>>>>> On Tue, Feb 11, 2014 at 5:50 PM, Hart, Darren <darren.hart at intel.com>
>>>>>> wrote:
>>>>>>> Bruce,
>>>>>>>
>>>>>>> While looking to update the MinnowBoard dora BSP I noticed that the
>>>>>>> minnow
>>>>>>> platform drivers Greg added to LTSI were not in standard/ltsi. Did
>>>>>>> you
>>>>>>> drop those in favor of the minnow-io feature?
>>>>>>
>>>>>> standard/ltsi is applied on top of the standard branch contents, and
>>>>>> since
>>>>>> we already had the minnow io features in there, I checked the patches
>>>>>> and went with the ones already in the standard branch.
>>>>>
>>>>> Ah, but I'm talking about minnow-io, which is not in the standard
>>>>> branch,
>>>>> it exists only in features/minnow-io (and greg's LTSI, but not
>>>>> standard/ltsi).
>>>>
>>>> Look again. When I merged LTSI, I had a 1:1 conflict with
>>>> patches already applied. So you may think that features/minnow-io
>>>> wasn't applied .. but it was.
>>>
>>> There are two things happening here.
>>>
>>> 1) The PCH_GBE and PCH_UART changes. Those were in standard/base and
>>> would
>>> have conflicted with LTSI.
>>>
>>> 2) The non-upstream minnow-io (drivers/platform/x86/minnow*) drivers.
>>> These are only in minnow-io, still.
>>>
>>> $ git rev-parse standard/ltsi
>>> e9cdab78bed262dbeadc7f403989f20972bcddde
>>>
>>> $ git rev-parse HEAD
>>> e9cdab78bed262dbeadc7f403989f20972bcddde
>>>
>>>
>>> $ ls drivers/platform/x86/minnow*
>>> ls: cannot access drivers/platform/x86/minnow*: No such file or
>>> directory
>>>
>>>
>>>
>>>
>>> $ git rev-parse meta
>>> 7fc16a9dc80bfdb8ebde9ba0f153e70e0c1f5f44
>>>
>>> $ git rev-parse HEAD
>>> 7fc16a9dc80bfdb8ebde9ba0f153e70e0c1f5f44
>>>
>>>
>>> # Sorry about this... Ugly :-)
>>> $ grep drivers/platform/x86/minnowboard
>>> meta/cfg/kernel-cache/features/minnow-io/*patch | cut -f2 -d ' ' | grep
>>> minnow | grep -ve "^b" | sort | uniq
>>> drivers/platform/x86/minnowboard-gpio.c
>>> drivers/platform/x86/minnowboard-gpio.h
>>> drivers/platform/x86/minnowboard-keys.c
>>> drivers/platform/x86/minnowboard.c
>>>
>>>
>>>
>>> So as far as I can tell, the minnow-io patches only exist in the
>>> minnow-io
>>> feature and have not been applied to standard/ltsi.
>>>
>>> Am I missing something?
>>
>> Hmm. I hit a full 8 pack of conflicts and confirmed against the patches
>> I had available.
>>
>> But thinking about that process, I was checking their existence in the
>> kernel-cache and may have assumed to much when I got deeper in the
>> conflicts .. maybe that's why I dislike unapplied patches so much ;)
>>
>> Have a look at the kernel-cache, and this block of the series file:
>>
>> ##patches.minnowboard/pch_uart-use-dmi-interface-for-board-detection.patch
>> ##patches.minnowboard/serial-pch_uart-remove-__initdata-annotation-from-dm
>> i_table.patch
>> ##patches.minnowboard/serial-pch_uart-fix-signed-ness-and-casting-of-uartc
>> lk-related-fields.patch
>> ##patches.minnowboard/serial-pch_uart-fix-compilation-warning.patch
>> ##patches.minnowboard/pch_gbe-convert-pr_-to-netdev_.patch
>> ##patches.minnowboard/pch_gbe-use-managed-functions-pcim_-and-devm_.patch
>> ##patches.minnowboard/pch_gbe-use-pch_gbe_phy_regs_len-instead-of-32.patch
>> ##patches.minnowboard/pci-add-circuitco-vendor-id-and-subsystem-id.patch
>> ##patches.minnowboard/pch_gbe-add-minnowboard-support.patch
>> ##patches.minnowboard/0001-gpio-sch-Add-sch_gpio_resume_set_enable.patch
>> ##patches.minnowboard/0002-minnowboard-Add-base-platform-driver-for-the-Mi
>> nnowB.patch
>> ##patches.minnowboard/0003-minnowboard-gpio-Export-MinnowBoard-expansion-G
>> PIO.patch
>> ##patches.minnowboard/0004-minnowboard-keys-Bind-MinnowBoard-buttons-to-ar
>> row-k.patch
>>
>> Which ones are you seeing that are missing ? I'll double check it myself
>> and pull in the missing ones.
>
> That would be the ones with the 000* prefix. Everything listed in
> minnow-io.scc:
>
>   cat meta/cfg/kernel-cache/features/minnow-io/minnow-io.scc
> # Depends on EG20T and Tunnel Creek GPIO (LPC, SCH, etc.)
> kconf hardware minnow-io.cfg
>
> patch 0001-gpio-sch-Add-sch_gpio_resume_set_enable.patch
> patch 0002-minnowboard-Add-base-platform-driver-for-the-MinnowB.patch
> patch 0003-minnowboard-gpio-Export-MinnowBoard-expansion-GPIO.patch
> patch 0004-minnowboard-keys-Bind-MinnowBoard-buttons-to-arrow-k.patch

Right, I had left these as an "on demand" feature in the kernel-cache,
but I'd rather have them integrated to avoid mistakes like this in
the future.

>
>
> If we add these to standard/ltsi, then we just need to drop the patches
> from the minnow-io fragment. Of course they will need to stay in the
> fragment for linux-yocto-dev as it won't have the LTSI bits and these
> patches will not go upstream as they are placeholders until there is
> proper device properties support in ACPI and the drivers can be updated to
> use that.
>
> If you prefer to leave these as patches in minnow-io.scc, I'm fine with
> that and will keep the BSP files consistent across versions.

I've added the 4 missing patches to standard/ltsi and then merged that
to all the branches. I've also commented out the patches in the minnow-io
feature .scc file on the meta branch. So any references to that feature
won't end up with patch failures.

I've also added the minnow-io feature to the -dev kernel (it was missing).

These are now pushed to the servers, and I'll send SRCREV updates along
with a few other pending patches shortly.

>
> I just noticed the gap and wanted to make sure it was intentional. How
> would you like to handle it?

See above :)

Bruce

>
> --
> Darren Hart
> Yocto Project - Linux Kernel
> Intel Open Source Technology Center
>
>
>



More information about the linux-yocto mailing list