| Message ID | 1393428679-18462-1-git-send-email-alexander.stein@systec-electronic.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 7995d74ab297e4f5526c8df70007e1e39f0d1f5c |
| Headers | show |
On Wed, Feb 26, 2014 at 04:31:19PM +0100, Alexander Stein wrote: > If during registering SPI master due to SPI device probing a SPI transfer > is issued the DMA buffers are not allocated yet. Applied, thanks.
On Thursday 27 February 2014 13:37:19, Mark Brown wrote: > On Wed, Feb 26, 2014 at 04:31:19PM +0100, Alexander Stein wrote: > > If during registering SPI master due to SPI device probing a SPI transfer > > is issued the DMA buffers are not allocated yet. > > Applied, thanks. Thinking about this patch over night, this also should go to stable, no? Best regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Feb 27, 2014 at 09:13:21AM +0100, Alexander Stein wrote: > On Thursday 27 February 2014 13:37:19, Mark Brown wrote: > > On Wed, Feb 26, 2014 at 04:31:19PM +0100, Alexander Stein wrote: > > > If during registering SPI master due to SPI device probing a SPI transfer > > > is issued the DMA buffers are not allocated yet. > > Applied, thanks. > Thinking about this patch over night, this also should go to stable, no? Possibly, though I'd have thought that someone would have noticed by now if there were any affected systems using stable?
On Friday 28 February 2014 12:43:31, Mark Brown wrote: > On Thu, Feb 27, 2014 at 09:13:21AM +0100, Alexander Stein wrote: > > On Thursday 27 February 2014 13:37:19, Mark Brown wrote: > > > On Wed, Feb 26, 2014 at 04:31:19PM +0100, Alexander Stein wrote: > > > > If during registering SPI master due to SPI device probing a SPI transfer > > > > is issued the DMA buffers are not allocated yet. > > > > Applied, thanks. > > > Thinking about this patch over night, this also should go to stable, no? > > Possibly, though I'd have thought that someone would have noticed by now > if there were any affected systems using stable? Well, i think this is a rather rarely use case. You need either all drivers compiled in where the SPI device driver is loaded before SPI master or you need SPI master als module while the SPI device driver is already compiled in. Oh, and the SPI device driver must do a SPI transfer during probe. So the conditions are reptty strict when this problem might happen. Alexander PS: On EG20T (PCH) it seems this will never happen as the DMA channels are allocated wrongly (see other patch from me) andso DMA will never be used. -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Mar 03, 2014 at 08:21:16AM +0100, Alexander Stein wrote: Fix your mailer to word wrap within paragraphs so that your mail is legible. > Well, i think this is a rather rarely use case. You need either all > drivers compiled in where the SPI device driver is loaded before SPI > master or you need SPI master als module while the SPI device driver > is already compiled in. Oh, and the SPI device driver must do a SPI > transfer during probe. So the conditions are reptty strict when this > problem might happen. > PS: On EG20T (PCH) it seems this will never happen as the DMA channels > are allocated wrongly (see other patch from me) andso DMA will never > be used. OK, so this doesn't sound terribly urgent then? It's hard to see and other bugs mean it wouldn't be triggered anyway?
On Tuesday 04 March 2014 12:44:22, Mark Brown wrote: > On Mon, Mar 03, 2014 at 08:21:16AM +0100, Alexander Stein wrote: > > Well, i think this is a rather rarely use case. You need either all > > drivers compiled in where the SPI device driver is loaded before SPI > > master or you need SPI master als module while the SPI device driver > > is already compiled in. Oh, and the SPI device driver must do a SPI > > transfer during probe. So the conditions are reptty strict when this > > problem might happen. > > > PS: On EG20T (PCH) it seems this will never happen as the DMA channels > > are allocated wrongly (see other patch from me) andso DMA will never > > be used. > > OK, so this doesn't sound terribly urgent then? It's hard to see and > other bugs mean it wouldn't be triggered anyway? Yes, at least for EG20T. I have no idea about those MLxxxx IOH. Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/spi/spi-topcliff-pch.c b/drivers/spi/spi-topcliff-pch.c index c2a3435..f73fb77 100644 --- a/drivers/spi/spi-topcliff-pch.c +++ b/drivers/spi/spi-topcliff-pch.c @@ -1457,6 +1457,11 @@ static int pch_spi_pd_probe(struct platform_device *plat_dev) pch_spi_set_master_mode(master); + if (use_dma) { + dev_info(&plat_dev->dev, "Use DMA for data transfers\n"); + pch_alloc_dma_buf(board_dat, data); + } + ret = spi_register_master(master); if (ret != 0) { dev_err(&plat_dev->dev, @@ -1464,14 +1469,10 @@ static int pch_spi_pd_probe(struct platform_device *plat_dev) goto err_spi_register_master; } - if (use_dma) { - dev_info(&plat_dev->dev, "Use DMA for data transfers\n"); - pch_alloc_dma_buf(board_dat, data); - } - return 0; err_spi_register_master: + pch_free_dma_buf(board_dat, data); free_irq(board_dat->pdev->irq, data); err_request_irq: pch_spi_free_resources(board_dat, data);
If during registering SPI master due to SPI device probing a SPI transfer is issued the DMA buffers are not allocated yet. This fixes the following oops: pch_spi 0000:02:0c.1: enabling device (0000 -> 0002) pch_spi 0000:02:0c.1: master is unqueued, this is deprecated BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<c125aa05>] pch_spi_handle_dma+0x15c/0x6f4 [...] Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com> --- drivers/spi/spi-topcliff-pch.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)