On Wed, 2012-11-28 at 19:35 +0000, Conor O'Gorman wrote: > Hi Daniel, > > Thank you for consider my comments. > > There are a couple of points I'd make. AFAIK this is only needed for > ethernet bridging over atm. I am not familiar with an ethernet style > mac > being used in straight atm connections. As far as I can see the field > you are setting is only pulled out by the br2684 driver, which is > providing the ethernet veneer. > > I do see that one or two atm drivers get a serial number from their > hardware, and a few more pull up an eeprom value. > > Would some adjustment in br2684 be more appropriate? > > I have no problem with a hack, if it is recognised as such, with some > intention to improve it later. > > Concerning what MAC to apply, yes some variation on the serial number > is > appropriate. I have in the past used the top bits of the available > space, rather than a simple increment, as it avoids bumping into a > similar unit. > > Conor > The br2684 driver seems to expect that the MAC is already on the device before a virtual circuit is created, but it seems to leave the mechanism for doing so to the ATM driver. The only other working ATM driver in OpenWrt is for AR7, and that has always had the MAC set in the driver itself. If you know of a use case within OpenWrt but without br2684 for the lantiq ATM driver specifically, I'd like to hear it. I don't really like inserting code like this into a place like that, but the only alternative I could think of would be even worse: creating a sysfs node in the ATM driver to receive a list of MAC addresses (since the driver can handle more than one interface) from userspace before any virtual circuit is created. RFC.
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
