Fixes#4429
Driver didn't work properly when a transfer consisted of multiple
messages.
Fix doesn't use auto end mode anymore. msg_done function waits for
transfer to complete and issues stop condition if necessary.
Tested with stm32f3_disco board and samples/drivers/i2c_fujitsu_fram
example adapted to use I2C_1 as I2C_DEV
Signed-off-by: Daniel Wagenknecht <wagenknecht@clage.de>
Fix TinyCrypt shim driver Kconfig dependencies.
Limit the scope of crypto_driver_api functions to driver file only.
Remove dead code from crypto_tc_shim_priv.h
Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
GPIO_PIN_ENABLE, GPIO_PIN_DISABLE configuration constants overlap
functionality provided by pinmux driver. They usage makes the API
inconsistent. They are almost uniformly ignored by the existing device
drivers. Only few of them take these constants into account.
This commit deprecates usage of the two configuration constants.
Signed-off-by: Piotr Mienkowski <piotr.mienkowski@gmail.com>
Instead of every hardware number generator driver providing an
implementation of this function, use the random device API to
centralize the implementation of this function.
This is a very simplistic function that can be seen as a stepping stone
to refactor the random number generation in Zephyr.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
This should clear up some of the confusion with random number
generators and drivers that obtain entropy from the hardware. Also,
many hardware number generators have limited bandwidth, so it's natural
for their output to be only used for seeding a random number generator.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Some "random" drivers are not drivers at all: they just implement the
function `sys_rand32_get()`. Move those to a random subsystem in
preparation for a reorganization.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Certain interrupt-driven APIs were excluded as they are intended
only to be called from ISRs, or involve registering a callback
which runs in interrupt context.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
spi_transceive_async() omitted as we don't support k_poll objects
in user mode (yet).
The checking for spi_transceive() is fairly complex as we have to
validate the config struct passed in along with device instances
contained within it.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Many APIs had two versions, by port and by pin, which called the same
API with different parameters. This has been reorganized to reduce
the number of system calls.
Callback registration API skipped.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
pinmux_pin_get() needs memory validated for the func parameter since
it's a pointer that gets written to.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The page_layout API returns pointers to kernel memory and is not
exposed to user mode. This is fine for flash_get_page_count()
and flash_get_page_info APIs since these copy the values, but some
redesign work will be needed to get flash_page_foreach() working in
user mode since we do not want the callback running in a privileged
state.
Due to the way that (even unimplemented) system call prototypes are
generated, the definition of struct flash_pages_info needed to be
moved outside of the #ifdef.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Straightforward conversion for adc_enable/disable.
adc_read() uses a sequence table, which points to an array
of struct adc_seq_entry, each element pointing
to memory buffers. Need to validate all of these as being readable
by the caller, and the buffers writable.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
i2c actually only has two entry points into the driver,
i2c_configure and i2c_transfer. All the other APIs are derived
from these.
All derived APIs now just call i2c_transfer() with appropriate args.
The handler for i2c_transfer() needs to examine the message array
and validate all the buffers involved depending on whether we are
reading or writing to them.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Waiting for tx to complete should timeout after 10ms
instead of blocking forever in case ack is not received.
Signed-off-by: Kamil Sroka <kamil.sroka@nordicsemi.no>
Adding sleep before TX FIFO flash fixes splitting networking packets
sent over USB endpoints making ECM broken since there is no flow
control other then frame sizes.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
The situation when FIFO is not empty is not a bug and it is spamming
console when only bugs are enabled.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
The Designware FIFO is filled in units of 32 bit words, but the buffer
we are passed is not guaranteed to be a multiple of 4 bytes long, nor
aligned on a 4-byte boundary. So in theory we are reading 0-3 bytes
of unused garbage from the end of the array.
That's currently benign on supported platforms with this hardware,
which all support misaligned reads. But not all do. And the incoming
arrival of memory protection opens the possibility that those extra
bytes would cross a protection boundary and cause a crash or security
bug.
Do this right.
(Note that this is fixed to little endian byte order. The Designware
databook is frustratingly silent on the endianness it expects, but
existing hardware I can see is definitely LE and I see a few spots in
the Linux dwc2 driver that likewise assume LE).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The designware hardware in dedicated FIFO mode (which is all we
support right now for lack of shared-FIFO hardware) has one hardware
FIFO per IN (i.e. transmit) endpoint. But it doesn't assign them on
its own, it's the drivers responsibility to populate the TxFNum field
of the DIEPCTL registers with integer indices corresponding to the
desired FIFO.
We weren't doing that, which meant that all IN endpoints were sharing
the same FIFO zero which is supposed to be dedicated to EP0 control
transfers. The net effect is that sometimes outbound transfers would
be corrupted, showing data from the wrong endpoint. More often that
not this would leak from control transfers over to the
higher-bandwidth bulk endpoints of the application, but occasionally
you'd see a control transfer itself get borked and the USB device
would glitch.
Get this right and set the FIFOs properly.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There is no particular reason this spot in usb_dw_tx() cannot be
reached by racing threads on the same endpoint, though existing API
usage in the tree is all unithreaded. The FIFO state read at the top
of the function must still be true at the bottom or else the packet
byte count will be corrupt.
Also, as described in an existing comment, the databook has some
scary-sounding warnings about access to the registers during FIFO
operations, even if they "should" be on separate endpoints and
unrelated.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Issue a error message, if the _mcr20a_read_reg fails.
Do not execute SPI burst read/write if the buffer is too small.
Unlock mutex if set_pan_id, set_short_addr or set_ieee_addr
fail.
Force abort of the sequence when the higher level changes the channel
even though a T or TR sequence is in progress.
Signed-off-by: Johann Fischer <j.fischer@phytec.de>
checkpatch returns the following errors:
"ERROR:COMPLEX_MACRO: Macros with complex values
should be enclosed in parentheses"
Let's fix all of them.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
The WS2812 LED driver IC has a one-wire interface which encodes bit
values as pulse widths.
The ICs themselves are basically shift registers. Roughly speaking, a
"short" pulse shifts in a zero bit, a "long" pulse shifts in a one
bit, and an inter-pulse gap exceeding a reset time threshold causes a
pixel to latch the shifted-in color values. Each chip has an output
pin for daisy chaining. Refer to the chip datsheets and comments in
Kconfig.ws2812 for more details.
To meet timing without hogging the core, this driver generates pulses
using SPI. To work, this requires the MOSI line to stay low between
SPI frames, and for inter-frame delays to be less than the reset pulse
time.
There are other ways do it (PWM + DMA on some SoCs, GPIO bit-banging
if no other tasks need the core), but this is a reasonably
general-purpose implementation.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
LPD880x (e.g. LPD8803, LPD8806) devices are LED driver ICs which can
be controlled via a reduced SPI interface (clock and data only), and
support daisy chaining.
Add an led_strip driver for these devices.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
This API covers drivers for strips, or strings, of individually
addressable LEDs. Both RGB and grayscale LED strip drivers can be
implemented within these APIs.
The API only provides for updating the entire strip, since not all
strips support updating individual LEDs without affecting the others.
Subsequent patches will add individual driver support.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
This ensures DW_apb_i2c correctly transmits the slave address (7 or
10 bit) based on ic_10bitaddr_master when configured in master mode.
Signed-off-by: Rajavardhan Gundi <rajavardhan.gundi@intel.com>
The ic_tar and ic_sar were earlier set to 9 bits but now its
corrected to consider 10 bits.
Signed-off-by: Rajavardhan Gundi <rajavardhan.gundi@intel.com>
When the header file is located in the same directory as the source
file it is better to use a relative quote-include, e.g.
than a system include like
Avoiding the use of system includes in these cases is beneficial
because;
* The source code will be easier to build because there will be fewer
system include paths.
* It is easier for a user to determine where a quote-include header
file is located than where a system include is located.
* You are less likely to encounter aliasing issues if the list of
system include paths is minimized.
Authors:
Anas Nashif
Sebastian Bøe
Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
No need to send FCS bytes as the monitor_15_4 is configured to not
expect them. If we change the monitor_15_4 to use them, then we would
need to put correct values into these two FCS bytes.
So cleanest solution is not to send FCS bytes at all.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
`rc` gets assigned values from function returning `int` and not
`u32_t`.
Fixes#4051.
Coverity-ID: 177219
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Loopback is a networking interface which doesn't actually transfer
any data via link layer externally, and instead just mirrors back
(i.e. any packet send to the loopback interface will be received from
it). This interface very useful for testing.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
