Luben Tuikov wrote: > On 09/10/05 21:44, Douglas Gilbert wrote: > >>Luben Tuikov wrote: >> >> >>>Signed-off-by: Luben Tuikov <luben_tuikov@xxxxxxxxxxx> >> >> >><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 - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
