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.038 / U:30.812 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site