[Arm-dev] Add Marvell Armada7k8k NIC (mvpp2) support patches

Hi Jim,

I've prepared list of mainline patches, that smoothely apply onto
v4.14 baseline. The NIC is working with ACPI as expected.
Because it's not clear to me, how patches should be submitted (please
see my questions from previous emails), below you can find a full
list.

Please let know, how can we proceed from here and how possibly could I
test real Centos image with patches applied.

Thanks,
Marcin

====== LIST of MVPP2 Patches ======
38c5eb93aca9 net: mvpp2: remove useless goto (v4.15-rc1)
2d1d7df8a365 net: mvpp2: set the Rx FIFO size depending on the port speeds for
PPv2.2 (v4.15-rc1)
7c10f9742d76 net: mvpp2: initialize the Tx FIFO size (v4.15-rc1)
1d7d15d79fb4 net: mvpp2: initialize the RSS tables (v4.15-rc1)
1d17db08c056 net: mvpp2: limit TSO segments and use stop/wake thresholds
(v4.15-rc1)
02856a3ba633 net: mvpp2: use the aggr txq size define everywhere (v4.15-rc1)
6eb5d375cefc net: mvpp2: simplify the Tx desc set DMA logic (v4.15-rc1)
118d6298f6f0 net: mvpp2: add ethtool GOP statistics (v4.15-rc1)
e5c500eb298a net: mvpp2: fix GOP statistics loop start and stop conditions
(v4.15-rc1)
ba2d8d887d96 net: mvpp2: fix the txq_init error path (v4.15-rc2)
26146b0e6b68 net: mvpp2: cleanup probed ports in the probe error path
(v4.15-rc2)
e749aca84b10 net: mvpp2: do not disable GMAC padding (v4.15-rc2)
76e583c5f50e net: mvpp2: check ethtool sets the Tx ring size is to a valid min
value (v4.15-rc2)
a154f8e399a0 net: mvpp2: allocate zeroed tx descriptors (v4.15-rc3)
8a7b741e76cd net: mvpp2: fix the RSS table entry offset (v4.15-rc3)
b70d4a5195c7 net: mvpp2: only free the TSO header buffers when it was allocated
(v4.16-rc1)
7cf87e4a5c2b net: mvpp2: split the max ring size from the default one
(v4.16-rc1)
385c284fee84 net: mvpp2: align values in ethtool get_coalesce (v4.16-rc1)
24b28ccb8575 net: mvpp2: report the tx-usec coalescing information to ethtool
(v4.16-rc1)
86162281c25f net: mvpp2: adjust the coalescing parameters (v4.16-rc1)
babe2dbb28e7 device property: Introduce fwnode_get_mac_address() (v4.16-rc1)
b28f263b8670 device property: Introduce fwnode_get_phy_mode() (v4.16-rc1)
7c6c57f2ab2c device property: Introduce fwnode_irq_get() (v4.16-rc1)
3395de96ae59 device property: Allow iterating over available child fwnodes
(v4.16-rc1)
bf147153d7f4 net: mvpp2: simplify maintaining enabled ports' list (v4.16-rc1)
248122212f68 net: mvpp2: use device_*/fwnode_* APIs instead of of_* (v4.16-rc1)
a75edc7c2eab net: mvpp2: enable ACPI support in the driver (v4.16-rc1)
7ac8ff95f48c mvpp2: fix multicast address filter (v4.16-rc3)
56beda3db602 net: mvpp2: Add hardware offloading for VLAN filtering (v4.17-rc1)
01d049366529 net: mvpp2: use the same buffer pool for all ports (v4.17-rc1)
effbf5f58d64 net: mvpp2: update the BM buffer free/destroy logic (v4.17-rc1)
93ff130f1c2b net: mvpp2: use a data size of 10kB for Tx FIFO on port 0
(v4.17-rc1)
381c56712db4 net: mvpp2: enable UDP/TCP checksum over IPv6 (v4.17-rc1)
576193f2d579 net: mvpp2: jumbo frames support (v4.17-rc1)
6e61e10a8a96 net: mvpp2: mvpp2_check_hw_buf_num() can be static (v4.17-rc1)
ce2a27c761ac net: mvpp2: Simplify MAC filtering function parameters (v4.17-rc1)
10fea26ce2aa net: mvpp2: Add support for unicast filtering (v4.17-rc1)
e2e031640b3a net: mvpp2: use correct index on array mvpp2_pools (v4.17-rc1)
47e0e14eb1a6 net: mvpp2: Make mvpp2_prs_hw_read a parser entry init function
(v4.17-rc1)
0c6d9b44145d net: mvpp2: Don't use dynamic allocs for local variables
(v4.17-rc1)
cdcfeb0fb473 net: mvpp2: Use relaxed I/O in data path (v4.17-rc1)
3d92f0b58206 net: mvpp2: Fix parser entry init boundary check (v4.17-rc1)
982e05001c47 net: mvpp2: Fix TCAM filter reserved range (v4.17-rc2)
da42bb271305 net: mvpp2: Fix DMA address mask size (v4.17-rc2)
45f972adb7f4 net: mvpp2: Fix clk error path in mvpp2_probe (v4.17-rc4)
9af771ced473 net: mvpp2: Fix clock resource by adding missing mg_core_clk
(v4.17-rc4)
====== END OF LIST =============


pon., 13 sie 2018 o 10:50 Marcin Wojtas <mw at semihalf.com> napisał(a):
>
> Hi Jim,
>
> Would it be possible, that you take a look at my questions form the
> previous email?
>
> Thanks in advance,
> Marcin
>
> śr., 1 sie 2018 o 17:11 Marcin Wojtas <mw at semihalf.com> napisał(a):
> >
> > Hi Jim,
> >
> > wt., 31 lip 2018 o 18:09 Jim Perrin <jperrin at centos.org> napisał(a):
> > >
> > >
> > >
> > > On 07/30/2018 07:00 AM, Marcin Wojtas wrote:
> > > > Hi Jim,
> > > >
> > > > It's been a while, since I sent the patch. Any objections about merging?
> > > >
> > > > Is v4.11 kernel still a valid baseline or for the next releases or we
> > > > should use v4.14? When is that transition and next release supposed to
> > > > happen?
> > > >
> > >
> > > The current version of the supported kernel is 4.14, so this would need
> > > to be updated to support the 4.14 tree.
> > >
> >
> > There is still a gap between vanilla v4.14 version of the driver and
> > the upstream commits that allow to use it with ACPI (although much
> > smaller than for v4.11). What is a procedure of providing you the
> > patches?
> >
> > >
> > >
> > > > Best regards,
> > > > Marcinsob., 23 cze 2018 o 08:18 Marcin Wojtas <mw at semihalf.com> napisał(a):
> > > >>
> > > >> Hi,
> > > >>
> > > >> I'm sending a patch that is applicable on top of the kernel
> > > >> sig-altarch7-aarch64 branch. It enables ACPI support for the Marvell
> > > >> Armada7k8k NIC - this required backporting very big amount of patches
> > > >> (all merged upstream), hence I decided to attach the single commit,
> > > >> instead of issueing 'git send-email' of it.
> > > >>
> > >
> > >
> > > Once we got to 4.14, there didn't seem to be a demand for the
> > > sig-altarch kernel to continue so I left it at the previous version.
> > > From the sounds of things, you still need it for this to work?
> >
> > Is v4.14-based Centos an official version to support aarch64? If yes,
> > I'd complement this version with the needed patches.
> >
> > Btw. if I google 'Centos aarch64' the links point to the altarch/7
> > images. What is their kernel base then? In other words, where should
> > one search
> > for most recent image of aarch64 images? Is there any public release
> > schedule available?
> >
> > About sig-altarch tree, I'd need to make sure internally. From your
> > perspective, would it be recommended?
> >
> > >
> > > >> Despite many attempts I wasn't able to build entire rpm package with
> > > >> the mock build utility, however I managed to test the clean kernel
> > > >> v4.11 with applied all patches and built with updated .config. Please
> > > >> let know if this patch is sufficient and can be merged.
> > >
> > > I'm guessing no unless it patches/builds against 4.14 as well. I'll see
> > > about updating the sig-altarch tree so that we can test there.
> > >
> >
> > For sure I need to send updated patch list for v4.14. Please see my
> > question above.
> >
> > Thanks,
> > Marcin