Hi Mark,

Can you provide some information about testing the bug? Thanks in advance.

Regards,
Tianhao

Hi Tianhao,

The mvpp2.ko module should be present in the modules directory in the OS. I can help to test the changes, I'd just need to get an access to the aarch64 booting ISO.

Best regards,
Marcin

At least on the RHEL8 kernel side, the driver code itself hasn't been touched for 2 years, and there are various phylink and gpio changes that have not been applied to it that means that the driver in the tree won't compile at all.

I figured out that fe25ec04763a "gpio: pass lookup and descriptor flags to request_own" is needed to fix at least compilation error.

I'm still getting an error in phylink_mac_link_up, and there's 8+ unapplied commits that may need to be reordered and applied to resolve the error.

Also, there's an issue with drivers/pinctrl/mvebu/pinctrl-armada-37xx.c which I have not figured out.

Any help from the CentOS stream team would be appreciated.

Hi Mark,

(In reply to Mark Langsdorf from comment #5)
> At least on the RHEL8 kernel side, the driver code itself hasn't been
> touched for 2 years, and there are various phylink and gpio changes that
> have not been applied to it that means that the driver in the tree won't
> compile at all.
> 
> I figured out that fe25ec04763a "gpio: pass lookup and descriptor flags to
> request_own" is needed to fix at least compilation error.
> 
> I'm still getting an error in phylink_mac_link_up, and there's 8+ unapplied
> commits that may need to be reordered and applied to resolve the error.

On vanilla v4.18, the phylink is there and the mvpp2 driver can use it. Does it mean you have other backports from newer branches around that are conflicting?

> 
> Also, there's an issue with drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
> which I have not figured out.
> 

For the config MVPP2 (drivers/net/ethernet/marvell/Kconfig) used with ACPI the dependency on CONFIG_MVEBU is a bit unfortunate (it is true for the DT world).
All the selected options (see CONFIG_MVEBU section in arch/arm64/Kconfig.platforms) are totally useless for the kernel that is supposed to work with ACPI.

> Any help from the CentOS stream team would be appreciated.

Please let know if and how can I possibly help here as well.

Best regards,
Marcin

There's been enough partial backports that just enabling the mvpp2 driver doesn't work:

drivers/gpio/gpio-mvebu.c: In function ‘mvebu_pwm_request’:
drivers/gpio/gpio-mvebu.c:611:33: error: type of formal parameter 4 is incomplete
        pwm->hwpwm, "mvebu-pwm", 0);
                                 ^
drivers/gpio/gpio-mvebu.c:610:10: error: too few arguments to function ‘gpiochip_request_own_desc’
   desc = gpiochip_request_own_desc(&mvchip->chip,
          ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/gpio/gpio-mvebu.c:39:
./include/linux/gpio/driver.h:713:19: note: declared here
 struct gpio_desc *gpiochip_request_own_desc(struct gpio_chip *chip,
                   ^~~~~~~~~~~~~~~~~~~~~~~~~

Applying patches to fix these errors causes additional errors.  I'll give it another try but this is frustrating.

Hi Mark,

In paralel I ramped the setup with 4.18.0-240.el8.aarch64 and I reproduce the exact problem that you are observing. I'll try to do the smallest required backport on my own and will get back here. One question - I have the 4.18.0-240.el8 raw sources, without history. Is there any way to view the upstream patches that were already backported?

Thanks,
Marcin

I'm not aware of a way for external folks to get access to the git history.

I wouldn't expect anything else, but I gave it a try :) Please give me a moment, so I can try the backports myself.

Thanks,
Marcin

Petr Oros is going to rebase phylink in 1878147 and I don't think I can proceed on this bug until those commits land in the dev-test branch.

Deferring this work until a major customer needs it.  Marvell is no longer supporting their server line.

We can reopen this if it turns out that someone cares.