Using request_firmware assumes that the driver knows the FW file name
no it knows an ALIAS for it.
and the driver initiates the load. That's not our model where we work
with different FWs, don't know what the names are,
you can have the user make a symlink to the one he wants. No Big Deal.
They are used to parameter the HW:
register access,
ethtool supports that, so shouldn't be an ioctl for sure
configuration of queue sets, on board memory
configuration,
I'm sure ethtool can do that too
firmware load, etc ...
and for this we have request_firmware() interface.
adding
Arjan van de Ven wrote:
They are used to parameter the HW:
register access,
ethtool supports that, so shouldn't be an ioctl for sure
configuration of queue sets, on board memory
configuration,
I'm sure ethtool can do that too
firmware load, etc ...
and for this we have
+/*
+ * Interrupt handler for asynchronous events used with MSI-X.
+ */
+static irqreturn_t t3_async_intr_handler(int irq, void *cookie)
+{
+ t3_slow_intr_handler(cookie);
+ return IRQ_HANDLED;
+}
this looks very wrong; why is t3_slow_intr_handler a void rather than
returning
Arjan,
Thanks for the review. Please see my replies inline.
Arjan van de Ven wrote:
+/*
+ * Interrupt handler for asynchronous events used with MSI-X.
+ */
+static irqreturn_t t3_async_intr_handler(int irq, void *cookie)
+{
+ t3_slow_intr_handler(cookie);
+ return IRQ_HANDLED;
+}
Stephen,
Thanks for the review. Please see my replies inline.
Stephen Hemminger wrote:
O
+ * If we have multiple receive queues per port serviced by NAPI we need one
+ * netdevice per queue as NAPI operates on netdevices. We already have one
+ * netdevice, namely the one associated with
O
+ * If we have multiple receive queues per port serviced by NAPI we need one
+ * netdevice per queue as NAPI operates on netdevices. We already have one
+ * netdevice, namely the one associated with the interface, so we use dummy
+ * ones for any additional queues. Note that these
