mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: <admiyo@os.amperecomputing.com>
Cc: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Jeremy Kerr <jk@codeconstruct.com.au>,
	Matt Johnston <matt@codeconstruct.com.au>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Huisong Li <lihuisong@huawei.com>
Subject: Re: [PATCH v4 0/3] MCTP over PCC
Date: Thu, 11 Jul 2024 09:57:29 -0700	[thread overview]
Message-ID: <66900ef8e7c79_1a77429414@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <20240702225845.322234-1-admiyo@os.amperecomputing.com>

admiyo@ wrote:
> From: Adam Young <admiyo@os.amperecomputing.com>
> 
> This series adds support for the Management Control Transport Protocol (MCTP)
> over the Platform Communication Channel (PCC) mechanism.
> 
> MCTP defines a communication model intended to
> facilitate communication between Management controllers
> and other management controllers, and between Management
> controllers and management devices
> 
> PCC is a mechanism for communication between components within
> the  Platform.  It is a composed of shared memory regions,
> interrupt registers, and status registers.
> 
> The MCTP over PCC driver makes use of two PCC channels. For
> sending messages, it uses a Type 3 channel, and for receiving
> messages it uses the paired Type 4 channel.  The device
> and corresponding channels are specified via ACPI.
> 
> The first patch in the series implements a mechanism to allow the driver
> to indicate whether an ACK should be sent back to the caller
> after processing the interrupt.  This is an optional feature in
> the PCC code, but has been made explicitly required in another driver.
> The implementation here maintains the backwards compatibility of that
> driver.
> 
> The second patch in the series is the required change from ACPICA
> code that will be imported into the Linux kernel when synchronized
> with the ACPICA repository. It ahs already merged there and will
> be merged in as is.  It is included here so that the patch series
> can run and be tested prior to that merge.

This cover letter looks woefully insufficient.

What is the end user visible effect of merging these patches, or not
merging these patches?  I.e. what does Linux gain by merging them, what
pressing end user need goes unsatisfied if these are not merged? What is
the security model for these commands, i.e. how does a distro judge
whether this facility allows bypass of Kernel Lockdown protections?

The Kconfig does not help either. All this patch says is "communication
path exists, plumb it direct to userspace", with no discussion of
intended use cases, assumptions, or tradeoffs.

  parent reply	other threads:[~2024-07-11 16:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-02 22:58 admiyo
2024-07-02 22:58 ` [PATCH v4 1/3] mctp pcc: Check before sending MCTP PCC response ACK admiyo
2024-07-03 19:52   ` Simon Horman
2024-07-04  2:44   ` kernel test robot
2024-07-04  8:53   ` kernel test robot
2024-07-04  9:40   ` Jeremy Kerr
2024-07-02 22:58 ` [PATCH v4 2/3] mctp pcc: Allow PCC Data Type in MCTP resource admiyo
2024-07-02 22:58 ` [PATCH v4 3/3] mctp pcc: Implement MCTP over PCC Transport admiyo
2024-07-03 19:53   ` Simon Horman
2024-07-04  5:43   ` kernel test robot
2024-07-04  6:08   ` kernel test robot
2024-07-04 10:23   ` Jeremy Kerr
2024-07-08 22:16     ` Adam Young
2024-07-11 16:57 ` Dan Williams [this message]
2024-07-15 18:21   ` [PATCH v4 0/3] MCTP over PCC Adam Young

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=66900ef8e7c79_1a77429414@dwillia2-xfh.jf.intel.com.notmuch \
    --to=dan.j.williams@intel.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=admiyo@os.amperecomputing.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.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 \
    --cc=sudeep.holla@arm.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

all inboxes | Powered by JetHome®