* Locking.  Consider whether /var/lib/lsvpd should be locked when
  update-lsvpd-db is running.  Currently multiple executions of
  update-lsvpd-db can occur concurrently with little risk.

* Implement VPD bus aliases that use a flattened namespace so the
  query commands can find all of the VPD by processing a single
  directory.  This could be done by flattening the directory
  structure, replacing each '/' with '%'.  This may not be faster if
  the directory gets *very* big.  The links would probably point to
  the parent directories, so the sort order would be correct.

  A compromise would be to duplicate the structure and have it contain
  only links to the VPD directories (or their parents).  The advantage
  of this approach is that the directories would be quite sparse and,
  for the device-tree case, wouldn't contain irrelevant
  subdirectories.  Therefore, find should work quicker.

* Sanity checking for SCSI EVPD page 0x0.

* Change environment variable $LSVPD_FAKE_NO_SYSFS to be
  $LSVPD_SYSFS_DIR and use it as lsvpd_sysfs_dir if it points to an
  existing directory.  If it doesn't point to a directory then don't
  use the sysfs code.

* Add the sysfs SCSI device VPD faking code to device_handler.  It
  can't hurt.  This involves making sure device_scsi_sg checks its
  activation conditions properly.

* PN and EC from EEPROM of certain network cards.
ext
  I've now noticed that for 14106902 (although not for the "14108902"
  - also an e1000-based card), the PN and EC appear near the end of
  the EEPROM, which can be got at via the ethtool interface:


  io-bears:~/martins # ethtool -e eth1
  Offset          Values
  ------          ------
  0x0000          00 02 55 d3 5c 56 30 05 ff ff ff ff ff ff ff ff
  0x0010          80 c3 03 64 03 46 69 02 14 10 26 10 86 80 e8 34
  0x0020          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  0x0030          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  0x0040          0c c3 86 72 00 35 02 21 c8 04 ff ff ff ff ff ff
  0x0050          ff ff ff ff ff ff ff ff ff ff ff ff ff ff 02 06
  0x0060          2c 00 00 40 04 11 00 00 ff ff ff ff ff ff ff ff
  0x0070          ff ff ff ff ff ff ff ff ff ff ff ff ff ff dd 5c
  0x0080          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  0x0090          ...
  0x01f0          30 30 50 36 31 33 30 48 31 32 38 31 38 20 38 55

  In this case we see:

    PN @ 0x01f0 (7 bytes) = 00P6130
    EC @ 0x01f7 (6 bytes) = H12818

  However, there doesn't seem to be anything else.

  Write a templating system (based on
  vendor/device/subvendor/subsystem-id) to parse the contents of the
  EEPROM.

* VPD from EEPROM on Digi 80P4353 serial card.  This is awaiting
  device driver support.

  sa1         U787E.001.AAA0010-P2-C1-T1    2-Port Asynchronous EIA-232
                                            PCI Adapter

        Displayable Message......... 2-Port Asynchronous EIA-232 PCI Adapter
        Part Number................. 80P4353
        FRU Number.................. 80P4353
        Manufacturer................Digi
        EC Level....................H13251
        Serial Number............... 014132959
        Device Specific.(YL)........U787E.001.AAA0010-P2-C1-T1

* Consider whether scan.d/07device_scsi_sg_scan:device_setup_scsi()
  should remove any device nodes it creates.

* Consider making PCI 2.2 VPD dynamic.  That is, make the query
  commands retrieve it.

* Consider factorising code in pci/pci_*_map.c.  This would involve
  factorising the structures too.  I'm not sure this is worth it.

* More adapters in lsmcode.

* Physical location aliases?

* Support system-wide N5 and N6 fields on pSeries:

    The next 2 keywords are also system-wide and are present only on
    systems with a Capacity Upgrade on Demand Capacity Card. N5
    represents the licensed entitlement of Capacity Upgrade on Demand
    (CUoD) processors. N6 represents the licensed entitlement of CUoD
    memory. The values for N5 and N6 are generated by making the
    "ibm,get-system-parameter" RTAS call.

  This is pending a stable RTAS interface... and demand.

* Implement hooks for hotplug and look at dynamic /proc/device-tree.

* Implement a regression testing suite.  This would allow testing of
  various components, although wouldn't allow testing of the overall
  system.

* Ethernet & SCSI adapter VPD is currently synthesised in a minimal
  way.  

  In the longer term some sort of real VPD retrieval needs to be
  implemented. I'm going to look at getting binary blobs with the
  contents of PCI expansion ROMs in /sys.  Note: this happened in
  2.6.10, but I had nothing to do with it...  :-)

* Add serial ports and other (hopefully) boring things...

* ...
