Re: [PATCH v2 2/2] cxl/cdat: Fix header sum value in CDAT checksum

[Dan Williams <dan.j.williams@intel.com>]

Jonathan Cameron wrote:
> On Mon, 18 Dec 2023 15:30:14 -0800
> Dan Williams <dan.j.williams@intel.com> wrote:
> 
> > Ira Weiny wrote:
> > > Jonathan Cameron wrote:  
> > > > On Wed, 29 Nov 2023 17:33:04 -0800
> > > > Ira Weiny <ira.weiny@intel.com> wrote:
> > > >   
> > > 
> > > [snip]
> > >   
> > > > > [1] https://lore.kernel.org/all/20231116-fix-cdat-devm-free-v1-1-b148b40707d7@intel.com/
> > > > > 
> > > > > Fixes: aba578bdace5 ("hw/cxl/cdat: CXL CDAT Data Object Exchange implementation")
> > > > > Cc: Huai-Cheng Kuo <hchkuo@avery-design.com.tw>
> > > > > Signed-off-by: Ira Weiny <ira.weiny@intel.com>  
> > > > 
> > > > This only becomes a problem with the addition of DCDs so I'm not going to rush it in.  
> > > 
> > > That makes sense.
> > >   
> > > > Btw cc qemu-devel on qemu patches!
> > > >   
> > > 
> > > Ah...  yea my bad.  
> > 
> > Might I also ask for a more prominent way to quickly identify kernel vs
> > qemu patches, like a "[QEMU PATCH]" prefix? I tend to look for "hw/" in
> > the diff path names, but the kernel vs qemu question is ambiguous when
> > looking at the linux-cxl Patchwork queue.
> I'm not sure if the QEMU maintainers would be that keen on a tag there.
> Maybe just stick qemu/cxl: in the cover letter naming as a prefix?
> [PATCH 0/4] qemu/cxl: Whatever the change is

+1 from me.

> > @Jonathan, what do you think of having the kernel patchwork-bot watch
> > your tree for updating patch state (if it is not happening already).
> My QEMU tree is a bit intermittent and frequently rebased as I'm juggling
> too many patches. Not sure we'd get a good match.  Mind you I've
> never tried the bot so not even sure how to configure it.

Here's the documentation:
https://korg.docs.kernel.org/patchwork/index.html

The basics are you just point the bot at kernel tree and whenever that
tree is updated it checks if any of the new commits match patchwork
patches by git-patch-id (or equivalent). Rebases are ok as it will just
"re-accept" the patch with new commit id. The main benefit it has is
transitioning patches to the Accepted state, or Mainline state depending
on what branch you tell it represents those states.

It does require a git.kernel.org tree to monitor, but we might already
get benefit from just pointing it to:

https://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git/

...to automatically mark patches as "Accepted". The "Superseded" state
comes for free with the existing patchwork-bot monitoring of the
linux-cxl@ list.