(added Cc: lsml)
Kristian Høgsberg wrote at lkml:
> I saw that the stack
[the FireWire stack]
> creates a struct device per LUN, which is kinda gross in my opinion.
If you mean regular "unit directories" here, not SCSI LUs, then one
device per unit makes sense. Different units of a node may
Stefan Richter wrote:
Kristian Høgsberg wrote:
Jeff Garzik wrote:
doesn't allowing the stack to issue REPORT LUNS take care of this?
Possibly, I don't have firewire multi-LUN devices to test with here.
The LUNs are also discoverable from the firewire config rom, which is
why I put the
Stefan Richter wrote:
Kristian Høgsberg wrote:
Jeff Garzik wrote:
doesn't allowing the stack to issue REPORT LUNS take care of this?
Possibly, I don't have firewire multi-LUN devices to test with here.
The LUNs are also discoverable from the firewire config rom, which is
why I put the
(added Cc: lsml)
Kristian Høgsberg wrote at lkml:
I saw that the stack
[the FireWire stack]
creates a struct device per LUN, which is kinda gross in my opinion.
If you mean regular unit directories here, not SCSI LUs, then one
device per unit makes sense. Different units of a node may
Kristian Høgsberg wrote:
> Jeff Garzik wrote:
>> doesn't allowing the stack to issue REPORT LUNS take care of this?
>
> Possibly, I don't have firewire multi-LUN devices to test with here.
> The LUNs are also discoverable from the firewire config rom, which is
> why I put the comment there.
Jeff Garzik wrote:
Again, thanks for your comments, I've added patches to my git repo, will send
out a new set on LKML before the end of this week.
+/* I don't know why the SCSI stack doesn't define something like
this... */
+typedef void (*scsi_done_fn_t) (struct scsi_cmnd *);
submit a
Jeff Garzik wrote:
Again, thanks for your comments, I've added patches to my git repo, will send
out a new set on LKML before the end of this week.
+/* I don't know why the SCSI stack doesn't define something like
this... */
+typedef void (*scsi_done_fn_t) (struct scsi_cmnd *);
submit a
Kristian Høgsberg wrote:
Jeff Garzik wrote:
doesn't allowing the stack to issue REPORT LUNS take care of this?
Possibly, I don't have firewire multi-LUN devices to test with here.
The LUNs are also discoverable from the firewire config rom, which is
why I put the comment there. This
Jeff Garzik wrote:
> Kristian Høgsberg wrote:
>> +struct sbp2_status {
>> +unsigned int orb_high:16;
>
> unsigned short? probably generates better code than a bitfield:16
>
>
>> +unsigned int sbp_status:8;
>
> unsigned char?
>
>
>> +unsigned int len:3;
>> +unsigned int
Jeff Garzik wrote:
Kristian Høgsberg wrote:
+struct sbp2_status {
+unsigned int orb_high:16;
unsigned short? probably generates better code than a bitfield:16
+unsigned int sbp_status:8;
unsigned char?
+unsigned int len:3;
+unsigned int dead:1;
+unsigned
Kristian Høgsberg wrote:
Pull in the fw-sbp2 driver for firewire storage devices.
Signed-off-by: Kristian Høgsberg <[EMAIL PROTECTED]>
---
drivers/fw/fw-ohci.c |2
drivers/fw/fw-sbp2.c | 1083 ++
2 files changed, 1084 insertions(+), 1
Pull in the fw-sbp2 driver for firewire storage devices.
Signed-off-by: Kristian Høgsberg <[EMAIL PROTECTED]>
---
drivers/fw/fw-ohci.c |2
drivers/fw/fw-sbp2.c | 1083 ++
2 files changed, 1084 insertions(+), 1 deletions(-)
diff --git
Pull in the fw-sbp2 driver for firewire storage devices.
Signed-off-by: Kristian Høgsberg [EMAIL PROTECTED]
---
drivers/fw/fw-ohci.c |2
drivers/fw/fw-sbp2.c | 1083 ++
2 files changed, 1084 insertions(+), 1 deletions(-)
diff --git
Kristian Høgsberg wrote:
Pull in the fw-sbp2 driver for firewire storage devices.
Signed-off-by: Kristian Høgsberg [EMAIL PROTECTED]
---
drivers/fw/fw-ohci.c |2
drivers/fw/fw-sbp2.c | 1083 ++
2 files changed, 1084 insertions(+), 1
14 matches
Mail list logo
