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/
This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:07 EST