d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
4cc8a9da49
freebsd-skq/sys/dev/iicbus/iiconf.h

184 lines
6.3 KiB
C
Raw Normal View History

Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
/*-
sys/dev: further adoption of SPDX licensing ID tags. Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
2017-11-27 14:52:40 +00:00
* SPDX-License-Identifier: BSD-2-Clause-FreeBSD
*
Major rework of the iicbus/smbus framework: - VIA chipset SMBus controllers added - alpm driver updated - Support for dynamic modules added - bktr FreeBSD smbus updated but not tested - cleanup
2002-03-23 15:49:15 +00:00
* Copyright (c) 1998, 2001 Nicolas Souchu
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
$Id$ -> $FreeBSD$
1999-08-28 01:08:13 +00:00
* $FreeBSD$
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
*/
#ifndef __IICONF_H
#define __IICONF_H
#include <sys/queue.h>
Revert r268543. We should probably fix sys/gpio.h instead.
2014-07-12 06:23:42 +00:00
#include <dev/iicbus/iic.h>
Allow iic bridges to support a generalized transfer, rather than forcing all transfers to do the start read/write stop by hand. Some smart bridges prefer this sort of operation, and this allows us to support their features more easily. When bridges don't support it, we fall back to using the old-style opertaions. Expand the ioctl interface to expose this function. Unlike the old-style interface, this interface is thread safe, even on old bridges.
2006-07-14 23:15:06 +00:00
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
Fix warnings in preparation for adding -Wall -Wcast-qual to the kernel compile
1999-01-27 21:50:00 +00:00
#define IICPRI (PZERO+8) /* XXX sleep/wakeup queue priority */
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
#define LSB 0x1
/*
Fix a bug introduced with recursive bus ownership support in r321584. The recursive ownership support added in r321584 was unconditionally in effect all the time -- whenever a given i2c slave device instance tried to lock the i2c bus for exclusive use when it already owned the bus, the call returned immediately without waiting. However, many i2c slave drivers use bus ownership to enforce that only a single thread at a time can be using the slave device. The recursive locking changes broke this use case. Now there is a new flag, IIC_RECURSIVE, which can be mixed in with the other flags passed to iicbus_acquire_bus() to allow drivers to indicate when recursive locking is desired. Using the flag implies that the driver is managing concurrent access to the device by different threads in some way. This immediately fixes all existing i2c slave drivers except for the two i2c RTC drivers which use the recursive locking feature; those will be fixed in a followup commit.
2018-01-23 23:30:19 +00:00
* Options affecting iicbus_request_bus()
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
*/
#define IIC_DONTWAIT 0
#define IIC_NOINTR 0
#define IIC_WAIT 0x1
#define IIC_INTR 0x2
Add a short name, IIC_INTRWAIT, for the common case (IIC_INTR | IIC_WAIT).
2015-10-10 02:06:07 +00:00
#define IIC_INTRWAIT (IIC_INTR | IIC_WAIT)
Fix a bug introduced with recursive bus ownership support in r321584. The recursive ownership support added in r321584 was unconditionally in effect all the time -- whenever a given i2c slave device instance tried to lock the i2c bus for exclusive use when it already owned the bus, the call returned immediately without waiting. However, many i2c slave drivers use bus ownership to enforce that only a single thread at a time can be using the slave device. The recursive locking changes broke this use case. Now there is a new flag, IIC_RECURSIVE, which can be mixed in with the other flags passed to iicbus_acquire_bus() to allow drivers to indicate when recursive locking is desired. Using the flag implies that the driver is managing concurrent access to the device by different threads in some way. This immediately fixes all existing i2c slave drivers except for the two i2c RTC drivers which use the recursive locking feature; those will be fixed in a followup commit.
2018-01-23 23:30:19 +00:00
#define IIC_RECURSIVE 0x4
Add support for i2c bus mux hardware. An i2c bus can be divided into segments which can be selectively connected and disconnected from the main bus. This is usually done to enable using multiple slave devices having the same address, by isolating the devices onto separate bus segments, only one of which is connected to the main bus at once. There are several types of i2c bus muxes, which break down into two general categories... - Muxes which are themselves i2c slaves. These devices respond to i2c commands on their upstream bus, and based on those commands, connect various downstream buses to the upstream. In newbus terms, they are both a child of an iicbus and the parent of one or more iicbus instances. - Muxes which are not i2c devices themselves. Such devices are part of the i2c bus electrically, but in newbus terms their parent is some other bus. The association with the upstream bus must be established by separate metadata (such as FDT data). In both cases, the mux driver has one or more iicbus child instances representing the downstream buses. The mux driver implements the iicbus_if interface, as if it were an iichb host bridge/i2c controller driver. It services the IO requests sent to it by forwarding them to the iicbus instance representing the upstream bus, after electrically connecting the upstream bus to the downstream bus that hosts the i2c slave device which made the IO request. The net effect is automatic mux switching which is transparent to slaves on the downstream buses. They just do i2c IO they way they normally do, and the bus is electrically connected for the duration of the IO and then idled when it is complete. The existing iicbus_if callback() method is enhanced so that the parameter passed to it can be a struct which contains a device_t for the requesting bus and slave devices. This change is done by adding a flag that indicates the extra values are present, and making the flags field the first field of a new args struct. If the flag is set, the iichb or mux driver can recast the pointer-to-flags into a pointer-to-struct and access the extra fields. Thus abi compatibility with older drivers is retained (but a mux cannot exist on the bus with the older iicbus driver in use.) A new set of core support routines exists in iicbus.c. This code will help implement mux drivers for any type of mux hardware by supplying all the boilerplate code that forwards IO requests upstream. It also has code for parsing metadata and instantiating the child iicbus instances based on it. Two new hardware mux drivers are added. The ltc430x driver supports the LTC4305/4306 mux chips which are controlled via i2c commands. The iic_gpiomux driver supports any mux hardware which is controlled by manipulating the state of one or more gpio pins. Test Plan Tested locally using a variety of mux'd bus configurations involving both ltc4305 and a homebrew gpio-controlled mux. Tested configurations included cascaded muxes (unlikely in the real world, but useful to prove that 'it all just works' in terms of the automatic switching and upstream forwarding of IO requests).
2020-01-02 17:51:49 +00:00
#define IIC_REQBUS_DEV 0x8 /* See struct iic_reqbus_data, below. */
/*
* The original iicbus->bridge callback api took a pointer to an int containing
* flags. The new api allows a pointer to this struct, with IIC_REQBUS_DEV set
* in the flags to let the implementation know the pointer is actually to this
* struct which has the flags word first, followed by the device_t of the
* requesting bus and device.
*
* Note that the requesting device may not be a i2c slave device which is a
* child of the requested bus -- it may be a mux device which is electrically
* part of the bus hierarchy, but whose driver belongs to some other bus
* hierarchy such as gpio.
*/
struct iic_reqbus_data {
int flags; /* Flags from the set defined above. */
device_t bus; /* The iicbus being requested. */
device_t dev; /* The device requesting the bus. */
};
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
/*
* i2c modes
*/
#define IIC_MASTER 0x1
#define IIC_SLAVE 0x2
#define IIC_POLLED 0x4
/*
* i2c speed
*/
#define IIC_UNKNOWN 0x0
#define IIC_SLOW 0x1
#define IIC_FAST 0x2
#define IIC_FASTEST 0x3
iicbb is generic support for I2C bit-banging. Other files: timeout management added to the I2C framework.
1998-10-31 11:31:07 +00:00
#define IIC_LAST_READ 0x1
/*
* callback index
*/
#define IIC_REQUEST_BUS 0x1
#define IIC_RELEASE_BUS 0x2
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
/*
* interrupt events
*/
#define INTR_GENERAL 0x1 /* general call received */
#define INTR_START 0x2 /* the I2C interface is addressed */
#define INTR_STOP 0x3 /* stop condition received */
#define INTR_RECEIVE 0x4 /* character received */
#define INTR_TRANSMIT 0x5 /* character to transmit */
#define INTR_ERROR 0x6 /* error */
#define INTR_NOACK 0x7 /* no ack from master receiver */
/*
* adapter layer errors
*/
sys/dev: minor spelling fixes. Most affect comments, very few have user-visible effects.
2016-05-03 03:41:25 +00:00
#define IIC_NOERR 0x0 /* no error occurred */
Use IIC_EBUSBSY and IIC_BUSERR status values consistantly across all drivers. Make it clearer what each one means in the comments that define them. IIC_BUSBSY was used in many places to mean two different things, either "someone else has reserved the bus so you have to wait until they're done" or "the signal level on the bus was not in the state I expected before/after issuing some command". Now IIC_BUSERR is used consistantly to refer to protocol/signaling errors, and IIC_BUSBSY refers to ownership/reservation of the bus.
2015-10-09 22:49:50 +00:00
#define IIC_EBUSERR 0x1 /* bus error (hardware not in expected state) */
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
#define IIC_ENOACK 0x2 /* ack not received until timeout */
#define IIC_ETIMEOUT 0x3 /* timeout */
Use IIC_EBUSBSY and IIC_BUSERR status values consistantly across all drivers. Make it clearer what each one means in the comments that define them. IIC_BUSBSY was used in many places to mean two different things, either "someone else has reserved the bus so you have to wait until they're done" or "the signal level on the bus was not in the state I expected before/after issuing some command". Now IIC_BUSERR is used consistantly to refer to protocol/signaling errors, and IIC_BUSBSY refers to ownership/reservation of the bus.
2015-10-09 22:49:50 +00:00
#define IIC_EBUSBSY 0x4 /* bus busy (reserved by another client) */
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
#define IIC_ESTATUS 0x5 /* status error */
#define IIC_EUNDERFLOW 0x6 /* slave ready for more data */
#define IIC_EOVERFLOW 0x7 /* too much data */
iicbb is generic support for I2C bit-banging. Other files: timeout management added to the I2C framework.
1998-10-31 11:31:07 +00:00
#define IIC_ENOTSUPP 0x8 /* request not supported */
#define IIC_ENOADDR 0x9 /* no address assigned to the interface */
Add iic2errno(), a helper function to translate IIC_Exxxxx status values to errno values that are at least vaguely equivelent. Also add a new status value, IIC_ERESOURCE, to indicate a failure to acquire memory or other required resources to complete a transaction. The IIC_Exxxxxx values are supposed to communicate low-level details of the i2c transaction status between the lowest-layer hardware driver and higher-layer bus protocol and device drivers for slave devices on the bus. Most of those slave drivers just return all status values from the lower layers directly to their callers, resulting in crazy error reporting from a user's point of view (things like timeouts being reported as "no such process"). Now there's a helper function to make it easier to start cleaning up all those drivers.
2015-10-09 23:20:08 +00:00
#define IIC_ERESOURCE 0xa /* resources (memory, whatever) unavailable */
Create a mechanism for encoding a system errno into the IIC_Exxxxx space. Errors are communicated between the i2c controller layer and upper layers (iicbus and slave device drivers) using a set of IIC_Exxxxxx constants which effectively define a private number space separate from (and having values that conflict with) the system errno number space. Sometimes it is necessary to report a plain old system error (especially EINTR) from the controller or bus layer and have that value make it back across the syscall interface intact. I initially considered replicating a few "crucial" errno values with similar names and new numbers, e.g., IIC_EINTR, IIC_ERESTART, etc. It seemed like that had the potential to grow over time until many of the errno names were duplicated into the IIC_Exxxxx space. So instead, this defines a mechanism to "encode" an errno into the IIC_Exxxx space by setting the high bit and putting the errno into the lower-order bits; a new errno2iic() function does this. The existing iic2errno() recognizes the encoded values and extracts the original errno out of the encoded value. An interesting wrinkle occurs with the pseudo-error values such as ERESTART -- they aleady have the high bit set, and turning it off would be the wrong thing to do. Instead, iic2errno() recognizes that lots of high bits are on (i.e., it's a negative number near to zero) and just returns that value as-is. Thus, existing drivers continue to work without needing any changes, and there is now a way to return errno values from the lower layers. The first use of that is in iicbus_poll() which does mtx_sleep() with the PCATCH flag, and needs to return the errno from that up the call chain. Differential Revision: https://reviews.freebsd.org/D20975
2019-09-14 19:33:36 +00:00
#define IIC_ERRNO __INT_MIN /* marker bit: errno is in low-order bits */
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
Return only IIC_Exxxx status values from iicbus-layer functions. Most of these functions are thin wrappers around calling the hardware-layer driver, but some of them do sanity checks and return an error. Since the hardware layer can only return IIC_Exxxxx status values, the iicbus helper functions must also adhere to that, so that drivers at higher layers can assume that any non-zero status value is an IIC_Exxxx value that provides details about what happened at the hardware layer (sometimes those details are important for certain slave drivers).
2015-10-09 23:58:19 +00:00
/*
* Note that all iicbus functions return IIC_Exxxxx status values,
* except iic2errno() (obviously) and iicbus_started() (returns bool).
*/
Add iic2errno(), a helper function to translate IIC_Exxxxx status values to errno values that are at least vaguely equivelent. Also add a new status value, IIC_ERESOURCE, to indicate a failure to acquire memory or other required resources to complete a transaction. The IIC_Exxxxxx values are supposed to communicate low-level details of the i2c transaction status between the lowest-layer hardware driver and higher-layer bus protocol and device drivers for slave devices on the bus. Most of those slave drivers just return all status values from the lower layers directly to their callers, resulting in crazy error reporting from a user's point of view (things like timeouts being reported as "no such process"). Now there's a helper function to make it easier to start cleaning up all those drivers.
2015-10-09 23:20:08 +00:00
extern int iic2errno(int);
Create a mechanism for encoding a system errno into the IIC_Exxxxx space. Errors are communicated between the i2c controller layer and upper layers (iicbus and slave device drivers) using a set of IIC_Exxxxxx constants which effectively define a private number space separate from (and having values that conflict with) the system errno number space. Sometimes it is necessary to report a plain old system error (especially EINTR) from the controller or bus layer and have that value make it back across the syscall interface intact. I initially considered replicating a few "crucial" errno values with similar names and new numbers, e.g., IIC_EINTR, IIC_ERESTART, etc. It seemed like that had the potential to grow over time until many of the errno names were duplicated into the IIC_Exxxxx space. So instead, this defines a mechanism to "encode" an errno into the IIC_Exxxx space by setting the high bit and putting the errno into the lower-order bits; a new errno2iic() function does this. The existing iic2errno() recognizes the encoded values and extracts the original errno out of the encoded value. An interesting wrinkle occurs with the pseudo-error values such as ERESTART -- they aleady have the high bit set, and turning it off would be the wrong thing to do. Instead, iic2errno() recognizes that lots of high bits are on (i.e., it's a negative number near to zero) and just returns that value as-is. Thus, existing drivers continue to work without needing any changes, and there is now a way to return errno values from the lower layers. The first use of that is in iicbus_poll() which does mtx_sleep() with the PCATCH flag, and needs to return the errno from that up the call chain. Differential Revision: https://reviews.freebsd.org/D20975
2019-09-14 19:33:36 +00:00
extern int errno2iic(int);
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
extern int iicbus_request_bus(device_t, device_t, int);
extern int iicbus_release_bus(device_t, device_t);
extern device_t iicbus_alloc_bus(device_t);
extern void iicbus_intr(device_t, int, char *);
iicbb is generic support for I2C bit-banging. Other files: timeout management added to the I2C framework.
1998-10-31 11:31:07 +00:00
extern int iicbus_null_repeated_start(device_t, u_char);
extern int iicbus_null_callback(device_t, int, caddr_t);
#define iicbus_reset(bus,speed,addr,oldaddr) \
(IICBUS_RESET(device_get_parent(bus), speed, addr, oldaddr))
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
Change /dev/smb and /dev/iic interface to allow user programs to interact with devices dynamically. That means, + only one /dev/iic or /dev/smb device for each smb/iic bus to access + I2C/SMB device address must be given to any ioctl + new devices may be plugged and accessed after boot, which was impossible previously (device addresses were hardcoded into the kernel)
1999-01-09 18:08:24 +00:00
/* basic I2C operations */
extern int iicbus_started(device_t);
extern int iicbus_start(device_t, u_char, int);
extern int iicbus_stop(device_t);
Submitted by: Nicolas Souchu <nsouch@freebsd.org> Updated to support bt848 driver MSP34xx audio chip. This adds changes made in 1.3.2.1 and 1.3.2.2 from RELENG_3
1999-01-28 15:56:18 +00:00
extern int iicbus_repeated_start(device_t, u_char, int);
const poison submitted by: john wehle
2006-12-05 06:19:36 +00:00
extern int iicbus_write(device_t, const char *, int, int *, int);
Change /dev/smb and /dev/iic interface to allow user programs to interact with devices dynamically. That means, + only one /dev/iic or /dev/smb device for each smb/iic bus to access + I2C/SMB device address must be given to any ioctl + new devices may be plugged and accessed after boot, which was impossible previously (device addresses were hardcoded into the kernel)
1999-01-09 18:08:24 +00:00
extern int iicbus_read(device_t, char *, int, int *, int, int);
Submitted by: Nicolas Souchu <nsouch@freebsd.org> Updated to support bt848 driver MSP34xx audio chip. This adds changes made in 1.3.2.1 and 1.3.2.2 from RELENG_3
1999-01-28 15:56:18 +00:00
/* single byte read/write functions, start/stop not managed */
extern int iicbus_write_byte(device_t, char, int);
extern int iicbus_read_byte(device_t, char *, int);
Change /dev/smb and /dev/iic interface to allow user programs to interact with devices dynamically. That means, + only one /dev/iic or /dev/smb device for each smb/iic bus to access + I2C/SMB device address must be given to any ioctl + new devices may be plugged and accessed after boot, which was impossible previously (device addresses were hardcoded into the kernel)
1999-01-09 18:08:24 +00:00
/* Read/write operations with start/stop conditions managed */
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
extern int iicbus_block_write(device_t, u_char, char *, int, int *);
extern int iicbus_block_read(device_t, u_char, char *, int, int *);
Allow iic bridges to support a generalized transfer, rather than forcing all transfers to do the start read/write stop by hand. Some smart bridges prefer this sort of operation, and this allows us to support their features more easily. When bridges don't support it, we fall back to using the old-style opertaions. Expand the ioctl interface to expose this function. Unlike the old-style interface, this interface is thread safe, even on old bridges.
2006-07-14 23:15:06 +00:00
/* vectors of iic operations to pass to bridge */
int iicbus_transfer(device_t bus, struct iic_msg *msgs, uint32_t nmsgs);
Add iicbus_transfer_excl(), a helper routine to do an i2c bus transaction while holding exclusive ownership of the bus. This is the routine most slave drivers should use unless they have a need to acquire and hold the bus across a series of related operations that involves multiple transfers.
2015-10-22 00:54:59 +00:00
int iicbus_transfer_excl(device_t bus, struct iic_msg *msgs, uint32_t nmsgs,
int how);
Allow iic bridges to support a generalized transfer, rather than forcing all transfers to do the start read/write stop by hand. Some smart bridges prefer this sort of operation, and this allows us to support their features more easily. When bridges don't support it, we fall back to using the old-style opertaions. Expand the ioctl interface to expose this function. Unlike the old-style interface, this interface is thread safe, even on old bridges.
2006-07-14 23:15:06 +00:00
int iicbus_transfer_gen(device_t bus, struct iic_msg *msgs, uint32_t nmsgs);
Add a pair of convenience routines for doing simple "register" read/writes on i2c devices, where the "register" can be any length. Many (perhaps most) common i2c devices are organized as a collection of (usually 1-byte-wide) registers, and are accessed by first writing a 1-byte register index/offset number, then by reading or writing the data. Generally there is an auto-increment feature so the when multiple bytes are read or written, multiple contiguous registers are accessed. Most existing slave device drivers allocate an array of iic_msg structures, fill in all the transfer info, and invoke iicbus_transfer(). These new functions commonize all that and reduce register access to a simple call with a few arguments.
2017-07-26 20:40:24 +00:00
/*
* Simple register read/write routines, but the "register" can be any size.
* The transfers are done with iicbus_transfer_excl(). Reads use a repeat-start
* between sending the address and reading; writes use a single start/stop.
*/
int iicdev_readfrom(device_t _slavedev, uint8_t _regaddr, void *_buffer,
uint16_t _buflen, int _waithow);
int iicdev_writeto(device_t _slavedev, uint8_t _regaddr, void *_buffer,
uint16_t _buflen, int _waithow);
Major rework of the iicbus/smbus framework: - VIA chipset SMBus controllers added - alpm driver updated - Support for dynamic modules added - bktr FreeBSD smbus updated but not tested - cleanup
2002-03-23 15:49:15 +00:00
#define IICBUS_MODVER 1
#define IICBUS_MINVER 1
#define IICBUS_MAXVER 1
#define IICBUS_PREFVER IICBUS_MODVER
make iicbb_devclass and iicbb_driver globally visible. This will let drivers that implemnt the i2c bit banging bus interface not have to recompile iicbb in order to add an attachment for it. This will mean the bktr and other definitions can go back to their respective drivers.
2003-06-19 02:50:08 +00:00
extern driver_t iicbb_driver;
extern devclass_t iicbb_devclass;
Major rework of the iicbus/smbus framework: - VIA chipset SMBus controllers added - alpm driver updated - Support for dynamic modules added - bktr FreeBSD smbus updated but not tested - cleanup
2002-03-23 15:49:15 +00:00
#define IICBB_MODVER 1
#define IICBB_MINVER 1
#define IICBB_MAXVER 1
#define IICBB_PREFVER IICBB_MODVER
Submitted by: nsouch Philips I2C bus generic support other new bus architecture.
1998-09-03 20:51:50 +00:00
#endif
Reference in New Issue Copy Permalink