This thread is no longer active, it has been moved to a reworked to reflect current FreeBSD mechanisms and is to be found in D7814

We have reworked the driver a bit once we finish sanity checks the newer version will appear here, or, if the changes happen to be too big, this issue will be abandoned with proper link to an update. ETA: today/tomorrow, once the HEAD gets back to normal.

Anyone?

This is yet another version, which takes into consideration other Alpine platforms.

It looks things went forward - the D4879 got into mainline. There are no dependencies left, may I ask you for your review, then?

Since other changes slipped in-between it would be cleaner to resubmit a new version. Plus following @mav suggestion on putting it at the end

Anyone would like to share a comment on this? There are a few pending commits blocked by this one...

Add implementation of new bus_get_bus_tag(). This is required for archs where child bus tag differs from parent's one (another endianess).
There are added methods in some platforms nexus.c files which return platform specific default tag and ofw_pci_bus_get_bus_tag() in dev/ofw/ofw_pci.c for PowerPC which return correct tag.

This diff just ports the ofw_pci stuff, taking into consideration the recent changes in PPC files (r294277). This shall be a good starting point for further modifications - I hope I omitted nothing from the discussion conclusions.

As previously suggested this diff includes move from ppc ofw code into sys ofw, which is a desired transition regardless on additional changes. It also includes changes in _nranges() function which is desired in our platform code. That implied some minor changes in header. Could you please comment starting from this revison?

In our code it would be convenient and elegant to have some cell attributes kept aside and use at a later stage - this is done in ofw_pci_nranges(). Moving the files to have everything shared is a good idea, but some changes are needed while the transition. It could be done in two runs (move the code, and then update for our needs) but taking the changes are slight I would rather merge them into one commit.

As for the fdt header I looks it is remaining not cleaned up. Shall not appear at this stage.
Moving it as is would conflict with what we expected from its functionality, and would need to copy&paste&modify the code, just in another directory. Slightly extending the functionality gives what is needed in ARM code, not really conflicting PPC flow.

Any comments on this? Unless you have objections I would be happy to have it commited.

This is an update version, with fixes applied + uses the common code to be found in D4879: OFW PCI code decuplications - involves ARM, PPC and SPARC64

Filled missing options that were added.

Fixing it would mean digging into bootloader code, so I'd rather steer clear of it. We are not going to use the MSI-x extenstion on this board.

This is an updated version of previous drop, and addresses comments from previous review.
Additionally, it adds MSI-x support, because during discussion it turned out that this is a cleaner way.

Fixed #ifdef mess.

Anyone? ACK/NACK?

This is yet another revision of this patch, after out-of-band discussion with Warner, so should be much closer to a final version.

This is a polished version of previous commit:

• the check for binutils is based on clang variable which is more reliable.
• code duplication removal
• ensuring that interrupts are disabled on mode change

Removed spare dmb() in favor to dsb() only. That change in hal appeared when fixing compilation errors after extracting PCI.

This version is without PCI support - that will appear in a separate review.

Thank you for discussion and suggestions. This revision fixes reported style + a bit more.
As for the discussion topics, a roadmap with regard to mentioned issues looks like this:

1. delivery the platform support as is - this is a coherent change in terms of platform and hal
2. the next planned code drop involves msix support so relates to pci enhancement and cleanup. At this stage I will deal with dts compatibility - this will let me parallelise some works.
3. meanwhile, I will move the hal to sys/contrib. This shall be a painless transition and will prelude another hal drop in for eth driver

Does it sound reasonable?

This revision addresses all your pointers. I hope all problems are solved now.

Hi,
I have two concerns regarding this issue:

1. the commit to the repository you made is different than the code in this review
2. there is a bug in the commit in ofw_bus_find_compatible():

OF_getprop_alloc shall be called with child instead of node. Could you fix it plesase?

Does anyone has objections to this version?

Hi, thank you for adding the functionality, btw could you also send the header? It is missing in the commit.

Thank you for previous comments. Here is updated diff, I hope it is fine now.

Right, sorry for the mess with the #ifdefs, fixing it.

Thank you all for your feedback. Unless answered to the remarks, I followed your recommendations, which results in the second version. Please, have a look at this.

In D2340#42671, @onwahe-gmail-com wrote:

Was this tested with ARM_NEW_PMAP option?

I see there was huge amount of good work put into fixing the race, fruitful discussion, but also no updates since last month. Frankly speaking, I am waiting to see this fix in mainline, instead of using patch from with Wojciech Macek. Are there any more issues with this or can it be merged?

Do you have any concerns regarding these changes? If so, please, let me know.
There is one issue still not solved - current gcc version probably will not be able to handle that. Do we really care?

Seems this thread has stalled a bit. May I ask you for some input regarding this change? The conclusion at this state is that we want keep just one identifier, that is KERNBASE, and do not want a system-wide change, at least now. The drawback of currest proposal that this feature would be arm-related, but taking into consideration the usage diversity of arm-based devices, that would not be unusual. As I pointed out,there are #ifndefs already existing in arm's vmparam.h so this change would be merely an extension to the present scheme. What do you think?