cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

TODO (2865B)


      1Contributions are solicited in particular to remedy the following issues:
      2
      3cpcihp:
      4
      5* There are no implementations of the ->hardware_test, ->get_power and
      6  ->set_power callbacks in struct cpci_hp_controller_ops.  Why were they
      7  introduced?  Can they be removed from the struct?
      8
      9cpqphp:
     10
     11* The driver spawns a kthread cpqhp_event_thread() which is woken by the
     12  hardirq handler cpqhp_ctrl_intr().  Convert this to threaded IRQ handling.
     13  The kthread is also woken from the timer pushbutton_helper_thread(),
     14  convert it to call irq_wake_thread().  Use pciehp as a template.
     15
     16* A large portion of cpqphp_ctrl.c and cpqphp_pci.c concerns resource
     17  management.  Doesn't this duplicate functionality in the core?
     18
     19ibmphp:
     20
     21* Implementations of hotplug_slot_ops callbacks such as get_adapter_present()
     22  in ibmphp_core.c create a copy of the struct slot on the stack, then perform
     23  the actual operation on that copy.  Determine if this overhead is necessary,
     24  delete it if not.  The functions also perform a NULL pointer check on the
     25  struct hotplug_slot, this seems superfluous.
     26
     27* Several functions access the pci_slot member in struct hotplug_slot even
     28  though pci_hotplug.h declares it private.  See get_max_bus_speed() for an
     29  example.  Either the pci_slot member should no longer be declared private
     30  or ibmphp should store a pointer to its bus in struct slot.  Probably the
     31  former.
     32
     33* ibmphp_init_devno() takes a struct slot **, it could instead take a
     34  struct slot *.
     35
     36* The return value of pci_hp_register() is not checked.
     37
     38* The various slot data structures are difficult to follow and need to be
     39  simplified.  A lot of functions are too large and too complex, they need
     40  to be broken up into smaller, manageable pieces.  Negative examples are
     41  ebda_rsrc_controller() and configure_bridge().
     42
     43* A large portion of ibmphp_res.c and ibmphp_pci.c concerns resource
     44  management.  Doesn't this duplicate functionality in the core?
     45
     46sgi_hotplug:
     47
     48* Several functions access the pci_slot member in struct hotplug_slot even
     49  though pci_hotplug.h declares it private.  See sn_hp_destroy() for an
     50  example.  Either the pci_slot member should no longer be declared private
     51  or sgi_hotplug should store a pointer to it in struct slot.  Probably the
     52  former.
     53
     54shpchp:
     55
     56* There is only a single implementation of struct hpc_ops.  Can the struct be
     57  removed and its functions invoked directly?  This has already been done in
     58  pciehp with commit 82a9e79ef132 ("PCI: pciehp: remove hpc_ops").  Clarify
     59  if there was a specific reason not to apply the same change to shpchp.
     60
     61* The ->get_mode1_ECC_cap callback in shpchp_hpc_ops is never invoked.
     62  Why was it introduced?  Can it be removed?
     63
     64* The hardirq handler shpc_isr() queues events on a workqueue.  It can be
     65  simplified by converting it to threaded IRQ handling.  Use pciehp as a
     66  template.