The vivid driver emulates CEC, but it is not a precise emulation. In particular it will not correctly emulate errors like Arbitration Lost. The right approach is likely to emulate the CEC bus at the low level and use the cec-pin framework to implement the emulated CEC adapters. Difficulty: Medium/Hard. Time: 1-2 weeks.

Mentor(s): Hans Verkuil, Shuah Khan

Requires a Raspberry Pi and a TV with CEC support. The v4l-utils repository contains the cec-compliance utility that is used to test CEC. The CEC commands are divided into groups called 'Features' where each 'Feature' deals with specific CEC functionality (e.g. starting a recording, programming timers, TV tuning, etc.). Some features are tested in-depth, others only have limited test coverage. Extending test coverage would be very nice. Different people can improve test support for different features, so this can be done in parallel. Difficulty: Easy/Medium (depends on the feature). Time: variable (again very much dependent on the feature).

Mentor(s): Hans Verkuil, Shuah Khan

Currently only SDR input is emulated. Hans Verkuil started the work and which can be continued to completion. As part of this work the current SDR implementation needs to be converted to a proper kthread implementation as was done for video. Some knowledge of SDR (i.e. how software defined radio works) is a nice-to-have. Difficulty: Medium. Time: 10 days.

Mentor(s): Hans Verkuil, Shuah Khan

Metadata capture is fairly new and emulation for this was never added to vivid. Metadata output has also appeared in kernel 5.0, so it makes sense for this project to add emulation support for both capture and output at the same time. Difficulty: Medium/Hard. Time: capture only: 10-15 days. Add another 5 days for metadata output support.

Mentor(s): Hans Verkuil, Shuah Khan

It will be very similar to regular video capture, but we would need a new test pattern for this, something that emulates touchpads. Difficulty: Medium (I think). Time: 5-10 days.

Mentor(s): Hans Verkuil, Shuah Khan

The Linux kernel reclaims physical memory in the event of a shortage by compaction or page reclaim. The two approaches are implemented in a similar fashion in that, as memory falls below various thresholds, they proceed first asynchronously, via kcompactd or kswapd, and then synchronously. The latter, i.e. the “direct” path, is considerably slower and the corresponding stall in the caller is typically perceived as an impact on performance.

Direct compaction and reclaim will be avoided if their asynchronous counterparts can reclaim memory more quickly than it is consumed. Conversely, if memory is consumed more quickly than it may be reclaimed, then stalling can be avoided only by increasing the watermark at which the asynchronous daemons are activated. This, however, increases the risk of spurious activity when there is no real threat of exhaustion.

This project aims to use mathematical forecasting techniques to identify imminent memory exhaustion with a view to averting it by preemptive memory reclamation. The objective is to reduce stalls even under high rates of memory consumption and yet avoid compaction or page reclaim until absolutely necessary.

Mentor: Khalid Aziz Mentee: Bharath Vedartham

Enhance lspci utility which is included in the PCI Utilities Package. Please work with Bjorn Helgaas on how to contribute.

• (Completed) Simplify lspci bridge windows decode : The show_range() function in the lspci utility has code to print “[empty]”, but I think that code is dead and should be removed. See commit 41d883cb97f9 (“lspci: better display of ranges behind a bridge”).
• (Completed) Add lspci support to decode an AIDA64 log file : “lspci -xxx” produces a hexdump of PCI configuration space, and “lspci -F” reads that dump file and decodes it. lspci could be enhanced to decode the hexdump format from an AIDA64 log file.
• (Completed) Add lspci support to decode “pci=earlydump” output : Booting the kernel with the “pci=earlydump” parameter produces a hexdump of PCI configuration space in the dmesg log. lspci could be enhanced to decode that hexdump.
• Change lspci to hexdump vendor-specific capabilities: PCI allows vendor-specific capability structures in configuration space. lspci only knows how to decode capabilities defined by the PCI specs, but it could still produce a hexdump of the vendor-specific data.

Mentor: Bjorn Helgaas Mentee: Kelsey Skunberg

The include/linux/pci.h header file defines several symbols that are used only in drivers/pci/. Some of these should be moved to drivers/pci/pci.h so they're not visible to the rest of the kernel. Start by looking at each symbol in include/linux/pci.h and searching for uses outside drivers/pci/.

Mentor: Bjorn Helgaas Mentee: Kelsey Skunberg

Architectures currently define HAVE_ARCH_PCI_RESOURCE_TO_USER if they want to provide their own pci_resource_to_user() implementation. If we make the generic version a weak function, the architecture-specific versions would automatically override the generic one, and the #defines could be removed.

Mentor: Bjorn Helgaas

Code that iterates over all standard PCI BARs typically uses PCI_STD_RESOURCE_END, but this is error-prone because it requires “i ⇐ PCI_STD_RESOURCE_END” rather than something like “i < PCI_NUM_BARS”. We could add such a definition and use it the same way PCI_SRIOV_NUM_BARS is used.

Mentor: Bjorn Helgaas

We currently use EXPORT_SYMBOL_GPL(pci_bus_sem), but I don't think any modules use it, so it shouldn't need to be exported.

Mentor: Bjorn Helgaas Mentee: Kelsey Skunberg

octeon_mbox_process_cmd() directly writes the PCI_EXP_DEVCTL_BCR_FLR bit, which bypasses timing requirements imposed by the PCIe spec. It should use the pcie_flr() interface instead.

Mentor: Bjorn Helgaas

“pci_dev.resource[PCI_BRIDGE_RESOURCES + 0]” and following elements have specific meanings but code often uses these hard-coded offsets instead of a symbolic name. Add names, e.g., PCI_BRIDGE_WINDOW_IO, for them.

Mentor: Bjorn Helgaas (in progress)

drivers/net/fddi/skfp/h/skfbi.h defines its own copies of PCI_COMMAND, PCI_STATUS, etc. These should be removed in favor of the generic definitions in include/uapi/linux/pci_regs.h. Other drivers probably do similar things.

Mentor: Bjorn Helgaas

PCIe defines two optional hotplug indicators: a Power indicator and an Attention indicator. Both are controlled by the same register, and each can be on, off or blinking. The current interfaces (pciehp_green_led_{on,off,blink}() and pciehp_set_attention_status()) are non-uniform and require two register writes in many cases where we could do one.

Mentor: Bjorn Helgaas

This is a common pattern:

if (!acpi_has_method(handle, "_DEP"))
  return <error>;

status = acpi_evaluate_reference(handle, "_DEP", ...);
if (ACPI_FAILURE(status))
  return <error>;

The acpi_has_method() call is superfluous because the acpi_evaluate_*() interfaces already return an error if the method doesn't exist.

Mentor: Bjorn Helgaas Mentee: Kelsey Skunberg

The PCIe Capability has several versions and it's tricky to use it correctly. All access to this capability should be via pcie_capability_*() accessors that know about the different versions, but some drivers don't use them. For example, this affects PCI_EXP_DEVCAP, PCI_EXP_DEVCTL, PCI_EXP_DEVSTA, PCI_EXP_LNKCAP, etc. One such user is mtip_disable_link_opts().

Mentor: Bjorn Helgaas

Power management was originally implemented using function pointers in struct pci_driver, e.g., pci_driver.suspend, pci_driver.resume, etc. This was replaced over ten years ago by a scheme that uses hooks in the generic struct device_driver instead of the struct pci_driver. For some of the history, see:

• 1eede070a59e ("Introduce new top level suspend and hibernation callbacks")
• adf094931ffb ("PM: Simplify the new suspend/hibernation framework for devices")

Several PCI drivers still use the legacy power management hooks (struct pci_driver.suspend, etc), but we'd like to convert them to the new style and eventually remove pci_driver.suspend entirely. Here are some previous driver conversions:

• 226e6b866d74 ("gpio: pch: Convert to dev_pm_ops")
• 1089c91111a1 ("parport: PCI core handles power state for us")
• 8249c47c6ba4 ("fm10k: use generic PM hooks instead of legacy PCIe power hooks")
• 0e5d3da40055 ("i40e: use newer generic PM support instead of legacy PM callbacks")

Examples of drivers that need conversion are ne2k_driver and mlx4_driver. One approach to finding others might be to remove the pci_driver.suspend member, build all drivers, and see which drivers fail to build.

The pci_has_legacy_pm_support() interface is also relevant and could be removed eventually.

Mentor: Bjorn Helgaas Mentee: Krzysztof Wilczynski (in progress)