| /linux-4.1.27/fs/btrfs/tests/ |
| H A D | extent-io-tests.c | 108 /* Test this scenario test_find_delalloc()
131 * Test this scenario test_find_delalloc()
167 * Test this scenario test_find_delalloc()
192 * Test this scenario test_find_delalloc()
|
| H A D | free-space-tests.c | 679 * Now test a similar scenario, but where our extent entry is located test_steal_space_from_bitmap_to_extent()
|
| /linux-4.1.27/kernel/time/ |
| H A D | tick-broadcast-hrtimer.c | 28 * run into the following live lock scenario: bc_set_mode()
|
| H A D | hrtimer.c | 535 * scenario: hrtimer_force_reprogram()
|
| /linux-4.1.27/lib/raid6/test/ |
| H A D | test.c | 71 /* We don't implement the DQ failure scenario, since it's test_disks()
|
| /linux-4.1.27/arch/arc/kernel/ |
| H A D | irq.c | 200 * Another twist is prev scenario with flow being
223 * theory, it can also cause the dreaded L1-L2-L1 scenario arch_local_irq_enable()
238 * re-enabling both may cause whaco L1-L2-L1 scenario arch_local_irq_enable()
|
| H A D | entry.S | 31 * -In a rare scenario, Process gets a Priv-V exception and gets scheduled
35 * Instr Error could also cause similar scenario, so same there as well.
|
| /linux-4.1.27/arch/arm/probes/kprobes/ |
| H A D | test-core.c | 1074 static unsigned long test_context_cpsr(int scenario) test_context_cpsr() argument
1081 cpsr = (scenario & 0xf) << 28; /* N,Z,C,V flags */ test_context_cpsr()
1082 cpsr |= (scenario & 0xf) << 16; /* GE flags */ test_context_cpsr()
1083 cpsr |= (scenario & 0x1) << 27; /* Toggle Q flag */ test_context_cpsr()
1090 if (scenario == 15) test_context_cpsr()
1100 if (scenario == 15) test_context_cpsr()
1105 unsigned x = (scenario >> 4); test_context_cpsr()
1113 if ((scenario & 0xf) == 0xf) test_context_cpsr()
1128 switch (scenario) { test_context_cpsr()
1152 int scenario = test_case_run_count>>1; setup_test_context() local
1161 val = (scenario & 1) ? VALM : ~VALM; setup_test_context()
1171 val = (scenario & 2) ? VALR : ~VALR; setup_test_context()
1176 regs->ARM_cpsr |= test_context_cpsr(scenario); setup_test_context()
|
| /linux-4.1.27/arch/sh/mm/ |
| H A D | mmap.c | 130 * so fall back to the bottom-up function here. This scenario arch_get_unmapped_area_topdown()
|
| /linux-4.1.27/arch/x86/include/asm/ |
| H A D | i387.h | 94 * However, even in that very unlikely scenario,
|
| /linux-4.1.27/arch/powerpc/oprofile/cell/ |
| H A D | pr_util.h | 60 * example, for an overlay scenario with one overlay segment
|
| H A D | vma_map.c | 261 * example, for an overlay scenario with one overlay segment create_vma_map()
|
| /linux-4.1.27/include/linux/ |
| H A D | lz4.h | 17 * Provides the maximum size that LZ4 may output in a "worst case" scenario
|
| H A D | hrtimer.h | 73 * to preserve the HRTIMER_STATE_CALLBACK in the above scenario. This
|
| /linux-4.1.27/arch/x86/mm/ |
| H A D | hugetlbpage.c | 109 * so fall back to the bottom-up function here. This scenario hugetlb_get_unmapped_area_topdown()
|
| /linux-4.1.27/arch/sparc/mm/ |
| H A D | hugetlbpage.c | 77 * so fall back to the bottom-up function here. This scenario hugetlb_get_unmapped_area_topdown()
|
| /linux-4.1.27/arch/mips/mm/ |
| H A D | mmap.c | 114 * so fall back to the bottom-up function here. This scenario arch_get_unmapped_area_common()
|
| /linux-4.1.27/arch/arm/mm/ |
| H A D | mmap.c | 157 * so fall back to the bottom-up function here. This scenario arch_get_unmapped_area_topdown()
|
| /linux-4.1.27/arch/arm/kvm/ |
| H A D | init.S | 34 * The init scenario is:
|
| /linux-4.1.27/drivers/gpu/drm/i915/ |
| H A D | i915_vgpu.c | 147 * To give an example, the drawing below depicts one typical scenario after
|
| H A D | intel_fbc.c | 633 * In the scenario that we go from a valid to invalid intel_fbc_update()
|
| H A D | intel_dp.c | 5261 * dynamically, based on the usage scenario. This feature is applicable
5269 * (may appear as a blink on screen) and is used in dock-undock scenario.
5289 * the scenario of video playback wherein RR is set based on the rate
|
| /linux-4.1.27/drivers/clocksource/ |
| H A D | fsl_ftm_timer.c | 133 * the following scenario: ftm_set_next_event()
|
| /linux-4.1.27/arch/x86/kernel/ |
| H A D | sys_x86_64.c | 211 * so fall back to the bottom-up function here. This scenario arch_get_unmapped_area_topdown()
|
| /linux-4.1.27/drivers/video/fbdev/via/ |
| H A D | via_clock.c | 361 * The only known stable scenario is to leave this bits as-is, via_clock_init()
|
| /linux-4.1.27/include/net/irda/ |
| H A D | irttp.h | 47 /* Worst case scenario, two window of data - Jean II */
|
| /linux-4.1.27/arch/s390/mm/ |
| H A D | mmap.c | 165 * so fall back to the bottom-up function here. This scenario arch_get_unmapped_area_topdown()
|
| /linux-4.1.27/arch/m68k/include/asm/ |
| H A D | mac_psc.h | 23 * continuously, although how you keep the buffer filled in this scenario is
|
| /linux-4.1.27/kernel/sched/ |
| H A D | cpupri.c | 21 * worst case complexity of O(min(102, nr_domcpus)), though the scenario that
|
| /linux-4.1.27/tools/perf/tests/ |
| H A D | dso-data.c | 307 * Test scenario: test__dso_data_reopen()
|
| /linux-4.1.27/drivers/lguest/ |
| H A D | hypercalls.c | 243 * a similar scenario might one day bite us, so it's worth mentioning.
|
| /linux-4.1.27/drivers/net/usb/ |
| H A D | cdc_subset.c | 58 * better approach. Handling the "other end unplugs/replugs" scenario
|
| /linux-4.1.27/drivers/net/ethernet/ti/ |
| H A D | davinci_mdio.c | 47 * scenario in practice.
|
| /linux-4.1.27/drivers/scsi/bfa/ |
| H A D | bfa_ioc_cb.c | 331 * or in MEMTEST states. In a normal scenario, this IOC bfa_ioc_cb_sync_complete()
|
| /linux-4.1.27/drivers/pci/ |
| H A D | slot.c | 237 * the slot. In this scenario, the caller may pass -1 for @slot_nr.
|
| /linux-4.1.27/drivers/net/wireless/ath/wil6210/ |
| H A D | rx_reorder.c | 131 * Another scenario, Rx get delayed and we got packet from before
|
| /linux-4.1.27/drivers/cpufreq/ |
| H A D | cpufreq_governor.c | 133 * rate) indicates this scenario. dbs_check_cpu()
|
| /linux-4.1.27/arch/tile/mm/ |
| H A D | hugetlbpage.c | 203 * so fall back to the bottom-up function here. This scenario hugetlb_get_unmapped_area_topdown()
|
| /linux-4.1.27/arch/parisc/kernel/ |
| H A D | sys_parisc.c | 197 * so fall back to the bottom-up function here. This scenario arch_get_unmapped_area_topdown()
|
| /linux-4.1.27/fs/ext4/ |
| H A D | ext4_extents.h | 147 * unwritten extent with only one special scenario when ee_len = 0x8000.
|
| /linux-4.1.27/mm/ |
| H A D | cleancache.c | 60 * handle such a scenario, here we call ->init_fs or ->init_shared_fs cleancache_register_ops()
|
| H A D | frontswap.c | 94 * OK. The other scenario where calls to frontswap_store (called via inc_frontswap_invalidates()
|
| H A D | gup.c | 525 * This is meant to be called in the specific scenario where for locking reasons
|
| H A D | filemap.c | 1429 * a _large_ part of the i/o request. Imagine the worst scenario:
|
| H A D | mmap.c | 1980 * so fall back to the bottom-up function here. This scenario arch_get_unmapped_area_topdown()
|
| /linux-4.1.27/drivers/media/platform/s5p-tv/ |
| H A D | mixer_reg.c | 100 * because typical usage scenario would be mxr_reg_reset()
|
| /linux-4.1.27/drivers/media/usb/cx231xx/ |
| H A D | cx231xx-pcb-cfg.c | 787 "scenario %d\n", initialize_cx231xx()
|
| /linux-4.1.27/drivers/staging/unisys/visorchipset/ |
| H A D | visorchipset_main.c | 123 /* The following globals are used to handle the scenario where we are unable to
125 * this scenario, we simply stash the controlvm message, then attempt to
1646 * scenario where this can occur is when we need to throttle
1823 /* this is a scenario where throttling controlvm_periodic_work()
|
| /linux-4.1.27/drivers/gpu/drm/ |
| H A D | drm_modeset_lock.c | 416 * deadlock scenario has been detected and it is an error to attempt
|
| /linux-4.1.27/arch/sparc/kernel/ |
| H A D | sys_sparc_64.c | 198 * so fall back to the bottom-up function here. This scenario arch_get_unmapped_area_topdown()
|
| /linux-4.1.27/drivers/usb/gadget/udc/bdc/ |
| H A D | bdc_core.c | 341 * called from disconnect/bus reset scenario's, to ensure proper HW cleanup
|
| /linux-4.1.27/fs/xfs/ |
| H A D | xfs_filestream.c | 69 * With a shrinkfs feature, the above scenario could panic the system.
|
| H A D | xfs_log.c | 3554 * The commit-rec is smaller than padding in this scenario and so it is xfs_log_calc_unit_res()
|
| /linux-4.1.27/kernel/ |
| H A D | pid.c | 18 * allocation scenario when all but one out of 1 million PIDs possible are
|
| H A D | cpuset.c | 1973 * users who wish to allow that scenario, then this could be cpuset_css_online()
|
| /linux-4.1.27/include/linux/mfd/ |
| H A D | si476x-core.h | 71 * active for polling use scenario) and device is turned on with
|
| /linux-4.1.27/kernel/rcu/ |
| H A D | srcu.c | 242 * in the interim. But the missed-increment scenario laid out srcu_readers_active_idx_check()
245 * scenario occurs, the return values from the two calls to srcu_readers_active_idx_check()
|
| H A D | rcutorture.c | 1617 * The scenario that leads to this happening is that the rcu_torture_err_cb()
|
| /linux-4.1.27/kernel/locking/ |
| H A D | lockdep.c | 18 * Bugs are reported even if the current locking scenario does not cause
1116 * is the deadlock scenario, as it is obvious that the print_circular_lock_scenario()
1136 printk(" Possible unsafe locking scenario:\n\n"); print_circular_lock_scenario()
1451 * is the deadlock scenario, as it is obvious that the print_irq_lock_scenario()
1471 printk(" Possible interrupt unsafe locking scenario:\n\n"); print_irq_lock_scenario()
1716 printk(" Possible unsafe locking scenario:\n\n"); print_deadlock_scenario()
2220 printk(" Possible unsafe locking scenario:\n\n"); print_usage_bug_scenario()
|
| /linux-4.1.27/drivers/net/wireless/iwlwifi/mvm/ |
| H A D | fw-api.h | 1417 /* Smart Fifo possible scenario */
1469 * @long_delay_timeouts: aging and idle timer values for each scenario
1471 * @full_on_timeouts: timer values for each scenario in full on state.
|
| /linux-4.1.27/arch/powerpc/mm/ |
| H A D | slice.c | 350 * so fall back to the bottom-up function here. This scenario slice_find_area_topdown()
|
| /linux-4.1.27/arch/arc/mm/ |
| H A D | cache_arc700.c | 564 * it still needs to handle a 2 page scenario, where the range flush_icache_range()
|
| /linux-4.1.27/net/bluetooth/ |
| H A D | hci_request.c | 316 * In this kind of scenario skip the update and let the random set_random_addr()
|
| H A D | hci_conn.c | 327 /* FIXME: It was observed that in pairing failed scenario, refcnt hci_conn_timeout()
|
| /linux-4.1.27/drivers/tty/hvc/ |
| H A D | hvcs.c | 1016 * EBUSY is the most likely scenario though the vty could have been hvcs_partner_connect()
1287 * scenario. */ hvcs_hangup()
|
| /linux-4.1.27/fs/ubifs/ |
| H A D | recovery.c | 736 * cut happened. I do not know how realistic is this scenario ubifs_recover_leb()
1362 * very cumbersome for a scenario that is quite unlikely and the only negative
|
| /linux-4.1.27/drivers/iommu/ |
| H A D | fsl_pamu.c | 29 /* define indexes for each operation mapping scenario */
|
| H A D | amd_iommu.c | 773 * In this scenario, the bit will be set, and disable amd_iommu_int_thread()
|
| /linux-4.1.27/drivers/media/v4l2-core/ |
| H A D | v4l2-dev.c | 478 * the worst case scenario is that there are VIDEO_NUM_DEVICES - 1 slots in
|
| /linux-4.1.27/drivers/staging/media/omap4iss/ |
| H A D | iss.c | 827 * scenario. We'll call it here to avoid race conditions. omap4iss_module_sync_idle()
|
| /linux-4.1.27/drivers/net/wireless/zd1211rw/ |
| H A D | zd_chip.c | 351 if (value & (1 << 24)) { /* LED scenario */ read_pod()
|
| /linux-4.1.27/drivers/gpu/drm/exynos/ |
| H A D | exynos_mixer.c | 659 * because typical usage scenario would be mixer_win_reset()
|
| /linux-4.1.27/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ |
| H A D | ramgt215.c | 657 /* There's 4 scenario's gt215_ram_calc()
|
| /linux-4.1.27/drivers/block/ |
| H A D | umem.c | 753 * Note no locks taken out here. In a worst case scenario, we could drop
|
| H A D | cciss.c | 4230 /* Limit commands in memory limited kdump scenario. */ cciss_get_max_perf_mode_cmds()
|
| /linux-4.1.27/drivers/bus/ |
| H A D | arm-ccn.c | 527 * as in the worst case scenario (an event every cycle), with 1GHz
|
| /linux-4.1.27/drivers/gpu/drm/radeon/ |
| H A D | radeon_fence.c | 203 /* Note there is a scenario here for an infinite loop but it's radeon_fence_activity()
|
| /linux-4.1.27/drivers/hwmon/ |
| H A D | abituguru3.c | 105 * Worst case scenario 16 in sensors (longest names_length) and the rest
|
| H A D | abituguru.c | 1563 * scenario but some will hold 0x00. abituguru_detect()
|
| /linux-4.1.27/drivers/usb/dwc3/ |
| H A D | ep0.c | 189 * Because of this scenario, SNPS decided to change the programming __dwc3_gadget_ep0_queue()
|
| H A D | gadget.c | 403 * programming model in this scenario can cause errors. For two
407 * and SET_INTERFACE (8.1.5). This is incorrect in the scenario of
|
| /linux-4.1.27/fs/xfs/libxfs/ |
| H A D | xfs_trans_resv.c | 118 * The 'modify' param indicates to include the record modification scenario. The
|
| H A D | xfs_bmap.c | 84 * for both ATTR1 and ATTR2 we have to assume the worst case scenario xfs_bmap_compute_maxlevels()
5567 * in this scenario. Check anyways and warn if we xfs_bmse_shift_one()
|
| /linux-4.1.27/lib/ |
| H A D | locking-selftest.c | 782 * Deadlock scenario:
|
| /linux-4.1.27/net/sctp/ |
| H A D | output.c | 571 /* Considering the multiple CPU scenario, this is a sctp_packet_transmit()
|
| H A D | sm_statefuns.c | 1300 * scenario.
|
| /linux-4.1.27/drivers/scsi/fcoe/ |
| H A D | fcoe.c | 1333 * This scenario occurs when the module is being removed fcoe_percpu_thread_destroy()
1349 * This a non-SMP scenario where the singular Rx thread is fcoe_percpu_thread_destroy()
|
| /linux-4.1.27/drivers/hwtracing/coresight/ |
| H A D | coresight-etm3x.c | 410 * with tracing being left on (crash scenario) if user disable occurs etm_disable()
|
| /linux-4.1.27/drivers/mmc/host/ |
| H A D | mmc_spi.c | 97 * card's password" scenario); it's mostly applied to STOP_TRANSMISSION after
|
| /linux-4.1.27/drivers/media/platform/omap3isp/ |
| H A D | ispvideo.c | 562 * This function is intended to be used on suspend/resume scenario. It
|
| H A D | isp.c | 1389 * scenario. We'll call it here to avoid race conditions. omap3isp_module_sync_idle()
|
| H A D | ispccdc.c | 331 * ccdc_lsc_error_handler - Handle LSC prefetch error scenario.
|
| /linux-4.1.27/drivers/net/wireless/iwlwifi/dvm/ |
| H A D | sta.c | 830 * scenario the RXON flags will be updated to indicate we are not
|
| /linux-4.1.27/drivers/input/mouse/ |
| H A D | psmouse-base.c | 1300 * do not handle scenario when mouse "upgrades" its protocol while psmouse_resync()
|
| H A D | cyapa_gen5.c | 2555 * This issue has the scenario is that, cyapa_gen5_irq_cmd_handler()
|
| /linux-4.1.27/arch/tile/kernel/ |
| H A D | setup.c | 598 * particularly interesting scenario, so we just keep it simple and
|
| /linux-4.1.27/arch/mn10300/kernel/ |
| H A D | gdb-stub.c | 74 * going. In this scenario the host machine was a PC and the
|
| /linux-4.1.27/drivers/md/ |
| H A D | dm-crypt.c | 967 * In order to avoid this scenario we allocate the pages under a mutex.
|
| H A D | raid5.c | 6936 * could be lost. Consider a scenario: discard a stripe rdev_for_each()
|
| /linux-4.1.27/drivers/scsi/libfc/ |
| H A D | fc_lport.c | 30 * having an lport reset just before we send a frame. In that scenario the
|
| /linux-4.1.27/drivers/rtc/ |
| H A D | rtc-ds1685.c | 720 * catch this scenario. ds1685_rtc_work_queue()
|
| /linux-4.1.27/drivers/staging/lustre/lustre/obdclass/ |
| H A D | lu_object.c | 1824 * There exists a potential lock inversion deadlock scenario when using
|
| /linux-4.1.27/drivers/net/ethernet/broadcom/bnx2x/ |
| H A D | bnx2x_dcb.c | 1022 /* need HW lock to avoid scenario of two drivers bnx2x_dcbx_init()
|
| H A D | bnx2x_ethtool.c | 1167 * attempt to access nvram at the same time, we could run into a scenario such
|
| H A D | bnx2x_main.c | 7079 * as "scan-off". Real-life scenario for example: if a driver is being bnx2x_init_hw_common()
10515 * but hasn't loaded yet, therefore creating a scenario of bnx2x_prev_unload_common()
|
| /linux-4.1.27/drivers/net/ethernet/chelsio/cxgb/ |
| H A D | sge.c | 250 * the application is migrated to another CPU. In that scenario, we try to
|
| /linux-4.1.27/arch/x86/kernel/cpu/ |
| H A D | perf_event.c | 229 * fail. The tools will also become useless in this scenario. check_hw_exists()
|
| /linux-4.1.27/drivers/acpi/ |
| H A D | scan.c | 236 * to be careful. The usage scenario for this kind of relationship is that all
|
| /linux-4.1.27/drivers/tty/vt/ |
| H A D | keyboard.c | 1090 * need to handle the scenario when keyboard handler is not
|
| /linux-4.1.27/fs/nfs/ |
| H A D | inode.c | 1620 * A very similar scenario holds for the dir cache.
|
| /linux-4.1.27/drivers/power/ |
| H A D | charger-manager.c | 1362 * scenario or hardware restrictions, the user enter 1 or 0(zero) to '/sys/
|
| /linux-4.1.27/arch/frv/kernel/ |
| H A D | gdb-stub.c | 69 * going. In this scenario the host machine was a PC and the
|
| /linux-4.1.27/net/mac80211/ |
| H A D | ieee80211_i.h | 1906 * We might already be suspended if the following scenario occurs: ieee80211_can_run_worker()
|
| H A D | tx.c | 923 * This scenario is handled in ieee80211_tx_prepare but extra ieee80211_tx_h_fragment()
|
| H A D | util.c | 2044 * them in a hardware restart scenario is not easily done ieee80211_reconfig()
|
| /linux-4.1.27/kernel/irq/ |
| H A D | manage.c | 734 * the following scenario: irq_finalize_oneshot()
|
| /linux-4.1.27/drivers/video/fbdev/omap2/dss/ |
| H A D | dsi.c | 3398 * exit HS mode. Hence, this is the scenario where the least amount of command
3430 * Hence, this is the scenario where the least amount of command mode data can
|
| /linux-4.1.27/drivers/net/ethernet/ibm/emac/ |
| H A D | core.c | 676 Here is the worst case scenario for the RX FIFO "headroom" emac_configure()
|
| /linux-4.1.27/drivers/net/ethernet/intel/ |
| H A D | e100.c | 123 * scenario where all Rx resources have been indicated and none re-
|
| /linux-4.1.27/drivers/net/wireless/ath/ath5k/ |
| H A D | base.c | 1845 * the Sectored AP scenario, switch antenna every ath5k_beacon_setup()
|
| /linux-4.1.27/drivers/net/wireless/ath/ath6kl/ |
| H A D | cfg80211.c | 2563 * In the current scenario, WOW resume should happen before start processing
|
| /linux-4.1.27/drivers/net/wireless/hostap/ |
| H A D | hostap_ap.c | 2782 * ports of the bridge. Since this is a valid scenario, do not hostap_handle_sta_tx()
|
| /linux-4.1.27/drivers/dma/ |
| H A D | pl330.c | 244 * For typical scenario, at 1word/burst, 10MB and 20MB xfers per req
|
| /linux-4.1.27/arch/x86/kernel/apic/ |
| H A D | io_apic.c | 1912 * To prevent this scenario we read the Remote IRR bit ioapic_irqd_unmask()
|
| /linux-4.1.27/drivers/usb/musb/ |
| H A D | musb_host.c | 2042 * speed scenario as NAK interrupts are not coming from a musb_schedule()
|
| /linux-4.1.27/fs/ |
| H A D | namespace.c | 516 * MNT_WRITE_HOLD protects against this scenario, because mnt_make_readonly()
|
| /linux-4.1.27/arch/x86/kvm/ |
| H A D | x86.c | 5555 * change creates an intractable locking scenario; the order kvmclock_cpufreq_notifier()
7240 * uniform across all VCPUs (not to mention the scenario is extremely
|
| /linux-4.1.27/drivers/usb/host/ |
| H A D | xhci.c | 2154 * scenario for any one interval. The hardware dynamically schedules the
2159 * case scenario. Instead, we come up with an estimate that is no less than
|
| /linux-4.1.27/drivers/scsi/qla4xxx/ |
| H A D | ql4_os.c | 4726 * Issue a force soft reset to workaround this scenario. qla4xxx_soft_reset()
9375 * scenario or from some application like sg_reset
|
| /linux-4.1.27/drivers/staging/wlan-ng/ |
| H A D | hfa384x_usb.c | 1277 * This scenario is so unlikely that I'm hfa384x_usbctlx_complete_sync()
|
| /linux-4.1.27/drivers/staging/lustre/lustre/include/ |
| H A D | cl_object.h | 1506 * top-to-bottom or bottom-to-top) captures this scenario, so try-locking has
|
| /linux-4.1.27/drivers/net/wireless/brcm80211/brcmfmac/ |
| H A D | cfg80211.c | 2481 * scenario, driver will be storing the power save brcmf_cfg80211_set_power_mgmt()
|
| /linux-4.1.27/drivers/net/wireless/iwlegacy/ |
| H A D | common.c | 2381 * scenario the RXON flags will be updated to indicate we are not
|
| /linux-4.1.27/drivers/ata/ |
| H A D | libata-scsi.c | 3943 * this particular deadlock scenario. ata_scsi_hotplug()
|
| /linux-4.1.27/fs/ocfs2/ |
| H A D | dir.c | 2874 * Prepare for worst case allocation scenario of two separate ocfs2_expand_inline_dir()
|
| /linux-4.1.27/drivers/media/dvb-frontends/ |
| H A D | drxk_hard.c | 6081 * worst case scenario init_drxk()
|
| /linux-4.1.27/fs/btrfs/ |
| H A D | extent_io.c | 3020 * belonging to the 2nd range. Imagine the following scenario: __do_readpage()
|
| /linux-4.1.27/drivers/net/ethernet/intel/e1000e/ |
| H A D | ich8lan.c | 3953 * the checksum...a likely scenario. e1000_validate_nvm_checksum_ich8lan()
|
| /linux-4.1.27/drivers/net/wireless/ti/wlcore/ |
| H A D | main.c | 2844 * Currently the only valid scenario for JOIN during association wlcore_join()
|
| /linux-4.1.27/drivers/net/ethernet/intel/ixgbe/ |
| H A D | ixgbe_main.c | 4739 * We are assuming the worst case scenario here, and that ixgbe_sfp_link_config()
|
| /linux-4.1.27/drivers/message/fusion/ |
| H A D | mptbase.c | 2520 * recursive scenario; GetLanConfigPages times out, timer expired mpt_do_ioc_recovery()
|
| /linux-4.1.27/drivers/scsi/ |
| H A D | hpsa.c | 6102 /* Limit commands in memory limited kdump scenario. */ hpsa_get_max_perf_mode_cmds()
|
| /linux-4.1.27/drivers/scsi/aic7xxx/ |
| H A D | aic79xx_core.c | 2758 * scenario. After this first LQIRETRY, the LQI ahd_handle_transmission_error()
|
| /linux-4.1.27/drivers/staging/rtl8723au/hal/ |
| H A D | rtl8723a_bt-coexist.c | 4005 When in a transmitter test scenario and the frames/bursts count have been bthci_CmdAMPTestCommand()
|