From owner-freebsd-embedded@FreeBSD.ORG Sat Dec 3 00:02:49 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A3AE1065677 for ; Sat, 3 Dec 2011 00:02:49 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 4BC488FC16 for ; Sat, 3 Dec 2011 00:02:49 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 1F3F0106DD7; Sat, 3 Dec 2011 01:02:48 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Stefan Bethke In-Reply-To: <20111202191122.GK25601@funkthat.com> Date: Sat, 3 Dec 2011 01:02:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <20111202164539.fff3ea91.ray@dlink.ua> <20111202191122.GK25601@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1251.1) Cc: Aleksandr Rybalko , freebsd-embedded@freebsd.org Subject: Re: TL-WR1043: switch X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 00:02:49 -0000 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 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 Fon +49 151 14070811