--- On Mon, 1/28/08, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > The ideal solution would be to do mapping against a
> different struct
> > device for each port, so that we could maintain the
> proper DMA mask for
> > each of them at all times. However I'm not sure if
> that's possible.
>
> I cannot
--- On Mon, 1/28/08, Robert Hancock <[EMAIL PROTECTED]> wrote:
> The trick is that if an ATAPI device is connected, we (as
> far as I'm
> aware) can't use ADMA mode, so we have to switch that
> port into legacy
> mode.
Can you double check this with the HW architect of the
HW DMA engine of the A
--- On Thu, 1/31/08, Tony Battersby <[EMAIL PROTECTED]> wrote:
> From: Tony Battersby <[EMAIL PROTECTED]>
> Subject: [PATCH] [RFC] sd: make error handling more robust
> To: "James Bottomley" <[EMAIL PROTECTED]>, "Luben Tuikov" <[EMAIL
> PRO
--- On Thu, 1/31/08, Luben Tuikov <[EMAIL PROTECTED]> wrote:
> Negate original:
> if (driver_byte(result) == DRIVER_SENSE ||
> (sense_valid && sense_defered))
> Inspect sense.
>
> Negate your proposed change "&&" ->
--- On Fri, 2/1/08, Tony Battersby <[EMAIL PROTECTED]> wrote:
>
> Also, I disagree about treating recovered error like
> hardware/medium
> error. Recovered error is supposed to mean "the last
> command completed
> successfully, with some recovery action performed by the
> device
> server".
Which
--- On Fri, 2/1/08, Tony Battersby <[EMAIL PROTECTED]> wrote:
> From: Tony Battersby <[EMAIL PROTECTED]>
> Subject: [PATCH] [SCSI] sd: make error handling more robust (v2)
> To: "linux-scsi@vger.kernel.org" , "James
> Bottomley" <[EMAIL PRO
--- On Fri, 2/1/08, Tony Battersby <[EMAIL PROTECTED]> wrote:
>
> I disagree only with this part of the commit:
>
> - good_bytes = (error_sector -
> SCpnt->request->sector) << 9;
> - if (good_bytes < 0 || good_bytes
> >= this_count)
> -
; <[EMAIL PROTECTED]>, "linux-scsi@vger.kernel.org"
> , "Luben Tuikov" <[EMAIL PROTECTED]>, "Salyzyn,
> Mark" <[EMAIL PROTECTED]>
> Date: Sunday, February 3, 2008, 7:14 AM
> On Feb 2, 2008 5:06 PM, James Bottomley
> <[EMAIL PROTECTED]> w
--- On Sat, 2/2/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> From: James Bottomley <[EMAIL PROTECTED]>
> Subject: Re: [PATCH] [SCSI] sd: make error handling more robust (v2)
> To: "Tony Battersby" <[EMAIL PROTECTED]>
> Cc: "linux-scsi@vger.kern
--- On Mon, 2/4/08, Tony Battersby <[EMAIL PROTECTED]> wrote:
> I _really_ _really_ hope that you don't believe that I
> am trying to take
> credit for your work. If you take another look, my original
> patch had
> the following hunk:
>
> +
> + /* Make sure that bad_lba is one of the s
--- On Mon, 2/4/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-02-04 at 01:11 -0800, Luben Tuikov wrote:
> > Looks good except that "End LBA" is usually
> defined
> > to be something of the sort of "the LBA of the
> last
> > logi
--- On Sun, 2/3/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> The enclosure misc device is really just a library providing
> sysfs
> support for physical enclosure devices and their
> components.
Who is the target audience/user of those facilities?
a) The kernel itself needing to read/write SE
--- On Mon, 2/4/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> > > The enclosure misc device is really just a
> library providing
> > > sysfs
> > > support for physical enclosure devices and their
> > > components.
> >
> > Who is the target audience/user of those facilities?
> > a) The kernel it
--- On Mon, 2/4/08, Boaz Harrosh <[EMAIL PROTECTED]> wrote:
> There are 3 usages of sense handling in drivers
>
> 1. sense is available in driver internal structure and is
> mem-copied to upper level
> 2. A CHECK_CONDITION status was returned and the driver
> uses the scsi_eh_prep_cmnd()
>for
--- On Mon, 2/4/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-02-04 at 18:01 -0800, Luben Tuikov wrote:
> > --- On Mon, 2/4/08, James Bottomley
> <[EMAIL PROTECTED]> wrote:
> > > > > The enclosure misc device is really
> just
--- On Mon, 2/4/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> > --- On Mon, 2/4/08, James Bottomley
> <[EMAIL PROTECTED]> wrote:
> > > On Mon, 2008-02-04 at 18:01 -0800, Luben Tuikov
> wrote:
> > > > --- On Mon, 2/4/08, James Bottomley
> &g
--- On Tue, 2/5/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> > > > I guess the same could be said for STGT and
> SCST,
> > > right?
> > >
> > > You mean both of their kernel pieces are modular?
>
> > > That's correct.
> >
> > No, you know very well what I mean.
> >
> > By the same logic you
--- On Tue, 2/5/08, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On Mon, 4 Feb 2008 18:39:22 -0800 (PST)
> Luben Tuikov <[EMAIL PROTECTED]> wrote:
>
> > --- On Mon, 2/4/08, Boaz Harrosh
> <[EMAIL PROTECTED]> wrote:
> > > There are 3 usages of sense
--- On Tue, 2/5/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> > > Wrong ... we don't export non-SCSI devices as
> SCSI
> > > (with the single and
> > > rather annoying exception of ATA via SAT).
> >
> > I didn't say you should do that. I had already
> > mentioned that vendors export such contr
--- On Tue, 2/5/08, Ke Wei <[EMAIL PROTECTED]> wrote:
> + for_each_phy(port->wide_port_phymap, no, j, mvi->chip->n_phy) {
> + mvs_write_port_cfg_addr(mvi, no, PHYR_WIDE_PORT);
> + mvs_write_port_cfg_data(mvi, no , port->wide_port_phymap);
> + } else {
> +
--- On Tue, 2/5/08, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > --- On Tue, 2/5/08, FUJITA Tomonori
> <[EMAIL PROTECTED]> wrote:
> > > On Mon, 4 Feb 2008 18:39:22 -0800 (PST)
> > > Luben Tuikov <[EMAIL PROTECTED]> wrote:
> > >
> >
; drivers/scsi/aic94xx/aic94xx_sas.h would redefine
> ABORT_TASK
> as a different value.
>
> Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
Acked-by: Luben Tuikov <[EMAIL PROTECTED]>
Luben
> ---
> drivers/scsi/aic94xx/aic94xx_sas.h |2 +-
> drive
TED]>, "[EMAIL PROTECTED]" <[EMAIL
> PROTECTED]>, "Mike Snitzer" <[EMAIL PROTECTED]>
> Date: Wednesday, February 6, 2008, 1:54 PM
> Luben Tuikov [mailto:[EMAIL PROTECTED] sez:
> > Just as in your case and Tony's case, which I
> presume
--- On Thu, 2/7/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> This is all a tradeoff. If you want userspace *never* to
> issue raw SCSI
> commands like INQUIRY, we're going to have to provide
> the needed
> information from the kernel via sysfs ... including VPD
> strings. This
> is something
Is there an open iSCSI Target implementation which does NOT
issue commands to sub-target devices via the SCSI mid-layer, but
bypasses it completely?
Luben
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
--- On Fri, 2/8/08, Vladislav Bolkhovitin <[EMAIL PROTECTED]> wrote:
> > Is there an open iSCSI Target implementation which
> does NOT
> > issue commands to sub-target devices via the SCSI
> mid-layer, but
> > bypasses it completely?
>
> What do you mean? To call directly low level backstorage
> S
--- On Fri, 2/8/08, Nicholas A. Bellinger <[EMAIL PROTECTED]> wrote:
> > Is there an open iSCSI Target implementation which
> does NOT
> > issue commands to sub-target devices via the SCSI
> mid-layer, but
> > bypasses it completely?
> >
> >Luben
> >
>
> Hi Luben,
>
> I am guessing you mean
--- On Fri, 2/8/08, Alan Cox <[EMAIL PROTECTED]> wrote:
> The word "illegal" has a precise dictionary
> meaning of "prohibited by
> law". The error messages are therefore incorrect as so
> far nobody has
> made SCSI violations a criminal offence.
>
> This corrects scsi to match various other subsy
--- On Tue, 2/12/08, Kristen Carlson Accardi <[EMAIL PROTECTED]> wrote:
> Hi,
> I apologize for taking so long to review this patch. I
> obviously agree
> wholeheartedly with Luben. The problem I ran into while
> trying to
> design an enclosure management interface for the SATA
> devices is that
--- On Tue, 2/12/08, James Bottomley [EMAIL PROTECTED]> wrote:
> > I apologize for taking so long to review this patch.
> I obviously agree
> > wholeheartedly with Luben. The problem I ran into
> while trying to
> > design an enclosure management interface for the SATA
> devices is that
> > there
--- On Tue, 2/12/08, James Bottomley [EMAIL PROTECTED]> wrote:
> > I understand what you are trying to do - I guess I
> just doubt the value
> > you've added by doing this. I think that
> there's going to be so much
> > customization that system vendors will want to add,
> that they are going
> >
--- Gilbert Wu <[EMAIL PROTECTED]> wrote:
> Fixed the problem that "smartctl -a /dev/some_sata_disk -d ata" does
> not work on SATA device. ( The smartctl v5.38 does need "-d ata"
> option.)
I'm testing my own SATL with "-d sat".
> The aic94xx need to return ATA output register for all ATA com
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Michael Reed wrote:
>
> > as having a unique WWN should be a product requirement, is an indicator of
> > a problem. Shouldn't the proper solution be to have the card repaired?
> > Arbitrarily assigning a WWN could mask or introduce other problems, in
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Luben Tuikov wrote:
> > This still does not justify "let's generate it in the kernel".
>
> Once an admin specifies to use an alternate WWN provision, the method
> used to obtain that WWN is an implementation det
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Luben Tuikov wrote:
> > --- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >> Luben Tuikov wrote:
> >>> This still does not justify "let's generate it in the kernel".
> >> Once an admin spe
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Luben Tuikov wrote:
> > --- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >> Luben Tuikov wrote:
> >>> --- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >>>> Luben Tuikov wrote:
> >>>>&
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Luben Tuikov wrote:
> > --- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >> Luben Tuikov wrote:
> >>> --- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >>>> Luben Tuikov wrote:
> >>>>&
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Matthew Jacob wrote:
> >> The generation algorithm is whatever makes people happy. I would
> >> probably pick a fixed prefix like 0x6C 0x69 0x63 ("lin"), something that
> >> doesn't conflict with IEEE org ids for a long time to come. Then,
> >> get_ran
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Luben Tuikov wrote:
> > What is needed is persistence, regardless of reboots of what OS
> > is running on the host CPU/system. SAS WWNs are properties of
> > the SAS target/initiator port, they are not properties of when
>
--- David Miller <[EMAIL PROTECTED]> wrote:
> From: Luben Tuikov <[EMAIL PROTECTED]>
> Date: Wed, 3 Oct 2007 15:08:48 -0700 (PDT)
>
> > Your "want to get their card working" way of view is very
> > simplistic to justify generating and assigning SAS WW
--- James Bottomley <[EMAIL PROTECTED]> wrote:
>
> For the record, what the current in-kernel aic94xx driver does for this
> case is allow a parameter override to specify the WWN in the case where
> the card burned in one has gone missing or is corrupt. I think this is
> the correctly balanced ap
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> James Bottomley wrote:
> > My problem with auto generated is that it's provably impossible to
> > generate globally unique numbers for WWNs without some internal source
> > of uniqueness (I know sparcs have this in their serial number, but most
> > PCs
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
> James Bottomley wrote:
> > If you remember Rusty's guide to interfaces, this is a level 14 easy to
> > misuse interface: "The obvious use is wrong"; since the obvious use is
> > to put it in module parameters and have the problem go away (for
> > now ...
--- James Smart <[EMAIL PROTECTED]> wrote:
> Here's one pro for setting WWNs at arbitrary times...
>If the box is migrating applications (say containers) that want
>different SAN connectivity, where that connectivity (view) is based
>on their WWN, it would be really nice to selectively
--- Gilbert Wu <[EMAIL PROTECTED]> wrote:
> 1. Create a file "update_bios" in sysfs to allow user to update bios
> from user space.
>
> 2. The BIOS image file can be downloaded from web site
>
>
"http://www.adaptec.com/en-US/downloads/bios_fw/bios_fw_ver?productId=SAS-48300&dn=Adaptec+
You should run "git-update-server-info" in
pub/scm/linux/kernel/git/jgarzik/libata-dev.git.
info/refs disagrees with refs/heads/* .
Luben
--- Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> [ I just sent this upstream to Andrew and Linus ]
>
> Now that I have nailed down the corruption problem
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-10-13 at 16:05 -0600, Matthew Wilcox wrote:
> > On Thu, Oct 11, 2007 at 08:11:21PM -0500, Rob Landley wrote:
> > > My impression from asking questions on the linux-scsi mailing list is
> > > that the
> > > scsi upper/middle/lower layer
--- Rob Landley <[EMAIL PROTECTED]> wrote:
> On Sunday 14 October 2007 7:45:46 pm Luben Tuikov wrote:
> > Matthew's expletive and extremely rude response really shows
> > the general attitude of the linux-scsi people.
>
> No, it doesn't. James Bottomley ha
Being the Application Client, SCSI Core needs entry points
for SCSI Event notifications.
For example, Transport Reset event notification entry is
nowhere to be found. Although to be fare, for this to exist,
SCSI Core needs to have a concept of SCSI Port and it doesn't
have that.
Currently, SCSI
--- Douglas Gilbert <[EMAIL PROTECTED]> wrote:
>
> I seem to be fighting a losing battle against the mindset
That may be the case.
> It is the _transport_ that should block the command,
> if it so chooses. In this case the transport is a
> virtual one between sr/sg and libata and libata should
>
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-01-31 at 09:56 +, Christoph Hellwig wrote:
> > On Tue, Jan 30, 2007 at 03:31:25PM -0800, Wu, Gilbert wrote:
> > > Subject: [PATCH] scsi: Update Aic94xx SAS/SATA Linux open source device
> > > driver for new sequence firmware.
> > >
--- Douglas Gilbert <[EMAIL PROTECTED]> wrote:
> This code was effectively removed from Luben's control
> about 18 months ago and has passed through several sets
Or rather, it was "forked off" of my main development tree.
I guess, bottomley felt more comfortable with controlling
it, that way.
> F
--- "Darrick J. Wong" <[EMAIL PROTECTED]> wrote:
> Laziness, in my case. I suppose it would be useful to document the fact
> that I've made changes to libsas/aic94xx. Though the "what has been
> done" part ... I was hoping the commit messages would suffice.
Doing a rev list on drivers/scsi/aic94
--- John Scarpa <[EMAIL PROTECTED]> wrote:
> Dear Luben,
>
> I am trying to compile the aic94xx for my aic9410 directly into my
> kernel (fc5_64bit-2.6.20)... Is this possible or must it be loaded as a
> module? I am really not wanting to add modular support to my nice neat
> monolithic kerne
--- Tejun Heo <[EMAIL PROTECTED]> wrote:
> Cornelia Huck wrote:
> > On Sat, 31 Mar 2007 00:08:19 +0900,
> > Tejun Heo <[EMAIL PROTECTED]> wrote:
> >
> >> (3) make sure all existing kobjects are released by module exit function.
> >>
> >> For example, let's say there is a hypothetical disk device /
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> I'd favour trying to separate kobject and struct device for this ...
> move all the sysfs stuff into kobject and device only stuff into struct
^^^
Currently the kobject implementation is pure and well-defined. I
AS or SATA drives?
> > >
> > 8 SAS drives
> >
> > I have already received some information from Luben Tuikov and Alexis
> > Bruemmer (he told me that there is a new firmware seq file at Adaptec)
> > and I am sending you the message:
> >
> > Lube
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-06-21 at 21:40 -0700, Mike Anderson wrote:
> > James Bottomley <[EMAIL PROTECTED]> wrote:
> > > A proposal to display the correct form of the LUN would be useful if you
> > > wish to make it? ... The problem is really that SAM specifies
--- Doug Maxey <[EMAIL PROTECTED]> wrote:
> On Fri, 22 Jun 2007 09:11:39 CDT, James Bottomley wrote:
> > On Thu, 2007-06-21 at 21:40 -0700, Mike Anderson wrote:
> > > James Bottomley <[EMAIL PROTECTED]> wrote:
> > > > A proposal to display the correct form of the LUN would be useful if you
> > > >
--- Stefan Richter <[EMAIL PROTECTED]> wrote:
> Hannes Reinecke wrote:
> > why don't we stick with the original implementation like zfcp had it?
> > We can simpley expand the midlayer to add an attribute 'lun'
> > to each scsi_device. This would be the LUN as returned by eg
> > REPORT LUNS.
> > No
--- Stefan Richter <[EMAIL PROTECTED]> wrote:
> My thought was that SCSI core's role would only be to create the
> respective sysfs attributes (thus enforcing uniform naming of the
> attributes), but that the transport layer implementations are
> responsible to feed string representations there; in
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> You're sort of confusing what we display as the LUN and what we
> represent it as internally (admittedly they're the same at the moment).
> The object would be to separate these and the debate is really about
> what to display.
Display this:
"%016l
--- Stefan Richter <[EMAIL PROTECTED]> wrote:
> Do all these transports use the same *name* for the attribute holding
> the target port identifier's?
Sure, it is "tpid".
> In other words, is userspace able to find
> the target port identifier without knowing which transport is at work?
How can t
--- Swen Schillig <[EMAIL PROTECTED]> wrote:
> I think Luben and Stefan suggested a good way to do that, ok apart from the
> be64 bits :-)
What is the objection to the use of be64_to_cpu()?
> So, just use the struct scsi_lun in its full extend, for the sysfs without a
> leading "0x",
> and forg
--- Stefan Richter <[EMAIL PROTECTED]> wrote:
> How about:
>
> union scsi_lun {
> __u8lun[8];
> __be64 lun64;
> __be16 lun16;
> };
I'd rather not even hint that a LUN is to be viewed
as anything integer-like. Just use u8[8] aligned.
(I.e. it is u64 only at the time when
--- Stefan Richter <[EMAIL PROTECTED]> wrote:
> SAM itself speaks of the LUN as 8 bytes quantity as well as 64 bits
> quantity (and 2 bytes quantity as well as 16 bits quantity). Of course
> whether this dualism should be exposed in an API is another question.
"64 bit quantity", the keyword here
A similar change went into the SAS/SATL layer I support
shortly after I posted the version which you forked off.
The git date of the commit is: Tue Feb 7 22:14:54 2006 -0800.
BTW, the problem you're "debugging" may require a protocol
trace and a sequencer update by Adaptec.
Luben
--- On Wed,
--- On Thu, 2/21/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> Look, Luben; I don't mind you making an arse of
> yourself on the mailing
> lists; that's about par for the course nowadays.
No, you just did in this thread by pretending to be any kind of
authority or have an expertise on how to fi
--- On Fri, 2/22/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> The clear nexus I_T and clear nexus I_T_L functions in the
> aic94xx
> specify the SUSPEND_TX flag which causes the sequencer to
> be suspended
> until it receives a RESUME_TX. Unfortunately, nothing ever
> sends the
> resume, so th
oc/scsi/scsi
#cat /proc/partitions
<>
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
= sd.c 1.31 vs edited =
--- 1.31/drivers/scsi/sd.c 2003-06-25 19:34:08 -04:00
+++ edited/sd.c 2005-02-14 17:09:43 -05:00
@@ -1332,8 +1332,8 @@
rscsi_disks[i].device = SDp;
OSM header file.
diff -Nru a/drivers/scsi/adp94xx/adp94xx_osm.h b/drivers/scsi/adp94xx/adp94xx_osm.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/scsi/adp94xx/adp94xx_osm.h 2005-02-16 16:08:12 -05:00
@@ -0,0 +1,1375 @@
+/*
+ * Adaptec ADP94xx SAS HBA device driver for Linux.
+ *
+ * Writ
OSM code. Part 3/3.
+
+/*
+ * Function:
+ * asd_pci_dev_remove()
+ *
+ * Description:
+ * This routine is called when the controller is removed or during
+ * module unloading.
+ */
+static void
+asd_pci_dev_remove(struct pci_dev *pdev)
+{
+ struct asd_softc *asd;
+ unsigned long flags;
+
+ a
OSM code. Part 2/3.
+
+ASD_COMMAND_BUILD_STATUS
+asd_setup_data(struct asd_softc *asd, struct scb *scb, Scsi_Cmnd *cmd)
+{
+ struct asd_ssp_task_hscb *ssp_hscb;
+ struct sg_element *sg;
+ int dir;
+ int error;
+
+ /*
+ * All SSP, STP, and SATA SCBs have their direction
+ * flags and SG
OSM code. Part 1/3.
diff -Nru a/drivers/scsi/adp94xx/adp94xx_osm.c b/drivers/scsi/adp94xx/adp94xx_osm.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/scsi/adp94xx/adp94xx_osm.c 2005-02-16 16:08:12 -05:00
@@ -0,0 +1,1923 @@
+/*
+ * Adaptec ADP94xx SAS HBA device driver for Linux.
+ *
+ * W
IOCTL header file.
diff -Nru a/drivers/scsi/adp94xx/adp94xx_ioctl.h b/drivers/scsi/adp94xx/adp94xx_ioctl.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/scsi/adp94xx/adp94xx_ioctl.h 2005-02-16 16:08:12 -05:00
@@ -0,0 +1,277 @@
+/*
+ * Adaptec ADP94xx SAS HBA driver for Linux - IOCTL data s
IOCTL code.
diff -Nru a/drivers/scsi/adp94xx/adp94xx_ioctl.c b/drivers/scsi/adp94xx/adp94xx_ioctl.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/scsi/adp94xx/adp94xx_ioctl.c 2005-02-16 16:08:12 -05:00
@@ -0,0 +1,1041 @@
+/*
+ * Adaptec ADP94xx SAS HBA driver for Linux - IOCTL interface fo
Hardware interface header file.
diff -Nru a/drivers/scsi/adp94xx/adp94xx_hwi.h b/drivers/scsi/adp94xx/adp94xx_hwi.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/scsi/adp94xx/adp94xx_hwi.h 2005-02-16 16:08:12 -05:00
@@ -0,0 +1,1242 @@
+/*
+ * Adaptec ADP94xx SAS HBA device driver for Linux
Inline functions.
diff -Nru a/drivers/scsi/adp94xx/adp94xx_inline.h b/drivers/scsi/adp94xx/adp94xx_inline.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/scsi/adp94xx/adp94xx_inline.h 2005-02-16 16:08:12 -05:00
@@ -0,0 +1,1075 @@
+/*
+ * Adaptec ADP94xx SAS HBA device driver for Linux.
+ *
Hardware interface. Part 2/3.
+
+/*
+ * Function:
+ * asd_hwi_process_prim_event()
+ *
+ * Description:
+ * Process any recevied primitives that are not handled by the
+ * firmware (eg. BROADCAST, HARD_RESET, etc.)
+ */
+static void
+asd_hwi_process_prim_event(struct asd_softc *asd, struct asd_p
Hardware interface. Part 3/3.
+
+static void
+asd_hwi_reset_device_done(struct asd_softc *asd, struct scb *scb,
+ struct asd_done_list *dl)
+{
+ asd_log(ASD_DBG_ERROR, "DL Opcode = 0x%x.\n", dl->opcode);
+
+ /*
+ * There is a possibility that this post routine is called after
+ * the S
Hardware interface. Part 1/3.
diff -Nru a/drivers/scsi/adp94xx/adp94xx_hwi.c b/drivers/scsi/adp94xx/adp94xx_hwi.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/scsi/adp94xx/adp94xx_hwi.c 2005-02-16 16:08:12 -05:00
@@ -0,0 +1,1976 @@
+/*
+ * Adaptec ADP94xx SAS HBA device driver for Linux.
The drivers' Kconfig and Makefile.
diff -Nru a/drivers/scsi/adp94xx/Kconfig b/drivers/scsi/adp94xx/Kconfig
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/scsi/adp94xx/Kconfig 2005-02-16 16:08:12 -05:00
@@ -0,1 +1,12 @@
+#
+# adp94xx 2.5.x kernel configuration file.
+#
+# $Id: //depot/razor/
Adding a menu option in Kconfig and a compilation directive in Makefile
in SCSI.
diff -Nru a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
--- a/drivers/scsi/Kconfig 2005-02-16 16:08:12 -05:00
+++ b/drivers/scsi/Kconfig 2005-02-16 16:08:12 -05:00
@@ -368,6 +368,8 @@
source "drivers/scsi/aic
Hi,
Adaptec would like to announce its SAS/SATA Linux device driver
for inclusion into the Linux kernel.
The driver supports Adaptec's AIC-94XX chip based, eight port SAS
and SATA 64-bit PCI-X, 133MHz ASIC controller.
The driver source is presented as a broken up BK patch over
the latest scsi-misc-
Hardware registers macro definitions. Part 1/2.
diff -Nru a/drivers/scsi/adp94xx/adp94xx_reg.h b/drivers/scsi/adp94xx/adp94xx_reg.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/scsi/adp94xx/adp94xx_reg.h 2005-02-16 16:08:12 -05:00
@@ -0,0 +1,1224 @@
+/*
+ * Adaptec ADP94xx SAS HBA device
Hardware registers macro definitions. Part 2/2.
+#define LmMnSATAFS(LinkNum, Mode) LmSEQ_PHY_REG(Mode, LinkNum, 0x7E)
+#define LmMnXMTSIZE(LinkNum, Mode) LmSEQ_PHY_REG(Mode, LinkNum, 0x93)
+
+/* mode 0 */
+#define LmMnFRMERR(LinkNum, Mode) LmSEQ_PHY_REG(Mode, LinkNum, 0xB0)
+
+#define LmACRCERR
SAS header file definitions.
diff -Nru a/drivers/scsi/adp94xx/adp94xx_sas.h b/drivers/scsi/adp94xx/adp94xx_sas.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/scsi/adp94xx/adp94xx_sas.h 2005-02-16 16:08:12 -05:00
@@ -0,0 +1,1101 @@
+/*
+ * Adaptec ADP94xx SAS HBA device driver for Linux.
+
Anything SATA related. Part 1/2.
diff -Nru a/drivers/scsi/adp94xx/adp94xx_sata.c b/drivers/scsi/adp94xx/adp94xx_sata.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/scsi/adp94xx/adp94xx_sata.c 2005-02-16 16:08:12 -05:00
@@ -0,0 +1,1891 @@
+/*
+ * Adaptec ADP94xx SAS HBA device driver for
Anything SATA related header file.
diff -Nru a/drivers/scsi/adp94xx/adp94xx_sata.h b/drivers/scsi/adp94xx/adp94xx_sata.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/scsi/adp94xx/adp94xx_sata.h 2005-02-16 16:08:12 -05:00
@@ -0,0 +1,756 @@
+/*
+ * Adaptec ADP94xx SAS HBA device driver for
Anything SATA related. Part 2/2.
+
+ASD_COMMAND_BUILD_STATUS
+asd_sata_control_mode_select(
+struct asd_softc *asd,
+struct asd_device *dev,
+struct scb *scb,
+uint8_t *bufptr
+)
+{
+ if (bufptr[1] != (CONTROL_MODE_PAGE_LEN - 2)) {
+ return ASD_COMMAND_BUILD_FAILED;
+ }
+
+ /*
+ * T10/04-136
Communicating with the sequencers. Part 1/2.
diff -Nru a/drivers/scsi/adp94xx/adp94xx_seq.c b/drivers/scsi/adp94xx/adp94xx_seq.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/scsi/adp94xx/adp94xx_seq.c 2005-02-16 16:08:12 -05:00
@@ -0,0 +1,1470 @@
+/*
+ * Adaptec ADP94xx SAS HBA device dr
Communicating with the sequencers. Part 2/2.
+
+/*
+ * Function:
+ * asd_hwi_post_init_cseq()
+ *
+ * Description:
+ * Clear CSEQ Mode n Interrupt status and Response mailbox.
+ */
+static void
+asd_hwi_post_init_cseq(struct asd_softc *asd)
+{
+ u_int i;
+
+ for (i = 0; i < 8; i++) {
+ asd_hwi
The sequencer programs.
diff -Nru a/drivers/scsi/adp94xx/adp94xx_seq.h b/drivers/scsi/adp94xx/adp94xx_seq.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/scsi/adp94xx/adp94xx_seq.h 2005-02-16 16:08:12 -05:00
@@ -0,0 +1,2840 @@
+/*
+ * Central and Link Sequencer Code for AIC-94xx
+ * Vers
The readme file.
diff -Nru a/drivers/scsi/adp94xx/readme.txt b/drivers/scsi/adp94xx/readme.txt
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/scsi/adp94xx/readme.txt 2005-02-16 16:08:12 -05:00
@@ -0,0 +1,289 @@
+
+=
added that to the subject lines.
"sign your work" is more of a legal sign-off than a notation of
authorship. In some cases, a company lawyer may be the person included
in the signed-off-by line.
Ok, I see. I guess I was a bit shy on that.
Feel free to add "Signed-off-by: Luben
On 02/17/05 14:03, Jeff Garzik wrote:
Luben,
Your emails do not comply with the Linux kernel patch submission format.
Please read
http://linux.yyz.us/patch-format.html
Most critical is rule number #5 (signed-off-by line), but also important
is rule number #1 (providing a useful subject lin
On 02/17/05 15:57, James Bottomley wrote:
Well, the initial reaction is yuk.
Just from a brief glance over the files, the code is full of obfuscation
and unnecessary compatibility gunk which needs removing.
It's also full of the same queueing junk that I asked be taken out of
the aic7xxx driver.
Th
On 02/17/05 16:08, Andi Kleen wrote:
Luben Tuikov <[EMAIL PROTECTED]> writes:
+/** Misc Macros ***/
[... lots of code...]
What are they all good for? As far as I can see every one of them
duplicates or wraps something Linux alrea
On 02/25/05 06:57, Doug Ledford wrote:
struct is silly. Just use what's available, reliable, always
initialized, and intended for you to use (cmd->use_sg) instead of trying
to use a roughly duplicate item from a different abstraction layer that
isn't always involved in commands sent to a low level
On 03/01/05 03:14, Douglas Gilbert wrote:
- scsi_error.c: scsi_normalize_sense
I introduced scsi_normalize_sense() recently, Christoph H.
proposed it should be static but Luben Tuikov (aic7xxx
maintainer) said he wished to use it in the future.
Hence it was left global.
Hi guys,
I think the
1 - 100 of 257 matches
Mail list logo
