Date: Sat, 3 Dec 2011 22:36:41 +0100 From: Stefan Bethke <stb@lassitu.de> To: Adrian Chadd <adrian@freebsd.org> Cc: Aleksandr Rybalko <ray@dlink.ua>, freebsd-embedded@freebsd.org Subject: Re: TL-WR1043: switch Message-ID: <B114DFDD-66FD-4E80-94FA-AED8AB27793B@lassitu.de> In-Reply-To: <CAJ-VmokrnjhvV8rS5s292UdFM4GbyxXJHNhMmyKyDrAdmiJh3Q@mail.gmail.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> <E29B1787-FF42-4462-81C0-8185F70C45B6@lassitu.de> <CAJ-Vmo=YMTuk6gOsjp15QWpRuBPkdDvM3JvamE6E38MhCsL7iw@mail.gmail.com> <2DB1EAFF-BFEA-4104-8F5A-E4D00BFDF8F9@lassitu.de> <CAJ-VmokrnjhvV8rS5s292UdFM4GbyxXJHNhMmyKyDrAdmiJh3Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 03.12.2011 um 16:47 schrieb Adrian Chadd: > Hi, >=20 > Initial comments (yes, I broke my own rule..) >=20 > * Don't get rid of SCL_PIN / SDA_PIN: instead rename them to > blah_PIN_DEFAULT, and use those defines instead of hardcoding 0 and 1. > I have a "thing" for avoiding hard-coded constants, and this makes it > more obvious that those 0/1 values are pins rather than true/false. > * We should break this out into separate diffs - let's focus right now > on fixing/extending the i2c bus code to work with the "strict" flag > you've introduced. The rest of the diff is GPIO stuff. That way we > can commit it in two parts. = http://www.lassitu.de/freebsd/iicbus-optional-relaxed-bus-semantics.patch > Stuff to look at later: >=20 > * The gpio default stuff is fine (but luis has send me some alternate > hint code to look at too!) - however, the capabilities are either in > or out. What about pullup, pulldown, etc? I'd be happy to review and test luis' code. The code that I added does instantiate each pin with DEFAULT_CAPS (read = and write), sets the name and sets the pin to either read or write. = =46rom ar71xx_gpio.c and ar71xxreg.h it seems that these devices only = support input and output and no other modes. > * Is there any way to make that "configure GPIO from hint" function > generic? Or should we worry about that later on? (eg so the rt305x CPU > support from ray@ can also use this?) sys/dev/gpio/gpiobus.c has no method to set the pin capabilities, only = to report the ones the underlying device offers. So every driver needs = to do it's confuration itself. The code itself certainly could be = factored out. > And my final question: >=20 > Does this actually now work for mainipulating the switch phy? If so: >=20 > * how does it work; I have a userland program that can read and write switch registers (and = PHY registers through that interface). See below. > * do we get per-physical-switch-port statistics somehow? They're there, and the OpenWrt driver has code to read them. I haven't = gotten round to implement that. > * how do I tinker with it next week when I'm over in Melbourne, > talking about this stuff to a group of researchers that want to use > the 1043nd? :) http://www.lassitu.de/freebsd/rtl8366ctl.tbz =46rom the enclosed README: > At this stage, the control program can talk to the switch, and > - print out some configuration information; > - print out some phy information; > - read and write arbitrary switch registers; > - read and write arbitrary phy registers. >=20 > Configuration actions are not implemented yet. I'll try and whip up a command to configure VLANs. 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?B114DFDD-66FD-4E80-94FA-AED8AB27793B>