- 28 May, 2020 40 commits
-
-
Ulf Hansson authored
The MMC_CAP_ERASE bit is no longer used by the mmc core as erase, discard and trim operations are now always supported. Therefore, drop the bit and move all mmc hosts away from using it. Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by:
Rui Miguel Silva <rmfrfs@gmail.com> Link: https://lore.kernel.org/r/20200508112902.23575-1-ulf.hansson@linaro.orgReviewed-by:
Linus Walleij <linus.walleij@linaro.org>
-
Ulf Hansson authored
Step by step, mmc host drivers and the mmc core have been improved in regards to support erase/discard/trim operations. We have now reached a point when it no longer seems reasonable to use an opt-in approach to enable the functionality. Therefore, let's switch to make the operations always supported. Signed-off-by:
-
Ulf Hansson authored
Using a fixed 1s polling timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the polling to be aborted, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Note that, even if the sdricoh_cs driver may currently not support HW busy detection on DAT0, some comments in the code refer to that the HW may support it. Therefore, it seems better to be proactive in this case. Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Ulf Hansson authored
Rather than to poll in a busy-loop, let's convert into using read_poll_timeout() and insert a small delay between each polling attempts. In particular, this avoids hogging the CPU. Additionally, to convert to read_poll_timeout() we also need to switch from using a specific number of polling attempts, into a specific timeout in us instead. The previous 100000 attempts, is translated into a total timeout of total 1s, as that seemed like reasonable value to pick. Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Ulf Hansson authored
Rather than to poll in a busy-loop, let's convert into using read_poll_timeout() and insert a small delay between each polling attempts. In particular, this avoids hogging the CPU. Additionally, to convert to read_poll_timeout() we also need to switch from using a specific number of polling attempts, into a specific timeout in us instead. The previous 100000 attempts, is translated into a total timeout of total 1s, as that seemed like reasonable value to pick. Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Ulf Hansson authored
Some commands uses R1B responses, which means the card may assert the DAT0 line to signal busy for a period of time, after it has received the command. The mmc core normally specifies the busy period for the command in the cmd->busy_timeout. Ideally the driver should respect it, but that requires quite some update of the code, so let's defer that to someone with the HW at hand. Instead, let's inform the mmc core about the maximum supported busy timeout in ->max_busy_timeout during ->probe(). This value corresponds to the fixed ~2s timeout of the polling loop, implemented in cb710_wait_for_event(). In this way, we let the mmc core validate the needed timeout, which may lead to that it converts from a R1B into a R1 response and then use CMD13 to poll for busy completion. In other words, this change enables support for commands with longer busy periods than 2s, like erase (CMD38) for example. Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20200507192218.GA16315@embeddedorSigned-off-by:
-
Martin Blumenstingl authored
The vendor driver (from the 3.10 kernel) triggers a soft reset every time before starting a new command. While this fixes a problem where SDIO cards are not detected at all (because all commands simply timed out) this hurts SD card read performance a bit (in my tests between 10% to 20%). Trigger a soft reset after we got a CRC error or if the previous command timed out (just like the vendor driver from the same 3.10 kernel for the newer SDHC controller IP does). This fixes detection of SDIO cards and doesn't hurt SD card read performance at the same time. With this patch the initialization of an RTL8723BS SDIO card looks like this: req done (CMD52): -110: 00000000 00000000 00000000 00000000 clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 21 width 1 timing 0 starting CMD0 arg 00000000 flags 000000c0 req done (CMD0): 0: 00000000 00000000 00000000 00000000 clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 1 timing 0 starting CMD8 arg 000001aa flags 000002f5 req done (CMD8): -110: 00000000 00000000 00000000 00000000 starting CMD5 arg 00000000 flags 000002e1 req done (CMD5): 0: 90ff0000 00000000 00000000 00000000 starting CMD5 arg 00200000 flags 000002e1 req done (CMD5): 0: 90ff0000 00000000 00000000 00000000 starting CMD3 arg 00000000 flags 00000075 req done (CMD3): 0: 00010000 00000000 00000000 00000000 starting CMD7 arg 00010000 flags 00000015 req done (CMD7): 0: 00001e00 00000000 00000000 00000000 starting CMD52 arg 00000000 flags 00000195 req done (CMD52): 0: 00001032 00000000 00000000 00000000 [... more CMD52 omitted ...] clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 1 timing 2 clock 50000000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 1 timing 2 starting CMD52 arg 00000e00 flags 00000195 req done (CMD52): 0: 00001000 00000000 00000000 00000000 starting CMD52 arg 80000e02 flags 00000195 req done (CMD52): 0: 00001002 00000000 00000000 00000000 clock 50000000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 4 timing 2 starting CMD52 arg 00020000 flags 00000195 req done (CMD52): 0: 00001007 00000000 00000000 00000000 [... more CMD52 omitted ...] new high speed SDIO card at address 0001 Fixes: ed80a13b ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs") Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20200503222805.2668941-1-martin.blumenstingl@googlemail.comTested-by:
Tobias Baumann <017623705678@o2online.de> Signed-off-by:
-
Lad Prabhakar authored
Add support for r8a7742 SoC. Renesas RZ/G1H (R8A7742) MMCIF is identical to the R-Car Gen2 family. Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by:
Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/1588794695-27852-2-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.comSigned-off-by:
-
Wolfram Sang authored
The 'pengutronix' address is defunct for years. Use the proper contact address. Signed-off-by:
Wolfram Sang <wsa@kernel.org> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200502142840.19418-1-wsa@kernel.orgSigned-off-by:
-
Krishna Konda authored
Following eMMC JEDEC JESD84-B51 standard, an enhanced form of rpmb is supported. What this enhanced mode supports is in addition to be able to write one rpmb or two rpmb frames at a time, 32 frames can be written at a time. Expose this information present in ext csd field so that the user space application that wants to make use of this can do so. Signed-off-by:
Krishna Konda <kkonda@codeaurora.org> Signed-off-by:
Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Link: https://lore.kernel.org/r/1588341189-4371-1-git-send-email-vbadigan@codeaurora.orgSigned-off-by:
-
Ulf Hansson authored
According to the comment in mmc_sdio_reinit_card(), some SDIO cards may require a "[CMD5,5,3,7] init sequence", which isn't always obeyed in mmc_sdio_init_card(). Especially, when we end up retrying the UHS-I specific initialization, there is a missing CMD5. Let's update the code to make the behaviour consistent and let's also take the opportunity to clean up the code a bit, to avoid open coding. Signed-off-by:
-
Ulf Hansson authored
While initializing an SDIO card in mmc_sdio_init_card(), we may need to retry the UHS-I specific initialization, in case the first attempt fails. This leads to resending a CMD8, but also to restart from scratch with the so called OCR mask negotiations. This is unnecessary as we already have a negotiated OCR mask, so let's use that instead. In this way, the behaviour also becomes more consistent with other similar paths. Signed-off-by:
-
Ulf Hansson authored
Over the years, the code in mmc_sdio_init_card() has grown to become quite messy. Unfortunate this has also lead to that several paths are leaking memory in form of an allocated struct mmc_card, which includes additional data, such as initialized struct device for example. Unfortunate, it's a too complex task find each offending commit. Therefore, this change fixes all memory leaks at once. Cc: <stable@vger.kernel.org> Signed-off-by:
-
Ulf Hansson authored
During some scenarios mmc_sdio_init_card() runs a retry path for the UHS-I specific initialization, which leads to removal of the previously allocated card. A new card is then re-allocated while retrying. However, in one of the corresponding error paths we may end up to remove an already removed card, which likely leads to a NULL pointer exception. So, let's fix this. Fixes: 5fc3d80e ("mmc: sdio: don't use rocr to check if the card could support UHS mode") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Rajendra Nayak authored
Even though specifying OPP's in device tree is optional, ignoring all errors reported by dev_pm_opp_of_add_table() means we can't distinguish between a missing OPP table and a wrong/buggy OPP table. While missing OPP table (dev_pm_opp_of_add_table() returns a -ENODEV in such case) can be ignored, a wrong/buggy OPP table in device tree should make the driver error out. while we fix that, lets also fix the variable names for opp/opp_table to avoid confusion and name them opp_table/has_opp_table instead. Suggested-by:
Matthias Kaehlcke <matthias@chromium.org> Signed-off-by:
Rajendra Nayak <rnayak@codeaurora.org> Link: https://lore.kernel.org/r/1588080785-6812-10-git-send-email-rnayak@codeaurora.orgSigned-off-by:
-
Takeshi Saito authored
With R-Car Gen3, CRC error occue at the following TAPs. H3, M3W 1.3, M3N... TAP=2,3,6,7 M3W 3.0 ... TAP=1,3,5,7 (Note: for 4tap SoCs, the numbers get divided by 2) Do not use these TAPs in HS400, and also don't use auto correction but manual correction. We check for bad taps in two places: 1) After tuning HS400: Then, we select a neighbouring TAP. One of them must be good, because there are never three bad taps in a row. Retuning won't help because we just finished tuning. 2) After a manual correction request: Here, we can't switch to the requested TAP. But we can retune (if the HS200 tuning was good) because the environment might have changed since the last tuning. If not, we stay on the same TAP. Signed-off-by:
Takeshi Saito <takeshi.saito.xv@renesas.com> [wsa: refactored to match upstream driver, reworded commit msg] Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20200423130432.9990-3-wsa+renesas@sang-engineering.comSigned-off-by:
-
Wolfram Sang authored
For ES1.2, add a comment explaining the situation. For ES1.3 (and later, although unlikely), add a new entry defining it as 4tap. Signed-off-by:
-
Ulf Hansson authored
Using a fixed 3s polling timeout for all commands with R1B responses is a bit problematic. For some commands it means waiting longer than needed for the polling to be aborted, which may not a big issue, but still. For other commands, like for an erase (CMD38), may require longer timeouts than 3s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Ulf Hansson authored
Clarify the use of r1b_timeout, by renaming it to MMC_SPI_R1B_TIMEOUT_MS and by dropping the corresponding confusing comment about it. Additionally, let's also add a new define, MMC_SPI_INIT_TIMEOUT_MS and use it during the initialization. Even if these two defines are given the same value, the split makes it easier to understand them. Cc: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Ulf Hansson authored
Using a fixed 1s timeout for all commands (and data transfers) is a bit problematic. For some commands it means waiting longer than needed for the timer to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Bruce Chang <brucechang@via.com.tw> Cc: Harald Welte <HaraldWelte@viatech.com> Signed-off-by:
-
Ulf Hansson authored
Some commands uses R1B responses, which means the card may assert the DAT0 line to signal busy for a period of time, after it has received the command. The mmc core normally specifies the busy period for the command in the cmd->busy_timeout. Ideally the driver should respect it, but that requires quite some update of the code, so let's defer that to someone with the HW at hand. Instead, let's inform the mmc core about the maximum supported busy timeout in ->max_busy_timeout during ->probe(). This value corresponds to the fixed 1s timeout used by tifm_sd. In this way, we let the mmc core validate the needed timeout, which may lead to that it converts from a R1B into a R1 response and then use CMD13 to poll for busy completion. In other words, this change enables support for commands with longer busy periods than 1s, like erase (CMD38) for example. Cc: Alex Dubov <oakad@yahoo.com> Signed-off-by:
-
Ulf Hansson authored
The in-parameter timeout is always set to TRANSFER_TIMEOUT by the callers of sdricoh_query_status(), hence let's drop it. Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Ulf Hansson authored
Move MMC_APP_CMD specific handling to be managed by sdricoh_mmc_cmd(), as this makes the code a bit cleaner. Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Ulf Hansson authored
Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Ulf Hansson authored
Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Ulf Hansson authored
For commands that doesn't involve to prepare a data transfer, owl-mmc is using a fixed 30s response timeout. This is a bit problematic. For some commands it means waiting longer than needed for the completion to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 30s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
-
Ulf Hansson authored
Some commands uses R1B responses, which means the card may assert the DAT0 line to signal busy for a period of time, after it has received the command. The mmc core normally specifies the busy period for the command in the cmd->busy_timeout. Ideally the driver should respect it, but that requires quite some update of the code, so let's defer that to someone with the HW at hand. Instead, let's inform the mmc core about the maximum supported busy timeout in ->max_busy_timeout during ->probe(). This value corresponds to the fixed 5s timeout used by jz4740. In this way, we let the mmc core validate the needed timeout, which may lead to that it converts from a R1B into a R1 response and then use CMD13 to poll for busy completion. In other words, this change enables support for commands with longer busy periods than 5s, like erase (CMD38) for example. Cc: Paul Cercueil <paul@crapouillou.net> Signed-off-by:
-
Zou Wei authored
Fix the following sparse warning: drivers/mmc/host/sdhci-pci-o2micro.c:497:6: warning: symbol 'sdhci_pci_o2_set_clock' was not declared. Should it be static? drivers/mmc/host/sdhci-pci-o2micro.c:512:5: warning: symbol 'sdhci_pci_o2_probe_slot' was not declared. Should it be static? drivers/mmc/host/sdhci-pci-o2micro.c:581:5: warning: symbol 'sdhci_pci_o2_probe' was not declared. Should it be static? drivers/mmc/host/sdhci-pci-o2micro.c:786:5: warning: symbol 'sdhci_pci_o2_resume' was not declared. Should it be static? Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zou Wei <zou_wei@huawei.com> Acked-by:
-
Zou Wei authored
Fixes coccicheck warning: drivers/mmc/core/debugfs.c:222:0-23: WARNING: mmc_clock_fops should be defined with DEFINE_DEBUGFS_ATTRIBUTE Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE for debugfs files Fixes: 703aae3d ("mmc: add a file to debugfs for changing host clock at runtime") Fixes: a04c50aa ("mmc: core: no need to check return value of debugfs_create functions") Reported-by:
-
Masahiro Yamada authored
If sdhci-of-at91.c is compiled without CONFIG_HAVE_CLK, the line caps1 |= FIELD_PREP(SDHCI_CLOCK_MUL_MASK, clk_mul); ... emits "FIELD_PREP: value too large for the field" warning. The compiler seems to decide clk_mul is constant (unsigned int)-1, because clk_get_rate() returns 0 when CONFIG_HAVE_CLK is disabled. Add HAVE_CLK to the depenency since this driver does not work without the clock APIs anyway. Reported-by:
Randy Dunlap <rdunlap@infradead.org> Suggested-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Link: https://lore.kernel.org/r/20200422153401.7913-1-yamada.masahiro@socionext.comSigned-off-by:
-
Wolfram Sang authored
After TAP refactorization, we can use 'unsigned int' for two more variables because all the calculations work on this type now. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20200420170230.9091-1-wsa+renesas@sang-engineering.comSigned-off-by:
-
Ludovic Barre authored
This patch fix a power-on issue, and avoid to retry the power sequence. In power off sequence: sdmmc must set pwr_reg in "power-cycle" state (value 0x2), to prevent the card from being supplied through the signal lines (all the lines are driven low). In power on sequence: when the power is stable, sdmmc must set pwr_reg in "power-off" state (value 0x0) to drive all signal to high before to set "power-on". To avoid writing the same value to the power register several times, this register is cached by the pwr_reg variable. At probe pwr_reg is initialized to 0 by kzalloc of mmc_alloc_host. Like pwr_reg value is 0 at probing, the power on sequence fail because the "power-off" state is not writes (value 0x0) and the lines remain drive to low. This patch initializes "pwr_reg" variable with power register value. This it done in sdmmc variant init to not disturb default mmci behavior. Signed-off-by:
Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200420161831.5043-1-ludovic.barre@st.comSigned-off-by:
-
Rajendra Nayak authored
On some qualcomm SoCs we need to vote on a performance state of a power domain depending on the clock rates. Hence move to using OPP api to set the clock rate and performance state specified in the OPP table. On platforms without an OPP table, dev_pm_opp_set_rate() is eqvivalent to clk_set_rate() Signed-off-by:
-
Ulf Hansson authored
Using a fixed 1s timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the timeout to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Rui Miguel Silva <rmfrfs@gmail.com> Cc: Johan Hovold <johan@kernel.org> Cc: Alex Elder <elder@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: greybus-dev@lists.linaro.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20200414161413.3036-20-ulf.hansson@linaro.orgSigned-off-by:
-
Ulf Hansson authored
Some commands uses R1B responses, which means the card may assert the DAT0 line to signal busy for a period of time, after it has received the command. The mmc core normally specifies the busy period for the command in the cmd->busy_timeout. Ideally the driver should respect it, but that requires quite some update of the code, so let's defer that to someone with the HW at hand. Instead, let's inform the mmc core about the maximum supported busy timeout in ->max_busy_timeout during ->probe(). This value corresponds to the fixed 4s timeout used by usdhi6rol0. In this way, we let the mmc core validate the needed timeout, which may lead to that it converts from a R1B into a R1 response and then use CMD13 to poll for busy completion. In other words, this change enables support for commands with longer busy periods than 4s, like erase (CMD38) for example. Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Lars Persson <lars.persson@axis.com> Signed-off-by:
Jesper Nilsson <jesper.nilsson@axis.com> Link: https://lore.kernel.org/r/20200414161413.3036-6-ulf.hansson@linaro.orgSigned-off-by:
-
Ulf Hansson authored
Using a fixed 2s timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the timer to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 2s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
Ludovic Desroches <ludovic.desroches@microchip.com> Link: https://lore.kernel.org/r/20200414161413.3036-4-ulf.hansson@linaro.orgSigned-off-by:
-
Ulf Hansson authored
Setting the timer on a per request basis, is rather limiting as the timer really depends on what commands that is to be sent as part of the request. Therefore improve the behaviour by programming the timer per command basis instead. Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
-
Ulf Hansson authored
When atmci_request_end() is about to finish a request for one slot, there is a possibility that there is new request queued for another slot. If this turns out to be the case, the new request is started and the timer is re-programmed for it. Although, a few lines below in atmci_request_end(), this timer becomes deleted, likely corresponding to the other recently completed request. This looks wrong, so let's fix it. Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
-
Veerabhadrarao Badiganti authored
ADMA_ERR_SIZE_EN bit of VENDOR_SPECIFIC_FUNC register controls ADMA length mismatch error interrupt. Enable it by default. And update all bit shift defines with BIT macro. Signed-off-by:
-
