Date: Sat, 3 Dec 2011 01:02:47 +0100 From: Stefan Bethke <stb@lassitu.de> To: John-Mark Gurney <jmg@funkthat.com> Cc: Aleksandr Rybalko <ray@dlink.ua>, freebsd-embedded@freebsd.org Subject: Re: TL-WR1043: switch Message-ID: <E29B1787-FF42-4462-81C0-8185F70C45B6@lassitu.de> In-Reply-To: <20111202191122.GK25601@funkthat.com> References: <68ABED76-CB1F-405A-8036-EC254F7511FA@lassitu.de> <3B3DB17D-BF87-40EE-B1C1-445F178E8844@lassitu.de> <86030CEE-6839-4B96-ACDC-2BA9AC1E4AE4@lassitu.de> <2D625CC9-A0E3-47AA-A504-CE8FB2F90245@lassitu.de> <203BF1C8-D528-40C9-8611-9C7AC7E43BAB@lassitu.de> <3C0E9CA3-E130-4E9A-ABCC-1782E28999D1@lassitu.de> <2B8826C7-00C7-4117-B424-4A86F1346DFF@bsdimp.com> <20111130231311.4a154bc5.ray@ddteam.net> <CAJ-Vmon8-yo-UQ%2B81feLT-Yr%2BJimMsEbLHWfd9kZP_s4804%2BtA@mail.gmail.com> <20111202164539.fff3ea91.ray@dlink.ua> <20111202191122.GK25601@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org> wrote: >>=20 >>>> .. erk. >>>>=20 >>>> 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? >>=20 >> 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. >=20 > 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=85 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 --=20 Stefan Bethke <stb@lassitu.de> Fon +49 151 14070811
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E29B1787-FF42-4462-81C0-8185F70C45B6>