aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-08-26Add skiboot-5.1.18 release notesskiboot-5.1.18Stewart Smith1-0/+31
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-08-25opal/hmi: Fix a TOD HMI failure during a race condition.Mahesh Salgaonkar1-0/+7
There are chances where another interrupt can wake a CPU in 0x100 vector just when HMI for TOD error is also pending. In such a rare race condition if CPU has woken up with tb_loss power saving mode, it will invoke opal call to resync the TB. Since TOD is already in error state, resync TB will timeout leaving TFMR bit 18 set to '1'. (TFMR[18]=1 means TB is prepared to receive new value from TOD. Once the new value is received this bit gets reset to '0', otherwise TB would stay in waiting state). When HMI is delivered, it may find all TFMR errors are already cleared but would fail to restore TB since TFMR bit 18 is already set. This leads to HMI recovery failure causing a kernel crash. This patch fixes this by clearing of TB errors if TFMR[18] is set to 1. This makes sure that TB is in clean state before TB restore process starts. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> (cherry picked from commit 026b9a13bf8d61a7e72721d59961b40cbc98b410) Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-08-24hw/phb3: Update capi initialization sequenceFrederic Barrat1-1/+2
The capi initialization sequence was revised in a circumvention document when a 'link down' error was converted from fatal to Endpoint Recoverable. Other, non-capi, register setup was corrected even before the initial open-source release of skiboot, but a few capi-related registers were not updated then, so this patch fixes it. The point is that a link-down error detected by the UTL logic will lead to an AIB fence, so that the CAPP unit can detect the error. Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> (cherry picked from commit e36f4f219b642c6c5032208fca7191fbd75fe1a3) Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-08-02log_level: Reduce the in memory console log_level to lower priorityPridhiviraj Paidipeddi3-3/+3
Below are the in-memory console log messages observed with error level(PR_ERROR) [54460318,3] HBRT: Mem region 'ibm,homer-image' not found ! [54465404,3] HBRT: Mem region 'ibm,homer-image' not found ! [54470372,3] HBRT: Mem region 'ibm,homer-image' not found ! [54475369,3] HBRT: Mem region 'ibm,homer-image' not found ! [11540917382,3] NVRAM: Layout appears sane [11694529822,3] OPAL: Trying a CPU re-init with flags: 0x2 [61291003267,3] OPAL: Trying a CPU re-init with flags: 0x1 [61394005956,3] OPAL: Trying a CPU re-init with flags: 0x2 Lowering the log level of mem region not found messages to PR_WARNING and remaining messages to PR_INFO level [54811683,4] HBRT: Mem region 'ibm,homer-image' not found ! [10923382751,6] NVRAM: Layout appears sane [55533988976,6] OPAL: Trying a CPU re-init with flags: 0x1 Signed-off-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> (cherry picked from commit 341daa8104af3231b908e6fcffeedb5e47b33990) Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-07-28core/flash: Fix passing pointer instead of valueCyril Bur1-1/+1
flash_find_subpartition() accepts a pointer to a boolean variable indicating ecc for a region of flash and passes the pointer directly to flash_read_corrected() which actually only wants the value. This has always worked probably because there has always been ECC on sub partitions. How there aren't any warnings triggered by this condition escapes me. Fixes: 6c26bc7 ("libflash: move ffs_flash_read into libflash") Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> (cherry picked from commit 81a538a678edf666568ca4adffe074b3dbce6dc3) Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-07-21FSP/ELOG: Fix OPAL generated elog resend logicVasant Hegde1-5/+0
Fix resend logic in opal_resend_pending_logs, so that it actually restarts sending remaining logs. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> (cherry picked from commit a6d4a7884e95cb9c918b8a217c11e46b01218358) Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-07-21FSP/ELOG: Fix possible event notifier hangsVasant Hegde2-3/+18
In some corner cases host may send acknowledgement without reading actual data (fsp_opal_elog_info -> fsp_opal_elog_ack). Because of this elog_read_from_fsp_head_state may be stuck in wrong state (ELOG_STATE_HOST_INFO) and not able to send remaining ELOG's to host. Hence reset ELOG state and start sending remaining ELOG's. Also in normal case we will ACK the logs which are already processed (elog_read_processed). Hence rearrange the code such that we go through elog_read_processed first. Finally return OPAL_PARAMETER if we are not able to find ELOG ID. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [stewart@linux.vnet.ibm.com: spelling fix] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> (cherry picked from commit e7c8cba4ad773055f390632c2996d3242b633bf4) Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-07-21FSP/ELOG: Disable event notification if list is not consistentVasant Hegde1-0/+2
Chances of elog_read_pending inconsistent state is very very less. Just to be on safer side, disable notification if list is not in consistent state. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Reviewed-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> (cherry picked from commit 1fb10de164d3ca034193df81c1f5d007aec37781) Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-07-21FSP/ELOG: Improve elog event statesVasant Hegde2-1/+3
ELOG enables event notification once new log is available. And this will be disabled after host completes reading logs (it has to complete both fsp_opal_elog_info and fsp_opal_elog_read). Ideally we should disable notification as soon as host consumes event (after fsp_opal_elog_info). Also if host fails to call fsp_opal_elog_read (ex: situations like duplicate event), then we endup keeping notification forever. This patch introduces new ELOG state (ELOG_STATE_HOST_INFO). As soon as host consumes event elog will move to this new state so that event notification is disabled. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> (cherry picked from commit cec5750a4a86ff3f69e1d8817eda023f4d40c492) Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-07-21FSP/ELOG: Fix OPAL generated elog event notificationVasant Hegde3-18/+34
We use elog notifier to notify logs from multiple sources (FSP generated logs - fsp-elog-read.c and OPAL generated logs - fsp-elog-write.c). OPAL generated logs sets elog event bit whenever it has new logs to send to host. But it relies on fsp-elog-read.c to disable the event bit..which is wrong! This patch creates common function to enable/disable event notification. It will enable event notification if any of the source is ready to send error log to host and disables notification once it completes sending all errors to host. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> (cherry picked from commit ec366ad4e2e871096fa4c614ad7e89f5bb6f884f) Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-07-21FSP/ELOG: Disable event notification during kexecVasant Hegde1-13/+33
ELOG enables event notification once new log is available. And this will be disabled after host completes reading logs (it has to complete both fsp_opal_elog_info and fsp_opal_elog_read). In some corner cases like kexec, host may endup reading same ELOG id twice (calling fsp_opal_elog_info twice because of resend request). Host finds it as duplicate and it will not read actual log (fsp_opal_elog_read()). In such situations we fails to disable event notification :-( Scenario : OPAL Host ------------------------------------- OPAL_EVENT_ELOG_AVAIL --> kexec OPAL_EVENT_ELOG_AVAIL --> elog client registered <-- read ELOG (id=x) <-- resend elog (opal_resend_pending_logs()) resend all ELOG --> read ELOG (id=x) -- Duplicate ELOG ! bhoom!! kernel call trace: ------------------ [ 28.055923] CPU: 10 PID: 20 Comm: irq/29-opal-elo Not tainted 4.4.0-24-generic #43-Ubuntu [ 28.056012] task: c0000000ef982a20 ti: c0000000efa38000 task.ti: c0000000efa38000 [ 28.056100] NIP: c000000008010a24 LR: c000000008010a24 CTR: 0000000030033758 [ 28.056188] REGS: c0000000efa3b9c0 TRAP: 0901 Not tainted (4.4.0-24-generic) [ 28.056274] MSR: 9000000100009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 22000844 XER: 20000000 [ 28.056499] CFAR: c000000008009958 SOFTE: 1 GPR00: c000000008131e8c c0000000efa3bc40 c0000000095b4200 0000000000000900 GPR04: c0000000094a63c8 0000000000000001 9000000100009033 0000000000000062 GPR08: 0000000000000000 0000000000000000 c0000000ef960400 9000000100001003 GPR12: c00000000806de48 c00000000fb45f00 [ 28.057042] NIP [c000000008010a24] arch_local_irq_restore+0x74/0x90 [ 28.057117] LR [c000000008010a24] arch_local_irq_restore+0x74/0x90 [ 28.057189] Call Trace: [ 28.057221] [c0000000efa3bc40] [c0000000f108a980] 0xc0000000f108a980 (unreliable) [ 28.057326] [c0000000efa3bc60] [c000000008131e8c] irq_finalize_oneshot.part.2+0xbc/0x250 [ 28.057429] [c0000000efa3bcb0] [c000000008132170] irq_thread_fn+0x80/0xa0 [ 28.057519] [c0000000efa3bcf0] [c00000000813263c] irq_thread+0x1ac/0x280 [ 28.057609] [c0000000efa3bd80] [c0000000080e61e0] kthread+0x110/0x130 [ 28.057698] [c0000000efa3be30] [c000000008009538] ret_from_kernel_thread+0x5c/0xa4 [ 28.057799] Instruction dump: [ 28.057844] 994d02ca 2fa30000 409e0024 e92d0020 61298000 7d210164 38210020 e8010010 [ 28.057995] 7c0803a6 4e800020 60420000 4bff17ad <60000000> 4bffffe4 60420000 e92d0020 This patch adds kexec notifier client. It will disable event notification during kexec. Once host is ready to receive ELOG's again it will call fsp_opal_resend_pending_logs(). This call re-enables ELOG notication. It will fix above issue. I will add follow up patch to improve event state. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> (cherry picked from commit d2ae07fd97bb9408456279cec799f72cb78680a6) Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-07-21Add skiboot-5.1.17 release notesskiboot-5.1.17Stewart Smith1-0/+19
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-07-21hw/xscom: Reset XSCOM engine after querying sleeping core FIRVipin K Parashar1-2/+2
XSCOM engine blocks subsequently after querying FIR of any sleeping core. This causes subsequent XSCOM opertions to hang forever due to XSCOM engine being continuously busy. Reset XSCOM engine after querying FIR of any sleeping core. Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> (cherry picked from commit 15cec493804ff14e6246eb1b65e9d0c7cb469a81) Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-07-21hw/xscom: Reset XSCOM engine after finite number of retries when busyVipin K Parashar3-17/+64
OPAL retries XSCOM read/write operations forever till it succeeds. This can cause XSCOM ops to hang forever when XSCOM engine remains busy for some reason. Changed it to retry XSCOM operations only XSCOM_BUSY_MAX_RETRIES number of times instead of retrying forever. Also added logic to reset XSCOM engine after XSCOM_BUSY_RESET_THRESHOLD number of retries to unblock it when it remains busy. Cc: stable # 9c2d82394fd2 ("xscom: Return OPAL_WRONG_STATE on XSCOM ops..") Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> (cherry picked from commit e761222593a1ae932cddbc81239b6a7cd98ddb70) Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-07-21xscom: Return OPAL_WRONG_STATE on XSCOM ops if CPU is asleepRussell Currey2-11/+23
xscom_read and xscom_write return OPAL_SUCCESS if they worked, and OPAL_HARDWARE if they didn't. This doesn't provide information about why the operation failed, such as if the CPU happens to be asleep. This is specifically useful in error scanning, so if every CPU is being scanned for errors, sleeping CPUs likely aren't the cause of failures. So, return OPAL_WRONG_STATE in xscom_read and xscom_write if the CPU is sleeping. Signed-off-by: Russell Currey <ruscur@russell.cc> Reviewed-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> (cherry picked from commit 9c2d82394fd2303847cac4a665dee62556ca528a) Signed-off-by: Vipin K Parashar <vipin@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-06-20Fix typosStewart Smith8-12/+12
Backport of user visible typo fixes partial cherry picked from 4c95b5e04e3c4f72e4005574f67cd6e365d3276f Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-06-09Fixup whitespace and build warning/errorStewart Smith1-4/+4
Fixes: f46c1e506d199332b0f9741278c8ec35b3e39135 Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> (cherry picked from commit 348dacfaca9f139db2603f5c2e78d87e21938ca6)
2016-06-09pci: Do a dummy config write to devices to establish bus numberBenjamin Herrenschmidt1-0/+7
On PCI Express, devices need to know their own bus number in order to provide the correct source identification (aka RID) in upstream packets they might send, such as error messages or DMAs. However while devices know (and hard wire) their own device and function number, they know nothing about bus numbers by default, those are decoded by bridges for routing. All they know is that if their parent bridge sends a "type 0" configuration access, they should decode it provided the device and function numbers match. The PCIe spec thus defines that when a device receive such a configuration access and it's a write, it should "capture" the bus number in the source field of the packet, and re-use as the originator bus number of all subsequent outgoing requests. In order to ensure that a device has this bus number firmly established before it's likely to send error packets upstream, we should thus do a dummy configuration write to it as soon as possible after probing. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com> [stewart@linux.vnet.ibm.com: fix Evolution broken patch, write vdid rather than &vdid as per Gavin suggestion] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> (cherry picked from commit f46c1e506d199332b0f9741278c8ec35b3e39135)
2016-04-29Add skiboot-5.1.16 release notesskiboot-5.1.16Stewart Smith1-0/+52
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-04-27hw/phb3: Ensure PQ bits are cleared in the IVC when masking IRQMichael Neuling1-6/+26
When we mask an interrupt, we may race with another interrupt coming in from the hardware. If this occurs, the P and/or Q bit may end up being set but we never EOI/clear them. This could result in a lost interrupt or the next interrupt that comes in after re-enabling never being presented. This patch ensures that when masking an interrupt, any pending P/Q bits are cleared. This fixes a bug seen with some CAPI workloads which have lots of interrupt masking at the same time as high interrupt load. The fix is not specific to CAPI though. Signed-off-by: Michael Neuling <mikey@neuling.org> Tested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-04-27hw/phb3: Fix potential race in EOIMichael Neuling1-5/+29
When we EOI we need to clear the present (P) bit in the Interrupt Vector Cache (IVC). We must clear P ensuring that any additional interrupts that come in aren't lost while also maintaining coherency with the Interrupt Vector Table (IVT). To do this, the hardware provides a conditional update bit in the IVC. This bit ensures that generation counts between the IVT and the IVC updates are synchronised. Unfortunately we never set this the bit to conditionally update the P bit in the IVC based on the generation count. Also, we didn't set what we wanted the new generation count to be if the update was successful. This patch fixes sets both of these. It also reworks and documents the code so that mortals may eventually be able to understand this process. Signed-off-by: Michael Neuling <mikey@neuling.org> Tested-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com> Tested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-04-06OPAL:Handle mbox response with bad status:0x24 during FSP terminationMamatha2-3/+15
Problem Description: During FSP termination/reset, FSP received mbox command from OPAL for "Fetching platform management function data". As FSP is in termination state DMAE operation failed to write memory data to hypervisor, so FSP sent mbox command with response status as 0x24 to OPAL and OPAL committed a predictive log with SRC BB822411 and sent back response status as 0xFE, which FSP IPMI will not understand the failure at the Host and IPMI will log the error. Fix:This patch is to fix when OPAL receives a bad response from FSP 0x24 due to DMAE error, commit informational log and return response status as SUCCESS and for all other bad status response commit predictive log. Signed-off-by: Mamatha Inamdar <mamatha4@linux.vnet.ibm.com> Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-04-01hmi: Fix a bug where partial hmi event was reported to host.Mahesh Salgaonkar1-7/+8
The current code sends partial hmi event (4 * 64bits instead of 5 * 64bits) to host. The last 64 bits contains chip id/pir info for reporting checkstop events. This bug affects only checkstop events. Host console o/p without this patch: [ 305.628283] Fatal Hypervisor Maintenance interrupt [Not recovered] [ 305.628341] Error detail: Malfunction Alert [ 305.628388] HMER: 8040000000000000 [ 305.628423] CPU PIR: 00000000 [ 305.628458] [Unit: VSU] Logic core check stop Host console o/p with this patch: [ 200.122883] Fatal Hypervisor Maintenance interrupt [Not recovered] [ 200.122941] Error detail: Malfunction Alert [ 200.122986] HMER: 8040000000000000 [ 200.123021] CPU PIR: 000008e8 [ 200.123055] [Unit: VSU] Logic core check stop Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-03-16Add skiboot-5.1.15 release notesskiboot-5.1.15Stewart Smith1-0/+9
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-03-11ipmi-sel: Fix memory leak in error pathVasant Hegde1-0/+1
Commit a5299ba2 dropped non-severe event from logging to BMC, but I forgot to releaes the error log structure. Fixes: a5299ba2 (IPMI: Only log events that needs attention) Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-03-09add skiboot-5.1.14 release notesskiboot-5.1.14Stewart Smith1-0/+20
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-02-23fsp: fix spelling of "advertise" in log messageAndrew Donnellan1-1/+1
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-02-23core: Add explicit 1:1 mappings in ranges propertiesSam Mendoza-Jonas1-5/+12
Currently skiboot adds an empty ranges property for each PCI bridge, representing a 1:1 mapping, which the kernel can later update if needed. However this does not appear to be the case, which leads to an issue in the kernel where the translation of assigned-addresses properties is mishandled and prematurely drops the PCI memory flags (ie. the first cell of an address). Instead, explicitly describe a 1:1 mapping in each bridge's ranges property, allowing assigned-addresses to be properly handled. Signed-off-by: Sam Mendoza-Jonas <sam@mendozajonas.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-27Add skiboot-5.1.13 release notesskiboot-5.1.13Stewart Smith1-0/+43
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-27hmi: Identify the phb upon CAPI malfunction alertPhilippe Bergheaud1-1/+3
commit 2e4cc4dca8c0d31138adc52076b38d80c5a6bef0 upstream Find the phb index with capp_phb3_attached_mask. Signed-off-by: Philippe Bergheaud <felix@linux.vnet.ibm.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-21DT sorting testOliver O'Halloran5-46/+148
Moved the dt_dump() into test/dt_common.c so that it can be shared between hdata/test/hdata_to_dt.c and core/test/run-device.c run-device.c contains two tests, one basic sorting test and a generate-and-sort test. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> [stewart@linux.vnet.ibm.com: remove trailing whitespace] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-21hdata/test: Updated the hdata_to_dt test data for the new sorting behaviourOliver O'Halloran1-8906/+8725
Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-21core/device.c: Sort nodes with name@unit names by unitOliver O'Halloran1-4/+52
When unflattening (or building from hdat) a device tree child nodes are added in the order in which they are encountered. For nodes that have a <basename>@<unit> style name with a common basename it is useful to have them in the tree sorted by the unit in ascending order. Currently this requires the source data to present them in sorted order, but this isn't always the case. This patch modifies the node insertion process to insert new nodes in the correct location so the list of child nodes is sorted. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> [stewart@linux.vnet.ibm.com: remove trailing whitespace] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-21hdata/hdata_to_dt.c: Also print node names.Oliver O'Halloran2-8648/+8995
Currently the hdata_to_dt script will only dump the node properties. This change adds a "node: <name>" line to the default output and adds the -t flag to only print the node names, without properties. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-21sparse: fix incorrect type warnings in hdata/fsp.cStewart Smith1-3/+3
commit 5c3e642911ed217bc476478694281a89fe8ef73c upstream No changes in resulting code as skiboot is BE, but does silence the sparse warnings. hdata/fsp.c:67:9: warning: incorrect type in initializer (different base types) hdata/fsp.c:67:9: expected unsigned int hdata/fsp.c:67:9: got restricted beint16_t const [usertype] hw_version hdata/fsp.c:68:9: warning: incorrect type in initializer (different base types) hdata/fsp.c:68:9: expected unsigned int hdata/fsp.c:68:9: got restricted beint16_t const [usertype] sw_version hdata/fsp.c:103:46: warning: incorrect type in argument 1 (different base types) hdata/fsp.c:103:46: expected unsigned int [unsigned] [usertype] proc_chip_id hdata/fsp.c:103:46: got restricted beint32_t const [usertype] proc_chip_id Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-21sparse: fix missing beXX_to_cpu() conversions in hdata/fsp.cStewart Smith1-5/+5
commit 7c2f38eff810fd2a84707ae15994e3188cfac834 upstream hdata/fsp.c:55:20: warning: restricted beint16_t degrades to integer hdata/fsp.c:62:27: warning: restricted beint16_t degrades to integer hdata/fsp.c:85:27: warning: restricted beint16_t degrades to integer hdata/fsp.c:85:27: warning: restricted beint16_t degrades to integer hdata/fsp.c:100:9: warning: cast from restricted beint64_t hdata/fsp.c:144:27: warning: restricted beint16_t degrades to integer doesn't do anything currently as skiboot is BE Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-21sparse: fix endian conversions in hdata/iohub.cStewart Smith1-7/+7
commit d6e3293cb1d794bf118aab334bb250ed12236956 upstream Since skiboot is all BE and hdat is BE, this changes nothing except for silencing the sparse warnings hdata/iohub.c:35:9: warning: incorrect type in initializer (different base types) hdata/iohub.c:35:9: expected unsigned int hdata/iohub.c:35:9: got restricted beint32_t const [usertype] buid_ext hdata/iohub.c:36:9: warning: incorrect type in argument 1 (different base types) hdata/iohub.c:36:9: expected unsigned int [unsigned] [usertype] proc_chip_id hdata/iohub.c:36:9: got restricted beint32_t const [usertype] proc_chip_id hdata/iohub.c:36:9: warning: incorrect type in argument 1 (different base types) hdata/iohub.c:36:9: expected unsigned int [unsigned] [usertype] proc_chip_id hdata/iohub.c:36:9: got restricted beint32_t const [usertype] proc_chip_id hdata/iohub.c:38:9: warning: incorrect type in initializer (different base types) hdata/iohub.c:38:9: expected unsigned int hdata/iohub.c:38:9: got restricted beint32_t const [usertype] gx_index hdata/iohub.c:39:9: warning: incorrect type in initializer (different base types) hdata/iohub.c:39:9: expected unsigned int hdata/iohub.c:39:9: got restricted beint32_t const [usertype] ec_level hdata/iohub.c:114:63: warning: incorrect type in argument 1 (different base types) hdata/iohub.c:114:63: expected unsigned short [unsigned] [usertype] slca_index hdata/iohub.c:114:63: got restricted beint16_t const [usertype] slca_index hdata/iohub.c:634:17: warning: incorrect type in argument 1 (different base types) hdata/iohub.c:634:17: expected restricted beint32_t [usertype] be_val hdata/iohub.c:634:17: got restricted beint16_t const [usertype] hub_num hdata/iohub.c:708:22: warning: incorrect type in assignment (different base types) hdata/iohub.c:708:22: expected unsigned int [unsigned] type hdata/iohub.c:708:22: got restricted beint32_t const [usertype] card_type Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-21sparse: fix conversion of hdat slca_indexStewart Smith1-1/+1
commit 020a741ae22dd70a027918dbb738cb16fed3bb57 upstream No code changes as skiboot is BE. hdata/vpd.c:559:38: warning: incorrect type in argument 1 (different base types) hdata/vpd.c:559:38: expected unsigned short [unsigned] [usertype] slca_index hdata/vpd.c:559:38: got restricted beint16_t const [usertype] slca_index Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-21sparse: fix beint32_t degrades to int in hdata/pcia.cStewart Smith1-1/+1
commit 54104305325788ec01695d4f58fb7379d8956a5d upstream hdata/pcia.c:32:37: warning: restricted beint32_t degrades to integer No resulting code change for skiboot as BE Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-21Fix endian flip in printf for FSP in hdata/fsp.cStewart Smith2-3/+4
commit dfab2fb87c2d83e240a002e8829b525d10342df3 upstream Harmless for skiboot as we're BE. When building and running unit tests on LE though, we got an incorrect hw/software version for FSP hardware/software for hdata_to_dt test. Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-21Revive hdata_to_dt and make it work againStewart Smith2-18/+3
commit 27b49826e5f1d9c0008c0a5bf0953dd673a9b9e1 upstream Some functions were stubbed out which meant we hit assert rather than dumping out the device tree Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-21Use VALGRIND callout rather than tricky malloc/memcpyStewart Smith1-3/+3
commit d04030556db4bb73151172ded3f279882e706dbd upstream The tricky memcpy trips up various static analysers and looks rather odd. The more correct thing to do is to ask valgrind to mark it as undefined. There's a call for that, and we depend on valgrind to run the test suite anyway, so we're not introducing a new dependency. Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-21Enable -Werror for -WformatStewart Smith6-16/+64
commit 56bc1890b229072513788992d1d29b6f173c13de upstream We create our own inttypes.h to get the correct printf formatting for 64bit numbers. Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-21Add hdata_to_dt testStewart Smith7-11/+8767
commit 6dc84bb65a3f51b97d2728a8fcdadacf8114293f upstream This adds ~1000 lines of code to the coverage-report. We manipulate the log levels of a few messages that contain pointers so that a basic diff of the hdata_to_dt output is possible. Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-15external/gard: Fix displaying 'cleared' gard recordsCyril Bur1-3/+33
When a garded component is replaced hostboot detects this and updates the gard partition. What hostboot does is set the record_id field to 0xFFFFFFFF but leaves the rest of the flash untouched, this has caused issues with the gard tool the thinking was that an entire record of all 0xFF bytes would signal not a valid record. This patch add rectifies this issue and `gard list` will no longer show any record with an id of 0xFFFFFFFF. Equivalent to 91cebdcd557dfc2dfc8050a34edb11a43facaf74 in master Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-14firestone: fix spacing in slot nameJeremy Kerr1-1/+1
The other SlotN names have no space. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> [stewart@linux.vnet.ibm.com: Cherry-picked to stable] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-12Add OPAL_CONSOLE_FLUSH to the OPAL APIRussell Currey6-23/+59
uart consoles only flush output when polled. The Linux kernel calls these pollers frequently, except when in a panic state. As such, panic messages are not fully printed unless the system is configured to reboot after panic. This patch adds a new call to the OPAL API to flush the buffer. If the system has a uart console (i.e. BMC machines), it will incrementally flush the buffer, returning if there is more to be flushed or not. If the system has a different console, the function will have no effect. This will allow the Linux kernel to ensure that panic message have been fully printed out. The existing synchronous flushing mechanism used in OPAL's shutdown and reboot routines has been refactored into a helper that repeatedly calls the new partial flush function. Signed-off-by: Russell Currey <ruscur@russell.cc> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-12-14external/opal-prd: Set initial size valueJeremy Kerr1-0/+1
We're not initialising 'size' in handle_prd_control_run_cmd. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-12-14external/common: Fix grammar in arch_flash error messageSamuel Mendoza-Jonas1-1/+1
Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-12-04Add skiboot-5.1.12 release notesskiboot-5.1.12Stewart Smith1-0/+44
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
generated by cgit v1.1 at 2024-09-08 13:19:28 +0000