'for_each_available_child_of_node' performs an of_node_get on each
iteration, so a return from the middle of the loop requires an of_node_put.
Fixes: bbb6b2f9865b ("spi: Add FSI-attached SPI controller driver")
Signed-off-by: Christophe JAILLET
---
drivers/spi/spi-fsi.c | 4 +++-
1 file changed,
It was previoulsy possible to have a device tree with more chips than
the driver supports and go off the end of CS arrays.
This patches inforces CS limit but sets that limit to the max of the
default limit and what is in the device tree when driver is loaded.
Signed-off-by: Joe Burmeister
---
d
On Mon, 19 Apr 2021 14:06:31 +0100, Joe Burmeister wrote:
> If the setup callback failed, but the controller has auto_runtime_pm
> and set_cs, the setup failure could be missed.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: Handle SPI
If the setup callback failed, but the controller has auto_runtime_pm
and set_cs, the setup failure could be missed.
Signed-off-by: Joe Burmeister
---
drivers/spi/spi.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 8b283b2c
On Tue, Apr 13, 2021 at 08:59:02PM +0800, Jay Fang wrote:
> On 2021/4/13 20:47, Mark Brown wrote:
> > On Tue, Apr 13, 2021 at 02:27:23PM +0200, Geert Uytterhoeven wrote:
> >> The HiSilicon Kunpeng SPI controller is only present on HiSilicon
> >> Kunpeng SoCs. Hence add a dependency on ARCH_HISI,
On 2021/4/13 20:47, Mark Brown wrote:
> On Tue, Apr 13, 2021 at 02:27:23PM +0200, Geert Uytterhoeven wrote:
>> The HiSilicon Kunpeng SPI controller is only present on HiSilicon
>> Kunpeng SoCs. Hence add a dependency on ARCH_HISI, to prevent asking
>> the user about this driver when configuring a
On Tue, Apr 13, 2021 at 02:27:23PM +0200, Geert Uytterhoeven wrote:
> The HiSilicon Kunpeng SPI controller is only present on HiSilicon
> Kunpeng SoCs. Hence add a dependency on ARCH_HISI, to prevent asking
> the user about this driver when configuring a kernel without Hisilicon
> platform support
The HiSilicon Kunpeng SPI controller is only present on HiSilicon
Kunpeng SoCs. Hence add a dependency on ARCH_HISI, to prevent asking
the user about this driver when configuring a kernel without Hisilicon
platform support.
Fixes: c770d8631e1810d8 ("spi: Add HiSilicon SPI Controller Driver for Ku
On Thu, 8 Apr 2021 18:33:47 +0800, Clark Wang wrote:
> When some drivers use spi to send data, spi_transfer->speed_hz is
> not assigned. If spidev->max_speed_hz is not assigned as well, it
> will cause an error in configuring the clock.
> Add a check for these two values before configuring the cloc
On Fri, 9 Apr 2021 00:57:18 +0500, Muhammad Usama Anjum wrote:
> If device_get_match_data returns NULL, devdata isn't being updated
> properly. It is being used later in the function. Both devdata and
> spi->devdata should be updated to avoid NULL pointer dereference.
Applied to
https://git.ke
For the header file comment? I think it's actually backwards since
`devm_allocated = true` would indicate the device is managed with
devres. Should I send a followup change or v2?
On Fri, Apr 9, 2021 at 12:20 AM Andy Shevchenko
wrote:
>
>
>
> On Wednesday, April 7, 2021, William A. Kennington II
> Hi Dinghao,
>
> On 4/8/21 6:33 PM, Michal Simek wrote:
> > ++
> >
> > On 4/8/21 11:25 AM, Dinghao Liu wrote:
> >> When platform_get_irq() fails, a pairing PM usage counter
> >> increment is needed to keep the counter balanced. It's the
> >> same for the following error paths.
> >>
> >> Signed-of
On Wed, 7 Apr 2021 at 09:55, William A. Kennington III wrote:
>
> We can't rely on the contents of the devres list during
> spi_unregister_controller(), as the list is already torn down at the
> time we perform devres_find() for devm_spi_release_controller. This
> causes devices registered with de
Hi Dinghao,
On 4/8/21 6:33 PM, Michal Simek wrote:
++
On 4/8/21 11:25 AM, Dinghao Liu wrote:
When platform_get_irq() fails, a pairing PM usage counter
increment is needed to keep the counter balanced. It's the
same for the following error paths.
Signed-off-by: Dinghao Liu
---
drivers/spi/s
If device_get_match_data returns NULL, devdata isn't being updated
properly. It is being used later in the function. Both devdata and
spi->devdata should be updated to avoid NULL pointer dereference.
Addresses-Coverity: ("NULL pointer dereference")
Fixes: 0e6521f13c2 ("spi: orion: Use device_get_m
On Wed, 7 Apr 2021 02:55:27 -0700, William A. Kennington III wrote:
> We can't rely on the contents of the devres list during
> spi_unregister_controller(), as the list is already torn down at the
> time we perform devres_find() for devm_spi_release_controller. This
> causes devices registered with
On Thu, 8 Apr 2021 17:25:59 +0800, Dinghao Liu wrote:
> When platform_get_irq() fails, a pairing PM usage counter
> increment is needed to keep the counter balanced. It's the
> same for the following error paths.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-ne
On Thu, Apr 08, 2021 at 06:33:47PM +0800, Clark Wang wrote:
> When some drivers use spi to send data, spi_transfer->speed_hz is
> not assigned. If spidev->max_speed_hz is not assigned as well, it
> will cause an error in configuring the clock.
Please don't send new patches in reply to other thread
On Thu, Apr 08, 2021 at 06:33:47PM +0800, Clark Wang wrote:
> When some drivers use spi to send data, spi_transfer->speed_hz is
> not assigned. If spidev->max_speed_hz is not assigned as well, it
> will cause an error in configuring the clock.
> Add a check for these two values before configuring
On Wed, Apr 07, 2021 at 02:55:27AM -0700, William A. Kennington III wrote:
> [ cut here ]
> WARNING: CPU: 1 PID: 660 at lib/refcount.c:28
> refcount_warn_saturate+0x108/0x174
> [] (refcount_warn_saturate) from []
> (kobject_put+0x90/0x98)
> [] (kobject_put) from [] (put_d
++
On 4/8/21 11:25 AM, Dinghao Liu wrote:
> When platform_get_irq() fails, a pairing PM usage counter
> increment is needed to keep the counter balanced. It's the
> same for the following error paths.
>
> Signed-off-by: Dinghao Liu
> ---
> drivers/spi/spi-zynqmp-gqspi.c | 1 +
> 1 file changed,
When some drivers use spi to send data, spi_transfer->speed_hz is
not assigned. If spidev->max_speed_hz is not assigned as well, it
will cause an error in configuring the clock.
Add a check for these two values before configuring the clock. An
error will be returned when they are not assigned.
Sig
Enable 16/32 bits per word support for spi-imx slave mode.
It only support 8 bits per word in slave mode before.
Signed-off-by: Clark Wang
Reviewed-by: Haibo Chen
---
drivers/spi/spi-imx.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-imx.c b
When platform_get_irq() fails, a pairing PM usage counter
increment is needed to keep the counter balanced. It's the
same for the following error paths.
Signed-off-by: Dinghao Liu
---
drivers/spi/spi-zynqmp-gqspi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-zynqmp-gqspi.
We can't rely on the contents of the devres list during
spi_unregister_controller(), as the list is already torn down at the
time we perform devres_find() for devm_spi_release_controller. This
causes devices registered with devm_spi_alloc_{master,slave}() to be
mistakenly identified as legacy, non-
On Wed, Mar 24, 2021 at 05:17:52PM -0700, Dmitry Torokhov wrote:
> OK, I can look into it. In the meantime wills something like below a bit
> easier for you to stomach? If so I'll resubmit formally.
Well, it's a bit nicer for a bus level bodge so I guess, but really I'm
more thinking we need some
On Sat, Mar 27, 2021 at 03:33:57PM -0500, Rob Herring wrote:
> The 'spi-nor' compatible used in the example is not documented. Use the
> documented 'jedec,spi-nor' compatible instead.
>
> Cc: Mark Brown
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: linux-...@vger.kernel.org
> Cc: linux-te...
On Sat, Mar 27, 2021 at 03:33:57PM -0500, Rob Herring wrote:
> The 'spi-nor' compatible used in the example is not documented. Use the
> documented 'jedec,spi-nor' compatible instead.
>
> Cc: Mark Brown
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: linux-...@vger.kernel.org
> Cc: linux-te...
The 'spi-nor' compatible used in the example is not documented. Use the
documented 'jedec,spi-nor' compatible instead.
Cc: Mark Brown
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: linux-...@vger.kernel.org
Cc: linux-te...@vger.kernel.org
Signed-off-by: Rob Herring
---
Documentation/devicetree/bi
On Wed, 24 Mar 2021 17:05:16 -0500, Eddie James wrote:
> Updated restricted chips have trouble processing multiple sequenced
> operations. So remove the capability to sequence multiple operations and
> reduce the maximum transfer size to 8 bytes.
Applied to
https://git.kernel.org/pub/scm/linux
On Thu, Mar 25, 2021 at 09:46:50AM -0500, Eddie James wrote:
> On Thu, 2021-03-25 at 13:50 +, Mark Brown wrote:
> > On Wed, Mar 24, 2021 at 05:05:16PM -0500, Eddie James wrote:
> > > Updated restricted chips have trouble processing multiple sequenced
> > > operations. So remove the capability
On Thu, 2021-03-25 at 13:50 +, Mark Brown wrote:
> On Wed, Mar 24, 2021 at 05:05:16PM -0500, Eddie James wrote:
>
> > Updated restricted chips have trouble processing multiple sequenced
> > operations. So remove the capability to sequence multiple
> > operations and
> > reduce the maximum tran
On Wed, Mar 24, 2021 at 05:05:16PM -0500, Eddie James wrote:
> Updated restricted chips have trouble processing multiple sequenced
> operations. So remove the capability to sequence multiple operations and
> reduce the maximum transfer size to 8 bytes.
That's a very small limit, it would be nice
On Wed, 24 Mar 2021 at 22:05, Eddie James wrote:
>
> Updated restricted chips have trouble processing multiple sequenced
> operations. So remove the capability to sequence multiple operations and
> reduce the maximum transfer size to 8 bytes.
>
> Signed-off-by: Eddie James
Reviewed-by: Joel Stan
On Wed, Mar 24, 2021 at 11:39:35PM +, Mark Brown wrote:
> On Wed, Mar 24, 2021 at 03:27:23PM -0700, Dmitry Torokhov wrote:
> > On Wed, Mar 24, 2021 at 09:32:26PM +, Mark Brown wrote:
>
> > > TBH that looks like a fairly standard case where you probably don't want
> > > to be using devm for
On Wed, Mar 24, 2021 at 03:27:23PM -0700, Dmitry Torokhov wrote:
> On Wed, Mar 24, 2021 at 09:32:26PM +, Mark Brown wrote:
> > TBH that looks like a fairly standard case where you probably don't want
> > to be using devm for the interrupts in the first place. Leaving the
> > interrupts live a
On Wed, Mar 24, 2021 at 09:32:26PM +, Mark Brown wrote:
> On Tue, Mar 23, 2021 at 12:04:34PM -0700, Dmitry Torokhov wrote:
> > On Tue, Mar 23, 2021 at 05:36:06PM +, Mark Brown wrote:
>
> > No it is ordering issue. I do not have a proven real-life example for
> > SPI, but we do have one for
Updated restricted chips have trouble processing multiple sequenced
operations. So remove the capability to sequence multiple operations and
reduce the maximum transfer size to 8 bytes.
Signed-off-by: Eddie James
---
drivers/spi/spi-fsi.c | 27 +++
1 file changed, 7 inser
On Tue, Mar 23, 2021 at 12:04:34PM -0700, Dmitry Torokhov wrote:
> On Tue, Mar 23, 2021 at 05:36:06PM +, Mark Brown wrote:
> No it is ordering issue. I do not have a proven real-life example for
> SPI, but we do have one for I2C:
> https://lore.kernel.org/linux-devicetree/20210305041236.3489-
On Tue, Mar 23, 2021 at 05:36:06PM +, Mark Brown wrote:
> On Mon, Mar 22, 2021 at 12:38:15PM -0700, Dmitry Torokhov wrote:
> > On Mon, Mar 22, 2021 at 12:37:07PM +, Mark Brown wrote:
>
> > > This feels like it might make sense to push up to the driver core level
> > > then rather than doin
On Mon, Mar 22, 2021 at 12:38:15PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 22, 2021 at 12:37:07PM +, Mark Brown wrote:
> > This feels like it might make sense to push up to the driver core level
> > then rather than doing in individual buses?
> That is exactly the issue: we can't. Driver
On Mon, Mar 22, 2021 at 12:37:07PM +, Mark Brown wrote:
> On Sun, Mar 21, 2021 at 06:43:32PM -0700, Dmitry Torokhov wrote:
>
> > Note that this is not SPI-specific issue. I already send a similar
> > patch for I2C and will be sending more.
>
> This feels like it might make sense to push up to
On Sun, Mar 21, 2021 at 06:43:32PM -0700, Dmitry Torokhov wrote:
> Note that this is not SPI-specific issue. I already send a similar
> patch for I2C and will be sending more.
This feels like it might make sense to push up to the driver core level
then rather than doing in individual buses?
sig
More and more drivers rely on devres to manage their resources, however
if bus' probe() and release() methods are not trivial and control some
of resources as well (for example enable or disable clocks, or attach
device to a power domain), we need to make sure that driver-allocated
resources are re
On Thu, 18 Mar 2021 08:24:50 +0100, Alain Volmat wrote:
> stm32_spi_remove() accesses the driver's private data after calling
> spi_unregister_master() even though that function releases the last
> reference on the spi_master and thereby frees the private data.
>
> Fix by switching over to the new
stm32_spi_remove() accesses the driver's private data after calling
spi_unregister_master() even though that function releases the last
reference on the spi_master and thereby frees the private data.
Fix by switching over to the new devm_spi_alloc_master() helper which
keeps the private data acces
Hi Lukas,
On Tue, Mar 16, 2021 at 10:17:44PM +0100, Lukas Wunner wrote:
> On Fri, Mar 12, 2021 at 11:34:46AM +0100, Alain Volmat wrote:
> > --- a/drivers/spi/spi-stm32.c
> > +++ b/drivers/spi/spi-stm32.c
> > @@ -1960,6 +1960,7 @@ static int stm32_spi_remove(struct platform_device
> > *pdev)
> >
On Fri, Mar 12, 2021 at 11:34:46AM +0100, Alain Volmat wrote:
> --- a/drivers/spi/spi-stm32.c
> +++ b/drivers/spi/spi-stm32.c
> @@ -1960,6 +1960,7 @@ static int stm32_spi_remove(struct platform_device
> *pdev)
> struct spi_master *master = platform_get_drvdata(pdev);
> struct stm32_spi
On Fri, 12 Mar 2021 11:34:46 +0100, Alain Volmat wrote:
> A call to spi_unregister_master() triggers calling remove()
> for all the spi devices binded to the spi master.
>
> Some spi device driver requires to "talk" with the spi device
> during the remove(), e.g.:
> - a LCD panel like drivers/gpu/
On Fri, 12 Mar 2021 11:35:29 +0100, Alain Volmat wrote:
> Avoid CONFIG_PM preprocessor check for pm suspend/resume
> callbacks and identify the functions with __maybe_unused.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: stm32: avoid i
Avoid CONFIG_PM preprocessor check for pm suspend/resume
callbacks and identify the functions with __maybe_unused.
Signed-off-by: Alain Volmat
---
drivers/spi/spi-stm32.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-st
From: Antonio Borneo
A call to spi_unregister_master() triggers calling remove()
for all the spi devices binded to the spi master.
Some spi device driver requires to "talk" with the spi device
during the remove(), e.g.:
- a LCD panel like drivers/gpu/drm/panel/panel-lg-lg4573.c
will turn off t
On Wed, Mar 03, 2021 at 05:02:39PM +0800, Leilk Liu wrote:
> On Wed, 2021-03-03 at 08:18 +0100, Greg Kroah-Hartman wrote:
> > On Wed, Mar 03, 2021 at 10:56:36AM +0800, Leilk Liu wrote:
> > > From: "leilk.liu"
> > >
> > > It is wanted to use MTK spi bus driver with GPL-2.0 or MIT license.
> > > Bu
On Wed, 2021-03-03 at 08:18 +0100, Greg Kroah-Hartman wrote:
> On Wed, Mar 03, 2021 at 10:56:36AM +0800, Leilk Liu wrote:
> > From: "leilk.liu"
> >
> > It is wanted to use MTK spi bus driver with GPL-2.0 or MIT license.
> > But now it is only licensed as GPL-2.0, so re-license it as dual
> > MIT/
On Wed, Mar 03, 2021 at 10:56:36AM +0800, Leilk Liu wrote:
> From: "leilk.liu"
>
> It is wanted to use MTK spi bus driver with GPL-2.0 or MIT license.
> But now it is only licensed as GPL-2.0, so re-license it as dual
> MIT/GPL.
>
> Signed-off-by: leilk.liu
Please use your name here, not an em
Leilk Liu 於 2021年3月3日 週三 上午10:57寫道：
>
> From: "leilk.liu"
>
> It is wanted to use MTK spi bus driver with GPL-2.0 or MIT license.
> But now it is only licensed as GPL-2.0, so re-license it as dual
> MIT/GPL.
>
> Signed-off-by: leilk.liu
Acked-by: Axel Lin
Change usleep_range() to udelay(). Since delay request
for 1 to 2 usec so we have to use udelay() instead of
usleep_range() as per kernel documentation.
Signed-off-by: Md Sadre Alam
---
drivers/spi/spi-qup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-
On Mon, 15 Feb 2021 19:04:25 +0800, angkery wrote:
> Fix OF node leaks by calling of_node_put in
> for_each_available_child_of_node when the cycle returns.
>
> Generated by: scripts/coccinelle/iterators/for_each_child.cocci
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sp
On Thu, 25 Feb 2021 13:55:34 +0100, Arnd Bergmann wrote:
> Building this file with clang leads to a an unreachable code path
> causing a warning from objtool:
>
> drivers/spi/spi-rockchip.o: warning: objtool:
> rockchip_spi_transfer_one()+0x2e0: sibling call from callable instruction
> with modi
On Thu, 18 Feb 2021 15:28:40 +0200, Tudor Ambarus wrote:
> The DMA cap mask is no longer used since:
> commit 7758e390699f ("spi: atmel: remove compat for non DT board when
> requesting dma chan")
> Drop it now.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-ne
On Mon, 22 Feb 2021 03:32:43 +0100, Alexander Sverdlin wrote:
> Set the (optional) idle pinctrl state during runtime suspend. This is the
> same schema used in PL022 driver and can help with HW designs sharing
> the SPI lines for different purposes.
Applied to
https://git.kernel.org/pub/scm/li
On Fri, Feb 26, 2021 at 12:05 PM 'Pratyush Yadav' via Clang Built
Linux wrote:
> On 26/02/21 10:49AM, Arnd Bergmann wrote:
> > On Fri, Feb 26, 2021 at 9:16 AM 'Pratyush Yadav' via Clang Built Linux
> > wrote:
>
> Returning an error code from this function (along with the dev_warn() or
> WARN_ON
On 26/02/21 10:49AM, Arnd Bergmann wrote:
> On Fri, Feb 26, 2021 at 9:16 AM 'Pratyush Yadav' via Clang Built Linux
> wrote:
> >
> > Hi,
> >
> > On 25/02/21 01:55PM, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > Building this file with clang leads to a an unreachable code path
> > > c
On Fri, Feb 26, 2021 at 9:16 AM 'Pratyush Yadav' via Clang Built Linux
wrote:
>
> Hi,
>
> On 25/02/21 01:55PM, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > Building this file with clang leads to a an unreachable code path
> > causing a warning from objtool:
> >
> > drivers/spi/spi-rockchi
Hi,
On 25/02/21 01:55PM, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Building this file with clang leads to a an unreachable code path
> causing a warning from objtool:
>
> drivers/spi/spi-rockchip.o: warning: objtool:
> rockchip_spi_transfer_one()+0x2e0: sibling call from callable instruct
Am Donnerstag, 25. Februar 2021, 13:55:34 CET schrieb Arnd Bergmann:
> From: Arnd Bergmann
>
> Building this file with clang leads to a an unreachable code path
> causing a warning from objtool:
>
> drivers/spi/spi-rockchip.o: warning: objtool:
> rockchip_spi_transfer_one()+0x2e0: sibling call
On Thu, Feb 25, 2021 at 4:55 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> Building this file with clang leads to a an unreachable code path
> causing a warning from objtool:
>
> drivers/spi/spi-rockchip.o: warning: objtool:
> rockchip_spi_transfer_one()+0x2e0: sibling call from callable i
On Thu, 25 Feb 2021 at 13:55, Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> Building this file with clang leads to a an unreachable code path
> causing a warning from objtool:
>
> drivers/spi/spi-rockchip.o: warning: objtool:
> rockchip_spi_transfer_one()+0x2e0: sibling call from callable ins
From: Arnd Bergmann
Building this file with clang leads to a an unreachable code path
causing a warning from objtool:
drivers/spi/spi-rockchip.o: warning: objtool:
rockchip_spi_transfer_one()+0x2e0: sibling call from callable instruction with
modified stack frame
Use BUG() instead of unreacha
Set the (optional) idle pinctrl state during runtime suspend. This is the
same schema used in PL022 driver and can help with HW designs sharing
the SPI lines for different purposes.
Signed-off-by: Alexander Sverdlin
---
drivers/spi/spi-omap2-mcspi.c | 24 ++--
1 file changed,
The DMA cap mask is no longer used since:
commit 7758e390699f ("spi: atmel: remove compat for non DT board when
requesting dma chan")
Drop it now.
Signed-off-by: Tudor Ambarus
---
drivers/spi/spi-atmel.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/sp
Release the RX channel and free the dma coherent memory when
devm_spi_register_master() fails
Signed-off-by: Tudor Ambarus
---
drivers/spi/spi-ti-qspi.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
From: Junlin Yang
Fix OF node leaks by calling of_node_put in
for_each_available_child_of_node when the cycle returns.
Generated by: scripts/coccinelle/iterators/for_each_child.cocci
Signed-off-by: Junlin Yang
---
drivers/spi/spi-cadence-quadspi.c | 6 +-
1 file changed, 5 insertions(+),
On Mon, Feb 15, 2021 at 3:52 PM Jan Kiszka wrote:
> On 15.02.21 14:22, Andy Shevchenko wrote:
> > On Sun, Feb 14, 2021 at 10:57:46PM +0800, Dejin Zheng wrote:
> >> Call to 'pci_free_irq_vectors()' are missing both in the error handling
> >> path of the probe function, and in the remove function. S
On Mon, Feb 15, 2021 at 03:22:38PM +0200, Andy Shevchenko wrote:
> On Sun, Feb 14, 2021 at 10:57:46PM +0800, Dejin Zheng wrote:
> > Call to 'pci_free_irq_vectors()' are missing both in the error handling
> > path of the probe function, and in the remove function. So add them.
>
> I'm wondering if
On 15.02.21 14:22, Andy Shevchenko wrote:
> On Sun, Feb 14, 2021 at 10:57:46PM +0800, Dejin Zheng wrote:
>> Call to 'pci_free_irq_vectors()' are missing both in the error handling
>> path of the probe function, and in the remove function. So add them.
>
> I'm wondering if you noticed that it's don
On Sun, Feb 14, 2021 at 10:57:46PM +0800, Dejin Zheng wrote:
> Call to 'pci_free_irq_vectors()' are missing both in the error handling
> path of the probe function, and in the remove function. So add them.
I'm wondering if you noticed that it's done by pcim_* API.
Perhaps you can introduce pcim_al
On Mon, Feb 15, 2021 at 11:41:50AM +0200, Jarkko Nikula wrote:
> On 2/15/21 11:23 AM, Jan Kiszka wrote:
> > On 14.02.21 15:57, Dejin Zheng wrote:
> > > Call to 'pci_free_irq_vectors()' are missing both in the error handling
> > > path of the probe function, and in the remove function. So add them.
On 2/15/21 11:23 AM, Jan Kiszka wrote:
On 14.02.21 15:57, Dejin Zheng wrote:
Call to 'pci_free_irq_vectors()' are missing both in the error handling
path of the probe function, and in the remove function. So add them.
Fixes: 64e02cb0bdfc7c ("spi: pca2xx-pci: Allow MSI")
Signed-off-by: Dejin Zhe
On 14.02.21 15:57, Dejin Zheng wrote:
> Call to 'pci_free_irq_vectors()' are missing both in the error handling
> path of the probe function, and in the remove function. So add them.
>
> Fixes: 64e02cb0bdfc7c ("spi: pca2xx-pci: Allow MSI")
> Signed-off-by: Dejin Zheng
> ---
> drivers/spi/spi-pxa
Call to 'pci_free_irq_vectors()' are missing both in the error handling
path of the probe function, and in the remove function. So add them.
Fixes: 64e02cb0bdfc7c ("spi: pca2xx-pci: Allow MSI")
Signed-off-by: Dejin Zheng
---
drivers/spi/spi-pxa2xx-pci.c | 13 ++---
1 file changed, 10 ins
On Thu, 11 Feb 2021 12:37:14 -0800, Kees Cook wrote:
> Since "data" is u32, &data is a "u32 *" type, which means pointer math
> will move in u32-sized steps. This was meant to be a byte offset, so
> cast &data to "char *" to aim the copy into the correct location.
>
> Seen with -Warray-bounds (and
On Thu, 11 Feb 2021 19:08:20 +0100, Nicolas Saenz Julienne wrote:
> With the introduction of 26751de25d25 ("spi: bcm2835: Micro-optimise
> FIFO loops") it has become apparent that some users might initiate
> zero-length SPI transfers. A fact the micro-optimization omitted, and
> which turned out to
On Fri, Feb 12, 2021 at 01:57:24PM +0100, Geert Uytterhoeven wrote:
> On Fri, Feb 12, 2021 at 1:55 PM Mark Brown wrote:
> > No, I think it's fine - there's probably some sensible use case with
> > drivers reusing a statically allocated transfer/buffer set for multiple
> > operations and just twea
Hi Mark,
On Fri, Feb 12, 2021 at 1:55 PM Mark Brown wrote:
> On Fri, Feb 12, 2021 at 01:48:21PM +0100, Nicolas Saenz Julienne wrote:
> > On Fri, 2021-02-12 at 12:31 +, Mark Brown wrote:
> > > On Thu, Feb 11, 2021 at 07:08:20PM +0100, Nicolas Saenz Julienne wrote:
>
> > > > - if (xfer-
On Fri, Feb 12, 2021 at 01:48:21PM +0100, Nicolas Saenz Julienne wrote:
> On Fri, 2021-02-12 at 12:31 +, Mark Brown wrote:
> > On Thu, Feb 11, 2021 at 07:08:20PM +0100, Nicolas Saenz Julienne wrote:
> > > - if (xfer->tx_buf || xfer->rx_buf) {
> > > + if ((xfer->tx_buf || xfer->
On Fri, 2021-02-12 at 12:31 +, Mark Brown wrote:
> On Thu, Feb 11, 2021 at 07:08:20PM +0100, Nicolas Saenz Julienne wrote:
>
> > - if (xfer->tx_buf || xfer->rx_buf) {
> > + if ((xfer->tx_buf || xfer->rx_buf) && xfer->len) {
>
> I think the issue here is more that some user
On Thu, Feb 11, 2021 at 07:08:20PM +0100, Nicolas Saenz Julienne wrote:
> - if (xfer->tx_buf || xfer->rx_buf) {
> + if ((xfer->tx_buf || xfer->rx_buf) && xfer->len) {
I think the issue here is more that some users were passing in buffers
with zero length transfers, the abo
On Thu, Feb 11, 2021 at 12:37:14PM -0800, Kees Cook wrote:
> Since "data" is u32, &data is a "u32 *" type, which means pointer math
> will move in u32-sized steps. This was meant to be a byte offset, so
> cast &data to "char *" to aim the copy into the correct location.
>
> Seen with -Warray-bound
Since "data" is u32, &data is a "u32 *" type, which means pointer math
will move in u32-sized steps. This was meant to be a byte offset, so
cast &data to "char *" to aim the copy into the correct location.
Seen with -Warray-bounds (and found by Coverity):
In file included from ./include/linux/str
With the introduction of 26751de25d25 ("spi: bcm2835: Micro-optimise
FIFO loops") it has become apparent that some users might initiate
zero-length SPI transfers. A fact the micro-optimization omitted, and
which turned out to cause crashes[1].
Instead of changing the micro-optimization itself, use
On Wed, 10 Feb 2021 15:54:28 +0200, Tudor Ambarus wrote:
> It is safer to disable the QSPI IP at suspend, in order to avoid
> possible impact of glitches on the internal FSMs. This is a theoretical
> fix, there were no problems seen as of now. Tested on sama5d2 and
> sam9x60 versions of the IP.
Ap
It is safer to disable the QSPI IP at suspend, in order to avoid
possible impact of glitches on the internal FSMs. This is a theoretical
fix, there were no problems seen as of now. Tested on sama5d2 and
sam9x60 versions of the IP.
Signed-off-by: Tudor Ambarus
---
drivers/spi/atmel-quadspi.c | 1
Hi Fabio,
Fabio Estevam wrote on Wed, 3 Feb 2021 14:10:15
-0300:
> Hi Miquel,
>
> On Wed, Feb 3, 2021 at 2:06 PM Miquel Raynal
> wrote:
> >
> > Commit 9326e4f1e5dd ("spi: Limit the spi device max speed to controller's
> > max speed")
> > rationaly introduced a new condition on which the devi
Hi Miquel,
On Wed, Feb 3, 2021 at 2:06 PM Miquel Raynal wrote:
>
> Commit 9326e4f1e5dd ("spi: Limit the spi device max speed to controller's max
> speed")
> rationaly introduced a new condition on which the device's maximum
> speed would be set to the controller's one: if the device advertizes a
Commit 9326e4f1e5dd ("spi: Limit the spi device max speed to controller's max
speed")
rationaly introduced a new condition on which the device's maximum
speed would be set to the controller's one: if the device advertizes a
higher speed than the one supported by the controller.
However, it seems
On Sat, 30 Jan 2021 15:35:45 +0100, Rasmus Villemoes wrote:
> Commit 7a2da5d7960a ("spi: fsl: Fix driver breakage when SPI_CS_HIGH
> is not set in spi->mode") broke our MPC8309 board by effectively
> inverting the boolean value passed to fsl_spi_cs_control. The
> SPISEL_BOOT signal is used as chips
Commit 7a2da5d7960a ("spi: fsl: Fix driver breakage when SPI_CS_HIGH
is not set in spi->mode") broke our MPC8309 board by effectively
inverting the boolean value passed to fsl_spi_cs_control. The
SPISEL_BOOT signal is used as chipselect, but it's not a gpio, so
we cannot rely on gpiolib handling th
On Sat, Jan 23, 2021 at 04:03:44AM +0100, corentin noel wrote:
> Signed-off-by: corentin noel
This doesn't apply against current code, please check and resend. It
should apply against my tree which already has your previous patches
including the one which
> if (!ddma_memid)
> -
Hi, Andreas,
On 12/21/20 12:43 AM, Andreas Rammhold wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> This adds support for the xt25f128b as found on the rockpi4b SBC.
>
> Signed-off-by: Andreas Rammhold
> ---
>
> This continues the effo
1 - 100 of 1159 matches
Mail list logo
