| /Linux-v5.10/drivers/crypto/cavium/cpt/ |
| 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-v5.10/drivers/usb/misc/ |
| D | ftdi-elan.c | 152 struct u132_respond respond[RESPOND_SIZE]; member
331 struct u132_respond *respond = &ftdi->respond[RESPOND_MASK & in ftdi_elan_abandon_completions() local
333 *respond->result = -ESHUTDOWN; in ftdi_elan_abandon_completions()
334 *respond->value = 0; in ftdi_elan_abandon_completions()
335 complete(&respond->wait_completion); in ftdi_elan_abandon_completions()
502 dev_err(&ftdi->udev->dev, "respond error %d\n", retval); in ftdi_elan_respond_work()
1012 struct u132_respond *respond = &ftdi->respond[ in ftdi_elan_respond_engine() local
1021 *respond->value = data; in ftdi_elan_respond_engine()
1022 *respond->result = 0; in ftdi_elan_respond_engine()
1023 complete(&respond->wait_completion); in ftdi_elan_respond_engine()
[all …]
|
| /Linux-v5.10/drivers/char/tpm/ |
| D | tpm_ibmvtpm.h | 52 #define INIT_CRQ_RES 0x01 /* Init respond */
53 #define INIT_CRQ_COMP_RES 0x02 /* Init complete respond */
|
| /Linux-v5.10/arch/sparc/kernel/ |
| D | pci_sabre.c | 137 #define SABRE_PCITASR_EF 0x0000000000000080UL /* Respond to 0xe0000000-0xffffffff */
138 #define SABRE_PCITASR_CD 0x0000000000000040UL /* Respond to 0xc0000000-0xdfffffff */
139 #define SABRE_PCITASR_AB 0x0000000000000020UL /* Respond to 0xa0000000-0xbfffffff */
140 #define SABRE_PCITASR_89 0x0000000000000010UL /* Respond to 0x80000000-0x9fffffff */
141 #define SABRE_PCITASR_67 0x0000000000000008UL /* Respond to 0x60000000-0x7fffffff */
142 #define SABRE_PCITASR_45 0x0000000000000004UL /* Respond to 0x40000000-0x5fffffff */
143 #define SABRE_PCITASR_23 0x0000000000000002UL /* Respond to 0x20000000-0x3fffffff */
144 #define SABRE_PCITASR_01 0x0000000000000001UL /* Respond to 0x00000000-0x1fffffff */
|
| /Linux-v5.10/Documentation/misc-devices/ |
| D | eeprom.rst | 68 The other devices will not be found on a DIMM because they respond to more
80 does not respond to byte reads. If this register is present, the lower 128
83 device will no longer respond at the 0x30-37 address. The eeprom driver
|
| /Linux-v5.10/net/netlabel/ |
| 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-v5.10/drivers/misc/ibmasm/ |
| D | heartbeat.c | 21 * to the driver. The driver must respond to the heartbeats or else the OS
24 * continues to respond to heartbeats, making the service processor believe
|
| /Linux-v5.10/drivers/infiniband/hw/qib/ |
| 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-v5.10/Documentation/process/ |
| D | 6.Followthrough.rst | 44 impulse to respond in kind. Code review is about the code, not about
59 that the reviewer is asking you to fix. And respond back to the reviewer:
177 respond to these reports is a matter of basic pride in your work. If that
209 really only one way to respond: be pleased that your problem got solved and
|
| /Linux-v5.10/drivers/input/joystick/iforce/ |
| D | iforce-main.c | 278 dev_warn(&iforce->dev->dev, "Device does not respond to id packet M\n"); in iforce_init_device()
283 dev_warn(&iforce->dev->dev, "Device does not respond to id packet P\n"); in iforce_init_device()
288 dev_warn(&iforce->dev->dev, "Device does not respond to id packet B\n"); in iforce_init_device()
293 dev_warn(&iforce->dev->dev, "Device does not respond to id packet N\n"); in iforce_init_device()
|
| /Linux-v5.10/drivers/scsi/bfa/ |
| D | bfa_hw_ct.c | 61 * Actions to respond RME Interrupt for Catapult ASIC:
79 * Actions to respond RME Interrupt for Catapult2 ASIC:
|
| /Linux-v5.10/drivers/w1/slaves/ |
| 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-v5.10/drivers/media/rc/ |
| D | gpio-ir-recv.c | 37 * Respond to interrupt taking more latency when cpu in idle. in gpio_ir_recv_irq()
43 * respond to interrupt, another is delay introduced by async api. in gpio_ir_recv_irq()
|
| /Linux-v5.10/Documentation/devicetree/bindings/iio/pressure/ |
| D | ms5611.txt | 7 - reg: the I2C address or SPI chip select the device will respond to
|
| D | zpa2326.txt | 7 - reg: the I2C address or SPI chip select the device will respond to
|
| /Linux-v5.10/drivers/platform/chrome/ |
| 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
230 dev_warn(ec_dev->dev, "EC failed to respond in time\n"); in cros_ec_spi_receive_packet()
338 dev_warn(ec_dev->dev, "EC failed to respond in time\n"); in cros_ec_spi_receive_response()
447 * itself, it can't respond to any commands and instead in do_cros_ec_pkt_xfer_spi()
|
| /Linux-v5.10/Documentation/devicetree/bindings/rtc/ |
| D | isil,isl12026.txt | 4 registers respond at bus address 0x6f, and the EEPROM array responds
|
| /Linux-v5.10/net/dccp/ |
| 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()
|
| D | minisocks.c | 137 * Process an incoming packet for RESPOND sockets represented
249 DCCP_BUG("DCCP-ACK packets are never sent in LISTEN/RESPOND state"); in dccp_reqsk_send_ack()
|
| /Linux-v5.10/include/linux/ |
| D | pmbus.h | 21 * Some PMBus chips respond with valid data when trying to read an unsupported
|
| /Linux-v5.10/drivers/platform/chrome/wilco_ec/ |
| D | mailbox.c | 131 /* For some commands (eg shutdown) the EC will not respond, that's OK */ in wilco_ec_transfer()
133 dev_dbg(ec->dev, "EC does not respond to this command\n"); in wilco_ec_transfer()
|
| /Linux-v5.10/net/netfilter/ |
| D | nf_conntrack_proto_dccp.c | 34 * - RESPOND:
38 * It MAY also leave the RESPOND state for CLOSED after a timeout of
75 [CT_DCCP_RESPOND] = "RESPOND",
109 * RESPOND: Response from server seen, waiting for Ack from client
118 * Some states exist only on one side of the connection: REQUEST, RESPOND,
|
| /Linux-v5.10/Documentation/devicetree/bindings/media/i2c/ |
| D | chrontel,ch7322.yaml | 39 the device will respond to power status requests with "standby"
|
| /Linux-v5.10/net/tipc/ |
| D | discover.c | 209 bool respond = false; in tipc_disc_rcv() local
247 &maddr, &respond, &dupl_addr); in tipc_disc_rcv()
250 if (!respond) in tipc_disc_rcv()
|
| /Linux-v5.10/drivers/usb/gadget/function/ |
| D | f_hid.c | 515 goto respond; in hidg_setup()
523 goto respond; in hidg_setup()
544 goto respond; in hidg_setup()
564 goto respond; in hidg_setup()
572 goto respond; in hidg_setup()
593 respond: in hidg_setup()
|
