155 		 * to clear frozen PE during PCI config access.  in pnv_eeh_enable_phbs()
394 	 * the PE becomes frozen for the first time and the flag has  in pnv_eeh_probe()
546 	 * Check PHB state. If the PHB is frozen for the  in pnv_eeh_get_phb_state()
574 	 * We don't clobber hardware frozen state until PE  in pnv_eeh_get_pe_state()
646 	 * If the PE is switching to frozen state for the  in pnv_eeh_get_pe_state()
1047 	 * frozen state during PE reset. However, the good idea here from  in pnv_eeh_reset()
1048 	 * benh is to keep frozen state before we get PE reset done completely  in pnv_eeh_reset()
1049 	 * (until BAR restore). With the frozen state, HW drops illegal IO  in pnv_eeh_reset()
1050 	 * or MMIO access, which can incur recursive frozen PE during PE  in pnv_eeh_reset()
1051 	 * reset. The side effect is that EEH core has to clear the frozen  in pnv_eeh_reset()
1058 	 * The frozen PE might be caused by PAPR error injection  in pnv_eeh_reset()
1060 	 * frozen PE as stated in the hardware spec. Unfortunately,  in pnv_eeh_reset()
1371 	 * have been frozen. However, we still need poke until  in pnv_eeh_get_pe()
1372 	 * hitting the frozen PE on top level.  in pnv_eeh_get_pe()
1383 		/* Frozen parent PE */  in pnv_eeh_get_pe()
1403  * fenced PHB and frozen PE should be handled by EEH core eventually.
1526 				pr_err("EEH: Frozen PE#%x "  in pnv_eeh_next_error()
1545 		 * frozen PE. In the time for frozen PE, EEH core  in pnv_eeh_next_error()
1562 		 * We probably have the frozen parent PE out there and  in pnv_eeh_next_error()
1563 		 * we need have to handle frozen parent PE firstly.  in pnv_eeh_next_error()
1572 				/* Frozen parent PE ? */  in pnv_eeh_next_error()
1664 	 * P7IOC blocks PCI config access to frozen PE, but PHB3  in eeh_powernv_init()