lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 1 Feb 2007 13:49:18 -0800
From:	Kristen Carlson Accardi <kristen.c.accardi@...el.com>
To:	"Andy Currid" <ACurrid@...dia.com>
Cc:	"Jeff Garzik" <jeff@...zik.org>, "Peer Chen" <pchen@...dia.com>,
	"Christoph Hellwig" <hch@...radead.org>,
	"Prakash Punnoor" <prakash@...noor.de>,
	"Andrew Morton" <akpm@...l.org>, <linux-kernel@...r.kernel.org>,
	<linux-ide@...r.kernel.org>, "Kuan Luo" <kluo@...dia.com>
Subject: Re: [PATCH] SCSI: Add the SGPIO support for sata_nv.c

On Thu, 1 Feb 2007 11:55:35 -0800
"Andy Currid" <ACurrid@...dia.com> wrote:

> 
> I'm not sure I understand your point. To support SGPIO initiators
> incorporated
> into SATA host controllers, it is pretty much inevitable that some SGPIO
> support
> will have to be added directly into individual drivers for thoese
> controllers;

If SGPIO is defined as a generic protocol, could there be bits that are
used universally by all controllers that support a SGPIO interface, and
then of course chipset specific bits as far as how this is used?  For
example, AHCI 1.1 specifies that Enclosure Management via SGPIO is 
supported, and uses the message interface defined in SFF-8485.  If there
are any parts to your implementation that are remotely standard, it would
be preferrable in my opinion to split them out into a separate file
so that you have vendor specific code in the driver, and generic sgpio
defines in a separate file that can be shared somehow.

Probably I should have more appropriately asked whether there were any
bits in this that could be made common :).

Kristen

> the SGPIO standard does not define a register level interface for
> accessing
> this functionality, so vendor implementations vary.
> 
> It's possible that with an SGPIO initiator integrated within a SAS host
> controller,
> you may be able to use SMP frames to access it, using the messaging
> defined in
> SFF-8485 chapter 8 - but I wouldn't bank on it.
> 
> Andy
> 
> -----Original Message-----
> From: linux-kernel-owner@...r.kernel.org
> [mailto:linux-kernel-owner@...r.kernel.org] On Behalf Of Kristen Carlson
> Accardi
> Sent: Wednesday, January 31, 2007 15:22
> To: Jeff Garzik
> Cc: Peer Chen; Christoph Hellwig; Prakash Punnoor; Andrew Morton;
> linux-kernel@...r.kernel.org; linux-ide@...r.kernel.org; Kuan Luo
> Subject: Re: [PATCH] SCSI: Add the SGPIO support for sata_nv.c
> 
> On Fri, 17 Nov 2006 13:04:30 -0500
> Jeff Garzik <jeff@...zik.org> wrote:
> 
> > Peer Chen wrote:
> > > I didn't get any comment from you guys for new patch, does someone
> take
> > > care this patch, do we still need some modification upon it? Or do
> we
> > > need re-submit it in other thread?
> > 
> > For my part, it's in my queue of things to review.  I need to figure
> out 
> > the best way to export this support.
> > 
> > 	Jeff
> 
> Adding SGPIO support directly into an individual SATA driver seems to be
> a very bad idea since SGPIO is a) a protocol that can be used by many 
> different SATA controllers and is not nvidia specific and b) can also
> be used by SAS.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> -----------------------------------------------------------------------------------
> This email message is for the sole use of the intended recipient(s) and may contain
> confidential information.  Any unauthorized review, use, disclosure or distribution
> is prohibited.  If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.
> -----------------------------------------------------------------------------------
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ