From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Ira Weiny <ira.weiny@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
Ben Widawsky <bwidawsk@kernel.org>,
qemu-devel@nongnu.org, linux-cxl@vger.kernel.org
Subject: Re: [PATCH v2] hw/cxl/device: Add Flex Bus Port DVSEC
Date: Fri, 16 Dec 2022 07:37:55 -0500 [thread overview]
Message-ID: <20221216072445-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20221216093136.000026c3@Huawei.com>
On Fri, Dec 16, 2022 at 09:31:36AM +0000, Jonathan Cameron wrote:
> On Thu, 15 Dec 2022 09:28:30 -0800
> Ira Weiny <ira.weiny@intel.com> wrote:
>
> > On Thu, Dec 15, 2022 at 05:16:33PM +0000, Jonathan Cameron wrote:
> > > On Wed, 14 Dec 2022 12:54:11 -0800
> > > Ira Weiny <ira.weiny@intel.com> wrote:
> > >
> > > > The Flex Bus Port DVSEC was missing on type 3 devices which was blocking
> > > > RAS checks.[1]
> > > >
> > > > Add the Flex Bus Port DVSEC to type 3 devices as per CXL 3.0 8.2.1.3.
> > > >
> > > > [1] https://lore.kernel.org/linux-cxl/167096738875.2861540.11815053323626849940.stgit@djiang5-desk3.ch.intel.com/
> > > >
> > > > Cc: Dave Jiang <dave.jiang@intel.com>
> > > > Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > > Cc: Ben Widawsky <bwidawsk@kernel.org>
> > > > Cc: qemu-devel@nongnu.org
> > > > Cc: linux-cxl@vger.kernel.org
> > > > Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> > > Looks good to me.
> > >
> > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > >
> > > As Michael wasn't cc'd on patch posting, so might not get this directly I'll add
> > > it to the front of the series adding the RAS event emulation on basis that's the
> > > first time we'll see a failure in Linux (I think?)
> >
> > Ah thanks!
> >
> > Sorry, I thought you were the 'maintainer' of the CXL stuff for qemu.
>
> Ah I am, but so far the CXL stuff has routed through Michael as PCI maintainer
> because of the high level of overlap. So far I've done that by grouping up
> patches and send them in sets to Michael. This one is more of a fix, so maybe
> wants to move quicker than I will.
>
> This gives me a good opportunity to ask Michael:
>
> How do you want us to handle this in future? I'd expect the overlap with the PCI
> core stuff to reduce going forwards, as most of the infrastructure is now in
> place and obviously would want you to look at anything that does touch core PCI
> code, but for the rest of it, would you prefer that I send pull requests going
> forwards? I'm more than happy to keep dumping this stuff on you, but seems
> rather mean!
>
> If we do move to pull requests, what scope of stuff do you want us to seek your
> review on? If things go according to plan there will be a bunch of stuff related
> to the switch ports in the near future, some of which is going to add complex
> PCI topologies and new forms of hotplug so I'll definitely want your input on
> that, but we also have a bunch of stuff around memory error reporting etc which
> I'm thinking may be of less interest to you. Obviously I'd love it if you have
> time to review everything but don't want to impose unnecessarily.
>
> Jonathan
It's not been too bad so far :) I'm not used to reviewing pull requests
- patches are easier if you want my review. If you are happy too then
all is well. Yes I assume if I'm CC'd directly people want my input
if not then not. And learning a bit about how error reporting works
is interesting to me.
But if you want to send some pulls directly that's fine too, at this point
I trust you to do the right thing.
>
> >
> > >
> > > Michael, if you want to pick this up directly that's great too!
> >
> > Should I send directly to Michael in future?
> >
> > >
> > > As a side note the WTF? is because we made up a hardware related time delay
> > > number having no idea whatsoever on what a realistic value was. Cut and paste
> > > from the instances of this structure in the root port and the switch ports.
> > >
> >
> > Yep I just followed that based off the other code.
> >
> > Ira
> >
> > > Jonathan
> > >
> > >
> > >
> > > > ---
> > > > Changes in v2:
> > > > Jonathan
> > > > type 3 device does not support CACHE
> > > > Comment the 68B bit
> > > >
> > > > - Link to v1: https://lore.kernel.org/r/20221213-ira-flexbus-port-v1-1-86afd4f30be6@intel.com
> > > > ---
> > > > hw/mem/cxl_type3.c | 11 +++++++++++
> > > > 1 file changed, 11 insertions(+)
> > > >
> > > > diff --git a/hw/mem/cxl_type3.c b/hw/mem/cxl_type3.c
> > > > index 0317bd96a6fb..e6beac143fc1 100644
> > > > --- a/hw/mem/cxl_type3.c
> > > > +++ b/hw/mem/cxl_type3.c
> > > > @@ -416,6 +416,17 @@ static void build_dvsecs(CXLType3Dev *ct3d)
> > > > cxl_component_create_dvsec(cxl_cstate, CXL2_TYPE3_DEVICE,
> > > > GPF_DEVICE_DVSEC_LENGTH, GPF_DEVICE_DVSEC,
> > > > GPF_DEVICE_DVSEC_REVID, dvsec);
> > > > +
> > > > + dvsec = (uint8_t *)&(CXLDVSECPortFlexBus){
> > > > + .cap = 0x26, /* 68B, IO, Mem, non-MLD */
> > > > + .ctrl = 0x02, /* IO always enabled */
> > > > + .status = 0x26, /* same as capabilities */
> > > > + .rcvd_mod_ts_data_phase1 = 0xef, /* WTF? */
> > > > + };
> > > > + cxl_component_create_dvsec(cxl_cstate, CXL2_TYPE3_DEVICE,
> > > > + PCIE_FLEXBUS_PORT_DVSEC_LENGTH_2_0,
> > > > + PCIE_FLEXBUS_PORT_DVSEC,
> > > > + PCIE_FLEXBUS_PORT_DVSEC_REVID_2_0, dvsec);
> > > > }
> > > >
> > > > static void hdm_decoder_commit(CXLType3Dev *ct3d, int which)
> > > >
> > > > ---
> > > > base-commit: e11b57108b0cb746bb9f3887054f34a2f818ed79
> > > > change-id: 20221213-ira-flexbus-port-ce526de8111d
> > > >
> > > > Best regards,
> > >
prev parent reply other threads:[~2022-12-16 12:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-14 20:54 [PATCH v2] hw/cxl/device: Add Flex Bus Port DVSEC Ira Weiny
2022-12-15 17:16 ` Jonathan Cameron
2022-12-15 17:16 ` Jonathan Cameron via
2022-12-15 17:28 ` Ira Weiny
2022-12-16 9:31 ` Jonathan Cameron
2022-12-16 9:31 ` Jonathan Cameron via
2022-12-16 12:37 ` Michael S. Tsirkin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221216072445-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=bwidawsk@kernel.org \
--cc=dave.jiang@intel.com \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.