Storing a chain of pbuf was an original design of @pfalcon's lwIP socket
module. The problem with storing just one, like modlwip does is that
"peer closed connection" notification is completely asynchronous and out of
band. So, there may be following sequence of actions:

1. pbuf #1 arrives, and stored in a socket.
2. pbuf #2 arrives, and rejected, which causes lwIP to put it into a
queue to re-deliver later.
3. "Peer closed connection" is signaled, and socket is set at such status.
4. pbuf #1 is processed.
5. There's no stored pbufs in teh socket, and socket status is "peer closed
connection", so EOF is returned to a client.
6. pbuf #2 gets redelivered.

Apparently, there's no easy workaround for this, except to queue all
incoming pbufs in a socket. This may lead to increased memory pressure,
as number of pending packets would be regulated only by TCP/IP flow
control, whereas with previous setup lwIP had a global overlook of number
packets waiting for redelivery and could regulate them centrally.

Storing a chain of pbuf was an original design of @pfalcon's lwIP socket
module. The problem with storing just one, like modlwip does is that
"peer closed connection" notification is completely asynchronous and out of
band. So, there may be following sequence of actions:

1. pbuf #1 arrives, and stored in a socket.
2. pbuf #2 arrives, and rejected, which causes lwIP to put it into a
queue to re-deliver later.
3. "Peer closed connection" is signaled, and socket is set at such status.
4. pbuf #1 is processed.
5. There's no stored pbufs in teh socket, and socket status is "peer closed
connection", so EOF is returned to a client.
6. pbuf #2 gets redelivered.

Apparently, there's no easy workaround for this, except to queue all
incoming pbufs in a socket. This may lead to increased memory pressure,
as number of pending packets would be regulated only by TCP/IP flow
control, whereas with previous setup lwIP had a global overlook of number
packets waiting for redelivery and could regulate them centrally.

*: Heading to 2015-07-18

Fixes micropython#2.

Fix up Makefile dependencies

Update from upstream repo micropython/micropython@master

Merge last mod. in patch-1

Get latest

riot: Modify Pin to (PORT, PIN) tuple

Micropython update

Fix issues with Makefile

Pull master

Fix tuple test

merge with current master of circuitpython

merging from upstream

5.0.x

update fork

Better handle //| and do __init__.c first.

this includes patch for PR6494 and allows both patch to co-exists

Users can then choose between 2 ways
   machine.deepsleep([ms])
   pyb.standby([ms], [wakeup Pins X1|X18], [wakeup trigger FALLING|RISING])

-- tested 1.13
machine.deepsleep(2000) # OK
machine.deepsleep(5000) # OK
machine.deepsleep(10000) # OK
machine.deepsleep(20000) # OK
machine.deepsleep() # OK waited 2 minutes

-- tested new firmware
machine.deepsleep(2000) # OK
machine.deepsleep(5000) # OK
machine.deepsleep(10000) # OK
machine.deepsleep(20000) # OK
machine.deepsleep() # OK waited 2 minutes

pyb.standby(0) # OK waited for 2 minutes
pyb.standby(2000) # OK
pyb.standby(5000) # OK
pyb.standby(10000) # OK
pyb.standby(20000) # OK
pyb.standby() # OK waited for 2 minutes

pyb.standby(0, pyb.WKUP_X1, pyb.WKUP_X1_FALLING) # OK wake up on interrupt within 10 sec
pyb.standby(2000, pyb.WKUP_X1, pyb.WKUP_X1_FALLING) # OK wakes up after 2sec
pyb.standby(5000, pyb.WKUP_X1, pyb.WKUP_X1_FALLING) # OK wakes up after 5 sec
pyb.standby(10000, pyb.WKUP_X1, pyb.WKUP_X1_FALLING) # OK wakes up after 10 sec and wakes up on interrupt within 10 sec
pyb.standby(20000, pyb.WKUP_X1, pyb.WKUP_X1_FALLING) # OK wakes up after 20 sec  and wakes up on interrupt within 20 sec

pyb.standby(0, pyb.WKUP_X18, pyb.WKUP_X18_FALLING) # OK wake up on interrupt within 10 sec
pyb.standby(2000, pyb.WKUP_X18, pyb.WKUP_X18_FALLING) # OK wakes up after 2sec
pyb.standby(5000, pyb.WKUP_X18, pyb.WKUP_X18_FALLING) # OK wakes up after 5 sec
pyb.standby(10000, pyb.WKUP_X18, pyb.WKUP_X18_FALLING) # OK wakes up after 10 sec and wakes up on interrupt within 10 sec
pyb.standby(20000, pyb.WKUP_X18, pyb.WKUP_X18_FALLING) # OK wakes up after 20 sec  and wakes up on interrupt within 20 sec

-- TO TEST
pyb.standby(0, pyb.WKUP_X1 | pyb.WKUP_X18, pyb.WKUP_X1_FALLING | pyb.WKUP_X18_FALLING) #
machine.deepsleep with upower.py

Master

A crash like the following occurs in the unix port:
```
Program received signal SIGSEGV, Segmentation fault.
0x00005555555a2d7a in mp_obj_module_set_globals (self_in=0x55555562c860 <ulab_user_cmodule>, globals=0x55555562c840 <mp_module_ulab_globals>) at ../../py/objmodule.c:145
145	    self->globals = globals;
(gdb) up
#1  0x00005555555b2781 in mp_builtin___import__ (n_args=5, args=0x7fffffffdbb0) at ../../py/builtinimport.c:496
496	                mp_obj_module_set_globals(outer_module_obj,
(gdb)
micropython#2  0x00005555555940c9 in mp_import_name (name=824, fromlist=0x555555621f10 <mp_const_none_obj>, level=0x1) at ../../py/runtime.c:1392
1392	    return mp_builtin___import__(5, args);
```

I don't understand how it doesn't happen on the embedded ports, because
the module object should reside in ROM and the assignment of self->globals
should trigger a Hard Fault.

By checking VERIFY_PTR, we know that the pointed-to data is on the heap
so we can do things like mutate it.

It was incorrect to NULL out the pointer to our heap allocated buffer in
`reset`, because subsequent to framebuffer_reset, but while
the heap was still active, we could call `get_bufinfo` again,
leading to a fresh allocation on the heap that is about to be destroyed.

Typical stack trace:
```
#1  0x0006c368 in sharpdisplay_framebuffer_get_bufinfo
micropython#2  0x0006ad6e in _refresh_display
micropython#3  0x0006b168 in framebufferio_framebufferdisplay_background
micropython#4  0x00069d22 in displayio_background
micropython#5  0x00045496 in supervisor_background_tasks
micropython#6  0x000446e8 in background_callback_run_all
micropython#7  0x00045546 in supervisor_run_background_tasks_if_tick
micropython#8  0x0005b042 in common_hal_neopixel_write
micropython#9  0x00044c4c in clear_temp_status
micropython#10 0x000497de in spi_flash_flush_keep_cache
micropython#11 0x00049a66 in supervisor_external_flash_flush
micropython#12 0x00044b22 in supervisor_flash_flush
micropython#13 0x0004490e in filesystem_flush
micropython#14 0x00043e18 in cleanup_after_vm
micropython#15 0x0004414c in run_repl
micropython#16 0x000441ce in main
```
When this happened -- which was inconsistent -- the display would keep
some heap allocation across reset which is exactly what we need to avoid.

NULLing the pointer in reconstruct follows what RGBMatrix does, and that
code is a bit more battle-tested anyway.

If I had a motivation for structuring the SharpMemory code differently,
I can no longer recall it.

Testing performed: Ran my complicated calculator program over multiple
iterations without observing signs of heap corruption.

Closes: micropython#3473

merging from adafruit

# This is the 1st commit message:

special_accessors: runtime addition of descriptors could set

Adding descriptors at runtime doesn't set the special accessor flag.
or atleast the way I was doing it.

type_attr calls `check_for_special_accessors` (before adding the special accessor flag)  which will obviously return false (because no special accessor was added
on the original object)

I've replaced the validation to check if the new attribute to be added is an descriptor (if true - then set the special accessor flag)

Signed-off-by: Jonathan Bruchim <yonbruchim@gmail.com>

# This is the commit message micropython#2:

I've noticed that adding descriptors at runtime doesn't set the special accessor flag.
or atleast the way I was doing it.

type_attr calls `check_for_special_accessors` (before adding the special accessor flag)  which will obviously return false (because no special accessor was added
on the original object)

I've replaced the validation to check if the new attribute to be added is an descriptor (if true - then set the special accessor flag)

Signed-off-by: Jonathan Bruchim <yonbruchim@gmail.com>

asan considers that memcmp(p, q, N) is permitted to access N bytes at each
of p and q, even for values of p and q that have a difference earlier.
Accessing additional values is frequently done in practice, reading 4 or
more bytes from each input at a time for efficiency, so when completing
"non_exist<TAB>" in the repl, this causes a diagnostic:

    ==16938==ERROR: AddressSanitizer: global-buffer-overflow on
    address 0x555555cd8dc8 at pc 0x7ffff726457b bp 0x7fffffffda20 sp 0x7fff
    READ of size 9 at 0x555555cd8dc8 thread T0
        #0 0x7ffff726457a  (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a)
        #1 0x555555b0e82a in mp_repl_autocomplete ../../py/repl.c:301
        #2 0x555555c89585 in readline_process_char ../../lib/mp-readline/re
        #3 0x555555c8ac6e in readline ../../lib/mp-readline/readline.c:513
        #4 0x555555b8dcbd in do_repl /home/jepler/src/micropython/ports/uni
        #5 0x555555b90859 in main_ /home/jepler/src/micropython/ports/unix/
        #6 0x555555b90a3a in main /home/jepler/src/micropython/ports/unix/m
        #7 0x7ffff619a09a in __libc_start_main ../csu/libc-start.c:308
        #8 0x55555595fd69 in _start (/home/jepler/src/micropython/ports/uni

    0x555555cd8dc8 is located 0 bytes to the right of global variable
    'import_str' defined in '../../py/repl.c:285:23' (0x555555cd8dc0) of
    size 8
      'import_str' is ascii string 'import '

Signed-off-by: Jeff Epler <jepler@gmail.com>

asan considers that memcmp(p, q, N) is permitted to access N bytes at each
of p and q, even for values of p and q that have a difference earlier.
Accessing additional values is frequently done in practice, reading 4 or
more bytes from each input at a time for efficiency, so when completing
"non_exist<TAB>" in the repl, this causes a diagnostic:

    ==16938==ERROR: AddressSanitizer: global-buffer-overflow on
    address 0x555555cd8dc8 at pc 0x7ffff726457b bp 0x7fffffffda20 sp 0x7fff
    READ of size 9 at 0x555555cd8dc8 thread T0
        #0 0x7ffff726457a  (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a)
        micropython#1 0x555555b0e82a in mp_repl_autocomplete ../../py/repl.c:301
        micropython#2 0x555555c89585 in readline_process_char ../../lib/mp-readline/re
        micropython#3 0x555555c8ac6e in readline ../../lib/mp-readline/readline.c:513
        micropython#4 0x555555b8dcbd in do_repl /home/jepler/src/micropython/ports/uni
        micropython#5 0x555555b90859 in main_ /home/jepler/src/micropython/ports/unix/
        micropython#6 0x555555b90a3a in main /home/jepler/src/micropython/ports/unix/m
        micropython#7 0x7ffff619a09a in __libc_start_main ../csu/libc-start.c:308
        micropython#8 0x55555595fd69 in _start (/home/jepler/src/micropython/ports/uni

    0x555555cd8dc8 is located 0 bytes to the right of global variable
    'import_str' defined in '../../py/repl.c:285:23' (0x555555cd8dc0) of
    size 8
      'import_str' is ascii string 'import '

Signed-off-by: Jeff Epler <jepler@gmail.com>

ports/riot: fix include in mpconfigport.h

fix rp2040 with new shared irq usb handler

Update changes of the last month for new hardware models