lkml.org 
[lkml]   [2005]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2.6.13 2/14] sas-class: README
Luben Tuikov wrote:
> On 09/10/05 21:44, Douglas Gilbert wrote:
>
>>Luben Tuikov wrote:
>>
>>
>>>Signed-off-by: Luben Tuikov <luben_tuikov@adaptec.com>
>>
>>
>><snip>
>>
>>An interesting document.
>
>
> Hi Doug, how are you?

Fine, but loosing a fair amount of time reading emails :-)

> If there is something wrong with the document in general,
> please point it out.
>
> Your "An interesting document" sounds like James's
> "Aside from all other problems".
>
>
>>I have a small quibble here (and a larger
>>one about the SMP user space access that I will elaborate on
>>in a day or so).
>
>
> Ok.
>
> (Thinking to myself: I wonder, if he's got a problem with
> SMP user space access, why not post it now? Why in a day
> or so?)
>
>
>>>+Port events, passed on a _phy_:
>>>+ PORTE_BYTES_DMAED, (M)
>>>+ PORTE_BROADCAST_RCVD, (E)
>>>+ PORTE_LINK_RESET_ERR, (C)
>>>+ PORTE_TIMER_EVENT, (C)
>>>+ PORTE_HARD_RESET.
>>
>>
>>Link layer broadcasts don't only come from expanders
>>(i.e. BROADCAST(CHANGE) ); SAS 1.1 (sas1r09e.pdf) defines
>
>
> I'm aware of what the spec says.
>
>
>>BROADCAST(SES) coming from a target port associated with
>
>
> I'm aware of this primitive.
>
>
>>an enclosure device (SES peripheral type). It is not
>>clear to me how the associated primitive is conveyed back
>>with the broadcast.
>
>
> As you can see the message is "PORTE_BROADCAST_RCVD".
> The _type_ of BROADCAST is encoded in phy->sas_prim.

Good.

> See sas_port.c::void sas_porte_broadcast_rcvd(struct sas_phy *phy).
>
> This function decides what to do depending on the type of
> BROADCAST received.
>
> Currently there have been no requests for handling of
> BROADCAST(SES).
>
> When there's such a request, we handle it there, telling
> the Discover code of a SES event.
>
> Currently only BROADCAST(CHANGE) is handled _by default_.
>
> I.e. we search the domain for the expander and phy which
> generated it, and act on it. If we find no expander and
> phy which generated it, in case we processed a different
> BROADCAST or an expander has broken firmware, we return.
> This is all in the code.
>
> BROADCAST filtering is also present in the LLDD, i.e.
> notify on such and such BROADCAST or primitive in general.
> This is done by the hardware itself (no firmware) so it
> is very fast.
>
>
>>If it is not conveyed back then perhaps that broadcast define
>>could be expanded to:
>> PORTE_BROADCAST_CHANGE (E)
>> PORTE_BROADCAST_SES (Target)
>
>
> I can add this event if you want.

No need, phy->sys_prim is fine.

> The questiong is _what_ to do on this event. This is a complex
> answer and I'd rather have a _SES_ layer (or at least a logical
> module/library) to handle those as storage vendors want this,
> _right now_.

Simple answer: generate a hotplug event and let a
user application that cares worry about it. No
need for a SES layer in the kernel.

> In fact, I've some patches to submit regarding SES devices
> on the domain, but I wanted to _trim *down*_ the politics,
> _not_ escalate them.

Oh no, not a sysfs representation of SES abstractions :-)

> Also this patch was "SAS support", not "SES device support".

True.

>>and a note inserted that BROADCAST(RESERVED CHANGE 0) and
>>BROADCAST(RESERVED CHANGE 1) be mapped to PORTE_BROADCAST_CHANGE
>>by the LLDD as per table 79 of sas1r09e.pdf .
>
>
> They already are Doug.
>
>
>>BTW table 70 indicates an initiator can originate a BROADCAST(CHANGE),
>>not just an expander.
>
>
> I hope this isn't going to be a thread about
> * pointing out the obvious, or
> * some kind of competion of who's read the spec the most.
>
> All in all, you could've just asked "How about BROADCAST(SES)?".

Indeed.

It may be an idea to encourage people who look at
your submission.

Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-09-13 11:24    [W:0.056 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site