Address objections.

• Rename the functions as agreed during the discussion.
• Precompute the total size of class data.
• Implement support for nested classes with optimisation for the most common cases.

Another thing: Wouldn't it be much cleaner to extend the implementation of pmap_mapdev_attr() for early boot phase of armv7? subr_devmap.c looks ready for this job.

I'm not thrilled with this solution.
The standard pre-pmap_bootstrap() KVA is 128 MB, including:

• kernel text/data/bss (section-mapped from KERNBASE);
• early page tables (kern_pt1, kern_pt2tab and initial L2 pages);
• whatever initarm() takes (dpcpu, stacks, msgbuf, etc.).

In D59191#1358240, @br wrote:

Eqos driver does expect that the memory returned is non-cached, otherwise it would be incorrect to flush all the descriptors at once. Bus_dma could not figure out by itself which descriptor to flush if that is fully transparent to driver.

The EQOS driver expects coherent memory, not uncachable memory. But yes, on ARM, coherent memory can be realised as uncacheable if the device sits on a non-coherent bus, or as normal cacheable memory if the device sits on a DMA coherent bus (i.e. ACE). However, this decision lies with the busdma layer. The driver may request memory with a given characteristic, and the busdma layer is responsible for fulfilling that request.

If we must use uncached descriptors for all DMAs, then it is limitation, because having descriptors to reside in cached memory could be the more efficient and faster way to deal with them on heavy usage. That would require individual flushes.

There is no way to make cached memory coherent for a device that is not on a coherent bus. The golden rule is that the CPU can load a cache line or flush it at any time, irrespective of the executed code. This is the result of SMP, speculative reads and various streaming optimisations. Forget about this. Ask Adrian; MIPS gave us a big lesson in this area.

As descriptors operate on coherent memory, bus_dma_sync() can access them at any time without issue. Using a shorter bus_dma_sync() per descriptor doesn't make sense because bus_dma_sync() on coherent memory is a pure read or write barrier, nothing more.

For memory barries don't we prefer to use macroses like mb() instead of calling to busdma sync routines?
Current dwc(4) driver does that instead of busdma_sync. It makes it easier to read the code, and probably a bit faster for CPU.

bus_dma_sync() should be used here. However, we do not yet have a proper operation for this, so rmb()/wmb() can be tolerated.

In D59191#1357815, @br wrote:

I have spent a few days on eqos(4) but did not get it working.

I also think that rqos should be merged back into dwc.

I see all this, but I'm not able to understand how it should work.

I'm also fine with it, thanks. Is the device_get_softc_class() function OK? That's actually the one I had the most trouble with.

How does this correspond with the MII bus? Shouldn't we combine these two drivers into one?

kobj_total_data_size looks good — thanks!
kobj_instance_data_offset seems too long to me, and 'instance' is not entirely precise. Can we shorten it to kobj_data_offset?

This is one of my dilemmas. KOBJ consistently uses 'baseclass', but 'kobj_offsetof_baseclass' or 'kobj_baseclass_offsetof' looks ugly, especially since these could also be used for the main/leaf class.

In D59115#1355807, @kib wrote:

kobj should not mention 'softc', it is not limited to the driver support. It should be named more generally.

Completely agree, but despite my best efforts, I can't figure out which word to use instead of “softc”

Not exactly. The D57176 has nothing to do with simplebus; all of its clock nodes in the DT are leaf nodes.

Sorry, I was too brief. In the past, Martin gave me many versions of the clock code for pre-review, so I have a tendency to respond briefly.
The issue is the audsys/audiosys driver (at least, I didn't check the other clocks). It is not a leaf node, but it has subnodes, so it must implement the simplebus class together with the MT_CLK class. This is impossible in the current situation because both classes have their own softc.
The audsys driver version in review only derives simplebus, which means it cannot work at all. It doesn't have a method for physical access to clock related registers or locking functions (CLKDEV interface).

This code is fundamentally incomplete and unusable in its current state.

• All PLL clocks are crudely faked with fixed clock events instead of being dynamic, without any check.
• The UART silently accepts and programs invalid baud rates without any error reporting.
  • pinctrl implements barely ~10% of the properties defined in the bindings, rendering it effectively useless. -Several clock driver nodes (simplebus being a clear example) lack required functionality and must be rewritten from scratch.

This code is nowhere near ready and demands substantial rework. I'm sorry, but the quality of this AI slope is significantly below my acceptance limit.

Firstly, I must apologize. on my first response I didn't re-read the Rockchip TRM and instead relied on my own memory, which turned out to be a bad idea.

In D58212#1335515, @bz wrote:

I think the only thing I'd love to see is to tell users in the commit message how to apply this as it seems this needs to be done manually.

It would be significantly better to use predefined classes for fixed rate, fixed divider, gates or so .

At this stage, I do not want to introduce tables or hard-coded segment mappings
and/or limits for DMA memory allocation.
For flexibility, the primary interface should be based on functions. A default
implementation can always be added later if a sufficiently robust common case
is identified.

remove redundant empty line

update commit log

Rename function and fix cut&paste error

That's a very good and valid question.
Combining the fact that the 'dma-ranges' DT property (which this change targets) can describe multiple discontinuous ranges and that PCI(e) mappings further depend on transaction types quickly opens a very large Pandora's box. Add chained DMA tags and the IOMMU into the mix, and the problem becomes even more complex.
The honest answer is: I don't know how to handle this in full generality right now.
Today, it remains the driver's responsibility to work with CPU addresses. Modernising busdma would require a significant amount of work, and I'm not confident I have the energy or deep enough knowledge to tackle it all at once.
This minimal implementation is intended only to enable RPi5 support for now, nothing more yet.

All of these clock drivers share too much common code. Firstly, why don't you subclass these from the base class in mdtk_clk.c? If that's not sufficient, why don't you use a new base class that implements all this glue and subclass it?

I would much rather have PowerPC adapt the clock, reset and other frameworks. After all, PowerPC .dts files use them, so I don't see a single reason why we could not include them in the PowerPC build.
The assumption that FDT means that all these frameworks would make the world much simpler.

Aliasing SEGV_PKUERR and SEGV_MTEAERR breaks Qt6 (at least Qt6-base), as it has both in one switch. It seems Linux takes PKUERR as arch-independent.

LGTM

I'm not sure if anyone knows the exact, precise response. ARMv7 unwinding is pure mesh. All of my attempts to understand it ended with me turning off the computer and opening a bottle of good wine.
I think it's possible to write a backtrace that doesn't use it, but I also think it's used by the unwinder library, which is also used for backtraces.
My motivation was to be careful about security. If the executable implements real unwinder personalities, we should also use it for libsys

I understand that libsys might be the last frame.
However, this also means that the unwinder is supposed to call the function aeabi_unwind_cpp_pr0, found in the .ARM.exidx section of the corresponding object.
In your case, this is buildin_trap().
Is this right?

Sorry for my poorly formulated question.
The hidden but not weak aeabi_unwind_cpp_pr* symbols means that we don't expect or want to process exceptions generated in libsys because the unwinder always ends in an abort/trap. So why don't we simply compile libsys with -fno-exceptions?

Should not these symbols also be marked as weak? Hidden symbols are not 'overloaded' in the same library. kib, jrtc27 any comment about this, please?

It was should be closed with 62e1227219f2f79a2ed7a672149dc3d774d25dd4, sorry.

At first look only:

• • the '#ifndef MT7531' is clearly incompatible with GENERIC kernel.
• the defined FDT bindings between the NIC and the switch are not followed. Instead, a "brutal" hack (fdt_find_ethernet_prop_switch) is used.
• the eqos driver changes is improper. All of these are should be in attached the phy driver.

Use correct diff

Use correct diff

In D53891#1231630, @alc wrote:

In D53891#1231619, @mmel wrote:

Confirmed, this part is enough.

This makes sense to me. Suppose that the object has OBJ_ONEMAPPING set. On a memory-starved machine, we could have paged out all of the object's pages, so that the resident count would be zero. Then, if a hole is punched in a mapping to this object, then vm_map_entry_delete() will call vm_object_page_remove(), which will fail to release the swap space.

@mmel you have been testing on ARMv7, correct?

yes, and also on arm32 jail

Confirmed, this part is enough.

After another day of extensive testing, I can confirm that everything is working properly.