/linux/drivers/crypto/cavium/cpt/ |
H A D | cptvf_mbox.c | 96 dev_err(&pdev->dev, "PF didn't respond to READY msg\n"); in cptvf_check_pf_ready() 115 dev_err(&pdev->dev, "PF didn't respond to vq_size msg\n"); in cptvf_send_vq_size_msg() 134 dev_err(&pdev->dev, "PF didn't respond to vf_type msg\n"); in cptvf_send_vf_to_grp_msg() 153 dev_err(&pdev->dev, "PF didn't respond to vf_type msg\n"); in cptvf_send_vf_priority_msg() 169 dev_err(&pdev->dev, "PF didn't respond to UP msg\n"); in cptvf_send_vf_up() 186 dev_err(&pdev->dev, "PF didn't respond to DOWN msg\n"); in cptvf_send_vf_down()
|
/linux/include/linux/ |
H A D | pmbus.h | 21 * Some PMBus chips respond with valid data when trying to read an unsupported 40 * Some PMBus chips don't respond with valid data when reading the CAPABILITY 62 * Some PMBus chips respond with invalid data when reading the WRITE_PROTECT
|
/linux/arch/sparc/kernel/ |
H A D | pci_sabre.c | 140 #define SABRE_PCITASR_EF 0x0000000000000080UL /* Respond to 0xe0000000-0xffffffff */ 141 #define SABRE_PCITASR_CD 0x0000000000000040UL /* Respond to 0xc0000000-0xdfffffff */ 142 #define SABRE_PCITASR_AB 0x0000000000000020UL /* Respond to 0xa0000000-0xbfffffff */ 143 #define SABRE_PCITASR_89 0x0000000000000010UL /* Respond to 0x80000000-0x9fffffff */ 144 #define SABRE_PCITASR_67 0x0000000000000008UL /* Respond to 0x60000000-0x7fffffff */ 145 #define SABRE_PCITASR_45 0x0000000000000004UL /* Respond to 0x40000000-0x5fffffff */ 146 #define SABRE_PCITASR_23 0x0000000000000002UL /* Respond to 0x20000000-0x3fffffff */ 147 #define SABRE_PCITASR_01 0x0000000000000001UL /* Respond to 0x00000000-0x1fffffff */
|
/linux/drivers/char/tpm/ |
H A D | tpm_ibmvtpm.h | 52 #define INIT_CRQ_RES 0x01 /* Init respond */ 53 #define INIT_CRQ_COMP_RES 0x02 /* Init complete respond */
|
/linux/net/netlabel/ |
H A D | netlabel_mgmt.h | 64 * The kernel should respond with a series of the following messages. 141 * NLM_F_DUMP flag should be set. The kernel should respond with a series of 151 * kernel to respond to an VERSION request.
|
/linux/drivers/infiniband/hw/qib/ |
H A D | qib_qsfp.c | 81 * Module could take up to 2 Msec to respond to MOD_SEL, and there in qsfp_read() 123 * ready to respond to MOD_SEL negation, and there is no way in qsfp_read() 131 * Module could take up to 2 Msec to respond to MOD_SEL in qsfp_read() 190 * Module could take up to 2 Msec to respond to MOD_SEL, in qib_qsfp_write() 228 * ready to respond to MOD_SEL negation, and there is no way in qib_qsfp_write() 235 * Module could take up to 2 Msec to respond to MOD_SEL in qib_qsfp_write()
|
/linux/drivers/misc/ibmasm/ |
H A D | heartbeat.c | 22 * to the driver. The driver must respond to the heartbeats or else the OS 25 * continues to respond to heartbeats, making the service processor believe
|
/linux/Documentation/process/ |
H A D | 6.Followthrough.rst | 44 impulse to respond in kind. Code review is about the code, not about 66 that the reviewer is asking you to fix. And respond back to the reviewer: 184 respond to these reports is a matter of basic pride in your work. If that 216 really only one way to respond: be pleased that your problem got solved and
|
/linux/drivers/input/joystick/iforce/ |
H A D | iforce-main.c | 279 dev_warn(&iforce->dev->dev, "Device does not respond to id packet M\n"); in iforce_init_device() 284 dev_warn(&iforce->dev->dev, "Device does not respond to id packet P\n"); in iforce_init_device() 289 dev_warn(&iforce->dev->dev, "Device does not respond to id packet B\n"); in iforce_init_device() 294 dev_warn(&iforce->dev->dev, "Device does not respond to id packet N\n"); in iforce_init_device()
|
/linux/Documentation/i2c/ |
H A D | slave-testunit-backend.rst | 137 Partial command. This test will respond to a block process call as defined by 170 128 bytes. However, it will only respond if the read message is connected to 230 If the host does not respond to the alert within 1 second, the test will be
|
/linux/drivers/usb/gadget/function/ |
H A D | f_hid.c | 29 * userspace half that time to respond before we return an empty report. 600 * i.e. give userspace time to respond in get_report_workqueue_handler() 621 /* Search again for report ID in list and respond to GET_REPORT request */ in get_report_workqueue_handler() 888 goto respond; in hidg_setup() 896 goto respond; in hidg_setup() 906 goto respond; in hidg_setup() 921 goto respond; in hidg_setup() 931 goto respond; in hidg_setup() 949 goto respond; in hidg_setup() 957 goto respond; in hidg_setup() [all …]
|
/linux/drivers/scsi/bfa/ |
H A D | bfa_hw_ct.c | 61 * Actions to respond RME Interrupt for Catapult ASIC: 79 * Actions to respond RME Interrupt for Catapult2 ASIC:
|
/linux/drivers/net/wwan/iosm/ |
H A D | iosm_ipc_mux_codec.h | 266 * ipc_mux_dl_acb_send_cmds - Respond to the Command blocks. 274 * @respond: If true return transaction ID 280 size_t res_size, bool blocking, bool respond);
|
/linux/drivers/w1/slaves/ |
H A D | w1_ds2413.c | 62 /* slave didn't respond, try to select it again */ in state_read() 63 dev_warn(&sl->dev, "slave device did not respond to PIO_ACCESS_READ, " \ in state_read()
|
/linux/drivers/platform/chrome/ |
H A D | cros_ec_spi.c | 24 * about 400-500us for the EC to respond there is not a lot of 25 * point in tuning this. If the EC could respond faster then 34 * Allow for a long time for the EC to respond. We support i2c 226 dev_warn(ec_dev->dev, "EC failed to respond in time\n"); in cros_ec_spi_receive_packet() 334 dev_warn(ec_dev->dev, "EC failed to respond in time\n"); in cros_ec_spi_receive_response() 444 * itself, it can't respond to any commands and instead in do_cros_ec_pkt_xfer_spi()
|
/linux/net/dccp/ |
H A D | input.c | 52 * - RESPOND (already handled by dccp_check_req) in dccp_rcv_close() 327 * or (S.state == RESPOND and P.type == Data), in __dccp_rcv_established() 592 * S.state = RESPOND in dccp_rcv_state_process() 596 * Cookies Continue with S.state == RESPOND in dccp_rcv_state_process() 636 * or (S.state == RESPOND and P.type == Data), in dccp_rcv_state_process()
|
H A D | minisocks.c | 134 * Process an incoming packet for RESPOND sockets represented 246 DCCP_BUG("DCCP-ACK packets are never sent in LISTEN/RESPOND state"); in dccp_reqsk_send_ack()
|
/linux/Documentation/ABI/testing/ |
H A D | sysfs-bus-fsi-devices-sbefifo | 6 timeout; i.e. the SBE did not respond within the time allotted
|
/linux/Documentation/devicetree/bindings/rtc/ |
H A D | isil,isl12026.txt | 4 registers respond at bus address 0x6f, and the EEPROM array responds
|
/linux/Documentation/scsi/ |
H A D | BusLogic.rst | 306 respond to synchronous transfer negotiation for UltraSCSI speed. AutoSCSI 324 The BT-948/958/958D will not respond to any of the ISA compatible I/O ports 325 that previous BusLogic SCSI Host Adapters respond to. This driver supports 375 UltraSCSI operation, or where existing SCSI devices do not properly respond 500 respond correctly when Logical Units above 0 are addressed.
|
/linux/drivers/platform/chrome/wilco_ec/ |
H A D | mailbox.c | 135 /* For some commands (eg shutdown) the EC will not respond, that's OK */ in wilco_ec_transfer() 137 dev_dbg(ec->dev, "EC does not respond to this command\n"); in wilco_ec_transfer()
|
/linux/Documentation/maintainer/ |
H A D | feature-and-driver-maintainers.rst | 34 reviewers should try to respond quicker than what is the usual patch 81 Maintainers furthermore should respond to reports about other kinds of
|
/linux/net/tipc/ |
H A D | discover.c | 210 bool respond = false; in tipc_disc_rcv() local 251 &maddr, &respond, &dupl_addr); in tipc_disc_rcv() 254 if (!respond) in tipc_disc_rcv()
|
/linux/Documentation/devicetree/bindings/i2c/ |
H A D | hpe,gxp-i2c.yaml | 34 arm and respond to interrupts from its engine. Each bit in the
|
/linux/net/netfilter/ |
H A D | nf_conntrack_proto_dccp.c | 34 * - RESPOND: 38 * It MAY also leave the RESPOND state for CLOSED after a timeout of 76 [CT_DCCP_RESPOND] = "RESPOND", 111 * RESPOND: Response from server seen, waiting for Ack from client 120 * Some states exist only on one side of the connection: REQUEST, RESPOND,
|