[PATCH v4 1/2] net: cortina_ni: Add eth support for Cortina Access CAxxxx SoCs

[Tom Rini <trini@konsulko.com>]

On Wed, Jun 03, 2020 at 01:05:18AM -0700, Alex Nemirovsky wrote:
> From: Aaron Tseng <aaron.tseng@cortina-access.com>
> 
> Add Cortina Access Ethernet device driver for CAxxxx SoCs.
> This driver supports only the DM_ETH network model.
> 
> Signed-off-by: Aaron Tseng <aaron.tseng@cortina-access.com>
> Signed-off-by: Alex Nemirovsky <alex.nemirovsky@cortina-access.com>
> 
> CC: Joe Hershberger <joe.hershberger@ni.com>
> CC: Abbie Chang <abbie.chang@Cortina-Access.com>
> CC: Tom Rini <trini@konsulko.com>
> 
> ---
> 
> Changes in v4: None
> Changes in v3:
> - Changed commit comment to state that only DM model is supported
> - Removed blank line at end of C file
> 
> Changes in v2:
> - Remove legacy mode support
> - Add support for additional SoC variants
> - Remove unused variables
> 
>  MAINTAINERS              |    4 +
>  drivers/net/Kconfig      |    7 +
>  drivers/net/Makefile     |    1 +
>  drivers/net/cortina_ni.c | 1909 ++++++++++++++++++++++++++++++++++++++++++++++
>  drivers/net/cortina_ni.h |  592 ++++++++++++++
>  5 files changed, 2513 insertions(+)
>  create mode 100644 drivers/net/cortina_ni.c
>  create mode 100644 drivers/net/cortina_ni.h

So, is there a similar driver in upstream Linux?  This driver doesn't
quite fit right.  At an "easy" level, there's still the customer macro
around debug statements and not using pr_debug(), and contains a whole
lot of debug code.  There's also code for a saturn platform, is that
being upstreamed?  There's a ton of union usage which is also uncommon.
A small item is it looks like this has its own crc function, when we
have those available already.  There's also things like:
> +enum ca_status_t ca_mdio_read(CA_IN       unsigned int          addr,
> +			      CA_IN       unsigned int		offset,
> +			      CA_OUT      unsigned short	*data)
> +{

Where CA_IN / CA_OUT just don't fit.

Which brings me back to why I asked the first question, this feels a lot
like a driver for an RTOS or some other system was adapted to U-Boot,
rather than writing a new driver for U-Boot based on internal knowledge
of the part in question.  And I think that applies to a lot of the
drivers as seen in the NAND review as well.  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/20200603/0578a615/attachment.sig>