[PATCH] drm/sched: Add missing structure comment
Add a missing structure comment for the recently
added @list member.
Cc: Stephen Rothwell
Cc: Daniel Vetter
Cc: Christian König
Fixes: 8935ff00e3b1 ("drm/scheduler: "node" --> "list"")
Reported-by: Stephen Rothwell
Signed-off-by: Luben Tuikov
---
include/drm/gpu_scheduler.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 2e0c368e19f6..975e8a67947f 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -171,10 +171,10 @@ struct drm_sched_fence *to_drm_sched_fence(struct
dma_fence *f);
* struct drm_sched_job - A job to be run by an entity.
*
* @queue_node: used to append this struct to the queue of jobs in an entity.
+ * @list: a job participates in a "pending" and "done" lists.
* @sched: the scheduler instance on which this job is scheduled.
* @s_fence: contains the fences for the scheduling of job.
* @finish_cb: the callback for the finished fence.
- * @node: used to append this struct to the @drm_gpu_scheduler.pending_list.
* @id: a unique id assigned to each job scheduled on the scheduler.
* @karma: increment on every hang caused by this job. If this exceeds the hang
* limit of the scheduler then the job is marked guilty and will not
--
2.29.2.404.ge67fbf927d
Re: [PATCH] drm/sched: Add missing structure comment
On 2020-12-09 5:24 p.m., Stephen Rothwell wrote:
> Hi Luben,
>
> On Wed, 9 Dec 2020 16:58:07 -0500 Luben Tuikov wrote:
>>
>> Add a missing structure comment for the recently
>> added @list member.
>>
>> Signed-off-by: Luben Tuikov
>>
>> Cc: Stephen Rothwell
>> Cc: Daniel Vetter
>> Cc: Christian König
>
> The commit message tags should all be together at the end of the commit
> message (probably with your SoB last). Also:
>
> Fixes: 8935ff00e3b1 ("drm/scheduler: "node" --> "list"")
> Reported-by: Stephen Rothwell
Right! I was just looking into this as the empty
line up there didn't look good.
I'll resubmit.
Regards,
Luben
[PATCH] drm/sched: Add missing structure comment
Add a missing structure comment for the recently added @list member. Signed-off-by: Luben Tuikov Cc: Stephen Rothwell Cc: Daniel Vetter Cc: Christian König --- include/drm/gpu_scheduler.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h index 2e0c368e19f6..975e8a67947f 100644 --- a/include/drm/gpu_scheduler.h +++ b/include/drm/gpu_scheduler.h @@ -171,10 +171,10 @@ struct drm_sched_fence *to_drm_sched_fence(struct dma_fence *f); * struct drm_sched_job - A job to be run by an entity. * * @queue_node: used to append this struct to the queue of jobs in an entity. + * @list: a job participates in a "pending" and "done" lists. * @sched: the scheduler instance on which this job is scheduled. * @s_fence: contains the fences for the scheduling of job. * @finish_cb: the callback for the finished fence. - * @node: used to append this struct to the @drm_gpu_scheduler.pending_list. * @id: a unique id assigned to each job scheduled on the scheduler. * @karma: increment on every hang caused by this job. If this exceeds the hang * limit of the scheduler then the job is marked guilty and will not -- 2.29.2.404.ge67fbf927d
Re: linux-next: build warning after merge of the drm-misc tree
On 2020-12-09 05:02, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (htmldocs)
> produced this warning:
>
> include/drm/gpu_scheduler.h:201: warning: Function parameter or member 'list'
> not described in 'drm_sched_job'
>
> Introduced by commit
>
> 8935ff00e3b1 ("drm/scheduler: "node" --> "list"")
>
Thanks for the notification.
I'll send out a patch to fix this.
Regards,
Luben
Re: [PATCH 0/3] drm/amd/display: Fix kernel panic by breakpoint
On 2020-10-23 03:46, Takashi Iwai wrote: > Hi, > > the amdgpu driver's ASSERT_CRITICAL() macro calls the > kgdb_breakpoing() even if no debug option is set, and this leads to a > kernel panic on distro kernels. The first two patches are the > oneliner fixes for those, while the last one is the cleanup of those > debug macros. This looks like good work and solid. Hopefully it gets picked up. Regards, Luben > > > Takashi > > === > > Takashi Iwai (3): > drm/amd/display: Fix kernel panic by dal_gpio_open() error > drm/amd/display: Don't invoke kgdb_breakpoint() unconditionally > drm/amd/display: Clean up debug macros > > drivers/gpu/drm/amd/display/Kconfig | 1 + > drivers/gpu/drm/amd/display/dc/gpio/gpio_base.c | 4 +-- > drivers/gpu/drm/amd/display/dc/os_types.h | 33 > + > 3 files changed, 15 insertions(+), 23 deletions(-) >
Re: [Linux-kernel-mentees] [PATCH] drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()
On 2020-07-29 9:49 a.m., Alex Deucher wrote:
> On Wed, Jul 29, 2020 at 4:11 AM Christian König
> wrote:
>>
>> Am 28.07.20 um 21:29 schrieb Peilin Ye:
>>> Compiler leaves a 4-byte hole near the end of `dev_info`, causing
>>> amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace
>>> when `size` is greater than 356.
>>>
>>> In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, which
>>> unfortunately does not initialize that 4-byte hole. Fix it by using
>>> memset() instead.
>>>
>>> Cc: sta...@vger.kernel.org
>>> Fixes: c193fa91b918 ("drm/amdgpu: information leak in amdgpu_info_ioctl()")
>>> Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
>>> Suggested-by: Dan Carpenter
>>> Signed-off-by: Peilin Ye
>>
>> Reviewed-by: Christian König
>>
>> I can't count how many of those we have fixed over the years.
>>
>> At some point we should probably document that using "= {}" or "= { 0 }"
>> in the kernel is a really bad idea and should be avoided.
>
> Moreover, it seems like different compilers seem to behave relatively
> differently with these and we often get reports of warnings with these
> on clang. When in doubt, memset.
There are quite a few of those under drivers/gpu/drm, for "amd/", "scheduler/"
drm*.c files,
$find . \( -regex "./drm.*\.c" -or -regex "./amd/.*\.c" -or -regex
"./scheduler/.*\.c" \) -exec egrep -n -- " *= *{ *(|NULL|0) *}" \{\} \+ | wc -l
374
$_
Out of which only 16 are of the non-ISO C variety, "= {}",
$find . \( -regex "./drm.*\.c" -or -regex "./amd/.*\.c" -or -regex
"./scheduler/.*\.c" \) -exec egrep -n -- " *= *{ *}" \{\} \+ | wc -l
16
$_
Perhaps the latter are the more pressing ones, since it is a C++ initializer
and not a ISO C one.
Regards,
Luben
>
> Alex
>
>>
>> Thanks,
>> Christian.
>>
>>> ---
>>> $ pahole -C "drm_amdgpu_info_device" drivers/gpu/drm/amd/amdgpu/amdgpu_kms.o
>>> struct drm_amdgpu_info_device {
>>> __u32 device_id;/* 0 4 */
>>> __u32 chip_rev; /* 4 4 */
>>> __u32 external_rev; /* 8 4 */
>>> __u32 pci_rev; /*12 4 */
>>> __u32 family; /*16 4 */
>>> __u32 num_shader_engines; /*20 4 */
>>> __u32 num_shader_arrays_per_engine; /*24
>>> 4 */
>>> __u32 gpu_counter_freq; /*28 4 */
>>> __u64 max_engine_clock; /*32 8 */
>>> __u64 max_memory_clock; /*40 8 */
>>> __u32 cu_active_number; /*48 4 */
>>> __u32 cu_ao_mask; /*52 4 */
>>> __u32 cu_bitmap[4][4]; /*5664 */
>>> /* --- cacheline 1 boundary (64 bytes) was 56 bytes ago --- */
>>> __u32 enabled_rb_pipes_mask; /* 120 4 */
>>> __u32 num_rb_pipes; /* 124 4 */
>>> /* --- cacheline 2 boundary (128 bytes) --- */
>>> __u32 num_hw_gfx_contexts; /* 128 4 */
>>> __u32 _pad; /* 132 4 */
>>> __u64 ids_flags;/* 136 8 */
>>> __u64 virtual_address_offset; /* 144 8 */
>>> __u64 virtual_address_max; /* 152 8 */
>>> __u32 virtual_address_alignment; /* 160 4
>>> */
>>> __u32 pte_fragment_size;/* 164 4 */
>>> __u32 gart_page_size; /* 168 4 */
>>> __u32 ce_ram_size; /* 172 4 */
>>> __u32 vram_type;/* 176 4 */
>>> __u32 vram_bit_width; /* 180 4 */
>>> __u32 vce_harvest_config; /* 184 4 */
>>> __u32 gc_double_offchip_lds_buf; /* 188 4
>>> */
>>> /* --- cacheline 3 boundary (192 bytes) --- */
>>> __u64 prim_buf_gpu_addr;/* 192 8 */
>>> __u64 pos_buf_gpu_addr; /* 200 8 */
>>> __u64 cntl_sb_buf_gpu_addr; /* 208 8 */
>>> __u64 param_buf_gpu_addr; /* 216 8 */
>>> __u32 prim_buf_size;/* 224 4 */
>>> __u32 pos_buf_size; /* 228 4 */
>>> __u32 cntl_sb_buf_size; /* 232 4 */
>>> __u32 param_buf_size; /* 236 4 */
>>> __u32 wave_front_size; /* 240 4 */
>>>
Re: [RFC 02/17] dma-fence: basic lockdep annotations
On 2020-05-12 4:59 a.m., Daniel Vetter wrote:
> Design is similar to the lockdep annotations for workers, but with
> some twists:
>
> - We use a read-lock for the execution/worker/completion side, so that
> this explicit annotation can be more liberally sprinkled around.
> With read locks lockdep isn't going to complain if the read-side
> isn't nested the same way under all circumstances, so ABBA deadlocks
> are ok. Which they are, since this is an annotation only.
>
> - We're using non-recursive lockdep read lock mode, since in recursive
> read lock mode lockdep does not catch read side hazards. And we
> _very_ much want read side hazards to be caught. For full details of
> this limitation see
>
> commit e91498589746065e3ae95d9a00b068e525eec34f
> Author: Peter Zijlstra
> Date: Wed Aug 23 13:13:11 2017 +0200
>
> locking/lockdep/selftests: Add mixed read-write ABBA tests
>
> - To allow nesting of the read-side explicit annotations we explicitly
> keep track of the nesting. lock_is_held() allows us to do that.
>
> - The wait-side annotation is a write lock, and entirely done within
> dma_fence_wait() for everyone by default.
>
> - To be able to freely annotate helper functions I want to make it ok
> to call dma_fence_begin/end_signalling from soft/hardirq context.
> First attempt was using the hardirq locking context for the write
> side in lockdep, but this forces all normal spinlocks nested within
> dma_fence_begin/end_signalling to be spinlocks. That bollocks.
>
> The approach now is to simple check in_atomic(), and for these cases
> entirely rely on the might_sleep() check in dma_fence_wait(). That
> will catch any wrong nesting against spinlocks from soft/hardirq
> contexts.
>
> The idea here is that every code path that's critical for eventually
> signalling a dma_fence should be annotated with
> dma_fence_begin/end_signalling. The annotation ideally starts right
> after a dma_fence is published (added to a dma_resv, exposed as a
> sync_file fd, attached to a drm_syncobj fd, or anything else that
> makes the dma_fence visible to other kernel threads), up to and
> including the dma_fence_wait(). Examples are irq handlers, the
> scheduler rt threads, the tail of execbuf (after the corresponding
> fences are visible), any workers that end up signalling dma_fences and
> really anything else. Not annotated should be code paths that only
> complete fences opportunistically as the gpu progresses, like e.g.
> shrinker/eviction code.
>
> The main class of deadlocks this is supposed to catch are:
>
> Thread A:
>
> mutex_lock(A);
> mutex_unlock(A);
>
> dma_fence_signal();
>
> Thread B:
>
> mutex_lock(A);
> dma_fence_wait();
> mutex_unlock(A);
>
> Thread B is blocked on A signalling the fence, but A never gets around
> to that because it cannot acquire the lock A.
>
> Note that dma_fence_wait() is allowed to be nested within
> dma_fence_begin/end_signalling sections. To allow this to happen the
> read lock needs to be upgraded to a write lock, which means that any
> other lock is acquired between the dma_fence_begin_signalling() call and
> the call to dma_fence_wait(), and still held, this will result in an
> immediate lockdep complaint. The only other option would be to not
> annotate such calls, defeating the point. Therefore these annotations
> cannot be sprinkled over the code entirely mindless to avoid false
> positives.
>
> v2: handle soft/hardirq ctx better against write side and dont forget
> EXPORT_SYMBOL, drivers can't use this otherwise.
>
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-r...@vger.kernel.org
> Cc: amd-...@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Cc: Chris Wilson
> Cc: Maarten Lankhorst
> Cc: Christian König
> Signed-off-by: Daniel Vetter
> ---
> drivers/dma-buf/dma-fence.c | 53 +
> include/linux/dma-fence.h | 12 +
> 2 files changed, 65 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 6802125349fb..d5c0fd2efc70 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -110,6 +110,52 @@ u64 dma_fence_context_alloc(unsigned num)
> }
> EXPORT_SYMBOL(dma_fence_context_alloc);
>
> +#ifdef CONFIG_LOCKDEP
> +struct lockdep_map dma_fence_lockdep_map = {
> + .name = "dma_fence_map"
> +};
> +
> +bool dma_fence_begin_signalling(void)
> +{
> + /* explicitly nesting ... */
> + if (lock_is_held_type(_fence_lockdep_map, 1))
> + return true;
> +
> + /* rely on might_sleep check for soft/hardirq locks */
> + if (in_atomic())
> + return true;
> +
> + /* ... and non-recursive readlock */
> + lock_acquire(_fence_lockdep_map, 0, 0, 1, 1, NULL, _RET_IP_);
> +
> + return false;
> +}
> +EXPORT_SYMBOL(dma_fence_begin_signalling);
Hi Daniel,
This is great work and
Re: [PATCH] enclosure: add support for enclosure services
--- 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 > > to wind up adding a custom library regardless, so > standardising those > > few things won't buy us anything. > > It depends ... if you actually have a use for the > customisations, yes. > If you just want the basics of who (what's in the > enclousure), what > (activity) and where (locate) then I think it solves your > problem almost > entirely. If the kernel doesn't solve it "entirely", then it is better off without the kernel bloat. In fact vendors would distribute their own user-space application(s) to provide a consistent and complete solution(s) of their product(s) to their customer(s). This could also be achieved via "sg_ses", which can also control custom vendor pages if the encodings are known by the customer (which they would be if they purchased the product). > So, entirely as a straw horse, tell me what else your > enclosures provide > that I haven't listed in the four points. You shouldn't insist on this. It should already be clear to you this direction isn't the vendor's preference. > The SES > standards too provide > a huge range of things that no-one ever seems to implement > (temperature, > power, fan speeds etc). Vendors do use "temperature, power and fan speeds" and in fact more features, some of them completely custom for their product, since they end up writing the SES device server of the enclosure themselves (for their product). This kind of control and representation is better left to user-space. The kernel neither needs to represent it nor know about it, since it is itself not using nor controlling it. > I think the users of enclosures fall int these categories This statement (above) really means that the numbers below are but merely the speculation of one person. > > 85% just want to know where their device actually is (i.e. > that sdc is > in enclosure slot 5) > 50% like watching the activity lights > 30% want to be able to have a visual locate function > 20% want a visual failure indication (the other 80% rely on > some OS > notification instead) > > When you add up the overlapping needs, you get about 90% of > people happy > with the basics that the enclosure services provide. 90% doesn't make it a necessary requirement for the kernel to have this, as well as the fact that the kernel is neither needing this to function properly, nor using it. > Could there be more ... sure; should there be more ... I don't think > so ... that's what value add the user libraries can provide. "should there be more ... I don't think so" This decision isn't yours to make. In fact such a decision is never made by one person only. This decision is made by 1) the industry, 2) the customers and 3) vendors by the pricing of their product(s). Luben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] enclosure: add support for enclosure services
--- 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 is all this vendor defined stuff. For example, > for the AHCI LED > > protocol, the only "defined" LED is > 'activity'. For LED2 and LED3 it > > is up to hardware vendors to define these. For SGPIO > there's all kinds > > of ways for hw vendors to customize. I felt that it > was going to be a > > maintainance nightmare to have to keep track of > various vendors > > enclosure implementations in the ahci driver, and that > it'd be better > > to just have user space libraries take care of that. > Plus, that way a > > vendor doesn't have to get a patch into the kernel > to get their new > > spiffy wizzy bang blinky lights working (think of how > long it takes > > something to even get into a vendor kernel, which is > what these guys > > care about...). So I'm still not sold on having > an enclosure > > abstraction in the kernel - at least for the SATA > controllers. > > Correct me if I'm wrong, but didn't the original > AHCI enclosure patch > expose activity LEDs via sysfs? > > I'm not saying there aren't a lot of non standard > pieces that need to be > activated by direct commands or other user activated > protocol. I am > saying there are a lot of standard pieces that we could do > with showing > in a uniform manner. Which is already the case without the SES kernel bloat. Case in point, the excellent user-space application "lsscsi" would clearly show which device is SES. And the excellent user-space application "sg_ses" could control an SES device. > The pieces I think are absolutely standard are > > 1. Actual enclosure presence (is this device in an > enclosure) "lsscsi" > 2. Activity LED, this seems to be a feature of every > enclosure. So that means that it needs a kernel representation? If this indeed were the case, for every "feature" of every type of device (not only SCSI) then the kernel itself would be insurmountably big. > I also think the following are reasonably standard (based > on the fact > that most enclosure standards recommend but don't > require this): > > 3. Locate LED (for locating the device). Even if you only > have an > activity LED, this is usually done by flashing the activity > LED in a > well defined pattern. > 4. Fault. this is the least standardised of the lot, but > does seem to > be present in about every enclosure implementation. > > All I've done is standardise these four pieces ... the > services actually > take into account that it might not be possible to do > certain of these > (like fault). And none of this means that it needs a kernel representation. 1. You're not "standardizing" any known, in-practice, kernel representation, that is already in practice and thusly needs a kernel representation. 2. The kernel itself is not using nor needing this "representation" in order to function properly (the kernel). Leaving control of SES devices to user-space makes both the kernel and the vendors happy. All the kernel needs to do is expose the SES device to user-space as it currently does. It makes it so much easier both to vendors and to the kernel to stay out of unnecessary representations. Vendors may choose to distribute their own applications to control their hardware, as long as the kernel exposes an SES device and provides functionality, as opposed to policy of any kind. Luben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] enclosure: add support for enclosure services
--- 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 is all this vendor defined stuff. For example, for the AHCI LED protocol, the only defined LED is 'activity'. For LED2 and LED3 it is up to hardware vendors to define these. For SGPIO there's all kinds of ways for hw vendors to customize. I felt that it was going to be a maintainance nightmare to have to keep track of various vendors enclosure implementations in the ahci driver, and that it'd be better to just have user space libraries take care of that. Plus, that way a vendor doesn't have to get a patch into the kernel to get their new spiffy wizzy bang blinky lights working (think of how long it takes something to even get into a vendor kernel, which is what these guys care about...). So I'm still not sold on having an enclosure abstraction in the kernel - at least for the SATA controllers. Correct me if I'm wrong, but didn't the original AHCI enclosure patch expose activity LEDs via sysfs? I'm not saying there aren't a lot of non standard pieces that need to be activated by direct commands or other user activated protocol. I am saying there are a lot of standard pieces that we could do with showing in a uniform manner. Which is already the case without the SES kernel bloat. Case in point, the excellent user-space application lsscsi would clearly show which device is SES. And the excellent user-space application sg_ses could control an SES device. The pieces I think are absolutely standard are 1. Actual enclosure presence (is this device in an enclosure) lsscsi 2. Activity LED, this seems to be a feature of every enclosure. So that means that it needs a kernel representation? If this indeed were the case, for every feature of every type of device (not only SCSI) then the kernel itself would be insurmountably big. I also think the following are reasonably standard (based on the fact that most enclosure standards recommend but don't require this): 3. Locate LED (for locating the device). Even if you only have an activity LED, this is usually done by flashing the activity LED in a well defined pattern. 4. Fault. this is the least standardised of the lot, but does seem to be present in about every enclosure implementation. All I've done is standardise these four pieces ... the services actually take into account that it might not be possible to do certain of these (like fault). And none of this means that it needs a kernel representation. 1. You're not standardizing any known, in-practice, kernel representation, that is already in practice and thusly needs a kernel representation. 2. The kernel itself is not using nor needing this representation in order to function properly (the kernel). Leaving control of SES devices to user-space makes both the kernel and the vendors happy. All the kernel needs to do is expose the SES device to user-space as it currently does. It makes it so much easier both to vendors and to the kernel to stay out of unnecessary representations. Vendors may choose to distribute their own applications to control their hardware, as long as the kernel exposes an SES device and provides functionality, as opposed to policy of any kind. Luben -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] enclosure: add support for enclosure services
--- 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 > there is all this vendor defined stuff. For example, for > the AHCI LED > protocol, the only "defined" LED is > 'activity'. For LED2 and LED3 it > is up to hardware vendors to define these. For SGPIO > there's all kinds > of ways for hw vendors to customize. I felt that it was > going to be a > maintainance nightmare to have to keep track of various > vendors > enclosure implementations in the ahci driver, and that > it'd be better > to just have user space libraries take care of that. Plus, > that way a > vendor doesn't have to get a patch into the kernel to > get their new > spiffy wizzy bang blinky lights working (think of how long > it takes > something to even get into a vendor kernel, which is what > these guys > care about...). So I'm still not sold on having an > enclosure > abstraction in the kernel - at least for the SATA > controllers. And I agree wholeheartedly with Kristen. Luben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] enclosure: add support for enclosure services
--- 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 there is all this vendor defined stuff. For example, for the AHCI LED protocol, the only defined LED is 'activity'. For LED2 and LED3 it is up to hardware vendors to define these. For SGPIO there's all kinds of ways for hw vendors to customize. I felt that it was going to be a maintainance nightmare to have to keep track of various vendors enclosure implementations in the ahci driver, and that it'd be better to just have user space libraries take care of that. Plus, that way a vendor doesn't have to get a patch into the kernel to get their new spiffy wizzy bang blinky lights working (think of how long it takes something to even get into a vendor kernel, which is what these guys care about...). So I'm still not sold on having an enclosure abstraction in the kernel - at least for the SATA controllers. And I agree wholeheartedly with Kristen. Luben -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scsi_error: Fix language abuse.
--- 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 subsystems
> I've slowly been
> ridding of this.
>
> Pedantically-signed-off-by: Alan Cox
> <[EMAIL PROTECTED]>
Alan,
In standards and in hardware specs, from which the meaning of
"illegal" is borrowed from (into standards), "illegal" doesn't
necessarily mean "invalid", and cannot be substituted for.
This is exactly why this particular word is used in the ASC/ASCQ
assignments. It exposes an underlying behaviour.
For example:
> - {0x2004, "Illegal command while in write capable state"},
> + {0x2004, "Invalid command while in write capable state"},
Consider this: the command itself can be very perfectly "valid",
e.g. the SCB contents, format, etc., but certainly "illegal".
Similarly for the rest of this patch.
Luben
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scsi_error: Fix language abuse.
--- 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 subsystems
I've slowly been
ridding of this.
Pedantically-signed-off-by: Alan Cox
[EMAIL PROTECTED]
Alan,
In standards and in hardware specs, from which the meaning of
illegal is borrowed from (into standards), illegal doesn't
necessarily mean invalid, and cannot be substituted for.
This is exactly why this particular word is used in the ASC/ASCQ
assignments. It exposes an underlying behaviour.
For example:
- {0x2004, Illegal command while in write capable state},
+ {0x2004, Invalid command while in write capable state},
Consider this: the command itself can be very perfectly valid,
e.g. the SCB contents, format, etc., but certainly illegal.
Similarly for the rest of this patch.
Luben
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Scst-devel] Integration of SCST in the mainstream Linux kernel
--- 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 futher down the stack, which I > don't know this to Yes, that's what I meant. > be the case. Going futher up the layers is the design of > v2.9 LIO-SE. > There is a diagram explaining the basic concepts from a > 10,000 foot > level. > > http://linux-iscsi.org/builds/user/nab/storage-engine-concept.pdf Thanks! Luben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Integration of SCST in the mainstream Linux kernel
--- 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 > SCSI drivers > queuecommand() routine? What are advantages of it? Yes, that's what I meant. Just curious. Thanks, Luben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Integration of SCST in the mainstream Linux kernel
--- 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 SCSI drivers queuecommand() routine? What are advantages of it? Yes, that's what I meant. Just curious. Thanks, Luben -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Scst-devel] Integration of SCST in the mainstream Linux kernel
--- 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 futher down the stack, which I don't know this to Yes, that's what I meant. be the case. Going futher up the layers is the design of v2.9 LIO-SE. There is a diagram explaining the basic concepts from a 10,000 foot level. http://linux-iscsi.org/builds/user/nab/storage-engine-concept.pdf Thanks! Luben -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Scst-devel] Integration of SCST in the mainstream Linux kernel
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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Scst-devel] Integration of SCST in the mainstream Linux kernel
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-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] enclosure: add support for enclosure services
--- 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 controls > > as either enclosure or processor type devices, > > and this is why I told you that that is what > > needs to be exported, which incidentally is > > a device node of that type. > > > > Without a common usage model already in the kernel > > to abstract (e.g. sd for block device, since you > brought > > that up) your abstraction seems redundant and > arbitrary. > > Exactly, so the first patch in this series (a while ago ^^^ See last paragraph. > now) was a > common usage model abstraction of enclosures, and the > second was an > implementation in terms of SES. I will do one in terms of > SGPIO as > well ... assuming I ever find a SGPIO enclosure ... The vendor would've abstracted that away most commonly using SES. > > > Your kernel code already uses READ DIAGNOSTIC, etc, > > and I'd rather leave that to user-space. > > You can do it in user space as well. It's just a bit > difficult to get > information out of a SES enclosure without using it, and > getting some of > the information is a requirement of the abstraction. You missed my point. Your abstraction is redundant and arbitrary -- it is not based on any known, in-practice, usage model, already in place that needs a better, common way of doing XYZ, and therefore needs an abstraction. Luben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] enclosure: add support for enclosure services
--- 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're preaching to include your > > solution part of the kernel, you can also apply to > > SCST. > > Ah, but it's not ... the current patch is merely > exporting an interface. > The debate in STGT vs SCST is not whether to export an > interface but > where to draw the line. "draw the line" -- I see. BTW, what is wrong with "exporting the interface"? What is wrong if both implementations are in the kernel and then let the users and distros decide which one they like best and use more? It'll not be the fist time this has happened in the kernel. Both are actively maintained. It seems highly arbitrary to say: "X is in the kernel, Y is not. If you want Y, just forget about it and fix X." Give people choice at config time. This is off topic anyway. > You could also argue in the same vein that sd is redundant > because a > filesystem could talk directly to the device via /dev/sgX > (in fact OSD > based filesystems already do this). Yes, I've mentioned this thing before on this list. Oh, maybe 3 years ago. This is why I had wanted for transport protocols to export ... (oh, let's not get this off topic). (Apparently it takes 3 years...) > The argument is true, > but misses > the bigger picture that the interfaces exported by sd are > more portable > (apply to non-SCSI block devices) and easier to use. It isn't quite the same thing. It's like comparing apples to oranges. > > > > > Yes, for which the transport layer, > implements the > > > > scsi device node for the SES device. It > doesn't > > > really > > > > matter if the SCSI commands sent to the SES > device go > > > > over SGPIO or FC or SAS or Bluetooth or I2C, > etc, the > > > > transport layer can implement that and > present the > > > > /dev/sgX node. > > > > > > But it does matter if the enclosure device > doesn't > > > speak SCSI. > > > > Enclosure management isn't as simple as you're > > portraying it here. The enclosure management > > device speaks either SES or SAF-TE. The transport > > protocol to access it could be SGPIO or I2C or... > > Look, just read the spec; SGPIO is a bus for driving > enclosures ... I thought Serial General Purpose Input Output (SGPIO) was a method to serialize general purpose IO signals. > it > doesn't require SES or SAF-TE or even any SCSI > protocol. That's true. And this is why I mentioned a couple of emails ago to simply export a sgpio device node *IF* this is what is needed. Of course devices that use SGPIO abstract it away for their functional purpose, e.g. enclosures, LED, etc, and provide a more general way to control it -- highly hardware specific on one side. Your abstraction currently deals with "SES" devices and I'd rather leave that to user-space. Alternatively, which I presume is what you're thinking, a HW specific core would be using your "abstraction" to provide some unified access to raw features, and that "unified access" isn't defined anywhere, and would likely not be. Alternatively that "unified access" is things like SES and SAF-TE, which is what vendors prefer to export, or they prefer to drive this directly via other means. That is, I fail to see the kernel bloat, for things that aren't necessary in the kernel. If you want your abstraction to fly, it first needs a common usage model to abstract, and the latter is missing _from the kernel_. Unless I don't know the details and you've been asked to implement this for a single vendor's HW solution. > > > SGPIO > > > isn't a SCSI protocol ... it's a general > purpose > > > serial bus protocol. > > > It's pretty simple and register based, but it > might (or > > > might not) be > > > accessible via a SCSI bridge. > > > > I see. You've just discovered SGPIO -- good for > you. > > > > At any rate, I told you already that what is needed > > is not what you've provided but a _device node_ > > exported by the kernel, either a processor or > > enclosure type. > > 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 controls as either enclosure or processor type devices, and this is why I told you that that is what needs to be exported, which incidentally is a device node of that type. Without a common usage model already in the kernel to abstract (e.g. sd for block device, since you brought that up) your abstraction seems redundant and arbitrary. Your kernel code already uses READ DIAGNOSTIC, etc, and I'd rather leave that to user-space. Luben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo
Re: [PATCH] enclosure: add support for enclosure services
--- 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're preaching to include your solution part of the kernel, you can also apply to SCST. Ah, but it's not ... the current patch is merely exporting an interface. The debate in STGT vs SCST is not whether to export an interface but where to draw the line. draw the line -- I see. BTW, what is wrong with exporting the interface? What is wrong if both implementations are in the kernel and then let the users and distros decide which one they like best and use more? It'll not be the fist time this has happened in the kernel. Both are actively maintained. It seems highly arbitrary to say: X is in the kernel, Y is not. If you want Y, just forget about it and fix X. Give people choice at config time. This is off topic anyway. You could also argue in the same vein that sd is redundant because a filesystem could talk directly to the device via /dev/sgX (in fact OSD based filesystems already do this). Yes, I've mentioned this thing before on this list. Oh, maybe 3 years ago. This is why I had wanted for transport protocols to export ... (oh, let's not get this off topic). (Apparently it takes 3 years...) The argument is true, but misses the bigger picture that the interfaces exported by sd are more portable (apply to non-SCSI block devices) and easier to use. It isn't quite the same thing. It's like comparing apples to oranges. Yes, for which the transport layer, implements the scsi device node for the SES device. It doesn't really matter if the SCSI commands sent to the SES device go over SGPIO or FC or SAS or Bluetooth or I2C, etc, the transport layer can implement that and present the /dev/sgX node. But it does matter if the enclosure device doesn't speak SCSI. Enclosure management isn't as simple as you're portraying it here. The enclosure management device speaks either SES or SAF-TE. The transport protocol to access it could be SGPIO or I2C or... Look, just read the spec; SGPIO is a bus for driving enclosures ... I thought Serial General Purpose Input Output (SGPIO) was a method to serialize general purpose IO signals. it doesn't require SES or SAF-TE or even any SCSI protocol. That's true. And this is why I mentioned a couple of emails ago to simply export a sgpio device node *IF* this is what is needed. Of course devices that use SGPIO abstract it away for their functional purpose, e.g. enclosures, LED, etc, and provide a more general way to control it -- highly hardware specific on one side. Your abstraction currently deals with SES devices and I'd rather leave that to user-space. Alternatively, which I presume is what you're thinking, a HW specific core would be using your abstraction to provide some unified access to raw features, and that unified access isn't defined anywhere, and would likely not be. Alternatively that unified access is things like SES and SAF-TE, which is what vendors prefer to export, or they prefer to drive this directly via other means. That is, I fail to see the kernel bloat, for things that aren't necessary in the kernel. If you want your abstraction to fly, it first needs a common usage model to abstract, and the latter is missing _from the kernel_. Unless I don't know the details and you've been asked to implement this for a single vendor's HW solution. SGPIO isn't a SCSI protocol ... it's a general purpose serial bus protocol. It's pretty simple and register based, but it might (or might not) be accessible via a SCSI bridge. I see. You've just discovered SGPIO -- good for you. At any rate, I told you already that what is needed is not what you've provided but a _device node_ exported by the kernel, either a processor or enclosure type. 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 controls as either enclosure or processor type devices, and this is why I told you that that is what needs to be exported, which incidentally is a device node of that type. Without a common usage model already in the kernel to abstract (e.g. sd for block device, since you brought that up) your abstraction seems redundant and arbitrary. Your kernel code already uses READ DIAGNOSTIC, etc, and I'd rather leave that to user-space. Luben -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] enclosure: add support for enclosure services
--- 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 controls as either enclosure or processor type devices, and this is why I told you that that is what needs to be exported, which incidentally is a device node of that type. Without a common usage model already in the kernel to abstract (e.g. sd for block device, since you brought that up) your abstraction seems redundant and arbitrary. Exactly, so the first patch in this series (a while ago ^^^ See last paragraph. now) was a common usage model abstraction of enclosures, and the second was an implementation in terms of SES. I will do one in terms of SGPIO as well ... assuming I ever find a SGPIO enclosure ... The vendor would've abstracted that away most commonly using SES. Your kernel code already uses READ DIAGNOSTIC, etc, and I'd rather leave that to user-space. You can do it in user space as well. It's just a bit difficult to get information out of a SES enclosure without using it, and getting some of the information is a requirement of the abstraction. You missed my point. Your abstraction is redundant and arbitrary -- it is not based on any known, in-practice, usage model, already in place that needs a better, common way of doing XYZ, and therefore needs an abstraction. Luben -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] enclosure: add support for enclosure services
--- 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 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 > SES pages? > > > > > > That depends on the enclosure integration, but > right at the > > > moment, it > > > doesn't > > > > Yes, I didn't suspect so. > > > > > > > > > b) A user space application using sysfs to > read/write > > > >SES pages? > > > > > > Not an application so much as a user. The idea > of sysfs is > > > to allow > > > users to get and set the information in addition > to > > > applications. > > > > Exactly the same argument stands for a user-space > > application with a user-space library. > > > > This is the classical case of where it is better to > > do this in user-space as opposed to the kernel. > > > > The kernel provides capability to access the SES > > device. The user space application and library > > provide interpretation and control. Thus if the > > enclosure were upgraded, one doesn't need to > > upgrade their kernel in order to utilize the new > > capabilities of the SES device. Plus upgrading > > a user-space application is a lot easier than > > the kernel (and no reboot necessary). > > The implementation is modular, so it's remove and > insert ... I guess the same could be said for STGT and SCST, right? LOL, no seriously, this is unnecessary kernel bloat, or rather at the wrong place (see below). > > > Consider another thing: vendors would really like > > unprecedented access to the SES device in the > enclosure > > so as your ses/enclosure code keeps state it would > > get out of sync when vendor user-space enclosure > > applications access (and modify) the SES device's > > pages. > > The state model doesn't assume nothing else will alter > the state. But it would be trivial exercise to show that an inconsistent state can be had by modifying pages of the SES device directly from userspace bypassing your implementation. > > > You can test this yourself: submit a patch > > that removes SES /dev/sgX support; advertise your > > ses/class solution and watch the fun. > > > > > > At the moment SES device management is done > via > > > > an application (user-space) and a user-space > library > > > > used by the application and /dev/sgX to send > SCSI > > > > commands to the SES device. > > > > > > I must have missed that when I was looking for > > > implementations; what's > > > the URL? > > > > I'm not aware of any GPLed ones. That doesn't > > necessarily mean that the best course of action is > > to bloat the kernel. You can move your ses/enclosure > > stuff to a user space application library > > and thus start a GPLed one. > > Certainly ... patches welcome. I've non at the moment, plus I don't think you'd be the point of contact for a user-space SES library. Unless of course you've already started something up on sourceforge. Really, such an effort already exists: it is called sg_ses(8). > > > > But, if we have non-scsi enclosures to integrate, > that > > > makes it harder > > > for a user application because it has to know all > the > > > implementations. > > > > So does the kernel. And as I pointed out above, it > > is a lot easier to upgrade a user-space application > and > > library than it is to upgrade a new kernel and having > > to reboot the computer to run the new kernel. > > No, think again ... it's easy for SES based enclosures > because they have > a SCSI transport. We have no transport for SGPIO based > enclosures nor > for any of the other more esoteric ones. Yes, for which the transport layer, implements the scsi device node for the SES device. It doesn't really matter if the SCSI commands sent to the SES device go over SGPIO or FC or SAS or Bluetooth or I2C, etc, the transport layer can implement that and present the /dev/sgX node. Case in point: the protocol FW running on the ASIC provides this capability so really the LLDD would only see a the pure SCS
Re: [PATCH] enclosure: add support for enclosure services
--- 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 itself needing to read/write SES pages? > > That depends on the enclosure integration, but right at the > moment, it > doesn't Yes, I didn't suspect so. > > > b) A user space application using sysfs to read/write > >SES pages? > > Not an application so much as a user. The idea of sysfs is > to allow > users to get and set the information in addition to > applications. Exactly the same argument stands for a user-space application with a user-space library. This is the classical case of where it is better to do this in user-space as opposed to the kernel. The kernel provides capability to access the SES device. The user space application and library provide interpretation and control. Thus if the enclosure were upgraded, one doesn't need to upgrade their kernel in order to utilize the new capabilities of the SES device. Plus upgrading a user-space application is a lot easier than the kernel (and no reboot necessary). Consider another thing: vendors would really like unprecedented access to the SES device in the enclosure so as your ses/enclosure code keeps state it would get out of sync when vendor user-space enclosure applications access (and modify) the SES device's pages. You can test this yourself: submit a patch that removes SES /dev/sgX support; advertise your ses/class solution and watch the fun. > > At the moment SES device management is done via > > an application (user-space) and a user-space library > > used by the application and /dev/sgX to send SCSI > > commands to the SES device. > > I must have missed that when I was looking for > implementations; what's > the URL? I'm not aware of any GPLed ones. That doesn't necessarily mean that the best course of action is to bloat the kernel. You can move your ses/enclosure stuff to a user space application library and thus start a GPLed one. > But, if we have non-scsi enclosures to integrate, that > makes it harder > for a user application because it has to know all the > implementations. So does the kernel. And as I pointed out above, it is a lot easier to upgrade a user-space application and library than it is to upgrade a new kernel and having to reboot the computer to run the new kernel. > A sysfs framework on the other hand is a universal known > thing for the > user applications. So would a user-space ses library, a la libses.so. > > One could have a very good argument to not bloat > > the kernel with this but leave it to a user-space > > application and a library to do all this and > > communicate with the SES device via the kernel's > /dev/sgX. > > The same thing goes for other esoteric SCSI infrastructure > pieces like > cd changers. On the whole, given that ATA is asking for > enclosure > management in kernel, it makes sense to consolidate the > infrastructure > and a ses ULD is a very good test bed. What is wrong with exporting the SES device as /dev/sgX and having a user-space application and library to do all this? Luben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] enclosure: add support for enclosure services
--- 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 SES pages? b) A user space application using sysfs to read/write SES pages? At the moment SES device management is done via an application (user-space) and a user-space library used by the application and /dev/sgX to send SCSI commands to the SES device. One could have a very good argument to not bloat the kernel with this but leave it to a user-space application and a library to do all this and communicate with the SES device via the kernel's /dev/sgX. Luben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] enclosure: add support for enclosure services
--- 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 SES pages? b) A user space application using sysfs to read/write SES pages? At the moment SES device management is done via an application (user-space) and a user-space library used by the application and /dev/sgX to send SCSI commands to the SES device. One could have a very good argument to not bloat the kernel with this but leave it to a user-space application and a library to do all this and communicate with the SES device via the kernel's /dev/sgX. Luben -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] enclosure: add support for enclosure services
--- 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 itself needing to read/write SES pages? That depends on the enclosure integration, but right at the moment, it doesn't Yes, I didn't suspect so. b) A user space application using sysfs to read/write SES pages? Not an application so much as a user. The idea of sysfs is to allow users to get and set the information in addition to applications. Exactly the same argument stands for a user-space application with a user-space library. This is the classical case of where it is better to do this in user-space as opposed to the kernel. The kernel provides capability to access the SES device. The user space application and library provide interpretation and control. Thus if the enclosure were upgraded, one doesn't need to upgrade their kernel in order to utilize the new capabilities of the SES device. Plus upgrading a user-space application is a lot easier than the kernel (and no reboot necessary). Consider another thing: vendors would really like unprecedented access to the SES device in the enclosure so as your ses/enclosure code keeps state it would get out of sync when vendor user-space enclosure applications access (and modify) the SES device's pages. You can test this yourself: submit a patch that removes SES /dev/sgX support; advertise your ses/class solution and watch the fun. At the moment SES device management is done via an application (user-space) and a user-space library used by the application and /dev/sgX to send SCSI commands to the SES device. I must have missed that when I was looking for implementations; what's the URL? I'm not aware of any GPLed ones. That doesn't necessarily mean that the best course of action is to bloat the kernel. You can move your ses/enclosure stuff to a user space application library and thus start a GPLed one. But, if we have non-scsi enclosures to integrate, that makes it harder for a user application because it has to know all the implementations. So does the kernel. And as I pointed out above, it is a lot easier to upgrade a user-space application and library than it is to upgrade a new kernel and having to reboot the computer to run the new kernel. A sysfs framework on the other hand is a universal known thing for the user applications. So would a user-space ses library, a la libses.so. One could have a very good argument to not bloat the kernel with this but leave it to a user-space application and a library to do all this and communicate with the SES device via the kernel's /dev/sgX. The same thing goes for other esoteric SCSI infrastructure pieces like cd changers. On the whole, given that ATA is asking for enclosure management in kernel, it makes sense to consolidate the infrastructure and a ses ULD is a very good test bed. What is wrong with exporting the SES device as /dev/sgX and having a user-space application and library to do all this? Luben -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] enclosure: add support for enclosure services
--- 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 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 SES pages? That depends on the enclosure integration, but right at the moment, it doesn't Yes, I didn't suspect so. b) A user space application using sysfs to read/write SES pages? Not an application so much as a user. The idea of sysfs is to allow users to get and set the information in addition to applications. Exactly the same argument stands for a user-space application with a user-space library. This is the classical case of where it is better to do this in user-space as opposed to the kernel. The kernel provides capability to access the SES device. The user space application and library provide interpretation and control. Thus if the enclosure were upgraded, one doesn't need to upgrade their kernel in order to utilize the new capabilities of the SES device. Plus upgrading a user-space application is a lot easier than the kernel (and no reboot necessary). The implementation is modular, so it's remove and insert ... I guess the same could be said for STGT and SCST, right? LOL, no seriously, this is unnecessary kernel bloat, or rather at the wrong place (see below). Consider another thing: vendors would really like unprecedented access to the SES device in the enclosure so as your ses/enclosure code keeps state it would get out of sync when vendor user-space enclosure applications access (and modify) the SES device's pages. The state model doesn't assume nothing else will alter the state. But it would be trivial exercise to show that an inconsistent state can be had by modifying pages of the SES device directly from userspace bypassing your implementation. You can test this yourself: submit a patch that removes SES /dev/sgX support; advertise your ses/class solution and watch the fun. At the moment SES device management is done via an application (user-space) and a user-space library used by the application and /dev/sgX to send SCSI commands to the SES device. I must have missed that when I was looking for implementations; what's the URL? I'm not aware of any GPLed ones. That doesn't necessarily mean that the best course of action is to bloat the kernel. You can move your ses/enclosure stuff to a user space application library and thus start a GPLed one. Certainly ... patches welcome. I've non at the moment, plus I don't think you'd be the point of contact for a user-space SES library. Unless of course you've already started something up on sourceforge. Really, such an effort already exists: it is called sg_ses(8). But, if we have non-scsi enclosures to integrate, that makes it harder for a user application because it has to know all the implementations. So does the kernel. And as I pointed out above, it is a lot easier to upgrade a user-space application and library than it is to upgrade a new kernel and having to reboot the computer to run the new kernel. No, think again ... it's easy for SES based enclosures because they have a SCSI transport. We have no transport for SGPIO based enclosures nor for any of the other more esoteric ones. Yes, for which the transport layer, implements the scsi device node for the SES device. It doesn't really matter if the SCSI commands sent to the SES device go over SGPIO or FC or SAS or Bluetooth or I2C, etc, the transport layer can implement that and present the /dev/sgX node. Case in point: the protocol FW running on the ASIC provides this capability so really the LLDD would only see a the pure SCSI SES or processor device and register that with the kernel. At which point no new kernel bloat is required. Your code doesn't quite do that at the moment as it actually goes further in to read and present SES pages. Ideally it would simply provide capability for transport layers to register a SCSI device of type SES, or processor. Architecturally, the LLDD/transport layer would register the SGPIO device on one end with the SGPIO layer and on the other end as a SCSI SES/processpr device. After that sg_ses(8) or sglib, fits the bill for user space applications. That's not to say it can't be done, but it does mean that it can't be completely userspace. See previous paragraph. A sysfs framework on the other hand is a universal known thing for the user applications. So would a user-space ses library, a la libses.so. One could have a very good argument to not bloat the kernel
Re: DMA mapping on SCSI device?
--- 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 imagine why it should be that difficult. The PCI > subsystem > could over a pci_clone_device() or similar function. For > all complicated > purposes (sysfs etc) the original device could be used, so > it would > be hopefully not that difficult. > > The alternative would be to add a new family of PCI mapping > functions that take an explicit mask. Disadvantage would be > changing > all architectures, but on the other hand the interface > could be phase > in one by one (and nF4 primarily only works on x86 anyways) > > I suspect the later would be a little cleaner, although > they don't > make much difference. Yes, I guess, that's certainly doable. The current PCI abstraction is clean: HW DMA engine(s) implementation is a property of the PCI function. Marrying different behaviour of the HW DMA engine of the ASIC depending on the SCSI end device at the PCI device abstraction doesn't sound good. (An extreme design is a single DMA engine servicing the ASIC.) Although, the effect that Rob wants could be cleanly implemented at a higher level, pci_map_sg() and such, or fixing blk_queue_bounce_limit() in x86_64 to that effect. Luben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DMA mapping on SCSI device?
--- 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 ASIC? > This means it's only capable of 32-bit DMA. > However the other port > on the controller may be connected to a hard drive and > therefore still > capable of 64-bit DMA. If this is indeed the case as you've presented it here, it sounds like a HW shortcoming. I cannot see how the device type (or protocol) dictate how the DMA engine operates. They live in two different domains. > 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. The > thought of using the SCSI struct device for DMA mapping was > brought up > at one point.. any thoughts on that? The reason for this is that the object that a struct scsi_dev represents has nothing to do with HW DMA engines. It looks like your current solution is correct and x86_64's blk_queue_bounce_limit needs work. Luben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DMA mapping on SCSI device?
--- 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 imagine why it should be that difficult. The PCI subsystem could over a pci_clone_device() or similar function. For all complicated purposes (sysfs etc) the original device could be used, so it would be hopefully not that difficult. The alternative would be to add a new family of PCI mapping functions that take an explicit mask. Disadvantage would be changing all architectures, but on the other hand the interface could be phase in one by one (and nF4 primarily only works on x86 anyways) I suspect the later would be a little cleaner, although they don't make much difference. Yes, I guess, that's certainly doable. The current PCI abstraction is clean: HW DMA engine(s) implementation is a property of the PCI function. Marrying different behaviour of the HW DMA engine of the ASIC depending on the SCSI end device at the PCI device abstraction doesn't sound good. (An extreme design is a single DMA engine servicing the ASIC.) Although, the effect that Rob wants could be cleanly implemented at a higher level, pci_map_sg() and such, or fixing blk_queue_bounce_limit() in x86_64 to that effect. Luben -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DMA mapping on SCSI device?
--- 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 ASIC? This means it's only capable of 32-bit DMA. However the other port on the controller may be connected to a hard drive and therefore still capable of 64-bit DMA. If this is indeed the case as you've presented it here, it sounds like a HW shortcoming. I cannot see how the device type (or protocol) dictate how the DMA engine operates. They live in two different domains. 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. The thought of using the SCSI struct device for DMA mapping was brought up at one point.. any thoughts on that? The reason for this is that the object that a struct scsi_dev represents has nothing to do with HW DMA engines. It looks like your current solution is correct and x86_64's blk_queue_bounce_limit needs work. Luben -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What still uses the block 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 has been exceedingly polite and helpful, as > were several other people on the linux-scsi list when I asked them about this > stuff back in August. I wasn't referring to him specifically. He also stepped into the WWN thread in the same manner as he did in your thread. > Religion, politics, and anything remotely related to hotplug appear to be > topics to avoid in polite company if you want it to remain polite. (My > gripes with scsi mostly have to do with device enumeration. My attempts to > use sysfs also have to do with device enumeration. I've spotted a trend > here.) > > Rob > -- > "One of my most productive days was throwing away 1000 lines of code." > - Ken Thompson. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What still uses the block 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 has been exceedingly polite and helpful, as were several other people on the linux-scsi list when I asked them about this stuff back in August. I wasn't referring to him specifically. He also stepped into the WWN thread in the same manner as he did in your thread. Religion, politics, and anything remotely related to hotplug appear to be topics to avoid in polite company if you want it to remain polite. (My gripes with scsi mostly have to do with device enumeration. My attempts to use sysfs also have to do with device enumeration. I've spotted a trend here.) Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What still uses the block layer?
--- 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 layers doesn't use the block layer described in > > > Documentation/block/*. > > > > Entirely incorrect. > > OK, right ... could we please get a sense of decorum back on this list. > > Rob, if you didn't ask your alleged questions in such a pejorative > manner, we'd get a lot further; and Matthew, if you didn't rise to the > bait so spectacularly it wouldn't prolong these threads. > > Really, both of you, I have better things to do with my time than > mediate behaviours that should have been educated out of you in the > kindergarten sand pit. I really didn't find Rob's email "pejorative" at all. It seems to me he was just asking for clarification, information and trying to understand how it all works and ties together. His email seemed genuine enough of a person just asking to understand how it all works. Matthew's expletive and extremely rude response really shows the general attitude of the linux-scsi people. Heck, I got a similar response just a week ago here on the list, trying to convince Garzik and his band, that storage nodes SHOULD NOT be SAS WWN generators. Should I have even tried? That's the question. Good luck everyone, Luben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What still uses the block layer?
--- 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 layers doesn't use the block layer described in Documentation/block/*. Entirely incorrect. OK, right ... could we please get a sense of decorum back on this list. Rob, if you didn't ask your alleged questions in such a pejorative manner, we'd get a lot further; and Matthew, if you didn't rise to the bait so spectacularly it wouldn't prolong these threads. Really, both of you, I have better things to do with my time than mediate behaviours that should have been educated out of you in the kindergarten sand pit. I really didn't find Rob's email pejorative at all. It seems to me he was just asking for clarification, information and trying to understand how it all works and ties together. His email seemed genuine enough of a person just asking to understand how it all works. Matthew's expletive and extremely rude response really shows the general attitude of the linux-scsi people. Heck, I got a similar response just a week ago here on the list, trying to convince Garzik and his band, that storage nodes SHOULD NOT be SAS WWN generators. Should I have even tried? That's the question. Good luck everyone, Luben - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] libata update
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, I can attend to > this... Fun stuff: > > * port multiplier support (like an ethernet hub, only dumber) > > * Asynchronous notification -- finally userspace CD-ROM polling can go away! > (NOTE: waiting on James B to apply the piece that actually makes this > work...) > > * Alan continues to hammer out edge cases in generic ATA support. An > amazing amount of ancient and/or obscure hardware works with libata > thanks to him :) > > * Turn on ACPI by default (watch for bug reports!). This should make > suspend/resume work a lot better. > > * New drivers for embedded ATA chips. > > > Please pull from 'upstream-linus' branch of > master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git > upstream-linus > > to receive the following updates: > > Documentation/kernel-parameters.txt |8 +- > drivers/ata/Kconfig | 59 ++- > drivers/ata/Makefile |8 +- > drivers/ata/ahci.c | 451 +++--- > drivers/ata/ata_generic.c| 16 +- > drivers/ata/ata_piix.c | 71 +- > drivers/ata/libata-acpi.c| 165 +++- > drivers/ata/libata-core.c| 1329 ++-- > drivers/ata/libata-eh.c | 922 ++-- > drivers/ata/libata-pmp.c | 1191 + > drivers/ata/libata-scsi.c| 496 +++ > drivers/ata/libata-sff.c | 69 +- > drivers/ata/libata.h | 41 +- > drivers/ata/pata_acpi.c | 395 > drivers/ata/pata_ali.c | 17 +- > drivers/ata/pata_amd.c | 43 +- > drivers/ata/pata_artop.c | 20 +- > drivers/ata/pata_at32.c | 441 + > drivers/ata/pata_atiixp.c| 15 +- > drivers/ata/pata_bf54x.c | 1627 > ++ > drivers/ata/pata_cmd640.c|4 +- > drivers/ata/pata_cmd64x.c| 43 +- > drivers/ata/pata_cs5520.c| 47 +- > drivers/ata/pata_cs5530.c|4 +- > drivers/ata/pata_cs5535.c|4 +- > drivers/ata/pata_cypress.c |4 +- > drivers/ata/pata_efar.c | 11 +- > drivers/ata/pata_hpt366.c|4 +- > drivers/ata/pata_hpt37x.c| 28 +- > drivers/ata/pata_hpt3x2n.c | 11 +- > drivers/ata/pata_hpt3x3.c| 10 +- > drivers/ata/pata_icside.c| 39 +- > drivers/ata/pata_isapnp.c|8 +- > drivers/ata/pata_it8213.c| 11 +- > drivers/ata/pata_it821x.c| 17 +- > drivers/ata/pata_ixp4xx_cf.c | 24 +- > drivers/ata/pata_jmicron.c | 24 +- > drivers/ata/pata_legacy.c| 27 +- > drivers/ata/pata_marvell.c | 12 +- > drivers/ata/pata_mpc52xx.c |9 +- > drivers/ata/pata_mpiix.c | 25 +- > drivers/ata/pata_netcell.c |5 +- > drivers/ata/pata_ns87410.c | 11 +- > drivers/ata/pata_ns87415.c | 467 ++ > drivers/ata/pata_oldpiix.c | 11 +- > drivers/ata/pata_opti.c | 11 +- > drivers/ata/pata_optidma.c | 26 +- > drivers/ata/pata_pcmcia.c| 16 +- > drivers/ata/pata_pdc2027x.c | 114 ++-- > drivers/ata/pata_pdc202xx_old.c | 23 +- > drivers/ata/pata_platform.c | 16 +- > drivers/ata/pata_qdi.c | 15 +- > drivers/ata/pata_radisys.c |4 +- > drivers/ata/pata_rz1000.c| 13 +- > drivers/ata/pata_sc1200.c|4 +- > drivers/ata/pata_scc.c | 66 +- > drivers/ata/pata_serverworks.c |8 +- > drivers/ata/pata_sil680.c| 11 +- > drivers/ata/pata_sis.c | 33 +- > drivers/ata/pata_sl82c105.c | 11 +- > drivers/ata/pata_triflex.c | 11 +- > drivers/ata/pata_via.c | 16 +- > drivers/ata/pata_winbond.c | 13 +- > drivers/ata/pdc_adma.c | 103 ++- > drivers/ata/sata_inic162x.c | 34 +- > drivers/ata/sata_mv.c| 68 +- > drivers/ata/sata_nv.c| 53 +- > drivers/ata/sata_promise.c | 27 +- > drivers/ata/sata_qstor.c | 17 +- > drivers/ata/sata_sil.c | 53 +- > drivers/ata/sata_sil24.c | 341 ++-- > drivers/ata/sata_sis.c |2 - > drivers/ata/sata_svw.c | 14 +- > drivers/ata/sata_sx4.c | 25 +- > drivers/ata/sata_uli.c | 16 +- >
Re: [git patches] libata update
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, I can attend to this... Fun stuff: * port multiplier support (like an ethernet hub, only dumber) * Asynchronous notification -- finally userspace CD-ROM polling can go away! (NOTE: waiting on James B to apply the piece that actually makes this work...) * Alan continues to hammer out edge cases in generic ATA support. An amazing amount of ancient and/or obscure hardware works with libata thanks to him :) * Turn on ACPI by default (watch for bug reports!). This should make suspend/resume work a lot better. * New drivers for embedded ATA chips. Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git upstream-linus to receive the following updates: Documentation/kernel-parameters.txt |8 +- drivers/ata/Kconfig | 59 ++- drivers/ata/Makefile |8 +- drivers/ata/ahci.c | 451 +++--- drivers/ata/ata_generic.c| 16 +- drivers/ata/ata_piix.c | 71 +- drivers/ata/libata-acpi.c| 165 +++- drivers/ata/libata-core.c| 1329 ++-- drivers/ata/libata-eh.c | 922 ++-- drivers/ata/libata-pmp.c | 1191 + drivers/ata/libata-scsi.c| 496 +++ drivers/ata/libata-sff.c | 69 +- drivers/ata/libata.h | 41 +- drivers/ata/pata_acpi.c | 395 drivers/ata/pata_ali.c | 17 +- drivers/ata/pata_amd.c | 43 +- drivers/ata/pata_artop.c | 20 +- drivers/ata/pata_at32.c | 441 + drivers/ata/pata_atiixp.c| 15 +- drivers/ata/pata_bf54x.c | 1627 ++ drivers/ata/pata_cmd640.c|4 +- drivers/ata/pata_cmd64x.c| 43 +- drivers/ata/pata_cs5520.c| 47 +- drivers/ata/pata_cs5530.c|4 +- drivers/ata/pata_cs5535.c|4 +- drivers/ata/pata_cypress.c |4 +- drivers/ata/pata_efar.c | 11 +- drivers/ata/pata_hpt366.c|4 +- drivers/ata/pata_hpt37x.c| 28 +- drivers/ata/pata_hpt3x2n.c | 11 +- drivers/ata/pata_hpt3x3.c| 10 +- drivers/ata/pata_icside.c| 39 +- drivers/ata/pata_isapnp.c|8 +- drivers/ata/pata_it8213.c| 11 +- drivers/ata/pata_it821x.c| 17 +- drivers/ata/pata_ixp4xx_cf.c | 24 +- drivers/ata/pata_jmicron.c | 24 +- drivers/ata/pata_legacy.c| 27 +- drivers/ata/pata_marvell.c | 12 +- drivers/ata/pata_mpc52xx.c |9 +- drivers/ata/pata_mpiix.c | 25 +- drivers/ata/pata_netcell.c |5 +- drivers/ata/pata_ns87410.c | 11 +- drivers/ata/pata_ns87415.c | 467 ++ drivers/ata/pata_oldpiix.c | 11 +- drivers/ata/pata_opti.c | 11 +- drivers/ata/pata_optidma.c | 26 +- drivers/ata/pata_pcmcia.c| 16 +- drivers/ata/pata_pdc2027x.c | 114 ++-- drivers/ata/pata_pdc202xx_old.c | 23 +- drivers/ata/pata_platform.c | 16 +- drivers/ata/pata_qdi.c | 15 +- drivers/ata/pata_radisys.c |4 +- drivers/ata/pata_rz1000.c| 13 +- drivers/ata/pata_sc1200.c|4 +- drivers/ata/pata_scc.c | 66 +- drivers/ata/pata_serverworks.c |8 +- drivers/ata/pata_sil680.c| 11 +- drivers/ata/pata_sis.c | 33 +- drivers/ata/pata_sl82c105.c | 11 +- drivers/ata/pata_triflex.c | 11 +- drivers/ata/pata_via.c | 16 +- drivers/ata/pata_winbond.c | 13 +- drivers/ata/pdc_adma.c | 103 ++- drivers/ata/sata_inic162x.c | 34 +- drivers/ata/sata_mv.c| 68 +- drivers/ata/sata_nv.c| 53 +- drivers/ata/sata_promise.c | 27 +- drivers/ata/sata_qstor.c | 17 +- drivers/ata/sata_sil.c | 53 +- drivers/ata/sata_sil24.c | 341 ++-- drivers/ata/sata_sis.c |2 - drivers/ata/sata_svw.c | 14 +- drivers/ata/sata_sx4.c | 25 +- drivers/ata/sata_uli.c | 16 +- drivers/ata/sata_via.c | 35 +- drivers/ata/sata_vsc.c | 16 +- drivers/scsi/ipr.c
Re: [PATCH] aic94xx: Use request_firmware() to provide SAS address if the adapter lacks one
--- 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 set the WWN and >not touch the SAN config. No. The WWN stays the same and the SAN is re-configured to be aware of the node migration. Access patterns could be more complex than just a single portal allowing access to/from the SAN from/to the node. WWN is supposed to be persistent. This is what it actually is. It is NOT supposed to be "(auto)generated" and/or changed at a whim. This also has security implications, and enterprise networks may refuse to use software (read "kernel") which allows for arbitrary changes to a node's WWN. If access to a node is compromised, a rogue agent may change the node's WWN in order to access SAN zones that it normally will be denied access to. Luben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] aic94xx: Use request_firmware() to provide SAS address if the adapter lacks one
--- 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 set the WWN and not touch the SAN config. No. The WWN stays the same and the SAN is re-configured to be aware of the node migration. Access patterns could be more complex than just a single portal allowing access to/from the SAN from/to the node. WWN is supposed to be persistent. This is what it actually is. It is NOT supposed to be (auto)generated and/or changed at a whim. This also has security implications, and enterprise networks may refuse to use software (read kernel) which allows for arbitrary changes to a node's WWN. If access to a node is compromised, a rogue agent may change the node's WWN in order to access SAN zones that it normally will be denied access to. Luben - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD driver-core] Lifetime problems of the current driver model
--- 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. It is a good implementation [kobject], and I'd hate to see it lost into being convoluted with/into another model. Currently the infrastructure layers are well defined: kobject -> (A layer with objects, their behavor and implementation) device -> (--"--) sysfs. (--"--) This isn't that bad of an infrastructure. It is this well defined layering, i.e. objects, their behavior and implementation, that allows different (better/worse) infrastructures to be built on top of it. It is this well-defined layering which will allow what Tejun wants to be implemented. > device ... but that would get us into disentangling the ksets, which, on > balance, isn't going to be fun ... Luben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD driver-core] Lifetime problems of the current driver model
--- 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 /dev/dk0
> >> driven by a hypothetical driver mydrv. /dev/dk0 is represented like the
> >> following in the sysfs tree.
> >>
> >> /sys/devices/pci:00/:00:1f.0/dk0/{myknob0,myknob1}
> >>
> >> Owner of both attrs myknob0 and myknob1 is mydrv and opening either
> >> increases the reference counts of dk0 and mydrv and closing does the
> >> opposite.
> >>
> >> * When there is no opener of either knob and the /dev/dk0 isn't used by
> >> anyone. Reference count of dk0 is 1, mydrv 0.
> >
> > Hm, but as long as dk0 is registered, it can be looked up and someone
> > could get a reference on it.
>
> Yeah, exactly. That's why any getting any kobject reference backed by a
> module must be accompanied by try_module_get().
Tejun,
This has always been the case.
By design, the kobject infrastructure is one such that allows for
different behavior implementations. You could use it to accomplish
what you want and describe in your RFD, or you could use it to implement
what we have today or you could use it to implement completely different
(refcount) infrastructure.
Luben
>
> int mydrv_get_dk(struct dk *dk)
> {
> rc = try_module_get(mydrv);
> if (rc)
> return rc;
> kobject_get(>kobj);
> return 0;
> }
>
> >> * User issues rmmod mydrv. As mydrv's reference count is zero, unload
> >> proceeds and mydrv's exit function is called.
> >>
> >> * mydrv's exit function looks like the following.
> >>
> >> mydrv_exit()
> >> {
> >>sysfs_remove_file(dk0, myknob0);
> >>sysfs_remove_file(dk1, myknob1);
> >>device_del(dk0);
> >>deinit controller;
> >>release all resources;
> >> }
> >>
> >> The device_del(dk0) drops dk0's reference count to zero and its
> >> ->release is invoked immediately.
> >
> > And here is the problem if someone else still has a reference. The
> > module will be unloaded, but ->release will not be called until the
> > "someone else" gives up the reference...
>
> Exactly, in that case, module reference count must not be zero. You and
> I are saying the same thing. Why are we running in circle?
>
> --
> tejun
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD driver-core] Lifetime problems of the current driver model
--- 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 /dev/dk0
driven by a hypothetical driver mydrv. /dev/dk0 is represented like the
following in the sysfs tree.
/sys/devices/pci:00/:00:1f.0/dk0/{myknob0,myknob1}
Owner of both attrs myknob0 and myknob1 is mydrv and opening either
increases the reference counts of dk0 and mydrv and closing does the
opposite.
* When there is no opener of either knob and the /dev/dk0 isn't used by
anyone. Reference count of dk0 is 1, mydrv 0.
Hm, but as long as dk0 is registered, it can be looked up and someone
could get a reference on it.
Yeah, exactly. That's why any getting any kobject reference backed by a
module must be accompanied by try_module_get().
Tejun,
This has always been the case.
By design, the kobject infrastructure is one such that allows for
different behavior implementations. You could use it to accomplish
what you want and describe in your RFD, or you could use it to implement
what we have today or you could use it to implement completely different
(refcount) infrastructure.
Luben
int mydrv_get_dk(struct dk *dk)
{
rc = try_module_get(mydrv);
if (rc)
return rc;
kobject_get(dk-kobj);
return 0;
}
* User issues rmmod mydrv. As mydrv's reference count is zero, unload
proceeds and mydrv's exit function is called.
* mydrv's exit function looks like the following.
mydrv_exit()
{
sysfs_remove_file(dk0, myknob0);
sysfs_remove_file(dk1, myknob1);
device_del(dk0);
deinit controller;
release all resources;
}
The device_del(dk0) drops dk0's reference count to zero and its
-release is invoked immediately.
And here is the problem if someone else still has a reference. The
module will be unloaded, but -release will not be called until the
someone else gives up the reference...
Exactly, in that case, module reference count must not be zero. You and
I are saying the same thing. Why are we running in circle?
--
tejun
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD driver-core] Lifetime problems of the current driver model
--- 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. It is a good implementation [kobject], and I'd hate to see it lost into being convoluted with/into another model. Currently the infrastructure layers are well defined: kobject - (A layer with objects, their behavor and implementation) device - () sysfs. () This isn't that bad of an infrastructure. It is this well defined layering, i.e. objects, their behavior and implementation, that allows different (better/worse) infrastructures to be built on top of it. It is this well-defined layering which will allow what Tejun wants to be implemented. device ... but that would get us into disentangling the ksets, which, on balance, isn't going to be fun ... Luben - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1
--- Damien Wyart <[EMAIL PROTECTED]> wrote: > > > > The reiser4 failure is unexpected. Could you please see if you can > > > > capture a trace, let the people at [EMAIL PROTECTED] know? > > > > Ok, I've handwritten the messages, here they are : > > > > reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom > > > (fs/reiser4/txmngr.c:1087) (zam-597) > > > write log failed (-5) > > > > [ got 2 copies of them because I have 2 reiser4 fs) > > > > I got them mainly when I try to reboot or halt the machine, and the > > > process doesn't finish, the computer gets stuck after the reiser4 > > > messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2. > > * Laurent Riffard <[EMAIL PROTECTED]> [2006-12-18 09:03]: > > fix-sense-key-medium-error-processing-and-retry.patch seems to be the > > culprit. > > > Reverting it fix those reiser4 panics for me. Damien, could you confirm > > please ? > > Yes, this fixes it too on my side. Thanks for this tracking ! I had a bug in my dev tree which got picked up by the patch when I diffed against master: - scsi_end_request(cmd, 1, good_bytes, !!result) == NULL) + scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL) return; As james explained, the other chunk of the patch is still good. Luben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
--- [EMAIL PROTECTED] wrote: > From: Andrew Morton <[EMAIL PROTECTED]> > Date: Sun, Dec 17, 2006 at 03:05:39AM -0800 > > On Sun, 17 Dec 2006 12:00:12 +0100 > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > > > Okay, I have identified the patch that causes the problem to appear, > > > which is > > > > > > fix-sense-key-medium-error-processing-and-retry.patch > > > > > > With this patch reverted -rc1-mm1 is happily running on my test box. > > > > That was rather unexpected. Thanks. > > > I can confirm that 2.6.20-rc1-mm1 with this patch reverted mounts my > raid6 partition without problems. This is x86_64 with SMP. > The reason was that my dev tree was tainted by this bug: if (good_bytes && - scsi_end_request(cmd, 1, good_bytes, !!result) == NULL) + scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL) return; in scsi_io_completion(). I had there !!result which is wrong, and when I diffed against master, it produced a bad patch. As James mentioned one of the chunks is good and can go in. Luben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1
--- Damien Wyart [EMAIL PROTECTED] wrote: The reiser4 failure is unexpected. Could you please see if you can capture a trace, let the people at [EMAIL PROTECTED] know? Ok, I've handwritten the messages, here they are : reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom (fs/reiser4/txmngr.c:1087) (zam-597) write log failed (-5) [ got 2 copies of them because I have 2 reiser4 fs) I got them mainly when I try to reboot or halt the machine, and the process doesn't finish, the computer gets stuck after the reiser4 messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2. * Laurent Riffard [EMAIL PROTECTED] [2006-12-18 09:03]: fix-sense-key-medium-error-processing-and-retry.patch seems to be the culprit. Reverting it fix those reiser4 panics for me. Damien, could you confirm please ? Yes, this fixes it too on my side. Thanks for this tracking ! I had a bug in my dev tree which got picked up by the patch when I diffed against master: - scsi_end_request(cmd, 1, good_bytes, !!result) == NULL) + scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL) return; As james explained, the other chunk of the patch is still good. Luben - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
--- [EMAIL PROTECTED] wrote: From: Andrew Morton [EMAIL PROTECTED] Date: Sun, Dec 17, 2006 at 03:05:39AM -0800 On Sun, 17 Dec 2006 12:00:12 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: Okay, I have identified the patch that causes the problem to appear, which is fix-sense-key-medium-error-processing-and-retry.patch With this patch reverted -rc1-mm1 is happily running on my test box. That was rather unexpected. Thanks. I can confirm that 2.6.20-rc1-mm1 with this patch reverted mounts my raid6 partition without problems. This is x86_64 with SMP. The reason was that my dev tree was tainted by this bug: if (good_bytes - scsi_end_request(cmd, 1, good_bytes, !!result) == NULL) + scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL) return; in scsi_io_completion(). I had there !!result which is wrong, and when I diffed against master, it produced a bad patch. As James mentioned one of the chunks is good and can go in. Luben - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Infinite retries reading the partition table
--- James Bottomley <[EMAIL PROTECTED]> wrote: > On Wed, 2006-12-06 at 12:24 -0800, Luben Tuikov wrote: > > NEEDS_RETRY _does_ terminate, after it exhausts the retries. But since > > by the ASC value we know that no amount of retries is going to work, > > this chunk of the patch resolves it quicker, i.e. eliminates the > > "NEEDS_RETRY" pointless retries (given the SK/ASC combination). > > I agree that it's useful behaviour. However, the change header should > be something like "scsi_error: don't retry for unrecoverable medium > errors" not "infinite retries .." > > > > > - if (scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL) > > > > + if (good_bytes && > > > > + scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL) > > > > return; > > > > > > What exactly is this supposed to be doing? its result is identical to > > > the code it's replacing (because of the way scsi_end_request() processes > > > its second argument), so it can't have any effect on the stated problem. > > > > I suppose this is true, but I'd rather it not even go in > > scsi_end_request as (cmd, uptodate=1, good_bytes=0, retry=0) and complete > > at the bottom as (cmd, uptodate=0, total_xfer, retry=0). > > But, logically, this isn't part of the change set ... the behaviour > you're altering is unrelated to the change set details, so this piece > shouldn't be in. It is. If good_bytes=0 then nothing is up to date and uptodate should be set to 0. Look at my comment before the function call: /* A number of bytes were successfully read. ... I repeat again: it doesn't make sense to call scsi_end_request with uptodate=1 and good_bytes=0, since _no bytes are uptodate_. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Infinite retries reading the partition table
--- James Bottomley [EMAIL PROTECTED] wrote: On Wed, 2006-12-06 at 12:24 -0800, Luben Tuikov wrote: NEEDS_RETRY _does_ terminate, after it exhausts the retries. But since by the ASC value we know that no amount of retries is going to work, this chunk of the patch resolves it quicker, i.e. eliminates the NEEDS_RETRY pointless retries (given the SK/ASC combination). I agree that it's useful behaviour. However, the change header should be something like scsi_error: don't retry for unrecoverable medium errors not infinite retries .. - if (scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL) + if (good_bytes + scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL) return; What exactly is this supposed to be doing? its result is identical to the code it's replacing (because of the way scsi_end_request() processes its second argument), so it can't have any effect on the stated problem. I suppose this is true, but I'd rather it not even go in scsi_end_request as (cmd, uptodate=1, good_bytes=0, retry=0) and complete at the bottom as (cmd, uptodate=0, total_xfer, retry=0). But, logically, this isn't part of the change set ... the behaviour you're altering is unrelated to the change set details, so this piece shouldn't be in. It is. If good_bytes=0 then nothing is up to date and uptodate should be set to 0. Look at my comment before the function call: /* A number of bytes were successfully read. ... I repeat again: it doesn't make sense to call scsi_end_request with uptodate=1 and good_bytes=0, since _no bytes are uptodate_. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Infinite retries reading the partition table
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-12-05 at 21:08 -0800, Andrew Morton wrote:
> > case MEDIUM_ERROR:
> > + if (sshdr.asc == 0x11 || /* UNRECOVERED READ ERR */
> > + sshdr.asc == 0x13 || /* AMNF DATA FIELD */
> > + sshdr.asc == 0x14) { /* RECORD NOT FOUND */
> > + return SUCCESS;
> > + }
> > return NEEDS_RETRY;
>
> If the complaint is true; i.e. infinite retries, this is just a bandaid
> not a fix. What it's doing is marking the unrecoverable medium errors
> for no retry. However, what we really need to know is why NEEDS_RETRY
> isn't terminating after its allotted number of retries. Can we please
> have a trace of this?
NEEDS_RETRY _does_ terminate, after it exhausts the retries. But since
by the ASC value we know that no amount of retries is going to work,
this chunk of the patch resolves it quicker, i.e. eliminates the
"NEEDS_RETRY" pointless retries (given the SK/ASC combination).
> > - if (scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
> > + if (good_bytes &&
> > + scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
> > return;
>
> What exactly is this supposed to be doing? its result is identical to
> the code it's replacing (because of the way scsi_end_request() processes
> its second argument), so it can't have any effect on the stated problem.
I suppose this is true, but I'd rather it not even go in
scsi_end_request as (cmd, uptodate=1, good_bytes=0, retry=0) and complete
at the bottom as (cmd, uptodate=0, total_xfer, retry=0).
Luben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Infinite retries reading the partition table
--- James Bottomley [EMAIL PROTECTED] wrote:
On Tue, 2006-12-05 at 21:08 -0800, Andrew Morton wrote:
case MEDIUM_ERROR:
+ if (sshdr.asc == 0x11 || /* UNRECOVERED READ ERR */
+ sshdr.asc == 0x13 || /* AMNF DATA FIELD */
+ sshdr.asc == 0x14) { /* RECORD NOT FOUND */
+ return SUCCESS;
+ }
return NEEDS_RETRY;
If the complaint is true; i.e. infinite retries, this is just a bandaid
not a fix. What it's doing is marking the unrecoverable medium errors
for no retry. However, what we really need to know is why NEEDS_RETRY
isn't terminating after its allotted number of retries. Can we please
have a trace of this?
NEEDS_RETRY _does_ terminate, after it exhausts the retries. But since
by the ASC value we know that no amount of retries is going to work,
this chunk of the patch resolves it quicker, i.e. eliminates the
NEEDS_RETRY pointless retries (given the SK/ASC combination).
- if (scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
+ if (good_bytes
+ scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
return;
What exactly is this supposed to be doing? its result is identical to
the code it's replacing (because of the way scsi_end_request() processes
its second argument), so it can't have any effect on the stated problem.
I suppose this is true, but I'd rather it not even go in
scsi_end_request as (cmd, uptodate=1, good_bytes=0, retry=0) and complete
at the bottom as (cmd, uptodate=0, total_xfer, retry=0).
Luben
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Infinite retries reading the partition table
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Tue, 5 Dec 2006 21:00:20 -0800 (PST) Luben Tuikov <[EMAIL PROTECTED]>
> > wrote:
> > --- Michael Reed <[EMAIL PROTECTED]> wrote:
> > > Luben Tuikov wrote:
> > > ...snip...
> > > > This statement in scsi_io_completion() causes the infinite retry loop:
> > > >if (scsi_end_request(cmd, 1, good_bytes, !!result) == NULL)
> > > > return;
> > >
> > > The code in 2.6.19 is "result==0", not "!!result", which is logically
> > > the same as "result!=0". Did you mean to change the logic here?
> > > Am I missing something?
> >
> > Hmm, I think my trees have !!result from an earlier patch I posted.
> >
> > In this case it would appear that the second chunk of the patch
> > wouldn't be necessary, since result==0 would be false, and it
> > wouldn't retry.
> >
>
> I fixed things up. The below is as-intended, yes?
Yes, thanks!
Luben
>
>
> diff -puN
> drivers/scsi/scsi_error.c~fix-sense-key-medium-error-processing-and-retry
> drivers/scsi/scsi_error.c
> ---
> a/drivers/scsi/scsi_error.c~fix-sense-key-medium-error-processing-and-retry
> +++ a/drivers/scsi/scsi_error.c
> @@ -359,6 +359,11 @@ static int scsi_check_sense(struct scsi_
> return SUCCESS;
>
> case MEDIUM_ERROR:
> + if (sshdr.asc == 0x11 || /* UNRECOVERED READ ERR */
> + sshdr.asc == 0x13 || /* AMNF DATA FIELD */
> + sshdr.asc == 0x14) { /* RECORD NOT FOUND */
> + return SUCCESS;
> + }
> return NEEDS_RETRY;
>
> case HARDWARE_ERROR:
> diff -puN
> drivers/scsi/scsi_lib.c~fix-sense-key-medium-error-processing-and-retry
> drivers/scsi/scsi_lib.c
> --- a/drivers/scsi/scsi_lib.c~fix-sense-key-medium-error-processing-and-retry
> +++ a/drivers/scsi/scsi_lib.c
> @@ -871,7 +871,8 @@ void scsi_io_completion(struct scsi_cmnd
>* are leftovers and there is some kind of error
>* (result != 0), retry the rest.
>*/
> - if (scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
> + if (good_bytes &&
> + scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
> return;
>
> /* good_bytes = 0, or (inclusive) there were leftovers and
> _
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Infinite retries reading the partition table
--- Michael Reed <[EMAIL PROTECTED]> wrote: > Luben Tuikov wrote: > ...snip... > > This statement in scsi_io_completion() causes the infinite retry loop: > >if (scsi_end_request(cmd, 1, good_bytes, !!result) == NULL) > > return; > > The code in 2.6.19 is "result==0", not "!!result", which is logically > the same as "result!=0". Did you mean to change the logic here? > Am I missing something? Hmm, I think my trees have !!result from an earlier patch I posted. In this case it would appear that the second chunk of the patch wouldn't be necessary, since result==0 would be false, and it wouldn't retry. Luben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Infinite retries reading the partition table
--- Michael Reed [EMAIL PROTECTED] wrote: Luben Tuikov wrote: ...snip... This statement in scsi_io_completion() causes the infinite retry loop: if (scsi_end_request(cmd, 1, good_bytes, !!result) == NULL) return; The code in 2.6.19 is result==0, not !!result, which is logically the same as result!=0. Did you mean to change the logic here? Am I missing something? Hmm, I think my trees have !!result from an earlier patch I posted. In this case it would appear that the second chunk of the patch wouldn't be necessary, since result==0 would be false, and it wouldn't retry. Luben - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Infinite retries reading the partition table
--- Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 5 Dec 2006 21:00:20 -0800 (PST) Luben Tuikov [EMAIL PROTECTED]
wrote:
--- Michael Reed [EMAIL PROTECTED] wrote:
Luben Tuikov wrote:
...snip...
This statement in scsi_io_completion() causes the infinite retry loop:
if (scsi_end_request(cmd, 1, good_bytes, !!result) == NULL)
return;
The code in 2.6.19 is result==0, not !!result, which is logically
the same as result!=0. Did you mean to change the logic here?
Am I missing something?
Hmm, I think my trees have !!result from an earlier patch I posted.
In this case it would appear that the second chunk of the patch
wouldn't be necessary, since result==0 would be false, and it
wouldn't retry.
I fixed things up. The below is as-intended, yes?
Yes, thanks!
Luben
diff -puN
drivers/scsi/scsi_error.c~fix-sense-key-medium-error-processing-and-retry
drivers/scsi/scsi_error.c
---
a/drivers/scsi/scsi_error.c~fix-sense-key-medium-error-processing-and-retry
+++ a/drivers/scsi/scsi_error.c
@@ -359,6 +359,11 @@ static int scsi_check_sense(struct scsi_
return SUCCESS;
case MEDIUM_ERROR:
+ if (sshdr.asc == 0x11 || /* UNRECOVERED READ ERR */
+ sshdr.asc == 0x13 || /* AMNF DATA FIELD */
+ sshdr.asc == 0x14) { /* RECORD NOT FOUND */
+ return SUCCESS;
+ }
return NEEDS_RETRY;
case HARDWARE_ERROR:
diff -puN
drivers/scsi/scsi_lib.c~fix-sense-key-medium-error-processing-and-retry
drivers/scsi/scsi_lib.c
--- a/drivers/scsi/scsi_lib.c~fix-sense-key-medium-error-processing-and-retry
+++ a/drivers/scsi/scsi_lib.c
@@ -871,7 +871,8 @@ void scsi_io_completion(struct scsi_cmnd
* are leftovers and there is some kind of error
* (result != 0), retry the rest.
*/
- if (scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
+ if (good_bytes
+ scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
return;
/* good_bytes = 0, or (inclusive) there were leftovers and
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Infinite retries reading the partition table
--- Andrew Morton <[EMAIL PROTECTED]> wrote: > On Thu, 30 Nov 2006 22:34:57 -0800 (PST) > Luben Tuikov <[EMAIL PROTECTED]> wrote: > > > --- Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Wed, 29 Nov 2006 17:22:48 -0800 (PST) > > > Luben Tuikov <[EMAIL PROTECTED]> wrote: > > > > > > > Suppose reading sector 0 always reports an error, > > > > sense key HARDWARE ERROR. > > > > > > > > What I'm observing is that the request to read sector 0, > > > > reading partition information, is retried forever, ad infinitum. > > > > > > > > Does anyone have a patch to resolve this? (2.6.19-rc6) > > > > > > > > > > Please send a backtrace so we can see where the offending loop occurs. > > > > I posted a patch to linux-scsi > > hm. Does sending patches to linux-scsi get them applied? It might, I > don't know. Good question -- I don't know either. > > which resolves this issue: > > http://marc.theaimsgroup.com/?l=linux-scsi=116485834119885=2 > > That looks like it prevents the IO error. But why was an IO error causing > an infinite loop? What piece of code was initiating the retries? Here is what happens: sector 0 is broken -- the device cannot read the media at that location. The device properly returns a certain type of uncorrectable MEDIUM ERROR (ASC: UNRECOVERABLE READ ERR). SCSI Core loops around its retries (which this patch fixes) and eventually gives up and sends it for "completion". This is what happens when scsi_check_sense() returns NEEDS_RETRY to scsi_decide_disposition() to scsi_softirq(). The first chunk of the patch fixes this. We end up in scsi_io_completion(), where good_bytes = 0, and result = 0x0802 (DRIVER SENSE and CHECK CONDITION). This statement in scsi_io_completion() causes the infinite retry loop: if (scsi_end_request(cmd, 1, good_bytes, !!result) == NULL) return; substitute to get: scsi_end_request(cmd, uptodate=1, uptodate bytes=0, retry=1) Yeah, but it doesn't make sense to call scsi_end_request() with uptodate=1 and uptodate bytes = 0. This causes the infinite retry, since the code tries to re-read the whole xfer size (0 bytes were uptodate and retry=1), from the bad media. That is, we want to set uptodate=1 iff there was at least 1 byte up to date. Else if nothing was read, uptodate bytes = 0, then we should pass uptodate = 0, uptodate_bytes = total xfer, to mean the whole xfer is not uptodate; and retry iff there was no error. (This is the very bottom of the function.) ... I know, I know, but that's what we've got. See this commit 03aba2f79594ca94d159c8bab454de9bcc385b76 as well. Luben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Infinite retries reading the partition table
--- Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 30 Nov 2006 22:34:57 -0800 (PST) Luben Tuikov [EMAIL PROTECTED] wrote: --- Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 29 Nov 2006 17:22:48 -0800 (PST) Luben Tuikov [EMAIL PROTECTED] wrote: Suppose reading sector 0 always reports an error, sense key HARDWARE ERROR. What I'm observing is that the request to read sector 0, reading partition information, is retried forever, ad infinitum. Does anyone have a patch to resolve this? (2.6.19-rc6) Please send a backtrace so we can see where the offending loop occurs. I posted a patch to linux-scsi hm. Does sending patches to linux-scsi get them applied? It might, I don't know. Good question -- I don't know either. which resolves this issue: http://marc.theaimsgroup.com/?l=linux-scsim=116485834119885w=2 That looks like it prevents the IO error. But why was an IO error causing an infinite loop? What piece of code was initiating the retries? Here is what happens: sector 0 is broken -- the device cannot read the media at that location. The device properly returns a certain type of uncorrectable MEDIUM ERROR (ASC: UNRECOVERABLE READ ERR). SCSI Core loops around its retries (which this patch fixes) and eventually gives up and sends it for completion. This is what happens when scsi_check_sense() returns NEEDS_RETRY to scsi_decide_disposition() to scsi_softirq(). The first chunk of the patch fixes this. We end up in scsi_io_completion(), where good_bytes = 0, and result = 0x0802 (DRIVER SENSE and CHECK CONDITION). This statement in scsi_io_completion() causes the infinite retry loop: if (scsi_end_request(cmd, 1, good_bytes, !!result) == NULL) return; substitute to get: scsi_end_request(cmd, uptodate=1, uptodate bytes=0, retry=1) Yeah, but it doesn't make sense to call scsi_end_request() with uptodate=1 and uptodate bytes = 0. This causes the infinite retry, since the code tries to re-read the whole xfer size (0 bytes were uptodate and retry=1), from the bad media. That is, we want to set uptodate=1 iff there was at least 1 byte up to date. Else if nothing was read, uptodate bytes = 0, then we should pass uptodate = 0, uptodate_bytes = total xfer, to mean the whole xfer is not uptodate; and retry iff there was no error. (This is the very bottom of the function.) ... I know, I know, but that's what we've got. See this commit 03aba2f79594ca94d159c8bab454de9bcc385b76 as well. Luben - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Infinite retries reading the partition table
--- Andrew Morton <[EMAIL PROTECTED]> wrote: > On Wed, 29 Nov 2006 17:22:48 -0800 (PST) > Luben Tuikov <[EMAIL PROTECTED]> wrote: > > > Suppose reading sector 0 always reports an error, > > sense key HARDWARE ERROR. > > > > What I'm observing is that the request to read sector 0, > > reading partition information, is retried forever, ad infinitum. > > > > Does anyone have a patch to resolve this? (2.6.19-rc6) > > > > Please send a backtrace so we can see where the offending loop occurs. I posted a patch to linux-scsi which resolves this issue: http://marc.theaimsgroup.com/?l=linux-scsi=116485834119885=2 Luben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Infinite retries reading the partition table
--- Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 29 Nov 2006 17:22:48 -0800 (PST) Luben Tuikov [EMAIL PROTECTED] wrote: Suppose reading sector 0 always reports an error, sense key HARDWARE ERROR. What I'm observing is that the request to read sector 0, reading partition information, is retried forever, ad infinitum. Does anyone have a patch to resolve this? (2.6.19-rc6) Please send a backtrace so we can see where the offending loop occurs. I posted a patch to linux-scsi which resolves this issue: http://marc.theaimsgroup.com/?l=linux-scsim=116485834119885w=2 Luben - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Infinite retries reading the partition table
--- Luben Tuikov <[EMAIL PROTECTED]> wrote: > Suppose reading sector 0 always reports an error, > sense key HARDWARE ERROR. > > What I'm observing is that the request to read sector 0, > reading partition information, is retried forever, ad infinitum. > > Does anyone have a patch to resolve this? (2.6.19-rc6) Actually the device sends SK: MEDIUM ERROR, ASC: UNRECOVERED READ ERR, but SCSI Core seems to retry reading the partition table (sector 0) forever. Anyone seen this and/or has a patch in their tree for it? Luben P.S. This is fairly straightforward to inject/test. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Infinite retries reading the partition table
Suppose reading sector 0 always reports an error, sense key HARDWARE ERROR. What I'm observing is that the request to read sector 0, reading partition information, is retried forever, ad infinitum. Does anyone have a patch to resolve this? (2.6.19-rc6) Thanks, Luben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Infinite retries reading the partition table
Suppose reading sector 0 always reports an error, sense key HARDWARE ERROR. What I'm observing is that the request to read sector 0, reading partition information, is retried forever, ad infinitum. Does anyone have a patch to resolve this? (2.6.19-rc6) Thanks, Luben - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Infinite retries reading the partition table
--- Luben Tuikov [EMAIL PROTECTED] wrote: Suppose reading sector 0 always reports an error, sense key HARDWARE ERROR. What I'm observing is that the request to read sector 0, reading partition information, is retried forever, ad infinitum. Does anyone have a patch to resolve this? (2.6.19-rc6) Actually the device sends SK: MEDIUM ERROR, ASC: UNRECOVERED READ ERR, but SCSI Core seems to retry reading the partition table (sector 0) forever. Anyone seen this and/or has a patch in their tree for it? Luben P.S. This is fairly straightforward to inject/test. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13-mm2 1/3] sas_class: include files in include/scsi/sas/
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13-mm2/Documentation/dontdiff -Naur
linux-2.6.13-mm2-orig/include/scsi/sas/sas.h
linux-2.6.13-mm2/include/scsi/sas/sas.h
--- linux-2.6.13-mm2-orig/include/scsi/sas/sas.h1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13-mm2/include/scsi/sas/sas.h 2005-09-09 11:13:28.0
-0400
@@ -0,0 +1,164 @@
+/*
+ * SAS structures and definitions header file
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+ * USA
+ *
+ * $Id: //depot/sas-class/sas.h#23 $
+ */
+
+#ifndef _SAS_H_
+#define _SAS_H_
+
+#include
+#include
+
+#define SAS_ADDR_SIZE8
+#define HASHED_SAS_ADDR_SIZE 3
+#define SAS_ADDR(_sa) (be64_to_cpu(*(__be64 *)(_sa)))
+
+enum sas_oob_mode {
+ OOB_NOT_CONNECTED,
+ SATA_OOB_MODE,
+ SAS_OOB_MODE
+};
+
+/* See sas_discover.c if you plan on changing these.
+ */
+enum sas_dev_type {
+ NO_DEVICE = 0, /* protocol */
+ SAS_END_DEV = 1, /* protocol */
+ EDGE_DEV= 2, /* protocol */
+ FANOUT_DEV = 3, /* protocol */
+ SAS_HA = 4,
+ SATA_DEV= 5,
+ SATA_PM = 7,
+ SATA_PM_PORT= 8,
+};
+
+enum sas_phy_linkrate {
+ PHY_LINKRATE_NONE = 0,
+ PHY_LINKRATE_UNKNOWN = 0,
+ PHY_DISABLED,
+ PHY_RESET_PROBLEM,
+ PHY_SPINUP_HOLD,
+ PHY_PORT_SELECTOR,
+PHY_LINKRATE_1_5 = 0x08,
+ PHY_LINKRATE_G1 = PHY_LINKRATE_1_5,
+ PHY_LINKRATE_3 = 0x09,
+ PHY_LINKRATE_G2 = PHY_LINKRATE_3,
+ PHY_LINKRATE_6 = 0x0A,
+};
+
+/* Partly from IDENTIFY address frame. */
+enum sas_proto {
+ SATA_PROTO= 1,
+ SAS_PROTO_SMP = 2,/* protocol */
+ SAS_PROTO_STP = 4,/* protocol */
+ SAS_PROTO_SSP = 8,/* protocol */
+ SAS_PROTO_ALL = 0xE,
+};
+
+/* From the spec; local phys only */
+enum phy_func {
+ PHY_FUNC_NOP,
+ PHY_FUNC_LINK_RESET, /* Enables the phy */
+ PHY_FUNC_HARD_RESET,
+ PHY_FUNC_DISABLE,
+ PHY_FUNC_CLEAR_ERROR_LOG = 5,
+ PHY_FUNC_CLEAR_AFFIL,
+ PHY_FUNC_TX_SATA_PS_SIGNAL,
+ PHY_FUNC_RELEASE_SPINUP_HOLD = 0x10, /* LOCAL PORT ONLY! */
+};
+
+#include
+
+/* SAS LLDD would need to report only _very_few_ of those, like BROADCAST.
+ * Most of those are here for completeness.
+ */
+enum sas_prim {
+ SAS_PRIM_AIP_NORMAL = 1,
+ SAS_PRIM_AIP_R0 = 2,
+ SAS_PRIM_AIP_R1 = 3,
+ SAS_PRIM_AIP_R2 = 4,
+ SAS_PRIM_AIP_WC = 5,
+ SAS_PRIM_AIP_WD = 6,
+ SAS_PRIM_AIP_WP = 7,
+ SAS_PRIM_AIP_RWP= 8,
+
+ SAS_PRIM_BC_CH = 9,
+ SAS_PRIM_BC_RCH0= 10,
+ SAS_PRIM_BC_RCH1= 11,
+ SAS_PRIM_BC_R0 = 12,
+ SAS_PRIM_BC_R1 = 13,
+ SAS_PRIM_BC_R2 = 14,
+ SAS_PRIM_BC_R3 = 15,
+ SAS_PRIM_BC_R4 = 16,
+
+ SAS_PRIM_NOTIFY_ENSP= 17,
+ SAS_PRIM_NOTIFY_R0 = 18,
+ SAS_PRIM_NOTIFY_R1 = 19,
+ SAS_PRIM_NOTIFY_R2 = 20,
+
+ SAS_PRIM_CLOSE_CLAF = 21,
+ SAS_PRIM_CLOSE_NORM = 22,
+ SAS_PRIM_CLOSE_R0 = 23,
+ SAS_PRIM_CLOSE_R1 = 24,
+
+ SAS_PRIM_OPEN_RTRY = 25,
+ SAS_PRIM_OPEN_RJCT = 26,
+ SAS_PRIM_OPEN_ACPT = 27,
+
+ SAS_PRIM_DONE = 28,
+ SAS_PRIM_BREAK = 29,
+
+ SATA_PRIM_DMAT = 33,
+ SATA_PRIM_PMNAK = 34,
+ SATA_PRIM_PMACK = 35,
+ SATA_PRIM_PMREQ_S = 36,
+ SATA_PRIM_PMREQ_P = 37,
+ SATA_SATA_R_ERR = 38,
+};
+
+enum sas_open_rej_reason {
+ /* Abandon open */
+ SAS_OREJ_UNKNOWN = 0,
+ SAS_OREJ_BAD_DEST = 1,
+ SAS_OREJ_CONN_RATE = 2,
+ SAS_OREJ_EPROTO= 3,
+ SAS_OREJ_RESV_AB0 = 4,
+ SAS_OREJ_RESV_AB1 = 5,
+ SAS_OREJ_RESV_AB2 = 6,
+ SAS_OREJ_RESV_AB3 = 7,
+ SAS_OREJ_WRONG_DEST= 8,
+ SAS_OREJ_STP_NORES = 9,
+
+ /* Retry open */
+ SAS_OREJ_NO_DEST = 10,
+ SAS_OREJ_PATH_BLOCKED = 11,
+ SAS_OREJ_RSVD_CONT0 = 12,
+ SAS_OREJ_RSVD_CONT1 = 13,
+ SAS_ORE
[PATCH 2.6.13-mm2 0/3] scsi: SAS: Makefile and Kconfig
Andrew, The following is a patchset of the SAS code as posted today but it has the suggestions by Nish and Alexey, and it is against -mm2 tree. Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]> diff -X linux-2.6.13-mm2/Documentation/dontdiff -Nau linux-2.6.13-mm2-orig/drivers/scsi/Kconfig linux-2.6.13-mm2/drivers/scsi/Kconfig --- linux-2.6.13-mm2-orig/drivers/scsi/Kconfig 2005-09-09 17:49:57.0 -0400 +++ linux-2.6.13-mm2/drivers/scsi/Kconfig 2005-09-09 17:45:35.0 -0400 @@ -260,6 +260,16 @@ endmenu + +menu "SCSI Transport Layers" + +depends on SCSI + +source "drivers/scsi/sas-class/Kconfig" + +endmenu + + menu "SCSI low-level drivers" depends on SCSI!=n @@ -330,6 +340,8 @@ To compile this driver as a module, choose M here: the module will be called wd7000. +source "drivers/scsi/aic94xx/Kconfig" + config SCSI_ACARD tristate "ACARD SCSI support" depends on PCI && SCSI diff -X linux-2.6.13-mm2/Documentation/dontdiff -Nau linux-2.6.13-mm2-orig/drivers/scsi/Makefile linux-2.6.13-mm2/drivers/scsi/Makefile --- linux-2.6.13-mm2-orig/drivers/scsi/Makefile 2005-09-09 17:49:57.0 -0400 +++ linux-2.6.13-mm2/drivers/scsi/Makefile 2005-09-09 17:45:35.0 -0400 @@ -31,6 +31,7 @@ obj-$(CONFIG_SCSI_SPI_ATTRS) += scsi_transport_spi.o obj-$(CONFIG_SCSI_FC_ATTRS)+= scsi_transport_fc.o obj-$(CONFIG_SCSI_ISCSI_ATTRS) += scsi_transport_iscsi.o +obj-$(CONFIG_SAS_CLASS)+= sas-class/ obj-$(CONFIG_ISCSI_TCP)+= iscsi_tcp.o obj-$(CONFIG_SCSI_AMIGA7XX)+= amiga7xx.o 53c7xx.o @@ -64,6 +65,7 @@ obj-$(CONFIG_SCSI_AIC7XXX) += aic7xxx/ obj-$(CONFIG_SCSI_AIC79XX) += aic7xxx/ obj-$(CONFIG_SCSI_AACRAID) += aacraid/ +obj-$(CONFIG_SCSI_AIC94XX) += aic94xx/ obj-$(CONFIG_SCSI_AIC7XXX_OLD) += aic7xxx_old.o obj-$(CONFIG_SCSI_ARCMSR) += arcmsr/ obj-$(CONFIG_SCSI_IPS) += ips.o - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13 15/14+1] sas-class: include files in include/scsi/sas/
Those files live in include/scsi/sas/ and were missed in the
previous patchset:
sas.h
sas_class.h
sas_discover.h
sas_expander.h
sas_frames.h
sas_frames_be.h
sas_frames_le.h
sas_task.h
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/include/scsi/sas/sas.h linux-2.6.13/include/scsi/sas/sas.h
--- linux-2.6.13-orig/include/scsi/sas/sas.h1969-12-31 19:00:00.0
-0500
+++ linux-2.6.13/include/scsi/sas/sas.h 2005-09-09 11:13:28.0 -0400
@@ -0,0 +1,164 @@
+/*
+ * SAS structures and definitions header file
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+ * USA
+ *
+ * $Id: //depot/sas-class/sas.h#23 $
+ */
+
+#ifndef _SAS_H_
+#define _SAS_H_
+
+#include
+#include
+
+#define SAS_ADDR_SIZE8
+#define HASHED_SAS_ADDR_SIZE 3
+#define SAS_ADDR(_sa) (be64_to_cpu(*(__be64 *)(_sa)))
+
+enum sas_oob_mode {
+ OOB_NOT_CONNECTED,
+ SATA_OOB_MODE,
+ SAS_OOB_MODE
+};
+
+/* See sas_discover.c if you plan on changing these.
+ */
+enum sas_dev_type {
+ NO_DEVICE = 0, /* protocol */
+ SAS_END_DEV = 1, /* protocol */
+ EDGE_DEV= 2, /* protocol */
+ FANOUT_DEV = 3, /* protocol */
+ SAS_HA = 4,
+ SATA_DEV= 5,
+ SATA_PM = 7,
+ SATA_PM_PORT= 8,
+};
+
+enum sas_phy_linkrate {
+ PHY_LINKRATE_NONE = 0,
+ PHY_LINKRATE_UNKNOWN = 0,
+ PHY_DISABLED,
+ PHY_RESET_PROBLEM,
+ PHY_SPINUP_HOLD,
+ PHY_PORT_SELECTOR,
+PHY_LINKRATE_1_5 = 0x08,
+ PHY_LINKRATE_G1 = PHY_LINKRATE_1_5,
+ PHY_LINKRATE_3 = 0x09,
+ PHY_LINKRATE_G2 = PHY_LINKRATE_3,
+ PHY_LINKRATE_6 = 0x0A,
+};
+
+/* Partly from IDENTIFY address frame. */
+enum sas_proto {
+ SATA_PROTO= 1,
+ SAS_PROTO_SMP = 2,/* protocol */
+ SAS_PROTO_STP = 4,/* protocol */
+ SAS_PROTO_SSP = 8,/* protocol */
+ SAS_PROTO_ALL = 0xE,
+};
+
+/* From the spec; local phys only */
+enum phy_func {
+ PHY_FUNC_NOP,
+ PHY_FUNC_LINK_RESET, /* Enables the phy */
+ PHY_FUNC_HARD_RESET,
+ PHY_FUNC_DISABLE,
+ PHY_FUNC_CLEAR_ERROR_LOG = 5,
+ PHY_FUNC_CLEAR_AFFIL,
+ PHY_FUNC_TX_SATA_PS_SIGNAL,
+ PHY_FUNC_RELEASE_SPINUP_HOLD = 0x10, /* LOCAL PORT ONLY! */
+};
+
+#include
+
+/* SAS LLDD would need to report only _very_few_ of those, like BROADCAST.
+ * Most of those are here for completeness.
+ */
+enum sas_prim {
+ SAS_PRIM_AIP_NORMAL = 1,
+ SAS_PRIM_AIP_R0 = 2,
+ SAS_PRIM_AIP_R1 = 3,
+ SAS_PRIM_AIP_R2 = 4,
+ SAS_PRIM_AIP_WC = 5,
+ SAS_PRIM_AIP_WD = 6,
+ SAS_PRIM_AIP_WP = 7,
+ SAS_PRIM_AIP_RWP= 8,
+
+ SAS_PRIM_BC_CH = 9,
+ SAS_PRIM_BC_RCH0= 10,
+ SAS_PRIM_BC_RCH1= 11,
+ SAS_PRIM_BC_R0 = 12,
+ SAS_PRIM_BC_R1 = 13,
+ SAS_PRIM_BC_R2 = 14,
+ SAS_PRIM_BC_R3 = 15,
+ SAS_PRIM_BC_R4 = 16,
+
+ SAS_PRIM_NOTIFY_ENSP= 17,
+ SAS_PRIM_NOTIFY_R0 = 18,
+ SAS_PRIM_NOTIFY_R1 = 19,
+ SAS_PRIM_NOTIFY_R2 = 20,
+
+ SAS_PRIM_CLOSE_CLAF = 21,
+ SAS_PRIM_CLOSE_NORM = 22,
+ SAS_PRIM_CLOSE_R0 = 23,
+ SAS_PRIM_CLOSE_R1 = 24,
+
+ SAS_PRIM_OPEN_RTRY = 25,
+ SAS_PRIM_OPEN_RJCT = 26,
+ SAS_PRIM_OPEN_ACPT = 27,
+
+ SAS_PRIM_DONE = 28,
+ SAS_PRIM_BREAK = 29,
+
+ SATA_PRIM_DMAT = 33,
+ SATA_PRIM_PMNAK = 34,
+ SATA_PRIM_PMACK = 35,
+ SATA_PRIM_PMREQ_S = 36,
+ SATA_PRIM_PMREQ_P = 37,
+ SATA_SATA_R_ERR = 38,
+};
+
+enum sas_open_rej_reason {
+ /* Abandon open */
+ SAS_OREJ_UNKNOWN = 0,
+ SAS_OREJ_BAD_DEST = 1,
+ SAS_OREJ_CONN_RATE = 2,
+ SAS_OREJ_EPROTO= 3,
+ SAS_OREJ_RESV_AB0 = 4,
+ SAS_OREJ_RESV_AB1 = 5,
+ SAS_OREJ_RESV_AB2 = 6,
+ SAS_OREJ_RESV_AB3 = 7,
+ SAS_OREJ_WRONG_DEST= 8,
+ SAS_OREJ_STP_NORES = 9,
+
+ /
Re: [PATCH 2.6.13 9/14] sas-class: sas_expander.c Expander discovery and configuration
On 09/09/05 16:05, Nish Aravamudan wrote: > On 9/9/05, Luben Tuikov <[EMAIL PROTECTED]> wrote: > >>Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]> > > > > > >>--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_expander.c 1969-12-31 >>19:00:00.0 -0500 >>+++ linux-2.6.13/drivers/scsi/sas-class/sas_expander.c 2005-09-09 >>11:14:29.0 -0400 > > > > > +static int sas_ex_general(struct domain_device *dev) > > > > + set_current_state(TASK_INTERRUPTIBLE); > + schedule_timeout(5*HZ); > > Can you use msleep_interruptible() here? I don't see wait-queues in > the immediate vicinity. If not, and you're going for the normal -mm > route (and from there to mainline), can you use > schedule_timeout_interruptible(), please? Yes, sure. I don't see why not. Luben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.13 1/20] aic94xx: Makefile
On 09/09/05 16:18, Alexey Dobriyan wrote: > On Fri, Sep 09, 2005 at 03:32:05PM -0400, Luben Tuikov wrote: > >>--- linux-2.6.13-orig/drivers/scsi/aic94xx/Makefile >>+++ linux-2.6.13/drivers/scsi/aic94xx/Makefile > > >>+CHECK = sparse -Wbitwise > > > make C=1 CHECK="sparse -Wbitwise" > or > make C=1 > > >>+clean-files += *~ > > > Don't override what other people want. Ok, will do. Luben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.13 5/14] sas-class: sas_discover.c Discover process (end devices)
On 09/09/05 15:59, Nish Aravamudan wrote: > On 9/9/05, Luben Tuikov <[EMAIL PROTECTED]> wrote: > >>Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]> > > > > > > +static int sas_execute_task(struct sas_task *task, void *buffer, int size, > + int pci_dma_dir) > > > > + set_current_state(TASK_INTERRUPTIBLE); > + schedule_timeout(HZ); > > > > + set_current_state(TASK_INTERRUPTIBLE); > + schedule_timeout(5*HZ); > > Can you use msleep_interruptible() here? I don't see wait-queues in > the immediate vicinity. If not, and you're going for the normal -mm > route (and from there to mainline), can you use > schedule_timeout_interruptible(), please? Yes, sure. I don't see why not. Luben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13 4/14] sas-class: sas_common.c Common functions
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_common.c
linux-2.6.13/drivers/scsi/sas-class/sas_common.c
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_common.c 1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/sas-class/sas_common.c2005-09-09
11:14:29.0 -0400
@@ -0,0 +1,115 @@
+/*
+ * Serial Attached SCSI (SAS) class common functions
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+ * USA
+ *
+ * $Id: //depot/sas-class/sas_common.c#8 $
+ */
+
+#include
+#include "sas_internal.h"
+
+int sas_show_class(enum sas_class class, char *buf)
+{
+ static const char *class_str[] = {
+ [SAS] = "SAS",
+ [EXPANDER] = "EXPANDER",
+ };
+ return sprintf(buf, "%s\n", class_str[class]);
+}
+
+int sas_show_proto(enum sas_proto proto, char *page)
+{
+ static const char *proto_str[] = {
+ [SATA_PROTO] = "SATA",
+ [SAS_PROTO_SMP] = "SMP",
+ [SAS_PROTO_STP] = "STP",
+ [SAS_PROTO_SSP] = "SSP",
+ };
+ int v;
+ char *buf = page;
+
+ for (v = 1; proto != 0 && v <= SAS_PROTO_SSP; v <<= 1) {
+ if (v & proto) {
+ buf += sprintf(buf, "%s", proto_str[v]);
+
+ if (proto & ~((v<<1)-1))
+ buf += sprintf(buf, "|");
+ else
+ buf += sprintf(buf, "\n");
+ }
+ }
+ return buf-page;
+}
+
+int sas_show_linkrate(enum sas_phy_linkrate linkrate, char *page)
+{
+ static const char *phy_linkrate_str[] = {
+ [PHY_LINKRATE_NONE] = "",
+ [PHY_DISABLED] = "disabled",
+ [PHY_RESET_PROBLEM] = "phy reset problem",
+ [PHY_SPINUP_HOLD] = "phy spinup hold",
+ [PHY_PORT_SELECTOR] = "phy port selector",
+ [PHY_LINKRATE_1_5] = "1,5 GB/s",
+ [PHY_LINKRATE_3] = "3,0 GB/s",
+ [PHY_LINKRATE_6] = "6,0 GB/s",
+ };
+ return sprintf(page, "%s\n", phy_linkrate_str[linkrate]);
+}
+
+int sas_show_oob_mode(enum sas_oob_mode oob_mode, char *buf)
+{
+ switch (oob_mode) {
+ case OOB_NOT_CONNECTED:
+ return sprintf(buf, "%s", "");
+ break;
+ case SATA_OOB_MODE:
+ return sprintf(buf, "%s\n", "SATA");
+ break;
+ case SAS_OOB_MODE:
+ return sprintf(buf, "%s\n", "SAS");
+ break;
+ }
+ return 0;
+}
+
+void sas_hash_addr(u8 *hashed, const u8 *sas_addr)
+{
+ const u32 poly = 0x00DB2777;
+ u32 r = 0;
+ int i;
+
+ for (i = 0; i < 8; i++) {
+ int b;
+ for (b = 7; b >= 0; b--) {
+ r <<= 1;
+ if ((1 << b) & sas_addr[i]) {
+ if (!(r & 0x0100))
+ r ^= poly;
+ } else if (r & 0x0100)
+ r ^= poly;
+ }
+ }
+
+ hashed[0] = (r >> 16) & 0xFF;
+ hashed[1] = (r >> 8) & 0xFF ;
+ hashed[2] = r & 0xFF;
+}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13 11/14] sas-class: sas_internal.h SAS Layer internal header file
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]> diff -X linux-2.6.13/Documentation/dontdiff -Naur linux-2.6.13-orig/drivers/scsi/sas-class/sas_internal.h linux-2.6.13/drivers/scsi/sas-class/sas_internal.h --- linux-2.6.13-orig/drivers/scsi/sas-class/sas_internal.h 1969-12-31 19:00:00.0 -0500 +++ linux-2.6.13/drivers/scsi/sas-class/sas_internal.h 2005-09-09 11:14:47.0 -0400 @@ -0,0 +1,79 @@ +/* + * Serial Attached SCSI (SAS) class internal header file + * + * Copyright (C) 2005 Adaptec, Inc. All rights reserved. + * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]> + * + * This file is licensed under GPLv2. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of the + * License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 + * USA + * + * $Id: //depot/sas-class/sas_internal.h#35 $ + */ + +#ifndef _SAS_INTERNAL_H_ +#define _SAS_INTERNAL_H_ + +#include + +#define sas_printk(fmt, ...) printk(KERN_NOTICE "sas: " fmt, ## __VA_ARGS__) + +#ifdef SAS_DEBUG +#define SAS_DPRINTK(fmt, ...) printk(KERN_NOTICE "sas: " fmt, ## __VA_ARGS__) +#else +#define SAS_DPRINTK(fmt, ...) +#endif + +int sas_show_class(enum sas_class class, char *buf); +int sas_show_proto(enum sas_proto proto, char *buf); +int sas_show_linkrate(enum sas_phy_linkrate linkrate, char *buf); +int sas_show_oob_mode(enum sas_oob_mode oob_mode, char *buf); + +int sas_register_phys(struct sas_ha_struct *sas_ha); +void sas_unregister_phys(struct sas_ha_struct *sas_ha); + +int sas_register_ports(struct sas_ha_struct *sas_ha); +void sas_unregister_ports(struct sas_ha_struct *sas_ha); + +int sas_register_scsi_host(struct sas_ha_struct *sas_ha); +void sas_unregister_scsi_host(struct sas_ha_struct *sas_ha); + +int sas_start_event_thread(struct sas_ha_struct *sas_ha); +void sas_kill_event_thread(struct sas_ha_struct *sas_ha); + +int sas_init_queue(struct sas_ha_struct *sas_ha); +void sas_shutdown_queue(struct sas_ha_struct *sas_ha); + +void sas_phye_loss_of_signal(struct sas_phy *phy); +void sas_phye_oob_done(struct sas_phy *phy); +void sas_phye_oob_error(struct sas_phy *phy); +void sas_phye_spinup_hold(struct sas_phy *phy); + +void sas_deform_port(struct sas_phy *phy); + +void sas_porte_bytes_dmaed(struct sas_phy *phy); +void sas_porte_broadcast_rcvd(struct sas_phy *phy); +void sas_porte_link_reset_err(struct sas_phy *phy); +void sas_porte_timer_event(struct sas_phy *phy); +void sas_porte_hard_reset(struct sas_phy *phy); + +int sas_reserve_free_id(struct sas_port *port); +void sas_reserve_scsi_id(struct sas_port *port, int id); +void sas_release_scsi_id(struct sas_port *port, int id); + +void sas_hae_reset(struct sas_ha_struct *sas_ha); + +#endif /* _SAS_INTERNAL_H_ */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13 10/14] sas-class: sas_init.c SAS Transport Layer initialization
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_init.c
linux-2.6.13/drivers/scsi/sas-class/sas_init.c
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_init.c 1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/sas-class/sas_init.c 2005-09-09
11:14:29.0 -0400
@@ -0,0 +1,229 @@
+/*
+ * Serial Attached SCSI (SAS) Transport Layer initialization
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+ * USA
+ *
+ * $Id: //depot/sas-class/sas_init.c#44 $
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "sas_internal.h"
+#include
+
+kmem_cache_t *sas_task_cache;
+
+/* -- HA events -- */
+
+void sas_hae_reset(struct sas_ha_struct *sas_ha)
+{
+ ;
+}
+
+/* -- HA attributes -- */
+
+static ssize_t sas_ha_name_show(struct sas_ha_struct *sas_ha, char *buf)
+{
+ if (sas_ha->sas_ha_name)
+ return sprintf(buf, "%s\n", sas_ha->sas_ha_name);
+ return 0;
+}
+
+static ssize_t sas_ha_addr_show(struct sas_ha_struct *sas_ha, char *buf)
+{
+ return sprintf(buf, "%llx\n", SAS_ADDR(sas_ha->sas_addr));
+}
+
+/* -- SAS HA Class -- */
+
+#define to_sas_ha(_obj) container_of(to_kset(_obj),struct
sas_ha_struct,ha_kset)
+#define to_ha_attr(_attr) container_of(_attr, struct ha_attribute, attr)
+
+struct ha_attribute {
+ struct attribute attr;
+ ssize_t (*show)(struct sas_ha_struct *sas_ha, char *);
+ ssize_t (*store)(struct sas_ha_struct *sas_ha,const char *,size_t len);
+};
+
+static ssize_t ha_show_attr(struct kobject *kobj,
+struct attribute *attr,
+char *page)
+{
+ ssize_t ret = 0;
+ struct sas_ha_struct *sas_ha = to_sas_ha(kobj);
+ struct ha_attribute *ha_attr = to_ha_attr(attr);
+
+ if (ha_attr->show)
+ ret = ha_attr->show(sas_ha, page);
+ return ret;
+}
+
+static struct ha_attribute ha_attrs[] = {
+ __ATTR(ha_name, 0444, sas_ha_name_show, NULL),
+ __ATTR(device_name, 0444, sas_ha_addr_show, NULL),
+ __ATTR_NULL,
+};
+
+static struct attribute *def_attrs[ARRAY_SIZE(ha_attrs)];
+
+static struct sysfs_ops ha_sysfs_ops = {
+ .show = ha_show_attr,
+};
+
+static struct kobj_type ha_ktype = {
+ .sysfs_ops = _sysfs_ops,
+ .default_attrs = def_attrs,
+};
+
+/* This is our "root". */
+static struct kset sas_kset = {
+ .kobj = { .name = "sas" },
+ .ktype = _ktype, /* children are of this type */
+};
+
+int sas_register_ha(struct sas_ha_struct *sas_ha)
+{
+ int i, error = 0;
+
+ spin_lock_init(_ha->phy_port_lock);
+ sas_hash_addr(sas_ha->hashed_sas_addr, sas_ha->sas_addr);
+
+ if (sas_ha->lldd_queue_size == 0)
+ sas_ha->lldd_queue_size = 1;
+ else if (sas_ha->lldd_queue_size == -1)
+ sas_ha->lldd_queue_size = 128; /* Sanity */
+
+ error = sas_register_scsi_host(sas_ha);
+ if (error) {
+ printk(KERN_NOTICE "couldn't register scsi host\n");
+ return error;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(def_attrs)-1; i++)
+ def_attrs[i] = _attrs[i].attr;
+ def_attrs[i] = NULL;
+
+ /* make sas/ appear */
+ sas_kset.kobj.parent = _ha->core.shost->shost_gendev.kobj;
+ kset_register(_kset);
+
+ /* make sas/ha/ appear */
+ kobject_set_name(_ha->ha_kset.kobj, "%s", "ha");
+ sas_ha->ha_kset.kobj.kset = _kset; /* parent */
+ sas_ha->ha_kset.kobj.ktype = sas_kset.ktype;
+ kset_register(_ha->ha_kset);
+
+ error = sas_register_phys(sas_ha);
+ if (error) {
+ printk(KERN_NOTICE "couldn't register sas phys:%d\n", error);
+ goto Undo;
+ }
+
+ error = sas_register_ports(sas_ha);
+ if (error) {
+ printk(KERN_NOTICE "couldn't register sas port
[PATCH 2.6.13 20/20] aic94xx: aic94xx_tmf.c Implements the Task Management Funcions defined by SAS
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_tmf.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_tmf.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_tmf.c1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/aic94xx/aic94xx_tmf.c 2005-09-09
11:21:23.0 -0400
@@ -0,0 +1,634 @@
+/*
+ * Aic94xx Task Management Functions
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This file is part of the aic94xx driver.
+ *
+ * The aic94xx driver is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ * The aic94xx driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with the aic94xx driver; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/aic94xx/aic94xx_tmf.c#34 $
+ */
+
+#include
+#include
+#include "aic94xx.h"
+#include "aic94xx_sas.h"
+#include "aic94xx_hwi.h"
+
+/* -- Internal enqueue -- */
+
+static int asd_enqueue_internal(struct asd_ascb *ascb,
+ void (*tasklet_complete)(struct asd_ascb *,
+struct done_list_struct *),
+ void (*timed_out)(unsigned long))
+{
+ int res;
+
+ ascb->tasklet_complete = tasklet_complete;
+ ascb->uldd_timer = 1;
+
+ ascb->timer.data = (unsigned long) ascb;
+ ascb->timer.function = timed_out;
+ ascb->timer.expires = jiffies + AIC94XX_SCB_TIMEOUT;
+
+ add_timer(>timer);
+
+ res = asd_post_ascb_list(ascb->ha, ascb, 1);
+ if (unlikely(res))
+ del_timer(>timer);
+ return res;
+}
+
+static inline void asd_timedout_common(unsigned long data)
+{
+ struct asd_ascb *ascb = (void *) data;
+ struct asd_seq_data *seq = >ha->seq;
+unsigned long flags;
+
+ spin_lock_irqsave(>pend_q_lock, flags);
+seq->pending--;
+list_del_init(>list);
+spin_unlock_irqrestore(>pend_q_lock, flags);
+}
+
+/* -- CLEAR NEXUS -- */
+
+static void asd_clear_nexus_tasklet_complete(struct asd_ascb *ascb,
+struct done_list_struct *dl)
+{
+ ASD_DPRINTK("%s: here\n", __FUNCTION__);
+ if (!del_timer(>timer)) {
+ ASD_DPRINTK("%s: couldn't delete timer\n", __FUNCTION__);
+ return;
+ }
+ ASD_DPRINTK("%s: opcode: 0x%x\n", __FUNCTION__, dl->opcode);
+ ascb->uldd_task = (void *) (unsigned long) dl->opcode;
+ complete(>completion);
+}
+
+static void asd_clear_nexus_timedout(unsigned long data)
+{
+ struct asd_ascb *ascb = (void *) data;
+
+ ASD_DPRINTK("%s: here\n", __FUNCTION__);
+ asd_timedout_common(data);
+ ascb->uldd_task = (void *) TMF_RESP_FUNC_FAILED;
+ complete(>completion);
+}
+
+#define CLEAR_NEXUS_PRE \
+ ASD_DPRINTK("%s: PRE\n", __FUNCTION__); \
+res = 1;\
+ ascb = asd_ascb_alloc_list(asd_ha, , GFP_KERNEL); \
+ if (!ascb) \
+ return -ENOMEM; \
+\
+ scb = ascb->scb;\
+ scb->header.opcode = CLEAR_NEXUS
+
+#define CLEAR_NEXUS_POST\
+ ASD_DPRINTK("%s: POST\n", __FUNCTION__); \
+ res = asd_enqueue_internal(ascb, asd_clear_nexus_tasklet_complete, \
+ asd_clear_nexus_timedout); \
+ if (res)\
+ goto out_err; \
+ ASD_DPRINTK("%s: clear nexus posted, waiting...\n", __FUNCTION__); \
+ wait_for_completion(>completion); \
+ res = (int) (unsigned long) ascb->uldd_task; \
+ if (res == TC_NO_ERROR) \
+ res = TMF_RESP_FUNC_COMPLETE; \
+out_err:\
+ asd_ascb_free(ascb);\
+ return res
+
+int asd_clear_nexus_ha(struct sas_ha_struct *sas_ha)
+{
+ struct asd_ha_struct *asd_ha = sas_ha->lldd_ha;
+ struct asd_ascb *ascb;
+ struct scb *scb;
+ int res;
+
+ CLEAR_NEXUS_PRE;
+ scb->clear_nexus.nexus = NEXUS_ADAPTER;
+ CLEAR_NEXUS_POST;
+}
+
+int asd_clear_nexus_port(struct sa
[PATCH 2.6.13 19/20] aic94xx: aic94xx_task.c Implements the Execute Task SCSI RPC
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_task.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_task.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_task.c 1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/aic94xx/aic94xx_task.c2005-09-09
11:21:23.0 -0400
@@ -0,0 +1,645 @@
+/*
+ * Aic94xx SAS/SATA Tasks
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This file is part of the aic94xx driver.
+ *
+ * The aic94xx driver is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ * The aic94xx driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with the aic94xx driver; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/aic94xx/aic94xx_task.c#50 $
+ */
+
+#include
+#include
+#include
+#include "aic94xx.h"
+#include "aic94xx_sas.h"
+#include "aic94xx_hwi.h"
+
+static void asd_unbuild_ata_ascb(struct asd_ascb *a);
+static void asd_unbuild_smp_ascb(struct asd_ascb *a);
+static void asd_unbuild_ssp_ascb(struct asd_ascb *a);
+
+static inline void asd_can_dequeue(struct asd_ha_struct *asd_ha, int num)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(_ha->seq.pend_q_lock, flags);
+ asd_ha->seq.can_queue += num;
+ spin_unlock_irqrestore(_ha->seq.pend_q_lock, flags);
+}
+
+/* PCI_DMA_... to our direction translation.
+ */
+static const u8 data_dir_flags[] = {
+ [PCI_DMA_BIDIRECTIONAL] = DATA_DIR_BYRECIPIENT, /* UNSPECIFIED */
+ [PCI_DMA_TODEVICE] = DATA_DIR_OUT, /* OUTBOUND */
+ [PCI_DMA_FROMDEVICE]= DATA_DIR_IN, /* INBOUND */
+ [PCI_DMA_NONE] = DATA_DIR_NONE, /* NO TRANSFER */
+};
+
+static inline int asd_map_scatterlist(struct sas_task *task,
+ struct sg_el *sg_arr,
+ unsigned long gfp_flags)
+{
+ struct asd_ascb *ascb = task->lldd_task;
+ struct asd_ha_struct *asd_ha = ascb->ha;
+ struct scatterlist *sc;
+ int num_sg, res;
+
+ if (task->data_dir == PCI_DMA_NONE)
+ return 0;
+
+ if (task->num_scatter == 0) {
+ void *p = task->scatter;
+ dma_addr_t dma = pci_map_single(asd_ha->pcidev, p,
+ task->total_xfer_len,
+ task->data_dir);
+ sg_arr[0].bus_addr = cpu_to_le64((u64)dma);
+ sg_arr[0].size = cpu_to_le32(task->total_xfer_len);
+ sg_arr[0].flags |= ASD_SG_EL_LIST_EOL;
+ return 0;
+ }
+
+ num_sg = pci_map_sg(asd_ha->pcidev, task->scatter, task->num_scatter,
+ task->data_dir);
+ if (num_sg == 0)
+ return -ENOMEM;
+
+ if (num_sg > 3) {
+ int i;
+
+ ascb->sg_arr = asd_alloc_coherent(asd_ha,
+ num_sg*sizeof(struct sg_el),
+ gfp_flags);
+ if (!ascb->sg_arr) {
+ res = -ENOMEM;
+ goto err_unmap;
+ }
+ for (sc = task->scatter, i = 0; i < num_sg; i++, sc++) {
+ struct sg_el *sg =
+ &((struct sg_el *)ascb->sg_arr->vaddr)[i];
+ sg->bus_addr = cpu_to_le64((u64)sg_dma_address(sc));
+ sg->size = cpu_to_le32((u32)sg_dma_len(sc));
+ if (i == num_sg-1)
+ sg->flags |= ASD_SG_EL_LIST_EOL;
+ }
+
+ for (sc = task->scatter, i = 0; i < 2; i++, sc++) {
+ sg_arr[i].bus_addr =
+ cpu_to_le64((u64)sg_dma_address(sc));
+ sg_arr[i].size = cpu_to_le32((u32)sg_dma_len(sc));
+ }
+ sg_arr[1].next_sg_offs = 2 * sizeof(*sg_arr);
+ sg_arr[1].flags |= ASD_SG_EL_LIST_EOS;
+
+ memset(_arr[2], 0, sizeof(*sg_arr));
+ sg_arr[2].bus_addr=cpu_to_le64((u64)ascb->sg_arr->dma_handle);
+ } else {
+
[PATCH 2.6.13 18/20] aic94xx: aic94xx_seq_microcode.c Sequencer microcode
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]> Attached in gzipped format, since it is so big. aic94xx_seq_microcode.patch.gz Description: GNU Zip compressed data
[PATCH 2.6.13 14/20] aic94xx: aic94xx_scb.c Sequencer control block management
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_scb.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_scb.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_scb.c1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/aic94xx/aic94xx_scb.c 2005-09-09
11:21:23.0 -0400
@@ -0,0 +1,726 @@
+/*
+ * Aic94xx SAS/SATA driver SCB management.
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This file is part of the aic94xx driver.
+ *
+ * The aic94xx driver is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ * The aic94xx driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with the aic94xx driver; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/aic94xx/aic94xx_scb.c#70 $
+ */
+
+#include
+
+#include "aic94xx.h"
+#include "aic94xx_reg.h"
+#include "aic94xx_hwi.h"
+#include "aic94xx_seq.h"
+
+#include "aic94xx_dump.h"
+
+/* -- EMPTY SCB -- */
+
+#define DL_PHY_MASK 7
+#define BYTES_DMAED 0
+#define PRIMITIVE_RECVD 0x08
+#define PHY_EVENT0x10
+#define LINK_RESET_ERROR 0x18
+#define TIMER_EVENT 0x20
+#define REQ_TASK_ABORT 0xF0
+#define REQ_DEVICE_RESET 0xF1
+#define SIGNAL_NCQ_ERROR 0xF2
+#define CLEAR_NCQ_ERROR 0xF3
+
+#define PHY_EVENTS_STATUS (CURRENT_LOSS_OF_SIGNAL | CURRENT_OOB_DONE \
+ | CURRENT_SPINUP_HOLD | CURRENT_GTO_TIMEOUT \
+ | CURRENT_OOB_ERROR)
+
+static inline void get_lrate_mode(struct asd_phy *phy, u8 oob_mode)
+{
+ switch (oob_mode & 7) {
+ case PHY_SPEED_60:
+ phy->sas_phy.linkrate = PHY_LINKRATE_6;
+ break;
+ case PHY_SPEED_30:
+ phy->sas_phy.linkrate = PHY_LINKRATE_3;
+ break;
+ case PHY_SPEED_15:
+ phy->sas_phy.linkrate = PHY_LINKRATE_1_5;
+ break;
+ }
+ if (oob_mode & SAS_MODE)
+ phy->sas_phy.oob_mode = SAS_OOB_MODE;
+ else if (oob_mode & SATA_MODE)
+ phy->sas_phy.oob_mode = SATA_OOB_MODE;
+}
+
+static inline void asd_phy_event_tasklet(struct asd_ascb *ascb,
+struct done_list_struct *dl)
+{
+ struct asd_ha_struct *asd_ha = ascb->ha;
+ struct sas_ha_struct *sas_ha = _ha->sas_ha;
+ int phy_id = dl->status_block[0] & DL_PHY_MASK;
+ struct asd_phy *phy = _ha->phys[phy_id];
+
+ u8 oob_status = dl->status_block[1] & PHY_EVENTS_STATUS;
+ u8 oob_mode = dl->status_block[2];
+
+ switch (oob_status) {
+ case CURRENT_LOSS_OF_SIGNAL:
+ /* directly attached device was removed */
+ ASD_DPRINTK("phy%d: device unplugged\n", phy_id);
+ asd_turn_led(asd_ha, phy_id, 0);
+ sas_phy_disconnected(>sas_phy);
+ sas_ha->notify_phy_event(>sas_phy, PHYE_LOSS_OF_SIGNAL);
+ break;
+ case CURRENT_OOB_DONE:
+ /* hot plugged device */
+ asd_turn_led(asd_ha, phy_id, 1);
+ get_lrate_mode(phy, oob_mode);
+ ASD_DPRINTK("phy%d device plugged: lrate:0x%x, proto:0x%x\n",
+ phy_id, phy->sas_phy.linkrate, phy->sas_phy.iproto);
+ sas_ha->notify_phy_event(>sas_phy, PHYE_OOB_DONE);
+ break;
+ case CURRENT_SPINUP_HOLD:
+ /* hot plug SATA, no COMWAKE sent */
+ asd_turn_led(asd_ha, phy_id, 1);
+ sas_ha->notify_phy_event(>sas_phy, PHYE_SPINUP_HOLD);
+ break;
+ case CURRENT_GTO_TIMEOUT:
+ case CURRENT_OOB_ERROR:
+ ASD_DPRINTK("phy%d error while OOB: oob status:0x%x\n", phy_id,
+ dl->status_block[1]);
+ asd_turn_led(asd_ha, phy_id, 0);
+ sas_phy_disconnected(>sas_phy);
+ sas_ha->notify_phy_event(>sas_phy, PHYE_OOB_ERROR);
+ break;
+ }
+}
+
+/* If phys are enabled sparsely, this will do the right thing. */
+static inline unsigned ord_phy(struct asd_ha_struct *asd_ha,
+ struct asd_ph
[PATCH 2.6.13 9/20] aic94xx: aic94xx_init.c Driver initialization
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_init.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_init.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_init.c 1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/aic94xx/aic94xx_init.c2005-09-09
11:21:23.0 -0400
@@ -0,0 +1,785 @@
+/*
+ * Aic94xx SAS/SATA driver initialization.
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This file is part of the aic94xx driver.
+ *
+ * The aic94xx driver is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ * The aic94xx driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with the aic94xx driver; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/aic94xx/aic94xx_init.c#93 $
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "aic94xx.h"
+#include "aic94xx_reg.h"
+#include "aic94xx_hwi.h"
+#include "aic94xx_seq.h"
+
+/* The format is "version.release.patchlevel" */
+#define ASD_DRIVER_VERSION "1.0.0"
+
+static int attach_HostRAID = 0;
+module_param_named(attach_HostRAID, attach_HostRAID, int, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(attach_HostRAID, "\n"
+ "\tEnable(1) or disable(0) attaching to HostRAID enabled host
tadapters.\n"
+ "\tDefault: 0");
+
+static int use_msi = 0;
+module_param_named(use_msi, use_msi, int, S_IRUGO);
+MODULE_PARM_DESC(use_msi, "\n"
+ "\tEnable(1) or disable(0) using PCI MSI.\n"
+ "\tDefault: 0");
+
+static int lldd_max_execute_num = 0;
+module_param_named(collector, lldd_max_execute_num, int, S_IRUGO);
+MODULE_PARM_DESC(collector, "\n"
+ "\tIf greater than one, tells the SAS Layer to run in Task Collector\n"
+ "\tMode. If 1 or 0, tells the SAS Layer to run in Direct Mode.\n"
+ "\tThe aic94xx SAS LLDD supports both modes.\n"
+ "\tDefault: 0 (Direct Mode).\n");
+
+char sas_addr_str[2*SAS_ADDR_SIZE + 1] = "";
+
+static int __devinit asd_map_memio(struct asd_ha_struct *asd_ha)
+{
+ int err, i;
+ struct asd_ha_addrspace *io_handle;
+
+ asd_ha->iospace = 0;
+ for (i = 0; i < 3; i += 2) {
+ io_handle = _ha->io_handle[i==0?0:1];
+ io_handle->start = pci_resource_start(asd_ha->pcidev, i);
+ io_handle->len = pci_resource_len(asd_ha->pcidev, i);
+ io_handle->flags = pci_resource_flags(asd_ha->pcidev, i);
+ err = -ENODEV;
+ if (!io_handle->start || !io_handle->len) {
+ asd_printk("MBAR%d start or length for %s is 0.\n",
+ i==0?0:1, pci_name(asd_ha->pcidev));
+ goto Err;
+ }
+ err = pci_request_region(asd_ha->pcidev, i, ASD_DRIVER_NAME);
+ if (err) {
+ asd_printk("couldn't reserve memory region for %s\n",
+ pci_name(asd_ha->pcidev));
+ goto Err;
+ }
+ if (io_handle->flags & IORESOURCE_CACHEABLE)
+ io_handle->addr = ioremap(io_handle->start,
+ io_handle->len);
+ else
+ io_handle->addr = ioremap_nocache(io_handle->start,
+ io_handle->len);
+ if (!io_handle->addr) {
+ asd_printk("couldn't map MBAR%d of %s\n", i==0?0:1,
+ pci_name(asd_ha->pcidev));
+ goto Err_unreq;
+ }
+ }
+
+ return 0;
+Err_unreq:
+ pci_release_region(asd_ha->pcidev, i);
+Err:
+ if (i > 0) {
+ io_handle = _ha->io_handle[0];
+ iounmap(io_handle->addr);
+ pci_release_region(asd_ha->pcidev, 0);
+ }
+ return err;
+}
+
+static void __devexit asd_unmap_memio(struct asd_ha_struct *asd_ha)
+{
+ struct asd_ha_addrspace *io_handle;
+
+ i
[PATCH 2.6.13 6/20] aic94xx: aic94xx_dump.h Dumping utility header file
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_dump.h
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_dump.h
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_dump.h 1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/aic94xx/aic94xx_dump.h2005-09-09
11:21:23.0 -0400
@@ -0,0 +1,53 @@
+/*
+ * Aic94xx SAS/SATA driver dump header file.
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This file is part of the aic94xx driver.
+ *
+ * The aic94xx driver is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ * The aic94xx driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with the aic94xx driver; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/aic94xx/aic94xx_dump.h#9 $
+ */
+
+#ifndef _AIC94XX_DUMP_H_
+#define _AIC94XX_DUMP_H_
+
+#ifdef ASD_DEBUG
+
+void asd_dump_ddb_0(struct asd_ha_struct *asd_ha);
+void asd_dump_target_ddb(struct asd_ha_struct *asd_ha, u16 site_no);
+void asd_dump_scb_sites(struct asd_ha_struct *asd_ha);
+void asd_dump_seq_state(struct asd_ha_struct *asd_ha, u8 lseq_mask);
+void asd_dump_frame_rcvd(struct asd_phy *phy,
+struct done_list_struct *dl);
+void asd_dump_scb_list(struct asd_ascb *ascb, int num);
+#else /* ASD_DEBUG */
+
+static inline void asd_dump_ddb_0(struct asd_ha_struct *asd_ha) { }
+static inline void asd_dump_target_ddb(struct asd_ha_struct *asd_ha,
+u16 site_no) { }
+static inline void asd_dump_scb_sites(struct asd_ha_struct *asd_ha) { }
+static inline void asd_dump_seq_state(struct asd_ha_struct *asd_ha,
+ u8 lseq_mask) { }
+static inline void asd_dump_frame_rcvd(struct asd_phy *phy,
+ struct done_list_struct *dl) { }
+static inline void asd_dump_scb_list(struct asd_ascb *ascb, int num) { }
+#endif /* ASD_DEBUG */
+
+#endif /* _AIC94XX_DUMP_H_ */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13 16/20] aic94xx: aic94xx_seq.c Sequencer interface
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_seq.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_seq.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_seq.c1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/aic94xx/aic94xx_seq.c 2005-09-09
11:21:23.0 -0400
@@ -0,0 +1,1317 @@
+/*
+ * Aic94xx SAS/SATA driver sequencer interface.
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * Parts of this code adapted from David Chaw's adp94xx_seq.c.
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This file is part of the aic94xx driver.
+ *
+ * The aic94xx driver is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ * The aic94xx driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with the aic94xx driver; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/aic94xx/aic94xx_seq.c#40 $
+ */
+
+#include
+#include
+#include "aic94xx_reg.h"
+#include "aic94xx_hwi.h"
+
+#include "aic94xx_seq.h"
+#include "aic94xx_dump.h"
+
+#include "aic94xx_seq_microcode.c"
+
+/* It takes no more than 0.05 us for an instruction
+ * to complete. So waiting for 1 us should be more than
+ * plenty.
+ */
+#define PAUSE_DELAY 1
+#define PAUSE_TRIES 1000
+
+static u16 first_scb_site_no = 0x;
+static u16 last_scb_site_no;
+
+/* -- Pause/Unpause CSEQ/LSEQ -- */
+
+/**
+ * asd_pause_cseq - pause the central sequencer
+ * @asd_ha: pointer to host adapter structure
+ *
+ * Return 0 on success, negative on failure.
+ */
+int asd_pause_cseq(struct asd_ha_struct *asd_ha)
+{
+ int count = PAUSE_TRIES;
+ u32 arp2ctl;
+
+ arp2ctl = asd_read_reg_dword(asd_ha, CARP2CTL);
+ if (arp2ctl & PAUSED)
+ return 0;
+
+ asd_write_reg_dword(asd_ha, CARP2CTL, arp2ctl | EPAUSE);
+ do {
+ arp2ctl = asd_read_reg_dword(asd_ha, CARP2CTL);
+ if (arp2ctl & PAUSED)
+ return 0;
+ udelay(PAUSE_DELAY);
+ } while (--count > 0);
+
+ ASD_DPRINTK("couldn't pause CSEQ\n");
+ return -1;
+}
+
+/**
+ * asd_unpause_cseq - unpause the central sequencer.
+ * @asd_ha: pointer to host adapter structure.
+ *
+ * Return 0 on success, negative on error.
+ */
+int asd_unpause_cseq(struct asd_ha_struct *asd_ha)
+{
+ u32 arp2ctl;
+ int count = PAUSE_TRIES;
+
+ arp2ctl = asd_read_reg_dword(asd_ha, CARP2CTL);
+ if (!(arp2ctl & PAUSED))
+ return 0;
+
+ asd_write_reg_dword(asd_ha, CARP2CTL, arp2ctl & ~EPAUSE);
+ do {
+ arp2ctl = asd_read_reg_dword(asd_ha, CARP2CTL);
+ if (!(arp2ctl & PAUSED))
+ return 0;
+ udelay(PAUSE_DELAY);
+ } while (--count > 0);
+
+ ASD_DPRINTK("couldn't unpause the CSEQ\n");
+ return -1;
+}
+
+/**
+ * asd_seq_pause_lseq - pause a link sequencer
+ * @asd_ha: pointer to a host adapter structure
+ * @lseq: link sequencer of interest
+ *
+ * Return 0 on success, negative on error.
+ */
+static inline int asd_seq_pause_lseq(struct asd_ha_struct *asd_ha, int lseq)
+{
+ u32arp2ctl;
+ intcount = PAUSE_TRIES;
+
+ arp2ctl = asd_read_reg_dword(asd_ha, LmARP2CTL(lseq));
+ if (arp2ctl & PAUSED)
+ return 0;
+
+ asd_write_reg_dword(asd_ha, LmARP2CTL(lseq), arp2ctl | EPAUSE);
+ do {
+ arp2ctl = asd_read_reg_dword(asd_ha, LmARP2CTL(lseq));
+ if (arp2ctl & PAUSED)
+ return 0;
+ udelay(PAUSE_DELAY);
+ } while (--count > 0);
+
+ ASD_DPRINTK("couldn't pause LSEQ %d\n", lseq);
+ return -1;
+}
+
+/**
+ * asd_pause_lseq - pause the link sequencer(s)
+ * @asd_ha: pointer to host adapter structure
+ * @lseq_mask: mask of link sequencers of interest
+ *
+ * Return 0 on success, negative on failure.
+ */
+int asd_pause_lseq(struct asd_ha_struct *asd_ha, u8 lseq_mask)
+{
+ int lseq;
+ int err = 0;
+
+ for_each_sequencer(lseq_mask, lseq_mask, lseq) {
+ err = asd_seq_pause_lseq(asd_ha, lseq);
+ if (err)
+ return err;
+ }
+
+ return err;
+}
+
+/**
+ * asd
[PATCH 2.6.13 12/14] sas-class: sas_phy.c SAS Phy (events, attrs, initializaion)
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_phy.c
linux-2.6.13/drivers/scsi/sas-class/sas_phy.c
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_phy.c 1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/sas-class/sas_phy.c 2005-09-09
11:14:29.0 -0400
@@ -0,0 +1,307 @@
+/*
+ * Serial Attached SCSI (SAS) Phy class
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/sas-class/sas_phy.c#37 $
+ */
+
+#include "sas_internal.h"
+
+/* -- Phy events -- */
+
+void sas_phye_loss_of_signal(struct sas_phy *phy)
+{
+ phy->error = 0;
+ sas_deform_port(phy);
+}
+
+void sas_phye_oob_done(struct sas_phy *phy)
+{
+ phy->error = 0;
+}
+
+void sas_phye_oob_error(struct sas_phy *phy)
+{
+ struct sas_ha_struct *sas_ha = phy->ha;
+ struct sas_port *port = phy->port;
+
+ sas_deform_port(phy);
+
+ if (!port && phy->enabled && sas_ha->lldd_control_phy) {
+ phy->error++;
+ switch (phy->error) {
+ case 1:
+ case 2:
+ sas_ha->lldd_control_phy(phy, PHY_FUNC_HARD_RESET);
+ break;
+ case 3:
+ default:
+ phy->error = 0;
+ phy->enabled = 0;
+ sas_ha->lldd_control_phy(phy, PHY_FUNC_DISABLE);
+ break;
+ }
+ }
+}
+
+void sas_phye_spinup_hold(struct sas_phy *phy)
+{
+ struct sas_ha_struct *sas_ha = phy->ha;
+
+ phy->error = 0;
+ sas_ha->lldd_control_phy(phy, PHY_FUNC_RELEASE_SPINUP_HOLD);
+}
+
+/* -- Phy attributes -- */
+
+static ssize_t sas_phy_id_show(struct sas_phy *phy, char *buf)
+{
+ return sprintf(buf, "%d\n", phy->id);
+}
+
+static ssize_t sas_phy_enabled_show(struct sas_phy *phy, char *buf)
+{
+ return sprintf(buf, "%d\n", phy->enabled);
+}
+
+static ssize_t sas_phy_enabled_store(struct sas_phy *phy, const char *buf,
+size_t size)
+{
+ if (size > 0) {
+ if (buf[0] == '1')
+ phy->ha->lldd_control_phy(phy, PHY_FUNC_LINK_RESET);
+ }
+ return size;
+}
+
+static ssize_t sas_phy_class_show(struct sas_phy *phy, char *buf)
+{
+ if (!phy->enabled)
+ return 0;
+ return sas_show_class(phy->class, buf);
+}
+
+static ssize_t sas_phy_iproto_show(struct sas_phy *phy, char *page)
+{
+ if (!phy->enabled)
+ return 0;
+ return sas_show_proto(phy->iproto, page);
+}
+
+static ssize_t sas_phy_tproto_show(struct sas_phy *phy, char *page)
+{
+ if (!phy->enabled)
+ return 0;
+ return sas_show_proto(phy->tproto, page);
+}
+
+static ssize_t sas_phy_type_show(struct sas_phy *phy, char *buf)
+{
+ static const char *phy_type_str[] = {
+ [PHY_TYPE_PHYSICAL] = "physical",
+ [PHY_TYPE_VIRTUAL] = "virtual",
+ };
+ if (!phy->enabled)
+ return 0;
+ return sprintf(buf, "%s\n", phy_type_str[phy->type]);
+}
+
+static ssize_t sas_phy_role_show(struct sas_phy *phy, char *page)
+{
+ static const char *phy_role_str[] = {
+ [PHY_ROLE_NONE] = "none",
+ [PHY_ROLE_TARGET] = "target",
+ [PHY_ROLE_INITIATOR] = "initiator",
+ };
+ int v;
+ char *buf = page;
+
+ if (!phy->enabled)
+ return 0;
+
+ if (phy->role == PHY_ROLE_NONE)
+ return sprintf(buf, "%s\n", phy_role_str[PHY_ROLE_NONE]);
+
+ for (v = 1; v <= PHY_ROLE_INITIATOR; v <<= 1) {
+ if (v & phy->role) {
+ buf += sprintf(buf, "%s", phy_role_str[v]);
+ if (phy->role & ~((
[PATCH 2.6.13 8/20] aic94xx: aic94xx_hwi.h Hardware interface header file
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_hwi.h
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_hwi.h
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_hwi.h1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/aic94xx/aic94xx_hwi.h 2005-09-09
11:21:23.0 -0400
@@ -0,0 +1,393 @@
+/*
+ * Aic94xx SAS/SATA driver hardware interface header file.
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This file is part of the aic94xx driver.
+ *
+ * The aic94xx driver is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ * The aic94xx driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with the aic94xx driver; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/aic94xx/aic94xx_hwi.h#71 $
+ */
+
+#ifndef _AIC94XX_HWI_H_
+#define _AIC94XX_HWI_H_
+
+#include
+#include
+#include
+
+#include "aic94xx.h"
+#include "aic94xx_sas.h"
+
+/* Define ASD_MAX_PHYS to the maximum phys ever. Currently 8. */
+#define ASD_MAX_PHYS 8
+#define ASD_PCBA_SN_SIZE 12
+
+/* Those are to be further named properly, the "RAZORx" part, and
+ * subsequently included in include/linux/pci_ids.h.
+ */
+#define PCI_DEVICE_ID_ADAPTEC2_RAZOR10 0x410
+#define PCI_DEVICE_ID_ADAPTEC2_RAZOR12 0x412
+#define PCI_DEVICE_ID_ADAPTEC2_RAZOR1E 0x41E
+#define PCI_DEVICE_ID_ADAPTEC2_RAZOR30 0x430
+#define PCI_DEVICE_ID_ADAPTEC2_RAZOR32 0x432
+#define PCI_DEVICE_ID_ADAPTEC2_RAZOR3E 0x43E
+#define PCI_DEVICE_ID_ADAPTEC2_RAZOR3F 0x43F
+
+struct asd_ha_addrspace {
+ void __iomem *addr;
+ unsigned long start; /* pci resource start */
+ unsigned long len; /* pci resource len */
+ unsigned long flags; /* pci resource flags */
+
+ /* addresses internal to the host adapter */
+ u32 swa_base; /* mmspace 1 (MBAR1) uses this only */
+ u32 swb_base;
+ u32 swc_base;
+};
+
+struct bios_struct {
+ intpresent;
+ u8 maj;
+ u8 min;
+ u32bld;
+};
+
+struct unit_element_struct {
+ u16num;
+ u16size;
+ void *area;
+};
+
+struct flash_struct {
+ u32bar;
+ intpresent;
+ intwide;
+ u8 manuf;
+ u8 dev_id;
+ u8 sec_prot;
+
+ u32dir_offs;
+};
+
+struct asd_phy_desc {
+ /* From CTRL-A settings, then set to what is appropriate */
+ u8 sas_addr[SAS_ADDR_SIZE];
+ u8 max_sas_lrate;
+ u8 min_sas_lrate;
+ u8 max_sata_lrate;
+ u8 min_sata_lrate;
+ u8 flags;
+#define ASD_CRC_DIS 1
+#define ASD_SATA_SPINUP_HOLD 2
+
+ u8 phy_control_0; /* mode 5 reg 0x160 */
+ u8 phy_control_1; /* mode 5 reg 0x161 */
+ u8 phy_control_2; /* mode 5 reg 0x162 */
+ u8 phy_control_3; /* mode 5 reg 0x163 */
+};
+
+struct hw_profile {
+ struct bios_struct bios;
+ struct unit_element_struct ue;
+ struct flash_struct flash;
+
+ u8 sas_addr[SAS_ADDR_SIZE];
+ char pcba_sn[ASD_PCBA_SN_SIZE+1];
+
+ u8 enabled_phys; /* mask of enabled phys */
+ struct asd_phy_desc phy_desc[ASD_MAX_PHYS];
+ u32max_scbs; /* absolute sequencer scb queue size */
+ u32max_ddbs;
+ spinlock_t ddb_lock;
+ void *ddb_bitmap;
+
+ intnum_phys; /* ENABLEABLE */
+ intmax_phys; /* REPORTED + ENABLEABLE */
+
+ unsigned addr_range; /* max # of addrs; max # of possible ports */
+ unsigned port_name_base;
+ unsigned dev_name_base;
+ unsigned sata_name_base;
+};
+
+struct asd_dma_tok {
+ void *vaddr;
+ dma_addr_t dma_handle;
+ size_t size;
+};
+
+struct asd_ascb {
+ struct list_head list;
+ struct asd_ha_struct *ha;
+
+ struct scb *scb; /* equals dma_scb->vaddr */
+ struct asd_dma_tok dma_scb;
+ struct asd_dma_tok *sg_arr;
+
+ void (*tasklet_complete)(struct asd_ascb *, struct done_list_struct *);
+ u8 uldd_timer:1;
+
+ /* internally generated command */
+ struct timer_list timer;
+ struct completion completion;
+ u8tag_valid:1;
+ __be16tag;/* error recovery
[PATCH 2.6.13 10/20] aic94xx: aic94xx_reg.c Register access
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_reg.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_reg.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_reg.c1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/aic94xx/aic94xx_reg.c 2005-09-09
11:21:23.0 -0400
@@ -0,0 +1,333 @@
+/*
+ * Aic94xx SAS/SATA driver register access.
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This file is part of the aic94xx driver.
+ *
+ * The aic94xx driver is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ * The aic94xx driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with the aic94xx driver; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/aic94xx/aic94xx_reg.c#13 $
+ */
+
+#include
+#include "aic94xx_reg.h"
+#include "aic94xx.h"
+
+/* Writing to device address space.
+ * Offset comes before value to remind that the operation of
+ * this function is *offs = val.
+ */
+static inline void asd_write_byte(struct asd_ha_struct *asd_ha,
+ unsigned long offs, u8 val)
+{
+ if (unlikely(asd_ha->iospace))
+ outb(val,
+(unsigned long)asd_ha->io_handle[0].addr + (offs & 0xFF));
+ else
+ writeb(val, asd_ha->io_handle[0].addr + offs);
+ wmb();
+}
+
+static inline void asd_write_word(struct asd_ha_struct *asd_ha,
+ unsigned long offs, u16 val)
+{
+ if (unlikely(asd_ha->iospace))
+ outw(val,
+(unsigned long)asd_ha->io_handle[0].addr + (offs & 0xFF));
+ else
+ writew(val, asd_ha->io_handle[0].addr + offs);
+ wmb();
+}
+
+static inline void asd_write_dword(struct asd_ha_struct *asd_ha,
+ unsigned long offs, u32 val)
+{
+ if (unlikely(asd_ha->iospace))
+ outl(val,
+(unsigned long)asd_ha->io_handle[0].addr + (offs & 0xFF));
+ else
+ writel(val, asd_ha->io_handle[0].addr + offs);
+ wmb();
+}
+
+/* Reading from device address space.
+ */
+static inline u8 asd_read_byte(struct asd_ha_struct *asd_ha,
+ unsigned long offs)
+{
+ u8 val;
+ if (unlikely(asd_ha->iospace))
+ val = inb((unsigned long) asd_ha->io_handle[0].addr
+ + (offs & 0xFF));
+ else
+ val = readb(asd_ha->io_handle[0].addr + offs);
+ rmb();
+ return val;
+}
+
+static inline u16 asd_read_word(struct asd_ha_struct *asd_ha,
+ unsigned long offs)
+{
+ u16 val;
+ if (unlikely(asd_ha->iospace))
+ val = inw((unsigned long)asd_ha->io_handle[0].addr
+ + (offs & 0xFF));
+ else
+ val = readw(asd_ha->io_handle[0].addr + offs);
+ rmb();
+ return val;
+}
+
+static inline u32 asd_read_dword(struct asd_ha_struct *asd_ha,
+unsigned long offs)
+{
+ u32 val;
+ if (unlikely(asd_ha->iospace))
+ val = inl((unsigned long) asd_ha->io_handle[0].addr
+ + (offs & 0xFF));
+ else
+ val = readl(asd_ha->io_handle[0].addr + offs);
+ rmb();
+ return val;
+}
+
+static inline u32 asd_mem_offs_swa(void)
+{
+ return 0;
+}
+
+static inline u32 asd_mem_offs_swc(void)
+{
+ return asd_mem_offs_swa() + MBAR0_SWA_SIZE;
+}
+
+static inline u32 asd_mem_offs_swb(void)
+{
+ return asd_mem_offs_swc() + MBAR0_SWC_SIZE + 0x20;
+}
+
+/* We know that the register wanted is in the range
+ * of the sliding window.
+ */
+#define ASD_READ_SW(ww, type, ord) \
+static inline type asd_read_##ww##_##ord (struct asd_ha_struct *asd_ha,\
+ u32 reg) \
+{ \
+ struct asd_ha_addrspace *io_handle = _ha->io_handle[0];\
+ u32 map_offs=(reg - io_handle-> ww##_base )+asd_mem_offs_##ww ();\
+ return asd_read_##ord (asd_ha, (unsigned long) map_offs); \
+}
+
[PATCH 2.6.13 13/20] aic94xx: aic94xx_sas.h SAS specific for this hw/seq implementation header file
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_sas.h
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_sas.h
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_sas.h1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/aic94xx/aic94xx_sas.h 2005-09-09
11:21:23.0 -0400
@@ -0,0 +1,788 @@
+/*
+ * Aic94xx SAS/SATA driver SAS definitions and hardware interface header file.
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This file is part of the aic94xx driver.
+ *
+ * The aic94xx driver is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ * The aic94xx driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with the aic94xx driver; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/aic94xx/aic94xx_sas.h#61 $
+ */
+
+#ifndef _AIC94XX_SAS_H_
+#define _AIC94XX_SAS_H_
+
+#include
+#include
+
+/* -- DDBs -- */
+/* DDBs are device descriptor blocks which describe a device in the
+ * domain that this sequencer can maintain low-level connections for
+ * us. They are be 64 bytes.
+ */
+
+struct asd_ddb_ssp_smp_target_port {
+ u8 conn_type; /* byte 0 */
+#define DDB_TP_CONN_TYPE 0x81/* Initiator port and addr frame type 0x01 */
+
+ u8 conn_rate;
+ __be16 init_conn_tag;
+ u8 dest_sas_addr[8]; /* bytes 4-11 */
+
+ __le16 send_queue_head;
+ u8 sq_suspended;
+ u8 ddb_type; /* DDB_TYPE_TARGET */
+#define DDB_TYPE_UNUSED0xFF
+#define DDB_TYPE_TARGET0xFE
+#define DDB_TYPE_INITIATOR 0xFD
+#define DDB_TYPE_PM_PORT 0xFC
+
+ __le16 _r_a;
+ __be16 awt_def;
+
+ u8 compat_features; /* byte 20 */
+ u8 pathway_blocked_count;
+ __be16 arb_wait_time;
+ __be32 more_compat_features; /* byte 24 */
+
+ u8 conn_mask;
+ u8 flags; /* concurrent conn:2,2 and open:0(1) */
+#define CONCURRENT_CONN_SUPP 0x04
+#define OPEN_REQUIRED0x01
+
+ u16_r_b;
+ __le16 exec_queue_tail;
+ __le16 send_queue_tail;
+ __le16 sister_ddb;
+
+ __le16 _r_c;
+
+ u8 max_concurrent_conn;
+ u8 num_concurrent_conn;
+ u8 num_contexts;
+
+ u8 _r_d;
+
+ __le16 active_task_count;
+
+ u8 _r_e[9];
+
+ u8 itnl_reason; /* I_T nexus loss reason */
+
+ __le16 _r_f;
+
+ __le16 itnl_timeout;
+#define ITNL_TIMEOUT_CONST 0x7D0 /* 2 seconds */
+
+ __le32 itnl_timestamp;
+} __attribute__ ((packed));
+
+struct asd_ddb_stp_sata_target_port {
+ u8 conn_type; /* byte 0 */
+ u8 conn_rate;
+ __be16 init_conn_tag;
+ u8 dest_sas_addr[8]; /* bytes 4-11 */
+
+ __le16 send_queue_head;
+ u8 sq_suspended;
+ u8 ddb_type; /* DDB_TYPE_TARGET */
+
+ __le16 _r_a;
+
+ __be16 awt_def;
+ u8 compat_features; /* byte 20 */
+ u8 pathway_blocked_count;
+ __be16 arb_wait_time;
+ __be32 more_compat_features; /* byte 24 */
+
+ u8 conn_mask;
+ u8 flags; /* concurrent conn:2,2 and open:0(1) */
+#define SATA_MULTIPORT 0x80
+#define SUPPORTS_AFFIL 0x40
+#define STP_AFFIL_POL 0x20
+
+ u8 _r_b;
+ u8 flags2;/* STP close policy:0 */
+#define STP_CL_POL_NO_TX0x00
+#define STP_CL_POL_BTW_CMDS 0x01
+
+ __le16 exec_queue_tail;
+ __le16 send_queue_tail;
+ __le16 sister_ddb;
+ __le16 ata_cmd_scbptr;
+ __le32 sata_tag_alloc_mask;
+ __le16 active_task_count;
+ __le16 _r_c;
+ __le32 sata_sactive;
+ u8 num_sata_tags;
+ u8 sata_status;
+ u8 sata_ending_status;
+ u8 itnl_reason; /* I_T nexus loss reason */
+ __le16 ncq_data_scb_ptr;
+ __le16 itnl_timeout;
+ __le32 itnl_timestamp;
+} __attribute__ ((packed));
+
+/* This struct asd_ddb_init_port, describes the device descriptor block
+ * of an initiator port (when the sequencer is operating in target mode).
+ * Bytes [0,11] and [20,27] are from the OPEN address frame.
+ * The sequencer allocates an initiator port DDB entry.
+ */
+struct asd_ddb_init_port {
+ u8
[PATCH 2.6.13 7/14] sas-class: sas_dump.h Dumping utility header file
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_dump.h
linux-2.6.13/drivers/scsi/sas-class/sas_dump.h
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_dump.h 1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/sas-class/sas_dump.h 2005-09-09
11:14:51.0 -0400
@@ -0,0 +1,43 @@
+/*
+ * Serial Attached SCSI (SAS) Dump/Debugging routines header file
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/sas-class/sas_dump.h#2 $
+ */
+
+#include "sas_internal.h"
+
+#ifdef SAS_DEBUG
+
+void sas_dprint_porte(int phyid, enum port_event pe);
+void sas_dprint_phye(int phyid, enum phy_event pe);
+void sas_dprint_hae(struct sas_ha_struct *sas_ha, enum ha_event he);
+void sas_dump_port(struct sas_port *port);
+
+#else /* SAS_DEBUG */
+
+static inline void sas_dprint_porte(int phyid, enum port_event pe) { }
+static inline void sas_dprint_phye(int phyid, enum phy_event pe) { }
+static inline void sas_dprint_hae(struct sas_ha_struct *sas_ha,
+ enum ha_event he) { }
+static inline void sas_dump_port(struct sas_port *port) { }
+
+#endif /* SAS_DEBUG */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13 5/20] aic94xx: aic94xx_dump.c Debug/dumping utility
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_dump.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_dump.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_dump.c 1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/aic94xx/aic94xx_dump.c2005-09-09
11:21:23.0 -0400
@@ -0,0 +1,959 @@
+/*
+ * Aic94xx SAS/SATA driver dump interface.
+ *
+ * Copyright (C) 2004 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2004 David Chaw <[EMAIL PROTECTED]>
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This file is part of the aic94xx driver.
+ *
+ * The aic94xx driver is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ * The aic94xx driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with the aic94xx driver; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * 2005/07/14/LT Complete overhaul of this file. Update pages, register
+ * locations, names, etc. Make use of macros. Print more information.
+ * Print all cseq and lseq mip and mdp.
+ *
+ * $Id: //depot/aic94xx/aic94xx_dump.c#28 $
+ */
+
+#include "linux/pci.h"
+#include "aic94xx.h"
+#include "aic94xx_reg.h"
+#include "aic94xx_reg_def.h"
+#include "aic94xx_sas.h"
+
+#include "aic94xx_dump.h"
+
+#ifdef ASD_DEBUG
+
+#define MD(x) (1 << (x))
+#define MODE_COMMON (1 << 31)
+#define MODE_0_7(0xFF)
+
+static const struct lseq_cio_regs {
+ char*name;
+ u32 offs;
+ u8 width;
+ u32 mode;
+} LSEQmCIOREGS[] = {
+ {"LmMnSCBPTR",0x20, 16, MD(0)|MD(1)|MD(2)|MD(3)|MD(4) },
+ {"LmMnDDBPTR",0x22, 16, MD(0)|MD(1)|MD(2)|MD(3)|MD(4) },
+ {"LmREQMBX", 0x30, 32, MODE_COMMON },
+ {"LmRSPMBX", 0x34, 32, MODE_COMMON },
+ {"LmMnINT", 0x38, 32, MODE_0_7 },
+ {"LmMnINTEN", 0x3C, 32, MODE_0_7 },
+ {"LmXMTPRIMD",0x40, 32, MODE_COMMON },
+ {"LmXMTPRIMCS", 0x44, 8, MODE_COMMON },
+ {"LmCONSTAT", 0x45, 8, MODE_COMMON },
+ {"LmMnDMAERRS", 0x46, 8, MD(0)|MD(1) },
+ {"LmMnSGDMAERRS", 0x47, 8, MD(0)|MD(1) },
+ {"LmMnEXPHDRP", 0x48, 8, MD(0) },
+ {"LmMnSASAALIGN", 0x48, 8, MD(1) },
+ {"LmMnMSKHDRP", 0x49, 8, MD(0) },
+ {"LmMnSTPALIGN", 0x49, 8, MD(1) },
+ {"LmMnRCVHDRP", 0x4A, 8, MD(0) },
+ {"LmMnXMTHDRP", 0x4A, 8, MD(1) },
+ {"LmALIGNMODE", 0x4B, 8, MD(1) },
+ {"LmMnEXPRCVCNT", 0x4C, 32, MD(0) },
+ {"LmMnXMTCNT",0x4C, 32, MD(1) },
+ {"LmMnCURRTAG", 0x54, 16, MD(0) },
+ {"LmMnPREVTAG", 0x56, 16, MD(0) },
+ {"LmMnACKOFS",0x58, 8, MD(1) },
+ {"LmMnXFRLVL",0x59, 8, MD(0)|MD(1) },
+ {"LmMnSGDMACTL", 0x5A, 8, MD(0)|MD(1) },
+ {"LmMnSGDMASTAT", 0x5B, 8, MD(0)|MD(1) },
+ {"LmMnDDMACTL", 0x5C, 8, MD(0)|MD(1) },
+ {"LmMnDDMASTAT", 0x5D, 8, MD(0)|MD(1) },
+ {"LmMnDDMAMODE", 0x5E, 16, MD(0)|MD(1) },
+ {"LmMnPIPECTL", 0x61, 8, MD(0)|MD(1) },
+ {"LmMnACTSCB",0x62, 16, MD(0)|MD(1) },
+ {"LmMnSGBHADR", 0x64, 8, MD(0)|MD(1) },
+ {"LmMnSGBADR",0x65, 8, MD(0)|MD(1) },
+ {"LmMnSGDCNT",0x66, 8, MD(0)|MD(1) },
+ {"LmMnSGDMADR", 0x68, 32, MD(0)|MD(1) },
+ {"LmMnSGDMADR", 0x6C, 32, MD(0)|MD(1) },
+ {"LmMnXFRCNT",0x70, 32, MD(0)|MD(1) },
+ {"LmMnXMTCRC",0x74, 32, MD(1) },
+ {"LmCURRTAG", 0x74, 16, MD(0) },
+ {"LmPREVTAG", 0x76, 16, MD(0) },
+ {"LmMnDPSEL", 0x7B, 8, MD(0)|MD(1) },
+ {"LmDPTHSTAT",0x7C, 8, MODE_COMMON },
+ {"LmMnHOLDLVL", 0x7D, 8, MD(0) },
+ {"LmMnSATAFS",0x7E, 8, MD(1) },
+ {"LmMnCMPLTSTAT", 0x7F, 8, MD(0)|MD(1) },
+ {"LmPRMSTAT0",0x80, 32, MODE_COMMON },
+ {"LmPRMSTAT1",0x84, 32, MODE_COMMO
[PATCH 2.6.13 17/20] aic94xx: aic94xx_seq.h Sequencer interface header file
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]> diff -X linux-2.6.13/Documentation/dontdiff -Naur linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_seq.h linux-2.6.13/drivers/scsi/aic94xx/aic94xx_seq.h --- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_seq.h1969-12-31 19:00:00.0 -0500 +++ linux-2.6.13/drivers/scsi/aic94xx/aic94xx_seq.h 2005-09-09 11:21:23.0 -0400 @@ -0,0 +1,42 @@ +/* + * Aic94xx SAS/SATA driver sequencer interface header file. + * + * Copyright (C) 2005 Adaptec, Inc. All rights reserved. + * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]> + * + * This file is licensed under GPLv2. + * + * This file is part of the aic94xx driver. + * + * The aic94xx driver is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; version 2 of the + * License. + * + * The aic94xx driver is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with the aic94xx driver; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + * + * $Id: //depot/aic94xx/aic94xx_seq.h#6 $ + */ + +#ifndef _AIC94XX_SEQ_H_ +#define _AIC94XX_SEQ_H_ + +int asd_pause_cseq(struct asd_ha_struct *asd_ha); +int asd_unpause_cseq(struct asd_ha_struct *asd_ha); +int asd_pause_lseq(struct asd_ha_struct *asd_ha, u8 lseq_mask); +int asd_unpause_lseq(struct asd_ha_struct *asd_ha, u8 lseq_mask); +int asd_init_seqs(struct asd_ha_struct *asd_ha); +int asd_start_seqs(struct asd_ha_struct *asd_ha); + +void asd_update_port_links(struct sas_phy *phy); + +#endif - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13 6/14] sas-class: sas_dump.c Debug/dumping utility
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_dump.c
linux-2.6.13/drivers/scsi/sas-class/sas_dump.c
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_dump.c 1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/sas-class/sas_dump.c 2005-09-09
11:14:29.0 -0400
@@ -0,0 +1,77 @@
+/*
+ * Serial Attached SCSI (SAS) Dump/Debugging routines
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/sas-class/sas_dump.c#4 $
+ */
+
+#include "sas_dump.h"
+
+#ifdef SAS_DEBUG
+
+static const char *sas_hae_str[] = {
+ [0] = "HAE_RESET",
+};
+
+static const char *sas_porte_str[] = {
+ [0] = "PORTE_BYTES_DMAED",
+ [1] = "PORTE_BROADCAST_RCVD",
+ [2] = "PORTE_LINK_RESET_ERR",
+ [3] = "PORTE_TIMER_EVENT",
+ [4] = "PORTE_HARD_RESET",
+};
+
+static const char *sas_phye_str[] = {
+ [0] = "PHYE_LOSS_OF_SIGNAL",
+ [1] = "PHYE_OOB_DONE",
+ [2] = "PHYE_OOB_ERROR",
+ [3] = "PHYE_SPINUP_HOLD",
+};
+
+void sas_dprint_porte(int phyid, enum port_event pe)
+{
+ SAS_DPRINTK("phy%d: port event: %s\n", phyid, sas_porte_str[pe]);
+}
+void sas_dprint_phye(int phyid, enum phy_event pe)
+{
+ SAS_DPRINTK("phy%d: phy event: %s\n", phyid, sas_phye_str[pe]);
+}
+
+void sas_dprint_hae(struct sas_ha_struct *sas_ha, enum ha_event he)
+{
+ SAS_DPRINTK("ha %s: %s event\n", pci_name(sas_ha->pcidev),
+ sas_hae_str[he]);
+}
+
+void sas_dump_port(struct sas_port *port)
+{
+ SAS_DPRINTK("port%d: class:0x%x\n", port->id, port->class);
+ SAS_DPRINTK("port%d: sas_addr:%llx\n", port->id,
+ SAS_ADDR(port->sas_addr));
+ SAS_DPRINTK("port%d: attached_sas_addr:%llx\n", port->id,
+ SAS_ADDR(port->attached_sas_addr));
+ SAS_DPRINTK("port%d: iproto:0x%x\n", port->id, port->iproto);
+ SAS_DPRINTK("port%d: tproto:0x%x\n", port->id, port->tproto);
+ SAS_DPRINTK("port%d: oob_mode:0x%x\n", port->id, port->oob_mode);
+ SAS_DPRINTK("port%d: num_phys:%d\n", port->id, port->num_phys);
+}
+
+#endif /* SAS_DEBUG */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13 13/14] sas-class: sas_port.c SAS Port (events, attrs, initialization)
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_port.c
linux-2.6.13/drivers/scsi/sas-class/sas_port.c
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_port.c 1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/sas-class/sas_port.c 2005-09-09
11:50:35.0 -0400
@@ -0,0 +1,430 @@
+/*
+ * Serial Attached SCSI (SAS) Port class
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/sas-class/sas_port.c#41 $
+ */
+
+#include "sas_internal.h"
+#include
+
+/* called only when num_phys increments, afterwards */
+static void sas_create_port_sysfs_links(struct sas_phy *phy)
+{
+ struct sas_port *port = phy->port;
+
+ if (port->num_phys == 1) {
+ kobject_register(>port_kobj);
+ kset_register(>phy_kset);
+ kset_register(>dev_kset);
+ }
+ /* add port->phy link */
+ sysfs_create_link(>phy_kset.kobj, >phy_kobj,
+ kobject_name(>phy_kobj));
+ /* add phy->port link */
+ sysfs_create_link(>phy_kobj, >port_kobj, "port");
+}
+
+/* called only when num_phys decrements, just before it does */
+static void sas_remove_port_sysfs_links(struct sas_phy *phy)
+{
+ struct sas_port *port = phy->port;
+
+ /* remove phy->port link */
+ sysfs_remove_link(>phy_kobj, "port");
+ /* remove port to phy link */
+ sysfs_remove_link(>phy_kset.kobj, kobject_name(>phy_kobj));
+
+ if (port->num_phys == 1) {
+ kset_unregister(>dev_kset);
+ kset_unregister(>phy_kset);
+ kobject_unregister(>port_kobj);
+ }
+}
+
+/**
+ * sas_form_port -- add this phy to a port
+ * @phy: the phy of interest
+ *
+ * This function adds this phy to an existing port, thus creating a wide
+ * port, or it creates a port and adds the phy to the port.
+ */
+static void sas_form_port(struct sas_phy *phy)
+{
+ int i;
+ struct sas_ha_struct *sas_ha = phy->ha;
+ struct sas_port *port = phy->port;
+
+ if (port) {
+ if (memcmp(port->attached_sas_addr, phy->attached_sas_addr,
+ SAS_ADDR_SIZE) == 0)
+ sas_deform_port(phy);
+ else {
+ SAS_DPRINTK("%s: phy%d belongs to port%d
already(%d)!\n",
+ __FUNCTION__, phy->id, phy->port->id,
+ phy->port->num_phys);
+ return;
+ }
+ }
+
+ /* find a port */
+ spin_lock(_ha->phy_port_lock);
+ for (i = 0; i < sas_ha->num_phys; i++) {
+ port = sas_ha->sas_port[i];
+ spin_lock(>phy_list_lock);
+ if (*(u64 *) port->sas_addr &&
+ memcmp(port->attached_sas_addr,
+ phy->attached_sas_addr, SAS_ADDR_SIZE) == 0 &&
+ port->num_phys > 0) {
+ /* wide port */
+ SAS_DPRINTK("phy%d matched wide port%d\n", phy->id,
+ port->id);
+ break;
+ } else if (*(u64 *) port->sas_addr == 0 && port->num_phys==0) {
+ memcpy(port->sas_addr, phy->sas_addr, SAS_ADDR_SIZE);
+ break;
+ }
+ spin_unlock(>phy_list_lock);
+ }
+
+ if (i >= sas_ha->num_phys) {
+ printk(KERN_NOTICE "%s: couldn't find a free port, bug?\n",
+ __FUNCTION__);
+ spin_unlock(_ha->phy_port_lock);
+ return;
+ }
+
+ /* add the phy to the port */
+ list_add_tail(>port_phy_el, >phy_list);
+ phy->port = port;
+ port->num_phys++;
+ port->phy_mask |= (1U << phy->id
[PATCH 2.6.13 7/20] aic94xx: aic94xx_hwi.c Hardware interface
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_hwi.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_hwi.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_hwi.c1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/aic94xx/aic94xx_hwi.c 2005-09-09
11:21:23.0 -0400
@@ -0,0 +1,1262 @@
+/*
+ * Aic94xx SAS/SATA driver hardware interface.
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This file is part of the aic94xx driver.
+ *
+ * The aic94xx driver is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ * The aic94xx driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with the aic94xx driver; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/aic94xx/aic94xx_hwi.c#99 $
+ */
+
+#include
+#include
+
+#include
+
+#include "aic94xx.h"
+#include "aic94xx_reg.h"
+#include "aic94xx_hwi.h"
+#include "aic94xx_seq.h"
+#include "aic94xx_dump.h"
+
+u32 MBAR0_SWB_SIZE;
+
+/* -- Initialization -- */
+
+static void asd_get_user_sas_addr(struct asd_ha_struct *asd_ha)
+{
+ extern char sas_addr_str[];
+ /* If the user has specified a WWN it overrides other settings
+*/
+ if (sas_addr_str[0] != '\0')
+ asd_destringify_sas_addr(asd_ha->hw_prof.sas_addr,
+sas_addr_str);
+ else if (asd_ha->hw_prof.sas_addr[0] != 0)
+ asd_stringify_sas_addr(sas_addr_str, asd_ha->hw_prof.sas_addr);
+}
+
+static void asd_propagate_sas_addr(struct asd_ha_struct *asd_ha)
+{
+ int i;
+
+ for (i = 0; i < ASD_MAX_PHYS; i++) {
+ if (asd_ha->hw_prof.phy_desc[i].sas_addr[0] == 0)
+ continue;
+ /* Set a phy's address only if it has none.
+*/
+ ASD_DPRINTK("setting phy%d addr to %llx\n", i,
+ SAS_ADDR(asd_ha->hw_prof.sas_addr));
+ memcpy(asd_ha->hw_prof.phy_desc[i].sas_addr,
+ asd_ha->hw_prof.sas_addr, SAS_ADDR_SIZE);
+ }
+}
+
+/* -- PHY initialization -- */
+
+static void asd_init_phy_identify(struct asd_phy *phy)
+{
+ phy->identify_frame = phy->id_frm_tok->vaddr;
+
+ memset(phy->identify_frame, 0, sizeof(*phy->identify_frame));
+
+ phy->identify_frame->dev_type = SAS_END_DEV;
+ if (phy->sas_phy.role & PHY_ROLE_INITIATOR)
+ phy->identify_frame->initiator_bits = phy->sas_phy.iproto;
+ if (phy->sas_phy.role & PHY_ROLE_TARGET)
+ phy->identify_frame->target_bits = phy->sas_phy.tproto;
+ memcpy(phy->identify_frame->sas_addr, phy->phy_desc->sas_addr,
+ SAS_ADDR_SIZE);
+ phy->identify_frame->phy_id = phy->sas_phy.id;
+}
+
+static int asd_init_phy(struct asd_phy *phy)
+{
+ struct asd_ha_struct *asd_ha = phy->sas_phy.ha->lldd_ha;
+ struct sas_phy *sas_phy = >sas_phy;
+
+ sas_phy->enabled = 1;
+ sas_phy->class = SAS;
+ sas_phy->iproto = SAS_PROTO_ALL;
+ sas_phy->tproto = 0;
+ sas_phy->type = PHY_TYPE_PHYSICAL;
+ sas_phy->role = PHY_ROLE_INITIATOR;
+ sas_phy->oob_mode = OOB_NOT_CONNECTED;
+ sas_phy->linkrate = PHY_LINKRATE_NONE;
+
+ phy->id_frm_tok = asd_alloc_coherent(asd_ha,
+sizeof(*phy->identify_frame),
+GFP_KERNEL);
+ if (!phy->id_frm_tok) {
+ asd_printk("no mem for IDENTIFY for phy%d\n", sas_phy->id);
+ return -ENOMEM;
+ } else
+ asd_init_phy_identify(phy);
+
+ memset(phy->frame_rcvd, 0, sizeof(phy->frame_rcvd));
+
+ return 0;
+}
+
+static int asd_init_phys(struct asd_ha_struct *asd_ha)
+{
+ u8 i;
+ u8 phy_mask = asd_ha->hw_prof.enabled_phys;
+
+ for (i = 0; i < ASD_MAX_PHYS; i++) {
+ struct asd_phy *phy = _ha->phys[i];
+
+ phy->phy_desc = _ha->hw_prof.phy_desc[i];
+
+ phy->sas_phy.enabled = 0;
+ phy->sas_
[PATCH 2.6.13 2/14] sas-class: README
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/README
linux-2.6.13/drivers/scsi/sas-class/README
--- linux-2.6.13-orig/drivers/scsi/sas-class/README 1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/sas-class/README 2005-09-09 12:22:32.0
-0400
@@ -0,0 +1,440 @@
+SAS Layer
+-
+
+The SAS Layer is a management infrastructure which manages
+SAS LLDDs. It sits between SCSI Core and SAS LLDDs. The
+layout is as follows: while SCSI Core is concerned with
+SAM/SPC issues, and a SAS LLDD+sequencer is concerned with
+phy/OOB/link management, the SAS layer is concerned with:
+
+ * SAS Phy/Port/HA event management (LLDD generates,
+SAS Layer processes),
+ * SAS Port management (creation/destruction),
+ * SAS Domain discovery and revalidation,
+ * SAS Domain device management,
+ * SCSI Host registration/unregistration,
+ * Device registration with SCSI Core (SAS) or libata
+(SATA), and
+ * Expander management and exporting expander control
+to user space.
+
+A SAS LLDD is a PCI device driver. It is concerned with
+phy/OOB management, and vendor specific tasks and generates
+events to the SAS layer.
+
+The SAS Layer does most SAS tasks as outlined in the SAS 1.1
+spec.
+
+The sas_ha_struct describes the SAS LLDD to the SAS layer.
+Most of it is used by the SAS Layer but a few fields need to
+be initialized by the LLDDs.
+
+After initializing your hardware, from the probe() function
+you call sas_register_ha(). It will register your LLDD with
+the SCSI subsystem, creating a SCSI host and it will
+register your SAS driver with the sysfs SAS tree it creates.
+It will then return. Then you enable your phys to actually
+start OOB (at which point your driver will start calling the
+notify_* event callbacks).
+
+Structure descriptions:
+
+struct sas_phy
+Normally this is statically embedded to your driver's
+phy structure:
+ struct my_phy {
+ blah;
+ struct sas_phy sas_phy;
+ bleh;
+ };
+And then all the phys are an array of my_phy in your HA
+struct (shown below).
+
+Then as you go along and initialize your phys you also
+initialize the sas_phy struct, along with your own
+phy structure.
+
+In general, the phys are managed by the LLDD and the ports
+are managed by the SAS layer. So the phys are initialized
+and updated by the LLDD and the ports are initialized and
+updated by the SAS layer.
+
+There is a scheme where the LLDD can RW certain fields,
+and the SAS layer can only read such ones, and vice versa.
+The idea is to avoid unnecessary locking.
+
+enabled -- must be set (0/1)
+id -- must be set [0,MAX_PHYS)
+class, proto, type, role, oob_mode, linkrate -- must be set
+oob_mode -- you set this when OOB has finished and then notify
+the SAS Layer.
+
+sas_addr -- this normally points to an array holding the sas
+address of the phy, possibly somewhere in your my_phy
+struct.
+
+attached_sas_addr -- set this when you (LLDD) receive an
+IDENTIFY frame or a FIS frame, _before_ notifying the SAS
+layer. The idea is that sometimes the LLDD may want to fake
+or provide a different SAS address on that phy/port and this
+allows it to do this. At best you should copy the sas
+address from the IDENTIFY frame or maybe generate a SAS
+address for SATA directly attached devices. The Discover
+process may later change this.
+
+frame_rcvd -- this is where you copy the IDENTIFY/FIS frame
+when you get it; you lock, copy, set frame_rcvd_size and
+unlock the lock, and then call the event. It is a pointer
+since there's no way to know your hw frame size _exactly_,
+so you define the actual array in your phy struct and let
+this pointer point to it. You copy the frame from your
+DMAable memory to that area holding the lock.
+
+sas_prim -- this is where primitives go when they're
+received. See sas.h. Grab the lock, set the primitive,
+release the lock, notify.
+
+port -- this points to the sas_port if the phy belongs
+to a port -- the LLDD only reads this. It points to the
+sas_port this phy is part of. Set by the SAS Layer.
+
+ha -- may be set; the SAS layer sets it anyway.
+
+lldd_phy -- you should set this to point to your phy so you
+can find your way around faster when the SAS layer calls one
+of your callbacks and passes you a phy. If the sas_phy is
+embedded you can also use container_of -- whatever you
+prefer.
+
+
+struct sas_port
+The LLDD doesn't set any fields of this struct -- it only
+reads them. They should be self explanatory.
+
+phy_mask is 32 bit, this should be enough for now, as I
+haven't heard of a HA having more than 8 phys.
+
+lldd_port -- I haven't found use for that -- maybe other
+LLDD who wish to have internal port representation can make
+use of this.
+
+
+struct sas_ha_struct
+It no
[PATCH 2.6.13 14/14] sas-class: SCSI Host glue
Note on Direct Mode (normal) and Task Collector Mode.
Direct Mode
---
In Direct Mode (default, normal) the SAS Layer calls Execute
Command SCSI RPC of the SAS LLDD which gives the command
to the SDS _immediately_.
This is the default normal operation for all SAS LLDDs.
Task Collector Mode
---
Some hardware has the ability to DMA a bunch of tasks into
the host adapter memory in one go.
Also some hardware has the ability to have pending
quite a large number of commands. For the aic94xx SAS
LLDD, this is currently 512, but can be extended to as
much memory the host has.
Task Collector Mode is advertized by the LLDD that it wants
the SAS Layer to run in that mode for that LLDD. The SAS Layer
then does a natural coalescing of requests and would send
a bunch of those, linked, in one invocation of the
Execute Command SCSI RPC.
Task collector mode accomodates this, so that the host
adapter firmware gets less interrupts.
DBMS machines may want to run in this mode.
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_scsi_host.c
linux-2.6.13/drivers/scsi/sas-class/sas_scsi_host.c
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_scsi_host.c1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/sas-class/sas_scsi_host.c 2005-09-09
11:14:29.0 -0400
@@ -0,0 +1,991 @@
+/*
+ * Serial Attached SCSI (SAS) class SCSI Host glue.
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+ * USA
+ *
+ * $Id: //depot/sas-class/sas_scsi_host.c#55 $
+ */
+
+#include "sas_internal.h"
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+/* The SAM LUN structure should be _completely_ opaque to SCSI Core.
+ * This is why this macro here, and not using the broken
+ * scsilun_to_int(). Ideally, a SCSI LUN should be communicated in
+ * its entirety, and not as an integer. For some unknown to myself
+ * reason, SCSI Core thinks that SCSI LUNs can be interpreted as
+ * integers.
+ */
+#define SCSI_LUN(_sam_lun) ((unsigned int)be32_to_cpu(*(__be32 *)_sam_lun))
+
+/* -- SCSI Core device registration -- */
+
+int sas_register_with_scsi(struct LU *lu)
+{
+ struct scsi_device *scsi_dev;
+
+ lu->map.channel = lu->parent->port->id;
+ lu->map.id = sas_reserve_free_id(lu->parent->port);
+ if (lu->map.id == -ENOMEM)
+ return -ENOMEM;
+
+ scsi_dev = scsi_add_device(lu->parent->port->ha->core.shost,
+ lu->map.channel, lu->map.id,
+ SCSI_LUN(lu->LUN));
+ if (IS_ERR(scsi_dev))
+ return PTR_ERR(scsi_dev);
+
+ return 0;
+}
+
+void sas_unregister_with_scsi(struct LU *lu)
+{
+ if (lu->uldd_dev) {
+ struct scsi_device *scsi_dev = lu->uldd_dev;
+ scsi_remove_device(scsi_dev);
+ }
+}
+
+/* -- SCSI Host glue -- */
+
+#define TO_SAS_TASK(_scsi_cmd) ((void *)(_scsi_cmd)->host_scribble)
+#define ASSIGN_SAS_TASK(_sc, _t) do { (_sc)->host_scribble = (void *) _t; }
while (0)
+
+static void sas_scsi_task_done(struct sas_task *task)
+{
+ struct task_status_struct *ts = >task_status;
+ struct scsi_cmnd *sc = task->uldd_task;
+ unsigned ts_flags = task->task_state_flags;
+ int hs = 0, stat = 0;
+
+ if (unlikely(!sc)) {
+ SAS_DPRINTK("task_done called with non existing SCSI cmnd!\n");
+ list_del_init(>list);
+ sas_free_task(task);
+ return;
+ }
+
+ if (ts->resp == SAS_TASK_UNDELIVERED) {
+ /* transport error */
+ hs = DID_NO_CONNECT;
+ } else { /* ts->resp == SAS_TASK_COMPLETE */
+ /* task delivered, what happened afterwards? */
+ switch (ts->stat) {
+ case SAS_DEV_NO_RESPONSE:
+ case SAS_INTERRUPTED:
+ case
[PATCH 2.6.13 8/14] sas-class: sas_event.c SAS Event management and processing
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_event.c
linux-2.6.13/drivers/scsi/sas-class/sas_event.c
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_event.c1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/sas-class/sas_event.c 2005-09-09
11:14:29.0 -0400
@@ -0,0 +1,294 @@
+/*
+ * Serial Attached SCSI (SAS) Event processing
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/sas-class/sas_event.c#25 $
+ */
+
+/**
+ * Implementation Of Priority Queue Without Duplication
+ * Luben Tuikov 2005/07/11
+ *
+ * The SAS class implements priority queue without duplication for
+ * handling ha/port/phy/discover events. That is, we want to process
+ * the last N unique/non-duplicating events, in the order they arrived.
+ *
+ * The requirement is that insertion is O(1), and ordered removal is O(1).
+ *
+ * Suppose events are identified by integers. Then what is required
+ * is that for a given sequence of any random integers R, to find a
+ * sorted sequence E, where
+ * a) |E| <= |R|. If the number of types of events is bounded,
+ *then E is also bounded by that number, from b).
+ * b) For all i and k, E[i] != E[k], except when i == k,
+ *this gives us uniqueness/non duplication.
+ * c) For all i < k, Order(E[i]) < Order(E[k]), this gives us
+ *ordering.
+ * d) If T(R) = E, then O(T) <= |R|, this ensures that insertion
+ *is O(1), and ordered removal is O(1) trivially, since we
+ *remove at the head of E.
+ *
+ * Example:
+ * If R = {4, 5, 1, 2, 5, 3, 3, 4, 4, 3, 1}, then
+ *E = {2, 5, 4, 3, 1}.
+ *
+ * The algorithm, T, makes use of an array of list elements, indexed
+ * by event type, and an event list head which is a linked list of the
+ * elements of the array. When the next event arrives, we index the
+ * array by the event, and add that event to the tail of the event
+ * list head, deleting it from its previous list position (if it had
+ * one).
+ *
+ * Clearly insertion is O(1).
+ *
+ * E is given by the elements of the event list, traversed from head
+ * to tail.
+ */
+
+#include
+#include "sas_internal.h"
+#include "sas_dump.h"
+#include
+
+static void sas_process_phy_event(struct sas_phy *phy)
+{
+ unsigned long flags;
+ struct sas_ha_struct *sas_ha = phy->ha;
+ enum phy_event phy_event;
+
+ spin_lock_irqsave(_ha->event_lock, flags);
+ while (!list_empty(>phy_event_list)) {
+ struct list_head *head = phy->phy_event_list.next;
+ phy_event = container_of(head, struct sas_event, el)->event;
+ list_del_init(head);
+ spin_unlock_irqrestore(_ha->event_lock, flags);
+
+ sas_dprint_phye(phy->id, phy_event);
+
+ switch(phy_event) {
+ case PHYE_LOSS_OF_SIGNAL:
+ sas_phye_loss_of_signal(phy);
+ break;
+ case PHYE_OOB_DONE:
+ sas_phye_oob_done(phy);
+ break;
+ case PHYE_OOB_ERROR:
+ sas_phye_oob_error(phy);
+ break;
+ case PHYE_SPINUP_HOLD:
+ sas_phye_spinup_hold(phy);
+ break;
+ }
+ spin_lock_irqsave(_ha->event_lock, flags);
+ }
+ /* Clear the bit in case we received events in due time. */
+ sas_ha->phye_mask &= ~(1 << phy->id);
+ spin_unlock_irqrestore(_ha->event_lock, flags);
+}
+
+static void sas_process_port_event(struct sas_phy *phy)
+{
+ unsigned long flags;
+ struct sas_ha_struct *sas_ha = phy->ha;
+ enum port_event port_event;
+
+ spin_lock_irqsave(_ha->event_lock, flags);
+ while (!list_empty(>port_event_list)) {
+ struct list_head *head = phy->port_event_list.next;
+ port_event = container_of(head, struct sas
[PATCH 2.6.13 5/14] sas-class: sas_discover.c Discover process (end devices)
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_discover.c
linux-2.6.13/drivers/scsi/sas-class/sas_discover.c
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_discover.c 1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/sas-class/sas_discover.c 2005-09-09
11:14:29.0 -0400
@@ -0,0 +1,1577 @@
+/*
+ * Serial Attached SCSI (SAS) Discover process
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/sas-class/sas_discover.c#130 $
+ */
+
+#include
+#include
+#include
+#include
+#include "sas_internal.h"
+#include
+#include
+
+/* -- Domain device attributes -- */
+
+ssize_t dev_show_type(struct domain_device *dev, char *page)
+{
+ static const char *dev_type[] = {
+ "no device",
+ "end device",
+ "edge expander",
+ "fanout expander",
+ "host adapter",
+ "sata device",
+ "sata port multiplier",
+ "sata port multiplier port",
+ };
+ return sprintf(page, "%s\n", dev_type[dev->dev_type]);
+}
+
+ssize_t dev_show_iproto(struct domain_device *dev, char *page)
+{
+ return sas_show_proto(dev->iproto, page);
+}
+
+ssize_t dev_show_tproto(struct domain_device *dev, char *page)
+{
+ return sas_show_proto(dev->tproto, page);
+}
+
+ssize_t dev_show_sas_addr(struct domain_device *dev, char *page)
+{
+ return sprintf(page, "%llx\n", SAS_ADDR(dev->sas_addr));
+}
+
+ssize_t dev_show_linkrate(struct domain_device *dev, char *page)
+{
+ return sas_show_linkrate(dev->linkrate, page);
+}
+
+ssize_t dev_show_min_linkrate(struct domain_device *dev, char *page)
+{
+ return sas_show_linkrate(dev->min_linkrate, page);
+}
+
+ssize_t dev_show_max_linkrate(struct domain_device *dev, char *page)
+{
+ return sas_show_linkrate(dev->max_linkrate, page);
+}
+
+ssize_t dev_show_pathways(struct domain_device *dev, char *page)
+{
+ return sprintf(page, "%d\n", dev->pathways);
+}
+
+/* -- SATA specific sysfs -- */
+
+static ssize_t sata_show_command_set(struct domain_device *dev, char *page)
+{
+ static const char *cs[] = {
+ "ATA",
+ "ATAPI",
+ };
+ return sprintf(page, "%s\n", cs[dev->sata_dev.command_set]);
+}
+
+static ssize_t sata_show_rps_resp(struct domain_device *dev, char *page)
+{
+ char *buf = page;
+ if ((dev->tproto & SAS_PROTO_STP) &&
+ dev->sata_dev.rps_resp.frame_type == SMP_RESPONSE &&
+ dev->sata_dev.rps_resp.function == SMP_REPORT_PHY_SATA &&
+ dev->sata_dev.rps_resp.result == SMP_RESP_FUNC_ACC) {
+ int i = 0;
+ u8 *p = (u8 *) >sata_dev.rps_resp;
+ for (i = 0; i < sizeof(struct smp_resp); i+=4, p+=4) {
+ buf += sprintf(buf, "%02x %02x %02x %02x\n",
+ *(p+0), *(p+1), *(p+2), *(p+3));
+ }
+ }
+ return buf-page;
+}
+
+static inline int show_chars(__le16 *p, int start, int words, char *page)
+{
+ int i;
+ char *buf = page;
+
+ for (i = start; i < start+words; i++) {
+ u16 s = le16_to_cpu(p[i]);
+ char a = (s&0xFF00)>>8;
+ char b = s&0x00FF;
+
+ if (a == 0)
+ break;
+ buf += sprintf(buf, "%c", a);
+ if (b == 0)
+ break;
+ buf += sprintf(buf, "%c", b);
+
+ }
+ return buf-page;
+}
+
+static ssize_t sata_show_serial_number(struct domain_device *dev, char *page)
+{
+ char *buf = page;
+ __le16 *identify_x = NULL;
+
+ if (dev->sata_dev.command_set == ATA_COMMAND_SET)
[PATCH 2.6.13 11/20] aic94xx: aic94xx_reg.h Register access header file
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_reg.h
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_reg.h
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_reg.h1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/aic94xx/aic94xx_reg.h 2005-09-09
11:21:23.0 -0400
@@ -0,0 +1,290 @@
+/*
+ * Aic94xx SAS/SATA driver hardware registers definitions.
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This file is part of the aic94xx driver.
+ *
+ * The aic94xx driver is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ * The aic94xx driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with the aic94xx driver; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/aic94xx/aic94xx_reg.h#18 $
+ */
+
+#ifndef _AIC94XX_REG_H_
+#define _AIC94XX_REG_H_
+
+#include
+#include "aic94xx_hwi.h"
+
+/* Values */
+#define AIC9410_DEV_REV_B00x8
+
+/* MBAR0, SWA, SWB, SWC, internal memory space addresses */
+#define REG_BASE_ADDR 0xB800
+#define REG_BASE_ADDR_CSEQCIO 0xB8002000
+#define REG_BASE_ADDR_EXSI0xB8042800
+
+#define MBAR0_SWA_SIZE0x58
+extern u32MBAR0_SWB_SIZE;
+#define MBAR0_SWC_SIZE0x8
+
+/* MBAR1, points to On Chip Memory */
+#define OCM_BASE_ADDR 0xA000
+#define OCM_MAX_SIZE 0x2
+
+/* Smallest address possible to reference */
+#define ALL_BASE_ADDR OCM_BASE_ADDR
+
+/* PCI configuration space registers */
+#define PCI_IOBAR_OFFSET 4
+
+#define PCI_CONF_MBAR10x6C
+#define PCI_CONF_MBAR0_SWA0x70
+#define PCI_CONF_MBAR0_SWB0x74
+#define PCI_CONF_MBAR0_SWC0x78
+#define PCI_CONF_MBAR_KEY 0x7C
+#define PCI_CONF_FLSH_BAR 0xB8
+
+#include "aic94xx_reg_def.h"
+
+u8 asd_read_reg_byte(struct asd_ha_struct *asd_ha, u32 reg);
+u16 asd_read_reg_word(struct asd_ha_struct *asd_ha, u32 reg);
+u32 asd_read_reg_dword(struct asd_ha_struct *asd_ha, u32 reg);
+
+void asd_write_reg_byte(struct asd_ha_struct *asd_ha, u32 reg, u8 val);
+void asd_write_reg_word(struct asd_ha_struct *asd_ha, u32 reg, u16 val);
+void asd_write_reg_dword(struct asd_ha_struct *asd_ha, u32 reg, u32 val);
+
+void asd_read_reg_string(struct asd_ha_struct *asd_ha, void *dst,
+u32 offs, int count);
+void asd_write_reg_string(struct asd_ha_struct *asd_ha, void *src,
+ u32 offs, int count);
+
+#define ASD_READ_OCM(type, ord, S)\
+static inline type asd_read_ocm_##ord (struct asd_ha_struct *asd_ha, \
+u32 offs)\
+{ \
+ struct asd_ha_addrspace *io_handle = _ha->io_handle[1]; \
+ type val = read##S (io_handle->addr + (unsigned long) offs); \
+ rmb();\
+ return val; \
+}
+
+ASD_READ_OCM(u8, byte, b);
+ASD_READ_OCM(u16,word, w);
+ASD_READ_OCM(u32,dword,l);
+
+#define ASD_DDBSITE_READ(type, ord)\
+static inline type asd_ddbsite_read_##ord (struct asd_ha_struct *asd_ha, \
+ u16 ddb_site_no,\
+ u16 offs) \
+{ \
+ asd_write_reg_word(asd_ha, ALTCIOADR, MnDDB_SITE + offs); \
+ asd_write_reg_word(asd_ha, ADDBPTR, ddb_site_no); \
+ return asd_read_reg_##ord (asd_ha, CTXACCESS); \
+}
+
+ASD_DDBSITE_READ(u32, dword);
+ASD_DDBSITE_READ(u16, word);
+
+static inline u8 asd_ddbsite_read_byte(struct asd_ha_struct *asd_ha,
+ u16 ddb_site_no,
+ u16 offs)
+{
+ if (offs & 1)
+ return asd_ddbsite_read_word(asd_ha, ddb_site_no,
+offs & ~1) >> 8;
+ else
+
[PATCH 2.6.13 15/20] aic94xx: aic94x_sds.c Shared Data Structures and memory
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_sds.c
linux-2.6.13/drivers/scsi/aic94xx/aic94xx_sds.c
--- linux-2.6.13-orig/drivers/scsi/aic94xx/aic94xx_sds.c1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/aic94xx/aic94xx_sds.c 2005-09-09
11:21:23.0 -0400
@@ -0,0 +1,964 @@
+/*
+ * Aic94xx SAS/SATA driver access to shared data structures and memory
+ * maps.
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This file is part of the aic94xx driver.
+ *
+ * The aic94xx driver is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ * The aic94xx driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with the aic94xx driver; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/aic94xx/aic94xx_sds.c#34 $
+ */
+
+#include
+#include
+
+#include "aic94xx.h"
+#include "aic94xx_reg.h"
+
+/* -- OCM stuff -- */
+
+struct asd_ocm_dir_ent {
+ u8 type;
+ u8 offs[3];
+ u8 _r1;
+ u8 size[3];
+} __attribute__ ((packed));
+
+struct asd_ocm_dir {
+ char sig[2];
+ u8 _r1[2];
+ u8 major; /* 0 */
+ u8 minor; /* 0 */
+ u8 _r2;
+ u8 num_de;
+ struct asd_ocm_dir_ent entry[15];
+} __attribute__ ((packed));
+
+struct asd_bios_chim_struct {
+ char sig[4];
+ u8 major; /* 1 */
+ u8 minor; /* 0 */
+ u8 bios_major;
+ u8 bios_minor;
+ __le32 bios_build;
+ u8 flags;
+ u8 pci_slot;
+ __le16 ue_num;
+ __le16 ue_size;
+ u8 _r[14];
+ /* The unit element array is right here.
+*/
+} __attribute__ ((packed));
+
+/**
+ * asd_read_ocm_seg - read an on chip memory (OCM) segment
+ * @asd_ha: pointer to the host adapter structure
+ * @buffer: where to write the read data
+ * @offs: offset into OCM where to read from
+ * @size: how many bytes to read
+ *
+ * Return the number of bytes not read. Return 0 on success.
+ */
+static int asd_read_ocm_seg(struct asd_ha_struct *asd_ha, void *buffer,
+ u32 offs, int size)
+{
+ u8 *p = buffer;
+ if (unlikely(asd_ha->iospace))
+ asd_read_reg_string(asd_ha, buffer, offs+OCM_BASE_ADDR, size);
+ else {
+ for ( ; size > 0; size--, offs++, p++)
+ *p = asd_read_ocm_byte(asd_ha, offs);
+ }
+ return size;
+}
+
+static int asd_read_ocm_dir(struct asd_ha_struct *asd_ha,
+ struct asd_ocm_dir *dir, u32 offs)
+{
+ int err = asd_read_ocm_seg(asd_ha, (void *)dir, offs, sizeof(*dir));
+ if (err) {
+ ASD_DPRINTK("couldn't read ocm segment\n");
+ return err;
+ }
+ if (dir->sig[0] != 'M' || dir->sig[1] != 'O') {
+ ASD_DPRINTK("no valid dir signature(%c%c) at start of OCM\n",
+ dir->sig[0], dir->sig[1]);
+ return -ENOENT;
+ }
+ if (dir->major != 0) {
+ asd_printk("unsupported major version of ocm dir:0x%x\n",
+ dir->major);
+ return -ENOENT;
+ }
+ dir->num_de &= 0xf;
+ return 0;
+}
+
+#define THREE_TO_NUM(X) ((X)[0] | ((X)[1] << 8) | ((X)[2] << 16))
+
+static int asd_find_dir_entry(struct asd_ocm_dir *dir, u8 type,
+ u32 *offs, u32 *size)
+{
+ int i;
+ struct asd_ocm_dir_ent *ent;
+
+ for (i = 0; i < dir->num_de; i++) {
+ if (dir->entry[i].type == type)
+ break;
+ }
+ if (i >= dir->num_de)
+ return -ENOENT;
+ ent = >entry[i];
+ *offs = (u32) THREE_TO_NUM(ent->offs);
+ *size = (u32) THREE_TO_NUM(ent->size);
+ return 0;
+}
+
+#define OCM_BIOS_CHIM_DE 2
+#define BC_BIOS_PRESENT 1
+
+static int asd_get_bios_chim(struct asd_ha_struct *asd_ha,
+struct asd_ocm_dir *dir)
+{
+ int err;
+ struct asd_bios_chim_struct *bc_struct;
+ u32 offs, size;
+
+ err = asd_find_dir_entry(dir, OCM_BIOS_CHIM_DE, , );
+ if (err) {
+ ASD_DPRINTK(&q
[PATCH 2.6.13 9/14] sas-class: sas_expander.c Expander discovery and configuration
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]>
diff -X linux-2.6.13/Documentation/dontdiff -Naur
linux-2.6.13-orig/drivers/scsi/sas-class/sas_expander.c
linux-2.6.13/drivers/scsi/sas-class/sas_expander.c
--- linux-2.6.13-orig/drivers/scsi/sas-class/sas_expander.c 1969-12-31
19:00:00.0 -0500
+++ linux-2.6.13/drivers/scsi/sas-class/sas_expander.c 2005-09-09
11:14:29.0 -0400
@@ -0,0 +1,1830 @@
+/*
+ * Serial Attached SCSI (SAS) Expander discovery and configuration
+ *
+ * Copyright (C) 2005 Adaptec, Inc. All rights reserved.
+ * Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under GPLv2.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * $Id: //depot/sas-class/sas_expander.c#54 $
+ */
+
+#include
+#include
+
+#include "sas_internal.h"
+#include
+#include
+
+static int sas_discover_expander(struct domain_device *dev);
+static int sas_configure_routing(struct domain_device *dev, u8 *sas_addr);
+static int sas_disable_routing(struct domain_device *dev, u8 *sas_addr);
+
+static ssize_t smp_portal_read(struct kobject *, char *, loff_t, size_t);
+static ssize_t smp_portal_write(struct kobject *, char *, loff_t, size_t);
+
+/* -- Expander attributes -- */
+
+static ssize_t ex_show_change_count(struct domain_device *dev, char *page)
+{
+ return sprintf(page, "%d\n", dev->ex_dev.ex_change_count);
+}
+
+static ssize_t ex_show_max_route_indexes(struct domain_device *dev, char *page)
+{
+ return sprintf(page, "%d\n", dev->ex_dev.max_route_indexes);
+}
+
+static ssize_t ex_show_num_phys(struct domain_device *dev, char *page)
+{
+ return sprintf(page, "%d\n", dev->ex_dev.num_phys);
+}
+
+static ssize_t ex_show_enclosure_logical_id(struct domain_device *dev,
+ char *page)
+{
+ return sprintf(page, "%llx\n",
+ SAS_ADDR(dev->ex_dev.enclosure_logical_id));
+}
+
+static ssize_t ex_show_vendor_id(struct domain_device *dev, char *page)
+{
+ return sprintf(page, "%s\n", dev->ex_dev.vendor_id);
+}
+
+static ssize_t ex_show_product_id(struct domain_device *dev, char *page)
+{
+ return sprintf(page, "%s\n", dev->ex_dev.product_id);
+}
+
+static ssize_t ex_show_product_rev(struct domain_device *dev, char *page)
+{
+ return sprintf(page, "%s\n", dev->ex_dev.product_rev);
+}
+
+static ssize_t ex_show_component_vendor_id(struct domain_device *dev,
+ char *page)
+{
+ return sprintf(page, "%s\n", dev->ex_dev.component_vendor_id);
+}
+
+static ssize_t ex_show_component_id(struct domain_device *dev, char *page)
+{
+ return sprintf(page, "%d\n", dev->ex_dev.component_id);
+}
+
+static ssize_t ex_show_component_revision_id(struct domain_device *dev,
+char *page)
+{
+ return sprintf(page, "%d\n", dev->ex_dev.component_revision_id);
+}
+
+static ssize_t ex_show_conf_route_table(struct domain_device *dev,
+ char *page)
+{
+ return sprintf(page, "%d\n", dev->ex_dev.conf_route_table);
+}
+
+static ssize_t ex_show_configuring(struct domain_device *dev,
+ char *page)
+{
+ return sprintf(page, "%d\n", dev->ex_dev.configuring);
+}
+
+static struct domain_dev_attribute ex_attrs[] = {
+ __ATTR(dev_type, 0444, dev_show_type, NULL),
+ __ATTR(iproto, 0444, dev_show_iproto, NULL),
+ __ATTR(tproto, 0444, dev_show_tproto, NULL),
+ __ATTR(sas_addr, 0444, dev_show_sas_addr, NULL),
+ __ATTR(linkrate, 0444, dev_show_linkrate, NULL),
+ __ATTR(min_linkrate, 0444, dev_show_min_linkrate, NULL),
+ __ATTR(max_linkrate, 0444, dev_show_max_linkrate, NULL),
+ __ATTR(pathways, 0444, dev_show_pathways, NULL),
+ __ATTR(change_count, 0444, ex_show_change_count, NULL),
+ __ATTR(max_route_indexes, 0444, ex_show_max_route_indexes, NULL),
+ __ATTR(num_phys, 0444, ex_show_num_phys, NULL),
+ __ATTR(enclosure_logical_id, 0444, ex_show_enclosure_logical_id, NULL),
+ __ATTR(v
[PATCH 2.6.13 0/14] sas-class: Kconfig
Signed-off-by: Luben Tuikov <[EMAIL PROTECTED]> diff -X linux-2.6.13/Documentation/dontdiff -Naur linux-2.6.13-orig/drivers/scsi/sas-class/Kconfig linux-2.6.13/drivers/scsi/sas-class/Kconfig --- linux-2.6.13-orig/drivers/scsi/sas-class/Kconfig1969-12-31 19:00:00.0 -0500 +++ linux-2.6.13/drivers/scsi/sas-class/Kconfig 2005-09-09 11:33:28.0 -0400 @@ -0,0 +1,40 @@ +# +# Kernel configuration file for the SAS Class +# +# Copyright (C) 2005 Adaptec, Inc. All rights reserved. +# Copyright (C) 2005 Luben Tuikov <[EMAIL PROTECTED]> +# +# This file is licensed under GPLv2. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; version 2 of the +# License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +# General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 +# USA +# +# $Id: //depot/sas-class/Kconfig#2 $ +# + +config SAS_CLASS + tristate "SAS Layer and Discovery" + depends on SCSI + help + If you wish to use a SAS Low Level Device Driver (LLDD) + say Y or M here. Otherwise, say N. + +config SAS_DEBUG + bool "Compile the SAS Layer in debug mode" + default y + depends on SAS_CLASS + help + Compiles the SAS Layer in debug mode. In debug mode, the + SAS Layer prints diagnostic and debug messages. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
