[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2c4a42ee-164b-447f-b51d-07b2585345b3@broadcom.com>
Date: Fri, 9 Aug 2024 15:17:24 -0700
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Andrew Lunn <andrew@...n.ch>,
Jitendra Vegiraju <jitendra.vegiraju@...adcom.com>
Cc: netdev@...r.kernel.org, alexandre.torgue@...s.st.com,
joabreu@...opsys.com, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com, mcoquelin.stm32@...il.com,
bcm-kernel-feedback-list@...adcom.com, richardcochran@...il.com,
ast@...nel.org, daniel@...earbox.net, hawk@...nel.org,
john.fastabend@...il.com, linux-kernel@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com,
linux-arm-kernel@...ts.infradead.org, bpf@...r.kernel.org,
linux@...linux.org.uk, horms@...nel.org
Subject: Re: [PATCH net-next v3 3/3] net: stmmac: Add PCI driver support for
BCM8958x
On 8/9/24 13:12, Andrew Lunn wrote:
> On Thu, Aug 08, 2024 at 06:54:51PM -0700, Jitendra Vegiraju wrote:
>> On Tue, Aug 6, 2024 at 4:15 PM Andrew Lunn <andrew@...n.ch> wrote:
>>>
>>> On Mon, Aug 05, 2024 at 05:56:43PM -0700, Jitendra Vegiraju wrote:
>>>> On Fri, Aug 2, 2024 at 4:08 PM Andrew Lunn <andrew@...n.ch> wrote:
>>>>>
>>>>>> Management of integrated ethernet switch on this SoC is not handled by
>>>>>> the PCIe interface.
>>>>>
>>>>> MDIO? SPI? I2C?
>>>>>
>>>> The device uses SPI interface. The switch has internal ARM M7 for
>>>> controller firmware.
>>>
>>> Will there be a DSA driver sometime soon talking over SPI to the
>>> firmware?
>>>
>> Hi Andrew,
>
> So the switch will be left in dumb switch everything to every port
> mode? Or it will be totally autonomous using the in build firmware?
>
> What you cannot expect is we allow you to manage the switch from Linux
> using something other than an in kernel driver, probably DSA or pure
> switchdev.
This looks reasonable as an advice about to ideally fit within the
existing Linux subsystems, however that is purely informational and it
should not impair the review and acceptance of the stmmac drivers.
Doing otherwise, and rejecting the stmmac changes because now you and
other reviewers/maintainers know how it gets used in the bigger picture
means this is starting to be overreaching. Yes silicon vendor companies
like to do all sorts of proprietary things for random reasons, I think
we have worked together long enough on DSA that you know my beliefs on
that aspect.
I think the stmmac changes along have their own merit, and I would
seriously like to see a proper DSA or switchdev driver for the switching
silicon that is being used, but I don't think we need to treat the
latter as a prerequisite for merging the former.
Thanks!
--
Florian
Powered by blists - more mailing lists