In D7326#156220, @manu wrote:

In D7326#156219, @bsz_semihalf.com wrote:

In D7326#156208, @manu wrote:

This DTS will be imported as part of the Linux 4.7 DTS import

That's fine. When do you expect it to happen?

@andrew imported the DTS in the vendor branch so it would not take a long time.
Anyway thanks for working on this board, I was wondering if this could be my new router at home :)

In D7326#156208, @manu wrote:

This DTS will be imported as part of the Linux 4.7 DTS import

Any comments on this series of patches?

Any comments on this series of patches?

mv_msi_data is function used only on ArmadaXP, which doesn't work on current anyway. So I can't test if it works unless we find a brave hero that brings ArmadaXP alive.

Thank you for your remarks - diff was updated accordingly. If there are no objections, we will commit that.

Moved IRQ definitions to platform header.

Few corrections.

@andrew, is it OK? Please accept if so.

Commited.

Corrected to follow @andrew 's remarks.

In D5032#106855, @meloun-miracle-cz wrote:

I have same problem with Tegra UART (it's also ns8250 based) , not yet identified. Are you sure that this is really bug in Armada38X chipset or we have bug in UART driver?

@ian, @imp, would you mind to review this and following commits? Or can we commit with approval of only one of reviewers?

@andrew, the commit was reduced. Necessity of remaining change was explained by Michal above. Please let me know if it's acceptable for you.

Corrected KERNVIRTADDR.

Abandoned because D4675 replaces it.

ian, andrew - please let me know if it's OK, so we can commit the first chunk.

Works fine for me, thank you! As for Andrew's issue, perhaps we could add sys/arm/arm/ofw_machdep.c to sys/conf/files.arm64?

In D4602#97309, @imp wrote:

Has this change been tested on platforms that inspired the original strict check in the first place?

I decided to seperate DTS change and correcting strict compatibility requirement, as there are more calls we are affected by.

In D4423#94478, @andrew wrote:

Can you change the data in mv_timer_compat to encode if the device is supported & if the interrupt is optional similar to how we do it in the mpcore timer driver. It would then simplify supporting new devices with this driver.

Removed ARM_L2_PIPT.

Added device mpcore_timer, removed unneccessary options, corrected tabs after device.

Merged with D4210.

fdt_immr_addr modified instead of changing compatible.

Abandonen, as this is not required after we removed EARLY_PRINTK and doesn't work properly with ARM_NEW_PMAP.

In D4379#94451, @andrew wrote:

Why not fix the code?

Added #else.

Added gic_decode_fdt to fdt_pic_table instead.

Seperated nodes according to Ian's remark.

files.mv included on default.

Sure, thank you :)

D4369 solved the issue.

Interrupt is required by timers (we already use mpcore timers), watchdog doesn't need it. It simply resets system on timeout.

USB can't work without D4369. I try to submit working series of patches (after D4220 one could successfully boot A38X), so I would prefer if such order was kept.

It depends on D4372. Unless we care if it compiles after every commit (as far as I know, we do), it can be merged.

No. I just don't know how to mark it outdated on Phabricator.

In D4214#94222, @ian wrote:

I think you wouldn't need this if you enabled ARM_INTRNG for the platform, wouldn't that be a better way to go?

In D4370#94235, @ian wrote:

This makes our local copy of the dts different than the published linux copy, that seems like a step in the wrong direction. The linux driver must be able to work without this interrupt? (I hate that linux just leaves hardware descriptions out of dts files if their driver doesn't care about that detail, is that the case here?)

andrew, I updated the diff. Please let me know if this is solution you expected.

Added conditions for "marvell,orion-ehci" case, in which driver shouldn't attach interrupt line for errors.