| Message ID | 20250515083132.255410-1-csokas.bence@prolan.hu |
|---|---|
| Headers | show |
| Series | Add `devm_dma_request_chan()` to simplify probe path in atmel-quadspi.c | expand |
On Thu, May 15, 2025 at 10:31:28AM +0200, Bence Csókás wrote: > Change in v4: > * split PM imbalance fix (now merged) and DMA cleanup (this series) > Change in v6: > * rebase to spi/for-next, see note below: > > There is currently no difference in drivers/dma/dmaengine.c between it and > dma/next [1], therefore PATCH 1/2 should be safe for Vinod to apply. But > this way PATCH 2/2 is trivial to apply. I didn't want to pull the whole > linux-next tree, but if any ofyou run into problems, let me know, and I'll > rebase the series on it instead. I can't tell what the plan is here, or what the status is for the first patch (since I'm not CCed). The second patch depends on a new API introduced in the first patch so it can't be merged independently.
Hi, On 2025. 05. 15. 10:45, Mark Brown wrote: > On Thu, May 15, 2025 at 10:31:28AM +0200, Bence Csókás wrote: > >> Change in v4: >> * split PM imbalance fix (now merged) and DMA cleanup (this series) >> Change in v6: >> * rebase to spi/for-next, see note below: >> >> There is currently no difference in drivers/dma/dmaengine.c between it and >> dma/next [1], therefore PATCH 1/2 should be safe for Vinod to apply. But >> this way PATCH 2/2 is trivial to apply. I didn't want to pull the whole >> linux-next tree, but if any ofyou run into problems, let me know, and I'll >> rebase the series on it instead. > > I can't tell what the plan is here, or what the status is for the first > patch (since I'm not CCed). The second patch depends on a new API > introduced in the first patch so it can't be merged independently. Yes, the situation is a bit convoluted. Obviously 2/2 will be applied after 1/2, in a similar vein than the former PM series. So what I was trying to say: Vinod should be able to apply 1/2 to his branch (dma/next) right now, which can then be merged to spi/for-next. This merged branch should be able to then cleanly apply 2/2. Bence
On Thu, May 15, 2025 at 11:14:22AM +0200, Csókás Bence wrote: > On 2025. 05. 15. 10:45, Mark Brown wrote: > > I can't tell what the plan is here, or what the status is for the first > > patch (since I'm not CCed). The second patch depends on a new API > > introduced in the first patch so it can't be merged independently. > Yes, the situation is a bit convoluted. Obviously 2/2 will be applied after > 1/2, in a similar vein than the former PM series. > So what I was trying to say: Vinod should be able to apply 1/2 to his branch > (dma/next) right now, which can then be merged to spi/for-next. This merged > branch should be able to then cleanly apply 2/2. I wouldn't expect to pull the whole DMA tree in, that'll have a huge amount of extra stuff in it - if I was going to pull something I'd expect a topic branch. Wouldn't it be simpler for me to just apply both patches at this point if there's no conflicts with the DMA tree? We're at -rc6 now...
On Thu, May 15, 2025 at 11:26:57AM +0200, Csókás Bence wrote: > On 2025. 05. 15. 11:22, Mark Brown wrote: > > Wouldn't it be simpler for me to just apply both > > patches at this point if there's no conflicts with the DMA tree? We're > > at -rc6 now... > That also works for me. I should send 1/2 to you as well, correct? I think at this point with the merge window likely to open on Sunday it's probably easiest to just resend the SPI patch after the merge window, it'll likely take more time/effort to work out what to do than it will for the reset changes to land in Linus' tree.
The probe function of the atmel-quadspi driver got quite convoluted, especially since the addition of SAMA7G5 support, that was forward-ported from an older vendor kernel. To alleivate this - and similar problems in the future - an effort was made to migrate as many functions as possible, to their devm_ managed counterparts. Patch 1/2 adds the new `devm_dma_request_chan()` function. Patch 2/2 then uses this APIs to simplify the probe() function. Change in v4: * split PM imbalance fix (now merged) and DMA cleanup (this series) Change in v6: * rebase to spi/for-next, see note below: There is currently no difference in drivers/dma/dmaengine.c between it and dma/next [1], therefore PATCH 1/2 should be safe for Vinod to apply. But this way PATCH 2/2 is trivial to apply. I didn't want to pull the whole linux-next tree, but if any ofyou run into problems, let me know, and I'll rebase the series on it instead. [1] commit 3c018bf5a0ee ("dmaengine: idxd: Remove unused pointer and macro") Links to previous versions: pre-series: https://lore.kernel.org/linux-kernel/20241222141427.819222-1-csokas.bence@prolan.hu/ https://lore.kernel.org/linux-kernel/20250114222851.1023194-1-csokas.bence@prolan.hu/ v1: https://lore.kernel.org/linux-kernel/20250115160244.1102881-1-csokas.bence@prolan.hu/ v2: https://lore.kernel.org/linux-kernel/20250124085221.766303-8-csokas.bence@prolan.hu/ v3: https://lore.kernel.org/linux-kernel/20250207124802.165408-1-csokas.bence@prolan.hu/ v4: https://lore.kernel.org/lkml/20250317135340.382532-1-csokas.bence@prolan.hu/ v5: https://lore.kernel.org/lkml/20250505184936.312274-1-csokas.bence@prolan.hu Bence Csókás (2): dma: Add devm_dma_request_chan() spi: atmel-quadspi: Use `devm_dma_request_chan()` drivers/dma/dmaengine.c | 30 +++++++++++++++++++++++ drivers/spi/atmel-quadspi.c | 48 ++++++++++--------------------------- include/linux/dmaengine.h | 7 ++++++ 3 files changed, 50 insertions(+), 35 deletions(-) base-commit: 6155cbfffd294bb267f053ec596ced41bcdb0986