Hi,
This is the latest iteration of the synchronous background command handling
work. Currently there are no users, but it is expected that firmware update
and scan media be the first two to use it.
Patches 1-3 are requirements for the actual patch 4.
Changes from v1/v2 (https://lore.kernel.org/linux-cxl/[email protected]):
o Picked up tags for patches 1 and 2.
o Added more context to the changelog in the rcuwait patch 1. (Dan)
o Added new patch 3 for common request irq functionality. (Dan)
o Misc cleanups in patch 4. (Jonathan)
o Don't clobber the ctrl settings. (Dan)
o Removed bogus warning in irq handler. (Jonathan, Dan)
o Make sleep uninterruptible and clarify in the changelog that
timeouts are in fact unexpected.
Applies against 'fixes' from cxl.git.
Thanks!
Davidlohr Bueso (4):
rcuwait: Support timeouts
cxl/pci: Allocate irq vectors earlier during probe
cxl/pci: Introduce cxl_request_irq()
cxl/mbox: Add background cmd handling machinery
drivers/cxl/core/mbox.c | 3 +-
drivers/cxl/cxl.h | 8 +++
drivers/cxl/cxlmem.h | 7 +++
drivers/cxl/pci.c | 136 ++++++++++++++++++++++++++++++++++------
include/linux/rcuwait.h | 23 ++++++-
5 files changed, 153 insertions(+), 24 deletions(-)
--
2.40.1
Davidlohr Bueso wrote:
> Hi,
>
> This is the latest iteration of the synchronous background command handling
> work. Currently there are no users, but it is expected that firmware update
> and scan media be the first two to use it.
>
> Patches 1-3 are requirements for the actual patch 4.
>
> Changes from v1/v2 (https://lore.kernel.org/linux-cxl/[email protected]):
> o Picked up tags for patches 1 and 2.
> o Added more context to the changelog in the rcuwait patch 1. (Dan)
> o Added new patch 3 for common request irq functionality. (Dan)
> o Misc cleanups in patch 4. (Jonathan)
> o Don't clobber the ctrl settings. (Dan)
> o Removed bogus warning in irq handler. (Jonathan, Dan)
> o Make sleep uninterruptible and clarify in the changelog that
> timeouts are in fact unexpected.
>
> Applies against 'fixes' from cxl.git.
Like Linus I want to see the conflicts. Whenever possible base on latest
Linus tag like v6.4-rc3. In this case I will add this to a
for-6.5/cxl-background topic branch based on 'fixes' for now, but once
'fixes' hits v6.4-rc4 I will move the topic baseline just to have it not
be based on a random point in the history.
This also encourages me to be more proactive about getting fixes
upstream so that the next Linus tag can be used for development.
On Tue, 23 May 2023, Dan Williams wrote:
>Like Linus I want to see the conflicts. Whenever possible base on latest
>Linus tag like v6.4-rc3.
So I'm clear, do you want me to resend this series based on -rc3?
Frankly I'm always confused as to what is the correct/preferred branch to
do development on.
>In this case I will add this to a
>for-6.5/cxl-background topic branch based on 'fixes' for now, but once
>'fixes' hits v6.4-rc4 I will move the topic baseline just to have it not
>be based on a random point in the history.
Ok, thanks for picking this up.
Davidlohr Bueso wrote:
> On Tue, 23 May 2023, Dan Williams wrote:
>
> >Like Linus I want to see the conflicts. Whenever possible base on latest
> >Linus tag like v6.4-rc3.
>
> So I'm clear, do you want me to resend this series based on -rc3?
No, not this time but for next time my preference is "when in doubt, pick
a mainline tag".
> Frankly I'm always confused as to what is the correct/preferred branch to
> do development on.
My plan is to do better about publishing topic branches for
work-in-progress items like this. So now we have for-6.5/cxl-background
for this common baseline for sanitization and firmware update. At least
one of those will need to be queued before this topic moves forward
since the new infrastructure needs a user.
The problem with picking 'next' or to a lesser extent 'fixes' as a
development baseline is that it ties unrelated topics together. If
something happens and we decided a topic neeeds to drop out of 'next' or
be rebased, that's much easier to do if random topics have not grown
implicit silent depenendencies over time.
Like in this case these patches do not apply to v6.4-rc3 because they
collide with the movement of cxl_await_media_ready() to cxl_pci.
However, nothing about that media-ready fix is needed for background
command support so the patches can just depend on a mainline tag.