| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
We only have to guarantee interoperability for compliant
devices. A device that draw more than 51mA during classification is
noncompliant.
As I pointed out in my comment it was a mistake in AF to
allow a PSE to power a device that has failed classification and that we should
fix that in AT. I'm not concerned that a device that is noncompliant will
not get power from a Type 2 PSE.
The other problem with your remedy is that there is a two
layer slight of hand going on here. If you allow a Type 2 PSE to assign
this noncompliant PD class 0 there is another statement that says the Type 2 PSE
can treat the class 0 PD as Class 4 and now we are back to the start. You
are allowing a noncompliant device to draw up to 30W, therefore enabling dumb
PDs. My opinion is this is completely unacceptable. If I were a
devious designer, I would just draw 60mA during class and then move on to
drawing 30W.
the only thing we have to be careful of is that we are not
making all legacy PSEs noncompliant by removing their ability to power devices
that fail classification as Class 0. I would support your statement if it
said:
If a PSE detects Iclass_lim, it may power the PD strictly at Class 0
levels or it may choose to enter the IDLE mode. A Type 2 PSE that decides
to power a PD that violates Iclass_lim shall limit Pport to 15.4W. In this
case, there is no allowance for the Type 2 PSE to power at Type 2
levels.
or some other equivalent but better wording. I would
want a shall statement that generates a PICS that would check that a PSE will
police at 15.4W if it powers a noncompliant device. Of course we would
also have to figure out how to work this into the state
diagram.
To me the easier solution is to make the decision to not
power these devices.
-Chad
From: Darshan, Yair [mailto:YDarshan@microsemi.com] Sent: Wednesday, May 21, 2008 10:05 AM To: Chad Jones (cmjones); Clay Stanford; Matthew Landry; Fred Schindler (frs); Patoka, Martin; Bill Delveaux (bdelveau); Anoop Vetteth (avetteth); McCormack, Michael; gthompso@nortelnetworks.com; Jetzt, John J (John); Reshef, Tamir; Feldman, Daniel; Rimboim, Pavlick Cc: STDS-802-3-POEP@listserv.ieee.org Subject: Problems with remedy regarding PSE type 2 behaviour when it reads bad classification Hi
guys, I have found a problem
with the remedy on the above subject. We have 3 cases in
which we agree last meeting to return to IDLE
state. Case
1: If PSE type 2 reads
class The rational was that
we don’t want to encourage someone using different coding so we can reserve it
for future use. So far it makes
sense. Case
2: If PSE Type 2 pass
detection successfully and fails to complete classification, it will return to
IDLE state. Rational: Classification in Type
2 PSE and PD is mandatory. If it is not working then probably one of the two
parts PSE or PD is non compliant or defective. Case
3: If PSE detects
Iclass_lim, it will return to IDLE. The problem is in Case
3. Rational: a) If PSE type 2
connected to PD type 1, and PSE reads Iclass_lim then according to last week
change, PSE will return to IDLE state. b) But If PSE type 1
connected to PD type 1, and PSE reads Iclass_lim, PSE is assign Class 0 which
mean the PD will be operated. Which means that in
(a), PD type 1 will not work ever never with PSE type 2 under Iclass_lim and may
work with PSE type 1. This is violates
backwards compatibility and creates interoperability problems between PSE type 1
and PSE type 2 connected to PD type 1 exhibiting
Iclass_lim. The solution for this
problem is: In Case 3 (and maybe
also in case 2) , The PSE type 2 shall assign Class 0 as well as Type 1 PSE, if
it detects Iclass_lim. What is your opinion on
these guys? Yair
Analog Mixed Signal
Group Microsemi
Corporation
Cell:
+972-54-4893019 E-mail: <mailto:ydarshan@microsemi.com>. |