- 28 5月, 2016 1 次提交
-
-
由 Arnd Bergmann 提交于
Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: NArnd Bergmann <arnd@arndb.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 03 3月, 2016 1 次提交
-
-
由 Emilio López 提交于
MODULE_DEVICE_TABLE() is missing, so the module isn't auto-loading on supported systems. This commit adds the missing line so it loads automatically when building it as a module and running on a system with the early sunxi DMA engine. Signed-off-by: NEmilio López <emilio.lopez@collabora.co.uk> Reviewed-by: NJavier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: NVinod Koul <vinod.koul@intel.com>
-
- 30 9月, 2015 1 次提交
-
-
由 Emilio López 提交于
Currently, sun4i_dma_free_contract iterates over lists and frees memory as it goes through them, causing reads to recently freed memory to be performed. Fix this by using the safe version of the iterator, so freed memory is not referenced at all. Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NEmilio López <emilio@elopez.com.ar> Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: NVinod Koul <vinod.koul@intel.com>
-
- 20 8月, 2015 1 次提交
-
-
由 Emilio López 提交于
This patch adds support for the DMA engine present on Allwinner A10, A13, A10S and A20 SoCs. This engine has two kinds of channels: normal and dedicated. The main difference is in the mode of operation; while a single normal channel may be operating at any given time, dedicated channels may operate simultaneously provided there is no overlap of source or destination. Hardware documentation can be found on A10 User Manual (section 12), A13 User Manual (section 14) and A20 User Manual (section 1.12) Signed-off-by: NEmilio López <emilio@elopez.com.ar> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: NVinod Koul <vinod.koul@intel.com>
-