RE: [PATCH v4 2/5] net: lan743x: read SFP straps from PCI11x1x device

[Ronnie.Kunin]

Hi Andrew, 
Thanks for your comments

> -----Original Message-----
> From: Andrew Lunn <andrew@xxxxxxx>
> Sent: Monday, June 1, 2026 8:41 AM
> To: Thangaraj Samynathan - I53494 <Thangaraj.S@xxxxxxxxxxxxx>
> Cc: netdev@xxxxxxxxxxxxxxx; andrew+netdev@xxxxxxx;
> davem@xxxxxxxxxxxxx; edumazet@xxxxxxxxxx; kuba@xxxxxxxxxx;
> pabeni@xxxxxxxxxx; Bryan Whitehead - C21958
> <Bryan.Whitehead@xxxxxxxxxxxxx>; UNGLinuxDriver
> <UNGLinuxDriver@xxxxxxxxxxxxx>; linux@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH v4 2/5] net: lan743x: read SFP straps from PCI11x1x
> device
> 
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
> 
> > > In practice distributions turn on nearly everything. So the code is
> > > likely to be built. Rather than a Kconfig symbol, can you move the
> > > code into a module, which only gets loaded for pci11x1x?
> > [Thangaraj Samynathan] Thanks for the suggestion. We agree this is a
> reasonable direction.
> > For this series, CONFIG_LAN743X_SFP addresses the dependency concern.
> > For distro builds that enable most options, a separate module would
> > typically be built and loaded as well, so the practical result is the
> > same.
> 
> Not necessarily. You have a strapping pin, which indicates if the hardware has
> been designed for SFP. Use that to load the kernel module with all the SFP
> code.

That is what we were originally doing: single driver, no conditional compile, decide on SFP strap. But previous review recommendations to solve dependency problems from Jakub took us towards adding conditional compile for the SFP feature.

> 
> Maybe also go talk to Marketing. What has this device been designed for and
> what applications is it marketed towards? >You talk about Intel drivers. They are
> used in servers and desktop machines. You generally don't worry too much
> about code size for those targets, there is a lot of RAM available. However, if
> the target market is deeply embedded, RAM can be short. 

The PCI11x1x is a general-purpose piece of silicon. It can (and based on experience with previous general-purpose devices we've made) will be used in all sort of designs and use cases ranging all the way from deeply embedded to industrial PC clients (onboard or thru PCIe adapters) or even servers (albeit on the management interfaces, I don't think this has been designed in any server data plane so far). The device does not have an internal PHY and typically our customers will select one phy and for their final product put it in the same board where the PCI11x1x is. So why did we make an evaluation board with an SFP cage ? So that our customers can evaluate whatever PHY they want regardless of what their use case is. 

> However, why
> would use pick an embedded SoC which does not have integrated Ethernet?
> Pretty much all embedded SoCs do.

We've certainly had many cases where even if there was integrated ethernet in their SoC of choice, they still wanted our ethernet device as well due to features we have the integrated one did not. 

> 
> Make the architecture fit the use case.
> 
>    Andrew

Going back to the original discussion about whether a kconfig option, as recommended by Jakub in his review, is acceptable. Beside the above explanation on use cases which by itself may provide enough justification, I just took a quick peek and saw quite numerous kconfig bool options exist across many other drivers enabling extra features like debugging interfaces, ptp support, special modes of operation of the hardware, etc. Looks to me like this bool SFP kconfig selection for LAN743x is along the same lines of those, so why would it not be a valid alternative for our driver? 

Ronnie