performance issues.
* Access to the GPIO bus is already locked by requesting
and releasing the bus - thus the lock isn't really needed
for each GPIO pin change.
* Don't lock and unlock the GPIO bus for -each- i2c access -
the i2c bus code is already doing this by calling the upper
layer callback to request/release the bus. This thus locks
the bus for the entirety of the transaction.
TODO:
* Further verify that everything is correctly requesting/
releasing the GPIO bus.
* Look at how to lock the GPIO pin configuration stuff,
potentially by locking/unlocking the bus at the gpiobus
layer.
Fix the TCP header size calculation such that makes TSO engine
cache all header(ethernet/IP/TCP) bytes to its internal buffer.
While here, remove extra pull up for TCP payload. Unlike some
em(4) controllers, fxp(4) does not require such work around for
TSO.
The two limitations are ethernet/IP/TCP header size should be less
than or equal to the size of controller's internal buffer(80 bytes)
and these header information should be found in the first fragment
of a TSO frame.
of the rx_ring to bus_dmamap_sync(9). Given that netmap code tries to
obtain the bus addresses of netmap buffers via vtophys(9) instead of using
bus_dma(9) it currently has zero chance of actually working on sparc64
though (and for that matter f.e. also not with MACs limited to 32-bit DMA
on x86 machines with more than 4GB of RAM).
- put underlying keyboard(s) into the polling mode for the whole
duration of the grab, instead of the previous behavior of going into
and out of the polling mode around each polling attempt
- ditto for setting K_XLATE mode and enabling a disabled keyboard
Inspired by: bde
MFC after: 2 months
At the moment grab and ungrab methods of all console drivers are no-ops.
Current intended meaning of the calls is that the kernel takes control of
console input. In the future the semantics may be extended to mean that
the calling thread takes full ownership of the console (e.g. console
output from other threads could be suspended).
Inspired by: bde
MFC after: 2 months
unsupported form of the latter. This change has been reviewed and accepted
in the -hackers list.
Submitted by: Alexander Best
Reviewed by: David Schulz
- Device configuration via plain text config file. Also able to operate
when not attached to the chip as the master driver.
- Generic "work request" queue that serves as the base for both ctrl and
ofld tx queues.
- Generic interrupt handler routine that can process any event on any
kind of ingress queue (via a dispatch table).
- A couple of new driver ioctls. cxgbetool can now install a firmware
to the card ("loadfw" command) and can read the card's memory
("memdump" and "tcb" commands).
- Lots of assorted information within dev.t4nex.X.misc.* This is
primarily for debugging and won't show up in sysctl -a.
- Code to manage the L2 tables on the chip.
- Updates to cxgbe(4) man page to go with the tunables that have changed.
- Updates to the shared code in common/
- Updates to the driver-firmware interface (now at fw 1.4.16.0)
MFC after: 1 month
attached this way.
The AR5212 based NICs have a variety of RF frontends, so there's a linker set
which the AR5212 attach routine calls. The same framework is used for the
AR5416 and later but as there's a fixed RF frontend for each 11n NIC, it
is just directly attached.
However in the case of compiling a cut down HAL (eg _just_ AR9130 WMAC support),
the linker set ends up being empty and this causes the compile to fail.
So this is just a workaround for that - it means those users who wish an 11n
only HAL can compile the 11n chipsets and RF frontend they need, and just
"ath_ar5212" for the AR5212/AR5416 common code, and it'll just work.
Sponsored by: Hobnob, Inc.
will time out and close opened /dev/dspX.Y device(s), if
any. This is a workaround because we cannot unregister PCM
devices while the audio character device is in use.
Add a missing inclusion guard.
MFC after: 1 weeks
This patch should remove the need for kldunload of USB
controller drivers at suspend and kldload of USB controller
drivers at resume.
This patch also fixes some build issues in avr32dci.c
MFC after: 2 weeks
messages.
o Add check for actually resolved speed in miibus_statchg callback
instead of blindly reprogramming BCE_EMAC_MODE register. The
callback may be called multiple times(e.g. link UP, link
transition, auto-negotiate complete etc) while auto-negotiation
is in progress. All unresolved link state changes are ignored
now and setting BCE_EMAC_MODE after link establishment is done
once.
o bce(4) is careful enough not to drive MII_TICK if driver got a
valid link. To detect lost link, bce(4) relied on link state
change interrupt and if driver see the interrupt, it forced to
drive MII_TICK by calling bce_tick() in interrupt handler.
Because bce(4) generates multiple link state change interrupts
while auto-negotiation is in progress, bce_tick() would be
called multiple times and this resulted in generating multiple
link UP/DOWN messages.
With this change, bce_tick() is not called in interrupt handler
anymore such that miibus_statchg callback handles link state
changes with consistent manner.
Reviewed by: davidch
If I interpret the C standard correctly, the storage specifier should be
placed before the inline keyword. While at it, replace __inline by
inline in the files affected.
As C1X is close to being released, there is no need to wrap around a
feature that is already part of C90. Most of these files already use
`const' in different placed as well.
- in destroy_lun_state() assert hold == 1 instead of 0, as it should
receive hold taken by the create_lun_state() or get_lun_statep() before;
- fix hold count leak inside rls_lun_statep() that also fired above assert;
- in destroy_lun_state() use SIM bus number instead of SIM path id for
ISP_GET_PC_ADDR(), as it was before r196008;
- make isp_disable_lun() to set status in CCB;
- make isp_target_mark_aborted() set status into the proper CCB.
Reviewed by: mjacob
Sponsored by: iXsystems, inc.
MFC after: 1 month
- Two struct members eee_disable are used in a function that expects
an int *, so declare them int, not bool.
- igb_tx_ctx_setup() returns a boolean value, so declare it bool, not int.
- igb_header_split is passed to TUNABLE_INT, so delcare it int, not bool.
- igb_tso_setup() returns a bool, so declare it bool, not boolean_t.
- Do not re-define bool/true/false if the symbols already exist.
MFC after: 2 weeks
Sponsored by: Isilon Systems, LLC
- {ixgbe,ixv}_header_split is passed to TUNABLE_INT, so delcare it
int, not bool.
- {ixgbe,ixv}_tx_ctx_setup() returns a boolean value, so declare it
bool, not int.
- {ixgbe,ixv}_tso_setup() returns a bool, so declare it bool, not boolean_t.
- {ixgbe,ixv}_txeof() returns a bool, so declare it bool, not boolean_t.
- Do not re-define bool if the symbol already exists.
MFC after: 2 weeks
Sponsored by: Isilon Systems, LLC
processors with CPUID signature 06_1AH, 06_1EH, and 06_1FH.
Refuse to allocate them on unsupported model.
Submitted by: Davide Italiano <davide.italiano@gmail.com>
MFC after: 1 month
