Orange Pi5 kernel

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