Mitchell Blank Jr wrote:
> Wow, I act as the maintainer for a couple weeks, and I already am
> having a decision appealed to the supreme court ;-)
Yep. Sorry about that.
> 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)
My SAR, the FS50, is especially for DSL modems. I Have no idea how a
physical layer down event would propagate from the PHY side to the
FS50. I cold poll a PHY register maybe. Hmm. OK. that'd be part of
the PHY driver, right?
> * DSL PHYs can support variable link rates which the SAR may need to
> change timing for.
Right: We need separate up and downlink speeds, right?
> * 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;
> }
> };
Isn't this just like folding
write_phy_8
write_phy_16
write_phy_32
read_phy_8
read_phy_16
read_phy_32
..._phy...
all into one?
> 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.
Anyway, if we sit down for an hour and think about it really well, I
think we can come up with something workable for the next few years.
> (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)
If I'd believed in Code freeze, I'd have been stuck since last august.
That's a year now!
> 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
This has no advantages besides being gross over the next one.
> * 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.
I've done this. I'm into the "cleanup" stage now, so I'd rather do it
right, once and for all.
Roger.
-- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of * ****** prejudices acquired by age eighteen. -- Albert Einstein ********- 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/
This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:07 EST