Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t
Jens Axboe wrote: > On Thu, Oct 25 2007, Rolf Eike Beer wrote: > > Jens Axboe wrote: > > > On Thu, Oct 25 2007, Rolf Eike Beer wrote: > > > > Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven: > > > > > > Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> > > > > > > --- > > > > > > Whether this is a complete patch, suitable for all architectures, > > > > > > I'm not sure: it builds, boots and runs correctly on the x86_32 > > > > > > box in question, but you'll be a lot wiser than me about using > > > > > > dma_addr_t for everyone. (Seems a bit of a shame to include > > > > > > here, when I think all arches already get to > > > > > > include it one way or another, typically via asm/scatterlist.h; > > > > > > but I guess it's safest to repeat it.) > > > > > > > > > > there is a problem with this... sg_phys doesn't return an actual > > > > > *dma* address at least not an address you can give to the > > > > > device. Using dma_addr_t is thus a bit misleading. > > > > > > > > Ok, then: how do I actually get such an address? > > > > > > You use the dma mapping api, Documentation/DMA-mapping.txt > > > > Which comes back always to the same point: if I get a buffer from > > userspace to use for DMA: what can I do then? I need to convert a > > given list of (physical, pinned) pages to DMA addresses. > > get_user_pages() -> fill in sg table -> pci/dma_map_sg() So the answer to the first question should have been sg_dma_address() ;) Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t
Jens Axboe wrote: > On Thu, Oct 25 2007, Rolf Eike Beer wrote: > > Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven: > > > > Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> > > > > --- > > > > Whether this is a complete patch, suitable for all architectures, > > > > I'm not sure: it builds, boots and runs correctly on the x86_32 box > > > > in question, but you'll be a lot wiser than me about using dma_addr_t > > > > for everyone. (Seems a bit of a shame to include here, > > > > when I think all arches already get to include it one way or another, > > > > typically via asm/scatterlist.h; but I guess it's safest to repeat > > > > it.) > > > > > > there is a problem with this... sg_phys doesn't return an actual *dma* > > > address at least not an address you can give to the device. > > > Using dma_addr_t is thus a bit misleading. > > > > Ok, then: how do I actually get such an address? > > You use the dma mapping api, Documentation/DMA-mapping.txt Which comes back always to the same point: if I get a buffer from userspace to use for DMA: what can I do then? I need to convert a given list of (physical, pinned) pages to DMA addresses. Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 2.6.24-rc1] fix sg_phys to use dma_addr_t
Am Donnerstag, 25. Oktober 2007 schrieb Arjan van de Ven: > > Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> > > --- > > Whether this is a complete patch, suitable for all architectures, > > I'm not sure: it builds, boots and runs correctly on the x86_32 box > > in question, but you'll be a lot wiser than me about using dma_addr_t > > for everyone. (Seems a bit of a shame to include here, > > when I think all arches already get to include it one way or another, > > typically via asm/scatterlist.h; but I guess it's safest to repeat > > it.) > > there is a problem with this... sg_phys doesn't return an actual *dma* > address at least not an address you can give to the device. > Using dma_addr_t is thus a bit misleading. Ok, then: how do I actually get such an address? Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 3/4] [SCSI] ips: PCI API cleanups
Jeff Garzik wrote:
> * pass Scsi_Host to ips_remove_device() via pci_set_drvdata(),
> allowing us to eliminate the ips_ha[] search loop and call
> ips_release() directly.
>
> * call pci_{request,release}_regions() and eliminate individual
> request/release_[mem_]region() calls
>
> * call pci_disable_device(), paired with pci_enable_device()
>
> * s/0/NULL/ in a few places
>
> * check ioremap() return value
> @@ -7036,32 +7042,17 @@ ips_init_phase1(struct pci_dev *pci_dev, int
> *indexPtr) uint32_t base;
> uint32_t offs;
>
> - if (!request_mem_region(mem_addr, mem_len, "ips")) {
> - IPS_PRINTK(KERN_WARNING, pci_dev,
> -"Couldn't allocate IO Memory space %x len
> %d.\n",
> -mem_addr, mem_len);
> - return -1;
> - }
> -
> base = mem_addr & PAGE_MASK;
> offs = mem_addr - base;
> ioremap_ptr = ioremap(base, PAGE_SIZE);
This looks odd. What are we actually doing here?
It seems that we want to map that PCI BAR. Since we're playing with PAGE_MASK
I assume the BAR always has a length
signature.asc
Description: This is a digitally signed message part.
[PATCH] Typo: depricated -> deprecated
Typo: depricated -> deprecated Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> --- commit b7ec07d26c9fd915fd32b759aa05a1ead8c432f5 tree 6f6dafac4072fddd670a97f68cbd64bf505d0408 parent 43dcafe3f7bfc07bdaf55d353fd4c5112c5f2be6 author Rolf Eike Beer <[EMAIL PROTECTED]> Sun, 07 Oct 2007 10:29:39 +0200 committer Rolf Eike Beer <[EMAIL PROTECTED]> Sun, 07 Oct 2007 10:29:39 +0200 drivers/acpi/Kconfig|2 +- drivers/net/natsemi.c |2 +- drivers/net/tulip/winbond-840.c |2 +- include/linux/cdrom.h |4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 4875f01..efd9690 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -52,7 +52,7 @@ config ACPI_PROCFS depends on PROC_FS ---help--- For backwards compatibility, this option allows - depricated /proc/acpi/ files to exist, even when + deprecated /proc/acpi/ files to exist, even when they have been replaced by functions in /sys. The deprecated files (and their replacements) include: diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c index b47a12d..4df046d 100644 --- a/drivers/net/natsemi.c +++ b/drivers/net/natsemi.c @@ -997,7 +997,7 @@ static int __devinit natsemi_probe1 (struct pci_dev *pdev, a delay. Note that pre-2.0.34 kernels had a cache-alignment bug that made udelay() unreliable. The old method of using an ISA access as a delay, __SLOW_DOWN_IO__, is - depricated. + deprecated. */ #define eeprom_delay(ee_addr) readl(ee_addr) diff --git a/drivers/net/tulip/winbond-840.c b/drivers/net/tulip/winbond-840.c index 5824f6a..2fad782 100644 --- a/drivers/net/tulip/winbond-840.c +++ b/drivers/net/tulip/winbond-840.c @@ -485,7 +485,7 @@ err_out_netdev: a delay. Note that pre-2.0.34 kernels had a cache-alignment bug that made udelay() unreliable. The old method of using an ISA access as a delay, __SLOW_DOWN_IO__, is - depricated. + deprecated. */ #define eeprom_delay(ee_addr) ioread32(ee_addr) diff --git a/include/linux/cdrom.h b/include/linux/cdrom.h index 2b641b1..5394d47 100644 --- a/include/linux/cdrom.h +++ b/include/linux/cdrom.h @@ -76,7 +76,7 @@ (struct cdrom_multisession) */ #define CDROM_GET_MCN 0x5311 /* Obtain the "Universal Product Code" if available (struct cdrom_mcn) */ -#define CDROM_GET_UPC CDROM_GET_MCN /* This one is depricated, +#define CDROM_GET_UPC CDROM_GET_MCN /* This one is deprecated, but here anyway for compatibility */ #define CDROMRESET 0x5312 /* hard-reset the drive */ #define CDROMVOLREAD 0x5313 /* Get the drive's volume setting @@ -506,7 +506,7 @@ struct cdrom_generic_command #define GPMODE_TO_PROTECT_PAGE 0x1d #define GPMODE_CAPABILITIES_PAGE 0x2a #define GPMODE_ALL_PAGES 0x3f -/* Not in Mt. Fuji, but in ATAPI 2.6 -- depricated now in favor +/* Not in Mt. Fuji, but in ATAPI 2.6 -- deprecated now in favor * of MODE_SENSE_POWER_PAGE */ #define GPMODE_CDROM_PAGE 0x0d - 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: Accessing 64-bit BARs
Am Donnerstag, 4. Oktober 2007 schrieb yogeshwar sonawane: > Hello all, > > For accessing memory-mapped 64bit-BAR regions of a PCI card, the > respective BAR regions has to be made accessible to the kernel using > ioremap() function. Then readl()/writel() can be used on the address > returned by ioremap(). You should use pci_iomap() to get an access pointer to the BAR. After this you can access the memory with ioread*() and iowrite*(). See "man pci_iomap(9)" if you build kernel manpages. Greetings, Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 19/30] scsi: Remove explicit casts of [kv]alloc return values in osst driver
Jesper Juhl wrote:
> [kv]alloc() return void *. No need to cast the return value.
> @@ -5756,7 +5756,7 @@ static int osst_probe(struct device *dev)
> write_lock(&os_scsi_tapes_lock);
> if (os_scsi_tapes == NULL) {
> os_scsi_tapes =
> - (struct osst_tape **)kmalloc(osst_max_dev *
> sizeof(struct osst_tape *),
> + kmalloc(osst_max_dev * sizeof(struct osst_tape *),
> GFP_ATOMIC);
> if (os_scsi_tapes == NULL) {
> write_unlock(&os_scsi_tapes_lock);
Three lines later:
for (i=0; i < osst_max_dev; ++i) os_scsi_tapes[i] = NULL;
This wants to be
os_scsi_tapes = kcalloc(osst_max_dev, sizeof(struct osst_tape *), GFP_ATOMIC);
Eike
signature.asc
Description: This is a digitally signed message part.
[PATCH][Doc] Typo: fro -> from
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> --- commit 11a9dc32fadc7fe6722dc62ce84f0e483eb85368 tree bc08486dd569753148b5e09d000866cec4d971d7 parent a3036bca04b4e27427e01ed74fb93b8600595bce author Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 17 Jul 2007 09:54:47 +0200 committer Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 17 Jul 2007 09:54:47 +0200 Documentation/console/console.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/console/console.txt b/Documentation/console/console.txt index d3e1744..877a1b2 100644 --- a/Documentation/console/console.txt +++ b/Documentation/console/console.txt @@ -29,7 +29,7 @@ In newer kernels, the following are also available: If sysfs is enabled, the contents of /sys/class/vtconsole can be examined. This shows the console backends currently registered by the -system which are named vtcon where is an integer fro 0 to 15. Thus: +system which are named vtcon where is an integer from 0 to 15. Thus: ls /sys/class/vtconsole . .. vtcon0 vtcon1 - 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: [Test_Module] Changing brightness in Toshiba notebooks with Phoenix Bios
Am Freitag, 15. Juni 2007 schrieb Renato S. Yamane: > Forwarding from: Toshiba_Linux-Users ([EMAIL PROTECTED]) > > = > I only tested on my Toshiba Satellite Pro A100 and it works. You may want to have a look on the "omnibook" project on http://omnibook.sf.net. Although it's named omnibook it added support for many laptop goodies on my A178. Eike signature.asc Description: This is a digitally signed message part.
[PATCH] Fix typo in include/linux/pci.h
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
---
commit f57463dabf991c306dc43dcf7445ec574484e4ee
tree 37c5d48baf200d7c8d04e506fd8b99217953
parent 58056c2424917e90b86ca11c2c5d3fd35313d7b6
author Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 10 Jul 2007 13:32:29 +0200
committer Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 10 Jul 2007 13:32:29 +0200
include/linux/pci.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 086a0e5..87aa73e 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -313,7 +313,7 @@ struct pci_dynids {
/* */
/** PCI Error Recovery System (PCI-ERS). If a PCI device driver provides
- * a set fof callbacks in struct pci_error_handlers, then that device driver
+ * a set of callbacks in struct pci_error_handlers, then that device driver
* will be notified of PCI bus errors, and will be driven to recovery
* when an error occurs.
*/
-
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][Doc] Document pci_iomap()
This useful interface is hardly mentioned anywhere in the in-tree
documentation.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
---
commit bdf4a23b9b1ff4be79a6f9b863f7203dba2dc808
tree a53c4a6c90e13d55fbf2a0b40cd9676bd9a5d0e5
parent 33738cbb6555861de1dce626c913fad06ce658cc
author Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 10 Jul 2007 11:08:51 +0200
committer Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 10 Jul 2007 11:08:51 +0200
Documentation/DocBook/deviceiobook.tmpl |3 ++-
include/asm-i386/io.h |3 +++
lib/iomap.c | 15 ++-
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/deviceiobook.tmpl
b/Documentation/DocBook/deviceiobook.tmpl
index 90ed23d..c917de6 100644
--- a/Documentation/DocBook/deviceiobook.tmpl
+++ b/Documentation/DocBook/deviceiobook.tmpl
@@ -316,7 +316,8 @@ CPU B: spin_unlock_irqrestore(&dev_lock, flags)
Public Functions Provided
-!Einclude/asm-i386/io.h
+!Iinclude/asm-i386/io.h
+!Elib/iomap.c
diff --git a/include/asm-i386/io.h b/include/asm-i386/io.h
index e797586..c48ef18 100644
--- a/include/asm-i386/io.h
+++ b/include/asm-i386/io.h
@@ -112,6 +112,9 @@ extern void __iomem * __ioremap(unsigned long offset,
unsigned long size, unsign
* writew/writel functions and the other mmio helpers. The returned
* address is not guaranteed to be usable directly as a virtual
* address.
+ *
+ * If the area you are trying to map is a PCI BAR you should have a
+ * look at pci_iomap().
*/
static inline void __iomem * ioremap(unsigned long offset, unsigned long size)
diff --git a/lib/iomap.c b/lib/iomap.c
index a57d262..864f2ec 100644
--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -240,7 +240,20 @@ void ioport_unmap(void __iomem *addr)
EXPORT_SYMBOL(ioport_map);
EXPORT_SYMBOL(ioport_unmap);
-/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
+/**
+ * pci_iomap - create a virtual mapping cookie for a PCI BAR
+ * @dev: PCI device that owns the BAR
+ * @bar: BAR number
+ * @maxlen: length of the memory to map
+ *
+ * Using this function you will get a __iomem address to your device BAR.
+ * You can access it using ioread*() and iowrite*(). These functions hide
+ * the details if this is a MMIO or PIO address space and will just do what
+ * you expect from them in the correct way.
+ *
+ * @maxlen specifies the maximum length to map. If you want to get access to
+ * the complete BAR without checking for its length first, pass %0 here.
+ * */
void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
{
unsigned long start = pci_resource_start(dev, bar);
-
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 4/4][Doc] Document pci_iomap()
This useful interface is hardly mentioned anywhere in the in-tree
documentation.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
---
commit 2cb2450818804edcbcb1486a4df0db06e5d49969
tree 2c53fbd2e0be832767446a8684561200b437a695
parent 288a3f1fd00365669ed9ad725b15ff67004cee0a
author Rolf Eike Beer <[EMAIL PROTECTED]> Mon, 14 Aug 2006 14:20:30 +0200
committer Rolf Eike Beer <[EMAIL PROTECTED]> Mon, 14 Aug 2006 14:20:30 +0200
Documentation/DocBook/deviceiobook.tmpl |1 +
include/asm-i386/io.h |3 +++
lib/iomap.c | 15 ++-
3 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/Documentation/DocBook/deviceiobook.tmpl
b/Documentation/DocBook/deviceiobook.tmpl
index 90ed23d..4f85515 100644
--- a/Documentation/DocBook/deviceiobook.tmpl
+++ b/Documentation/DocBook/deviceiobook.tmpl
@@ -317,6 +317,7 @@ CPU B: spin_unlock_irqrestore(&dev_lock, flags)
Public Functions Provided
!Einclude/asm-i386/io.h
+!Elib/iomap.c
diff --git a/include/asm-i386/io.h b/include/asm-i386/io.h
index b3724fe..e176483 100644
--- a/include/asm-i386/io.h
+++ b/include/asm-i386/io.h
@@ -112,6 +112,9 @@ extern void __iomem * __ioremap(unsigned long offset,
unsigned long size, unsign
* writew/writel functions and the other mmio helpers. The returned
* address is not guaranteed to be usable directly as a virtual
* address.
+ *
+ * If the area you are trying to map is a PCI BAR you should have a
+ * look on pci_iomap().
*/
static inline void __iomem * ioremap(unsigned long offset, unsigned long size)
diff --git a/lib/iomap.c b/lib/iomap.c
index 55689c5..8de891d 100644
--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -202,7 +202,20 @@ void ioport_unmap(void __iomem *addr)
EXPORT_SYMBOL(ioport_map);
EXPORT_SYMBOL(ioport_unmap);
-/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
+/**
+ * pci_iomap - create a virtual mapping cookie for a PCI BAR
+ * @dev: PCI device that owns the BAR
+ * @bar: BAR number
+ * @maxlen: length of the memory to map
+ *
+ * Using this function you will get a __iomem address to your device BAR.
+ * You can access it using ioread*() and iowrite*(). These functions hide
+ * the details if this is a MMIO or PIO address space and will just do what
+ * you expect from them in the correct way.
+ *
+ * @maxlen specifies the maximum length to map. If you want to get access to
+ * the complete BAR without checking for their length first pass %0 here.
+ **/
void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
{
unsigned long start = pci_resource_start(dev, bar);
-
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/4] Initialize filp->private_data only once in em28xx_v4l2_open
Some lines later filp->private_data is initialized to dev again. Since there
are some checks that might fail in the mean time keep the later version.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
---
commit 7103e0b114b01a16d7c1ea71914d5069d974167d
tree 6b976d7ce4e872b32805d7df73dd13b5349d439f
parent 39c068bce1d63f6c1345c1ddfda1841d9fd20c74
author Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 25 Jul 2006 17:55:34 +0200
committer Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 25 Jul 2006 17:55:34 +0200
drivers/media/video/em28xx/em28xx-video.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-video.c
b/drivers/media/video/em28xx/em28xx-video.c
index 2a461dd..b2ae0c8 100644
--- a/drivers/media/video/em28xx/em28xx-video.c
+++ b/drivers/media/video/em28xx/em28xx-video.c
@@ -268,8 +268,6 @@ static int em28xx_v4l2_open(struct inode *inode, struct
file *filp)
if (NULL == dev)
return -ENODEV;
- filp->private_data=dev;
-
em28xx_videodbg("open minor=%d type=%s users=%d\n",
minor,v4l2_type_names[dev->type],dev->users);
-
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 3/4][Doc] Fix typos in fs/sysfs/file.c
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> --- commit 966fef8404d59056d8524bf94d7dff790fe1fa82 tree 1adc274bc9b8e7e420db0b0023c8b70bd294e84e parent 0cbdc367b144a95709852c642a069ed652989520 author Rolf Eike Beer <[EMAIL PROTECTED]> Mon, 21 May 2007 22:55:30 +0200 committer Rolf Eike Beer <[EMAIL PROTECTED]> Mon, 21 May 2007 22:55:30 +0200 fs/sysfs/file.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index b502c71..dcb8e83 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -370,7 +370,7 @@ static int sysfs_release(struct inode * inode, struct file * filp) * again will not get new data, or reset the state of 'poll'. * Reminder: this only works for attributes which actively support * it, and it is not possible to test an attribute from userspace - * to see if it supports poll (Nether 'poll' or 'select' return + * to see if it supports poll (Neither 'poll' nor 'select' return * an appropriate error code). When in doubt, set a suitable timeout value. */ static unsigned int sysfs_poll(struct file *filp, poll_table *wait) - 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 1/4] Use kcalloc() in drivers/video/aty/atyfb_base.c
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
---
commit cc4a7b5dfee25083a6a5741b5b640ae2a1d3aa12
tree a4763216a61fa1501bf9b5dbb60f8860d1620b99
parent dcd9673a1ca36cb084de58f443edf42fd64b186b
author Rolf Eike Beer <[EMAIL PROTECTED]> Mon, 07 Aug 2006 13:36:24 +0200
committer Rolf Eike Beer <[EMAIL PROTECTED]> Mon, 07 Aug 2006 13:36:24 +0200
drivers/video/aty/atyfb_base.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/video/aty/atyfb_base.c b/drivers/video/aty/atyfb_base.c
index 053ff63..6bc51bb 100644
--- a/drivers/video/aty/atyfb_base.c
+++ b/drivers/video/aty/atyfb_base.c
@@ -2995,12 +2995,11 @@ static int __devinit atyfb_setup_sparc(struct pci_dev
*pdev,
/* nothing */ ;
j = i + 4;
- par->mmap_map = kmalloc(j * sizeof(*par->mmap_map), GFP_ATOMIC);
+ par->mmap_map = kcalloc(j, sizeof(*par->mmap_map), GFP_ATOMIC);
if (!par->mmap_map) {
PRINTKE("atyfb_setup_sparc() can't alloc mmap_map\n");
return -ENOMEM;
}
- memset(par->mmap_map, 0, j * sizeof(*par->mmap_map));
for (i = 0, j = 2; i < 6 && pdev->resource[i].start; i++) {
struct resource *rp = &pdev->resource[i];
-
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 0/4] misc patches
This are some random patches I've lying around here. They are not related to each other 1) Use kcalloc() in drivers/video/aty/atyfb_base.c 2) Initialize filp->private_data only once in em28xx_v4l2_open 3) [Doc] Fix typos in fs/sysfs/file.c 4) [Doc] Document pci_iomap() Eike signature.asc Description: This is a digitally signed message part.
Re: Add INPUT support to toshiba_acpi
Renato S. Yamane wrote: > Rolf Eike Beer wrote: > > Richard Hughes wrote: > >> Yes, although this is out of my area or expertise, sorry. > > > > I've looked a bit but can't find any driver interaction of those > > programs. Any further ideas welcome. > > Do you try omnibook driver? > svn export https://svn.sourceforge.net/svnroot/omnibook/omnibook/trunk > > toshiba_acpi don't work on my Toshiba M45-S355 (Toshiba BIOS) and I try > this module above and now I can change brightness writing in > /proc/omnibook/lcd and kpowersave can change brightness too. > > But, is impossible use multimedia keys (play, pause, browser, etc) and > couple keys (fn-fx), because Fn key and Multimedia keys don't is > recognized. Oh wow! Even my Multimedia keys get recognized. Thanks very much for your pointer. Eike signature.asc Description: This is a digitally signed message part.
Re: Add INPUT support to toshiba_acpi
Richard Hughes wrote: > On Tue, 2007-06-26 at 07:03 +0200, Rolf Eike Beer wrote: >> Richard Hughes wrote: >>> On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote: >>>> None of the above keys generated a key event. Neither does >>>> "Brightness down", but it still works. "Brightness up" generates an event >>>> and works. >> >>>> Kpowersave tells me it can't do brightness switching in software >>>> (which works in WinXtraPain). >> >> Yes, I need a special process running for this. Would it be of some >> use if I take a look with IRPtracker on it or is that all you need to >> know? > > Yes, although this is out of my area or expertise, sorry. I've looked a bit but can't find any driver interaction of those programs. Any further ideas welcome. Eike signature.asc Description: This is a digitally signed message part.
Re: Add INPUT support to toshiba_acpi
Richard Hughes wrote: > On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote: > > None of the above keys generated a key event. Neither does "Brightness > > down", but it still works. "Brightness up" generates an event and works. > > Kpowersave tells me it can't do brightness switching in software (which > > works in WinXtraPain). > > Do you know how windows does this? Do you have to load a special > system-try thing to make the keys work? Yes, I need a special process running for this. Would it be of some use if I take a look with IRPtracker on it or is that all you need to know? Eike signature.asc Description: This is a digitally signed message part.
Re: Add INPUT support to toshiba_acpi
Richard Hughes wrote: > On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote: > > None of the above keys generated a key event. Neither does "Brightness > > down", but it still works. "Brightness up" generates an event and works. > > Kpowersave tells me it can't do brightness switching in software (which > > works in WinXtraPain). > > Do you know how windows does this? Do you have to load a special > system-try thing to make the keys work? I'll have a look once I find time to boot Windows. Eike signature.asc Description: This is a digitally signed message part.
Re: [ANNOUNCE] Linux Kernel Tester’s Guide v0.3-rc1
Michal Piotrowski wrote:
> Hi,
>
> We are pleased to announce the availability of "Linux Kernel Tester's
> Guide" v0.3-rc1.
It would be cool if we can get a clickable table of contents. Normally it's
enough to include \usepackage{hyperref} before running pdflatex.
Eike
signature.asc
Description: This is a digitally signed message part.
Re: Add INPUT support to toshiba_acpi
Richard Hughes wrote: > Attached patch adds a kernel thread to do polling on Toshiba hardware. Is there something similar available to support other Toshiba laptops? I own a A110-178 that is not supported by the driver but has a lot of keys that I can't use currently: Fn: -screen zoom (I actually don't care about this one) -S2RAM -S2Disk -Mute* Multimedia: -Browser -Video player -Play/pause -Stop -Forward -Reverse *Mute: it's a bit special. If I use it I can an on screen display (mute/sound) but regardless of which setting is displayed the sound is still there. None of the above keys generated a key event. Neither does "Brightness down", but it still works. "Brightness up" generates an event and works. Kpowersave tells me it can't do brightness switching in software (which works in WinXtraPain). If you need an acpidump or I can do some testing just ask. Eike signature.asc Description: This is a digitally signed message part.
Re: [patch 34/54] Fix roundup_pow_of_two(1)
Chris Wright wrote: > * Theodore Tso ([EMAIL PROTECTED]) wrote: > > If this doesn't fix a user-visiable bug, should we be including it in > > the stable patch series? (Assuming that it doesn't, I wouldn't, but I > > tend to be more conservative about what I would include in a stable > > production release.) > > Rolf, despite simplicity of patch, I'm inclined to agree with Ted. > Were you effected by this in the wild, or just noticed by code > inspection? Code inspection. Drop it if you like, it's in mainline already. signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Fix roundup_pow_of_two(1)
Adrian Bunk wrote: > On Thu, May 17, 2007 at 11:56:56PM +0200, Rolf Eike Beer wrote: > > Fix roundup_pow_of_two(1) > > > > 1 is a power of two, therefore roundup_pow_of_two(1) should return 1. It > > does in case the argument is a variable but in case it's a constant it > > behaves wrong and returns 0. Probably nobody ever did it so this was > > never noticed. > > I'm not getting the problem. > 2^0 = 1 Yes. But it returned 0 (not 1 << 0). Eike signature.asc Description: This is a digitally signed message part.
Re: [BUG] Warning in mm/slab.c:777
You wrote: > Also sprach Rolf Eike Beer <[EMAIL PROTECTED]> (Sat, 26 May 2007 08:48:55 +0200): > > After bootup (runlevel 5) I found this in dmesg: > > > > WARNING: at mm/slab.c:777 __find_general_cachep() > > [] __kmalloc+0x40/0xc3 > > [] drm_rmdraw+0x126/0x24e [drm] > > [] skb_dequeue+0x39/0x3f > > [] drm_rmdraw+0x0/0x24e [drm] > > [] drm_ioctl+0x14c/0x192 [drm] > > [] do_ioctl+0x4c/0x62 > > [] vfs_ioctl+0x237/0x249 > > [] mntput_no_expire+0x11/0x68 > > [] sys_ioctl+0x4c/0x65 > > [] sysenter_past_esp+0x5f/0x85 > > === > > > > Kernel is Linus' git of yesterday, the first occurence of this in my logs > > was on May 16th. > > It may be the same zero request I hit in slub, and according to > http://bugzilla.kernel.org/show_bug.cgi?id=8476 people care about. Also > I remember a mail from Linus, where he meant it's handled quite well > (currently no link cause fetching thze whole IMAP quite takes some > time, sry). Thank you for your information. It may be the same alloc, but it's independent of SLUB: CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set Eike signature.asc Description: This is a digitally signed message part.
[BUG] Warning in mm/slab.c:777
After bootup (runlevel 5) I found this in dmesg: WARNING: at mm/slab.c:777 __find_general_cachep() [] __kmalloc+0x40/0xc3 [] drm_rmdraw+0x126/0x24e [drm] [] skb_dequeue+0x39/0x3f [] drm_rmdraw+0x0/0x24e [drm] [] drm_ioctl+0x14c/0x192 [drm] [] do_ioctl+0x4c/0x62 [] vfs_ioctl+0x237/0x249 [] mntput_no_expire+0x11/0x68 [] sys_ioctl+0x4c/0x65 [] sysenter_past_esp+0x5f/0x85 === Kernel is Linus' git of yesterday, the first occurence of this in my logs was on May 16th. Greetings, Eike signature.asc Description: This is a digitally signed message part.
[Doc] spelling fix for fs/sysfs/file.c
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> --- commit 966fef8404d59056d8524bf94d7dff790fe1fa82 tree 1adc274bc9b8e7e420db0b0023c8b70bd294e84e parent 0cbdc367b144a95709852c642a069ed652989520 author Rolf Eike Beer <[EMAIL PROTECTED]> Mon, 21 May 2007 22:55:30 +0200 committer Rolf Eike Beer <[EMAIL PROTECTED]> Mon, 21 May 2007 22:55:30 +0200 fs/sysfs/file.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index b502c71..dcb8e83 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -370,7 +370,7 @@ static int sysfs_release(struct inode * inode, struct file * filp) * again will not get new data, or reset the state of 'poll'. * Reminder: this only works for attributes which actively support * it, and it is not possible to test an attribute from userspace - * to see if it supports poll (Nether 'poll' or 'select' return + * to see if it supports poll (Neither 'poll' nor 'select' return * an appropriate error code). When in doubt, set a suitable timeout value. */ static unsigned int sysfs_poll(struct file *filp, poll_table *wait) - 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] MM: use DIV_ROUND_UP() in mm/memory.c
Replace a hand coded version of DIV_ROUND_UP(). Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED] --- commit ab35916f807eb4f2019a208e96cb0bddbb91dfc3 tree 6dc4485902c1a96a09ed287270de108630b26719 parent 335aa0289219ca2c1dc309d6bf856d4b25ad8746 author Rolf Eike Beer <[EMAIL PROTECTED]> Thu, 17 May 2007 23:03:06 +0200 committer Rolf Eike Beer <[EMAIL PROTECTED]> Thu, 17 May 2007 23:03:06 +0200 mm/memory.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mm/memory.c b/mm/memory.c index cb94488..5bc26b7 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -2674,7 +2674,7 @@ int make_pages_present(unsigned long addr, unsigned long end) write = (vma->vm_flags & VM_WRITE) != 0; BUG_ON(addr >= end); BUG_ON(end > vma->vm_end); - len = (end+PAGE_SIZE-1)/PAGE_SIZE-addr/PAGE_SIZE; + len = DIV_ROUND_UP(end, PAGE_SIZE) - addr/PAGE_SIZE; ret = get_user_pages(current, current->mm, addr, len, write, 0, NULL, NULL); if (ret < 0) - 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] MM: use DIV_ROUND_UP() in mm/memory.c
Andrew Morton wrote:
> Rolf Eike Beer wrote:
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -1838,12 +1838,11 @@ void unmap_mapping_range(struct address_space
>> *mapping,
>> {
>> struct zap_details details;
>> pgoff_t hba = holebegin >> PAGE_SHIFT;
>> -pgoff_t hlen = (holelen + PAGE_SIZE - 1) >> PAGE_SHIFT;
>> +pgoff_t hlen = DIV_ROUND_UP(holelen, PAGE_SIZE);
>>
>> /* Check for overflow. */
>> if (sizeof(holelen) > sizeof(hlen)) {
>> -long long holeend =
>> -(holebegin + holelen + PAGE_SIZE - 1) >> PAGE_SHIFT;
>> +long long holeend = DIV_ROUND_UP(holebegin + holelen,
>> PAGE_SIZE);
>> if (holeend & ~(long long)ULONG_MAX)
>> hlen = ULONG_MAX - hba + 1;
>> }
>> @@ -2592,7 +2591,7 @@ int make_pages_present(unsigned long addr, unsigned
>> long end)
>> write = (vma->vm_flags & VM_WRITE) != 0;
>> BUG_ON(addr >= end);
>> BUG_ON(end > vma->vm_end);
>> -len = (end+PAGE_SIZE-1)/PAGE_SIZE-addr/PAGE_SIZE;
>> +len = DIV_ROUND_UP(end, PAGE_SIZE) - addr/PAGE_SIZE;
>> ret = get_user_pages(current, current->mm, addr,
>> len, write, 0, NULL, NULL);
>> if (ret < 0)
>
> More seriously, on i386:
>
>textdata bss dec hex filename
> 15509 27 28 155643ccc mm/memory.o (before)
> 15561 27 28 156163d00 mm/memory.o (after)
>
> I'm not sure why - some of the quantities which we're dividing by there are
> 64-bit and perhaps the compiler has decided not to do shifting.
>
> Now I'm worried about all the other DIV_ROUND_UP() conversions we did. We
> should get in there and work out why it went bad.
It's the first two places that cause the increase in code size. The last one
is the exact replacement of how DIV_ROUND_UP() is defined so that can hardly
make a difference.
If the compiler can't find out to do shifting we might want to improve
DIV_ROUND_UP() to do some tricks with __builtin_constant_p() to do the shift.
Something like:
#define DIV_ROUND_UP(n, d) \
( \
__builtin_constant_p(d) ? ( \
is_power_of_2(d) ? \
(((n) + (d) - 1) >> ilog2(d)) : \
(((n) + (d) - 1) / (d)) \
) : \
(((n) + (d) - 1) / (d)) \
)
With this version mm/memory.o will result in the same size with and without my
patch so I guess it's doing what it should. If you like it tell me and I'll
send a patch.
Eike
signature.asc
Description: This is a digitally signed message part.
[PATCH] Fix roundup_pow_of_two(1)
Fix roundup_pow_of_two(1) 1 is a power of two, therefore roundup_pow_of_two(1) should return 1. It does in case the argument is a variable but in case it's a constant it behaves wrong and returns 0. Probably nobody ever did it so this was never noticed. Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> --- commit 01ceeffac83011f0b5021013cc4abd1c4f291df5 tree 7da59df51617d7cebd55e4361019181645a17e10 parent ab35916f807eb4f2019a208e96cb0bddbb91dfc3 author Rolf Eike Beer <[EMAIL PROTECTED]> Thu, 17 May 2007 23:43:54 +0200 committer Rolf Eike Beer <[EMAIL PROTECTED]> Thu, 17 May 2007 23:43:54 +0200 include/linux/log2.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/log2.h b/include/linux/log2.h index 57e641e..1b8a2c1 100644 --- a/include/linux/log2.h +++ b/include/linux/log2.h @@ -159,7 +159,7 @@ unsigned long __roundup_pow_of_two(unsigned long n) #define roundup_pow_of_two(n) \ ( \ __builtin_constant_p(n) ? ( \ - (n == 1) ? 0 : \ + (n == 1) ? 1 : \ (1UL << (ilog2((n) - 1) + 1)) \ ) : \ __roundup_pow_of_two(n) \ - 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/
[DOC] Fix wrong identifier name in Documentation/driver-model/devres.txt
Above and below we talk about my_midlayer_create_something, I assume that is also meant here. Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> --- commit bb5f6ef5bbbdc0233690fe3ba6d5787a6aab9b33 tree cd948e03b4add89be6e648d31b7778c64a51e8d2 parent 64aa7c3136258d3abc76354b5f83b9a9575169c0 author Rolf Eike Beer <[EMAIL PROTECTED]> Thu, 26 Apr 2007 09:23:39 +0200 committer Rolf Eike Beer <[EMAIL PROTECTED]> Thu, 26 Apr 2007 09:23:39 +0200 Documentation/driver-model/devres.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 5163b85..6c8d8f2 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -182,7 +182,7 @@ For example, you can do something like the following. ... - devres_close_group(dev, my_midlayer_something); + devres_close_group(dev, my_midlayer_create_something); return 0; } - 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/
Removing VM_LOCKED from user memory
Hi, I need some assistance handling a large memory segment of a user process. The user calls the kernel with a address and a length of it's own memory. My driver will lock this memory using get_user_pages(). This memory is used as DMA buffer directly from or to user processes. Everything works fine that far: allocating, DMA mapping, DMA transfers. But I currently can't get rid of the buffer again. Which function would help me to get all pages unlocked once the buffer isn't needed anymore? Is it enough to simply call sys_munlock() from the release and cleanup functions? There are no plans to share these mappings between different processes. Greetings, Eike signature.asc Description: This is a digitally signed message part.
[PATCH] MM: use DIV_ROUND_UP() in mm/memory.c
This should make no difference in behaviour.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
---
commit 64aa7c3136258d3abc76354b5f83b9a9575169c0
tree 8037adc04b57cd6150456399b7caccf99489385a
parent bf0bd376f79cadb4f8cd454db1723eb9be0aabc1
author Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 24 Apr 2007 16:05:40 +0200
committer Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 24 Apr 2007 16:05:40
+0200
mm/memory.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index e7066e7..45bba1f 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1838,12 +1838,11 @@ void unmap_mapping_range(struct address_space
*mapping,
{
struct zap_details details;
pgoff_t hba = holebegin >> PAGE_SHIFT;
- pgoff_t hlen = (holelen + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ pgoff_t hlen = DIV_ROUND_UP(holelen, PAGE_SIZE);
/* Check for overflow. */
if (sizeof(holelen) > sizeof(hlen)) {
- long long holeend =
- (holebegin + holelen + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ long long holeend = DIV_ROUND_UP(holebegin + holelen,
PAGE_SIZE);
if (holeend & ~(long long)ULONG_MAX)
hlen = ULONG_MAX - hba + 1;
}
@@ -2592,7 +2591,7 @@ int make_pages_present(unsigned long addr, unsigned long
end)
write = (vma->vm_flags & VM_WRITE) != 0;
BUG_ON(addr >= end);
BUG_ON(end > vma->vm_end);
- len = (end+PAGE_SIZE-1)/PAGE_SIZE-addr/PAGE_SIZE;
+ len = DIV_ROUND_UP(end, PAGE_SIZE) - addr/PAGE_SIZE;
ret = get_user_pages(current, current->mm, addr,
len, write, 0, NULL, NULL);
if (ret < 0)
-
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] EXPORT_SYMBOL() time functions
Christoph Hellwig wrote: > On Wed, Feb 21, 2007 at 02:13:38PM +0100, Rolf Eike Beer wrote: > > These functions were inlines before > > 8b9365d753d9870bb6451504c13570b81923228f. Now EXPORT_SYMBOL() them to > > allow them to be used in modules again. > > Just because they happened to be inlined that doesn't mean modules should > be using them. In fact no intree module uses them exactly because they're > not intended to be used by this kind of code. Please show the code you > want to use this for so we can see what you're really trying to do. Trying to convert a given user value (in milliseconds) to a timeout. No problem doing this with struct timespec. Eike pgpzZU2hCFZ61.pgp Description: PGP signature
Re: [PATCH] EXPORT_SYMBOL() time functions
Arjan van de Ven wrote: > On Wed, 2007-02-21 at 14:12 +0100, Rolf Eike Beer wrote: > > These functions were inlines before > > 8b9365d753d9870bb6451504c13570b81923228f. Now EXPORT_SYMBOL() them to > > allow them to be used in modules again. > > please do not add random exports without users; exports eat up kernel > size and memory. At minimum specify which mainline modules use the > exports.. Nothing in mainline now. I just found out that the module I'm writing doesn't work anymore as timeval_to_jiffies() disappeared. If this is planned to go away from modules I should consider switching to timespec. Eike pgpk4J9C51SGQ.pgp Description: PGP signature
[PATCH] EXPORT_SYMBOL() time functions
These functions were inlines before 8b9365d753d9870bb6451504c13570b81923228f.
Now EXPORT_SYMBOL() them to allow them to be used in modules again.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
---
Sent once again, this time without PGP signature so importing into git is
easier.
commit 0a543599f4a9ea02b587bda26e0e11ae94774f61
tree aa815eab413d2575925b0964a1fa01d41439b26b
parent 6b8afc66b9d6893d3fa292b75769b58539836ff3
author Rolf Eike Beer <[EMAIL PROTECTED]> Wed, 21 Feb 2007 14:10:12 +0100
committer Rolf Eike Beer <[EMAIL PROTECTED]> Wed, 21 Feb 2007 14:10:12 +0100
kernel/time.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/kernel/time.c b/kernel/time.c
index c6c80ea..0b351b2 100644
--- a/kernel/time.c
+++ b/kernel/time.c
@@ -635,6 +635,7 @@ timeval_to_jiffies(const struct timeval *value)
(((u64)usec * USEC_CONVERSION + USEC_ROUND) >>
(USEC_JIFFIE_SC - SEC_JIFFIE_SC))) >> SEC_JIFFIE_SC;
}
+EXPORT_SYMBOL(timeval_to_jiffies);
void jiffies_to_timeval(const unsigned long jiffies, struct timeval *value)
{
@@ -649,6 +650,7 @@ void jiffies_to_timeval(const unsigned long jiffies, struct
timeval *value)
tv_usec /= NSEC_PER_USEC;
value->tv_usec = tv_usec;
}
+EXPORT_SYMBOL(jiffies_to_timeval);
/*
* Convert jiffies/jiffies_64 to clock_t and back.
@@ -723,6 +725,7 @@ u64 nsec_to_clock_t(u64 x)
#endif
return x;
}
+EXPORT_SYMBOL(nsec_to_clock_t);
#if (BITS_PER_LONG < 64)
u64 get_jiffies_64(void)
-
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] EXPORT_SYMBOL() time functions
These functions were inlines before 8b9365d753d9870bb6451504c13570b81923228f.
Now EXPORT_SYMBOL() them to allow them to be used in modules again.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
---
commit 0a543599f4a9ea02b587bda26e0e11ae94774f61
tree aa815eab413d2575925b0964a1fa01d41439b26b
parent 6b8afc66b9d6893d3fa292b75769b58539836ff3
author Rolf Eike Beer <[EMAIL PROTECTED]> Wed, 21 Feb 2007 14:10:12 +0100
committer Rolf Eike Beer <[EMAIL PROTECTED]> Wed, 21 Feb 2007 14:10:12 +0100
kernel/time.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/kernel/time.c b/kernel/time.c
index c6c80ea..0b351b2 100644
--- a/kernel/time.c
+++ b/kernel/time.c
@@ -635,6 +635,7 @@ timeval_to_jiffies(const struct timeval *value)
(((u64)usec * USEC_CONVERSION + USEC_ROUND) >>
(USEC_JIFFIE_SC - SEC_JIFFIE_SC))) >> SEC_JIFFIE_SC;
}
+EXPORT_SYMBOL(timeval_to_jiffies);
void jiffies_to_timeval(const unsigned long jiffies, struct timeval *value)
{
@@ -649,6 +650,7 @@ void jiffies_to_timeval(const unsigned long jiffies, struct
timeval *value)
tv_usec /= NSEC_PER_USEC;
value->tv_usec = tv_usec;
}
+EXPORT_SYMBOL(jiffies_to_timeval);
/*
* Convert jiffies/jiffies_64 to clock_t and back.
@@ -723,6 +725,7 @@ u64 nsec_to_clock_t(u64 x)
#endif
return x;
}
+EXPORT_SYMBOL(nsec_to_clock_t);
#if (BITS_PER_LONG < 64)
u64 get_jiffies_64(void)
pgptlQoaEVqET.pgp
Description: PGP signature
[PATCH 1/2][IPX] Remove outdated information from Kconfig
SPX was removed in early 2.5. How to connect to a Mac or the other OS isn't hard to find out these days. Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> --- commit 0566e9a5f19ca9fe1982e2b4a89aff131cc6525b tree 20b72b4e347a0ff926f82188bb296c2b3a8911f5 parent ce4e52a8be675c1724fa3af503ff1c75478ff2e8 author Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 20 Feb 2007 19:43:37 +0100 committer Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 20 Feb 2007 19:43:37 +0100 net/ipx/Kconfig |6 +- 1 files changed, 1 insertions(+), 5 deletions(-) diff --git a/net/ipx/Kconfig b/net/ipx/Kconfig index 980a826..e9ad006 100644 --- a/net/ipx/Kconfig +++ b/net/ipx/Kconfig @@ -16,8 +16,7 @@ config IPX support", below. IPX is similar in scope to IP, while SPX, which runs on top of IPX, - is similar to TCP. There is also experimental support for SPX in - Linux (see "SPX networking", below). + is similar to TCP. To turn your Linux box into a fully featured NetWare file server and IPX router, say Y here and fetch either lwared from @@ -26,9 +25,6 @@ config IPX information, read the IPX-HOWTO available from <http://www.tldp.org/docs.html#howto>. - General information about how to connect Linux, Windows machines and - Macs is on the WWW at <http://www.eats.com/linux_mac_win.html>. - The IPX driver would enlarge your kernel by about 16 KB. To compile this driver as a module, choose M here: the module will be called ipx. Unless you want to integrate your Linux box with a local Novell - 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/2][IPX] Remove ancient changelog
[IPX] Remove ancient changelog Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> --- commit 6b8afc66b9d6893d3fa292b75769b58539836ff3 tree 9078513bb6727e61aee238da153d9b3358a1d817 parent 0566e9a5f19ca9fe1982e2b4a89aff131cc6525b author Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 20 Feb 2007 19:45:03 +0100 committer Rolf Eike Beer <[EMAIL PROTECTED]> Tue, 20 Feb 2007 19:45:03 +0100 net/ipx/ChangeLog | 101 - 1 files changed, 0 insertions(+), 101 deletions(-) diff --git a/net/ipx/ChangeLog b/net/ipx/ChangeLog deleted file mode 100644 index 3b29763..000 --- a/net/ipx/ChangeLog +++ /dev/null @@ -1,101 +0,0 @@ - Revision 0.21:Uses the new generic socket option code. - - Revision 0.22:Gcc clean ups and drop out device registration. Use the - new multi-protocol edition of hard_header - - Revision 0.23: IPX /proc by Mark Evans. Adding a route will - will overwrite any existing route to the same network. - - Revision 0.24:Supports new /proc with no 4K limit - - Revision 0.25:Add ephemeral sockets, passive local network - identification, support for local net 0 and - multiple datalinks - - Revision 0.26: Device drop kills IPX routes via it. (needed for module) - - Revision 0.27: Autobind - - Revision 0.28: Small fix for multiple local networks - - Revision 0.29: Assorted major errors removed - Small correction to promisc mode error fix - Asynchronous I/O support. Changed to use notifiers - and the newer packet_type stuff. Assorted major - fixes - - Revision 0.30:Moved to net/ipx/... - Don't set address length on recvfrom that errors. - Incorrect verify_area. - - Revision 0.31:New sk_buffs. This still needs a lot of - testing. - - Revision 0.32: Using sock_alloc_send_skb, firewall hooks. - Supports sendmsg/recvmsg - - Revision 0.33:Internal network support, routing changes, uses a - protocol private area for ipx data. - - Revision 0.34:Module support. - - Revision 0.35: Checksum support. , hooked in by - Handles WIN95 discovery packets - - Revision 0.36:Internal bump up for 2.1 - - Revision 0.37:Began adding POSIXisms. - - Revision 0.38: Asynchronous socket stuff made current. - - Revision 0.39: SPX interfaces - - Revision 0.40: Tiny SIOCGSTAMP fix ([EMAIL PROTECTED]) - - Revision 0.41: 802.2TR removed ([EMAIL PROTECTED]) - Fixed connecting to primary net, - Automatic binding on send & receive, - Martijn van Oosterhout <[EMAIL PROTECTED]> - - Revision 042: Multithreading - use spinlocks and refcounting to - protect some structures: ipx_interface sock list, list - of ipx interfaces, etc. - Bugfixes - do refcounting on net_devices, check function - results, etc. Thanks to davem and freitag for - suggestions and guidance. - Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>, - November, 2000 - - Revision 043: Shared SKBs, don't mangle packets, some cleanups - Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>, - December, 2000 - - Revision 044: Call ipxitf_hold on NETDEV_UP - acme - - Revision 045: fix PPROP routing bug - acme - - Revision 046: Further fixes to PPROP, ipxitf_create_internal was - doing an unneeded MOD_INC_USE_COUNT, implement - sysctl for ipx_pprop_broacasting, fix the ipx sysctl - handling, making it dynamic, some cleanups, thanks to - Petr Vandrovec for review and good suggestions. (acme) - - Revision 047: Cleanups, CodingStyle changes, move the ncp connection - hack out of line - acme - - Revision 048: Use sk->protinfo to store the pointer to IPX private - area, remove af_ipx from sk->protinfo and move ipx_opt - to include/net/ipx.h, use IPX_SK like DecNET, etc - acme - - Revision 049: SPX support dropped, see comment in ipx_create - acme - - Revision 050: Use seq_file for proc stuff, moving it to ipx_proc.c - acme - -Other fixes: - - Protect the module by a MOD_INC_USE_COUNT/MOD_DEC_USE_COUNT pair. Also, now - usage count is managed this way: - -Count one if the auto_interface mode is on - -Count one per configured interface - - Jacques Gelinas ([EMAIL PROTECTED]) - 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 0/2] Remove outdated information from IPX
Who cares about stuff describing what happened in early 2.5 days? Even worse is to reference Kconfig options removed back then. Go, rest in pieces. Eike pgpjdAVzZTifL.pgp Description: PGP signature
Re: [BUG?] register_blkdev: failed to get major for device mapper
Am Montag, 19. Februar 2007 schrieben Sie:
> On Mon, 19 Feb 2007 15:39:38 +0100 Rolf Eike Beer <[EMAIL PROTECTED]>
wrote:
> > > It's totally weird. It prints the "skipped" message for every (!)
> > > number, not just for the blacklisted ones. And I've triple checked that
> > > I don't have missed the '{'.
> > >
> > > Compiler is SuSEs 4.1.0 from their 10.1. I remember some rumors that
> > > this thing is just broken?
> >
> > Ok, I'm using the compiler from SuSE 10.2 now and it works. Time that we
> > refuse to build if it's a 4.1.0.
>
> argh, I was down to suspecting gcc.
>
> I suppose we can just stir the code around to make it go away. Like this?
Too late, sorry. I've upgraded to 4.1.3 and it works fine now. Maybe I'll find
time to check again but this will take some days.
Eike
pgplkNg9qlaNA.pgp
Description: PGP signature
Re: [BUG?] register_blkdev: failed to get major for device mapper
> Andrew Morton wrote:
> > On Mon, 19 Feb 2007 11:01:02 +0100 Rolf Eike Beer <[EMAIL PROTECTED]>
>
> wrote:
> > > Andrew Morton wrote:
> > > > On Fri, 16 Feb 2007 14:37:28 +0100
> > > >
> > > > Rolf Eike Beer <[EMAIL PROTECTED]> wrote:
> > > > > I can't bring up my machine with root LVM anymore using x86_64. The
> > > > > same machine from same kernel tree boots fine as x86. The error
> > > > > message is quoted in subject. The tree is at
> > > > > 86a71dbd3e81e8870d0f0e56b87875f57e58222b (for those not using git:
> > > > > somewhere after 2.6.20).
> > > >
> > > > Does this fix it? I don't see why it would, but this was recently
> > > > added.
> > >
> > > Yes. But now usb complains "unable to get a dynamic major for usb
> > > endpoints". Nevertheless the USB mouse works.
> >
> > That's just nutty.
> >
> > Can you add this, see what it says just prior to that "unable to get a
> > dynamic major for usb endpoints"?
>
> It's totally weird. It prints the "skipped" message for every (!) number,
> not just for the blacklisted ones. And I've triple checked that I don't
> have missed the '{'.
>
> Compiler is SuSEs 4.1.0 from their 10.1. I remember some rumors that this
> thing is just broken?
Ok, I'm using the compiler from SuSE 10.2 now and it works. Time that we
refuse to build if it's a 4.1.0.
Sorry for the noise.
Eike
pgpyZqMb3zglw.pgp
Description: PGP signature
Re: [BUG?] register_blkdev: failed to get major for device mapper
Andrew Morton wrote:
> On Mon, 19 Feb 2007 11:01:02 +0100 Rolf Eike Beer <[EMAIL PROTECTED]>
wrote:
> > Andrew Morton wrote:
> > > On Fri, 16 Feb 2007 14:37:28 +0100
> > >
> > > Rolf Eike Beer <[EMAIL PROTECTED]> wrote:
> > > > I can't bring up my machine with root LVM anymore using x86_64. The
> > > > same machine from same kernel tree boots fine as x86. The error
> > > > message is quoted in subject. The tree is at
> > > > 86a71dbd3e81e8870d0f0e56b87875f57e58222b (for those not using git:
> > > > somewhere after 2.6.20).
> > >
> > > Does this fix it? I don't see why it would, but this was recently
> > > added.
> >
> > Yes. But now usb complains "unable to get a dynamic major for usb
> > endpoints". Nevertheless the USB mouse works.
>
> That's just nutty.
>
> Can you add this, see what it says just prior to that "unable to get a
> dynamic major for usb endpoints"?
It's totally weird. It prints the "skipped" message for every (!) number, not
just for the blacklisted ones. And I've triple checked that I don't have
missed the '{'.
Compiler is SuSEs 4.1.0 from their 10.1. I remember some rumors that this
thing is just broken?
Eike
pgpUU18H8Yb3X.pgp
Description: PGP signature
Re: [BUG?] register_blkdev: failed to get major for device mapper
Andrew Morton wrote: > On Fri, 16 Feb 2007 14:37:28 +0100 > Rolf Eike Beer <[EMAIL PROTECTED]> wrote: > > I can't bring up my machine with root LVM anymore using x86_64. The same > > machine from same kernel tree boots fine as x86. The error message is > > quoted in subject. The tree is at > > 86a71dbd3e81e8870d0f0e56b87875f57e58222b (for those not using git: > > somewhere after 2.6.20). > > Does this fix it? I don't see why it would, but this was recently added. Yes. But now usb complains "unable to get a dynamic major for usb endpoints". Nevertheless the USB mouse works. Eike pgpKSL6uoxtH1.pgp Description: PGP signature
[BUG?] register_blkdev: failed to get major for device mapper
Hi, I can't bring up my machine with root LVM anymore using x86_64. The same machine from same kernel tree boots fine as x86. The error message is quoted in subject. The tree is at 86a71dbd3e81e8870d0f0e56b87875f57e58222b (for those not using git: somewhere after 2.6.20). Attached are my .config of x86 and x86_64 as well as dmesg of failed boot as captured via serial line. The only other report of this problem dates back to early 2005 (see http://lkml.org/lkml/2005/2/5/29) and was about 2.6.11-rc2-mm2. I successfully have 2.6.18-rc7-something on this machine as x86_64 so it worked in between. Any ideas? Greetings, Eike Linux version 2.6.20-siso1 ([EMAIL PROTECTED]) (gcc version 4.1.0 (SUSE Linux)) #7 SMP Fri Feb 16 11:08:53 CET 2007 Command line: root=/dev/system/root64 console=ttyS0,38400 console=tty0 vga=normal selinux=0 resume=/dev/system/swap splash=verbose showopts BIOS-provided physical RAM map: BIOS-e820: - 0009b000 (usable) BIOS-e820: 0009b000 - 000a (reserved) BIOS-e820: 000e9b60 - 0010 (reserved) BIOS-e820: 0010 - 7ffb (usable) BIOS-e820: 7ffb - 7ffbe000 (ACPI data) BIOS-e820: 7ffbe000 - 7ffe (ACPI NVS) BIOS-e820: 7ffe - 8000 (reserved) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fef0 (reserved) BIOS-e820: ff70 - 0001 (reserved) end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP 000FB650, 0014 (r0 ACPIAM) ACPI: RSDT 7FFB, 0034 (r1 A M I OEMRSDT 3000627 MSFT 97) ACPI: FACP 7FFB0200, 0084 (r2 A M I OEMFACP 3000627 MSFT 97) ACPI: DSDT 7FFB0450, 7E04 (r1 A0350 A03500011 INTL 2002026) ACPI: FACS 7FFBE000, 0040 ACPI: APIC 7FFB0390, 0080 (r1 A M I OEMAPIC 3000627 MSFT 97) ACPI: MCFG 7FFB0410, 003C (r1 A M I OEMMCFG 3000627 MSFT 97) ACPI: OEMB 7FFBE040, 005B (r1 A M I AMI_OEM 3000627 MSFT 97) Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 early_node_map[2] active PFN ranges 0:0 -> 155 0: 256 -> 524208 Nvidia board detected. Ignoring ACPI timer override. If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x508 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored. ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information Nosave address range: 0009b000 - 000a Nosave address range: 000a - 000ea000 Nosave address range: 000ea000 - 0010 Allocating PCI resources starting at 8800 (gap: 8000:7ec0) PERCPU: Allocating 33920 bytes of per cpu data Built 1 zonelists. Total pages: 512835 Kernel command line: root=/dev/system/root64 console=ttyS0,38400 console=tty0 vga=normal selinux=0 resume=/dev/system/swap splash=verbose s Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour VGA+ 80x25 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES:8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS:2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 1648 kB per task-struct memory footprint: 1680 bytes Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Checking aperture... Memory: 2036040k/2096832k available (2574k kernel code, 60004k reserved, 1582k data, 220k init) Calibrating delay using timer specific routine.. 6006.12 BogoMIPS (lpj=12012248) Mount-cache hash table entries: 256 CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 2048K using mwait in idle threads. CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 CPU0: Thermal monitoring enabled (TM1) Freeing SMP alternatives: 24k freed ACPI: Core revision 20070126 Using local APIC timer interrupts. result 12500430 Detected 12.500 MHz APIC timer. lockdep: not fixing up alternatives. Booting processor 1/2 APIC 0x1 Initializing CPU#1 Calibrating delay using timer specific routine.. 6000.83 BogoMIPS (lpj=12001670) CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 20
Re: [patch 3/4] ipmi: add pci remove handling
Am Donnerstag, 15. Februar 2007 schrieb Corey Minyard:
> On Thu, Feb 15, 2007 at 02:27:45AM -0800, Andrew Morton wrote:
> > Judging from the patch headers you were working against 2.6.19, which is
> > most optimistic. Please always prepare and test patches against the
> > latest kernel.
>
> Well, I had it applied against a 2.6.20 kernel, but I messed up the
> testing of it. Sorry, my bad.
>
> New patch...
>
>
> Add pci_remove handling to the driver, so it will clean up if
> the device is hot-removed.
>
> Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>
>
> Index: linux-2.6.20/drivers/char/ipmi/ipmi_si_intf.c
> ===
> --- linux-2.6.20.orig/drivers/char/ipmi/ipmi_si_intf.c
> +++ linux-2.6.20/drivers/char/ipmi/ipmi_si_intf.c
> @@ -2191,12 +2191,15 @@ static int __devinit ipmi_pci_probe(stru
> info->irq_setup = std_irq_setup;
>
> info->dev = &pdev->dev;
> + pdev->dev.driver_data = info;
>
> return try_smi_init(info);
> }
>
> static void __devexit ipmi_pci_remove(struct pci_dev *pdev)
> {
> + struct smi_info *info = pdev->dev.driver_data;
> + cleanup_one_si(info);
> }
Please use pci_{set,get}_drvdata() to access this field.
Greetings,
Eike
pgpZcQ9PcLVW1.pgp
Description: PGP signature
Re: [GIT PATCH] SCSI updates for 2.6.20
James Bottomley wrote: > On Mon, 2007-02-12 at 11:29 +0100, Rolf Eike Beer wrote: > > Am Sonntag, 11. Februar 2007 schrieb James Bottomley: > > > This is the accumulated SCSI tree for 2.6.20. It is available at > > > > > > master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git > > > > You once again have not included this two patches Andrew sent you on > > 20070602: > > > > [patch 08/33] remove extra newline from info message > > This one's waiting on Hannes to ack, since he's working in that driver Ah, thanks. (Added Hannes to CC). > > [patch 09/33] Fix scsi/scsi_transport.h compile error > > I did look at this one, but I can't find a configuration that will > induce a compile error like the header says. It's pending further > investigation. Just try to compile a file that only includes this header. I don't know if there is an existing (in-kernel) configuration where this can go wrong, I found it when hacking a replacement for cpqfcTS. Nevertheless this is still a bug, relying on a specific include order is just wrong. Greetings, Eike pgpbyzTwCkYYk.pgp Description: PGP signature
Re: [GIT PATCH] SCSI updates for 2.6.20
Am Sonntag, 11. Februar 2007 schrieb James Bottomley: > This is the accumulated SCSI tree for 2.6.20. It is available at > > master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git You once again have not included this two patches Andrew sent you on 20070602: [patch 08/33] remove extra newline from info message [patch 09/33] Fix scsi/scsi_transport.h compile error Is this by mistake or intentional? Greetings, Eike pgpEW0vvbYjZ8.pgp Description: PGP signature
Re: [PATCH UPDATED 2.6.20-rc3] Remove all the unneeded k[mzc]alloc casts
Ahmed S. Darwish wrote:
> Hi all,
> This is a patch to remove the unneeded k[mzc]alloc casts in the whole
> 2.6.20-rc3 tree. I tried to put this patch in a patchset but I couldn't
> cause the modified files have nothing in common (except the unneeded casts
> ofcourse).
>
> This patch includes http://lkml.org/lkml/fancy/2007/1/5/12 and
> http://lkml.org/lkml/2007/1/5/6.
>
> Signed-off-by: Ahmed Darwish
>
> diff --git a/arch/cris/arch-v32/mm/intmem.c
> b/arch/cris/arch-v32/mm/intmem.c index 41ee7f7..acb4e21 100644
> --- a/arch/cris/arch-v32/mm/intmem.c
> +++ b/arch/cris/arch-v32/mm/intmem.c
> @@ -27,8 +27,8 @@ static void crisv32_intmem_init(void)
> {
> static int initiated = 0;
> if (!initiated) {
> - struct intmem_allocation* alloc =
> - (struct intmem_allocation*)kmalloc(sizeof *alloc, GFP_KERNEL);
> + struct intmem_allocation* alloc = kmalloc(sizeof *alloc,
> + GFP_KERNEL);
sizeof(*alloc) (see Documentation/CodingStyle)
There are some more of this kind.
Eike
pgpr2XMlyB2V2.pgp
Description: PGP signature
Re: [PATCH 2.6.20-rc3] TTY_IO: Remove unnecessary kmalloc casts
Am Freitag, 5. Januar 2007 11:32 schrieb Ahmed S. Darwish: > On Fri, Jan 05, 2007 at 11:26:07AM +0100, Rolf Eike Beer wrote: > > One big patch for the whole kernel will not work anyway. You have to > > split it up to allow subsystems to integrate them in their own trees. > > With one big patch you would get collisions all over the tree causing the > > complete patch to get dropped. Also CC subsystem maintainers on their > > parts. And please send the patches as replies to the first one as it > > cleans up readability of lkml a lot :) > > Oops, Just read this warning after sending the (big) patch. Sorry It's my > first patch :). I'll split it and do as written. Thanks alot :). That wasn't meant for resending. If you resend the whole series it's good to start a new thread. But if you have several related patches (usually this [PATCH N/xx] thing) it helps if you either send a 0/xx first describing the whole series or at least sending everything as reply to 1/xx. This way the mail program will help everybody by keeping this things together. Eike pgpPIRcT33ff3.pgp Description: PGP signature
Re: [PATCH 2.6.20-rc3] TTY_IO: Remove unnecessary kmalloc casts
Am Freitag, 5. Januar 2007 11:06 schrieb Ahmed S. Darwish:
> On Fri, Jan 05, 2007 at 09:10:01AM +0100, Rolf Eike Beer wrote:
> > Ahmed S. Darwish wrote:
> > > Remove unnecessary kmalloc casts in drivers/char/tty_io.c
> > >
> > > Signed-off-by: Ahmed Darwish <[EMAIL PROTECTED]>
> >
> > if (!*ltp_loc) {
> > - ltp = (struct ktermios *) kmalloc(sizeof(struct ktermios),
> > - GFP_KERNEL);
> > + ltp = kmalloc(sizeof(struct ktermios), GFP_KERNEL);
> > ^^^
> > if (!ltp)
> > goto free_mem_out;
> > memset(ltp, 0, sizeof(struct ktermios));
> > ^^
> > kzalloc
> >
> > if (!*o_ltp_loc) {
> > - o_ltp = (struct ktermios *)
> > - kmalloc(sizeof(struct ktermios), GFP_KERNEL);
> > + o_ltp = kmalloc(sizeof(struct ktermios), GFP_KERNEL);
> > ^^^
> > if (!o_ltp)
> > goto free_mem_out;
> > memset(o_ltp, 0, sizeof(struct ktermios));
> > ^^
> > kzalloc
>
> Currently I'm dropping this patch and writing a big patch to remove all the
> k[mzc]alloc castings in the 20-rc3 tree as suggested by Mr. Robert Day.
One big patch for the whole kernel will not work anyway. You have to split it
up to allow subsystems to integrate them in their own trees. With one big
patch you would get collisions all over the tree causing the complete patch
to get dropped. Also CC subsystem maintainers on their parts. And please send
the patches as replies to the first one as it cleans up readability of lkml a
lot :)
> I think this will be better done in another patch to let every patch do one
> single thing. right ?
Yes. But I would suggest starting with the kmalloc()->kzalloc() things. When
you do this conversions just remove the casts of the lines you're touching.
This will reduce the size of the complete thing avoiding two rather trivial
patches touching the same line twice.
Eike
pgp4FNmC7ldji.pgp
Description: PGP signature
Re: [PATCH 2.6.20-rc3] TTY_IO: Remove unnecessary kmalloc casts
Ahmed S. Darwish wrote:
> Remove unnecessary kmalloc casts in drivers/char/tty_io.c
>
> Signed-off-by: Ahmed Darwish <[EMAIL PROTECTED]>
> if (!*ltp_loc) {
> - ltp = (struct ktermios *) kmalloc(sizeof(struct ktermios),
> - GFP_KERNEL);
> + ltp = kmalloc(sizeof(struct ktermios), GFP_KERNEL);
^^^
> if (!ltp)
> goto free_mem_out;
> memset(ltp, 0, sizeof(struct ktermios));
^^
kzalloc
> if (!*o_ltp_loc) {
> - o_ltp = (struct ktermios *)
> - kmalloc(sizeof(struct ktermios), GFP_KERNEL);
> + o_ltp = kmalloc(sizeof(struct ktermios), GFP_KERNEL);
^^^
> if (!o_ltp)
> goto free_mem_out;
> memset(o_ltp, 0, sizeof(struct ktermios));
^^
kzalloc
HTH
Eike
pgpMg2RKSFpk8.pgp
Description: PGP signature
[PATCH] Add const for time{spec,val}_compare arguments
The arguments are really const. Mark them const to allow these functions
being called from places where the arguments are const without getting
useless compiler warnings.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
---
commit aa6af3ef5a9708b1b81aa4b6b0d30c578ac1b29c
tree 157e65f05bcb7aac859186c944573f5d40935564
parent 213bcc9bc614154948b6f83cbb872ea046557598
author Rolf Eike Beer <[EMAIL PROTECTED]> Wed, 13 Dec 2006 09:46:58 +0100
committer Rolf Eike Beer <[EMAIL PROTECTED]> Wed, 13 Dec 2006 09:46:58 +0100
include/linux/time.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/time.h b/include/linux/time.h
index a5b7399..55cee17 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -46,7 +46,7 @@ static inline int timespec_equal(struct timespec *a, struct
timespec *b)
* lhs == rhs: return 0
* lhs > rhs: return >0
*/
-static inline int timespec_compare(struct timespec *lhs, struct timespec *rhs)
+static inline int timespec_compare(const struct timespec *lhs, const struct
timespec *rhs)
{
if (lhs->tv_sec < rhs->tv_sec)
return -1;
@@ -55,7 +55,7 @@ static inline int timespec_compare(struct timespec *lhs,
struct timespec *rhs)
return lhs->tv_nsec - rhs->tv_nsec;
}
-static inline int timeval_compare(struct timeval *lhs, struct timeval *rhs)
+static inline int timeval_compare(const struct timeval *lhs, const struct
timeval *rhs)
{
if (lhs->tv_sec < rhs->tv_sec)
return -1;
-
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/
WARNING at fs/inotify.c:181
Version is 2.6.19-rc6-git. System was more or less idle, just normal desktop stuff (copying single files by scp, writing mail). Don't know what exactly was working when this happened, I saw it some minutes later. BUG: warning at fs/inotify.c:181/set_dentry_child_flags() [] set_dentry_child_flags+0xcf/0x11c [] remove_watch_no_event+0x53/0x5f [] inotify_remove_watch_locked+0x12/0x3e [] mutex_lock+0x1a/0x29 [] inotify_rm_wd+0x6d/0x8a [] sys_inotify_rm_watch+0x38/0x4f [] syscall_call+0x7/0xb [] xfrm_policy_flush+0x10e/0x180 === Greetings, Eike pgpSRchqACMZP.pgp Description: PGP signature
Re: Interphase Tachyon drivers missing.
Am Mittwoch, 13. Dezember 2006 17:51 schrieb [EMAIL PROTECTED]:
> I'm not sure about the driver being cpqfc, I know in 2.6.0 & 1 the
> driver was definitely iphase.c/h/o
> I do know the chipset was used by almost everyone, Compaq/HP/DEC and
> Interphase's namebrand cards.
>
> I also know that the driver is still working in 2.4.33 my slackware 11
> default kernel picked up the card, which suprised me to say the least...
> I won't have time to spend a weekend on it until about christmas. {or
> probably christmas day is more likely} Even then I can't make any kind
> of promise that I can do anything useful about it...
Ok, than we're likely talking about different things. Maybe just another
driver for that chipset. If I'll ever find some time I'll have a look on this
one too.
Eike
pgpUWGUA5KgfY.pgp
Description: PGP signature
Re: Interphase Tachyon drivers missing.
[EMAIL PROTECTED] wrote: > I went to upgrade my kernel on a couple of boxes yesterday and noticed > that the Interphase Tachyon chipset Fibre Channel driver was removed > from the kernel. I think 2.6.1 was the last one it was still in. Was > there a reason it was pulled? > If not, do I have to volunteer to put it back in or can someone with > more skill re-add it? I suppose you're talking about the cpqfc driver? I have tried to clean it up but gave up. Next try was to rewrite, but due to lack of time there is no progress in the last month. The old driver was that horrible coded that noone can maintain it. It was originally written for something like Linux 2.2 and was never even forward ported completely to 2.4. With the major changes in Linux' driver model that went into 2.6 it was nearly unusable anyway. Not that the use of it in 2.4 can be encouraged. One of the main problems is the severe lack of error handling which you can see alone from the fact that there are tons of function returning void even in the critical I/O-path's. I have heard of at least 3 different people before you (not counting me) that would like to have a driver for this one. One even donated some hardware to me around last christmas. But nevertheless my lack of time stopped my work on this. Martin, you were hacking on something there too but never showed up some code. Is there anything new? Eike pgpDm036KyCaM.pgp Description: PGP signature
[PATCH 2/2] remove driverfs references from init/do_mounts.c
This patch is against 2.6.10, but still applies cleanly. It's just s/driverfs/sysfs/ in this file. Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> --- linux-2.6.10/init/do_mounts.c 2004-12-24 22:34:31.0 +0100 +++ linux-2.6.10/init/do_mounts.c.fixed 2005-01-07 13:42:02.406392368 +0100 @@ -127,10 +127,10 @@ fail: *used when disk name of partitioned disk ends on a digit. * * If name doesn't have fall into the categories above, we return 0. - * Driverfs is used to check if something is a disk name - it has + * Sysfs is used to check if something is a disk name - it has * all known disks under bus/block/devices. If the disk name - * contains slashes, name of driverfs node has them replaced with - * bangs. try_name() does the actual checks, assuming that driverfs + * contains slashes, name of sysfs node has them replaced with + * bangs. try_name() does the actual checks, assuming that sysfs * is mounted on rootfs /sys. */ - 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 0/2] driverfs is dead
This little patch series removes some references to driverfs, which is called sysfs for a long time. No code changes, this is all in comments. Please apply, Eike pgpCxirxymsMh.pgp Description: PGP signature
[PATCH 1/2] remove driverfs references from include/linux/cpu.h and net/sunrpc/rpc_pipe.c
This patch is against 2.6.10, but still applies cleanly. It's just s/driverfs/sysfs/ in these two files. Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> --- linux-2.6.10/include/linux/cpu.h2005-01-01 17:55:38.0 +0100 +++ linux-2.6.10/include/linux/cpu.h.fixed 2005-01-07 13:55:36.167681848 +0100 @@ -8,7 +8,7 @@ * Basic handling of the devices is done in drivers/base/cpu.c * and system devices are handled in drivers/base/sys.c. * - * CPUs are exported via driverfs in the class/cpu/devices/ + * CPUs are exported via sysfs in the class/cpu/devices/ * directory. * * Per-cpu interfaces can be implemented using a struct device_interface. --- linux-2.6.10/net/sunrpc/rpc_pipe.c 2005-01-01 17:55:50.0 +0100 +++ linux-2.6.10/net/sunrpc/rpc_pipe.c.fixed2005-01-07 14:01:05.373634936 +0100 @@ -3,7 +3,7 @@ * * Userland/kernel interface for rpcauth_gss. * Code shamelessly plagiarized from fs/nfsd/nfsctl.c - * and fs/driverfs/inode.c + * and fs/sysfs/inode.c * * Copyright (c) 2002, Trond Myklebust <[EMAIL PROTECTED]> * - 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: rc5 seemed to kill a disk that rc4-mm1 likes. Also some X trouble.
Linus Torvalds wrote: >On Mon, 22 Aug 2005, Rolf Eike Beer wrote: >> >It's a PII-350 with more or less SuSE 9.3. The machine has no net access, >> > so I can only try to narrow it down to one rc at the weekend. >> >> 2.6.12 works fine, everything since 2.6.13-rc1 breaks it. > >Gaah. I don't see anything really obvious in that range. However, I notice >that pci_mmap_resource() (in drivers/pci/pci-sysfs.c) now has > >+ if (i >= PCI_ROM_RESOURCE) >+ return -ENODEV; > >which seems a big bogus. Why wouldn't we allow the ROM resource to be >mapped? I could imagine that the X server would very much like to mmap it, >although I don't know if modern X actually does that. The fact that it >works when root runs the X server and causes problems for normal users >does seem like there's something that root can do that users can't do, and >doing a mmap() on /dev/mem might be just that. > >Eike, maybe you could change the ">=" to just ">" instead? > >PS. The patch that introduced this was billed as "no change for anything >but ppc". Tssk. This does not fix the problem. I'll narrow it down to one git snapshot next weekend (forgot the tarball on friday). Eike pgpHIQwK2yx47.pgp Description: PGP signature
Re: rc5 seemed to kill a disk that rc4-mm1 likes. Also some X trouble.
Linus Torvalds wrote: >On Mon, 22 Aug 2005, Rolf Eike Beer wrote: >> >It's a PII-350 with more or less SuSE 9.3. The machine has no net access, >> > so I can only try to narrow it down to one rc at the weekend. >> >> 2.6.12 works fine, everything since 2.6.13-rc1 breaks it. > >Gaah. I don't see anything really obvious in that range. However, I notice >that pci_mmap_resource() (in drivers/pci/pci-sysfs.c) now has > >+ if (i >= PCI_ROM_RESOURCE) >+ return -ENODEV; > >which seems a big bogus. Why wouldn't we allow the ROM resource to be >mapped? I could imagine that the X server would very much like to mmap it, >although I don't know if modern X actually does that. The fact that it >works when root runs the X server and causes problems for normal users >does seem like there's something that root can do that users can't do, and >doing a mmap() on /dev/mem might be just that. No, it's a bit more obscure. The kdm daemon does not start, but if I log in as user and do startx everything is fine. >Eike, maybe you could change the ">=" to just ">" instead? Will test this. Eike pgpVdmGAnAqtO.pgp Description: PGP signature
Re: rc5 seemed to kill a disk that rc4-mm1 likes. Also some X trouble.
>Helge Hafting wrote: >>Dave Airlie wrote: >>> I switched back to 2.6.13-rc4-mm1 at this point for another reason, >>> my X display aquired a nasty tendency to go blank for no reason >>> during work, >>> something I could fix by changing resolution baqck and forth. X >>> also tended to get >>> stuck for a minute now and then - a problem I haven't seen since >>> early 2.6. >>> >>> >>> >>> which head the radeon or MGA or both? >> >>The radeon 9200SE-pci gets stuck. The MGA-agp seems to be fine. I have >>compiled >>dri support for both, but I can't use it at the moment. I think that is >>caused by having ubuntu's xorg installed on debian. I needed xorg >>in order to run an xserver that doesn't use any tty - this way I can use >>two keyboards and have two simultaneous users. Debians xorg wasn't ready >>at the moment. The setup is fine with 2.6.13-rc4-mm1 x86-64, no problems >>there. > >I have some other issue with a MGA card (don't know exactly which, I have > only access to this on the weekend). With rc5 and rc6 kdm will not start on > bootup, X complains about some unresolved symbols in the X mga driver. If I > log in as user and do startx it works fine, also if I switch back to > 2.6.12-rc-something. Something seems to confuse X somehow. > >It's a PII-350 with more or less SuSE 9.3. The machine has no net access, so > I can only try to narrow it down to one rc at the weekend. 2.6.12 works fine, everything since 2.6.13-rc1 breaks it. Eike pgp6z17GgLau3.pgp Description: PGP signature
Re: [Fwd: help with PCI hotplug and a PCI device enabled after boot]
Mauro Carvalho Chehab wrote: >Em Qua, 2005-08-17 Ã s 13:15 +0200, Rolf Eike Beer escreveu: >> Damn, I should stop editing diffs by hand. > > I'm also have this old habbit ;-) That doesn't make it any better :) >> Change this to >> pci_bus_assign_resources and it should work. Sorry. > > It works, but produced an oops (attached). Looks like this is caused by your driver, I can't see any of my functions in the strace. Eike pgp4qi5wOqKuw.pgp Description: PGP signature
Re: rc5 seemed to kill a disk that rc4-mm1 likes. Also some X trouble.
Helge Hafting wrote: >Dave Airlie wrote: >> I switched back to 2.6.13-rc4-mm1 at this point for another reason, >> my X display aquired a nasty tendency to go blank for no reason >> during work, >> something I could fix by changing resolution baqck and forth. X >> also tended to get >> stuck for a minute now and then - a problem I haven't seen since >> early 2.6. >> >> >> >> which head the radeon or MGA or both? > >The radeon 9200SE-pci gets stuck. The MGA-agp seems to be fine. I have >compiled >dri support for both, but I can't use it at the moment. I think that is >caused by having ubuntu's xorg installed on debian. I needed xorg >in order to run an xserver that doesn't use any tty - this way I can use >two keyboards and have two simultaneous users. Debians xorg wasn't ready >at the moment. The setup is fine with 2.6.13-rc4-mm1 x86-64, no problems >there. I have some other issue with a MGA card (don't know exactly which, I have only access to this on the weekend). With rc5 and rc6 kdm will not start on bootup, X complains about some unresolved symbols in the X mga driver. If I log in as user and do startx it works fine, also if I switch back to 2.6.12-rc-something. Something seems to confuse X somehow. It's a PII-350 with more or less SuSE 9.3. The machine has no net access, so I can only try to narrow it down to one rc at the weekend. Eike pgptE4lUIjy8H.pgp Description: PGP signature
Re: [Fwd: help with PCI hotplug and a PCI device enabled after boot]
Am Mittwoch, 17. August 2005 12:54 schrieb Mauro Carvalho Chehab: >Rolf, > >Em Qua, 2005-08-17 Ã s 11:47 +0200, Rolf Eike Beer escreveu: >> Mauro Carvalho Chehab wrote: >> >I need some help with PCI hotplug for allowing a new driver at >> >Video4Linux. >> > >> >I need memory to set its internal registers. Is there a way to make >> >PCI drivers to allocate a memory region for the board? >> >> Use dummyphp instead of fakephp. It should handle this case. You can find >> it here: http://opensource.sf-tec.de/kernel/dummyphp-2.6.13-rc1.diff > > Didn't compile cleanly against -rc6. Do I need another patch or -mm >series? > >WARNING: /lib/modules/2.6.13-rc6/kernel/drivers/pci/hotplug/dummyphp.ko >needs unknown symbol pci_bus_add_resources Damn, I should stop editing diffs by hand. Change this to pci_bus_assign_resources and it should work. Sorry. Eike pgpfnaRPbSis6.pgp Description: PGP signature
Re: [Fwd: help with PCI hotplug and a PCI device enabled after boot]
Mauro Carvalho Chehab wrote: >I need some help with PCI hotplug for allowing a new driver at >Video4Linux. > >I need memory to set its internal registers. Is there a way to make >PCI drivers to allocate a memory region for the board? Use dummyphp instead of fakephp. It should handle this case. You can find it here: http://opensource.sf-tec.de/kernel/dummyphp-2.6.13-rc1.diff Eike pgptshqsGoNn7.pgp Description: PGP signature
[PATCH 2.6.13-rc6] improve start/stop code for worker thread in cpqfcTS driver, take 3
Improve start/stop code for HBA worker thread. For the moment the return code
of the start/stop functions is ignored, this will change once the init/exit
code is changed to use 2.6 driver model.
Version 2: remove that lock_kernel() stuff missed in the first version
Version 3: use kthread API (pointed out by Christoph Hellwig)
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
diff -aup linux-2.6.13-rc6/drivers/scsi/cpqfcTSinit.c
linux-2.6.13-rc6-eike/drivers/scsi/cpqfcTSinit.c
--- linux-2.6.13-rc6/drivers/scsi/cpqfcTSinit.c 2005-08-16 16:42:14.0
+0200
+++ linux-2.6.13-rc6-eike/drivers/scsi/cpqfcTSinit.c2005-08-16
18:59:26.0 +0200
@@ -43,6 +43,7 @@
#include
#include // request_region() prototype
#include
+#include
#include
#include// ioctl related
@@ -204,32 +205,26 @@ static void Cpqfc_initHBAdata(CPQFCHBA *
}
}
-
-/* (borrowed from linux/drivers/scsi/hosts.c) */
-static void launch_FCworker_thread(struct Scsi_Host *HostAdapter)
+static int launch_FCworker_thread(struct Scsi_Host *HostAdapter)
{
- DECLARE_MUTEX_LOCKED(sem);
-
- CPQFCHBA *cpqfcHBAdata = (CPQFCHBA *)HostAdapter->hostdata;
+ CPQFCHBA *cpqfcHBAdata = (CPQFCHBA *)HostAdapter->hostdata;
- ENTER("launch_FC_worker_thread");
+ ENTER(__function__);
- cpqfcHBAdata->notify_wt = &sem;
+ spin_unlock_irq(HostAdapter->host_lock);
- /* must unlock before kernel_thread(), for it may cause a reschedule. */
- spin_unlock_irq(HostAdapter->host_lock);
- kernel_thread((int (*)(void *))cpqfcTSWorkerThread,
- (void *) HostAdapter, 0);
- /*
- * Now wait for the kernel error thread to initialize itself
-
- */
- down (&sem);
- spin_lock_irq(HostAdapter->host_lock);
- cpqfcHBAdata->notify_wt = NULL;
+ cpqfcHBAdata->worker_thread = kthread_run(cpqfcTSWorkerThread,
+ HostAdapter,
+ "cpqfcTS_wt_%d", HostAdapter->host_no);
+ if (IS_ERR(cpqfcHBAdata->worker_thread)) {
+ printk(KERN_ERR DEV_NAME " can't start worker thread\n");
+ return PTR_ERR(cpqfcHBAdata->worker_thread);
+ }
- LEAVE("launch_FC_worker_thread");
+ spin_lock_irq(HostAdapter->host_lock);
+ LEAVE(__function__);
+ return 0;
}
@@ -317,9 +312,7 @@ int cpqfcTS_detect(Scsi_Host_Template *S
// each HBA on the PCI bus(ses)).
cpqfcHBAdata = (CPQFCHBA *)HostAdapter->hostdata;
- // make certain our data struct is clear
- memset( cpqfcHBAdata, 0, sizeof( CPQFCHBA ) );
-
+ memset(cpqfcHBAdata, 0, sizeof(*cpqfcHBAdata));
// initialize our HBA info
cpqfcHBAdata->HBAnum = NumberOfAdapters;
@@ -731,18 +724,7 @@ int cpqfcTS_release(struct Scsi_Host *Ho
DEBUG_PCI( printk(" disable hardware, destroy queues, free mem\n"));
cpqfcHBAdata->fcChip.ResetTachyon( cpqfcHBAdata, CLEAR_FCPORTS);
- // kill kernel thread
- if( cpqfcHBAdata->worker_thread ) // (only if exists)
- {
-DECLARE_MUTEX_LOCKED(sem); // synchronize thread kill
-
-cpqfcHBAdata->notify_wt = &sem;
-DEBUG_PCI( printk(" killing kernel thread\n"));
-send_sig( SIGKILL, cpqfcHBAdata->worker_thread, 1);
-down( &sem);
-cpqfcHBAdata->notify_wt = NULL;
-
- }
+ kthread_stop(cpqfcHBAdata->worker_thread);
cpqfc_free_private_data_pool(cpqfcHBAdata);
// free Linux resources
diff -aup linux-2.6.13-rc6/drivers/scsi/cpqfcTSstructs.h
linux-2.6.13-rc6-eike/drivers/scsi/cpqfcTSstructs.h
--- linux-2.6.13-rc6/drivers/scsi/cpqfcTSstructs.h 2005-08-16
16:42:14.0 +0200
+++ linux-2.6.13-rc6-eike/drivers/scsi/cpqfcTSstructs.h 2005-08-16
19:01:42.0 +0200
@@ -829,7 +829,7 @@ int CpqTsReadWriteWWN(void*, int ReadWri
int CpqTsReadWriteNVRAM(void*, void* data, int ReadWrite);
void cpqfcTS_WorkTask( struct Scsi_Host *HostAdapter);
-void cpqfcTSWorkerThread( void *host);
+extern int cpqfcTSWorkerThread(void *host);
int cpqfcTS_GetNVRAM_data( UCHAR *wwnbuf, UCHAR *buf );
ULONG cpqfcTS_ReadNVRAM( void* GPIOin, void* GPIOout , USHORT count,
diff -aup linux-2.6.13-rc6/drivers/scsi/cpqfcTSworker.c
linux-2.6.13-rc6-eike/drivers/scsi/cpqfcTSworker.c
--- linux-2.6.13-rc6/drivers/scsi/cpqfcTSworker.c 2005-08-16
16:42:14.0 +0200
+++ linux-2.6.13-rc6-eike/drivers/scsi/cpqfcTSworker.c 2005-08-16
19:05:42.0 +0200
@@ -31,8 +31,7 @@
#include
#include
#include
-
-#define SHUTDOWN_SIGS (sigmask(SIGKILL)|sigmask(SIGINT)|sigmask(SIGTERM))
+#include
#include
#include
@@ -145,9 +144,8 @@ static void IssueReportLunsCommand(
CPQFCHBA* cpqfcHBAdata,
TachFCHDR_GCMND* fchs);
-// (see scsi_error.c comments on kernel task creation)
-
-void cpqfcTSWorkerThread( void *host)
+int
+cpqfcTSWorkerThread(void *host)
{
struct Scsi_Host *HostAdapter =
[PATCH 2.6.13-rc6] improve start/stop code for worker thread in cpqfcTS driver, take 2
Use pid of worker thread and struct completion for signaling end of worker
thread (code more or less taken from drivers/net/8139too.c). For the moment
the return code of the start/stop functions is ignored, this will change
once the init/exit code is changed to use 2.6 driver model.
Version 2: remove that lock_kernel() stuff missed in the first version
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
diff -aup linux-2.6.13-rc6/drivers/scsi/cpqfcTSinit.c
linux-2.6.13-rc6-eike/drivers/scsi/cpqfcTSinit.c
--- linux-2.6.13-rc6/drivers/scsi/cpqfcTSinit.c 2005-08-16 16:42:14.0
+0200
+++ linux-2.6.13-rc6-eike/drivers/scsi/cpqfcTSinit.c2005-08-16
16:34:02.0 +0200
@@ -204,32 +204,35 @@ static void Cpqfc_initHBAdata(CPQFCHBA *
}
}
-
-/* (borrowed from linux/drivers/scsi/hosts.c) */
-static void launch_FCworker_thread(struct Scsi_Host *HostAdapter)
+static int launch_FCworker_thread(struct Scsi_Host *HostAdapter)
{
- DECLARE_MUTEX_LOCKED(sem);
-
- CPQFCHBA *cpqfcHBAdata = (CPQFCHBA *)HostAdapter->hostdata;
-
- ENTER("launch_FC_worker_thread");
-
- cpqfcHBAdata->notify_wt = &sem;
-
- /* must unlock before kernel_thread(), for it may cause a reschedule. */
- spin_unlock_irq(HostAdapter->host_lock);
- kernel_thread((int (*)(void *))cpqfcTSWorkerThread,
- (void *) HostAdapter, 0);
- /*
- * Now wait for the kernel error thread to initialize itself
-
- */
- down (&sem);
- spin_lock_irq(HostAdapter->host_lock);
- cpqfcHBAdata->notify_wt = NULL;
-
- LEAVE("launch_FC_worker_thread");
-
+ DECLARE_MUTEX_LOCKED(sem);
+
+ CPQFCHBA *cpqfcHBAdata = (CPQFCHBA *)HostAdapter->hostdata;
+
+ ENTER(__function__);
+
+ cpqfcHBAdata->notify_wt = &sem;
+
+ /* must unlock before kernel_thread(), for it may cause a reschedule. */
+ spin_unlock_irq(HostAdapter->host_lock);
+ cpqfcHBAdata->thr_pid = -1;
+ cpqfcHBAdata->time_to_die = 0;
+ cpqfcHBAdata->thr_pid = kernel_thread(cpqfcTSWorkerThread, HostAdapter,
0);
+ if (cpqfcHBAdata->thr_pid) {
+ printk(KERN_ERR DEV_NAME " can't start worker thread\n");
+ return cpqfcHBAdata->thr_pid;
+ } else {
+ /*
+ * Now wait for the kernel error thread to initialize itself
+ */
+ down (&sem);
+ spin_lock_irq(HostAdapter->host_lock);
+ cpqfcHBAdata->notify_wt = NULL;
+ }
+
+ LEAVE(__function__);
+ return 0;
}
@@ -317,9 +320,8 @@ int cpqfcTS_detect(Scsi_Host_Template *S
// each HBA on the PCI bus(ses)).
cpqfcHBAdata = (CPQFCHBA *)HostAdapter->hostdata;
- // make certain our data struct is clear
- memset( cpqfcHBAdata, 0, sizeof( CPQFCHBA ) );
-
+ memset(cpqfcHBAdata, 0, sizeof(*cpqfcHBAdata));
+ init_completion(&cpqfcHBAdata->thr_exited);
// initialize our HBA info
cpqfcHBAdata->HBAnum = NumberOfAdapters;
@@ -712,6 +714,25 @@ int cpqfcTS_ioctl( struct scsi_device *S
return result;
}
+static int
+cpqfcTS_kill_worker(CPQFCHBA *hba)
+{
+ int ret = 0;
+
+ if(hba->thr_pid >= 0) {
+ hba->time_to_die = 1;
+ wmb();
+ ret = kill_proc(hba->thr_pid, SIGTERM, 1);
+ if (ret) {
+ printk(KERN_ERR DEV_NAME " unable to signal thread
%i\n",
+ hba->thr_pid);
+ } else {
+ wait_for_completion(&hba->thr_exited);
+ hba->thr_pid = -1;
+ }
+ }
+ return ret;
+}
/* "Release" the Host Bus Adapter...
disable interrupts, stop the HBA, release the interrupt,
@@ -731,18 +752,7 @@ int cpqfcTS_release(struct Scsi_Host *Ho
DEBUG_PCI( printk(" disable hardware, destroy queues, free mem\n"));
cpqfcHBAdata->fcChip.ResetTachyon( cpqfcHBAdata, CLEAR_FCPORTS);
- // kill kernel thread
- if( cpqfcHBAdata->worker_thread ) // (only if exists)
- {
-DECLARE_MUTEX_LOCKED(sem); // synchronize thread kill
-
-cpqfcHBAdata->notify_wt = &sem;
-DEBUG_PCI( printk(" killing kernel thread\n"));
-send_sig( SIGKILL, cpqfcHBAdata->worker_thread, 1);
-down( &sem);
-cpqfcHBAdata->notify_wt = NULL;
-
- }
+ cpqfcTS_kill_worker(cpqfcHBAdata);
cpqfc_free_private_data_pool(cpqfcHBAdata);
// free Linux resources
diff -aup linux-2.6.13-rc6/drivers/scsi/cpqfcTSstructs.h
linux-2.6.13-rc6-eike/drivers/scsi/cpqfcTSstructs.h
--- linux-2.6.13-rc6/drivers/scsi/cpqfcTSstructs.h 2005-08-16
16:42:14.0 +0200
+++ linux-2.6.13-rc6-eike/drivers/scsi/cpqfcTSstructs.h 2005-08-16
16:28:53.0 +0200
@@ -829,7 +829,7 @@ int CpqTsReadWriteWWN(void*, int ReadWri
int C
[PATCH 2.6.13-rc6] improve start/stop code for worker thread in cpqfcTS driver
Use pid of worker thread and struct completion for signaling end of worker
thread (code more or less taken from drivers/net/8139too.c). For the moment
the return code of the start/stop functions is ignored, this will change
once the init/exit code is changed to use 2.6 driver model.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
diff -aup linux-2.6.13-rc6/drivers/scsi/cpqfcTSinit.c
linux-2.6.13-rc6-eike/drivers/scsi/cpqfcTSinit.c
--- linux-2.6.13-rc6/drivers/scsi/cpqfcTSinit.c 2005-08-16 16:42:14.0
+0200
+++ linux-2.6.13-rc6-eike/drivers/scsi/cpqfcTSinit.c2005-08-16
16:34:02.0 +0200
@@ -204,32 +204,35 @@ static void Cpqfc_initHBAdata(CPQFCHBA *
}
}
-
-/* (borrowed from linux/drivers/scsi/hosts.c) */
-static void launch_FCworker_thread(struct Scsi_Host *HostAdapter)
+static int launch_FCworker_thread(struct Scsi_Host *HostAdapter)
{
- DECLARE_MUTEX_LOCKED(sem);
-
- CPQFCHBA *cpqfcHBAdata = (CPQFCHBA *)HostAdapter->hostdata;
-
- ENTER("launch_FC_worker_thread");
-
- cpqfcHBAdata->notify_wt = &sem;
-
- /* must unlock before kernel_thread(), for it may cause a reschedule. */
- spin_unlock_irq(HostAdapter->host_lock);
- kernel_thread((int (*)(void *))cpqfcTSWorkerThread,
- (void *) HostAdapter, 0);
- /*
- * Now wait for the kernel error thread to initialize itself
-
- */
- down (&sem);
- spin_lock_irq(HostAdapter->host_lock);
- cpqfcHBAdata->notify_wt = NULL;
-
- LEAVE("launch_FC_worker_thread");
-
+ DECLARE_MUTEX_LOCKED(sem);
+
+ CPQFCHBA *cpqfcHBAdata = (CPQFCHBA *)HostAdapter->hostdata;
+
+ ENTER(__function__);
+
+ cpqfcHBAdata->notify_wt = &sem;
+
+ /* must unlock before kernel_thread(), for it may cause a reschedule. */
+ spin_unlock_irq(HostAdapter->host_lock);
+ cpqfcHBAdata->thr_pid = -1;
+ cpqfcHBAdata->time_to_die = 0;
+ cpqfcHBAdata->thr_pid = kernel_thread(cpqfcTSWorkerThread, HostAdapter,
0);
+ if (cpqfcHBAdata->thr_pid) {
+ printk(KERN_ERR DEV_NAME " can't start worker thread\n");
+ return cpqfcHBAdata->thr_pid;
+ } else {
+ /*
+ * Now wait for the kernel error thread to initialize itself
+ */
+ down (&sem);
+ spin_lock_irq(HostAdapter->host_lock);
+ cpqfcHBAdata->notify_wt = NULL;
+ }
+
+ LEAVE(__function__);
+ return 0;
}
@@ -317,9 +320,8 @@ int cpqfcTS_detect(Scsi_Host_Template *S
// each HBA on the PCI bus(ses)).
cpqfcHBAdata = (CPQFCHBA *)HostAdapter->hostdata;
- // make certain our data struct is clear
- memset( cpqfcHBAdata, 0, sizeof( CPQFCHBA ) );
-
+ memset(cpqfcHBAdata, 0, sizeof(*cpqfcHBAdata));
+ init_completion(&cpqfcHBAdata->thr_exited);
// initialize our HBA info
cpqfcHBAdata->HBAnum = NumberOfAdapters;
@@ -712,6 +714,25 @@ int cpqfcTS_ioctl( struct scsi_device *S
return result;
}
+static int
+cpqfcTS_kill_worker(CPQFCHBA *hba)
+{
+ int ret = 0;
+
+ if(hba->thr_pid >= 0) {
+ hba->time_to_die = 1;
+ wmb();
+ ret = kill_proc(hba->thr_pid, SIGTERM, 1);
+ if (ret) {
+ printk(KERN_ERR DEV_NAME " unable to signal thread
%i\n",
+ hba->thr_pid);
+ } else {
+ wait_for_completion(&hba->thr_exited);
+ hba->thr_pid = -1;
+ }
+ }
+ return ret;
+}
/* "Release" the Host Bus Adapter...
disable interrupts, stop the HBA, release the interrupt,
@@ -731,18 +752,7 @@ int cpqfcTS_release(struct Scsi_Host *Ho
DEBUG_PCI( printk(" disable hardware, destroy queues, free mem\n"));
cpqfcHBAdata->fcChip.ResetTachyon( cpqfcHBAdata, CLEAR_FCPORTS);
- // kill kernel thread
- if( cpqfcHBAdata->worker_thread ) // (only if exists)
- {
-DECLARE_MUTEX_LOCKED(sem); // synchronize thread kill
-
-cpqfcHBAdata->notify_wt = &sem;
-DEBUG_PCI( printk(" killing kernel thread\n"));
-send_sig( SIGKILL, cpqfcHBAdata->worker_thread, 1);
-down( &sem);
-cpqfcHBAdata->notify_wt = NULL;
-
- }
+ cpqfcTS_kill_worker(cpqfcHBAdata);
cpqfc_free_private_data_pool(cpqfcHBAdata);
// free Linux resources
diff -aup linux-2.6.13-rc6/drivers/scsi/cpqfcTSstructs.h
linux-2.6.13-rc6-eike/drivers/scsi/cpqfcTSstructs.h
--- linux-2.6.13-rc6/drivers/scsi/cpqfcTSstructs.h 2005-08-16
16:42:14.0 +0200
+++ linux-2.6.13-rc6-eike/drivers/scsi/cpqfcTSstructs.h 2005-08-16
16:28:53.0 +0200
@@ -829,7 +829,7 @@ int CpqTsReadWriteWWN(void*, int ReadWri
int CpqTsReadWriteNVRAM(void*, void* data, int ReadWrite);
vo
Re: [PATCH 2.6.13-rc6] remove dead reset function from cpqfcTS driver
Martin K. Petersen wrote: >>>>>> "Rolf" == Rolf Eike Beer <[EMAIL PROTECTED]> writes: > >Hey Rolf! I should go and use "R. Eike Beer" ;) >Rolf> There was a request on lkml last week for a working version of >Rolf> this driver. For the moment I try to clean this up a bit before >Rolf> doing some real work. I found 4 major things that should be >Rolf> done, for half of them I have patches in a proof-of-concept >Rolf> state. > >As Christoph said I'm working on a driver for the TachLite TL/TS/XL2 >chips. > >Initially I just wanted to add support for the integrated PHY on XL2 >so we could support those cards on PA-RISC. But when I started >looking at the driver I came to the conclusion that it was just too >ugly to live. Architecturally, the overall design of cpqfc just >doesn't fit in well with Linux. So I'm rewriting it from scratch - >but that obviously takes a while. >I think it's cool that you want to hack on cpqfcTS. But be aware that >it's not just a matter of running lindent and making it compile in >2.6.late. And without hardware it's going to be hard. Fibre channel >is very finicky. For the moment I'm trying to fix the most buggy parts. The Lindent run is scheduled to be done last, it's too big and adds nothing if it would go into kernel for now. It won't even compile now, my tests are only compile tests done with the two #error commented out. That should prevent most users from using it without all patches applied. The rest either knows what he's doing and/or would get crashes anyway ;) Next to come will be splitting up the ISR and then fixing the #errors. After this is might even work. :) >If you manage to get your hands on hardware (cards - avoid Tachyon >5000 series. TachLite 5100, 5166 or 5200 is what you want, disk array, >hub/switch, GBICs, etc.) I wouldn't mind some help... Give me some code and we can see... Bolke, what kind of adapter do you have? Eike pgp97W9dEtmZh.pgp Description: PGP signature
[PATCH 2.6.13-rc6] remove 2.4 compat code from cpqfcTS driver, take 3
Remove compat code for Linux 2.4 and earlier.
Version 2: Fixed bug in earlier version that caused compile error.
Version 3: found bug in previous patch, changed this to apply cleanly.
Sorry for the noise.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
--- a/drivers/scsi/cpqfcTScontrol.c 2005-08-13 19:00:35.0 +0200
+++ b/drivers/scsi/cpqfcTScontrol.c 2005-08-14 11:02:09.0 +0200
@@ -28,8 +28,6 @@
Hewlitt Packard Manual Part Number 5968-1083E.
*/
-#define LinuxVersionCode(v, p, s) (((v)<<16)+((p)<<8)+(s))
-
#include
#include
#include
--- a/drivers/scsi/cpqfcTSstructs.h 2005-08-14 11:11:52.0 +0200
+++ b/drivers/scsi/cpqfcTSstructs.h 2005-08-14 11:12:54.0 +0200
@@ -88,7 +88,6 @@
#define CPQFCTS_CMD_PER_LUN 15 // power of 2 -1, must be >0
#define CPQFCTS_REQ_QUEUE_LEN (TACH_SEST_LEN/2) // must be < TACH_SEST_LEN
-#define LinuxVersionCode(v, p, s) (((v)<<16)+((p)<<8)+(s))
#ifndef DECLARE_MUTEX_LOCKED
#define DECLARE_MUTEX_LOCKED(sem) struct semaphore sem = MUTEX_LOCKED
#endif
--- a/drivers/scsi/cpqfcTSinit.c2005-08-14 14:56:41.0 +0200
+++ b/drivers/scsi/cpqfcTSinit.c2005-08-14 14:57:27.0 +0200
@@ -29,8 +29,6 @@
*/
-#define LinuxVersionCode(v, p, s) (((v)<<16)+((p)<<8)+(s))
-
#include
#include
#include
@@ -72,31 +70,10 @@ int cpqfcTS_TargetDeviceReset( Scsi_Devi
// few fields...
// NOTE: proc_fs changes in 2.4 kernel
-#if LINUX_VERSION_CODE < LinuxVersionCode(2,3,27)
-static struct proc_dir_entry proc_scsi_cpqfcTS =
-{
- PROC_SCSI_CPQFCTS, // ushort low_ino (enumerated list)
- 7, // ushort namelen
- DEV_NAME,// const char* name
- S_IFDIR | S_IRUGO | S_IXUGO, // mode_t mode
- 2// nlink_t nlink
- // etc. ...
-};
-
-
-#endif
-
-#if LINUX_VERSION_CODE >= LinuxVersionCode(2,4,7)
-# define CPQFC_DECLARE_COMPLETION(x) DECLARE_COMPLETION(x)
-# define CPQFC_WAITING waiting
-# define CPQFC_COMPLETE(x) complete(x)
-# define CPQFC_WAIT_FOR_COMPLETION(x) wait_for_completion(x);
-#else
-# define CPQFC_DECLARE_COMPLETION(x) DECLARE_MUTEX_LOCKED(x)
-# define CPQFC_WAITING sem
-# define CPQFC_COMPLETE(x) up(x)
-# define CPQFC_WAIT_FOR_COMPLETION(x) down(x)
-#endif
+#define CPQFC_DECLARE_COMPLETION(x) DECLARE_COMPLETION(x)
+#define CPQFC_WAITING waiting
+#define CPQFC_COMPLETE(x) complete(x)
+#define CPQFC_WAIT_FOR_COMPLETION(x) wait_for_completion(x);
static int cpqfc_alloc_private_data_pool(CPQFCHBA *hba);
@@ -284,12 +261,6 @@ int cpqfcTS_detect(Scsi_Host_Template *S
ENTER("cpqfcTS_detect");
-#if LINUX_VERSION_CODE < LinuxVersionCode(2,3,27)
- ScsiHostTemplate->proc_dir = &proc_scsi_cpqfcTS;
-#else
- ScsiHostTemplate->proc_name = "cpqfcTS";
-#endif
-
for(i = 0; cpqfc_boards[i].vendor; i++) {
while((PciDev = pci_get_device(cpqfc_boards[i].vendor,
cpqfc_boards[i].device, PciDev))) {
@@ -2059,6 +2030,7 @@ void* fcMemManager( struct pci_dev *pdev
static Scsi_Host_Template driver_template = {
+ .proc_name = DEV_NAME,
.detect = cpqfcTS_detect,
.release= cpqfcTS_release,
.info = cpqfcTS_info,
-
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-rc6] MODULE_DEVICE_TABLE for cpqfcTS driver, take 2
cpqfcTSinit has a static array of PCI device and vendor ids supported by the
driver. Sounds familiar, doesn't it? Use pci_device_id as type for the
entries of this array and declare the array as MODULE_DEVICE_TABLE. Also use
pci_get_device() instead of pci_find_device() and remove some superfluos
defines for device scanning.
Version 2:
-use PCI_DEVICE makro (thanks to Jiri Slaby for pointing this out)
-fix compile error (diffed wrong files)
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
--- a/drivers/scsi/cpqfcTSstructs.h 2005-08-14 10:56:41.0 +0200
+++ b/drivers/scsi/cpqfcTSstructs.h 2005-08-14 10:57:32.0 +0200
@@ -95,12 +95,6 @@
#define DEV_NAME "cpqfcTS"
-struct SupportedPCIcards
-{
- __u16 vendor_id;
- __u16 device_id;
-};
-
// nn:nn denotes bit field
// TachyonHeader struct def.
// the fields shared with ODB
--- a/drivers/scsi/cpqfcTSinit.c2005-08-14 14:20:40.0 +0200
+++ b/drivers/scsi/cpqfcTSinit.c2005-08-14 14:25:33.0 +0200
@@ -264,18 +264,14 @@ static void launch_FCworker_thread(struc
* Agilent XL2
* HP Tachyon
*/
-#define HBA_TYPES 3
-
-#ifndef PCI_DEVICE_ID_COMPAQ_
-#define PCI_DEVICE_ID_COMPAQ_TACHYON 0xa0fc
-#endif
-
-static struct SupportedPCIcards cpqfc_boards[] __initdata = {
- {PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_TACHYON},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_TACHLITE},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_TACHYON},
+static struct pci_device_id cpqfc_boards[] __initdata = {
+ {PCI_DEVICE(PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_TACHYON), 0, 0,
0},
+ {PCI_DEVICE(PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_TACHLITE), 0, 0, 0},
+ {PCI_DEVICE(PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_TACHYON), 0, 0, 0},
+ {0, }
};
+MODULE_DEVICE_TABLE(pci, cpqfc_boards);
int cpqfcTS_detect(Scsi_Host_Template *ScsiHostTemplate)
{
@@ -294,14 +290,9 @@ int cpqfcTS_detect(Scsi_Host_Template *S
ScsiHostTemplate->proc_name = "cpqfcTS";
#endif
- for( i=0; i < HBA_TYPES; i++)
- {
-// look for all HBAs of each type
-
-while((PciDev = pci_find_device(cpqfc_boards[i].vendor_id,
- cpqfc_boards[i].device_id, PciDev)))
-{
-
+ for(i = 0; cpqfc_boards[i].vendor; i++) {
+while((PciDev = pci_get_device(cpqfc_boards[i].vendor,
+ cpqfc_boards[i].device, PciDev))) {
if (pci_enable_device(PciDev)) {
printk(KERN_ERR
"cpqfc: can't enable PCI device at %s\n", pci_name(PciDev));
-
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-rc6] remove 2.4 compat code from cpqfcTS driver, take 2
Remove compat code for Linux 2.4 and earlier. Fixed bug in earlier version
that caused compile error.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
--- a/drivers/scsi/cpqfcTScontrol.c 2005-08-13 19:00:35.0 +0200
+++ b/drivers/scsi/cpqfcTScontrol.c 2005-08-14 11:02:09.0 +0200
@@ -28,8 +28,6 @@
Hewlitt Packard Manual Part Number 5968-1083E.
*/
-#define LinuxVersionCode(v, p, s) (((v)<<16)+((p)<<8)+(s))
-
#include
#include
#include
--- a/drivers/scsi/cpqfcTSstructs.h 2005-08-14 11:11:52.0 +0200
+++ b/drivers/scsi/cpqfcTSstructs.h 2005-08-14 11:12:54.0 +0200
@@ -88,7 +88,6 @@
#define CPQFCTS_CMD_PER_LUN 15 // power of 2 -1, must be >0
#define CPQFCTS_REQ_QUEUE_LEN (TACH_SEST_LEN/2) // must be < TACH_SEST_LEN
-#define LinuxVersionCode(v, p, s) (((v)<<16)+((p)<<8)+(s))
#ifndef DECLARE_MUTEX_LOCKED
#define DECLARE_MUTEX_LOCKED(sem) struct semaphore sem = MUTEX_LOCKED
#endif
--- a/drivers/scsi/cpqfcTSinit.c2005-08-14 14:56:41.0 +0200
+++ b/drivers/scsi/cpqfcTSinit.c2005-08-14 14:57:27.0 +0200
@@ -29,8 +29,6 @@
*/
-#define LinuxVersionCode(v, p, s) (((v)<<16)+((p)<<8)+(s))
-
#include
#include
#include
@@ -72,31 +70,10 @@ int cpqfcTS_TargetDeviceReset( Scsi_Devi
// few fields...
// NOTE: proc_fs changes in 2.4 kernel
-#if LINUX_VERSION_CODE < LinuxVersionCode(2,3,27)
-static struct proc_dir_entry proc_scsi_cpqfcTS =
-{
- PROC_SCSI_CPQFCTS, // ushort low_ino (enumerated list)
- 7, // ushort namelen
- DEV_NAME,// const char* name
- S_IFDIR | S_IRUGO | S_IXUGO, // mode_t mode
- 2// nlink_t nlink
- // etc. ...
-};
-
-
-#endif
-
-#if LINUX_VERSION_CODE >= LinuxVersionCode(2,4,7)
-# define CPQFC_DECLARE_COMPLETION(x) DECLARE_COMPLETION(x)
-# define CPQFC_WAITING waiting
-# define CPQFC_COMPLETE(x) complete(x)
-# define CPQFC_WAIT_FOR_COMPLETION(x) wait_for_completion(x);
-#else
-# define CPQFC_DECLARE_COMPLETION(x) DECLARE_MUTEX_LOCKED(x)
-# define CPQFC_WAITING sem
-# define CPQFC_COMPLETE(x) up(x)
-# define CPQFC_WAIT_FOR_COMPLETION(x) down(x)
-#endif
+#define CPQFC_DECLARE_COMPLETION(x) DECLARE_COMPLETION(x)
+#define CPQFC_WAITING waiting
+#define CPQFC_COMPLETE(x) complete(x)
+#define CPQFC_WAIT_FOR_COMPLETION(x) wait_for_completion(x);
static int cpqfc_alloc_private_data_pool(CPQFCHBA *hba);
@@ -284,12 +261,6 @@ int cpqfcTS_detect(Scsi_Host_Template *S
ENTER("cpqfcTS_detect");
-#if LINUX_VERSION_CODE < LinuxVersionCode(2,3,27)
- ScsiHostTemplate->proc_dir = &proc_scsi_cpqfcTS;
-#else
- ScsiHostTemplate->proc_name = "cpqfcTS";
-#endif
-
for(i = 0; cpqfc_boards[i]; i++) {
while((PciDev = pci_get_device(cpqfc_boards[i].vendor,
cpqfc_boards[i].device, PciDev))) {
@@ -2059,6 +2030,7 @@ void* fcMemManager( struct pci_dev *pdev
static Scsi_Host_Template driver_template = {
+ .proc_name = DEV_NAME,
.detect = cpqfcTS_detect,
.release= cpqfcTS_release,
.info = cpqfcTS_info,
-
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-rc6] MODULE_DEVICE_TABLE for cpqfcTS driver
Jiri Slaby wrote:
>Rolf Eike Beer napsal(a):
>>Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
>>
>>--- a/drivers/scsi/cpqfcTSinit.c 2005-08-14 14:20:40.0 +0200
>>+++ b/drivers/scsi/cpqfcTSinit.c 2005-08-14 14:25:33.0 +0200
>>@@ -264,18 +264,14 @@ static void launch_FCworker_thread(struc
>> * Agilent XL2
>> * HP Tachyon
>> */
>>-#define HBA_TYPES 3
>>-
>>-#ifndef PCI_DEVICE_ID_COMPAQ_
>>-#define PCI_DEVICE_ID_COMPAQ_TACHYON 0xa0fc
>>-#endif
>>-
>>-static struct SupportedPCIcards cpqfc_boards[] __initdata = {
>>- {PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_TACHYON},
>>- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_TACHLITE},
>>- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_TACHYON},
>>+static struct pci_device_id cpqfc_boards[] __initdata = {
>>+ {PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_TACHYON, PCI_ANY_ID,
>> PCI_ANY_ID, 0, 0, 0}, + {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_TACHLITE,
>> PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, + {PCI_VENDOR_ID_HP,
>> PCI_DEVICE_ID_HP_TACHYON, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, +{0, }
>> };
>
>Wouldn't be better to use PCI_DEVICE macro for better readability?
Yes, useful little thing. Thanks, I wasn't aware of it.
>>+MODULE_DEVICE_TABLE(pci, cpqfc_boards);
>>
>> int cpqfcTS_detect(Scsi_Host_Template *ScsiHostTemplate)
>> {
>>@@ -294,14 +290,9 @@ int cpqfcTS_detect(Scsi_Host_Template *S
>> ScsiHostTemplate->proc_name = "cpqfcTS";
>> #endif
>>
>>- for( i=0; i < HBA_TYPES; i++)
>>- {
>>-// look for all HBAs of each type
>>-
>>-while((PciDev = pci_find_device(cpqfc_boards[i].vendor_id,
>>- cpqfc_boards[i].device_id, PciDev)))
>>-{
>>-
>>+ for(i = 0; cpqfc_boards[i]; i++) {
>>+while((PciDev = pci_get_device(cpqfc_boards[i].vendor,
>>+ cpqfc_boards[i].device, PciDev))) {
>> if (pci_enable_device(PciDev)) {
>> printk(KERN_ERR
>> "cpqfc: can't enable PCI device at %s\n", pci_name(PciDev));
>
>You maybe forgot to add pci_dev_put in error cases.
No, all errors will result in next iteration of this loop. Anyway this
function should be rewritten. Once I figure out how to do the correct
register stuff for SCSI drivers I'll port this over to Linux 2.6 driver
model. Then this loop will go away.
>You can inspire yourself here:
>http://www.fi.muni.cz/~xslaby/lnx/pci_find/drivers:scsi:cpqfcTSinit.c.txt
>(it wasn't accepted yet).
*g* I've done such patches more than once ;)
>BTW. Greg KH wants me to cc him, if some of these changes are being done.
I read that, yes. But I had reasons not to CC him. This change is more or less
to prevent others touching this file ;)
Eike
P.S.: your host is listed in cbl.abuseat.org. You should go and check this.
Either you have a dynamic IP used by someone dumb before (than you have to
ask them for delisting) or you probably have some sort of security hole.
pgpr5YYStXnMT.pgp
Description: PGP signature
Re: [PATCH 2.6.13-rc6] remove dead reset function from cpqfcTS driver
Christoph Hellwig wrote: >On Tue, Aug 16, 2005 at 11:11:06AM +0200, Rolf Eike Beer wrote: >> cpqfcTS_reset() is never referenced from anywhere. By using the >> nonexistent constant SCSI_RESET_ERROR it causes just another unneeded >> compile error. > >That was the old reset handler. Do you actually have this hardware? >The driver is pretty much un-recoverable and mkp is working on a from >scratch driver for this hardware - I don't think putting any work into the >driver makes sense unless you have a very urgent need to use it. No, I don't have (but maybe I'll get access to it soon). There was a request on lkml last week for a working version of this driver. For the moment I try to clean this up a bit before doing some real work. I found 4 major things that should be done, for half of them I have patches in a proof-of-concept state. -split the interrupt handler into a handler and a tasklet -remove the stack abuse -use Linux 2.6 hardware probing code (this would cause the most problems for me, I'm not familiar with the preferred way of doing this for scsi drivers) -fix kernel thread stopping After this some more error checking at different places can't hurt. And a big Lindent run. Eike pgp5IEqmwmedg.pgp Description: PGP signature
[PATCH 2.6.13-rc6] more whitespace cleanups for cpqfcTS
More whitespace cleanups:
-remove trailing whitespace
-remove brakets around return statements
-remove some double (or more) newlines
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
--- a/drivers/scsi/cpqfcTSi2c.c 2005-08-07 20:18:56.0 +0200
+++ b/drivers/scsi/cpqfcTSi2c.c 2005-08-14 15:47:35.0 +0200
@@ -1,6 +1,6 @@
-/* Copyright(c) 2000, Compaq Computer Corporation
- * Fibre Channel Host Bus Adapter
- * 64-bit, 66MHz PCI
+/* Copyright(c) 2000, Compaq Computer Corporation
+ * Fibre Channel Host Bus Adapter
+ * 64-bit, 66MHz PCI
* Originally developed and tested on:
* (front): [chip] Tachyon TS HPFC-5166A/1.2 L2C1090 ...
* SP# P225CXCBFIEL6T, Rev XC
@@ -18,16 +18,15 @@
* General Public License for more details.
* Written by Don Zimmerman
*/
-// These functions control the NVRAM I2C hardware on
+// These functions control the NVRAM I2C hardware on
// non-intelligent Fibre Host Adapters.
-// The primary purpose is to read the HBA's NVRAM to get adapter's
+// The primary purpose is to read the HBA's NVRAM to get adapter's
// manufactured WWN to copy into Tachyon chip registers
// Orignal source author unknown
#include
enum boolean { FALSE, TRUE } ;
-
#ifndef UCHAR
typedef __u8 UCHAR;
#endif
@@ -41,7 +40,6 @@ typedef __u16 USHORT;
typedef __u32 ULONG;
#endif
-
#include
#include
#include
@@ -61,7 +59,7 @@ static void tl_i2c_tx_byte( void* GPIOou
// Tachlite GPIO2, GPIO3 (I2C) DEFINES
// The NVRAM chip NM24C03 defines SCL (serial clock) and SDA (serial data)
// GPIO2 drives SDA, and GPIO3 drives SCL
-//
+//
// Since Tachlite inverts the state of the GPIO 0-3 outputs, SET writes 0
// and clear writes 1. The input lines (read in TL status) is NOT inverted
// This really helps confuse the code and debugging.
@@ -78,7 +76,6 @@ static void tl_i2c_tx_byte( void* GPIOou
#define SLAVE_READ_ADDRESS0xA1
#define SLAVE_WRITE_ADDRESS 0xA0
-
static void i2c_delay(ULONG mstime);
static void tl_i2c_clock_pulse( UCHAR , void* GPIOout);
@@ -102,9 +99,9 @@ static unsigned short tl_i2c_rx_ack( voi
// slave must drive data low for acknowledge
value = tl_read_i2c_data( GPIOin);
if (value & SENSE_DATA_HI )
-return( FALSE );
+return FALSE;
- return( TRUE );
+ return TRUE;
}
//-
//
@@ -116,7 +113,7 @@ static unsigned short tl_i2c_rx_ack( voi
//-
static UCHAR tl_read_i2c_data( void* gpioreg )
{
- return( (UCHAR)(readl( gpioreg ) & 0x08L) ); // GPIO3
+ return (UCHAR)(readl( gpioreg ) & 0x08L); // GPIO3
}
//-
//
@@ -171,16 +168,15 @@ static unsigned short tl_i2c_tx_start( v
// if he's still driving data low after 10 clocks, abort
value = tl_read_i2c_data( GPIOin ); // read status
if (!(value & 0x08) )
- return( FALSE );
+ return FALSE;
}
-
// To START, bring data low while clock high
tl_write_i2c_reg( GPIOout, SET_CLOCK_HI | SET_DATA_LO );
i2c_delay(0);
- return( TRUE ); // TX start successful
+ return TRUE; // TX start successful
}
//-
//
@@ -194,7 +190,7 @@ static unsigned short tl_i2c_tx_stop( vo
{
int i;
- for (i = 0; i < 10; i++)
+ for (i = 0; i < 10; i++)
{
// Send clock pulse, drive data line low
tl_i2c_clock_pulse( SET_DATA_LO, GPIOout );
@@ -207,10 +203,10 @@ static unsigned short tl_i2c_tx_stop( vo
// If slave is driving data line low, there's a problem; retry
if ( tl_read_i2c_data(GPIOin) & SENSE_DATA_HI )
- return( TRUE ); // TX STOP successful!
+ return TRUE; // TX STOP successful!
}
- return( FALSE ); // error
+ return FALSE; // error
}
//-
//
@@ -229,7 +225,7 @@ static void tl_i2c_tx_byte( void* GPIOou
tl_i2c_clock_pulse( (UCHAR)SET_DATA_HI, GPIOout);
else
tl_i2c_clock_pulse( (UCHAR)SET_DATA_LO, GPIOout);
- }
+ }
}
//-
//
@@ -243,7 +239,6 @@ static UCHAR tl_i2c_rx_byte( void* GPIOi
UCHAR bit;
UCHAR data = 0;
-
for (bit = 0x80; bit; bit >>= 1) {
// do clock pulse, let data line float high
tl_i2c_clock_pulse( SET_DATA_HI, GPIOout );
@@ -253,7 +248,7 @@ static UCHAR tl_i2c_rx_byte( void* GPIOi
data |= bit;
}
- return (data);
+ return data;
}
//*
//*
[PATCH 2.6.13-rc6] MODULE_DEVICE_TABLE for cpqfcTS driver
cpqfcTSinit has a static array of PCI device and vendor ids supported by the
driver. Sounds familiar, doesn't it? Use pci_device_id as type for the
entries of this array and declare the array as MODULE_DEVICE_TABLE. Also use
pci_get_device() instead of pci_find_device() and remove some superfluos
defines for device scanning.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
--- a/drivers/scsi/cpqfcTSstructs.h 2005-08-14 10:56:41.0 +0200
+++ b/drivers/scsi/cpqfcTSstructs.h 2005-08-14 10:57:32.0 +0200
@@ -95,12 +95,6 @@
#define DEV_NAME "cpqfcTS"
-struct SupportedPCIcards
-{
- __u16 vendor_id;
- __u16 device_id;
-};
-
// nn:nn denotes bit field
// TachyonHeader struct def.
// the fields shared with ODB
--- a/drivers/scsi/cpqfcTSinit.c2005-08-14 14:20:40.0 +0200
+++ b/drivers/scsi/cpqfcTSinit.c2005-08-14 14:25:33.0 +0200
@@ -264,18 +264,14 @@ static void launch_FCworker_thread(struc
* Agilent XL2
* HP Tachyon
*/
-#define HBA_TYPES 3
-
-#ifndef PCI_DEVICE_ID_COMPAQ_
-#define PCI_DEVICE_ID_COMPAQ_TACHYON 0xa0fc
-#endif
-
-static struct SupportedPCIcards cpqfc_boards[] __initdata = {
- {PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_TACHYON},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_TACHLITE},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_TACHYON},
+static struct pci_device_id cpqfc_boards[] __initdata = {
+ {PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_TACHYON, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_TACHLITE, PCI_ANY_ID, PCI_ANY_ID,
0, 0, 0},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_TACHYON, PCI_ANY_ID, PCI_ANY_ID, 0,
0, 0},
+ {0, }
};
+MODULE_DEVICE_TABLE(pci, cpqfc_boards);
int cpqfcTS_detect(Scsi_Host_Template *ScsiHostTemplate)
{
@@ -294,14 +290,9 @@ int cpqfcTS_detect(Scsi_Host_Template *S
ScsiHostTemplate->proc_name = "cpqfcTS";
#endif
- for( i=0; i < HBA_TYPES; i++)
- {
-// look for all HBAs of each type
-
-while((PciDev = pci_find_device(cpqfc_boards[i].vendor_id,
- cpqfc_boards[i].device_id, PciDev)))
-{
-
+ for(i = 0; cpqfc_boards[i]; i++) {
+while((PciDev = pci_get_device(cpqfc_boards[i].vendor,
+ cpqfc_boards[i].device, PciDev))) {
if (pci_enable_device(PciDev)) {
printk(KERN_ERR
"cpqfc: can't enable PCI device at %s\n", pci_name(PciDev));
-
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-rc6] remove 2.4 compat code from cpqfcTS driver
Remove compat code for Linux 2.4 and earlier.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
--- a/drivers/scsi/cpqfcTScontrol.c 2005-08-13 19:00:35.0 +0200
+++ b/drivers/scsi/cpqfcTScontrol.c 2005-08-14 11:02:09.0 +0200
@@ -28,8 +28,6 @@
Hewlitt Packard Manual Part Number 5968-1083E.
*/
-#define LinuxVersionCode(v, p, s) (((v)<<16)+((p)<<8)+(s))
-
#include
#include
#include
--- a/drivers/scsi/cpqfcTSstructs.h 2005-08-14 11:11:52.0 +0200
+++ b/drivers/scsi/cpqfcTSstructs.h 2005-08-14 11:12:54.0 +0200
@@ -88,7 +88,6 @@
#define CPQFCTS_CMD_PER_LUN 15 // power of 2 -1, must be >0
#define CPQFCTS_REQ_QUEUE_LEN (TACH_SEST_LEN/2) // must be < TACH_SEST_LEN
-#define LinuxVersionCode(v, p, s) (((v)<<16)+((p)<<8)+(s))
#ifndef DECLARE_MUTEX_LOCKED
#define DECLARE_MUTEX_LOCKED(sem) struct semaphore sem = MUTEX_LOCKED
#endif
--- a/drivers/scsi/cpqfcTSinit.c2005-08-14 14:56:41.0 +0200
+++ b/drivers/scsi/cpqfcTSinit.c2005-08-14 14:57:27.0 +0200
@@ -29,8 +29,6 @@
*/
-#define LinuxVersionCode(v, p, s) (((v)<<16)+((p)<<8)+(s))
-
#include
#include
#include
@@ -72,31 +70,10 @@ int cpqfcTS_TargetDeviceReset( Scsi_Devi
// few fields...
// NOTE: proc_fs changes in 2.4 kernel
-#if LINUX_VERSION_CODE < LinuxVersionCode(2,3,27)
-static struct proc_dir_entry proc_scsi_cpqfcTS =
-{
- PROC_SCSI_CPQFCTS, // ushort low_ino (enumerated list)
- 7, // ushort namelen
- DEV_NAME,// const char* name
- S_IFDIR | S_IRUGO | S_IXUGO, // mode_t mode
- 2// nlink_t nlink
- // etc. ...
-};
-
-
-#endif
-
-#if LINUX_VERSION_CODE >= LinuxVersionCode(2,4,7)
-# define CPQFC_DECLARE_COMPLETION(x) DECLARE_COMPLETION(x)
-# define CPQFC_WAITING waiting
-# define CPQFC_COMPLETE(x) complete(x)
-# define CPQFC_WAIT_FOR_COMPLETION(x) wait_for_completion(x);
-#else
-# define CPQFC_DECLARE_COMPLETION(x) DECLARE_MUTEX_LOCKED(x)
-# define CPQFC_WAITING sem
-# define CPQFC_COMPLETE(x) up(x)
-# define CPQFC_WAIT_FOR_COMPLETION(x) down(x)
-#endif
+#define CPQFC_DECLARE_COMPLETION(x) DECLARE_COMPLETION(x)
+#define CPQFC_WAITING waiting
+#define CPQFC_COMPLETE(x) complete(x)
+#define CPQFC_WAIT_FOR_COMPLETION(x) wait_for_completion(x);
static int cpqfc_alloc_private_data_pool(CPQFCHBA *hba);
@@ -284,12 +261,6 @@ int cpqfcTS_detect(Scsi_Host_Template *S
ENTER("cpqfcTS_detect");
-#if LINUX_VERSION_CODE < LinuxVersionCode(2,3,27)
- ScsiHostTemplate->proc_dir = &proc_scsi_cpqfcTS;
-#else
- ScsiHostTemplate->proc_name = "cpqfcTS";
-#endif
-
for(i = 0; cpqfc_boards[i]; i++) {
while((PciDev = pci_get_device(cpqfc_boards[i].vendor,
cpqfc_boards[i].device, PciDev))) {
@@ -2059,6 +2030,7 @@ void* fcMemManager( struct pci_dev *pdev
static Scsi_Host_Template driver_template = {
+ .procname = DEV_NAME;
.detect = cpqfcTS_detect,
.release= cpqfcTS_release,
.info = cpqfcTS_info,
-
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-rc6] remove superfluos ioctls from cpqfcTS
Remove ioctls to get PCI information and driver version. These information
can be found via lspci or dmesg. Also remove two typedefs already commented
out.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
--- a/drivers/scsi/cpqfcTSioctl.h 2005-08-07 20:18:56.0 +0200
+++ b/drivers/scsi/cpqfcTSioctl.h 2005-08-14 16:39:04.0 +0200
@@ -4,47 +4,6 @@
#define CCPQFCTS_IOC_MAGIC 'Z'
-typedef struct
-{
- __u8 bus;
- __u8 dev_fn;
- __u32 board_id;
-} cpqfc_pci_info_struct;
-
-typedef __u32 DriverVer_type;
-/*
-typedef union
-{
- struct // Peripheral Unit Device
- {
-__u8 Bus:6;
-__u8 Mode:2; // b00
-__u8 Dev;
- } PeripDev;
- struct // Volume Set Address
- {
-__u8 DevMSB:6;
-__u8 Mode:2; // b01
-__u8 DevLSB;
- } LogDev;
- struct // Logical Unit Device (SCSI-3, SCC-2 defined)
- {
-__u8 Targ:6;
-__u8 Mode:2; // b10
-__u8 Dev:5;
-__u8 Bus:3;
-
- } LogUnit;
-} SCSI3Addr_struct;
-
-
-typedef struct
-{
- SCSI3Addr_struct FCP_Nexus;
- __u8 cdb[16];
-} PassThru_Command_struct;
-*/
-
/* this is nearly duplicated in idashare.h */
typedef struct {
int lc; /* Controller number */
@@ -73,9 +32,6 @@
#define VENDOR_READ_OPCODE 0x26
#define VENDOR_WRITE_OPCODE0x27
-#define CPQFCTS_GETPCIINFO _IOR( CCPQFCTS_IOC_MAGIC, 1, cpqfc_pci_info_struct)
-#define CPQFCTS_GETDRIVVER _IOR( CCPQFCTS_IOC_MAGIC, 9, DriverVer_type)
-
#define CPQFCTS_SCSI_PASSTHRU _IOWR( CCPQFCTS_IOC_MAGIC,11, VENDOR_IOCTL_REQ)
/* We would rather have equivalent generic, low-level driver agnostic
@@ -91,4 +47,3 @@
/* Used to invoke Target Defice Reset for Fibre Channel */
// #define CPQFC_IOCTL_FC_TDR 0x5388
#define CPQFC_IOCTL_FC_TDR _IO( CCPQFCTS_IOC_MAGIC, 15)
-
--- a/drivers/scsi/cpqfcTSinit.c2005-08-14 15:05:57.0 +0200
+++ b/drivers/scsi/cpqfcTSinit.c2005-08-14 16:13:17.0 +0200
@@ -659,40 +659,6 @@ int cpqfcTS_ioctl( struct scsi_device *S
return result;
}
- case CPQFCTS_GETPCIINFO:
- {
- cpqfc_pci_info_struct pciinfo;
-
- if( !arg)
- return -EINVAL;
-
-
-
-pciinfo.bus = cpqfcHBAdata->PciDev->bus->number;
-pciinfo.dev_fn = cpqfcHBAdata->PciDev->devfn;
- pciinfo.board_id = cpqfcHBAdata->PciDev->device |
- (cpqfcHBAdata->PciDev->vendor <<16);
-
-if(copy_to_user( arg, &pciinfo, sizeof(cpqfc_pci_info_struct)))
- return( -EFAULT);
-return 0;
- }
-
- case CPQFCTS_GETDRIVVER:
- {
- DriverVer_type DriverVer =
- CPQFCTS_DRIVER_VER( VER_MAJOR,VER_MINOR,VER_SUBMINOR);
-
- if( !arg)
- return -EINVAL;
-
-if(copy_to_user( arg, &DriverVer, sizeof(DriverVer)))
- return( -EFAULT);
-return 0;
- }
-
-
-
case CPQFC_IOCTL_FC_TARGET_ADDRESS:
// can we find an FC device mapping to this SCSI target?
/* DumCmnd.channel = ScsiDev->channel; */ // For searching
-
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-rc6] remove dead reset function from cpqfcTS driver
cpqfcTS_reset() is never referenced from anywhere. By using the nonexistent
constant SCSI_RESET_ERROR it causes just another unneeded compile error.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
--- a/drivers/scsi/cpqfcTSinit.c2005-08-13 09:34:20.0 +0200
+++ b/drivers/scsi/cpqfcTSinit.c2005-08-13 10:36:19.0 +0200
@@ -1693,16 +1695,6 @@ int cpqfcTS_eh_device_reset(Scsi_Cmnd *C
return retval;
}
-
-int cpqfcTS_reset(Scsi_Cmnd *Cmnd, unsigned int reset_flags)
-{
-
- ENTER("cpqfcTS_reset");
-
- LEAVE("cpqfcTS_reset");
- return SCSI_RESET_ERROR; /* Bus Reset Not supported */
-}
-
/* This function determines the bios parameters for a given
harddisk. These tend to be numbers that are made up by the
host adapter. Parameters:
--- a/drivers/scsi/cpqfcTS.h2005-08-07 20:18:56.0 +0200
+++ b/drivers/scsi/cpqfcTS.h2005-08-13 14:02:44.0 +0200
@@ -9,7 +9,6 @@ extern const char * cpqfcTS_info(struct
extern int cpqfcTS_proc_info(struct Scsi_Host *, char *, char **, off_t, int,
int);
extern int cpqfcTS_queuecommand(Scsi_Cmnd *, void (* done)(Scsi_Cmnd *));
extern int cpqfcTS_abort(Scsi_Cmnd *);
-extern int cpqfcTS_reset(Scsi_Cmnd *, unsigned int);
extern int cpqfcTS_eh_abort(Scsi_Cmnd *Cmnd);
extern int cpqfcTS_eh_device_reset(Scsi_Cmnd *);
extern int cpqfcTS_biosparam(struct scsi_device *, struct block_device *,
-
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: Kernel 2.6.5 - Compaq Fibre Channel 64-bit/66Mhz HBA [PATCH]
Bolke de Bruin wrote: >Rolf Eike Beer wrote: >>If I can still help you then depends on >>your scheduling of this job. I'll try to do some hacking at the weekends. > >Does this mean you will not have time until October 5th or just time in >the weekend until that time? For the moment my weekends are more or less "free time to hack". My thesis is some hardware design, I don't have the tools at home so there is little I can do at the weekend. This will change in september I think, then I will TeX all day ;) >>Nevertheless without access to the hardware it will be a bit difficult. >> Much more than compile-testing is not possible for me. > >Access to hardware can be arranged Testing will very likely include crashing the machine more than once and doing some nasty things with the attached storage. Someone will have to plug the wire out of it while accessing the storage, reboot the switch and such stuff. This can really hurt in a production environment. >>I'll send some more cleanups to this driver in a few minutes (I'll CC you). >>What has to be done from my point of view is: >> >>-split up the interrupt handler in one small interrupt handler and one >> tasklet that does the actual work. I have a patch that would do this but >> I'm not familiar with this stuff. There are probably some bugs. >>-fix the stack abuse. I already sent a patch, this has to be made a bit >> nicer and better. >>-change the probe/remove stuff to use Linux 2.6 API. This is optional, but >> I think it will make this piece of dirt a bit cleaner ;) >>-the stopping of the kernel thread for every controller is a bit messy. >> There is a cleaner (and simpler) API in Linux 2.6 so this should also be >> adjusted. Not really critical, but it makes a lot of sense IMHO. >>-there is not much error checking. From my point of view there is to much >>trust in that everything is ok which can lead to serious trouble if the >> link sends you crap. > >For us everything more or less comes down to:is this feasible? I'm sure it is. >Currently we have three options: > >- Keep the current windows platform and not use 'full strength' of the >hardware (sunv20z), though controller and array will be EOL'd pretty >shortly by HP Before you throw it away send it to me ;) I like to have some obscure hardware around. >- Use a different controller (fyi HP's FCA2214) which needs a converter >for the GBIC's (2gb --> 1gb). And will be unsupported by HP Ugly. >- Sponsor someone (you) to update the driver to support 2.6 / amd64 in a >trusted fashion *g* >So for us it is little bit of risk management (jug :-) ) and we are >trying to find out our best option. I think the main stuff could be done in a week or two. My problem is that I can't test it on my own (and it's likely to do some bad things with data behind it) and that I would like to have someone experienced to review what I do. I'll keep sending this stuff to linux-scsi, but I have no reaction from anyone there. I hope they will wake up when the interesting stuff comes ;) Eike pgpgH6wkNPvtY.pgp Description: PGP signature
Re: Kernel 2.6.5 - Compaq Fibre Channel 64-bit/66Mhz HBA [PATCH]
Bolke de Bruin wrote:
>So the basic question is. Does this controller work on kernel 2.6.5?
Don't think about it. This thing is a mess. I tried to remove the #errors
(which was rather simple) and replace them by kmalloc(). Of course then
someone should care about ENOMEM case. One function had no problem at all, the
huge buffer can be avoided at all. The other one is called from an interrupt
handler. This thing tries to handle the complete packet transfer in the
interrupt. Don't use it. It will blow up.
If someone has some spare time this interrupt handler has to be split up. Here
is a diff of what I've done so far. To apply this one you will have to use my
two patches sent in the last days first, the subject lines are
[PATCH 2.6.13-rc5] reduce whitespace bloat in drivers/scsi/cpqfcTScontrol.c
[PATCH 2.6.13-rc5] rewrite drivers/scsi/cpqfcTScontrol.c::CpqTsGetSFQEntry
This patch also kills cpqfcTS_reset() function which is never referenced to.
It causes a compile error by using SCSI_RESET_ERROR, which is undefined (now?).
Eike
--- a/drivers/scsi/cpqfcTScontrol.c 2005-08-11 19:04:26.0 +0200
+++ b/drivers/scsi/cpqfcTScontrol.c 2005-08-11 19:28:05.0 +0200
@@ -556,27 +556,21 @@ static int PeekIMQEntry( PTACHYON fcChip
// first, we need to find an Inbound Completion message,
// If we find it, check the incoming frame payload (1st word)
// for LILP frame
-if( (fcChip->IMQ->QEntry[CI].type & 0x1FF) == 0x104 )
-{
- TachFCHDR_GCMND* fchs;
-#error This is too much stack
- ULONG ulFibreFrame[2048/4]; // max DWORDS in incoming FC Frame
- ULONG SFQpi = fcChip->IMQ->QEntry[CI].word[0] & 0x0fffL;
-
- CpqTsGetSFQEntry( fcChip,
-SFQpi,// SFQ producer ndx
- ulFibreFrame, 0); // DON'T update chip--this is a
"lookahead"
+ if( (fcChip->IMQ->QEntry[CI].type & 0x1FF) == 0x104 ) {
+ TachFCHDR_GCMND *fchs;
- fchs = (TachFCHDR_GCMND*)&ulFibreFrame;
- if( fchs->pl[0] == ELS_LILP_FRAME)
- {
-return 1; // found the LILP frame!
- }
- else
- {
- // keep looking...
- }
- }
+ /* Reference to the first chunk of this struct in QEntry
+* buffer. We can only rely on the first 64 bytes of
+* data because consumerIndex may have a wraparound.
+* This is no problem, we only want to see the first
+* double word of payload, which is within this range.
+*/
+ fchs = (TachFCHDR_GCMND*)
&fcChip->SFQ->QEntry[fcChip->SFQ->consumerIndex];
+
+ if(fchs->pl[0] == ELS_LILP_FRAME) {
+ return 1;
+ }
+ }
}
break;
@@ -665,8 +659,7 @@ int CpqTsProcessIMQEntry(void *host)
ULONG x_ID;
ULONG ulBuff, dwStatus;
TachFCHDR_GCMND* fchs;
-#error This is too much stack
- ULONG ulFibreFrame[2048/4]; // max number of DWORDS in incoming Fibre Frame
+ void *ulFibreFrame = kmalloc(2048, GFP_KERNEL); /* max number of DWORDS in
incoming Fibre Frame */
UCHAR ucInboundMessageType; // Inbound CM, dword 3 "type" field
ENTER("ProcessIMQEntry");
@@ -675,6 +668,9 @@ int CpqTsProcessIMQEntry(void *host)
// is a new message waiting for us?
// equal indexes means empty que
+ if (!ulFibreFrame)
+ return -ENOMEM;
+
if( fcChip->IMQ->producerIndex != fcChip->IMQ->consumerIndex )
{ // need to process message
@@ -881,7 +877,7 @@ int CpqTsProcessIMQEntry(void *host)
if( ucInboundMessageType == 1 )
{
-fchs = (TachFCHDR_GCMND*)ulFibreFrame; // cast to examine IB frame
+fchs = ulFibreFrame; // cast to examine IB frame
// don't fill up our Q with garbage - only accept FCP-CMND
// or XRDY frames
if( (fchs->d_id & 0xFF00) == 0x0600 ) // CMND
@@ -1432,7 +1428,7 @@ int CpqTsProcessIMQEntry(void *host)
// to analyze data transfer (successful?), then send a response
// frame for this exchange
- ulFibreFrame[0] = x_ID; // copy for later reference
+ *((ULONG*) ulFibreFrame) = x_ID; // copy for later reference
// if this was a TWE, we have to send satus response
if( Exchanges->fcExchange[ x_ID].type == SCSI_TWE )
@@ -1500,6 +1496,7 @@ int CpqTsProcessIMQEntry(void *host)
LEAVE("ProcessIMQEntry");
+ kfree(ulFibreFrame);
return iStatus;
}
--- a/drivers/scsi/cpqfcTSstructs.h 2005-08-11 19:30:55.0 +0200
+++ b/drivers/scsi/cpqfcTSstructs.h 2005-08-11 19:31:31.0 +0200
@@ -813,7 +813,6 @@ typedef struct
void (*UnFreezeTachyon)(void*, int );
int (*InitializeTachyon)(void*, int
Re: Kernel 2.6.5 - Compaq Fibre Channel 64-bit/66Mhz HBA
Am Donnerstag, 11. August 2005 18:41 schrieben Sie: >>arrays allocated by the driver eat 2kB each, so a stack overflow is very >>likely. Even with 8kB stack it is still not impossible. Using the version >>from 2.6.5 will not be a very good idea I think, it's likely to crash your >>machine one day. >> >:-( >: >>The right solution would be fixing the driver to use kmalloc()/kfree() when >> he really needs the memory. There was a patch only a few days ago that >> tried to do that, but it was not really well done and would have crashed. >> If you are really interested in I can do such a patch. The code of this >> driver sucks universes through nanotubes, but one day someone _will_ have >> to start cleaning this up. > >Define: really interested > >So, probably we are really interested. Though there are a couple of caveats: > >- Testing can be done only very limited. We have only one raid array >available and it is in production If whatever I do will go wrong you'll see it very fast. Then you can't receive data ;) >- Servers are not in yet, but will been in the next couple of weeks >- As Arjan noted the kernel will be "some vendor 2.6.5". More precisely >sles9 or rhle 3. This is dictated by the setup of informix 10 on those >machines, we are stuck with that unfortunately. To be really interesting >a patch should be backportable to 2.6.5 (or the equivalent rh kernel). This should be rather simple. Just use their kernel sources, copy the files from a newer kernel in and rebuild the module. >- I am currently investigating if other controllers are able to support >this raid array and are supported. If so it might be a better idea to >use those Yes, if you find some which have a driver that smells less it would be a good idea to use them. >- We are willing to offer something in exchange. This ranges from 24 >bottles of beer of your choice to something else. The something else >part needs to be discussed, but the beer part I can be held responsible >for :-) *g* I'll remind you ;) Eike pgpUx8zz6CDta.pgp Description: PGP signature
Re: Kernel 2.6.5 - Compaq Fibre Channel 64-bit/66Mhz HBA
Bolke de Bruin wrote: >So the basic question is. Does this controller work on kernel 2.6.5? The problem is that the default stack size was reduced to 4kB. The local arrays allocated by the driver eat 2kB each, so a stack overflow is very likely. Even with 8kB stack it is still not impossible. Using the version from 2.6.5 will not be a very good idea I think, it's likely to crash your machine one day. The right solution would be fixing the driver to use kmalloc()/kfree() when he really needs the memory. There was a patch only a few days ago that tried to do that, but it was not really well done and would have crashed. If you are really interested in I can do such a patch. The code of this driver sucks universes through nanotubes, but one day someone _will_ have to start cleaning this up. Eike pgpN8Op1BmpEY.pgp Description: PGP signature
[PATCH 2.6.13-rc5] rewrite drivers/scsi/cpqfcTScontrol.c::CpqTsGetSFQEntry
This patch applies on top of my previous one that removed the whitespace
bloat.
This patch now fixes the type horror in CpqTsGetSFQEntry():
-the destination buffer is now void* instead of ULONG*
-the offset is now done by a int (former ULONG) variable and not
adding bytes to the pointer address
-the last argument is not int, not boolean
-the second argument is compared to ULONG but is USHORT. And one (of two)
callers passes a ULONG casted to USHORT. Use ULONG instead.
-remove some of the comments
-don't use argument names in functions forward declaration: they don't match
the actual names anyway
While I'm at it, I fixed the coding style of this function. The rest of the
file is is still horror, but this no excuse for not fixing this function.
This shrinks the file by another 500 bytes and should not make any difference
in function.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
--- 2.6.13-rc6/drivers/scsi/cpqfcTScontrol.c2005-08-09 17:39:49.0
+0200
+++ b/drivers/scsi/cpqfcTScontrol.c 2005-08-09 17:49:41.0 +0200
@@ -52,8 +52,7 @@
//#define IMQ_DEBUG 1
static void fcParseLinkStatusCounters(TACHYON * fcChip);
-static void CpqTsGetSFQEntry(TACHYON * fcChip,
- USHORT pi, ULONG * buffr, BOOLEAN UpdateChip);
+static void CpqTsGetSFQEntry(TACHYON *, ULONG, void*, int);
static void
cpqfc_free_dma_consistent(CPQFCHBA *cpqfcHBAdata)
@@ -562,12 +561,11 @@ static int PeekIMQEntry( PTACHYON fcChip
TachFCHDR_GCMND* fchs;
#error This is too much stack
ULONG ulFibreFrame[2048/4]; // max DWORDS in incoming FC Frame
- USHORT SFQpi = (USHORT)(fcChip->IMQ->QEntry[CI].word[0] & 0x0fffL);
+ ULONG SFQpi = (fcChip->IMQ->QEntry[CI].word[0] & 0x0fffL);
CpqTsGetSFQEntry( fcChip,
SFQpi,// SFQ producer ndx
- ulFibreFrame, // contiguous dest. buffer
- FALSE); // DON'T update chip--this is a "lookahead"
+ ulFibreFrame, 0); // DON'T update chip--this is a
"lookahead"
fchs = (TachFCHDR_GCMND*)&ulFibreFrame;
if( fchs->pl[0] == ELS_LILP_FRAME)
@@ -875,8 +873,8 @@ int CpqTsProcessIMQEntry(void *host)
// clears SFQ entry from Tachyon buffer; copies to contiguous ulBuff
CpqTsGetSFQEntry(
fcChip, // i.e. this Device Object
-(USHORT)fcChip->SFQ->producerIndex, // SFQ producer ndx
-ulFibreFrame, TRUE);// contiguous destination buffer, update chip
+ fcChip->SFQ->producerIndex, // SFQ producer ndx
+ ulFibreFrame, 1);// contiguous destination buffer, update
chip
// analyze the incoming frame outside the INT handler...
// (i.e., Worker)
@@ -1739,57 +1737,54 @@ int CpqTsDestroyTachLiteQues( void *pHBA
return iStatus; // non-zero (failed) if any memory not freed
}
-// The SFQ is an array with SFQ_LEN length, each element (QEntry)
-// with eight 32-bit words. TachLite places incoming FC frames (i.e.
-// a valid FC frame with our AL_PA ) in contiguous SFQ entries
-// and sends a completion message telling the host where the frame is
-// in the que.
-// This function copies the current (or oldest not-yet-processed) QEntry to
-// a caller's contiguous buffer and updates the Tachyon chip's consumer index
-//
-// NOTE:
-// An FC frame may consume one or many SFQ entries. We know the total
-// length from the completion message. The caller passes a buffer large
-// enough for the complete message (max 2k).
-
-static void CpqTsGetSFQEntry(
- PTACHYON fcChip,
- USHORT producerNdx,
- ULONG *ulDestPtr,// contiguous destination buffer
-BOOLEAN UpdateChip)
+/**
+ * CpqTsGetSFQEntry
+ * @dest: contiguous destination buffer
+ *
+ *The SFQ is an array with SFQ_LEN length, each element (QEntry)
+ * with eight 32-bit words. TachLite places incoming FC frames (i.e.
+ * a valid FC frame with our AL_PA ) in contiguous SFQ entries
+ * and sends a completion message telling the host where the frame is
+ * in the queue.
+ * This function copies the current (or oldest not-yet-processed) QEntry to
+ * a caller's contiguous buffer and updates the Tachyon chip's consumer index
+ *
+ * NOTE:
+ * An FC frame may consume one or many SFQ entries. We know the total
+ * length from the completion message. The caller passes a buffer large
+ * enough for the complete message (max 2k).
+ */
+static void
+CpqTsGetSFQEntry(PTACHYON fcChip, ULONG producerNdx, void *ulDestPtr,
+ int UpdateChip)
{
- ULONG total_bytes=0;
- ULONG consumerIndex = fcChip->SFQ->consumerIndex;
-
- // check passed copy of SFQ producer index -
- // is a new message waiting for us?
- // equal indexes means SFS is c
[PATCH 2.6.13-rc6] Fix handling in parport_pc init code
parport_pc_find_ports():
r = pci_register_driver (&parport_pc_pci_driver);
if (r)
return r;
The only caller of parport_pc_find_ports() is parport_pc_init(), which has:
count += parport_pc_find_ports (irqval[0], dmaval[0]);
return 0;
This assignment is totally useless as count is local and never used again. Bad
thing is that module_init succeeds but something really bad had happened to
pci_register_driver() before (e.g. ENOMEM or something).
Also module_init does not fail if pnp_register_driver() fails. And the return
code of pnp_register_driver() can never be >0, if there are initial matches 0
is returned.
Why is parport_pc_find_isa_ports() marked as ((unused)) when it is used by
asm/parport.h? Shouldn't this be ((used)) to tell the compiler that this static
function has references to it that he might not see? I left this the way it is
if there is some magic I missed.
The return code of this function is of no interest, I did not touch it for now
because I don't wanted to change all the header files, I just changed it to
always return 0.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
--- linux-2.6.13-rc3/drivers/parport/parport_pc.c 2005-07-13
06:46:46.0 +0200
+++ linux-2.6.13-rc6/drivers/parport/parport_pc.c 2005-08-08
14:59:50.0 +0200
@@ -3096,16 +3096,11 @@ static struct pnp_driver parport_pc_pnp_
static int __devinit __attribute__((unused))
parport_pc_find_isa_ports (int autoirq, int autodma)
{
- int count = 0;
+ parport_pc_probe_port(0x3bc, 0x7bc, autoirq, autodma, NULL);
+ parport_pc_probe_port(0x378, 0x778, autoirq, autodma, NULL);
+ parport_pc_probe_port(0x278, 0x678, autoirq, autodma, NULL);
- if (parport_pc_probe_port(0x3bc, 0x7bc, autoirq, autodma, NULL))
- count++;
- if (parport_pc_probe_port(0x378, 0x778, autoirq, autodma, NULL))
- count++;
- if (parport_pc_probe_port(0x278, 0x678, autoirq, autodma, NULL))
- count++;
-
- return count;
+ return 0;
}
/* This function is called by parport_pc_init if the user didn't
@@ -3120,7 +3115,7 @@ parport_pc_find_isa_ports (int autoirq,
*/
static int __init parport_pc_find_ports (int autoirq, int autodma)
{
- int count = 0, r;
+ int r;
#ifdef CONFIG_PARPORT_PC_SUPERIO
detect_and_report_winbond ();
@@ -3128,27 +3123,26 @@ static int __init parport_pc_find_ports
#endif
/* Onboard SuperIO chipsets that show themselves on the PCI bus. */
- count += parport_pc_init_superio (autoirq, autodma);
-
/* PnP ports, skip detection if SuperIO already found them */
- if (!count) {
+ if (!parport_pc_init_superio(autoirq, autodma)) {
r = pnp_register_driver (&parport_pc_pnp_driver);
- if (r >= 0) {
+ if (!r) {
pnp_registered_parport = 1;
- count += r;
- }
+ } else
+ return r;
}
/* ISA ports and whatever (see asm/parport.h). */
- count += parport_pc_find_nonpci_ports (autoirq, autodma);
+ parport_pc_find_nonpci_ports(autoirq, autodma);
r = pci_register_driver (&parport_pc_pci_driver);
- if (r)
+ if (r) {
+ pnp_unregister_driver(&parport_pc_pnp_driver);
return r;
+ }
pci_registered_parport = 1;
- count += 1;
- return count;
+ return 0;
}
/*
@@ -3373,8 +3367,6 @@ __setup("parport_init_mode=",parport_ini
static int __init parport_pc_init(void)
{
- int count = 0;
-
if (parse_parport_params())
return -EINVAL;
@@ -3387,14 +3379,12 @@ static int __init parport_pc_init(void)
break;
if ((io_hi[i]) == PARPORT_IOHI_AUTO)
io_hi[i] = 0x400 + io[i];
- if (parport_pc_probe_port(io[i], io_hi[i],
- irqval[i], dmaval[i], NULL))
- count++;
+ parport_pc_probe_port(io[i], io_hi[i],
+ irqval[i], dmaval[i], NULL);
}
+ return 0;
} else
- count += parport_pc_find_ports (irqval[0], dmaval[0]);
-
- return 0;
+ return parport_pc_find_ports(irqval[0], dmaval[0]);
}
static void __exit parport_pc_exit(void)
-
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 1/2] cpqfc: fix for "Using too much stach" in 2.6 kernel
Dave Jones wrote: >On Thu, Aug 04, 2005 at 05:56:14PM +0200, Rolf Eike Beer wrote: > > Am Donnerstag, 4. August 2005 17:40 schrieb Dave Jones: > > >On Thu, Aug 04, 2005 at 11:38:30AM +0200, Rolf Eike Beer wrote: > > > > >+ulFibreFrame = kmalloc((2048/4), GFP_KERNEL); > > > > > > > > The size bug was already found by Dave Jones. This never should be > > > > written this way (not your fault). The array should have been > > > > [2048/sizeof(ULONG)]. > > > > > >wasteful. We only ever use 2048 bytes of this array, so doubling > > >its size on 64bit is pointless, unless you make changes later on > > >in the driver. (Which I think don't make sense, as we just copy > > >32 64byte chunks). > > > > No, this is how it should have been before. This way it would have been > > clear where the magic 4 came from. > >It's pointless to fix this, without fixing also CpqTsGetSFQEntry() >... At least half of the file should be rewritten. > > >we're trashing the last 48 bytes of every copy we make. > > >Does this driver even work ? > > > > No, ulDestPtr ist ULONG* so we increase it by sizeof(ULONG)*16 which is > > 64. > >Duh, yes. That is broken on 64-bit however, where it will advance 128 bytes >instead of 64 bytes. ULONG is defined to __u32 in some of the cpq* headers. Eike pgpFBEcZOTHsq.pgp Description: PGP signature
Re: [PATCH 1/2] cpqfc: fix for "Using too much stach" in 2.6 kernel
Am Donnerstag, 4. August 2005 17:40 schrieb Dave Jones:
>On Thu, Aug 04, 2005 at 11:38:30AM +0200, Rolf Eike Beer wrote:
> > >+ulFibreFrame = kmalloc((2048/4), GFP_KERNEL);
> >
> > The size bug was already found by Dave Jones. This never should be
> > written this way (not your fault). The array should have been
> > [2048/sizeof(ULONG)].
>
>wasteful. We only ever use 2048 bytes of this array, so doubling
>its size on 64bit is pointless, unless you make changes later on
>in the driver. (Which I think don't make sense, as we just copy
>32 64byte chunks).
No, this is how it should have been before. This way it would have been clear
where the magic 4 came from.
>Ermm, actually this looks totally bogus..
>CpqTsGetSFQEntry() ...
>
>if( total_bytes <= 2048 )
>{
> memcpy( ulDestPtr,
> &fcChip->SFQ->QEntry[consumerIndex],
> 64 ); // each SFQ entry is 64 bytes
> ulDestPtr += 16; // advance pointer to next 64 byte block
>}
>
>we're trashing the last 48 bytes of every copy we make.
>Does this driver even work ?
No, ulDestPtr ist ULONG* so we increase it by sizeof(ULONG)*16 which is 64.
This is one of the places I was talking about where people might miss what's
going on. ;) IMHO it makes absolutely no sense to use a ULONG* at this place.
Eike
pgpMOUVwTeQkP.pgp
Description: PGP signature
Re: [PATCH 1/2] cpqfc: fix for "Using too much stach" in 2.6 kernel
Saripalli, Venkata Ramanamurthy (STSD) wrote:
>Patch 1 of 2
>
>This patch fixes the "#error this is too much stack" in 2.6 kernel.
>Using kmalloc to allocate memory to ulFibreFrame.
Good idea.
>Please consider this for inclusion
Your patch is line-wrapped and can't be applied. Your second patch is also
line wrapped. And it touches this file in a different way so they can't be
applied cleanly over each other.
>diff -burpN old/drivers/scsi/cpqfcTScontrol.c
>new/drivers/scsi/cpqfcTScontrol.c
>--- old/drivers/scsi/cpqfcTScontrol.c 2005-07-12 22:52:29.0
>+0530
>+++ new/drivers/scsi/cpqfcTScontrol.c 2005-07-18 22:19:54.229947176
>+0530
>@@ -606,22 +606,25 @@ static int PeekIMQEntry( PTACHYON fcChip
> if( (fcChip->IMQ->QEntry[CI].type & 0x1FF) == 0x104 )
> {
> TachFCHDR_GCMND* fchs;
>-#error This is too much stack
>- ULONG ulFibreFrame[2048/4]; // max DWORDS in incoming FC
>Frame
>+ ULONG *ulFibreFrame; // max DWORDS in incoming FC Frame
> USHORT SFQpi = (USHORT)(fcChip->IMQ->QEntry[CI].word[0] &
>0x0fffL);
Why not use a void* here as type for the buffer? Or even better: remove this
at all and directly use fchs as target, because this is the only place where
this buffer goes to?
>+ulFibreFrame = kmalloc((2048/4), GFP_KERNEL);
The size bug was already found by Dave Jones. This never should be written
this way (not your fault). The array should have been [2048/sizeof(ULONG)].
> CpqTsGetSFQEntry( fcChip,
> SFQpi,// SFQ producer ndx
> ulFibreFrame, // contiguous dest. buffer
> FALSE); // DON'T update chip--this is a "lookahead"
CpqTsGetSFQEntry() should be modified to take a void* as third argument IMHO.
>-fchs = (TachFCHDR_GCMND*)&ulFibreFrame;
>+fchs = (TachFCHDR_GCMND*)ulFibreFrame;
> if( fchs->pl[0] == ELS_LILP_FRAME)
> {
>+ kfree(ulFibreFrame);
> return 1; // found the LILP frame!
> }
> else
> {
>+ kfree(ulFibreFrame);
> // keep looking...
> }
> }
What a ...
I would prefer if someone goes and really cleans up this driver.
-read Documentation/Codingstyle
-go through Lindent.
-kill this ULONG stuff. If you want __u32 use it.
-use void* for "just a buffer"
-don't use hardcoded type sizes. Use sizeof(type) to make clear what kind of
magic is going on.
-this is C, not C++. No C++ comments, use fewer uppercase letters.
The way it is is very likely to cause people missing what's really going on at
some places, which will cause errors afterwards.
Eike
pgpdH3O8o3ldS.pgp
Description: PGP signature
Re: Documentation - how to apply patches for various trees
Jesper Juhl wrote: >+The 2.6.x.y (-stable) and 2.6.x patches live at >+ ftp://ftp.kernel.org/pub/linux/kernel/v2.6/ >+ >+The -rc patches live at >+ ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/ >+ >+The -git patches live at >+ ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/ >+ >+The -mm kernels live at >+ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/ ^ To be consistent you must add a space here. Eike pgp0fJOY0dFcA.pgp Description: PGP signature
Re: Documentation - how to apply patches for various trees
Jesper Juhl wrote: >+Where can I download the patches? Maybe it would be useful to once again mention that local mirrors should be used at least for stable releases and */testing/*. >+The 2.6.x kernels [...] >+# moving from 2.6.11 to 2.6.12 >+$ cd ~/linux-2.6.11 # change to kernel source dir >+$ patch -p1 < ../patch-2.6.12 # apply the 2.6.12 patch patch also nows "-i": patch -p1 -i ../patch-2.6.12 More likely the user will get the patch compressed either with bzip2 or gzip, so I think it would be useful to tell once more how to apply such a patch: bzcat ../patch-2.6.12.bz2 | patch -p1 >+The 2.6.x.y kernels >+$ cd ~/linux-2.6.12.2 # change into the kernel source dir >+$ patch -p1 -R < ../patch-2.6.12.2# revert the 2.6.12.2 patch >+$ patch -p1 < ../patch-2.6.12.3 # apply the new 2.6.12.3 patch >+$ cd .. >+$ mv linux-2.6.12.2 linux-2.6.12.3# rename the kernel source dir The better way would probably be to use interdiff. Another goodie is that interdiff knows about -z: cd ~/linux-2.6.12.2 interdiff -z ../patch-2.6.12.2.bz2 ../patch-2.6.12.3.gz | patch -p1 This should only be shown as "another way" to do so. Sometimes interdiff get's confused and breaks things, although this is very unlikely for the stable diffs. >+The -mm kernels >+ These kernels in >+ addition to all the other experimental patches they contain usually also >+ contain any changes in the mainline -git kernels available at the time of >+ release. These two "contain"'s that close to each user are likely to confuse. In a German text I would but a comma before "in addition" and behind the first "contain", don't know what the rules for this are in English. Eike pgpO3TPl0gsRj.pgp Description: PGP signature
[PATCH 2.6.13-rc3-git4] watchdog: add missing 0x in alim1535_wdt.c
Hi,
usually the device IDs are given in hex. This one is a bit strange: it is
without 0x in the first place and used with it some lines later. I suspect the
first one to be the wrong. Patch attached.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
--- a/drivers/char/watchdog/alim1535_wdt.c 2005-07-22 01:17:42.0
+0200
+++ b/drivers/char/watchdog/alim1535_wdt.c 2005-07-22 01:17:52.0
+0200
@@ -317,7 +317,7 @@ static int ali_notify_sys(struct notifie
*/
static struct pci_device_id ali_pci_tbl[] = {
- { PCI_VENDOR_ID_AL, 1535, PCI_ANY_ID, PCI_ANY_ID,},
+ { PCI_VENDOR_ID_AL, 0x1535, PCI_ANY_ID, PCI_ANY_ID,},
{ 0, },
};
MODULE_DEVICE_TABLE(pci, ali_pci_tbl);
-
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] remove unneeded indentation in drivers/char/watchdog/i8xx_tco.c
Nils Faerber wrote: >Rolf Eike Beer schrieb: >> this patch changes a bit of indentation. Currently it is >> [...] >> Also some superfluous spaces are killed to match Codingstyle > >Don't know who added those strange things ;) >But looks OK to me to change it this way. > >So please go ahead and forward this patch. In this case add a Signed-off-by. Eike pgpW5brm8jKkx.pgp Description: PGP signature
Re: [PATCH] Remove Comtrol mail address from MAINTAINERS [next 1 address]
Am Donnerstag, 21. Juli 2005 01:43 schrieb Jiri Slaby: >Rolf Eike Beer wrotes: >>Send a patch, you know the addresses. > >kernel 2.6.13-rc3-git4 > >Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> > >--- a/MAINTAINERS 2005-07-21 01:13:32.0 +0200 >+++ b/MAINTAINERS 2005-07-21 01:17:41.0 +0200 >@@ -204,8 +204,6 @@ > > ADVANSYS SCSI DRIVER > P: Bob Frey >-M:[EMAIL PROTECTED] >-W:http://www.advansys.com/linux.html > L: linux-scsi@vger.kernel.org > S: Maintained Please do not remove this mail address until you have verified that it really does not exist and is not only rejected due to the broken mail setup of advansys.com. Removing the website is ok. The mail address you can remove is [EMAIL PROTECTED] Eike pgpjjh29fgUkL.pgp Description: PGP signature
Re: [PATCH] Remove Comtrol mail address from MAINTAINERS
Am Mittwoch, 20. Juli 2005 14:12 schrieb Jiri Slaby: >Rolf Eike Beer napsal(a): >>Every Mail to this address produces a mail telling that they do no longer >>monitor this address and you should use their webinterface. >> >>"We are pleased to offer this powerful replacement to standard email >> support." >> >>Some people just don't understand. >> >>Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> >> >>--- linux-2.6.13-rc3/MAINTAINERS 2005-07-20 09:05:30.0 +0200 >>+++ linux-2.6.13-rc3-eike/MAINTAINERS 2005-07-20 09:13:40.0 +0200 >>@@ -1934,7 +1934,6 @@ >> >> ROCKETPORT DRIVER >> P: Comtrol Corp. >>-M: [EMAIL PROTECTED] >> W: http://www.comtrol.com >> S: Maintained > >And you can remove these: > >... while talking to advansys.com <http://advansys.com>.: > >>> DATA > ><<< 550 5.7.1 <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>... >Relaying denied. Proper authentication required. Looks like the admin of their mail setup should ask someone who knows what he does. >550 5.1.1 <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>... User unknown ><<< 503 5.0.0 Need RCPT (recipient) This is just if your mailer uses PIPELINING and sent a DATA before getting the reply to RCPT TO: >... while talking to ali.ali.com.tw <http://ali.ali.com.tw>.: > >>> RCPT To:<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > ><<< 550 unknown user. >550 5.1.1 <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>... User unknown Send a patch, you know the addresses. Eike pgpHvRUd4MNNV.pgp Description: PGP signature
Re: [PATCH] pci_find_device --> pci_get_device
Jiri Slaby wrote:
>Rolf Eike Beer napsal(a):
>>Am Mittwoch, 20. Juli 2005 12:40 schrieb Jiri Slaby:
>>>Rolf Eike Beer napsal(a):
>>>>Your patch to arch/sparc64/kernel/ebus.c is broken, the removed and added
>>>>parts do not match in behaviour.
>>>
>>>I can't still see the difference.
>>
>>diff --git a/arch/sparc64/kernel/ebus.c b/arch/sparc64/kernel/ebus.c
>>--- a/arch/sparc64/kernel/ebus.c
>>+++ b/arch/sparc64/kernel/ebus.c
>>@@ -527,8 +527,15 @@ static struct pci_dev *find_next_ebus(st
>> {
>> struct pci_dev *pdev = start;
>>
>>- do {
>>- pdev = pci_find_device(PCI_VENDOR_ID_SUN, PCI_ANY_ID, pdev);
>>+while (pdev = pci_get_device(PCI_VENDOR_ID_SUN, PCI_ANY_ID, pdev))
>>+ if (pdev->device == PCI_DEVICE_ID_SUN_EBUS ||
>>+ pdev->device == PCI_DEVICE_ID_SUN_RIO_EBUS)
>>+ break;
>>+ *is_rio_p = !!(pdev && (pdev->device == PCI_DEVICE_ID_SUN_RIO_EBUS));
>>+
>>+/* do { // BEFORE \/ AFTER ^
This looks like some sed command went wrong. And I missed that you were
starting a comment here.
>Is there any difference? I don't see any, but... The reading of diff
>file in this case is not the best, maybe...
Yes, that was the problem. I would prefer if you could just remove the code
instead of commenting it out. This would have made this clearer.
If my editor doesn't fool me you are using spaces for indentation of the
while. There has to be a tab.
Question to the sparc folks: is it really needed to preserve the order of the
ebusses? Or would it be possible to do
pdev = pci_find_device(PCI_VENDOR_ID_SUN, PCI_DEVICE_ID_SUN_EBUS)
first and if this returns NULL start again with
pdev = pci_find_device(PCI_VENDOR_ID_SUN, PCI_DEVICE_ID_SUN_RIO_EBUS)
?
Eike
pgpJkMZjHYOk5.pgp
Description: PGP signature
Re: [PATCH] pci_find_device --> pci_get_device
Am Mittwoch, 20. Juli 2005 12:40 schrieb Jiri Slaby:
>Rolf Eike Beer napsal(a):
>>Your patch to arch/sparc64/kernel/ebus.c is broken, the removed and added
>>parts do not match in behaviour.
>
>I can't still see the difference.
diff --git a/arch/sparc64/kernel/ebus.c b/arch/sparc64/kernel/ebus.c
--- a/arch/sparc64/kernel/ebus.c
+++ b/arch/sparc64/kernel/ebus.c
@@ -527,8 +527,15 @@ static struct pci_dev *find_next_ebus(st
{
struct pci_dev *pdev = start;
- do {
- pdev = pci_find_device(PCI_VENDOR_ID_SUN, PCI_ANY_ID, pdev);
+while (pdev = pci_get_device(PCI_VENDOR_ID_SUN, PCI_ANY_ID, pdev))
+ if (pdev->device == PCI_DEVICE_ID_SUN_EBUS ||
+ pdev->device == PCI_DEVICE_ID_SUN_RIO_EBUS)
+ break;
+
+ *is_rio_p = !!(pdev && (pdev->device == PCI_DEVICE_ID_SUN_RIO_EBUS));
+
+/* do { // BEFORE \/ AFTER ^
+ * pdev = pci_find_device(PCI_VENDOR_ID_SUN, PCI_ANY_ID, pdev);
if (pdev &&
(pdev->device == PCI_DEVICE_ID_SUN_EBUS ||
pdev->device == PCI_DEVICE_ID_SUN_RIO_EBUS))
Eike
pgpDPcspkQ1pV.pgp
Description: PGP signature
[PATCH] remove unneeded indentation in drivers/char/watchdog/i8xx_tco.c
Hi,
this patch changes a bit of indentation. Currently it is
if (i8xx_tcp_pci) {
...
return 1;
}
return 0;
Now it will be
if (!i8xx_tcp_pci)
return 0;
...
return 1;
Also some superfluous spaces are killed to match Codingstyle.
Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>
--- linux-2.6.13-rc3/drivers/char/watchdog/i8xx_tco.c 2005-07-13
06:46:46.0 +0200
+++ linux-2.6.13-rc3-eike/drivers/char/watchdog/i8xx_tco.c 2005-07-20
10:22:18.0 +0200
@@ -391,7 +391,7 @@ MODULE_DEVICE_TABLE (pci, i8xx_tco_pci_t
* Init & exit routines
*/
-static unsigned char __init i8xx_tco_getdevice (void)
+static unsigned char __init i8xx_tco_getdevice(void)
{
struct pci_dev *dev = NULL;
u8 val1, val2;
@@ -407,47 +407,47 @@ static unsigned char __init i8xx_tco_get
}
}
- if (i8xx_tco_pci) {
- /*
-* Find the ACPI base I/O address which is the base
-* for the TCO registers (TCOBASE=ACPIBASE + 0x60)
-* ACPIBASE is bits [15:7] from 0x40-0x43
-*/
- pci_read_config_byte (i8xx_tco_pci, 0x40, &val1);
- pci_read_config_byte (i8xx_tco_pci, 0x41, &val2);
- badr = ((val2 << 1) | (val1 >> 7)) << 7;
- ACPIBASE = badr;
- /* Something's wrong here, ACPIBASE has to be set */
- if (badr == 0x0001 || badr == 0x) {
- printk (KERN_ERR PFX "failed to get TCOBASE address\n");
- return 0;
- }
- /*
-* Check chipset's NO_REBOOT bit
-*/
+ if (!i8xx_tco_pci)
+ return 0;
+
+ /*
+* Find the ACPI base I/O address which is the base
+* for the TCO registers (TCOBASE=ACPIBASE + 0x60)
+* ACPIBASE is bits [15:7] from 0x40-0x43
+*/
+ pci_read_config_byte(i8xx_tco_pci, 0x40, &val1);
+ pci_read_config_byte(i8xx_tco_pci, 0x41, &val2);
+ badr = ((val2 << 1) | (val1 >> 7)) << 7;
+ ACPIBASE = badr;
+ /* Something's wrong here, ACPIBASE has to be set */
+ if (badr == 0x0001 || badr == 0x) {
+ printk(KERN_ERR PFX "failed to get TCOBASE address\n");
+ return 0;
+ }
+ /*
+* Check chipset's NO_REBOOT bit
+*/
+ pci_read_config_byte(i8xx_tco_pci, 0xd4, &val1);
+ if (val1 & 0x02) {
+ val1 &= 0xfd;
+ pci_write_config_byte(i8xx_tco_pci, 0xd4, val1);
pci_read_config_byte (i8xx_tco_pci, 0xd4, &val1);
if (val1 & 0x02) {
- val1 &= 0xfd;
- pci_write_config_byte (i8xx_tco_pci, 0xd4, val1);
- pci_read_config_byte (i8xx_tco_pci, 0xd4, &val1);
- if (val1 & 0x02) {
- printk (KERN_ERR PFX "failed to reset NO_REBOOT
flag, reboot disabled by hardware\n");
- return 0; /* Cannot reset NO_REBOOT bit */
- }
- }
- /* Set the TCO_EN bit in SMI_EN register */
- if (!request_region (SMI_EN + 1, 1, "i8xx TCO")) {
- printk (KERN_ERR PFX "I/O address 0x%04x already in
use\n",
- SMI_EN + 1);
- return 0;
+ printk(KERN_ERR PFX "failed to reset NO_REBOOT flag,
reboot disabled by hardware\n");
+ return 0; /* Cannot reset NO_REBOOT bit */
}
- val1 = inb (SMI_EN + 1);
- val1 &= 0xdf;
- outb (val1, SMI_EN + 1);
- release_region (SMI_EN + 1, 1);
- return 1;
}
- return 0;
+ /* Set the TCO_EN bit in SMI_EN register */
+ if (!request_region(SMI_EN + 1, 1, "i8xx TCO")) {
+ printk(KERN_ERR PFX "I/O address 0x%04x already in use\n",
+ SMI_EN + 1);
+ return 0;
+ }
+ val1 = inb(SMI_EN + 1);
+ val1 &= 0xdf;
+ outb(val1, SMI_EN + 1);
+ release_region(SMI_EN + 1, 1);
+ return 1;
}
static int __init watchdog_init (void)
-
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] Remove Comtrol mail address from MAINTAINERS
Every Mail to this address produces a mail telling that they do no longer monitor this address and you should use their webinterface. "We are pleased to offer this powerful replacement to standard email support." Some people just don't understand. Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> --- linux-2.6.13-rc3/MAINTAINERS2005-07-20 09:05:30.0 +0200 +++ linux-2.6.13-rc3-eike/MAINTAINERS 2005-07-20 09:13:40.0 +0200 @@ -1934,7 +1934,6 @@ ROCKETPORT DRIVER P: Comtrol Corp. -M: [EMAIL PROTECTED] W: http://www.comtrol.com S: Maintained - 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] pci_find_device --> pci_get_device
Am Dienstag, 19. Juli 2005 17:44 schrieb Jiri Slaby:
>Rolf Eike Beer napsal(a):
>>Jiri Slaby wrote:
>>>Kernel version: 2.6.13-rc3-git4
>>>
>>>* This patch removes from kernel tree pci_find_device and changes
>>>it with pci_get_device. Next, it adds pci_dev_put, to decrease reference
>>>count of the variable.
>>>* Next, there are some (about 10 or so) gcc warning problems (i. e.
>>>variable may be unitialized) solutions, which were around code with old
>>>pci_find_device.
>>
>>Is this the reason why you initialize members of static structs? If this is
>>uninitialized it will end in the bss section and will be zeroed before the
>>kernel uses is. If you do it will go into data section and add more bloat
>> to the binary. At least this is the explanation I got once why not to do
>> this.
>
>I can't find now changes of initialization static variables, but i have
>deleted section
>dealing up with gcc warning from patch, it would go on a queue later.
Sorry, I misread the diff. That are static functions with the variables in
them, not static structs.
Your patch to arch/sparc64/kernel/ebus.c is broken, the removed and added
parts do not match in behaviour.
If you add braces after if's please add the '{' in the same line as the if
itself. This will make the diff bigger, but then this matches
Documentation/Coding-style.
Eike
pgpgUYjXrd3Ny.pgp
Description: PGP signature
