Commit Graph

17 Commits (dbbdd0f0778e222186d5003679db2ead49f6fc45)

Author SHA1 Message Date
Harrison Mutai 0214a156e7 Implement override of enable_* functions 2021-01-21 10:20:49 +00:00
Harrison Mutai 7b8ca37bd7 Add declaration to expose enable_* functions from SerialBase
UnBufferedSerial is missing a declaration to expose enable_input and
enable_output, which are inherited from the private base class Serial
Base. Add the using-declaration to the class definition.
2021-01-19 14:28:54 +00:00
pea-pod e1c754b179 Add SPI bitwidths to ST targets where supported 2021-01-11 07:53:07 -06:00
Martin Kojtal be295e42a4
Merge pull request #13917 from LDong-Arm/move_SFDP
Move SFDP to blockdevice
2020-12-10 13:03:23 +00:00
Martin Kojtal 4c94b4b495
Merge pull request #14005 from kjbracey-arm/teinsert
Correct/clarify TimerEvent::insert documentation
2020-12-09 14:18:06 +00:00
Kevin Bracey cf66a6ed13 Correct/clarify TimerEvent::insert documentation
There was much confusion over the functionality of the original
`TimerEvent::insert` call which was described as "Set relative timestamp
of the internal event".

This then extended to my Chrono conversion, meaning the new `insert`
call is not equivalent.

Clarify the original documentation, correct the deprecation messages,
and add more notes on conversion.

No functional change, as the new Chrono API makes more sense - it's just
different from the old API.

Problem actually spotted when I saw the strange code `convert_timestamp`
was producing for the 32-bit->64-bit timestamp conversion. The caller of
it was actually making the mistake of issuing
"TimerEvent::insert(rel_timeout)`, meaning they'd also misunderstood the
documentation, and were not getting the timeout they expected.

(Chrono would have prevented that mistake as durations and time points
are incompatible types).
2020-12-07 16:28:52 +02:00
Lingkai Dong 5d2fbdc11e Move SFDP into blockdevice where it belongs to 2020-11-26 17:31:31 +00:00
Lingkai Dong c41f7cb864 Fix integer type warnings in SFDP and *SPIFBlockDevice 2020-11-26 10:28:58 +00:00
Lingkai Dong e0bd9a1c6a sfdp_iterate_next_largest_erase_type: return -1 if no erase type is applicable 2020-11-25 13:34:01 +00:00
Lingkai Dong ac86aff928 sfdp_iterate_next_largest_erase_type: do not modify type_mask
The supported erase types of a given flash region are indicated
in bitfields of the variable `type_mask`. Even if an erase type
is unused for the current chunk (e.g. size too large, unaligned, etc.),
its bitfield should NOT be cleared - the same erase type might
actually be useful for the next chunk.

The function argument is now a value instead of a reference.
2020-11-24 18:07:34 +00:00
Evelyne Donnaes 9964212f9e Moved USB drivers under drivers/usb 2020-11-12 14:57:00 +00:00
Martin Kojtal f333c3ead1
Merge pull request #13699 from boraozgen/bugfix/sfdp-find-addr-region
Fix sfdp_find_addr_region algorithm
2020-11-12 08:43:02 +00:00
Martino Facchin db7954bc9b STM32: allow high speed USB endpoints 2020-11-10 17:22:28 +01:00
Bora Özgen 7f0716ad60 Fix sfdp_find_addr_region algorithm
sfdp_find_addr_region() was causing issues with SPI
flashes with sector table parsed from SFDP (in
particular SST26VF016B).

In particular, it was returning -1 when address 0 is
passed (probably also if the address in the first
region). I do not know why the search algorithm is
written to search from the higher to lower regions,
but it was obvious that it would fail for the first
region. Also it was harder to read due to the index
manipulation.
2020-11-03 14:23:02 +01:00
rogeryou 48524f25ae add opsi driver 2020-09-16 11:27:23 +08:00
talorion 6625bdb9f3 fixed resets after suspend 2020-09-02 13:39:16 +02:00
George Psimenos 009f91e2cc Move drivers headers 2020-07-31 10:02:47 +01:00