Re: [PATCH net-next 00/20] net: ethernet: Add qcom PPE driver

On Thu, Jan 11, 2024 at 11:49:53PM +0800, Jie Luo wrote:

On 1/11/2024 6:24 AM, Jakub Kicinski wrote:

quoted

On Wed, 10 Jan 2024 19:40:12 +0800 Luo Jie wrote:

quoted

The PPE(packet process engine) hardware block is available in Qualcomm
IPQ chipsets that support PPE architecture, such as IPQ9574 and IPQ5332.

What's the relationship between this driver and QCA8084?

The PPE (packet processing engine) is the network processing hardware block
in QCOM IPQ SoC. It includes the ethernet MAC and UNIPHY(PCS). This driver
is the base PPE driver which brings up the PPE and handles MAC/UNIPHY
operations. QCA8084 is the external 2.5Gbps 4-port PHY device, which can be
connected with PPE integrated MAC by UNIPHY(PCS).

Here is the relationship.
PPE integrated MAC --- PPE integrated UNIPHY(PCS) --- (PCS)QCA8084.

quoted

In the last month I see separate changes from you for mdio-ipq4019.c,
phy/at803x.c and now this driver (none of which got merged, AFAICT.)
Are you actually the author of this code, or are you just trying
to upstream bunch of vendor code?

Yes, Jakub, there are two authors in these patch series, Lei Wei and me.
The patches are already ready for some time, the code has been verified
on the Qualcomm reference design board. These are not downstream drivers
but drivers re-written for upstream.

quoted

Now you're dumping another 10kLoC on the list, and even though this is
hardly your first posting you're apparently not aware of our most basic
posting rules:
https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#tl-dr

The reviewers are getting frustrated. Please, help us help you.
Stop throwing code at the list and work out a plan with Andrew
and others on how to get something merged...

Sorry for trouble caused, will learn about the guidance provided by
the review comments, and follow up on the guidance and have the full
internal review of the patch updates before pushing the patch series.

I renew my will of helping in any kind of manner in this, I love the
intention for EDMAv2 to have an upstream driver instead of SSDK, hoping
in the future to also have the same treatement for EDMAv1 (it's really a
pitty to have a support hole with ipq807x not supported)

Feel free to send an email or anything, considering this is massive, an
extra eye before sending might make things better than reaching (I can
already see this) a massive series with at least 20 revision given the
complexity of this thing.

-- 
	Ansuel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel