From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 10 Jun 2020 16:11:48 -0400 Subject: [PATCH] net: dwc_eth_qos: add Kconfig option to select supported configuration In-Reply-To: References: <20200608092719.10643-1-patrick.delaunay@st.com> <20200610181019.GE24893@bill-the-cat> <9f331ffe-b156-8add-e098-69908b80cebf@denx.de> <20200610185218.GH24893@bill-the-cat> <552c2b40-7aaf-c015-ca49-ef14ae6ac905@denx.de> <20200610185851.GI24893@bill-the-cat> Message-ID: <20200610201148.GJ24893@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, Jun 10, 2020 at 09:01:39PM +0200, Marek Vasut wrote: > On 6/10/20 8:58 PM, Tom Rini wrote: > > On Wed, Jun 10, 2020 at 08:55:36PM +0200, Marek Vasut wrote: > >> On 6/10/20 8:52 PM, Tom Rini wrote: > >>> On Wed, Jun 10, 2020 at 08:42:20PM +0200, Marek Vasut wrote: > >>>> On 6/10/20 8:10 PM, Tom Rini wrote: > >>>>> On Mon, Jun 08, 2020 at 11:27:19AM +0200, Patrick Delaunay wrote: > >>>>> > >>>>>> Add configuration flag to select the supported dwc driver configuration: > >>>>>> - CONFIG_DWC_ETH_QOS_TEGRA186 > >>>>>> - CONFIG_DWC_ETH_QOS_IMX > >>>>>> - CONFIG_DWC_ETH_QOS_STM32 > >>>>>> > >>>>>> See Linux driver ethernet/stmicro/stmmac and associated glue layers > >>>>>> for other configuration examples. > >>>>>> > >>>>>> This patch removes the not-selected compatibles and lets the linker remove > >>>>>> the unused functions to reduce the size of the driver. > >>>>>> > >>>>>> Signed-off-by: Patrick Delaunay > >>>>>> --- > >>>>>> Hi, > >>>>>> > >>>>>> I propose this patch after Marek's remark in [1]. > >>>>>> > >>>>>> It is also linked to [2] to limit the STM32 glue for ST compatible. > >>>>>> > >>>>>> [1] net: dwc_eth_qos: Make clk_rx and clk_tx optional > >>>>>> http://patchwork.ozlabs.org/project/uboot/patch/20200512095603.29126-5-david.wu at rock-chips.com/#2432595 > >>>>>> > >>>>>> [2] net: dwc_eth_qos: update the compatible supported for STM32 > >>>>>> http://patchwork.ozlabs.org/project/uboot/list/?series=176917 > >>>>>> > >>>>>> > >>>>>> drivers/net/Kconfig | 27 ++++++++++++++++++++++++--- > >>>>>> drivers/net/dwc_eth_qos.c | 12 +++++++++--- > >>>>>> 2 files changed, 33 insertions(+), 6 deletions(-) > >>>>>> > >>>>>> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig > >>>>>> index 0b08de0ef4..c4b3667d3b 100644 > >>>>>> --- a/drivers/net/Kconfig > >>>>>> +++ b/drivers/net/Kconfig > >>>>>> @@ -156,9 +156,30 @@ config DWC_ETH_QOS > >>>>>> help > >>>>>> This driver supports the Synopsys Designware Ethernet QOS (Quality > >>>>>> Of Service) IP block. The IP supports many options for bus type, > >>>>>> - clocking/reset structure, and feature list. This driver currently > >>>>>> - supports the specific configuration used in NVIDIA's Tegra186 chip, > >>>>>> - but should be extensible to other combinations quite easily. > >>>>>> + clocking/reset structure, and feature list. > >>>>>> + > >>>>>> +config DWC_ETH_QOS_IMX > >>>>>> + bool "Synopsys DWC Ethernet QOS device support for IMX" > >>>>>> + depends on DWC_ETH_QOS > >>>>>> + help > >>>>>> + The Synopsys Designware Ethernet QOS IP block with the specific > >>>>>> + configuration used in IMX soc. > >>>>>> + > >>>>>> +config DWC_ETH_QOS_STM32 > >>>>>> + bool "Synopsys DWC Ethernet QOS device support for STM32" > >>>>>> + depends on DWC_ETH_QOS > >>>>>> + default y if ARCH_STM32MP > >>>>>> + help > >>>>>> + The Synopsys Designware Ethernet QOS IP block with the specific > >>>>>> + configuration used in STM32MP soc. > >>>>>> + > >>>>>> +config DWC_ETH_QOS_TEGRA186 > >>>>>> + bool "Synopsys DWC Ethernet QOS device support for TEGRA186" > >>>>>> + depends on DWC_ETH_QOS > >>>>>> + default y if TEGRA186 > >>>>>> + help > >>>>>> + The Synopsys Designware Ethernet QOS IP block with specific > >>>>>> + configuration used in NVIDIA's Tegra186 chip. > >>>>>> > >>>>>> config E1000 > >>>>>> bool "Intel PRO/1000 Gigabit Ethernet support" > >>>>> > >>>>> I like this idea. But, is there a reason to have more than one of these > >>>>> enabled? Assuming not, we should do this as a choice I think so it'll > >>>>> be clear to the next SoC that they'll need to add this table right away. > >>>> > >>>> Should we be able to enable different settings in U-Boot and in SPL , > >>>> e.g. for the use case where the SPL is the same on different SoCs, while > >>>> the U-Boot binary is not ? > >>> > >>> You mean be more like barebox and Linux where the board-specific stuff > >>> is kicked up one level and we have a more generic binary? I don't know > >>> and there's so much work that would be required before having to move > >>> this from a Kconfig choice to just Kconfig options I don't see that as > >>> being a relevant question here. > >>> > >>> Or did I misunderstand the question? > >> > >> More like automatically have a Kconfig option generate it's _SPL and > >> _TPL variant. > > > > Ah. Well, that is rephrasing my first question. Would it ever make > > sense to have more than one of these enabled? > > For some sort of universal SPL, maybe ? So no, there's not a reason today then and it should be a choice. Thanks! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: