<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers/Kconfig, branch dev-5.15-intel</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.15-intel</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.15-intel'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2021-11-05T07:22:07+00:00</updated>
<entry>
<title>drivers: jtag: Add JTAG core driver</title>
<updated>2021-11-05T07:22:07+00:00</updated>
<author>
<name>Ernesto Corona</name>
<email>ernesto.corona@intel.com</email>
</author>
<published>2020-09-29T15:39:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=c1738baebe83a474ad51776fee87cf3b2af26ce0'/>
<id>urn:sha1:c1738baebe83a474ad51776fee87cf3b2af26ce0</id>
<content type='text'>
JTAG class driver provide infrastructure to support hardware/software
JTAG platform drivers. It provide user layer API interface for flashing
and debugging external devices which equipped with JTAG interface
using standard transactions.

Driver exposes set of IOCTL to user space for:
- XFER:
  SIR (Scan Instruction Register, IEEE 1149.1 Data Register scan);
  SDR (Scan Data Register, IEEE 1149.1 Instruction Register scan);
- GIOCSTATUS read the current TAPC state of the JTAG controller
- SIOCSTATE Forces the JTAG TAPC to go into a particular state.
- SIOCFREQ/GIOCFREQ for setting and reading JTAG frequency.
- IOCBITBANG for low level control of JTAG signals.

Driver core provides set of internal APIs for allocation and
registration:
- jtag_register;
- jtag_unregister;
- jtag_alloc;
- jtag_free;

Platform driver on registration with jtag-core creates the next
entry in dev folder:
/dev/jtagX

Signed-off-by: Oleksandr Shamray &lt;oleksandrs@mellanox.com&gt;
Signed-off-by: Jiri Pirko &lt;jiri@mellanox.com&gt;
Signed-off-by: Ernesto Corona &lt;ernesto.corona@intel.com&gt;
Acked-by: Philippe Ombredanne &lt;pombredanne@nexb.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Boris Brezillon &lt;bbrezillon@kernel.org&gt;
Cc: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Johan Hovold &lt;johan@kernel.org&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: Joel Stanley &lt;joel@jms.id.au&gt;
Cc: Palmer Dabbelt &lt;palmer@sifive.com&gt;
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Cc: William Breathitt Gray &lt;vilhelm.gray@gmail.com&gt;
Cc: Federico Vaga &lt;federico.vaga@cern.ch&gt;
Cc: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Cc: Christian Gromm &lt;christian.gromm@microchip.com&gt;
Cc: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Cc: Yiwei Zhang &lt;zzyiwei@google.com&gt;
Cc: Alessandro Rubini &lt;rubini@gnudd.com&gt;
Cc: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Cc: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Cc: Steven Filary &lt;steven.a.filary@intel.com&gt;
Cc: Vadim Pasternak &lt;vadimp@mellanox.com&gt;
Cc: Amithash Prasad &lt;amithash@fb.com&gt;
Cc: Patrick Williams &lt;patrickw3@fb.com&gt;
Cc: Rgrs &lt;rgrs@protonmail.com&gt;
</content>
</entry>
<entry>
<title>peci: Add support for PECI bus driver core</title>
<updated>2021-11-05T07:22:04+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=6cc62068d78b988c2fe47d373d3853b24242507b'/>
<id>urn:sha1:6cc62068d78b988c2fe47d373d3853b24242507b</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.

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;
</content>
</entry>
<entry>
<title>firmware: include drivers/firmware/Kconfig unconditionally</title>
<updated>2021-10-07T14:51:26+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2021-09-28T07:50:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=951cd3a0866d29cb9c01ebc1d9c17590e598226e'/>
<id>urn:sha1:951cd3a0866d29cb9c01ebc1d9c17590e598226e</id>
<content type='text'>
Compile-testing drivers that require access to a firmware layer
fails when that firmware symbol is unavailable. This happened
twice this week:

 - My proposed to change to rework the QCOM_SCM firmware symbol
   broke on ppc64 and others.

 - The cs_dsp firmware patch added device specific firmware loader
   into drivers/firmware, which broke on the same set of
   architectures.

We should probably do the same thing for other subsystems as well,
but fix this one first as this is a dependency for other patches
getting merged.

Reviewed-by: Bjorn Andersson &lt;bjorn.andersson@linaro.org&gt;
Reviewed-by: Charles Keepax &lt;ckeepax@opensource.cirrus.com&gt;
Acked-by: Will Deacon &lt;will@kernel.org&gt;
Acked-by: Bjorn Andersson &lt;bjorn.andersson@linaro.org&gt;
Cc: Mark Brown &lt;broonie@kernel.org&gt;
Cc: Liam Girdwood &lt;lgirdwood@gmail.com&gt;
Cc: Charles Keepax &lt;ckeepax@opensource.cirrus.com&gt;
Cc: Simon Trimmer &lt;simont@opensource.cirrus.com&gt;
Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Reviewed-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</content>
</entry>
<entry>
<title>remove the lightnvm subsystem</title>
<updated>2021-08-14T21:54:09+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2021-08-12T13:23:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=9ea9b9c48387edc101d56349492ad9c0492ff78d'/>
<id>urn:sha1:9ea9b9c48387edc101d56349492ad9c0492ff78d</id>
<content type='text'>
Lightnvm supports the OCSSD 1.x and 2.0 specs which were early attempts
to produce Open Channel SSDs and never made it into the NVMe spec
proper.  They have since been superceeded by NVMe enhancements such
as ZNS support.  Remove the support per the deprecation schedule.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Link: https://lore.kernel.org/r/20210812132308.38486-1-hch@lst.de
Reviewed-by: Matias Bjørling &lt;mb@lightnvm.io&gt;
Reviewed-by: Javier González &lt;javier@javigon.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>ide: remove the legacy ide driver</title>
<updated>2021-06-16T14:53:58+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2021-06-16T13:46:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b7fb14d3ac63117e0e8beabe75f4ea52051fbe3a'/>
<id>urn:sha1:b7fb14d3ac63117e0e8beabe75f4ea52051fbe3a</id>
<content type='text'>
The legay ide driver has been replace with libata starting in 2003 and has
been scheduled for removal for a while.  Finally kill it off so that we
can start cleaning up various bits of cruft it forced on the block layer.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>staging: comedi: move out of staging directory</title>
<updated>2021-04-15T07:26:25+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2021-04-14T08:58:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=8ffdff6a8cfbdc174a3a390b6f825a277b5bb895'/>
<id>urn:sha1:8ffdff6a8cfbdc174a3a390b6f825a277b5bb895</id>
<content type='text'>
The comedi code came into the kernel back in 2008, but traces its
lifetime to much much earlier.  It's been polished and buffed and
there's really nothing preventing it from being part of the "real"
portion of the kernel.

So move it to drivers/comedi/ as it belongs there.

Many thanks to the hundreds of developers who did the work to make this
happen.

Cc: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Cc: H Hartley Sweeten &lt;hsweeten@visionengravers.com&gt;
Link: https://lore.kernel.org/r/YHauop4u3sP6lz8j@kroah.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>cxl/mem: Introduce a driver for CXL-2.0-Type-3 endpoints</title>
<updated>2021-02-17T04:36:38+00:00</updated>
<author>
<name>Dan Williams</name>
<email>dan.j.williams@intel.com</email>
</author>
<published>2021-02-17T04:09:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=4cdadfd5e0a70017fec735b7b6d7f2f731842dc6'/>
<id>urn:sha1:4cdadfd5e0a70017fec735b7b6d7f2f731842dc6</id>
<content type='text'>
The CXL.mem protocol allows a device to act as a provider of "System
RAM" and/or "Persistent Memory" that is fully coherent as if the memory
was attached to the typical CPU memory controller.

With the CXL-2.0 specification a PCI endpoint can implement a "Type-3"
device interface and give the operating system control over "Host
Managed Device Memory". See section 2.3 Type 3 CXL Device.

The memory range exported by the device may optionally be described by
the platform firmware memory map, or by infrastructure like LIBNVDIMM to
provision persistent memory capacity from one, or more, CXL.mem devices.

A pre-requisite for Linux-managed memory-capacity provisioning is this
cxl_mem driver that can speak the mailbox protocol defined in section
8.2.8.4 Mailbox Registers.

For now just land the initial driver boiler-plate and Documentation/
infrastructure.

Signed-off-by: Ben Widawsky &lt;ben.widawsky@intel.com&gt;
Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Acked-by: David Rientjes &lt;rientjes@google.com&gt; (v1)
Cc: Jonathan Corbet &lt;corbet@lwn.net&gt;
Link: https://www.computeexpresslink.org/download-the-specification
Link: https://lore.kernel.org/r/20210217040958.1354670-2-ben.widawsky@intel.com
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost</title>
<updated>2020-04-08T17:51:53+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2020-04-08T17:51:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=9bb715260ed4cef6948cb2e05cf670462367da71'/>
<id>urn:sha1:9bb715260ed4cef6948cb2e05cf670462367da71</id>
<content type='text'>
Pull virtio updates from Michael Tsirkin:

 - Some bug fixes

 - The new vdpa subsystem with two first drivers

* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
  virtio-balloon: Revert "virtio-balloon: Switch back to OOM handler for VIRTIO_BALLOON_F_DEFLATE_ON_OOM"
  vdpa: move to drivers/vdpa
  virtio: Intel IFC VF driver for VDPA
  vdpasim: vDPA device simulator
  vhost: introduce vDPA-based backend
  virtio: introduce a vDPA based transport
  vDPA: introduce vDPA bus
  vringh: IOTLB support
  vhost: factor out IOTLB
  vhost: allow per device message handler
  vhost: refine vhost and vringh kconfig
  virtio-balloon: Switch back to OOM handler for VIRTIO_BALLOON_F_DEFLATE_ON_OOM
  virtio-net: Introduce hash report feature
  virtio-net: Introduce RSS receive steering feature
  virtio-net: Introduce extended RSC feature
  tools/virtio: option to build an out of tree module
</content>
</entry>
<entry>
<title>Merge tag 'trace-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace</title>
<updated>2020-04-05T17:36:18+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2020-04-05T17:36:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=aa1a8ce533324d12696a9f4b71dbc5eb561a2e04'/>
<id>urn:sha1:aa1a8ce533324d12696a9f4b71dbc5eb561a2e04</id>
<content type='text'>
Pull tracing updates from Steven Rostedt:
 "New tracing features:

   - The ring buffer is no longer disabled when reading the trace file.

     The trace_pipe file was made to be used for live tracing and
     reading as it acted like the normal producer/consumer. As the trace
     file would not consume the data, the easy way of handling it was to
     just disable writes to the ring buffer.

     This came to a surprise to the BPF folks who complained about lost
     events due to reading. This is no longer an issue. If someone wants
     to keep the old disabling there's a new option "pause-on-trace"
     that can be set.

   - New set_ftrace_notrace_pid file. PIDs in this file will not be
     traced by the function tracer.

     Similar to set_ftrace_pid, which makes the function tracer only
     trace those tasks with PIDs in the file, the set_ftrace_notrace_pid
     does the reverse.

   - New set_event_notrace_pid file. PIDs in this file will cause events
     not to be traced if triggered by a task with a matching PID.

     Similar to the set_event_pid file but will not be traced. Note,
     sched_waking and sched_switch events may still be traced if one of
     the tasks referenced by those events contains a PID that is allowed
     to be traced.

  Tracing related features:

   - New bootconfig option, that is attached to the initrd file.

     If bootconfig is on the command line, then the initrd file is
     searched looking for a bootconfig appended at the end.

   - New GPU tracepoint infrastructure to help the gfx drivers to get
     off debugfs (acked by Greg Kroah-Hartman)

  And other minor updates and fixes"

* tag 'trace-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: (27 commits)
  tracing: Do not allocate buffer in trace_find_next_entry() in atomic
  tracing: Add documentation on set_ftrace_notrace_pid and set_event_notrace_pid
  selftests/ftrace: Add test to test new set_event_notrace_pid file
  selftests/ftrace: Add test to test new set_ftrace_notrace_pid file
  tracing: Create set_event_notrace_pid to not trace tasks
  ftrace: Create set_ftrace_notrace_pid to not trace tasks
  ftrace: Make function trace pid filtering a bit more exact
  ftrace/kprobe: Show the maxactive number on kprobe_events
  tracing: Have the document reflect that the trace file keeps tracing enabled
  ring-buffer/tracing: Have iterator acknowledge dropped events
  tracing: Do not disable tracing when reading the trace file
  ring-buffer: Do not disable recording when there is an iterator
  ring-buffer: Make resize disable per cpu buffer instead of total buffer
  ring-buffer: Optimize rb_iter_head_event()
  ring-buffer: Do not die if rb_iter_peek() fails more than thrice
  ring-buffer: Have rb_iter_head_event() handle concurrent writer
  ring-buffer: Add page_stamp to iterator for synchronization
  ring-buffer: Rename ring_buffer_read() to read_buffer_iter_advance()
  ring-buffer: Have ring_buffer_empty() not depend on tracing stopped
  tracing: Save off entry when peeking at next entry
  ...
</content>
</entry>
<entry>
<title>vdpa: move to drivers/vdpa</title>
<updated>2020-04-02T14:41:40+00:00</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2020-03-31T19:15:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=c9b9f5f8c0f3cdb893cb86c168cdaa3aa5ed7278'/>
<id>urn:sha1:c9b9f5f8c0f3cdb893cb86c168cdaa3aa5ed7278</id>
<content type='text'>
We have both vhost and virtio drivers that depend on vdpa.
It's easier to locate it at a top level directory otherwise
we run into issues e.g. if vhost is built-in but virtio
is modular.  Let's just move it up a level.

Reported-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
</content>
</entry>
</feed>
