When the requested number of GPIO lines is 0, return -EINVAL, not
-1 which is -EPERM.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We currently shift bits here and there without actually explaining
what we're doing. Add some helper variables with names indicating
their purpose to improve the code readability.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Currently we ignore the last odd range value, since each chip is
described by two values. Be more strict and require the user to
pass an even number of ranges.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Invert the logic of the irq_enabled check and only access the private
data after the input is sanitized.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We're currently only checking the first character of the input to the
debugfs event files, so a string like '0sdfdsf' is valid and indicates
a falling edge event.
Be more strict and only allow '0', '1', '0\n' & '1\n'.
While we're at it: move the sanitization code before the irq_enabled
check so that we indicate an error on invalid input even if nobody is
waiting for events.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
All IFC version >= 1.0 use 28nm technology for SRAM. Here SRAM has
a requirement to initialize before any read operation performed for
avoiding ECC Error.
So update condition check to initialize SRAM for all IFC version >= 1.0.0
Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Introduce some macros and helpers to avoid magic numbers and
rename macros/functions for clarification.
- We see '| 2' in several places. This means Data Cycle in MAP11 mode.
The Denali User's Guide says bit[1:0] of MAP11 is like follows:
b'00 = Command Cycle
b'01 = Address Cycle
b'10 = Data Cycle
So, this commit added DENALI_MAP11_{CMD,ADDR,DATA} macros.
- We see 'denali->flash_mem + 0x10' in several places, but 0x10 is a
magic number. Actually, this accesses the data port of the Host
Data/Command Interface. So, this commit added DENALI_HOST_DATA.
On the other hand, 'denali->flash_mem' gets access to the address
port, so DENALI_HOST_ADDR was also added.
- We see 'index_addr(denali, cmd, 0x1)' in denali_erase(), but 0x1
is a magic number. 0x1 means the erase operation. Replace 0x1
with DENALI_ERASE.
- Rename index_addr() to denali_host_write() for clarification
- Denali User's Guide says MAP{00,01,10,11} for access mode. Match
the macros with terminology in the IP document.
- Rename struct members as follows:
flash_bank -> active_bank (currently selected bank)
flash_reg -> reg (base address of registers)
flash_mem -> host (base address of host interface)
devnum -> devs_per_cs (devices connected in parallel)
bbtskipbytes -> oob_skip_bytes (number of bytes to skip in OOB)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Now this driver is ready to remove NAND_SKIP_BBTSCAN.
The BBT descriptors in denali.c are equivalent to the ones in
nand_bbt.c. There is no need to duplicate the equivalent structures.
The with-oob decriptors do not work for this driver anyway.
The bbt_pattern (offs = 8) and the version (veroffs = 12) area
overlaps the ECC area. Set NAND_BBT_NO_OOB flag to use the no_oob
variant of the BBT descriptors.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
For ecc->read_page() and ecc->write_page(), it is possible to call
dma_map_single() against the given buffer. This bypasses the driver
internal bounce buffer and save the memcpy().
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Recent versions of this IP support automatic erased page detection.
If an erased page is detected on reads, the controller does not set
INTR__ECC_UNCOR_ERR, but INTR__ERASED_PAGE.
The detection of erased pages is based on the number of zeros in a
page; if the number of zeros is less than the value in the field
ERASED_THRESHOLD, the page is assumed as erased.
Please note ERASED_THRESHOLD specifies the number of zeros in a _page_
instead of an ECC chunk. Moreover, the controller does not provide a
way to know the actual number of bitflips.
Actually, an erased page (all 0xff) is not an ECC correctable pattern
on the Denali ECC engine. In other words, there may be overlap between
the following two:
[1] a bit pattern reachable from a valid payload + ECC pattern within
ecc.strength bitflips
[2] a bit pattern reachable from an erased state (all 0xff) within
ecc.strength bitflips
So, this feature may intercept ECC correctable patterns, then replace
[1] with [2].
After all, this feature can work safely only when ECC_THRESHOLD == 1,
i.e. detect erased pages without any bitflips. This should be the
case most of the time. If there is a bitflip or more, the driver will
fallback to the software method by using nand_check_erased_ecc_chunk().
Strangely enough, the driver still has to fill the buffer with 0xff
in case of INTR__ERASED_PAGE because the ECC correction engine has
already manipulated the data in the buffer before it judges erased
pages.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
The Denali IP adopts the syndrome page layout; payload and ECC are
interleaved, with BBM area always placed at the beginning of OOB.
The figure below shows the page organization for ecc->steps == 2:
|----------------| |-----------|
| | | |
| | | |
| Payload0 | | |
| | | |
| | | |
| | | |
|----------------| | in-band |
| ECC0 | | area |
|----------------| | |
| | | |
| | | |
| Payload1 | | |
| | | |
| | | |
|----------------| |-----------|
| BBM | | |
|----------------| | |
|Payload1 (cont.)| | |
|----------------| |out-of-band|
| ECC1 | | area |
|----------------| | |
| OOB free | | |
|----------------| |-----------|
The current raw / oob accessors do not take that into consideration,
so in-band and out-of-band data are transferred as stored in the
device. In the case above,
in-band: Payload0 + ECC0 + Payload1(partial)
out-of-band: BBM + Payload1(cont.) + ECC1 + OOB-free
This is wrong. As the comment block of struct nand_ecc_ctrl says,
driver callbacks must hide the specific layout used by the hardware
and always return contiguous in-band and out-of-band data.
The current implementation is completely screwed-up, so read/write
callbacks must be re-worked.
Also, it is reasonable to support PIO transfer in case DMA may not
work for some reasons. Actually, the Data DMA may not be equipped
depending on the configuration of the RTL. This can be checked by
reading the bit 4 of the FEATURES register. Even if the controller
has the DMA support, dma_set_mask() and dma_map_single() could fail.
In either case, the driver can fall back to the PIO transfer. Slower
access would be better than giving up.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
It is not a good idea to re-use macros that represent a specific
register bit field for the transfer direction.
It is true that bit 8 indicates the direction for the MAP10 pipeline
operation and the data DMA operation, but this is not valid across
the IP.
Use a simple flag (write: 1, read: 0) for the direction.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
This driver stores the currently addressed page into denali->page,
which is later read out by helper functions. While I am tackling on
this driver, I often missed to insert "denali->page = page;" where
needed. This makes page_read/write callbacks to get access to a
wrong page, which is a bug hard to figure out.
Instead, I'd rather pass the page via function argument because the
compiler's prototype checks will help to detect bugs.
For the same reason, propagate dma_addr to the DMA helpers instead
of denali->buf.dma_buf .
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
The current bank reset implementation polls the INTR_STATUS register
until interested bits are set. This is not good because:
- polling simply wastes time-slice of the thread
- The while() loop may continue eternally if no bit is set, for
example, due to the controller problem. The denali_wait_for_irq()
uses wait_for_completion_timeout(), which is safer.
We can use interrupt by moving the denali_reset_bank() call below
the interrupt setup.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
The nand_scan_ident() iterates over maxchips, and calls nand_reset()
for each. This driver currently passes the maximum number of banks
(=chip selects) supported by the controller as maxchips. So, maxchips
is typically 4 or 8. Usually, less number of NAND chips are connected
to the controller.
This can be a problem for ONFi devices. Now, this driver implements
->setup_data_interface() hook, so nand_setup_data_interface() issues
Set Features (0xEF) command, which waits until the chip returns R/B#
response. If no chip there, we know it never happens, but the driver
still ends up with waiting for a long time. It will finally bail-out
with timeout error and the driver will work with existing chips, but
unnecessary wait will give a bad user experience.
The denali_nand_reset() polls the INTR__RST_COMP and INTR__TIME_OUT
bits, but they are always set even if not NAND chip is connected to
that bank. To know the chip existence, INTR__INT_ACT bit must be
checked; this flag is set only when R/B# is toggled. Since the Reset
(0xFF) command toggles the R/B# pin, this can be used to know the
actual number of chips, and update denali->max_banks.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
The NAND_CMD_SET_FEATURES support is missing from denali_cmdfunc().
We also see /* TODO: Read OOB data */ comment.
It would be possible to add more commands along with the current
implementation, but having ->cmd_ctrl() seems a better approach from
the discussion with Boris [1].
Rely on the default ->cmdfunc() from the framework and implement the
driver's own ->cmd_ctrl().
This transition also fixes NAND_CMD_STATUS and NAND_CMD_PARAM handling.
NAND_CMD_STATUS was just faked by the register read, so the only valid
bit was the WP bit. NAND_CMD_PARAM was completely broken; not only the
command sent on the bus was NAND_CMD_STATUS instead of NAND_CMD_PARAM,
but also the driver was only reading 8 bytes, while the parameter page
contains several hundreds of bytes.
Also add ->write_byte(), which is needed for write direction commands,
->read/write_buf(16), which will be used some commits later.
->read_word() is not used for now, but the core may call it in the
future.
Now, this driver can drop nand_onfi_get_set_features_notsupp().
[1] https://lkml.org/lkml/2017/3/15/97
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Simplify the interrupt handling and fix issues:
- The register field view of INTR_EN / INTR_STATUS is different
among IP versions. The global macro DENALI_IRQ_ALL is hard-coded
for Intel platforms. The interrupt mask should be determined at
run-time depending on the running platform.
- wait_for_irq() loops do {} while() until interested flags are
asserted. The logic can be simplified.
- The spin_lock() guard seems too complex (and suspicious in a race
condition if wait_for_completion_timeout() bails out by timeout).
- denali->complete is reused again and again, but reinit_completion()
is missing. Add it.
Re-work the code to make it more robust and easier to handle.
While we are here, also rename the jump label "failed_req_irq" to
more appropriate "disable_irq".
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Handling timing parameters in a driver's own way should be avoided
because it duplicates efforts of drivers/mtd/nand/nand_timings.c
Besides, this driver hard-codes Intel specific parameters such as
CLK_X=5, CLK_MULTI=4. Taking a certain device (Samsung K9WAG08U1A)
into account by get_samsung_nand_para() is weird as well.
Now, the core framework provides .setup_data_interface() hook, which
handles timing parameters in a generic manner.
While I am working on this, I found even more issues in the current
code, so fixed the following as well:
- In recent IP versions, WE_2_RE and TWHR2 share the same register.
Likewise for ADDR_2_DATA and TCWAW, CS_SETUP_CNT and TWB. When
updating one, the other must be masked. Otherwise, the other will
be set to 0, then timing settings will be broken.
- The recent IP release expanded the ADDR_2_DATA to 7-bit wide.
This register is related to tADL. As commit 74a332e78e ("mtd:
nand: timings: Fix tADL_min for ONFI 4.0 chips") addressed, the
ONFi 4.0 increased the minimum of tADL to 400 nsec. This may not
fit in the 6-bit ADDR_2_DATA in older versions. Check the IP
revision and handle this correctly, otherwise the register value
would wrap around.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
The function find_valid_banks() issues the Read ID (0x90) command,
then compares the first byte (Manufacturer ID) of each bank with
the one of bank0.
This is equivalent to what nand_scan_ident() does. The number of
chips is detected there, so this is unneeded.
What is worse for find_valid_banks() is that, if multiple chips are
connected to INTEL_CE4100 platform, it crashes the kernel by BUG().
This is what we should avoid. This function is just harmful and
unneeded.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
The denali_cmdfunc() actually does nothing valuable for
NAND_CMD_{PAGEPROG,READ0,SEQIN}.
For NAND_CMD_{READ0,SEQIN}, it copies "page" to "denali->page", then
denali_read_page(_raw) compares them just for the sanity check.
(Inconsistently, this check is missing from denali_write_page(_raw).)
The Denali controller is equipped with high level read/write interface,
so let's skip unneeded call of cmdfunc().
If NAND_ECC_CUSTOM_PAGE_ACCESS is set, nand_write_page() will not
call ->waitfunc hook. So, ->write_page(_raw) hooks should directly
return -EIO on failure. The error handling of page writes will be
much simpler.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
The null check functions do not and must not modify contents of the UUID
or GUID supplied.
Mark argument explicitly to reflect that.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
The ALSA PCM core refers to the appl_ptr value stored on the mmapped
page that is shared between kernel and user-space. Although the
reference is performed in the PCM stream lock, it doesn't guarantee
the atomic access when the value gets updated concurrently from the
user-space on another CPU.
In most of codes, this is no big problem, but still there are a few
places that may result in slight inconsistencies because they access
runtime->control->appl_ptr multiple times; that is, the second read
might be a different value from the first value. It can be even
backward or jumping, as we have no control for it. Hence, the
calculation may give an unexpected value. Luckily, there is no
security vulnerability by that, as far as I've checked. But still we
should address it.
This patch tries to reduce such possible cases. The fix is simple --
we just read once, store it to a local variable and use it for the
rest calculations. The READ_ONCE() macro is used for it in order to
avoid the ill-effect by possible compiler optimizations.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When the codec device is unregistered / freed, it may release the
resource while being used in an unsolicited event like the jack
detection work. This leads to use-after-free.
The fix here is to unregister the device at first, i.e. removing the
codec from the list, then flushing the pending works to assure that
all unsol events are gone. After this point, we're free from
accessing the codec via unsol events, thus can release the resources
gracefully.
The issue was spotted originally by Intel CI, but it couldn't be
reproduced reliably by its nature. So let's hope this fix really
addresses the whole issues.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196045
Reported-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We checked the quirks specific to the recent Intel chips by checking
the PCI IDs manually, but it's becoming messy with lots of IS_SKL()
and other macros, as the amount accumulated.
For simplification, here the new AZX_DRIVER_SKL type is introduced,
and check chip->driver_type instead of the manual PCI ID. The short
name for this is still "HDA Intel PCH", so that it doesn't break the
existing user-space unnecessarily.
Suggested-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Broxton-T was a forgotten child and we didn't apply the quirks for
Skylake+ properly. Meanwhile, a quirk for reducing the DMA latency
seems specific to the early Broxton model, so we leave as is.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Remove Initialization from POD HD500X because it's not needed.
Every time the device is connected dmesg gives the following output:
"receive length failed (error -11)".
To solve this problem, another flags is introduced
(LINE6_CAP_CONTROL_INFO) and it is only used for PODX3 in: sysfs
entries, call podhd_startup_finalize(pod) and disconnection.
With this patch the error disappear.
Signed-off-by: Hans P. Moller <hmoller@uc.cl>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add support for the Line6 POD HD500X multi effect processor for
playback and capture (in/out audio) through USB.
Signed-off-by: Hans P. Moller <hmoller@uc.cl>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On a POWER9 system, it is possible for an interrupt to become pending
for a VCPU when that VCPU is about to cede (execute a H_CEDE hypercall)
and has already disabled interrupts, or in the H_CEDE processing up
to the point where the XIVE context is pulled from the hardware. In
such a case, the H_CEDE should not sleep, but should return immediately
to the guest. However, the conditions tested in kvmppc_vcpu_woken()
don't include the condition that a XIVE interrupt is pending, so the
VCPU could sleep until the next decrementer interrupt.
To fix this, we add a new xive_interrupt_pending() helper which looks
in the XIVE context that was pulled from the hardware to see if the
priority of any pending interrupt is higher (numerically lower than)
the CPU priority. If so then kvmppc_vcpu_woken() will return true.
If the XIVE context has never been used, then both the pipr and the
cppr fields will be zero and the test will indicate that no interrupt
is pending.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
With the port_window support in DMAengine and the sDMA driver we can
convert the driver to DMAengine.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The external request lines are used by tusb6010 on OMAP24xx platforms.
Update the map so the driver can use dmaengine API to request the DMA
channel. At the same time add temporary map containing only the external
DMA request numbers for DT booted case on omap24xx since the tusb6010 stack
is not yet supports DT boot.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Handle the DMA TX in a similar way as we do for the RX: in the DMA
completion callback.
Since we are no longer using DMA completion interrupt for the TX we can as
wall keep these interrupts disabled, but keep the handler for debug
purposes.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Instead of requesting the DMA channel in tusb_omap_dma_allocate() do it
when the controller is created and in runtime work from the DMA channel
pool.
This change is needed for the DMAengine conversion of the driver since the
tusb_omap_dma_allocate() is called in interrupt context which might lead
to lock within the DMAengine API when requesting channel.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For the DMA we have ch (channel), dmareq and sync_dev parameters both
within the tusb_omap_dma_ch and tusb_omap_dma struct.
By creating a common struct the code can be simplified when selecting
between the shared or multichannel DMA parameters.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Having one musb_ep_select() instead the two calls in if/else is the same
thing, but makes the code a bit simpler to follow.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When using the g_ncm for networking this flag will make sure that the
buffer is aligned to 32bit so the DMA can be used to offload the data
movement.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For tusb6010 the DMA functionality only possible if the buffer is 32bit
aligned (SYNC access to FIFO) since with ASYNC access the TX/RX offset
registers will corrupt eventually.
The MUSB_G_NO_SKB_RESERVE will set the quirk_avoids_skb_reserve flag in
usb_gadget struct to provide correctly aligned buffer.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When the port_window support was verified it was done on setup where only
the MEM_TO_DEV direction was enabled. This got un-noticed and thus only
this direction worked.
Now that I have managed to get a setup to verify both direction it turned
out that the setup was incorrect:
omap_desc members are settings for the slave port while the omap_sg members
apply to the memory side of the sDMA setup.
Fixes: 527a275913 ("dmaengine: omap-dma: Fix the port_window support")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: dmaengine@vger.kernel.org
Cc: dan.j.williams@intel.com
Cc: vinod.koul@intel.com
Tested-by: Tony Lindgren <tony@atomide.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If dma_request_slave_channel() failed to return a channel,
then the driver will print an error and request to defer probe,
regardless of the cause of the failure.
Defer if the DMA is not ready yet otherwise print an error.
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Reviewed-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felipe writes:
usb: changes for v4.13 merge window
This time around we have a total of 57 non-merge commits. A list of
most important changes follows:
- Improvements to dwc3 tracing interface
- Initial dual-role support for dwc3
- Improvements to how we handle DMA resources in dwc3
- A new f_uac1 implementation which much more flexible
- Removal of AVR32 bits
- Improvements to f_mass_storage driver
of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by <linux/of.h> work with const
of_device_ids. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
2376 808 128 3312 cf0 drivers/crypto/caam/jr.o
File size after constify caam_jr_match:
text data bss dec hex filename
2976 192 128 3296 ce0 drivers/crypto/caam/jr.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
You can't reach init() if parent alg_name is invalid. Moreover,
cypto_alloc_base() will return ENOENT if alg_name is NULL.
Found while grasping the fallback mechanism.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by <linux/of.h> work with const
of_device_ids. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
2001 2168 48 4217 1079 drivers/crypto/n2_core.o
File size after constify dummy_tlb_ops.:
text data bss dec hex filename
3601 536 48 4185 1059 drivers/crypto/n2_core.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Increase the batch size to the maximum number of requests a ring can
handle at a time (its size). This is possible now that the request
queues are per hw ring. This improves performances.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
