Colin King writes:
> From: Colin Ian King
>
> Currently if the allocation of new_buf fails then a null pointer
> dereference occurs when assiging new_buf->vb. Avoid this by returning
> early on a memory allocation failure as there is not much more can
> be done at this point.
>
>
The current use of the mode flag SPI_CS_HIGH is fragile: it
overwrites anything already assigned by the SPI core.
Assign ^= SPI_CS_HIGH since we might be active high
already, and that is usually the case with GPIOs used
for chip select, even if they are in practice active low.
Add a comment
On Tue, 2019-12-03 at 10:39 -0500, Marcelo Diop-Gonzalez wrote:
> This undoes the previous call to alloc_chrdev_region() on failure,
> and is probably what was meant originally given the label name.
>
> Signed-off-by: Marcelo Diop-Gonzalez
> ---
>
Driver inverts meaning of GPIO_ACTIVE_LOW/HIGH. Fix it to prevent
confusion.
Signed-off-by: Michał Mirosław
---
drivers/staging/wfx/bus_spi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/wfx/bus_spi.c b/drivers/staging/wfx/bus_spi.c
index
On Wed, Dec 04, 2019 at 07:18:15AM +, Ardelean, Alexandru wrote:
> One example (for spi-cpha):
> if (of_property_read_u32(nc, "spi-cpha", ) == 0) {
> spi->mode |= SPI_CPHA_OVERRIDE;
> if (tmp)
> spi->mode |= SPI_CPHA;
We could also
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
debugfs_cleanup
head: d33387c085c2d53e86b2430ddf2861d48b573383
commit: 269c69a016f0c493a9932ea4bbc31bce4d64b059 [2/6] drm: make .debugfs_init
and drm_debugfs_create_files() return void
config: xtensa-allyesconfig
From: Colin Ian King
Currently if the allocation of new_buf fails then a null pointer
dereference occurs when assiging new_buf->vb. Avoid this by returning
early on a memory allocation failure as there is not much more can
be done at this point.
Addresses-Coverity: ("Dereference null return")
On Tue, Dec 03, 2019 at 04:51:54PM +, Jonathan Cameron wrote:
> If the driver picks a mode because that's what it says on the datasheet
> it prevents odd board configurations from working. The question
> becomes whether it makes sense in general to assume those odd board
> conditions don't
