28 Apr, 2014

1 commit


09 Apr, 2014

4 commits

  • next-20140324 currently fails compiling celleb_defconfig with:

    arch/powerpc/include/asm/opal.h:894:42: error: 'struct notifier_block' declared inside parameter list [-Werror]
    arch/powerpc/include/asm/opal.h:894:42: error: its scope is only this definition or declaration, which is probably not what you want [-Werror]
    arch/powerpc/include/asm/opal.h:896:14: error: 'struct notifier_block' declared inside parameter list [-Werror]

    This is due to a missing include which is added here.

    Signed-off-by: Michael Neuling
    Signed-off-by: Benjamin Herrenschmidt

    Michael Neuling
     
  • This call will not be understood by OPAL, and cause it to add an error
    to it's log. Among other things, this is useful for testing the
    behaviour of the log as it fills up.

    Signed-off-by: Joel Stanley
    Signed-off-by: Benjamin Herrenschmidt

    Joel Stanley
     
  • OPAL provides an in-memory circular buffer containing a message log
    populated with various runtime messages produced by the firmware.

    Provide a sysfs interface /sys/firmware/opal/msglog for userspace to
    view the messages.

    Signed-off-by: Joel Stanley
    Signed-off-by: Benjamin Herrenschmidt

    Joel Stanley
     
  • One OPAL call and one device tree property needed byte swapping.

    Signed-off-by: Anton Blanchard
    Signed-off-by: Benjamin Herrenschmidt

    Anton Blanchard
     

07 Apr, 2014

2 commits


03 Apr, 2014

1 commit

  • Pull powerpc non-virtualized cpuidle from Ben Herrenschmidt:
    "This is the branch I mentioned in my other pull request which contains
    our improved cpuidle support for the "powernv" platform
    (non-virtualized).

    It adds support for the "fast sleep" feature of the processor which
    provides higher power savings than our usual "nap" mode but at the
    cost of losing the timers while asleep, and thus exploits the new
    timer broadcast framework to work around that limitation.

    It's based on a tip timer tree that you seem to have already merged"

    * 'powernv-cpuidle' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
    cpuidle/powernv: Parse device tree to setup idle states
    cpuidle/powernv: Add "Fast-Sleep" CPU idle state
    powerpc/powernv: Add OPAL call to resync timebase on wakeup
    powerpc/powernv: Add context management for Fast Sleep
    powerpc: Split timer_interrupt() into timer handling and interrupt handling routines
    powerpc: Implement tick broadcast IPI as a fixed IPI message
    powerpc: Free up the slot of PPC_MSG_CALL_FUNC_SINGLE IPI message

    Linus Torvalds
     

24 Mar, 2014

3 commits


07 Mar, 2014

3 commits

  • This enables support for userspace to fetch and initiate FSP and
    Platform dumps from the service processor (via firmware) through sysfs.

    Based on original patch from Vasant Hegde

    Flow:
    - We register for OPAL notification events.
    - OPAL sends new dump available notification.
    - We make information on dump available via sysfs
    - Userspace requests dump contents
    - We retrieve the dump via OPAL interface
    - User copies the dump data
    - userspace sends ack for dump
    - We send ACK to OPAL.

    sysfs files:
    - We add the /sys/firmware/opal/dump directory
    - echoing 1 (well, anything, but in future we may support
    different dump types) to /sys/firmware/opal/dump/initiate_dump
    will initiate a dump.
    - Each dump that we've been notified of gets a directory
    in /sys/firmware/opal/dump/ with a name of the dump type and ID (in hex,
    as this is what's used elsewhere to identify the dump).
    - Each dump has files: id, type, dump and acknowledge
    dump is binary and is the dump itself.
    echoing 'ack' to acknowledge (currently any string will do) will
    acknowledge the dump and it will soon after disappear from sysfs.

    OPAL APIs:
    - opal_dump_init()
    - opal_dump_info()
    - opal_dump_read()
    - opal_dump_ack()
    - opal_dump_resend_notification()

    Currently we are only ever notified for one dump at a time (until
    the user explicitly acks the current dump, then we get a notification
    of the next dump), but this kernel code should "just work" when OPAL
    starts notifying us of all the dumps present.

    Signed-off-by: Stewart Smith
    Signed-off-by: Benjamin Herrenschmidt

    Stewart Smith
     
  • Based on a patch by: Mahesh Salgaonkar

    This patch adds support to read error logs from OPAL and export
    them to userspace through a sysfs interface.

    We export each log entry as a directory in /sys/firmware/opal/elog/

    Currently, OPAL will buffer up to 128 error log records, we don't
    need to have any knowledge of this limit on the Linux side as that
    is actually largely transparent to us.

    Each error log entry has the following files: id, type, acknowledge, raw.
    Currently we just export the raw binary error log in the 'raw' attribute.
    In a future patch, we may parse more of the error log to make it a bit
    easier for userspace (e.g. to be able to display a brief summary in
    petitboot without having to have a full parser).

    If we have >128 logs from OPAL, we'll only be notified of 128 until
    userspace starts acknowledging them. This limitation may be lifted in
    the future and with this patch, that should "just work" from the linux side.

    A userspace daemon should:
    - wait for error log entries using normal mechanisms (we announce creation)
    - read error log entry
    - save error log entry safely to disk
    - acknowledge the error log entry
    - rinse, repeat.

    On the Linux side, we read the error log when we're notified of it. This
    possibly isn't ideal as it would be better to only read them on-demand.
    However, this doesn't really work with current OPAL interface, so we
    read the error log immediately when notified at the moment.

    I've tested this pretty extensively and am rather confident that the
    linux side of things works rather well. There is currently an issue with
    the service processor side of things for >128 error logs though.

    Signed-off-by: Stewart Smith
    Signed-off-by: Benjamin Herrenschmidt

    Stewart Smith
     
  • Detect and recover from machine check when inside opal on a special
    scom load instructions. On specific SCOM read via MMIO we may get a machine
    check exception with SRR0 pointing inside opal. To recover from MC
    in this scenario, get a recovery instruction address and return to it from
    MC.

    OPAL will export the machine check recoverable ranges through
    device tree node mcheck-recoverable-ranges under ibm,opal:

    # hexdump /proc/device-tree/ibm,opal/mcheck-recoverable-ranges
    0000000 0000 0000 3000 2804 0000 000c 0000 0000
    0000010 3000 2814 0000 0000 3000 27f0 0000 000c
    0000020 0000 0000 3000 2814 xxxx xxxx xxxx xxxx
    0000030 llll llll yyyy yyyy yyyy yyyy
    ...
    ...
    #

    where:
    xxxx xxxx xxxx xxxx = Starting instruction address
    llll llll = Length of the address range.
    yyyy yyyy yyyy yyyy = recovery address

    Each recoverable address range entry is (start address, len,
    recovery address), 2 cells each for start and recovery address, 1 cell for
    len, totalling 5 cells per entry. During kernel boot time, build up the
    recovery table with the list of recovery ranges from device-tree node which
    will be used during machine check exception to recover from MMIO SCOM UE.

    Signed-off-by: Mahesh Salgaonkar
    Signed-off-by: Benjamin Herrenschmidt

    Mahesh Salgaonkar
     

05 Mar, 2014

1 commit


28 Feb, 2014

1 commit


15 Jan, 2014

2 commits


30 Dec, 2013

1 commit


13 Dec, 2013

2 commits


09 Dec, 2013

1 commit


05 Dec, 2013

2 commits

  • Move SG list and entry structure to header file so that
    it can be used in other places as well.

    Signed-off-by: Vasant Hegde
    Signed-off-by: Benjamin Herrenschmidt

    Vasant Hegde
     
  • Opal now has a new messaging infrastructure to push the messages to
    linux in a generic format for different type of messages using only one
    event bit. The format of the opal message is as below:

    struct opal_msg {
    uint32_t msg_type;
    uint32_t reserved;
    uint64_t params[8];
    };

    This patch allows clients to subscribe for notification for specific
    message type. It is upto the subscriber to decipher the messages who showed
    interested in receiving specific message type.

    The interface to subscribe for notification is:

    int opal_message_notifier_register(enum OpalMessageType msg_type,
    struct notifier_block *nb)

    The notifier will fetch the opal message when available and notify the
    subscriber with message type and the opal message. It is subscribers
    responsibility to copy the message data before returning from notifier
    callback.

    Signed-off-by: Mahesh Salgaonkar
    Signed-off-by: Benjamin Herrenschmidt

    Mahesh Salgaonkar
     

30 Oct, 2013

2 commits

  • Code update interface for powernv platform. This provides
    sysfs interface to pass new image, validate, update and
    commit images.

    This patch includes:
    - Below OPAL APIs for code update
    - opal_validate_flash()
    - opal_manage_flash()
    - opal_update_flash()

    - Create below sysfs files under /sys/firmware/opal
    - image : Interface to pass new FW image
    - validate_flash : Validate candidate image
    - manage_flash : Commit/Reject operations
    - update_flash : Flash new candidate image

    Updating Image:
    "update_flash" is an interface to indicate flash new FW.
    It just passes image SG list to FW. Actual flashing is done
    during system reboot time.

    Note:
    - SG entry format:
    I have kept version number to keep this list similar to what
    PAPR is defined.

    Signed-off-by: Vasant Hegde
    Signed-off-by: Benjamin Herrenschmidt

    Vasant Hegde
     
  • Create /sys/firmware/opal directory. We wil use this
    interface to fetch opal error logs, firmware update, etc.

    Signed-off-by: Vasant Hegde
    Signed-off-by: Benjamin Herrenschmidt

    Vasant Hegde
     

11 Oct, 2013

4 commits


27 Aug, 2013

1 commit


14 Aug, 2013

2 commits


21 Jun, 2013

1 commit

  • This patch implements a notifier to receive a notification on OPAL
    event mask changes. The notifier is only called as a result of an OPAL
    interrupt, which will happen upon reception of FSP messages or PCI errors.
    Any event mask change detected as a result of opal_poll_events() will not
    result in a notifier call.

    [benh: changelog]
    Signed-off-by: Gavin Shan
    Signed-off-by: Benjamin Herrenschmidt

    Gavin Shan
     

20 Jun, 2013

1 commit

  • The patch synchronizes OPAL APIs between kernel and firmware. Also,
    we starts to replace opal_pci_get_phb_diag_data() with the similar
    opal_pci_get_phb_diag_data2() and the former OPAL API would return
    OPAL_UNSUPPORTED from now on.

    Signed-off-by: Gavin Shan
    Signed-off-by: Benjamin Herrenschmidt

    Gavin Shan
     

14 May, 2013

1 commit


10 May, 2013

1 commit

  • We add a machine_shutdown hook that frees the OPAL interrupts
    (so they get masked at the source and don't fire while kexec'ing)
    and which triggers an IODA reset on all the PCIe host bridges
    which will have the effect of blocking all DMAs and subsequent
    PCIs interrupts.

    Signed-off-by: Benjamin Herrenschmidt

    Benjamin Herrenschmidt
     

26 Apr, 2013

1 commit

  • The EOI handler of MSI/MSI-X interrupts for P8 (PHB3) need additional
    steps to handle the P/Q bits in IVE before EOIing the corresponding
    interrupt. The patch changes the EOI handler to cover that. we have
    individual IRQ chip in each PHB instance. During the MSI IRQ setup
    time, the IRQ chip is copied over from the original one for that IRQ,
    and the EOI handler is patched with the one that will handle the P/Q
    bits (As Ben suggested).

    Signed-off-by: Gavin Shan
    Signed-off-by: Benjamin Herrenschmidt

    Gavin Shan
     

07 Dec, 2011

1 commit


20 Sep, 2011

1 commit

  • OPAL can handle various interrupt for us such as Machine Checks (it
    performs all sorts of recovery tasks and passes back control to us with
    informations about the error), Hardware Management Interrupts and Softpatch
    interrupts.

    This wires up the mechanisms and prints out specific informations returned
    by HAL when a machine check occurs.

    Signed-off-by: Benjamin Herrenschmidt

    Benjamin Herrenschmidt