imho, this is a complete mess with no concept.
At the very least, why do you need these tables at all? What's missing from the DT?

I'm sorry, but how does this work? There are multiple instances of 'ti_edma3tc' in the device tree (DT), so which one is stored in the single global softc?

The clock property is located in the parent node/driver because the parent node provides this clock for all its children. The children have no individual gate functionality, meaning the parent driver must enable the clock for them.

Sorry again. Would it not be better to connect the TI back to the tinderbox/universe?

oups, my mistake, sorry

perfect, thanks.

In D58812#1379542, @freebsd_sysctl.cz wrote:

• Added simplebus_driver as a base class of all mt_clk based drivers.

Why to all? What about all the other objections?

The IFCAP_VLAN_MTU indicates that the hardware can receive and transmit packets of up to 1504 bytes in length, so nothing more is necessary.
So, the only thing missing is the IPv6 CSUM (but it is advertised)

This is another gross hack. In theory, we could add read and write functions to this device to access EEPROM context. However, publishing raw EEPROM context outside of this device context would break all layering rules and is therefore nonsense.

This is pure hack, imho. The ACPI mux, buses and their devices must be enumerated in exactly the same way as in the FDT case.

The driver advertises the following: IFCAP_VLAN_MTU, IFCAP_HWCSUM and IFCAP_HWCSUM_IPV6. What happens if the user enables one of these? I only see that IFCAP_RXCSUM is implemented, albeit probably only partially. In all other cases, the driver either emits an invalid packet, is unable to receive a valid packet, or it panics.

I forgot about it yesterday. At worst, you can use .cfi_escape + DW_CFA_val_expression to select proper LR and SP directly in debugger.

You're definitely right, from an INTRNG point of view. Thanks.

Of course, I don't know anything about annotating the trap frame.
However, adding instructions to the absolutely hot path(s) in the system to fix the debugger doesn't seem like a good idea to me.

I still have a personal problem with ops. It looks too fine-grained to me, but this can be solved with the following commit if we find it necessary.

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