TL-WR1043: switch

Stefan Bethke stb at lassitu.de
Sat Dec 3 00:02:49 UTC 2011


Am 02.12.2011 um 20:11 schrieb John-Mark Gurney:

> Aleksandr Rybalko wrote this message on Fri, Dec 02, 2011 at 16:45 +0200:
>> On Fri, 2 Dec 2011 22:39:32 +0800
>> Adrian Chadd <adrian at freebsd.org> wrote:
>> 
>>>> .. erk.
>>>> 
>>>> Well, what shall we do? Create a different driver? Or just enable a
>>>> "quirk" or configuration paramater, which allows the device to be
>>>> not-quite-i2c?
>> 
>> It's too specific to Realtek, so from one point better to have
>> separate driver, but from another point it have i2c EEPROM on same bus.
>> So if we want to have access to both, we need quirk.
> 
> Not to complicate things, but you could have a custom bus driver that
> provides an attachment for the standard i2c bus, and another attachment
> for the Realtek part...  This custom bus driver would mediate access
> between the two…

I'm of two minds.  One the one hand, the one concrete example for the driver has only the switch chip connected to the bit-banging interface (gpioiic).  We can easily attach directly to gpioiic.  Heck, even code duplication is not that bad, since I believe the finer points of I2C can be ignored for this part. (I have to check whether clock stretching on the ack needs to be taken into account, but it seems even that is not necessary.)

On the other hand, the Realtek "almost I2C" seems to me to be compatible with real I2C devices, so coexistence shouldn't be a problem.  I believe that "arbitration" is not necessary, since the Realtek part follows the I2C semantics for slave selection fully (AFAICT).

The TL-WR1043ND has an unpopulated spot for an EEPROM.  Being able to use the existing code infrastructure to quickly add fun parts as a quick had would certainly be nice.

I see two ways to make iicbus play with the Realtek "System Management Interface" protocol: either make the patch I suggested optional via a hint, or let a slave device somehow indicate that it wants the relaxed semantics.  The hint is likely the option that is easier to implement.  Writing a new go-between bus driver is likely too complicated for me to accomplish right now.


Stefan

-- 
Stefan Bethke <stb at lassitu.de>   Fon +49 151 14070811





More information about the freebsd-embedded mailing list