[PATCH] net: dwc_eth_qos: add Kconfig option to select supported configuration

[Tom Rini <trini@konsulko.com>]

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 <patrick.delaunay@st.com>
> >>>>>> ---
> >>>>>> 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: <https://lists.denx.de/pipermail/u-boot/attachments/20200610/ab2e203b/attachment.sig>