[lwip 2/2] Move and rename sys_arch_data_sync_barier()

[Pavel Pisa]

Hello Kinsey and Sebastian,

On Thursday 09 of March 2023 14:46:28 Kinsey Moore wrote:
> Normally with rtems-lwip I would complain that this doesn't follow the
> convention of using #ifdef __rtems__ to modify files from upstream sources
> (each root directory except rtemslwip has an upstream source), but the uLan
> authors have given permission to fully integrate this code into the
> rtemslwip directory where possible (the TI code will go into its own
> directory). This patch looks good.

driver has no upstream, it has been designed for RTEMS and then
used even on FreeRTOS and it except for headers from Ti mainly
used for MDIO, it has been designed from scratch at CTU.
We have originally started and tried to fix Ti HalCoGen
code to work with Ti provided FreeRTOS and it newer worked
reliably. Then we have thrown away all that stuff and started
from scratch with some inspiration from similar BSD drivers.

I have call with Premek and we both agree on relicense to RTEMS
BSD variant. I can prepare commit when I have some while (I am
loaded by lectures, students support now). Next step is to move
code to 

  rtemslwip/tms570

As for

+static inline void
+tms570_data_sync_barier(void)
+{
+#ifdef __arm__
+  _ARM_Data_synchronization_barrier();
+#endif
+}

it is OK but may it be not ideal, because more drivers could require
write buffers and instructions memory access order synchronization.
We have added that definition to ports/os/rtems/arch/sys_arch.h

#ifndef __rtems__
static inline sys_prot_t
sys_arch_protect(void)
{
  sys_prot_t pval;

  rtems_interrupt_disable(pval);
  return pval;
}

static inline void
sys_arch_unprotect(sys_prot_t pval)
{
  rtems_interrupt_enable(pval);
}

static inline void
sys_arch_data_sync_barier(void){
  _ARM_Data_synchronization_barrier();
}
#else

as the generic solution when to allow same drivers to be used
with different architectures. There can be more drivers requiring
such protection.

In the fact tms570_emac is similar or equivalent to some other
ETHERNET NICs, I do not remember which one at the moment, I would
need to search. But I think that I have seen same/similar registers 
organization on other targets.

If I prepare changes of license, should I sent patches
only to the mailing list or should I try to create branch
and try to push it to rtems-lwip or fork some GitHub
matching repo?

...

It seems that my SSH key for ppisa at dispatch.rtems.org has
expired?

Best wishes,

Pavel