This appears to have been a mistake; there's no obvious explanation
in the commit history for why this is different from all other
iic_use_direct_match users.
Patch from Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>, thanks!
(If it really is intended to ues I2C_MATCH_DIRECT_COMPATIBLE here, we
need a clear explanation of why, written down in a nearby comment.)
atmospheric pressure sensor. This is an inexpensive to moderately
expensive chip available from a large number of places. The driver
supports all aspects of the two chips, except for the repeating read
mode which would allow for sub-second queries, such as fall detection
or perhaps even as an altimeter. This driver also only supports the
I2C interface and not the SPI interface.
The BME280, the one with humidity, is not fully tested at this point,
awaiting upon a breakout board and may not show proper humidity.
It was introduced in 2007 for some Xbox thing which was removed in
2011. The API and the threads it spawned have been sitting around
idly for over a decade serving no purpose -- sometimes causing kernel
lock spinouts in the event of panic.
Add ic_tag_private to obviate need for future ABI changes. Not
currently used, but we can privately allocate memory in iic_tag_init
for the purpose later if need be without changing ABI.
XXX kernel revbump -- changes struct i2c_controller
This way we don't pollute the NetBSD kernel namespace with all the
Linux compat shim definitions needed to build drm, except for the
local drm drivers that need the API.
it was found that the datasheet does not appear to provide enough
information to make use of the alarm and interrupt function work. So
actually remove the dead code that was an attempt at making that all
work. Adjust the man page to mention that this.
the iic module. There are valid configurations where i2c_subr code
can be both built-in and part of a loaded module (eg, piixpm is in
the kernel, but the iic module is loaded later). This causes the
in-kernel linker to detect a duplicate symbol.
interfaces, make sure that initialization and destruction
follow the proper sequence. This is triggered by the recent
changes to the devsw stuff; per riastradh@ the required call
sequence is:
devsw_attach()
config_init_component() or config_cf*_attach()
...
config_fini_component() or config_cf*_detach()
devsw_detach()
While here, add a few missing calls to some of the detach
routines.
Testing of these changes has been limited to:
1. compile without build break
2. no related test failures from atf
3. modload/modunload work as well as
before.
No functional device testing done, since I don't have any
of these devices. Let me know of any damage I might cause
here!
XXX Some of the modules affected by this commit are already
XXX broken; see kern/56772. This commit does not break
any additional modules (as far as I know).
Prune a whole lotta dead branches as a result of this. (Some logic
calling this is also wrong for other reasons; devsw_detach is final
-- you should never have any reason to decide to roll it back. To be
cleaned up in subsequent commits...)
XXX kernel ABI change to devsw_detach signature requires bump
from which the newly created handle will inherit it's implementation.
The root implementation for a new handle type is used if an invalid
"super handle" is passed.
add support for 8-bit and I2C variants of the chip:
- MCP23008 / MCP23S08: 8-bit (I2C / SPI)
- MCP23017 / MCP23S17: 16-bit (I2C / SPI)
- MCP23018 / MCP23S18: 16-bit (I2C / SPI), open-drain outputs
The MCP23x17 and MCP23x18 are essentially identical, software-wise; we
merely report different GPIO pin capabilities (no push-pull output for
MCP23x18). Also, remove the tri-state capability that was previously
advertised by the old version of this driver; these chips have no way
to put the pin into a HI-Z mode.
All 3 I2C versions are supported, but the SPI front-end still only
supports the MCP23S17 for now (SPI autoconfiguration needs an overhaul).
mcp23s17gpio(4) remains present as a link to the new mcpgpio(4) man page.
XXX Still to-do: FDT integration, interrupt suppoort.