Messages in this thread |  | | | Date | Tue, 1 Aug 2000 20:13:14 -0700 | | From | Mitchell Blank Jr <> | | Subject | Re: Interface change: Now or later? |
| |
Wow, I act as the maintainer for a couple weeks, and I already am having a decision appealed to the supreme court ;-)
Rogier Wolff wrote: > The cards that I own have a PHY chip that has a 16-bit interface to > the SAR (main) chip. > > Current ATM SAR drivers have a routine to write PHY chip registers > that has an 8-bit quantity for the value. Simply extending that is not > good, as some SARs know the difference between writing 0012 and 12 > (the first is a 16-bit write the second an 8-bit write) we therefore > need 8, 16, and 32-bit write routines to the phy devices. [...] > I think it is best to change this interface ASAP (i.e. before 2.4). > Mitch thinks it is best to wait for after 2.4 . I think this is > wrong. What do you think?
There are a number of changes that are needed in that interface for this and other reasons. Some others: * The PHYs should be able to propagate link-up/link-down state for physical layers that have a strong connection-oriented basis (DSL) * DSL PHYs can support variable link rates which the SAR may need to change timing for. * Devices that live on a packet-based bus (i.e. USB DSL modems) may want the PHY to queue read/writes into blocks. Currently doing a PHY-initiated firmware upload through the current read8/write8 interface would be pretty painful. I'm not sure if this is best done by offering a "read/write block" operation or a "set of commands" operation. * Some PHY error conditions require it to initiate a SAR reset
So eather we're going to add a lot of function pointers to atm_dev->ops or we need to move to a more generalized request interface, ala:
struct phy_event { enum phy_event_type type; union { u32 val; u8 *u8p; u16 *u16p; u32 *u32p; } }; So the options now are: (1) Go to an all-new interface now. Bad idea - I'm not even 100% sure what I want it to look like yet. It's still a work in progress. 2.5 thing.
(2) Extend the current interface to add read16/write16 to get around your issue. Not a terrible idea, but not one I'm particularly fond of either.
(3) Do nothing and let Linus et al actually ship 2.4.0. I really like this option. I am under no delusion that the ATM stack is a high priority for Linus at this moment, so I don't want to send him any patches that are anything but pure bug fix (I guess I'm old fashioned, but I actually care about code freezes)
There are at least two workable ways to work around this limitation in your driver: * Use the gross hack I emailed you earlier (implement a 8-bit pseudo register that just contains the MSB of the next value written). Yes, this is very gorss, but at least it's a localized gross, and will go away in 2.5
* Don't implement the PHY as a seperate driver - just combine it with your SAR driver. The entire point of having them seperate is that the same PHY will often be used by several different SAR chips. Since yours would currently be the only SAR supporting the 16-bit interface, there is little to gain by having the drivers seperate.
> (Can you talk some sense into him? :-)
Many have tried :-)
-Mitch
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |