From: Sudeep Holla <sudeep.holla@kernel.org>
To: Adam Young <admiyo@os.amperecomputing.com>
Cc: Jassi Brar <jassisinghbrar@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Jeremy Kerr <jk@codeconstruct.com.au>,
Matt Johnston <matt@codeconstruct.com.au>,
Sudeep Holla <sudeep.holla@kernel.org>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Huisong Li <lihuisong@huawei.com>
Subject: Re: [PATCH v45 3/7] mailbox/pcc.c: report errors for PCC clients
Date: Wed, 22 Jul 2026 10:07:12 +0100 [thread overview]
Message-ID: <20260722-quantum-efficient-loris-adb10e@sudeepholla> (raw)
In-Reply-To: <20260721175258.87600-4-admiyo@os.amperecomputing.com>
On Tue, Jul 21, 2026 at 01:52:52PM -0400, Adam Young wrote:
> The tx_done callback function has a return code (rc) parameter
> that the tx_done callback can use to determine how to handle an error.
> However the IRQ handler was not setting that value if there is an error.
>
> The following clients are affected:
>
> drivers/acpi/cppc_acpi.c
> drivers/i2c/busses/i2c-xgene-slimpro.c
> drivers/hwmon/xgene-hwmon.c
> drivers/soc/hisilicon/kunpeng_hccs.c
> drivers/devfreq/hisi_uncore_freq.c
>
> All of these only use the error code to report, so they
> are expecting an error code to come thorugh, but they
> do not modify behavior based on this code.
>
> In the case of an error code in the IRQ, the handler was returning
> IRQ_NONE which is not correct: the IRQ handler was matched
> to the IRQ. This mean that multiple error codes returned from
> a PCC triggered interrupt would end up disabling the device.
>
> In addition, if the error code IRQ was coming from a Type4 Device that was
> expecting an IRQ response, that device would then be hung.
>
I recall reviewing something similar and may have had comments, although I
cannot locate them at the moment, thanks to your random patch inclusion
exclusion scheme in this MCTP over PCC.
Could you please avoid continuing the MCTP-over-PCC series in its current
form? In the previous v44 revisions, PCC changes appeared to be removed in
some versions and replaced with unrelated changes in others, which has made
the series difficult to follow and review.
Please post PCC changes that are independent of MCTP as a separate series.
Where the MCTP implementation depends directly on those PCC changes, they may
be posted together. However, the current series appears to include several
unrelated cleanups described as part of the MCTP-over-PCC work.
To keep the review manageable, please separate those changes going forward. I
may need to NACK future revisions if unrelated PCC cleanups continue to be
bundled into this series. I will be away and would like to review any PCC
code, so your patience will be much appreciated.
--
Regards,
Sudeep
next prev parent reply other threads:[~2026-07-22 9:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-21 17:52 [PATCH v45 0/7] MCTP over PCC Adam Young
2026-07-21 17:52 ` [PATCH v45 1/7] mailbox/pcc.c: shmem map/unmap startup/teardown Adam Young
2026-07-21 17:52 ` [PATCH v45 2/7] mailbox/pcc.c: ignore errors on type 4 channels Adam Young
2026-07-22 8:55 ` Sudeep Holla
2026-07-22 17:04 ` Adam Young
2026-07-21 17:52 ` [PATCH v45 3/7] mailbox/pcc.c: report errors for PCC clients Adam Young
2026-07-22 9:07 ` Sudeep Holla [this message]
2026-07-22 17:07 ` Adam Young
2026-07-21 17:52 ` [PATCH v45 4/7] mailbox/pcc.c: add query channel function Adam Young
2026-07-21 17:52 ` [PATCH v45 5/7] mctp pcc: Implement MCTP over PCC Transport Adam Young
2026-07-21 17:52 ` [PATCH v45 6/7] synchronize IRQ before releasing shared memory Adam Young
2026-07-21 17:52 ` [PATCH v45 7/7] wrap pchan->chan_in_use in READ/WRITE_ONCE Adam Young
2026-07-22 8:50 ` Sudeep Holla
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=20260722-quantum-efficient-loris-adb10e@sudeepholla \
--to=sudeep.holla@kernel.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=admiyo@os.amperecomputing.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jassisinghbrar@gmail.com \
--cc=jk@codeconstruct.com.au \
--cc=kuba@kernel.org \
--cc=lihuisong@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeconstruct.com.au \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox