From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Arpit Kumar <arpit1.kumar@samsung.com>
Cc: <qemu-devel@nongnu.org>, <gost.dev@samsung.com>,
<linux-cxl@vger.kernel.org>, <nifan.cxl@gmail.com>,
<dave@stgolabs.net>, <vishak.g@samsung.com>,
<krish.reddy@samsung.com>, <a.manzanares@samsung.com>,
<alok.rathore@samsung.com>
Subject: Re: [PATCH 1/3] hw/cxl: Storing physical ports info during enumeration
Date: Wed, 18 Jun 2025 12:31:14 +0100 [thread overview]
Message-ID: <20250618123114.00002b98@huawei.com> (raw)
In-Reply-To: <20250617094625.i2j7ewin7fy2b2nj@test-PowerEdge-R740xd>
> >> +#define LINK_STATE_FLAG_PERST_ASSERTED (1 << 1)
> >> +#define LINK_STATE_FLAG_PRSNT (1 << 2)
> >> +#define LINK_STATE_FLAG_POWER_OFF (1 << 3)
> >> +
> >> +/* physical port control info - CXL r3.2 table 7-19 */
> >> +typedef enum {
> >> + PORT_DISABLED = 0,
> >> + BIND_IN_PROGRESS = 1,
> >> + UNBIND_IN_PROGRESS = 2,
> >> + DSP = 3,
> >> + USP = 4,
> >> + FABRIC_PORT = 5,
> >> + INVALID_PORT_ID = 15
> >> +} current_port_config_state;
> >
> >These aren't used as types really but more as defines.
> >Hence I'd be tempted to make them defines. Also provide
> >defines for the masks.
> >
> >Namespace the defines so it is obvious which field
> >they are in.
> >
> Will the below changes be the right way to proceed?
> #define CXL_PORT_CONFIG_STATE_DISABLED 0x0
> #define CXL_PORT_CONFIG_STATE_BIND_IN_PROGRESS 0x1 etc.
Yes
...
> >For similar things we do have firmware update in there which
> >is a mixture of device side stuff and CCI specific handling.
> >That might ideally be split up. Obviously not something for
> >this patch, but maybe we can avoid making CCI more bloated?
> >
> >To me it seems reasonable to store this in the port and set
> >it up whether or not the cci is connected.
> >
> got it, will try the implementation accordingly. It will be helpful if could share some
> reference on handling the same.
+ /*physical ports information */
+ struct phy_port pports;
+
Move this stuff to the CXLUpstreamPort.
Query the data to fill it in will need to be late enough that
everything is there to query. cxl_usp_reset() might work similar to how
we fill in link registers etc there.
Then when you handle any of the CCI calls, use CXL_USP(cci->d) to
get to that USP structure. Check that you have the right type if necessary
first though.
Jonathan
> >> +
> >> /* background command handling (times in ms) */
> >> struct {
> >> uint16_t opcode;
> >
>
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: Arpit Kumar <arpit1.kumar@samsung.com>
Cc: <qemu-devel@nongnu.org>, <gost.dev@samsung.com>,
<linux-cxl@vger.kernel.org>, <nifan.cxl@gmail.com>,
<dave@stgolabs.net>, <vishak.g@samsung.com>,
<krish.reddy@samsung.com>, <a.manzanares@samsung.com>,
<alok.rathore@samsung.com>
Subject: Re: [PATCH 1/3] hw/cxl: Storing physical ports info during enumeration
Date: Wed, 18 Jun 2025 12:31:14 +0100 [thread overview]
Message-ID: <20250618123114.00002b98@huawei.com> (raw)
In-Reply-To: <20250617094625.i2j7ewin7fy2b2nj@test-PowerEdge-R740xd>
> >> +#define LINK_STATE_FLAG_PERST_ASSERTED (1 << 1)
> >> +#define LINK_STATE_FLAG_PRSNT (1 << 2)
> >> +#define LINK_STATE_FLAG_POWER_OFF (1 << 3)
> >> +
> >> +/* physical port control info - CXL r3.2 table 7-19 */
> >> +typedef enum {
> >> + PORT_DISABLED = 0,
> >> + BIND_IN_PROGRESS = 1,
> >> + UNBIND_IN_PROGRESS = 2,
> >> + DSP = 3,
> >> + USP = 4,
> >> + FABRIC_PORT = 5,
> >> + INVALID_PORT_ID = 15
> >> +} current_port_config_state;
> >
> >These aren't used as types really but more as defines.
> >Hence I'd be tempted to make them defines. Also provide
> >defines for the masks.
> >
> >Namespace the defines so it is obvious which field
> >they are in.
> >
> Will the below changes be the right way to proceed?
> #define CXL_PORT_CONFIG_STATE_DISABLED 0x0
> #define CXL_PORT_CONFIG_STATE_BIND_IN_PROGRESS 0x1 etc.
Yes
...
> >For similar things we do have firmware update in there which
> >is a mixture of device side stuff and CCI specific handling.
> >That might ideally be split up. Obviously not something for
> >this patch, but maybe we can avoid making CCI more bloated?
> >
> >To me it seems reasonable to store this in the port and set
> >it up whether or not the cci is connected.
> >
> got it, will try the implementation accordingly. It will be helpful if could share some
> reference on handling the same.
+ /*physical ports information */
+ struct phy_port pports;
+
Move this stuff to the CXLUpstreamPort.
Query the data to fill it in will need to be late enough that
everything is there to query. cxl_usp_reset() might work similar to how
we fill in link registers etc there.
Then when you handle any of the CCI calls, use CXL_USP(cci->d) to
get to that USP structure. Check that you have the right type if necessary
first though.
Jonathan
> >> +
> >> /* background command handling (times in ms) */
> >> struct {
> >> uint16_t opcode;
> >
>
next prev parent reply other threads:[~2025-06-18 11:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20250602140008epcas5p25fce01492de105da3cdc0aaa533f6ebc@epcas5p2.samsung.com>
2025-06-02 13:59 ` [PATCH 0/3] FM-API Physical switch command set update Arpit Kumar
2025-06-02 13:59 ` [PATCH 1/3] hw/cxl: Storing physical ports info during enumeration Arpit Kumar
2025-06-10 14:21 ` Jonathan Cameron
2025-06-10 14:21 ` Jonathan Cameron via
2025-06-17 9:46 ` Arpit Kumar
2025-06-18 11:31 ` Jonathan Cameron [this message]
2025-06-18 11:31 ` Jonathan Cameron via
2025-06-02 13:59 ` [PATCH 2/3] hw/cxl: Simplified Identify Switch Device & Get Physical Port State Arpit Kumar
2025-06-10 14:29 ` Jonathan Cameron
2025-06-10 14:29 ` Jonathan Cameron via
2025-06-17 10:01 ` Arpit Kumar
2025-06-02 13:59 ` [PATCH 3/3] hw/cxl: Add Physical Port Control (Opcode 5102h) Arpit Kumar
2025-06-10 14:45 ` Jonathan Cameron
2025-06-10 14:45 ` Jonathan Cameron via
2025-06-17 10:11 ` Arpit Kumar
2025-06-18 11:32 ` Jonathan Cameron
2025-06-18 11:32 ` Jonathan Cameron via
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=20250618123114.00002b98@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=a.manzanares@samsung.com \
--cc=alok.rathore@samsung.com \
--cc=arpit1.kumar@samsung.com \
--cc=dave@stgolabs.net \
--cc=gost.dev@samsung.com \
--cc=krish.reddy@samsung.com \
--cc=linux-cxl@vger.kernel.org \
--cc=nifan.cxl@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=vishak.g@samsung.com \
/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.