Re: [PATCH] dtc: Coding police and printk levels

Alan Cox lxorguk.ukuu.org.uk> writes: > > On Fri, 22 Jun 2007 11:00:06 -0700 > "Darrick J. Wong" us.ibm.com> wrote: > > > On Fri, Jun 22, 2007 at 02:26:29PM +0100, Alan Cox wrote: > > > -244,7 +242,7 > > > if (check_signature(base + > > > signatures

scsi, was Re: -mm merge plans for 2.6.23

> restore-acpi-change-for-scsi.patch > git-scsi-misc-vs-greg-sysfs-stuff.patch > aacraid-rename-check_reset.patch > scsi-dont-build-scsi_dma_mapunmap-for-has_dma.patch > drivers-scsi-small-cleanups.patch > sym53c8xx_2-claims-cpqarray-device.patch > drivers-scsi-wd33c93c-cleanups.patch > make-seagat

Re: [patch 2/4] Expose Power Management Policy option to users

Hi! > This patch will modify the scsi subsystem to allow > users to set a power management policy for the link. > > The scsi subsystem will create a new sysfs file for each > host in /sys/class/scsi_host called "link_power_management_policy". > This file can have 3 possible values: > > Value

Re: [patch 2/4] Expose Power Management Policy option to users

On Mon, 9 Jul 2007 19:36:04 + Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > This patch will modify the scsi subsystem to allow > > users to set a power management policy for the link. > > > > The scsi subsystem will create a new sysfs file for each > > host in /sys/class/scsi_host call

Re: scsi, was Re: -mm merge plans for 2.6.23

On Wed, 11 Jul 2007 13:37:18 +0200 Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > restore-acpi-change-for-scsi.patch > > git-scsi-misc-vs-greg-sysfs-stuff.patch > > aacraid-rename-check_reset.patch > > scsi-dont-build-scsi_dma_mapunmap-for-has_dma.patch > > drivers-scsi-small-cleanups.patch > >

[PATCH] Cleanup sni_53c710

- base address is now a physical address; no need to convert it - remove not needed error printk in module init function Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]> --- diff --git a/drivers/scsi/sni_53c710.c b/drivers/scsi/sni_53c710.c index a7dfb65..0a6b45b 100644 --- a/drivers/scsi/s

[PATCH] Remove printk, which triggers because of low scsi clock on SNI RMs

remove printk, which triggers because of low scsi clock on SNI RMs Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]> --- diff --git a/drivers/scsi/53c700.c b/drivers/scsi/53c700.c index cb02656..b5ee4b3 100644 --- a/drivers/scsi/53c700.c +++ b/drivers/scsi/53c700.c @@ -267,8 +267,6 @@ NCR_70

[PATCH] Clean up scsi_add_lun a bit

This patch tidies up scsi_add_lun a bit. I rewrote the kerneldoc to match the actual parameters, moved the check for RBC and MMC REPORT_LUN devices away from the switch(), changed the setup of sdev->type to account for BLIST_ISROM, moved the check for BLIST_NO_ULD_ATTACH further down in the funct

[PATCH][BUG] Incorrect SCSI transfer length computation from odd sized scsi_execute_async() transfers.

Any function which use scsi_execute_async() and transfers "odd" sized data that doesn't align correctly with the segment sizes may have its transfer length padded out to the closest segment size. For writes, this results in unnecessary data being transfered to the SCSI target. For reads, it af

Re: [PATCH][BUG] Incorrect SCSI transfer length computation from odd sized scsi_execute_async() transfers.

Jeremy Linton wrote: Any function which use scsi_execute_async() and transfers "odd" sized data that doesn't align correctly with the segment sizes may have its transfer length padded out to the closest segment size. For writes, this results in unnecessary data being transfered to the SCSI ta

Re: [PATCH][BUG] Incorrect SCSI transfer length computation from odd sized scsi_execute_async() transfers.

Mike Christie wrote: I think you needed some other bits in there. See this patch I tried just setting the bufflen first, and that still had problems. Could you try the patch here http://marc.info/?l=linux-scsi&m=117392208211297&w=2 I just read the thread.. I didn't see any strange retries w