November 2019 - U-Boot

[U-Boot] [PATCH 0/2] net: macb: support arbitrary mdio addresses
by Josef Holzmayr 30 Nov '19

30 Nov '19

This patch mini-series enables the macb driver to access all addresses on the mdio bus instead of only the one of the connected phy. This is especially useful if you have a tagging switch connected to the macb. Josef Holzmayr (2): net: macb: explicitly pass phy_adr to mdio read and write net: macb: let miiphy_read/_write pass arbitrary addresses drivers/net/macb.c | 39 +++++++++++++++++---------------------- 1 file changed, 17 insertions(+), 22 deletions(-) -- 2.23.0 -- _____________________________________________________________ R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen Fon: +49 8444 9204-0 Fax: +49 8444 9204-50 www.rsi-elektrotechnik.de _____________________________________________________________ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548

2 4

[U-Boot] [PATCH] net: phy: Increase link up delay in genphy_update_link()
by Stefan Roese 30 Nov '19

30 Nov '19

I've noticed that in most cases when genphy_update_link() is called, the ethernet driver (mt7628-eth in this case) fails with the first ethernet packets. Resulting in a timeout of the first tftp command. Increasing the delay in the link check look from 1 to 50 ms and moving it below the BMSR register read fixes this issue, resulting in a stable ethernet traffic, even after initial link autonogotiation. Signed-off-by: Stefan Roese <sr(a)denx.de> Cc: Weijie Gao <weijie.gao(a)mediatek.com> Cc: Joe Hershberger <joe.hershberger(a)ni.com> --- drivers/net/phy/phy.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index ae37dd6c1e..18e5ebd29c 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -256,11 +256,11 @@ int genphy_update_link(struct phy_device *phydev) return -EINTR; } - if ((i++ % 500) == 0) + if ((i++ % 10) == 0) printf("."); - udelay(1000); /* 1 ms */ mii_reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMSR); + mdelay(50); /* 50 ms */ } printf(" done\n"); phydev->link = 1; -- 2.23.0

2 1

[U-Boot] [PATCH] net: rtl8169: Support RTL-8168c/8111c
by Thierry Reding 30 Nov '19

30 Nov '19

From: Thierry Reding <treding(a)nvidia.com> This version of the RTL-8168 chip can be found on some add-in cards sold by CSL-Computer GmbH & Co. KG. The chip isn't special in any way, but it needs to have the ChipCmd register programmed after the DMA descriptors have been set up, so make sure that happens by adding an entry to the chip information table. Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- drivers/net/rtl8169.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c index 521e5909a256..d887d00928f6 100644 --- a/drivers/net/rtl8169.c +++ b/drivers/net/rtl8169.c @@ -252,6 +252,7 @@ static struct { {"RTL-8169sc/8110sc", 0x18, 0xff7e1880,}, {"RTL-8168b/8111sb", 0x30, 0xff7e1880,}, {"RTL-8168b/8111sb", 0x38, 0xff7e1880,}, + {"RTL-8168c/8111c", 0x3c, 0xff7e1880,}, {"RTL-8168d/8111d", 0x28, 0xff7e1880,}, {"RTL-8168evl/8111evl", 0x2e, 0xff7e1880,}, {"RTL-8168/8111g", 0x4c, 0xff7e1880,}, -- 2.23.0

2 1

[U-Boot] [PATCH v4 0/5] Switch MVPP2 to use new MVMDIO
by nhed+uboot＠starry.com 30 Nov '19

30 Nov '19

From: Nevo Hed <nhed+github(a)starry.com> This patchset includes a couple of commits form Marvell's downstream repo and a change to replace mvpp2's SMI implementation with the new MVMDIO driver. The mvpp2 change is based partially on Ken Ma's mods against an earlier (his) version of MVMDIO that never made it to upstream and has since been re-implemented by Alex Marginean and seems to be in line for inclusion [1]. Puicked a few other mvpp2 patches from the afformentioned Marvell repo as they seemed important yet missing from upstream. Changes since v3: - Squashed the NULL dereference fix - Fixed multi-line comment format - Squashed the two mvpp2.c changes to use MVMDIO tinto a single one that can stand on its own. Changes since v2: - Removed `Reviewed-on` lines from Marvell commits, they are meaningless in upstream U-Boot - Commit messages rewording - Split out Kconfig (select of MVMDIO & DM_MDIO by MVPP2) - reworded heading on dtsi change to match last commit (due to noticing no delegates weere listed on patchworks) Changes since v1: - removes a redaundant fixed-link patch [1] https://patchwork.ozlabs.org/cover/1136769/ Grzegorz Jaszczyk (1): net: mvpp2: mark phy as invalid in case of missing appropriate driver Nevo Hed (3): arm: dts: armada-cp110-*dtsi: add xmdio nodes net: mvpp2: use new MVMDIO driver net: mvpp2: MVPP2 now needs MVMDIO Stefan Chulski (1): net: mvpp2x: fix traffic stuck after PHY start error arch/arm/dts/armada-cp110-master.dtsi | 9 + arch/arm/dts/armada-cp110-slave.dtsi | 9 + drivers/net/Kconfig | 2 + drivers/net/mvpp2.c | 241 ++++++-------------------- 4 files changed, 73 insertions(+), 188 deletions(-) -- 2.21.0

3 15

[U-Boot] [PATCH] drivers: net: fsl_enetc: register internal MDIO bus
by Alex Marginean 30 Nov '19

30 Nov '19

This bus is used to access internal SoC PHYs. These PHYs are configured by the ENETC driver directly, but it's useful to have command line access to this MDIO to debug the system especially when using new external PHYs. Signed-off-by: Alex Marginean <alexandru.marginean(a)nxp.com> --- drivers/net/fsl_enetc.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c index e86f3dddb5..02c1ee70d9 100644 --- a/drivers/net/fsl_enetc.c +++ b/drivers/net/fsl_enetc.c @@ -156,19 +156,14 @@ static void enetc_start_pcs(struct udevice *dev) priv->if_type = PHY_INTERFACE_MODE_NONE; - /* check internal mdio capability, not all ports need it */ + /* register internal MDIO for debug purposes */ if (enetc_read_port(priv, ENETC_PCAPR0) & ENETC_PCAPRO_MDIO) { - /* - * set up internal MDIO, this is part of ETH PCI function and is - * used to access serdes / internal SoC PHYs. - * We don't currently register it as a MDIO bus as it goes away - * when the interface is removed, so it can't practically be - * used in the console. - */ priv->imdio.read = enetc_mdio_read; priv->imdio.write = enetc_mdio_write; priv->imdio.priv = priv->port_regs + ENETC_PM_IMDIO_BASE; strncpy(priv->imdio.name, dev->name, MDIO_NAME_LEN); + if (!miiphy_get_dev_by_name(priv->imdio.name)) + mdio_register(&priv->imdio); } if (!ofnode_valid(dev->node)) { @@ -451,6 +446,10 @@ static void enetc_stop(struct udevice *dev) { /* FLR is sufficient to quiesce the device */ dm_pci_flr(dev); + /* leave the BARs accessible after we stop, this is needed to use + * internal MDIO in command line. + */ + dm_pci_clrset_config16(dev, PCI_COMMAND, 0, PCI_COMMAND_MEMORY); } /* -- 2.17.1

2 1

[U-Boot] [PATCH 1/3] drivers: net: fsl_enetc: Add 2.5Gbps to supported link speeds
by Alex Marginean 30 Nov '19

30 Nov '19

The original code enabled link speeds up to 1Gbps, but the interface can go up to 2.5G, enable that speed to in PHY AN mask. Signed-off-by: Alex Marginean <alexandru.marginean(a)nxp.com> --- I have these patches on top of the following two patch sets, they don't apply cleanly without them: https://patchwork.ozlabs.org/project/uboot/list/?series=142879 https://patchwork.ozlabs.org/project/uboot/list/?series=142858 drivers/net/fsl_enetc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c index c94ba240f8..64dc244da2 100644 --- a/drivers/net/fsl_enetc.c +++ b/drivers/net/fsl_enetc.c @@ -215,8 +215,9 @@ static void enetc_config_phy(struct udevice *dev) if (!priv->phy) return; - supported = GENMASK(6, 0); /* speeds up to 1G & AN */ - priv->phy->advertising = priv->phy->supported & supported; + supported = PHY_GBIT_FEATURES | SUPPORTED_2500baseX_Full; + priv->phy->supported &= supported; + priv->phy->advertising &= supported; phy_config(priv->phy); } -- 2.17.1

2 5

[U-Boot] [PATCH v3 00/11] Add XFI, USXGMII net protocols, use them in Aquantia driver
by Alex Marginean 30 Nov '19

30 Nov '19

There are several plaforms that use XFI and/or USXGMII protocols but declare them as XGMII in U-Boot because that's already defined. These protocols are not identical and in some cases specific configuration has to be applied for each of them. This patch series introduces XFI and USXGMII and updates the Aquantia PHY driver to use them, in addition to the existing XGMII. Currently AQR PHYs rely exclusively on firmware to configure system side protocols as well as a few other parameters, which means that FW has to be replaced on the PHY when switching between SGMII, SGMII-2.5G, XFI, USXGMII. This patch set adds support to the driver to reconfigure the system interface protocol based on the interface selected by the ethernet driver (typically picked up from DT). Additional configuration (mdi-reversal, smb-addr) is also picked up by Aquantia driver from the PHY DT node, if present from a couple of newly defined properties. The new aquantia DT attributes are documented in a new binding document. Also added a generic PHY node binding document using content from Linux. And last, update ENETC to use the new interface types. This patch set supersedes v2: https://patchwork.ozlabs.org/project/uboot/list/?series=124595 Changes in v3: - It seems some Gen1 Aquantia PHYs don't behave well when put in low power and we're not even reconfiguring Gen1 PHYs anyway, so just leave them alone. - Changed subject and description in cover letter. - Other minor changes. Changes in v2: - Flip USX AN bit both ways as needed, in v1 it was only set for USXGMII but not reset for XFI - Use CONFIG_DM_ETH instead of CONFIG_OF_CONTROL around the codeu using phydev->node - Use variable name interface instead of if_type for consistency with the rest of the code. Alex Marginean (11): include: phy: define XFI and USXGMII interface types include: phy: add data field for private driver data drivers: net: aquantia: use XFI, USXGMII interface types drivers: net: aquantia: add PHY generation information drivers: net: aquantia: set up SI protocol based on interface type drivers: net: aquantia: set MDI reversal based on DT property drivers: net: aquantia: set SMBus addr based on DT property drivers: net: aquantia: check system interface too when checking for link up doc: bindings: add bindings document for PHY nodes doc: bindings: Aquantia PHY node binding drivers: net: fsl_enetc: use XFI, USXGMII interface type macros doc/device-tree-bindings/net/aquantia-phy.txt | 25 ++ doc/device-tree-bindings/net/phy.txt | 24 ++ drivers/net/fsl_enetc.c | 2 + drivers/net/phy/aquantia.c | 226 ++++++++++++++++-- include/phy.h | 3 + include/phy_interface.h | 4 + 6 files changed, 265 insertions(+), 19 deletions(-) create mode 100644 doc/device-tree-bindings/net/aquantia-phy.txt create mode 100644 doc/device-tree-bindings/net/phy.txt -- 2.17.1

2 22

[U-Boot] [PATCH v5 0/3] Add helper function for linking a DM Eth device to a PHY
by Alex Marginean 30 Nov '19

30 Nov '19

The patch set introduces dm_eth_phy_connect which takes in an ethernet device and uses DT information to find the associated PHY and connect the Ethernet interface to it. This should simplify similar code in ethernet drivers. I've dropped the new binding for scanning an MDIO bus, I'll look into reworking that to match the behavior in Linux. The changes are more extensive though and I plan to do that in a separate submission. Finally the patch set updates fsl_enetc driver to use the new helper function reducing the code by about 30 lines. This patch set supersedes v3 series: https://patchwork.ozlabs.org/project/uboot/list/?series=140114 and v4 series: https://patchwork.ozlabs.org/project/uboot/list/?series=142858 Changes in v5: - drop mdio-handle binding - support alternative/obsolete bindings (like 'phy', 'phy-device') Changes in v4: - rebased on current head Changes in v3: - added cover letter - check for null PHY pointer before using it in dm_eth_connect_phy_handle - moved the code dealing with MDIO scanning into a separate patch - renames several arguments and variables for a bit more clarity and consistency Changes in v2: - Moved MDIO scan code into dm_mdio_phy_scan which is also exported - Use interface instead of if_type for consistency - don't use phy pointer if NULL in fsl_enetc code Alex Marginean (3): net: mdio-uclass: rename arguments of dm_mdio_phy_connect for clarity net: mdio-uclass: add dm_eth_phy_connect helper function drivers: net: fsl_enetc: use the new MDIO DM helper functions drivers/net/fsl_enetc.c | 53 ++++----------------- drivers/net/fsl_enetc.h | 1 + include/miiphy.h | 18 +++++-- net/mdio-uclass.c | 102 ++++++++++++++++++++++++++++++++++++++-- 4 files changed, 122 insertions(+), 52 deletions(-) -- 2.17.1

2 6

Re: [U-Boot] [PATCH v1] gcc-9: silence 'address-of-packed-member' warning
by Simon Goldschmidt 29 Nov '19

29 Nov '19

[bringing this back to the list, seems like I accidentally hit the single reply button before] On 29.11.19 21:02, Andy Shevchenko wrote: > On Fri, Nov 29, 2019 at 06:56:44PM +0100, Simon Goldschmidt wrote: >> Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> schrieb am Fr., 29. >> Nov. 2019, 18:48: >> >>> GCC 9.x starts complaining about potential misalignment of the pointer to >>> the array (in this case alignment=2) in the packed (alignment=1) >>> structures. >>> >>> Repeating Linus' Torvalds commit 6f303d60534c in the Linux kernel. >>> >>> Original commit message: >>> >>> We already did this for clang, but now gcc has that warning too. >>> Yes, yes, the address may be unaligned. And that's kind of the point. >>> >>> This in particular hides the warnings like >>> >>> drivers/usb/gadget/composite.c:545:23: warning: taking address of packed >>> member of ‘struct usb_string_descriptor’ may result in an unaligned pointer >>> value [-Waddress-of-packed-member] >>> 545 | collect_langs(sp, s->wData); >>> >> >> Is it really ok to hide this warning? This address is used for an u16 >> pointer later, so it needs to be aligned. How do we ensure that wData is >> correctly aligned? > > Why should it be? Because this code is working on a packed struct, which may be unaligned. If it's not, why not remove packing on struct usb_string_descriptor instead of silencing this warning altogether? > It worked before it will work after. Who guarantees this struct is aligned/will stay aligned in the future? Most of the platforms I know nowadays do work with unaligned access but are slow, so I think having the compiler warn here is good, no? > >> I took a different approach and fixed the called function to use byte >> access: >> >> https://patchwork.ozlabs.org/patch/1199138/ > > So, that commit can be reverted then. I admit this commit increases code size, but I'm not convinced that it's not necessary. If the access is always aligned, let's remove structure packing instead of reducing compiler warnings. (I still think most compiler warnings are good, not bad.) Regards, Simon

2 1

[U-Boot] [RFC] Eliminate boards not using CONFIG_DM=y
by Heinrich Schuchardt 29 Nov '19

29 Nov '19

Dear maintainers, we have been trying to move to the driver model for several years now. Starting in 2018 we have added warnings to the Makefile that boards not supporting the driver model will be eliminated. Still 24 % of the configuration files have not been converted and do not even use CONFIG_DM=y. If we want to get rid of legacy drivers, at some point we have to remove the 347 configuration files in the list below not using the driver model. I suggest to do this directly after the release of v2020.01 scheduled January 6th. This should not stop the maintainers from reinserting the boards after conversion to the driver model. Best regards Heinrich am3517_crane_defconfig apf27_defconfig apx4devkit_defconfig aristainetos2b_defconfig aristainetos2_defconfig aristainetos_defconfig aspenite_defconfig at91rm9200ek_defconfig at91rm9200ek_ram_defconfig B4420QDS_defconfig B4420QDS_NAND_defconfig B4420QDS_SPIFLASH_defconfig B4860QDS_defconfig B4860QDS_NAND_defconfig B4860QDS_SPIFLASH_defconfig B4860QDS_SRIO_PCIE_BOOT_defconfig bcm11130_defconfig bcm11130_nand_defconfig bcm23550_w1d_defconfig bcm28155_ap_defconfig bcm28155_w1d_defconfig bcm911360_entphn_defconfig bcm911360_entphn-ns_defconfig bcm911360k_defconfig bcm958300k_defconfig bcm958300k-ns_defconfig bcm958305k_defconfig bcm958622hr_defconfig bcm958712k_defconfig bg0900_defconfig BSC9131RDB_NAND_defconfig BSC9131RDB_NAND_SYSCLK100_defconfig BSC9131RDB_SPIFLASH_defconfig BSC9131RDB_SPIFLASH_SYSCLK100_defconfig BSC9132QDS_NAND_DDRCLK100_defconfig BSC9132QDS_NAND_DDRCLK133_defconfig BSC9132QDS_NOR_DDRCLK100_defconfig BSC9132QDS_NOR_DDRCLK133_defconfig BSC9132QDS_SDCARD_DDRCLK100_defconfig BSC9132QDS_SDCARD_DDRCLK133_defconfig BSC9132QDS_SPIFLASH_DDRCLK100_defconfig BSC9132QDS_SPIFLASH_DDRCLK133_defconfig C29XPCIE_defconfig C29XPCIE_NAND_defconfig C29XPCIE_SPIFLASH_defconfig caddy2_defconfig cm_t35_defconfig cm_t54_defconfig Cyrus_P5020_defconfig Cyrus_P5040_defconfig d2net_v2_defconfig dms-ba16-1g_defconfig dms-ba16_defconfig dockstar_defconfig duovero_defconfig edb9315a_defconfig edminiv2_defconfig flea3_defconfig gplugd_defconfig highbank_defconfig hrcon_defconfig hrcon_dh_defconfig ib62x0_defconfig iconnect_defconfig inetspace_v2_defconfig kc1_defconfig kmcoge4_defconfig kmcoge5ne_defconfig kmeter1_defconfig kmopti2_defconfig kmsupx5_defconfig kmtegr1_defconfig kmtepr2_defconfig ls2080a_emu_defconfig ls2080a_simu_defconfig MigoR_defconfig mpc8308_p1m_defconfig MPC8308RDB_defconfig MPC8313ERDB_33_defconfig MPC8313ERDB_66_defconfig MPC8313ERDB_NAND_33_defconfig MPC8313ERDB_NAND_66_defconfig MPC8315ERDB_defconfig MPC8323ERDB_defconfig MPC832XEMDS_ATM_defconfig MPC832XEMDS_defconfig MPC832XEMDS_HOST_33_defconfig MPC832XEMDS_HOST_66_defconfig MPC832XEMDS_SLAVE_defconfig MPC8349EMDS_defconfig MPC8349EMDS_PCI64_defconfig MPC8349EMDS_SDRAM_defconfig MPC8349EMDS_SLAVE_defconfig MPC8349ITX_defconfig MPC8349ITXGP_defconfig MPC8349ITX_LOWBOOT_defconfig MPC837XEMDS_defconfig MPC837XEMDS_HOST_defconfig MPC837XEMDS_SLAVE_defconfig MPC837XERDB_defconfig MPC837XERDB_SLAVE_defconfig MPC8536DS_36BIT_defconfig MPC8536DS_defconfig MPC8536DS_SDCARD_defconfig MPC8536DS_SPIFLASH_defconfig MPC8541CDS_defconfig MPC8541CDS_legacy_defconfig MPC8544DS_defconfig MPC8555CDS_defconfig MPC8555CDS_legacy_defconfig MPC8568MDS_defconfig MPC8569MDS_ATM_defconfig MPC8569MDS_defconfig MPC8572DS_36BIT_defconfig MPC8572DS_defconfig MPC8610HPCD_defconfig MPC8641HPCN_36BIT_defconfig MPC8641HPCN_defconfig mx23evk_defconfig mx23_olinuxino_defconfig mx25pdk_defconfig mx28evk_auart_console_defconfig mx28evk_defconfig mx28evk_nand_defconfig mx28evk_spi_defconfig mx31pdk_defconfig mx35pdk_defconfig mx51evk_defconfig mx53ard_defconfig mx53evk_defconfig mx53loco_defconfig mx53smd_defconfig mx6dlarm2_defconfig mx6dlarm2_lpddr2_defconfig mx6memcal_defconfig mx6qarm2_defconfig mx6qarm2_lpddr2_defconfig net2big_v2_defconfig netspace_lite_v2_defconfig netspace_max_v2_defconfig netspace_mini_v2_defconfig netspace_v2_defconfig nokia_rx51_defconfig nsa310s_defconfig omap3_ha_defconfig omap4_panda_defconfig omap4_sdp4430_defconfig omap5_uevm_defconfig openrd_base_defconfig openrd_client_defconfig openrd_ultimate_defconfig P1010RDB-PA_36BIT_NAND_defconfig P1010RDB-PA_36BIT_NOR_defconfig P1010RDB-PA_36BIT_SDCARD_defconfig P1010RDB-PA_36BIT_SPIFLASH_defconfig P1010RDB-PA_NAND_defconfig P1010RDB-PA_NOR_defconfig P1010RDB-PA_SDCARD_defconfig P1010RDB-PA_SPIFLASH_defconfig P1010RDB-PB_36BIT_NAND_defconfig P1010RDB-PB_36BIT_NOR_defconfig P1010RDB-PB_36BIT_SDCARD_defconfig P1010RDB-PB_36BIT_SPIFLASH_defconfig P1010RDB-PB_NAND_defconfig P1010RDB-PB_NOR_defconfig P1010RDB-PB_SDCARD_defconfig P1010RDB-PB_SPIFLASH_defconfig P1020MBG-PC_36BIT_defconfig P1020MBG-PC_36BIT_SDCARD_defconfig P1020MBG-PC_defconfig P1020MBG-PC_SDCARD_defconfig P1020UTM-PC_36BIT_defconfig P1020UTM-PC_36BIT_SDCARD_defconfig P1020UTM-PC_defconfig P1020UTM-PC_SDCARD_defconfig P1021RDB-PC_36BIT_defconfig P1021RDB-PC_36BIT_NAND_defconfig P1021RDB-PC_36BIT_SDCARD_defconfig P1021RDB-PC_36BIT_SPIFLASH_defconfig P1021RDB-PC_defconfig P1021RDB-PC_NAND_defconfig P1021RDB-PC_SDCARD_defconfig P1021RDB-PC_SPIFLASH_defconfig P1022DS_36BIT_defconfig P1022DS_36BIT_NAND_defconfig P1022DS_36BIT_SDCARD_defconfig P1022DS_36BIT_SPIFLASH_defconfig P1022DS_defconfig P1022DS_NAND_defconfig P1022DS_SDCARD_defconfig P1022DS_SPIFLASH_defconfig P1023RDB_defconfig P1024RDB_36BIT_defconfig P1024RDB_defconfig P1024RDB_NAND_defconfig P1024RDB_SDCARD_defconfig P1024RDB_SPIFLASH_defconfig P1025RDB_36BIT_defconfig P1025RDB_defconfig P1025RDB_NAND_defconfig P1025RDB_SDCARD_defconfig P1025RDB_SPIFLASH_defconfig P2041RDB_SRIO_PCIE_BOOT_defconfig P3041DS_SRIO_PCIE_BOOT_defconfig P4080DS_SRIO_PCIE_BOOT_defconfig P5020DS_defconfig P5020DS_NAND_defconfig P5020DS_SDCARD_defconfig P5020DS_SPIFLASH_defconfig P5020DS_SRIO_PCIE_BOOT_defconfig platinum_picon_defconfig platinum_titanium_defconfig pogo_e02_defconfig qemu_mips64_defconfig qemu_mips64el_defconfig qemu_mips_defconfig qemu_mipsel_defconfig qemu-ppce500_defconfig r7780mp_defconfig sansa_fuze_plus_defconfig sbc8349_defconfig sbc8349_PCI_33_defconfig sbc8349_PCI_66_defconfig sbc8548_defconfig sbc8548_PCI_33_defconfig sbc8548_PCI_33_PCIE_defconfig sbc8548_PCI_66_defconfig sbc8548_PCI_66_PCIE_defconfig sbc8641d_defconfig sc_sps_1_defconfig secomx6quq7_defconfig sh7752evb_defconfig sh7753evb_defconfig sh7757lcr_defconfig sh7763rdp_defconfig spear300_defconfig spear300_nand_defconfig spear300_usbtty_defconfig spear300_usbtty_nand_defconfig spear310_defconfig spear310_nand_defconfig spear310_pnor_defconfig spear310_usbtty_defconfig spear310_usbtty_nand_defconfig spear310_usbtty_pnor_defconfig spear320_defconfig spear320_nand_defconfig spear320_pnor_defconfig spear320_usbtty_defconfig spear320_usbtty_nand_defconfig spear320_usbtty_pnor_defconfig spear600_defconfig spear600_nand_defconfig spear600_usbtty_defconfig spear600_usbtty_nand_defconfig strider_con_defconfig strider_con_dp_defconfig strider_cpu_defconfig strider_cpu_dp_defconfig suvd3_defconfig T1023RDB_defconfig T1023RDB_NAND_defconfig T1023RDB_SDCARD_defconfig T1023RDB_SPIFLASH_defconfig T1024QDS_DDR4_defconfig T1024QDS_defconfig T1024QDS_NAND_defconfig T1024QDS_SDCARD_defconfig T1024QDS_SPIFLASH_defconfig T1040D4RDB_defconfig T1040D4RDB_NAND_defconfig T1040D4RDB_SDCARD_defconfig T1040D4RDB_SPIFLASH_defconfig T1040QDS_DDR4_defconfig T1040QDS_defconfig T1040RDB_defconfig T1040RDB_NAND_defconfig T1040RDB_SDCARD_defconfig T1040RDB_SPIFLASH_defconfig T1042RDB_defconfig T1042RDB_PI_defconfig T1042RDB_PI_NAND_defconfig T1042RDB_PI_SDCARD_defconfig T1042RDB_PI_SPIFLASH_defconfig T2080RDB_SRIO_PCIE_BOOT_defconfig T2081QDS_defconfig T2081QDS_NAND_defconfig T2081QDS_SDCARD_defconfig T2081QDS_SPIFLASH_defconfig T2081QDS_SRIO_PCIE_BOOT_defconfig T4160QDS_defconfig T4160QDS_NAND_defconfig T4160QDS_SDCARD_defconfig T4160RDB_defconfig T4240QDS_defconfig T4240QDS_NAND_defconfig T4240QDS_SDCARD_defconfig T4240QDS_SRIO_PCIE_BOOT_defconfig tao3530_defconfig ti814x_evm_defconfig titanium_defconfig TQM834x_defconfig tqma6dl_mba6_mmc_defconfig tqma6dl_mba6_spi_defconfig tqma6q_mba6_mmc_defconfig tqma6q_mba6_spi_defconfig tqma6s_mba6_mmc_defconfig tqma6s_mba6_spi_defconfig tqma6s_wru4_mmc_defconfig tricorder_defconfig tricorder_flash_defconfig ts4600_defconfig ts4800_defconfig tuge1_defconfig tuxx1_defconfig TWR-P1025_defconfig UCP1020_defconfig usbarmory_defconfig vct_platinumavc_defconfig vct_platinumavc_onenand_defconfig vct_platinumavc_onenand_small_defconfig vct_platinumavc_small_defconfig vct_platinum_defconfig vct_platinum_onenand_defconfig vct_platinum_onenand_small_defconfig vct_platinum_small_defconfig vct_premium_defconfig vct_premium_onenand_defconfig vct_premium_onenand_small_defconfig vct_premium_small_defconfig ve8313_defconfig vexpress_ca15_tc2_defconfig vexpress_ca5x2_defconfig vexpress_ca9x4_defconfig vme8349_defconfig warp_defconfig wb45n_defconfig wb50n_defconfig woodburn_defconfig woodburn_sd_defconfig x600_defconfig xfi3_defconfig xpedite517x_defconfig xpedite520x_defconfig xpedite537x_defconfig xpedite550x_defconfig zmx25_defconfig

6 12