Re: [build bug] drivers/scsi/NCR53C9x.c:913: error: 'Scsi_Cmnd' has no member named 'use_sg'
On Thu, 31 Jan 2008, Boaz Harrosh wrote: On Thu, Jan 31 2008 at 19:29 +0200, Ingo Molnar [EMAIL PROTECTED] wrote: FYI, automated testing found the following build breakage: drivers/scsi/NCR53C9x.c: In function 'esp_get_dmabufs': drivers/scsi/NCR53C9x.c:913: error: 'Scsi_Cmnd' has no member named 'use_sg' drivers/scsi/NCR53C9x.c:914: error: 'Scsi_Cmnd' has no member named 'request_bufflen' config attached. Ingo Cc linux-scsi mailing list. This driver and others are scheduled to be removed in the scsi-pending tree and are awaiting ACKs from - disappeared - maintainers. Well, buried in some other activities. You certainly have had my ack to remove dec_esp.c already and I started to work on replacement front-end drivers long ago. Unfortunately one of the three hardware configurations to be supported by the front-ends does not fit the interrupt handling model implemented by the esp_scsi.c core. Or it is actually the other way round as you cannot adjust hardware to fit the driver, so I am in a process of rewriting the core a little bit in this respect -- the core switches to interrupt polling under some circumstances and does not expect a higher-priority interrupt of a different kind to arrive from the bus master controller the SCSI chips are attached to instead. Being no SCSI expert though I have to study the SCSI spec well enough to understand some bits and I am somewhat distracted these days, so it may take a while yet. It is at the highest priority on my to-do list though. Maciej - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] esp_scsi: Fix reset cleanup spinlock recursion
The esp_reset_cleanup() function is called with the host lock held and
invokes starget_for_each_device() which wants to take it too. Here is a
fix along the lines of shost_for_each_device()/__shost_for_each_device()
adding a __starget_for_each_device() counterpart which assumes the lock
has already been taken.
Eventually, I think the driver should get modified so that more work is
done as a softirq rather than in the interrupt context, but for now it
fixes a bug that causes the spinlock debugger to fire.
While at it, it fixes a small number of cosmetic problems with
starget_for_each_device() too.
Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
Checked with checkpatch.pl and at the run time. Please apply.
Maciej
patch-mips-2.6.23-rc5-20070904-esp_scsi-reset-3
diff -up --recursive --new-file
linux-mips-2.6.23-rc5-20070904.macro/drivers/scsi/esp_scsi.c
linux-mips-2.6.23-rc5-20070904/drivers/scsi/esp_scsi.c
--- linux-mips-2.6.23-rc5-20070904.macro/drivers/scsi/esp_scsi.c
2007-10-23 14:07:38.0 +
+++ linux-mips-2.6.23-rc5-20070904/drivers/scsi/esp_scsi.c 2007-11-26
01:01:10.0 +
@@ -2028,8 +2028,8 @@ static void esp_reset_cleanup(struct esp
tp-flags |= ESP_TGT_CHECK_NEGO;
if (tp-starget)
- starget_for_each_device(tp-starget, NULL,
- esp_clear_hold);
+ __starget_for_each_device(tp-starget, NULL,
+ esp_clear_hold);
}
esp-flags = ~ESP_FLAG_RESETTING;
}
diff -up --recursive --new-file
linux-mips-2.6.23-rc5-20070904.macro/drivers/scsi/scsi.c
linux-mips-2.6.23-rc5-20070904/drivers/scsi/scsi.c
--- linux-mips-2.6.23-rc5-20070904.macro/drivers/scsi/scsi.c2007-09-04
04:55:44.0 +
+++ linux-mips-2.6.23-rc5-20070904/drivers/scsi/scsi.c 2007-12-05
16:00:40.0 +
@@ -886,11 +886,11 @@ EXPORT_SYMBOL(__scsi_iterate_devices);
* starget_for_each_device - helper to walk all devices of a target
* @starget: target whose devices we want to iterate over.
*
- * This traverses over each devices of @shost. The devices have
+ * This traverses over each device of @starget. The devices have
* a reference that must be released by scsi_host_put when breaking
* out of the loop.
*/
-void starget_for_each_device(struct scsi_target *starget, void * data,
+void starget_for_each_device(struct scsi_target *starget, void *data,
void (*fn)(struct scsi_device *, void *))
{
struct Scsi_Host *shost = dev_to_shost(starget-dev.parent);
@@ -905,6 +905,33 @@ void starget_for_each_device(struct scsi
EXPORT_SYMBOL(starget_for_each_device);
/**
+ * __starget_for_each_device - helper to walk all devices of a target
+ * (UNLOCKED)
+ * @starget: target whose devices we want to iterate over.
+ *
+ * This traverses over each device of @starget. It does _not_
+ * take a reference on the scsi_device, so the whole loop must be
+ * protected by shost-host_lock.
+ *
+ * Note: The only reason why drivers would want to use this is because
+ * they need to access the device list in irq context. Otherwise you
+ * really want to use starget_for_each_device instead.
+ **/
+void __starget_for_each_device(struct scsi_target *starget, void *data,
+ void (*fn)(struct scsi_device *, void *))
+{
+ struct Scsi_Host *shost = dev_to_shost(starget-dev.parent);
+ struct scsi_device *sdev;
+
+ __shost_for_each_device(sdev, shost) {
+ if ((sdev-channel == starget-channel)
+ (sdev-id == starget-id))
+ fn(sdev, data);
+ }
+}
+EXPORT_SYMBOL(__starget_for_each_device);
+
+/**
* __scsi_device_lookup_by_target - find a device given the target (UNLOCKED)
* @starget: SCSI target pointer
* @lun: SCSI Logical Unit Number
diff -up --recursive --new-file
linux-mips-2.6.23-rc5-20070904.macro/include/scsi/scsi_device.h
linux-mips-2.6.23-rc5-20070904/include/scsi/scsi_device.h
--- linux-mips-2.6.23-rc5-20070904.macro/include/scsi/scsi_device.h
2007-09-04 04:56:21.0 +
+++ linux-mips-2.6.23-rc5-20070904/include/scsi/scsi_device.h 2007-11-26
01:00:57.0 +
@@ -222,6 +222,9 @@ extern struct scsi_device *__scsi_device
uint);
extern void starget_for_each_device(struct scsi_target *, void *,
void (*fn)(struct scsi_device *, void *));
+extern void __starget_for_each_device(struct scsi_target *, void *,
+ void (*fn)(struct scsi_device *,
+void *));
/* only exposed to implement shost_for_each_device */
extern struct scsi_device *__scsi_iterate_devices(struct Scsi_Host *,
-
To unsubscribe from this list: send the line unsubscribe
Re: [patchset 0/24] Lots of the Accessors patches and !use_sg cleanup
On Tue, 11 Sep 2007, Boaz Harrosh wrote: [esp family] - Maciej W. Rozycki [EMAIL PROTECTED] 0020 drivers/scsi/NCR53C9x.c drivers/scsi/NCR53C9x.h drivers/scsi/dec_esp.c drivers/scsi/oktagon_esp.c drivers/scsi/sun3x_esp.c Not really, but I have suitable hardware and can test your changes to drivers/scsi/NCR53C9x.c, drivers/scsi/NCR53C9x.h and drivers/scsi/dec_esp.c only. Fortunately it does not really matter that much, because the the whole family of drivers has been deprecated and is going away at some pace in favour to the framework around the new drivers/scsi/esp_scsi.c core. Thanks for your effort though! Maciej - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Prefix each line of multiline printk(KERN_level foo\nbar) with KERN_level
On Sun, 26 Aug 2007, Geert Uytterhoeven wrote: What I mean is that probably there used to be a printk() call starting with `\n'. Then someone added a `KERN_ERR' in front of it. I gather '\n' at the beginning is to assure the following line is output on a separate line rather than as a continuation of another one which may have been output without a trailing '\n'. A situation where printk() is called with a string containing no trailing '\n' may be discouraged, but there are some more or less justified exceptions. For example the SCSI disk spin-up code is one. Therefore it may be reasonable for more critical messages -- perhaps not ones at KERN_ERR, but certainly KERN_CRIT and higher ones -- that may potentially happen asynchronously to start with '\n'. In this case a call would look like this: printk(\n KERN_CRIT The actual message.\n); Of course based on console_loglevel and default_message_level the leading '\n' may still get swallowed from what gets printed to the console terminal, but in reality I do not think that poses a problem, as these both can be set by a system administrator according to the local policy. Maciej - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.20-rc1 10/10] dec_esp: Driver model for the PMAZ-A
This is a set of changes that converts the PMAZ-A support to the driver
model.
Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
The use of the driver model required switching to the hotplug SCSI
initialization model, which in turn required a change to the core NCR53C9x
driver. I decided not to break all the frontend drivers and introduced an
additional parameter for esp_allocate() to select between the old and the
new model. I hope this is OK, but I would be fine with converting
NCR53C9x to the new model unconditionally as long as I do not have to fix
all the other frontends (OK, perhaps I could do some of them ;-) ).
Please apply.
Maciej
patch-2.6.20-rc1-tc-pmaz-a-5
diff -up --recursive --new-file linux-2.6.20-rc1.macro/drivers/scsi/NCR53C9x.c
linux-2.6.20-rc1/drivers/scsi/NCR53C9x.c
--- linux-2.6.20-rc1.macro/drivers/scsi/NCR53C9x.c 2006-12-14
01:14:23.0 +
+++ linux-2.6.20-rc1/drivers/scsi/NCR53C9x.c2006-12-18 21:29:38.0
+
@@ -528,12 +528,16 @@ void esp_bootup_reset(struct NCR_ESP *es
/* Allocate structure and insert basic data such as SCSI chip frequency
* data and a pointer to the device
*/
-struct NCR_ESP* esp_allocate(struct scsi_host_template *tpnt, void *esp_dev)
+struct NCR_ESP* esp_allocate(struct scsi_host_template *tpnt, void *esp_dev,
+int hotplug)
{
struct NCR_ESP *esp, *elink;
struct Scsi_Host *esp_host;
- esp_host = scsi_register(tpnt, sizeof(struct NCR_ESP));
+ if (hotplug)
+ esp_host = scsi_host_alloc(tpnt, sizeof(struct NCR_ESP));
+ else
+ esp_host = scsi_register(tpnt, sizeof(struct NCR_ESP));
if(!esp_host)
panic(Cannot register ESP SCSI host);
esp = (struct NCR_ESP *) esp_host-hostdata;
diff -up --recursive --new-file linux-2.6.20-rc1.macro/drivers/scsi/NCR53C9x.h
linux-2.6.20-rc1/drivers/scsi/NCR53C9x.h
--- linux-2.6.20-rc1.macro/drivers/scsi/NCR53C9x.h 2006-12-14
01:14:23.0 +
+++ linux-2.6.20-rc1/drivers/scsi/NCR53C9x.h2006-12-18 21:29:38.0
+
@@ -652,7 +652,7 @@ extern int nesps, esps_in_use, esps_runn
/* External functions */
extern void esp_bootup_reset(struct NCR_ESP *esp, struct ESP_regs *eregs);
-extern struct NCR_ESP *esp_allocate(struct scsi_host_template *, void *);
+extern struct NCR_ESP *esp_allocate(struct scsi_host_template *, void *, int);
extern void esp_deallocate(struct NCR_ESP *);
extern void esp_release(void);
extern void esp_initialize(struct NCR_ESP *);
diff -up --recursive --new-file linux-2.6.20-rc1.macro/drivers/scsi/blz1230.c
linux-2.6.20-rc1/drivers/scsi/blz1230.c
--- linux-2.6.20-rc1.macro/drivers/scsi/blz1230.c 2006-12-14
01:14:23.0 +
+++ linux-2.6.20-rc1/drivers/scsi/blz1230.c 2006-12-18 21:29:38.0
+
@@ -121,7 +121,8 @@ int __init blz1230_esp_detect(struct scs
*/
address = ZTWO_VADDR(board);
eregs = (struct ESP_regs *)(address + REAL_BLZ1230_ESP_ADDR);
- esp = esp_allocate(tpnt, (void *)board+REAL_BLZ1230_ESP_ADDR);
+ esp = esp_allocate(tpnt, (void *)board + REAL_BLZ1230_ESP_ADDR,
+ 0);
esp_write(eregs-esp_cfg1, (ESP_CONFIG1_PENABLE | 7));
udelay(5);
diff -up --recursive --new-file linux-2.6.20-rc1.macro/drivers/scsi/blz2060.c
linux-2.6.20-rc1/drivers/scsi/blz2060.c
--- linux-2.6.20-rc1.macro/drivers/scsi/blz2060.c 2006-12-14
01:14:23.0 +
+++ linux-2.6.20-rc1/drivers/scsi/blz2060.c 2006-12-18 21:29:38.0
+
@@ -100,7 +100,7 @@ int __init blz2060_esp_detect(struct scs
unsigned long board = z-resource.start;
if (request_mem_region(board+BLZ2060_ESP_ADDR,
sizeof(struct ESP_regs), NCR53C9x)) {
- esp = esp_allocate(tpnt, (void *)board+BLZ2060_ESP_ADDR);
+ esp = esp_allocate(tpnt, (void *)board + BLZ2060_ESP_ADDR, 0);
/* Do command transfer with programmed I/O */
esp-do_pio_cmds = 1;
diff -up --recursive --new-file
linux-2.6.20-rc1.macro/drivers/scsi/cyberstorm.c
linux-2.6.20-rc1/drivers/scsi/cyberstorm.c
--- linux-2.6.20-rc1.macro/drivers/scsi/cyberstorm.c2006-12-14
01:14:23.0 +
+++ linux-2.6.20-rc1/drivers/scsi/cyberstorm.c 2006-12-18 21:29:38.0
+
@@ -126,7 +126,7 @@ int __init cyber_esp_detect(struct scsi_
sizeof(struct ESP_regs));
return 0;
}
- esp = esp_allocate(tpnt, (void *)board+CYBER_ESP_ADDR);
+ esp = esp_allocate(tpnt, (void *)board + CYBER_ESP_ADDR, 0);
/* Do command transfer with programmed I/O */
esp-do_pio_cmds = 1;
diff -up --recursive --new-file
linux-2.6.20-rc1.macro/drivers/scsi/cyberstormII.c
linux-2.6.20
Re: iomapping a big endian area
On Tue, 5 Apr 2005, Russell King wrote: physical bus: 31...24 23...16 15...8 7...0 BE version 1 (word invariant) byte access byte 0 byte 1 byte 2 byte 3 word access 31-24 23-16 15-87-0 BE version 2 (byte invariant) byte access byte 3 byte 2 byte 1 byte 0 word access 7-0 15-823-16 31-24 These are just representations of the same thing. However, I did deliberately elect not to try to solve this problem in the accessors. I know all about the register relayout, because 53c700 has to do that on parisc. They aren't. On some of our platforms, we have to exclusive-or the address for byte accesses with 3 to convert to the right endian-ness. The same with certain MIPS configurations. And likewise you need to xor addresses with 2 for halfword accesses. Sure, from the point of view of which byte each byte of a word represents, it's true that they're indentical. But as far as the hardware is concerned, they're definitely different. To clarify it a bit: both big and little endian representations are always the same -- it's going to a domain of the reverse endianness that can be done in two different ways, i.e. by preserving either bit or byte ordering (as described above). Depending on the interpretation of data being passed you want one or the other. That's why some systems provide ways of doing both kinds of accesses in hardware (e.g. the host bus to PCI bridge) to save CPU cycles needed for bit shuffling otherwise. Maciej - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
