Re: [Intel-wired-lan] [PATCH iwl-net v2] ice: fix posted write support for sideband queue operations

[Jakub Ramaseuski <jramaseu@redhat.com>]

On Thu, Mar 19, 2026 at 12:15 PM Przemyslaw Korba <przemyslaw.korba@intel.com> wrote:
>
> On E830, PTP time adjustment commands sent via
> SBQ don't generate completion responses, causing the driver to
> timeout waiting and return -EIO, when trying:
>
> phc_ctl eth8 get adj 2 get
> dmesg: ice 0000:1a:00.0: PTP failed to adjust time, err -5
>
> Add support for posted mode not to wait for completion response.
>
> Fixes: 8f5ee3c477a8 ("ice: add support for sideband messages")
> Signed-off-by: Przemyslaw Korba <przemyslaw.korba@intel.com>
> ---
> v2:
> - change "postpone" to "posted"
> - init struct with {} instead of {0}
> v1:
> https://lore.kernel.org/intel-wired-lan/20260310110700.345904-1-przemyslaw.korba@intel.com/
>
>  drivers/net/ethernet/intel/ice/ice_common.c   | 7 ++++++-
>  drivers/net/ethernet/intel/ice/ice_controlq.c | 4 ++++
>  drivers/net/ethernet/intel/ice/ice_controlq.h | 1 +
>  3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c
> index 8866902efb91..c89c6ca1281b 100644
> --- a/drivers/net/ethernet/intel/ice/ice_common.c
> +++ b/drivers/net/ethernet/intel/ice/ice_common.c
> @@ -1765,6 +1765,7 @@ int ice_sbq_rw_reg(struct ice_hw *hw, struct ice_sbq_msg_input *in, u16 flags)
>  {
>         struct ice_sbq_cmd_desc desc = {0};
>         struct ice_sbq_msg_req msg = {0};
> +       struct ice_sq_cd cd = {};
>         u16 msg_len;
>         int status;
>
> @@ -1785,10 +1786,14 @@ int ice_sbq_rw_reg(struct ice_hw *hw, struct ice_sbq_msg_input *in, u16 flags)
>                  */
>                 msg_len -= sizeof(msg.data);
>
> +       if (in->opcode == ice_sbq_msg_wr)
> +               cd.posted = 1;
> +
>         desc.flags = cpu_to_le16(flags);
>         desc.opcode = cpu_to_le16(ice_sbq_opc_neigh_dev_req);
>         desc.param0.cmd_len = cpu_to_le16(msg_len);
> -       status = ice_sbq_send_cmd(hw, &desc, &msg, msg_len, NULL);
> +       status = ice_sbq_send_cmd(hw, &desc, &msg, msg_len, &cd);
> +
>         if (!status && !in->opcode)
>                 in->data = le32_to_cpu
>                         (((struct ice_sbq_msg_cmpl *)&msg)->data);
> diff --git a/drivers/net/ethernet/intel/ice/ice_controlq.c b/drivers/net/ethernet/intel/ice/ice_controlq.c
> index dcb837cadd18..a6008dc77fa4 100644
> --- a/drivers/net/ethernet/intel/ice/ice_controlq.c
> +++ b/drivers/net/ethernet/intel/ice/ice_controlq.c
> @@ -1086,6 +1086,10 @@ ice_sq_send_cmd(struct ice_hw *hw, struct ice_ctl_q_info *cq,
>         wr32(hw, cq->sq.tail, cq->sq.next_to_use);
>         ice_flush(hw);
>
> +       /* If the message is posted, don't wait for completion. */
> +       if (cd && cd->posted)
> +               goto sq_send_command_error;
> +
>         /* Wait for the command to complete. If it finishes within the
>          * timeout, copy the descriptor back to temp.
>          */
> diff --git a/drivers/net/ethernet/intel/ice/ice_controlq.h b/drivers/net/ethernet/intel/ice/ice_controlq.h
> index 788040dd662e..c50d6fcbacba 100644
> --- a/drivers/net/ethernet/intel/ice/ice_controlq.h
> +++ b/drivers/net/ethernet/intel/ice/ice_controlq.h
> @@ -77,6 +77,7 @@ struct ice_ctl_q_ring {
>  /* sq transaction details */
>  struct ice_sq_cd {
>         struct libie_aq_desc *wb_desc;
> +       u8 posted : 1;
>  };
>
>  /* rq event information */
>
> base-commit: acd2abc52dea91c3bc3d1b6dd8a92b9631d48bbf
> --
> 2.43.0
>
This is actually a valid fix to a,
885c5e57924dc0 ("ice: fix 'adjust' timer programming for E830 devices"),
which allows the E830 HW to continue in the function 
and then invoke the following: (with some ice_debug() messages enabled)

[ 2946.907728] ice 0000:6c:00.0: Failed to send message to PHY, err -5
[ 2946.907731] ice 0000:6c:00.0: Failed to prepare PHY ports for timer command 2, err -5
[ 2946.907733] ice 0000:6c:00.0: PTP failed to adjust time, err -5

But the patchwork lists it as Changes Requested. Any idea what happened with it?

Tested-by: Jakub Ramaseuski <jramaseu@redhat.com>