1. 19 Jun, 2019 1 commit
  2. 15 Jun, 2019 1 commit
  3. 29 May, 2019 1 commit
  4. 07 May, 2019 1 commit
  5. 03 May, 2019 1 commit
  6. 01 May, 2019 3 commits
    • Nick Crews's avatar
      power: supply: core: Add missing documentation for CHARGE_CONTROL_* properties · 61e93655
      Nick Crews authored
      The existing POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT and
      POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX properties
      don't have documentation. I add that documentation here.
      
      v5 changes:
      - Split this commit out from the previous two commits.
      Signed-off-by: default avatarNick Crews <ncrews@chromium.org>
      Reviewed-by: default avatarEnric Balletbo i Serra <enric.balletbo@collabora.com>
      Signed-off-by: default avatarSebastian Reichel <sebastian.reichel@collabora.com>
      61e93655
    • Nick Crews's avatar
      power: supply: core: Add CHARGE_CONTROL_{START_THRESHOLD,END_THRESHOLD} properties · 813cab8f
      Nick Crews authored
      Add POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD
      and POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties, to expand
      the existing CHARGE_CONTROL_* properties. I am adding them in order
      to support a new Chrome OS device, but these properties should be
      general enough that they can be used on other devices.
      
      When the charge_type is "Custom", the charge controller uses the
      POWER_SUPPLY_PROP_CHARGE_CONTROL_* properties as configuration for some
      other algorithm. For example, in the use case that I am supporting,
      this means the battery begins charging when the percentage
      level drops below POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and
      charging ceases when the percentage level goes above
      POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD.
      
      v5 changes:
      - Add the other missing CHARGE_CONTROL_* properties documentation in
        a separate commit
      - Split up adding the charge types and adding the
        POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and
        POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties into
        two different commits.
      v4 changes:
      - Add documentation for the new properties, and add documentation for
        the the previously missing charge_control_limit and
        charge_control_limit_max properties.
      Signed-off-by: default avatarNick Crews <ncrews@chromium.org>
      Reviewed-by: default avatarEnric Balletbo i Serra <enric.balletbo@collabora.com>
      Signed-off-by: default avatarSebastian Reichel <sebastian.reichel@collabora.com>
      813cab8f
    • Nick Crews's avatar
      power: supply: core: Add Standard, Adaptive, and Custom charge types · ba6cc850
      Nick Crews authored
      Add "Standard", "Adaptive", and "Custom" modes to the charge_type
      property, to expand the existing "Trickle" and "Fast" modes.
      I am adding them in order to support a new Chrome OS device,
      but these properties should be general enough that they can be
      used on other devices.
      
      The meaning of "Standard" is obvious, but "Adaptive" and "Custom" are
      more tricky: "Adaptive" means that the charge controller uses some
      custom algorithm to change the charge type automatically, with no
      configuration needed. "Custom" means that the charge controller uses the
      POWER_SUPPLY_PROP_CHARGE_CONTROL_* properties as configuration for some
      other algorithm.
      
      v5 changes:
      - Split up adding the charge types and adding the
        POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and
        POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties into
        two different commits.
      v4 changes:
      - Add documentation for the new properties, and add documentation for
        the the previously missing charge_control_limit and
        charge_control_limit_max properties.
      Signed-off-by: default avatarNick Crews <ncrews@chromium.org>
      Reviewed-by: default avatarEnric Balletbo i Serra <enric.balletbo@collabora.com>
      Signed-off-by: default avatarSebastian Reichel <sebastian.reichel@collabora.com>
      ba6cc850
  7. 25 Apr, 2019 8 commits
  8. 21 Apr, 2019 1 commit
    • Robert Shearman's avatar
      i2c: mux: pca954x: allow management of device idle state via sysfs · f1fb64b0
      Robert Shearman authored
      The behaviour, by default, to not deselect after each transfer is
      unsafe when there is a device with an address that conflicts with
      another device on another mux on the same parent bus, and it
      may not be convenient to use devicetree to set the deselect mux,
      e.g. when running on x86_64 when ACPI is used to discover most of the
      device hierarchy.
      
      Therefore, provide the ability to set the idle state behaviour using a
      new sysfs file, idle_state as a complement to the method of
      instantiating the device via sysfs. The possible behaviours are
      disconnect, i.e. to deselect all channels from the mux, as-is (the
      default), i.e. leave the last channel selected, and set a
      predetermined channel.
      
      The current behaviour of leaving the channel as-is after each
      transaction is preserved.
      Signed-off-by: default avatarRobert Shearman <robert.shearman@att.com>
      Signed-off-by: Peter Rosin's avatarPeter Rosin <peda@axentia.se>
      f1fb64b0
  9. 18 Apr, 2019 1 commit
  10. 16 Apr, 2019 1 commit
    • Nick Crews's avatar
      platform/chrome: wilco_ec: Add h1_gpio status to debugfs · 9e2b0e0b
      Nick Crews authored
      As part of Chrome OS's FAFT (Fully Automated Firmware Testing)
      tests, we need to ensure that the H1 chip is properly setting
      some GPIO lines. The h1_gpio attribute exposes the state
      of the lines:
      - ENTRY_TO_FACT_MODE in BIT(0)
      - SPI_CHROME_SEL in BIT(1)
      
      There are two reasons that I am exposing this in debugfs,
      and not as a GPIO:
      1. This is only useful for testing, so end users shouldn't ever
      care about this. In fact, if it passes the tests, then the value of
      h1_gpio will always be 2, so it would be really uninteresting for users.
      2. This GPIO is not connected to, controlled by, or really even related
      to the AP. The GPIO runs between the EC and the H1 security chip.
      
      Changes in v4:
      - Use "0x02x\n" instead of "02x\n" for format string
      - Use DEFINE_DEBUGFS_ATTRIBUTE()
      - Add documentation
      Changes in v3:
      - Fix documentation to correspond with formatting change in v2.
      Changes in v2:
      - Zero out the unused fields in the request.
      - Format result as "%02x\n" instead of as a decimal.
      Signed-off-by: default avatarNick Crews <ncrews@chromium.org>
      Signed-off-by: default avatarEnric Balletbo i Serra <enric.balletbo@collabora.com>
      9e2b0e0b
  11. 15 Apr, 2019 1 commit
    • Nick Crews's avatar
      platform/chrome: wilco_ec: Standardize mailbox interface · 14e14aaf
      Nick Crews authored
      The current API for the wilco EC mailbox interface is bad.
      
      It assumes that most messages sent to the EC follow a similar structure,
      with a command byte in MBOX[0], followed by a junk byte, followed by
      actual data. This doesn't happen in several cases, such as setting the
      RTC time, using the raw debugfs interface, and reading or writing
      properties such as the Peak Shift policy (this last to be submitted soon).
      
      Similarly for the response message from the EC, the current interface
      assumes that the first byte of data is always 0, and the second byte
      is unused. However, in both setting and getting the RTC time, in the
      debugfs interface, and for reading and writing properties, this isn't
      true.
      
      The current way to resolve this is to use WILCO_EC_FLAG_RAW* flags to
      specify when and when not to skip these initial bytes in the sent and
      received message. They are confusing and used so much that they are
      normal, and not exceptions. In addition, the first byte of
      response in the debugfs interface is still always skipped, which is
      weird, since this raw interface should be giving the entire result.
      
      Additionally, sent messages assume the first byte is a command, and so
      struct wilco_ec_message contains the "command" field. In setting or
      getting properties however, the first byte is not a command, and so this
      field has to be filled with a byte that isn't actually a command. This
      is again inconsistent.
      
      wilco_ec_message contains a result field as well, copied from
      wilco_ec_response->result. The message result field should be removed:
      if the message fails, the cause is already logged, and the callers are
      alerted. They will never care about the actual state of the result flag.
      
      These flags and different cases make the wilco_ec_transfer() function,
      used in wilco_ec_mailbox(), really gross, dealing with a bunch of
      different cases. It's difficult to figure out what it is doing.
      
      Finally, making these assumptions about the structure of a message make
      it so that the messages do not correspond well with the specification
      for the EC's mailbox interface. For instance, this interface
      specification may say that MBOX[9] in the received message contains
      some information, but the calling code needs to remember that the first
      byte of response is always skipped, and because it didn't set the
      RESPONSE_RAW flag, the next byte is also skipped, so this information
      is actually contained within wilco_ec_message->response_data[7]. This
      makes it difficult to maintain this code in the future.
      
      To fix these problems this patch standardizes the mailbox interface by:
      - Removing the WILCO_EC_FLAG_RAW* flags
      - Removing the command and reserved_raw bytes from wilco_ec_request
      - Removing the mbox0 byte from wilco_ec_response
      - Simplifying wilco_ec_transfer() because of these changes
      - Gives the callers of wilco_ec_mailbox() the responsibility of exactly
        and consistently defining the structure of the mailbox request and
        response
      - Removing command and result from wilco_ec_message.
      
      This results in the reduction of total code, and makes it much more
      maintainable and understandable.
      Signed-off-by: default avatarNick Crews <ncrews@chromium.org>
      Acked-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: default avatarEnric Balletbo i Serra <enric.balletbo@collabora.com>
      14e14aaf
  12. 07 Apr, 2019 1 commit
  13. 04 Apr, 2019 6 commits
  14. 02 Apr, 2019 1 commit
  15. 25 Mar, 2019 1 commit
  16. 21 Mar, 2019 1 commit
    • Kimberly Brown's avatar
      Drivers: hv: vmbus: Expose monitor data only when monitor pages are used · 46fc1548
      Kimberly Brown authored
      There are two methods for signaling the host: the monitor page mechanism
      and hypercalls. The monitor page mechanism is used by performance
      critical channels (storage, networking, etc.) because it provides
      improved throughput. However, latency is increased. Monitor pages are
      allocated to these channels.
      
      Monitor pages are not allocated to channels that do not use the monitor
      page mechanism. Therefore, these channels do not have a valid monitor id
      or valid monitor page data. In these cases, some of the "_show"
      functions return incorrect data. They return an invalid monitor id and
      data that is beyond the bounds of the hv_monitor_page array fields.
      
      The "channel->offermsg.monitor_allocated" value can be used to determine
      whether monitor pages have been allocated to a channel.
      
      Add "is_visible()" callback functions for the device-level and
      channel-level attribute groups. These functions will hide the monitor
      sysfs files when the monitor mechanism is not used.
      
      Remove ".default_attributes" from "vmbus_chan_attrs" and create a
      channel-level attribute group. These changes allow the new
      "is_visible()" callback function to be applied to the channel-level
      attributes.
      
      Call "sysfs_create_group()" in "vmbus_add_channel_kobj()" to create the
      channel's sysfs files. Add a new function,
      “vmbus_remove_channel_attr_group()”, and call it in "free_channel()" to
      remove the channel's sysfs files when the channel is closed.
      Signed-off-by: default avatarKimberly Brown <kimbrownkd@gmail.com>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Reviewed-by: default avatarMichael Kelley <mikelley@microsoft.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      46fc1548
  17. 06 Mar, 2019 3 commits
  18. 02 Mar, 2019 1 commit
  19. 21 Feb, 2019 3 commits
  20. 18 Feb, 2019 2 commits
    • Oded Gabbay's avatar
      habanalabs: add debugfs support · c2164773
      Oded Gabbay authored
      This patch adds debugfs support to the driver. It allows the user-space to
      display information that is contained in the internal structures of the
      driver, such as:
      - active command submissions
      - active user virtual memory mappings
      - number of allocated command buffers
      
      It also enables the user to perform reads and writes through Goya's PCI
      bars.
      Reviewed-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Signed-off-by: default avatarOded Gabbay <oded.gabbay@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c2164773
    • Oded Gabbay's avatar
      habanalabs: add sysfs and hwmon support · d91389bc
      Oded Gabbay authored
      This patch add the sysfs and hwmon entries that are exposed by the driver.
      
      Goya has several sensors, from various categories such as temperature,
      voltage, current, etc. The driver exposes those sensors in the standard
      hwmon mechanism.
      
      In addition, the driver exposes a couple of interfaces in sysfs, both for
      configuration and for providing status of the device or driver.
      
      The configuration attributes is for Power Management:
      - Automatic or manual
      - Frequency value when moving to high frequency mode
      - Maximum power the device is allowed to consume
      
      The rest of the attributes are read-only and provide the following
      information:
      - Versions of the various firmwares running on the device
      - Contents of the device's EEPROM
      - The device type (currently only Goya is supported)
      - PCI address of the device (to allow user-space to connect between
        /dev/hlX to PCI address)
      - Status of the device (operational, malfunction, in_reset)
      - How many processes are open on the device's file
      Reviewed-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Signed-off-by: default avatarOded Gabbay <oded.gabbay@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d91389bc
  21. 15 Feb, 2019 1 commit
    • Kimberly Brown's avatar
      Drivers: hv: vmbus: Expose counters for interrupts and full conditions · 396ae57e
      Kimberly Brown authored
      Counter values for per-channel interrupts and ring buffer full
      conditions are useful for investigating performance.
      
      Expose counters in sysfs for 2 types of guest to host interrupts:
      1) Interrupts caused by the channel's outbound ring buffer transitioning
      from empty to not empty
      2) Interrupts caused by the channel's inbound ring buffer transitioning
      from full to not full while a packet is waiting for enough buffer space to
      become available
      
      Expose 2 counters in sysfs for the number of times that write operations
      encountered a full outbound ring buffer:
      1) The total number of write operations that encountered a full
      condition
      2) The number of write operations that were the first to encounter a
      full condition
      
      Increment the outbound full condition counters in the
      hv_ringbuffer_write() function because, for most drivers, a full
      outbound ring buffer is detected in that function. Also increment the
      outbound full condition counters in the set_channel_pending_send_size()
      function. In the hv_sock driver, a full outbound ring buffer is detected
      and set_channel_pending_send_size() is called before
      hv_ringbuffer_write() is called.
      
      I tested this patch by confirming that the sysfs files were created and
      observing the counter values. The values seemed to increase by a
      reasonable amount when the Hyper-v related drivers were in use.
      Signed-off-by: default avatarKimberly Brown <kimbrownkd@gmail.com>
      Reviewed-by: default avatarMichael Kelley <mikelley@microsoft.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      396ae57e