This small update includes the proposed smaller changes.

I tested now with a revised version of the GPIO driver (submitted to this site few days ago) and U-boot which doesn't use its PCIE driver and the problem (PCIB0 not getting the link) does not show up anymore. Probably a mistake in GPIO driver's IO methods had caused the issue which I had described as a U-boot dependency. This PCIE driver's IO methods were much more carefully tested.

Revised and expanded version of the driver. Now contains methods getcaps, getname, toggle and pad configuration RW in setflags.

Behind the link below is a solution which follows an example of vscphy.c. It adds three #if clauses to bypass the FDT code. Functions and return instructions are included also without FDT since they are needed to avoid compiler errors. This solution assumes that functions are only used by computers which use FDT. The devices that use the other Motorcomm YT8511 revision seem to be Rockchip SoCs so the assumption looks safe at this point.
mcommphy.c

More on the dependency issue:
I took my tests later to a point where I discovered that removing any other parts than resets or clocks from u-boot's pcie driver doesn't cause the PCIB0's datalink to disapper (while removing the whole driver causes it). Then removing either clocks or resets causes u-boot to halt after running through the driver code. These outcomes are pretty mysterious because clocks and resets are treated similarly in freebsd's pcie driver and u-boot's driver. Could they nevertheless cause the dependency? Next step might be to investigate if clock rates appear similar for both drivers. But I'm not sure if this is worth the time.

(I tried to comment earlier but I had some hassle)

This update fixes small issues mentioned in previous comments and removes KVCO adjustments. I also report here about a U-Boot dependency.

I agree with all the comments.

More about the memory allocation issue: It looks now that in pcib_probe_windows() a wrong value is read to "val" variable from register PCIR_PMBASEL_1. I don't suspect a bug in the PCI code anymore. One developer said it's probably related to U-Boot.

RF_SHAREABLE removed, clocks rearranged to header file's order

Updating clk.h's path which has been changed during this year and adding this file to files.starfive

Now adding this file to files.starfive

Now adding this file to files.starfive

Redundant credits removed, BUS_PASS_ORDER modified

In D45600#1065301, @renatoalencar.73_gmail.com wrote:

Some of the issues you described are very similar to what I've encountered a couple of months ago when trying to run FreeBSD on a Orange Pi 3B, sometimes the interface would restart which would lead to an inconsistent state on the TX/RX ring descriptors on if_eqos, you can try to run with my patch too.

I investigated the LOR (lock order reversal) issue further by temporarily removing eqos locks entirely. Witness still keeps on talking about eqos lock, so it possibly rightly notices a connection between the eqos driver and callout API linked to its operations. Debugger's lock commands were pretty uninformative but by using printfs I became pretty sure the lock really is located in softclock (callout API) code (while the other lock involved in LOR is in the generic clock code, clk.c).

Now with the full context and without style corrections for if_eqos.c

Now the io_assign() function which was used by reset operations is optimized away within the framework of existing driver classes. At this point I don't see a reason to create more classes.

This update fixes smaller issues. The proposal to restructure the reset code by creating a new base class is left for later.

This update includes small changes that were proposed. See comments for the discussion about a new header file and having more static arrays.

doing it like it should be done

mhorne's improvements for jh7110_clk_pll.c and files.starfive added
(note: some lines in jh7110_clk_pll.c are over 80 chars)

This patch update fixes style issues, improves module load scheduling, removes reset timeout polling and UART clk special handling, adds PLL macros. I welcome yet discussion about these issues. I was pretty undecided about reset & UART.

Fixing obvious style issues

Okay, I had still few things to learn about formatting (some things were seen wrongly here because I had relied excessively on using spaces. I will stop that). I agree with almost every formatting related comment and I haven't answered those ones.

Restructuring code to the device tree used in Linux, now including separate devices and reset driver's methods.

Switching to another device tree. Makes no really difference for this file.

When switching to another device tree reset driver will be merged with clockgen driver

This code will be adjusted to support a device tree supplied with U-Boot

This code will be adjusted to support a device tree supplied with U-Boot (will be probably merged to clkgen code)

This code will be adjusted to support a device tree supplied with U-Boot

Fixing style issues

Fixing style issues

I blew up the previous fix. Now fixing the (style) fix.

• fixing style issues