[linux-yocto] [PATCH 00/15] Intel Axxia updates to linux-yocto-4.1

[Bruce Ashfield]

On 16-01-08 10:51 AM, Daniel Dragomir wrote:
> Hi Bruce,
>
> Please apply this series of fixes to Axxia platform drivers on
> the standard/axxia/base branch from linux-yocto-4.1.
> This series of patches brings various improvements and warning fixes
> to the Intel Axxia drivers including MISC, PCI, FEMAC, SPI/PL022, GPDMA
> and device trees.
>
> Bruce, I also have 2 questions:
> Why there is no preempt-rt branch for axxia? There is somethimg else we
> (axxia team) need to provide?

There is a preempt-rt branch for axxia. I created it in December
when I heard that the axxia had been tested against -rt and all
was well.

I just applied these changes to both standard and -rt:

To ssh://git@git.yoctoproject.org/linux-yocto-4.1.git
    43eb4b9e7be4..b7ab684f37ea  standard/axxia/base -> standard/axxia/base
    1ab6bfefd66f..606adeec8d66  standard/preempt-rt/axxia/base -> 
standard/preempt-rt/axxia/base


>
> Axxia team keep in their Github repos some defconfig files in arch/<ARCH>/configs,
> not full configs, only fragments that are just like the ones that are already in
> the yocto repo in the same location. Those are used when the kernel is built
> standalone with make. When the kernel is built with bitbake, fragments from meta-axxia
> layer and from meta branch (or yocto-kernel-cache repo) are used.
> At each rebase, we need to save and (re)add those files to our repo to be able to
> keep and maintain those.
> There is a posibility to have those defconfig files in the yocto repo also? It will
> be easier to maintain and keep them. At least some of them, the standard and debug
> defconfigs. We have, for 4.1 the folowing defconfigs:

That set of defconfigs, shows some of the most significant issue
with defconfigs. The number of them, and the churn to keep them
updated.

And by fragments, not defconfigs, do you mean that they are not
full configs, but are otherwise single file configs for the kernel
(that are largely just not tracking default values for options ?
aka savedefconfig ?).

The problem with maintaining the defconfigs in the linux-yocto
tree, is ensuring that they are kept in sync, the risk of divergence
from standard features shared by the other BSPs .. and that they'll
be used "out of habit".

We can easily construct configs from fragments without involving
bitbake or the rest of the build system. So out of curiosity, is it
end users, or developers that are the main consumer of the defconfigs ?

Bruce

>
> arch/arm/configs/axxia_5500_dbg_defconfig
> arch/arm/configs/axxia_5500_defconfig
> arch/arm/configs/axxia_5500_nosmp_dbg_defconfig
> arch/arm/configs/axxia_5500_nosmp_defconfig
> arch/arm/configs/axxia_5500_rt_dbg_defconfig
> arch/arm/configs/axxia_5500_rt_defconfig
> arch/arm/configs/axxia_5500_rt_nosmp_dbg_defconfig
> arch/arm/configs/axxia_5500_rt_nosmp_defconfig
> arch/arm64/configs/axxia_x9_dbg_defconfig
> arch/arm64/configs/axxia_x9_defconfig
> arch/arm64/configs/axxia_x9_nosmp_dbg_defconfig
> arch/arm64/configs/axxia_x9_nosmp_defconfig
> arch/arm64/configs/axxia_x9_rt_dbg_defconfig
> arch/arm64/configs/axxia_x9_rt_defconfig
> arch/arm64/configs/axxia_x9_rt_nosmp_dbg_defconfig
> arch/arm64/configs/axxia_x9_rt_nosmp_defconfig
> arch/arm64/configs/axxia_xlf_dbg_defconfig
> arch/arm64/configs/axxia_xlf_defconfig
> arch/arm64/configs/axxia_xlf_nosmp_dbg_defconfig
> arch/arm64/configs/axxia_xlf_nosmp_defconfig
> arch/arm64/configs/axxia_xlf_rt_dbg_defconfig
> arch/arm64/configs/axxia_xlf_rt_defconfig
> arch/arm64/configs/axxia_xlf_rt_nosmp_dbg_defconfig
> arch/arm64/configs/axxia_xlf_nosmp_defconfig
> arch/arm64/configs/axxia_xlf_rt_dbg_defconfig
> arch/arm64/configs/axxia_xlf_rt_defconfig
> arch/arm64/configs/axxia_xlf_rt_nosmp_dbg_defconfig
> arch/arm64/configs/axxia_xlf_rt_nosmp_defconfig
>
> Thank you,
> Daniel
>
> John Jacques (15):
>    drivers/dma: Remove Unused Code in the LSI GPDMA Driver
>    drivers/clk: Remove Warnings in Axxia Clock Driver
>    drivers/power: Cleanup Warnings in Axxia Reset Code
>    drivers/spi: Cleanup Warnings in PL022 Driver
>    drivers/net: Fix Compiler Warnings in the Axxia FEMAC Driver
>    pmu: Fix Compiler Warnings
>    arch/arm: Fix Compiler Warnings
>    drivers/misc: Fix Compile Warnings in the Axxia MTC Driver
>    arch/arm/mach-axxia: Fix Compile Warnings
>    arch/arm: Backport a Change to Fix Compiler Warnings
>    include/linux: Resolve Compile Warning
>    drivers/pci: Fix Error in Axxia PCIe Code
>    arch/arm: Fix Build Failure When CONFIG_SMP=n
>    drivers/misc: Fix Compile Warning in Axxia MTC Driver
>    axxia: Device Tree Updates
>
>   arch/arm/include/asm/cmpxchg.h             |  18 +-
>   arch/arm/include/asm/kmap_types.h          |   6 +-
>   arch/arm/mach-axxia/axxia.c                |   2 +-
>   arch/arm64/boot/dts/intel/axc67xx-sim.dtsi | 566 -----------------------------
>   arch/arm64/boot/dts/intel/axm5604-sim.dts  |   8 -
>   arch/arm64/boot/dts/intel/axm56xx-sim.dtsi | 393 --------------------
>   drivers/clk/clk-axm5516.c                  |   2 +-
>   drivers/dma/lsi-dma32.c                    |  44 ---
>   drivers/misc/lsi-mtc.c                     |   4 +-
>   drivers/net/ethernet/lsi/lsi-femac.c       |  53 +--
>   drivers/pci/host/axxia_pci.c               |   5 +-
>   drivers/power/reset/axxia-reset.c          |   2 +-
>   drivers/spi/spi-pl022.c                    |  51 ---
>   include/linux/blkdev.h                     |   2 +-
>   include/linux/pmu.h                        |   1 +
>   15 files changed, 35 insertions(+), 1122 deletions(-)
>   delete mode 100644 arch/arm64/boot/dts/intel/axc67xx-sim.dtsi
>   delete mode 100644 arch/arm64/boot/dts/intel/axm56xx-sim.dtsi
>