<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/include/uapi, branch dev-5.8</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.8</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.8'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2020-08-31T00:46:57+00:00</updated>
<entry>
<title>Merge tag 'v5.8.5' into dev-5.8</title>
<updated>2020-08-31T00:46:57+00:00</updated>
<author>
<name>Joel Stanley</name>
<email>joel@jms.id.au</email>
</author>
<published>2020-08-31T00:46:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=0dd0c8c492fa70707ca4f0d36dcb2e3c64105b16'/>
<id>urn:sha1:0dd0c8c492fa70707ca4f0d36dcb2e3c64105b16</id>
<content type='text'>
This is the 5.8.5 stable release

Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
</content>
</entry>
<entry>
<title>libnvdimm: Validate command family indices</title>
<updated>2020-08-21T11:15:03+00:00</updated>
<author>
<name>Dan Williams</name>
<email>dan.j.williams@intel.com</email>
</author>
<published>2020-07-20T22:07:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=88d1439b1e379cf13742e2a1f42c91d9931629d2'/>
<id>urn:sha1:88d1439b1e379cf13742e2a1f42c91d9931629d2</id>
<content type='text'>
commit 92fe2aa859f52ce6aa595ca97fec110dc7100e63 upstream.

The ND_CMD_CALL format allows for a general passthrough of passlisted
commands targeting a given command set. However there is no validation
of the family index relative to what the bus supports.

- Update the NFIT bus implementation (the only one that supports
  ND_CMD_CALL passthrough) to also passlist the valid set of command
  family indices.

- Update the generic __nd_ioctl() path to validate that field on behalf
  of all implementations.

Fixes: 31eca76ba2fc ("nfit, libnvdimm: limited/whitelisted dimm command marshaling mechanism")
Cc: Vishal Verma &lt;vishal.l.verma@intel.com&gt;
Cc: Dave Jiang &lt;dave.jiang@intel.com&gt;
Cc: Ira Weiny &lt;ira.weiny@intel.com&gt;
Cc: "Rafael J. Wysocki" &lt;rjw@rjwysocki.net&gt;
Cc: Len Brown &lt;lenb@kernel.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Vishal Verma &lt;vishal.l.verma@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>btrfs: pass checksum type via BTRFS_IOC_FS_INFO ioctl</title>
<updated>2020-08-21T11:14:49+00:00</updated>
<author>
<name>Johannes Thumshirn</name>
<email>johannes.thumshirn@wdc.com</email>
</author>
<published>2020-07-13T12:28:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=5199c3d6449a32940a062ff8fc986949be24bfe6'/>
<id>urn:sha1:5199c3d6449a32940a062ff8fc986949be24bfe6</id>
<content type='text'>
commit 137c541821a83debb63b3fa8abdd1cbc41bdf3a1 upstream.

With the recent addition of filesystem checksum types other than CRC32c,
it is not anymore hard-coded which checksum type a btrfs filesystem uses.

Up to now there is no good way to read the filesystem checksum, apart from
reading the filesystem UUID and then query sysfs for the checksum type.

Add a new csum_type and csum_size fields to the BTRFS_IOC_FS_INFO ioctl
command which usually is used to query filesystem features. Also add a
flags member indicating that the kernel responded with a set csum_type and
csum_size field.

For compatibility reasons, only return the csum_type and csum_size if
the BTRFS_FS_INFO_FLAG_CSUM_INFO flag was passed to the kernel. Also
clear any unknown flags so we don't pass false positives to user-space
newer than the kernel.

To simplify further additions to the ioctl, also switch the padding to a
u8 array. Pahole was used to verify the result of this switch:

The csum members are added before flags, which might look odd, but this
is to keep the alignment requirements and not to introduce holes in the
structure.

  $ pahole -C btrfs_ioctl_fs_info_args fs/btrfs/btrfs.ko
  struct btrfs_ioctl_fs_info_args {
	  __u64                      max_id;               /*     0     8 */
	  __u64                      num_devices;          /*     8     8 */
	  __u8                       fsid[16];             /*    16    16 */
	  __u32                      nodesize;             /*    32     4 */
	  __u32                      sectorsize;           /*    36     4 */
	  __u32                      clone_alignment;      /*    40     4 */
	  __u16                      csum_type;            /*    44     2 */
	  __u16                      csum_size;            /*    46     2 */
	  __u64                      flags;                /*    48     8 */
	  __u8                       reserved[968];        /*    56   968 */

	  /* size: 1024, cachelines: 16, members: 10 */
  };

Fixes: 3951e7f050ac ("btrfs: add xxhash64 to checksumming algorithms")
Fixes: 3831bf0094ab ("btrfs: add sha256 to checksumming algorithm")
CC: stable@vger.kernel.org # 5.5+
Signed-off-by: Johannes Thumshirn &lt;johannes.thumshirn@wdc.com&gt;
Reviewed-by: David Sterba &lt;dsterba@suse.com&gt;
Signed-off-by: David Sterba &lt;dsterba@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>bpf: Fix bpf_ringbuf_output() signature to return long</title>
<updated>2020-08-19T06:26:46+00:00</updated>
<author>
<name>Andrii Nakryiko</name>
<email>andriin@fb.com</email>
</author>
<published>2020-07-27T22:47:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=226020402b1fd210bf5335efa919368147fc4e7d'/>
<id>urn:sha1:226020402b1fd210bf5335efa919368147fc4e7d</id>
<content type='text'>
[ Upstream commit e1613b5714ee6c186c9628e9958edf65e9d9cddd ]

Due to bpf tree fix merge, bpf_ringbuf_output() signature ended up with int as
a return type, while all other helpers got converted to returning long. So fix
it in bpf-next now.

Fixes: b0659d8a950d ("bpf: Fix definition of bpf_ringbuf_output() helper in UAPI comments")
Signed-off-by: Andrii Nakryiko &lt;andriin@fb.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Acked-by: Song Liu &lt;songliubraving@fb.com&gt;
Link: https://lore.kernel.org/bpf/20200727224715.652037-1-andriin@fb.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>RDMA/qedr: Add EDPM max size to alloc ucontext response</title>
<updated>2020-08-19T06:26:36+00:00</updated>
<author>
<name>Michal Kalderon</name>
<email>michal.kalderon@marvell.com</email>
</author>
<published>2020-07-07T06:31:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=bdb550b1e4205881f7598e32d2fab9133ef0a694'/>
<id>urn:sha1:bdb550b1e4205881f7598e32d2fab9133ef0a694</id>
<content type='text'>
[ Upstream commit eb7f84e379daad69b4c92538baeaf93bbf493c14 ]

User space should receive the maximum edpm size from kernel driver,
similar to other edpm/ldpm related limits.  Add an additional parameter to
the alloc_ucontext_resp structure for the edpm maximum size.

In addition, pass an indication from user-space to kernel
(and not just kernel to user) that the DPM sizes are supported.

This is for supporting backward-forward compatibility between driver and
lib for everything related to DPM transaction and limit sizes.

This should have been part of commit mentioned in Fixes tag.

Link: https://lore.kernel.org/r/20200707063100.3811-3-michal.kalderon@marvell.com
Fixes: 93a3d05f9d68 ("RDMA/qedr: Add kernel capability flags for dpm enabled mode")
Signed-off-by: Ariel Elior &lt;ariel.elior@marvell.com&gt;
Signed-off-by: Michal Kalderon &lt;michal.kalderon@marvell.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>RDMA/qedr: Add EDPM mode type for user-fw compatibility</title>
<updated>2020-08-19T06:26:36+00:00</updated>
<author>
<name>Michal Kalderon</name>
<email>michal.kalderon@marvell.com</email>
</author>
<published>2020-07-07T06:30:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=06e28eb3bcef5eefe3500feefd05b9b559cebbf3'/>
<id>urn:sha1:06e28eb3bcef5eefe3500feefd05b9b559cebbf3</id>
<content type='text'>
[ Upstream commit bbe4f4245271bd0f21bf826996c0c5d87a3529c9 ]

In older FW versions the completion flag was treated as the ack flag in
edpm messages.  commit ff937b916eb6 ("qed: Add EDPM mode type for user-fw
compatibility") exposed the FW option of setting which mode the QP is in
by adding a flag to the qedr &lt;-&gt; qed API.

This patch adds the qedr &lt;-&gt; libqedr interface so that the libqedr can set
the flag appropriately and qedr can pass it down to FW.  Flag is added for
backward compatibility with libqedr.

For older libs, this flag didn't exist and therefore set to zero.

Fixes: ac1b36e55a51 ("qedr: Add support for user context verbs")
Link: https://lore.kernel.org/r/20200707063100.3811-2-michal.kalderon@marvell.com
Signed-off-by: Yuval Bason &lt;yuval.bason@marvell.com&gt;
Signed-off-by: Michal Kalderon &lt;michal.kalderon@marvell.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>seccomp: Fix ioctl number for SECCOMP_IOCTL_NOTIF_ID_VALID</title>
<updated>2020-08-19T06:26:12+00:00</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2020-06-15T22:42:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=51ef07ca87be36941e869f34896b95e15729b706'/>
<id>urn:sha1:51ef07ca87be36941e869f34896b95e15729b706</id>
<content type='text'>
[ Upstream commit 47e33c05f9f07cac3de833e531bcac9ae052c7ca ]

When SECCOMP_IOCTL_NOTIF_ID_VALID was first introduced it had the wrong
direction flag set. While this isn't a big deal as nothing currently
enforces these bits in the kernel, it should be defined correctly. Fix
the define and provide support for the old command until it is no longer
needed for backward compatibility.

Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>soc: aspeed: xdma: Add reset ioctl</title>
<updated>2020-08-06T00:30:34+00:00</updated>
<author>
<name>Eddie James</name>
<email>eajames@linux.ibm.com</email>
</author>
<published>2020-05-05T16:58:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a6f50f1aeb50cc92756a720b2bc42516d482ea5a'/>
<id>urn:sha1:a6f50f1aeb50cc92756a720b2bc42516d482ea5a</id>
<content type='text'>
Users of the XDMA engine need a way to reset it if something goes wrong.
Problems on the host side, or user error, such as incorrect host
address, may result in the DMA operation never completing and no way to
determine what went wrong. Therefore, add an ioctl to reset the engine
so that users can recover in this situation.

OpenBMC-Staging-Count: 2
Signed-off-by: Eddie James &lt;eajames@linux.ibm.com&gt;
Acked-by: Andrew Jeffery &lt;andrew@aj.id.au&gt;
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
</content>
</entry>
<entry>
<title>soc: aspeed: Add XDMA Engine Driver</title>
<updated>2020-08-06T00:30:34+00:00</updated>
<author>
<name>Eddie James</name>
<email>eajames@linux.ibm.com</email>
</author>
<published>2020-05-05T16:58:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=8bdaf5d46b2ff9fcb3b05a31afeb7e71c5e82fef'/>
<id>urn:sha1:8bdaf5d46b2ff9fcb3b05a31afeb7e71c5e82fef</id>
<content type='text'>
The XDMA engine embedded in the AST2500 and AST2600 SOCs performs PCI
DMA operations between the SOC (acting as a BMC) and a host processor
in a server.

This commit adds a driver to control the XDMA engine and adds functions
to initialize the hardware and memory and start DMA operations.

OpenBMC-Staging-Count: 2
Signed-off-by: Eddie James &lt;eajames@linux.ibm.com&gt;
Reviewed-by: Andrew Jeffery &lt;andrew@aj.id.au&gt;
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
</content>
</entry>
<entry>
<title>peci: Add support for PECI bus driver core</title>
<updated>2020-08-06T00:30:32+00:00</updated>
<author>
<name>Jae Hyun Yoo</name>
<email>jae.hyun.yoo@linux.intel.com</email>
</author>
<published>2019-12-18T01:27:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=90ddc4e972b53cb32bdc76a7180ede8b8c3797d2'/>
<id>urn:sha1:90ddc4e972b53cb32bdc76a7180ede8b8c3797d2</id>
<content type='text'>
This commit adds driver implementation for PECI bus core into linux
driver framework.

PECI (Platform Environment Control Interface) is a one-wire bus interface
that provides a communication channel from Intel processors and chipset
components to external monitoring or control devices. PECI is designed to
support the following sideband functions:

* Processor and DRAM thermal management
  - Processor fan speed control is managed by comparing Digital Thermal
    Sensor (DTS) thermal readings acquired via PECI against the
    processor-specific fan speed control reference point, or TCONTROL. Both
    TCONTROL and DTS thermal readings are accessible via the processor PECI
    client. These variables are referenced to a common temperature, the TCC
    activation point, and are both defined as negative offsets from that
    reference.
  - PECI based access to the processor package configuration space provides
    a means for Baseboard Management Controllers (BMC) or other platform
    management devices to actively manage the processor and memory power
    and thermal features.

* Platform Manageability
  - Platform manageability functions including thermal, power, and error
    monitoring. Note that platform 'power' management includes monitoring
    and control for both the processor and DRAM subsystem to assist with
    data center power limiting.
  - PECI allows read access to certain error registers in the processor MSR
    space and status monitoring registers in the PCI configuration space
    within the processor and downstream devices.
  - PECI permits writes to certain registers in the processor PCI
    configuration space.

* Processor Interface Tuning and Diagnostics
  - Processor interface tuning and diagnostics capabilities
    (Intel Interconnect BIST). The processors Intel Interconnect Built In
    Self Test (Intel IBIST) allows for infield diagnostic capabilities in
    the Intel UPI and memory controller interfaces. PECI provides a port to
    execute these diagnostics via its PCI Configuration read and write
    capabilities.

* Failure Analysis
  - Output the state of the processor after a failure for analysis via
    Crashdump.

PECI uses a single wire for self-clocking and data transfer. The bus
requires no additional control lines. The physical layer is a self-clocked
one-wire bus that begins each bit with a driven, rising edge from an idle
level near zero volts. The duration of the signal driven high depends on
whether the bit value is a logic '0' or logic '1'. PECI also includes
variable data transfer rate established with every message. In this way, it
is highly flexible even though underlying logic is simple.

The interface design was optimized for interfacing between an Intel
processor and chipset components in both single processor and multiple
processor environments. The single wire interface provides low board
routing overhead for the multiple load connections in the congested routing
area near the processor and chipset components. Bus speed, error checking,
and low protocol overhead provides adequate link bandwidth and reliability
to transfer critical device operating conditions and configuration
information.

This implementation provides the basic framework to add PECI extensions to
the Linux bus and device models. A hardware specific 'Adapter' driver can
be attached to the PECI bus to provide sideband functions described above.
It is also possible to access all devices on an adapter from userspace
through the /dev interface. A device specific 'Client' driver also can be
attached to the PECI bus so each processor client's features can be
supported by the 'Client' driver through an adapter connection in the bus.

OpenBMC-Staging-Count: 3
Signed-off-by: Jason M Biils &lt;jason.m.bills@linux.intel.com&gt;
Signed-off-by: Yunge Zhu &lt;yunge.zhu@linux.intel.com&gt;
Signed-off-by: Fengguang Wu &lt;fengguang.wu@intel.com&gt;
Signed-off-by: Jae Hyun Yoo &lt;jae.hyun.yoo@linux.intel.com&gt;
Reviewed-by: Haiyue Wang &lt;haiyue.wang@linux.intel.com&gt;
Reviewed-by: James Feist &lt;james.feist@linux.intel.com&gt;
Reviewed-by: Vernon Mauery &lt;vernon.mauery@linux.intel.com&gt;
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
</content>
</entry>
</feed>
