Re: [PATCH] sata_nv: fix nmi intr or system hanging in rhel4u6 adma.
Robert Hancock wrote: Kuan Luo wrote: Hi, robert One customer reported that their system received a nmi interrupt after issuing dd if=/dev/sdb of=/dev/null on a defective disk in rhel4u6. I tested it and found that my system hung both in rhel4u6(2.6.9-67) and 2.6.24-rc7. The patch can work well, but I am not sure if the patch has other potential effect on adma. I attached a file in case of lines breaked. The below info comes from Gunther Mayer to reproduce the issue. used a Seagate ST3500841NS 3.AE for my test; probably other seagate drives are also capable of creating media errors with the new hdparm-8.1: - compile hdparm-8.1 - hdparm -- yes-i-know-what-i-am-doing --make-bad-sector 6 /dev/sdb Unfortunately this does not succeed for nvidia sata controller (timeouts et al.), but it worked fine on AHCI machine (e.g. FSC R640). When I insert this newly created defective disk in Ultra 20, it reboots within seconds after issueing dd if=/dev/sdb of=/dev/null. Signed-off-by: [EMAIL PROTECTED] --- drivers/ata/sata_nv.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/ata/sata_nv.c b/drivers/ata/sata_nv.c index ed5473b..e824260 100644 --- a/drivers/ata/sata_nv.c +++ b/drivers/ata/sata_nv.c @@ -837,9 +837,10 @@ static void nv_adma_tf_read(struct ata_port *ap, struct ata_taskfile *tf) all shortly be aborted anyway. We assume that NCQ commands are not issued via passthrough, which is the only way that switching into ADMA mode could abort outstanding commands. */ -nv_adma_register_mode(ap); +struct nv_adma_port_priv *pp = ap-private_data; -ata_tf_read(ap, tf); +if (pp-flags NV_ADMA_PORT_REGISTER_MODE) +ata_tf_read(ap, tf); } static unsigned int nv_adma_tf_to_cpb(struct ata_taskfile *tf, __le16 *cpb) This is basically avoiding switching into register mode, right? I don't think this is a very good solution as the point of the tf_read function is that it's supposed to read the taskfile provided by the drive to diagnose the error, so not doing this isn't a good thing. Agree with this analysis -- if -tf_read() is being called, then obviously the core wants a current copy of the device's ATA registers. It is not a good solution to simply avoiding returning meaningful data, because -- as Robert notes -- we need tf_read for analysis. Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git: kmap_atomic() WARN_ON()
Ingo Molnar wrote: * Jeff Garzik [EMAIL PROTECTED] wrote: + unsigned long flags; + + local_irq_save(flags); hm, couldnt we attach the irq disabling to some spinlock, in a natural way? Explicit flags fiddling is a PITA once we do things like threaded irq handlers, -rt, etc. Attaching the irq disabling to some spinlock is what would be artificial... See the ahci.c patch earlier in this thread. It is taken without spin_lock_irqsave() in the interrupt handler, and there is no reason to disable interrupts for the entirety of the interrupt handler run -- only the part where we call kmap. This is only being done to satisfy kmap_atomic's requirements, not libata's. I could add a kmap lock but that just seems silly. Jeff -- 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: Proposal for proper durable fsync() and fdatasync()
Nick Piggin wrote: Anyway, the idea of making fsync/fdatasync etc. safe by default is a good idea IMO, and is a bad bug that we don't do that :( Agreed... it's also disappointing that [unless I'm mistaken] you have to hack each filesystem to support barriers. It seems far easier to make sync_blkdev() Do The Right Thing, and magically make all filesystems data-safe. Jeff -- 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: Proposal for proper durable fsync() and fdatasync()
Jamie Lokier wrote: Jeff Garzik wrote: Nick Piggin wrote: Anyway, the idea of making fsync/fdatasync etc. safe by default is a good idea IMO, and is a bad bug that we don't do that :( Agreed... it's also disappointing that [unless I'm mistaken] you have to hack each filesystem to support barriers. It seems far easier to make sync_blkdev() Do The Right Thing, and magically make all filesystems data-safe. Well, you need ordered metadata writes, barriers _and_ flushes with some filesystems. Merely writing all the data pages than issuing a drive cache flush won't Do The Right Thing with those filesystems - someone already mentioned Btrfs, where it won't. Oh certainly. That's why we have a VFS :) fsync for NFS will look quite different, too. But I agree that your suggestion would make a superb default, for filesystems which don't provide their own function. Yep. That would immediately cover a bunch of filesystems. It's not optimal even then. Devices: On a software RAID, you ideally don't want to issue flushes to all drives if your database did a 1 block commit entry. (But they probably use O_DIRECT anyway, changing the rules again). But all that can be optimised in generic VFS code eventually. It doesn't need filesystem assistance in most cases. My own idea is that we create a FLUSH command for blkdev request queues, to exist alongside READ, WRITE, and the current barrier implementation. Then FLUSH could be passed down through MD or DM. Jeff -- 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: Proposal for "proper" durable fsync() and fdatasync()
Jamie Lokier wrote: By durable, I mean that fsync() should actually commit writes to physical stable storage, Yes, it should. I was surprised that fsync() doesn't do this already. There was a lot of effort put into block I/O write barriers during 2.5, so that journalling filesystems can force correct write ordering, using disk flush cache commands. After all that effort, I was very surprised to notice that Linux 2.6.x doesn't use that capability to ensure fsync() flushes the disk cache onto stable storage. It's surprising you are surprised, given that this [lame] fsync behavior has remaining consistently lame throughout Linux's history. [snip huge long proposal] Rather than invent new APIs, we should fix the existing ones to _really_ flush data to physical media. Linux should default to SAFE data storage, and permit users to retain the older unsafe behavior via an option. It's completely ridiculous that we default to an unsafe fsync. And [anticipating a common response from others] it is completely irrelevant that POSIX fsync(2) permits Linux's current behavior. The current behavior is unsafe. Safety before performance -- ESPECIALLY when it comes to storing user data. Regards, Jeff (Linux ATA driver dude) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] net driver updates
Divy Le Ray wrote: So, it sounds like Krishna's patch is ok, because the race does not exist anymore in this driver? The first part is right indeed, but the second part is breaking the current usage of txq_stopped and the logic that stops and restarts the Tx queue. I can submit a patch fixing it. Plese let me know what's more convenient for you. At this point, yes a fix (with a good patch description) would be preferred... Thanks, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sata-MV, Intergated Sata Device Support
Mark Lord wrote:
Jeff Garzik wrote:
Jon Li wrote:
Hello,
I am curious as to whether there are plans to add support for integrated
sata devices. I personally want to add support for a 60x1C0 based
device (pci:id = 0x5182). I think adding support should be relatively
simple, except for a few issues outlined below.
In the original mvSata.c (ver3.4) that has 0x5182 support, the config
space is as such:
case MV_SATA_DEVICE_ID_5182:
pAdapter->numberOfChannels = MV_SATA_5182_PORT_NUM;
pAdapter->numberOfUnits = 1;
pAdapter->portsPerUnit = 2;
pAdapter->sataAdapterGeneration = MV_SATA_GEN_IIE;
/*The integrated sata core chip based on 60x1 C0*/
pAdapter->chipIs60X1C0 = MV_TRUE;
pAdapter->hostInterface = MV_HOST_IF_INTEGRATED;
pAdapter->mainMaskOffset = 0x20024; /*the iobaseaddress is
0x6*/
pAdapter->mainCauseOffset = 0x20020;
break;
I have not yet figured out how all these values are defined in sata-mv.c
(ver 0.8). Specifically, where do I define "numberOfChannels" which
should equal 2, and "numberOfUnits" which obviously equals 1?
I have a current config space (not completed) for sata-mv.c which is:
{ /* chip_5182 */
.sht= _sht,
.flags= (MV_COMMON_FLAGS | MV_6XXX_FLAGS |
MV_FLAG_DUAL_HC),
.pio_mask= 0x1f,/* pio0-4 */
.udma_mask= 0x7f,/* udma0-6 */
.port_ops= _ops,
},
...
Saeed: isn't this what your SOC patches already implemented for us?
As near as I can tell, sata_mv now already has support for the 60x1C0.
Saeed's stuff didn't support PCI though, and Jon Li is definitely
talking about PCI...
Jeff
--
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: [RFC] Disk shock protection (revisited)
Elias Oltmanns wrote: The general idea: A daemon running in user space monitors input data from an accelerometer. When the daemon detects a critical condition, i.e., a sudden acceleration (for instance, laptop slides off the desk), it signals the kernel so the hard disk may be put into a (more) safe state. To this end, the kernel has to issue an idle immediate command with unload feature and stop the block layer queue afterwards. Once the daemon tells us that the imminent danger is over, the most important task for the kernel is to restart the block layer queue. See below for more details. Speaking specifically to that problem, it seems to me that you either want an mlock'd daemon, or just simply to keep everything in the kernel, for this specific solution. You don't want, for example, to swap out other apps, swap in the daemon, in order to handle a sudden acceleration. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sata-MV, Intergated Sata Device Support
Jon Li wrote:
Hello,
I am curious as to whether there are plans to add support for integrated
sata devices. I personally want to add support for a 60x1C0 based
device (pci:id = 0x5182). I think adding support should be relatively
simple, except for a few issues outlined below.
In the original mvSata.c (ver3.4) that has 0x5182 support, the config
space is as such:
case MV_SATA_DEVICE_ID_5182:
pAdapter->numberOfChannels = MV_SATA_5182_PORT_NUM;
pAdapter->numberOfUnits = 1;
pAdapter->portsPerUnit = 2;
pAdapter->sataAdapterGeneration = MV_SATA_GEN_IIE;
/*The integrated sata core chip based on 60x1 C0*/
pAdapter->chipIs60X1C0 = MV_TRUE;
pAdapter->hostInterface = MV_HOST_IF_INTEGRATED;
pAdapter->mainMaskOffset = 0x20024; /*the iobaseaddress is
0x6*/
pAdapter->mainCauseOffset = 0x20020;
break;
I have not yet figured out how all these values are defined in sata-mv.c
(ver 0.8). Specifically, where do I define "numberOfChannels" which
should equal 2, and "numberOfUnits" which obviously equals 1?
I have a current config space (not completed) for sata-mv.c which is:
{ /* chip_5182 */
.sht= _sht,
.flags = (MV_COMMON_FLAGS | MV_6XXX_FLAGS |
MV_FLAG_DUAL_HC),
.pio_mask = 0x1f, /* pio0-4 */
.udma_mask = 0x7f, /* udma0-6 */
.port_ops = _ops,
},
I believe according to the new structure in sata-mv.c,
HC_MAIN_IRQ_CAUSE_OFS should equal 0x20020 and HC_MAIN_IRQ_MASK_OFS
should equal 0x20024 for the 0x5182 device.
My final question is how to implement the MV_HOST_IF_INTEGRATED flag?
Is this already implemented and renamed in sata-mv.c? Or do I need to
also add the routines?
I just wanted to point the current sata_mv hackers to this message from
April 2007...
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] net driver updates
Marin Mitov wrote: On Tuesday 26 February 2008 12:59:04 am you wrote: Divy Le Ray wrote: From: "Divy Le Ray" <[EMAIL PROTECTED]> Date: Wed, 20 Feb 2008 21:57:08 -0800 The driver is cxgb3 here, it uses LLTX. That's extremely unfortunate, hopefully you can update it to use a model like tg3 and others use. LLTX is a lost cause for hardware device drivers, and in fact we'd like to remove it tree wide eventually. Just for info: loopback.c uses it too :-) Yes, we're all aware of this. Google for "david miller loopback lltx" for a few examples... Also, please do not strip CC's, that's quite annoying. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git: kmap_atomic() WARN_ON()
Welcome to test this... (attached, not tested nor even compiled, really)
Jeff
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 0562b0a..7b1f1ee 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -1694,12 +1694,17 @@ void ata_scsi_rbuf_fill(struct ata_scsi_args *args,
u8 *rbuf;
unsigned int buflen, rc;
struct scsi_cmnd *cmd = args->cmd;
+ unsigned long flags;
+
+ local_irq_save(flags);
buflen = ata_scsi_rbuf_get(cmd, );
memset(rbuf, 0, buflen);
rc = actor(args, rbuf, buflen);
ata_scsi_rbuf_put(cmd, rbuf);
+ local_irq_restore(flags);
+
if (rc == 0)
cmd->result = SAM_STAT_GOOD;
args->done(cmd);
@@ -2473,6 +2478,9 @@ static void atapi_qc_complete(struct ata_queued_cmd *qc)
if ((scsicmd[0] == INQUIRY) && ((scsicmd[1] & 0x03) == 0)) {
u8 *buf = NULL;
unsigned int buflen;
+ unsigned long flags;
+
+ local_irq_save(flags);
buflen = ata_scsi_rbuf_get(cmd, );
@@ -2490,6 +2498,8 @@ static void atapi_qc_complete(struct ata_queued_cmd *qc)
}
ata_scsi_rbuf_put(cmd, buf);
+
+ local_irq_restore(flags);
}
cmd->result = SAM_STAT_GOOD;
Re: [git patches] net driver updates
Divy Le Ray wrote: From: "Divy Le Ray" <[EMAIL PROTECTED]> Date: Wed, 20 Feb 2008 21:57:08 -0800 The driver is cxgb3 here, it uses LLTX. That's extremely unfortunate, hopefully you can update it to use a model like tg3 and others use. LLTX is a lost cause for hardware device drivers, and in fact we'd like to remove it tree wide eventually. It sounds like I messed up. cxgb3 does not use LLTX - The Chelsio driver does, thus should be converted. So, it sounds like Krishna's patch is ok, because the race does not exist anymore in this driver? Jeff -- 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] libata: Add MMIO support to pata_sil680
Tim Ellis wrote: On 15 Feb 2008, at 21:45, Benjamin Herrenschmidt wrote: On Fri, 2008-02-15 at 15:53 +, Alan Cox wrote: That's strange though. Somebody with knowledge of that HW (or specs) who can spot something ? Could it be an issue with timing ? I don't have HW access to this machine. If somebody could send one to me I could do more investigation. Ben, would an ssh access to such a machine and to a terminal server suffice? It says clearly in the code where to start. See the FIXME notes in both libata-sff and libata-core about MMIO. Neither the DMA transfer start or the probe SRST sequence are correct with MMIO posting and this hasn't been fixed as I pointed out was needed when I originally NAKked the change. Without those being fixed (especially SRST) on any device with heavy PCI posting of mmio your controller *wont work*. The dbdma start is mostly harmless (things don't get posted for -that- long), though I suppose it's worth fixing. Would reading back dmactl do in that case or do you foresee any kind of side effect ? (Maybe only doing it for MMIO ?) As for SRST, I'm not totally confident how safe it is to read back there while doing the reset sequence, so I'm tempted to really only do it for MMIO and use altstat rather than ctl/stat (the later tends to have side effects which we don't want here). What do you think ? The main problem from here is that I don't know whether we are using MMIO or PIO from libata-core. Maybe I can add a host flag indicate that such flushing is needed ? In the meantime, Guennadi, can you check if that patch helps for you (to see if that is indeed the problem): diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 004dae4..1451a52 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -3461,10 +3461,13 @@ static int ata_bus_softreset(struct ata_port *ap, unsigned int devmask, /* software reset. causes dev0 to be selected */ iowrite8(ap->ctl, ioaddr->ctl_addr); +ioread16(ioaddr->nsect_addr); udelay(20);/* FIXME: flush */ iowrite8(ap->ctl | ATA_SRST, ioaddr->ctl_addr); +ioread16(ioaddr->nsect_addr); udelay(20);/* FIXME: flush */ iowrite8(ap->ctl, ioaddr->ctl_addr); +ioread16(ioaddr->nsect_addr); /* wait a while before checking status */ ata_wait_after_reset(ap, deadline); diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c index 60cd4b1..81d5828 100644 --- a/drivers/ata/libata-sff.c +++ b/drivers/ata/libata-sff.c @@ -273,6 +273,7 @@ void ata_bmdma_start(struct ata_queued_cmd *qc) * FIXME: The posting of this write means I/O starts are * unneccessarily delayed for MMIO */ +ioread8(ap->ioaddr.bmdma_addr + ATA_DMA_CMD); } /** Cheers, Ben. Unfortunately this patch appears to give same result as in the original post. Guennadi and I are looking into arranging access to a device. Thanks! Yes. Alan loves to complain about lack of MMIO flush, but in practice this is rarely the source of problems such as the one you describe. But if its broken its broken, and we need to revert. Any luck getting benh access to the device? Jeff -- 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: GAK!!!! Re: PCI: AMD SATA IDE mode quirk
Alan Cox wrote:
Signed-off-by: Crane Cai <[EMAIL PROTECTED]>
Acked-by: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Vomitted-upon-by: Alan Cox <[EMAIL PROTECTED]>
- if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
- u8 tmp;
+ /* set sb600/sb700/sb800 sata to ahci mode */
+ u8 tmp;
+ pci_read_config_byte(pdev, PCI_CLASS_DEVICE, );
+ if (tmp == 0x01) {
CLASS_DEVICE is cached in pdev->class so why not simply do:
if (pdev->class & (1 << 8))
I agree. I [obviously] missed this when I ack'd, mainly ack'ing the
overall change.
BIOS certainly may modify that PCI config register, but that's before
the kernel boots. So, using pdev->class is fine.
Jeff
--
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: [ugly patch] Save .15W-.5W by AHCI powersaving
Mark Lord wrote: Pavel Machek wrote: This is a patch (very ugly, assumes you have just one disk) to bring powersaving to AHCI. You need Alan's SCSI autosuspend (attached) patch as a base. It saves .5W compared to config with disk spinning, and even .15W compared to hdparm -y... on my thinkpad x60 anyway. .. There was a discussion of this here today. It makes good use of AHCI-specific features. Has it been tested with a Port-Multiplier yet? This is cool enough that we really ought to do a hardware-independent version, so that all SATA interfaces could benefit. Especially ata_piix, but others too. BTW we can also save power by allowing the user to choose to disable hotplugging support. Then we can power down PHYs that are not in use. That requires the addition of some policy controls, because it is user-specific whether or not to waste power waiting for a plug-in event. Jeff -- 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/
[git patches] libata updates
(additional explanation for the revert is in the full changeset
description)
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/libata-core.c |5 -
drivers/ata/libata.h |1 -
2 files changed, 4 insertions(+), 2 deletions(-)
Adrian Bunk (1):
make atapi_dmadir static
Jeff Garzik (1):
Revert "power_state: get rid of write-only variable in SATA"
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index fbc2435..4fbcce7 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -113,7 +113,7 @@ int atapi_enabled = 1;
module_param(atapi_enabled, int, 0444);
MODULE_PARM_DESC(atapi_enabled, "Enable discovery of ATAPI devices (0=off,
1=on)");
-int atapi_dmadir = 0;
+static int atapi_dmadir = 0;
module_param(atapi_dmadir, int, 0444);
MODULE_PARM_DESC(atapi_dmadir, "Enable ATAPI DMADIR bridge support (0=off,
1=on)");
@@ -6567,6 +6567,8 @@ int ata_host_suspend(struct ata_host *host, pm_message_t
mesg)
ata_lpm_enable(host);
rc = ata_host_request_pm(host, mesg, 0, ATA_EHI_QUIET, 1);
+ if (rc == 0)
+ host->dev->power.power_state = mesg;
return rc;
}
@@ -6585,6 +6587,7 @@ void ata_host_resume(struct ata_host *host)
{
ata_host_request_pm(host, PMSG_ON, ATA_EH_SOFTRESET,
ATA_EHI_NO_AUTOPSY | ATA_EHI_QUIET, 0);
+ host->dev->power.power_state = PMSG_ON;
/* reenable link pm */
ata_lpm_disable(host);
diff --git a/drivers/ata/libata.h b/drivers/ata/libata.h
index 6036ded..aa884f7 100644
--- a/drivers/ata/libata.h
+++ b/drivers/ata/libata.h
@@ -56,7 +56,6 @@ enum {
extern unsigned int ata_print_id;
extern struct workqueue_struct *ata_aux_wq;
extern int atapi_enabled;
-extern int atapi_dmadir;
extern int atapi_passthru16;
extern int libata_fua;
extern int libata_noacpi;
--
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: broken suspend in .2.6.25-rc3 on T61p (was Re: new regression in 2.6.25-rc3: no keyboard/lid acpi events on thinkpad T61p)
Pavel Machek wrote: commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2 Author: Pavel Machek <[EMAIL PROTECTED]> Date: Thu Feb 21 13:56:55 2008 +0100 power_state: get rid of write-only variable in SATA This is pretty unlikely to be it. Can you double check that this patch really breaks something? Quote... After reverting 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2 on top of 2.6.25-rc3 the kernel again resumes from suspend to ram. Seems pretty clear to me. Jeff -- 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: new regression in 2.6.25-rc3: can't resume from suspend to ram, ata1 errors
Michael S. Tsirkin wrote: git bisect points at this commit: commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2. power_state: get rid of write-only variable in SATA Hello Pavel -- It looks like this not a write-only variable after all... Jeff -- 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: net: tx timeouts with skge, 8139too, dmfe drivers/NICs
Marin Mitov wrote: Hi all, I experience very rare freezes at heavy outbound traffic (sending ~4GB DVD image to another host(s) on the same LAN) using skge driver (NIC on the mobo) as well as (recently tested) using rtl8139 or dmfe NICs on the PCI bus. There is a single switch between them (tested with another one just to exclude a faulty switch). skge <--> Marvell 88E8001 chip 8139too <--> Realtek 8136B chip dmfe <--> Davicom DM9102 chip Symptoms are similar: tx timeouts and no more net activity. KDE desktop works, computational programs - work, the machine is usable, but cannot ping, nor can be ping-ed anymore. rmmod && modprobe the respective modules repairs the problem. Simple surfing/e-mailing from it do not trigger the problem. The machine is used as LTSP server for old PCs (as X terminals) (mostly outbound traffic) and is not usable as such due to this problem. The kernel is 2.6.24.2-SMP/x86_32 (PREEMPT or not - NO difference). As far as this happens with 3 different NICs/drivers could it be a problem in the (common for all of them) networking subsystem? A TX timeout (like hardware timeouts, in general) is a very generic behavior, with many causes. In general, when you see timeouts with varied hardware and drivers, you're almost always dealing with a problem with interrupt delivery, or a generic system problem, rather than bugs in the network stack or all three drivers. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git: kmap_atomic() WARN_ON()
Björn Steinbrink wrote:
On 2008.02.07 00:58:42 +0100, Thomas Gleixner wrote:
current mainline triggers:
WARNING: at /home/tglx/work/kernel/x86/linux-2.6/arch/x86/mm/highmem_32.c:52
kmap_atomic_prot+0xe5/0x19b()
Modules linked in: ahci(+) sata_sil libata sd_mod scsi_mod raid1 ext3 jbd
ehci_hcd ohci_hcd uhci_hcd
Pid: 0, comm: swapper Not tainted 2.6.24 #173
[] warn_on_slowpath+0x41/0x51
[] ? __enqueue_entity+0x9c/0xa4
[] ? enqueue_entity+0x124/0x13b
[] ? enqueue_task_fair+0x41/0x4c
[] ? _spin_lock_irqsave+0x14/0x2e
[] ? lock_timer_base+0x1f/0x3e
[] kmap_atomic_prot+0xe5/0x19b
[] kmap_atomic+0x14/0x16
[] ata_scsi_rbuf_get+0x1e/0x2c [libata]
[] atapi_qc_complete+0x23f/0x289 [libata]
[] __ata_qc_complete+0x8e/0x93 [libata]
[] ata_qc_complete+0x115/0x128 [libata]
[] ata_qc_complete_multiple+0x86/0xa0 [libata]
[] ahci_interrupt+0x370/0x40d [ahci]
[] handle_IRQ_event+0x21/0x48
[] handle_edge_irq+0xc9/0x10a
[] ? handle_edge_irq+0x0/0x10a
[] do_IRQ+0x8b/0xb7
[] common_interrupt+0x23/0x28
[] ? init_chipset_cmd64x+0xb/0x93
[] ? mwait_idle_with_hints+0x39/0x3d
[] ? mwait_idle+0x0/0xf
[] mwait_idle+0xd/0xf
[] cpu_idle+0xb0/0xe4
[] rest_init+0x5d/0x5f
This is not a new problem. It was pointed out some time ago already,
but now the WARN_ON() finally made it into mainline :)
The fix is not obvious, as this code seems to be called from various
call sites.
Hm, do you have lockdep enabled? If not, does lockdep make this go away?
Because lockdep will set IRQF_DISABLED for all interrupt handlers, and
unless that flag is set, handle_IRQ_event will reenable interrupts while
the handler is running. And ahci_interrupt only uses a plain spin_lock,
so interrupts keep being enabled. The patch below should help with that.
Hmhm, maybe that also solves the deadlock you saw? Dunno...
I can't come up with an useful commit message right now, but I'll resend
in suitable form for submission if that thing actually works.
Björn
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 1db93b6..ae3dbc8 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1739,6 +1739,7 @@ static irqreturn_t ahci_interrupt(int irq, void
*dev_instance)
unsigned int i, handled = 0;
void __iomem *mmio;
u32 irq_stat, irq_ack = 0;
+ unsigned long flags;
VPRINTK("ENTER\n");
@@ -1751,7 +1752,7 @@ static irqreturn_t ahci_interrupt(int irq, void *dev_instance)
if (!irq_stat)
return IRQ_NONE;
- spin_lock(>lock);
+ spin_lock_irqsave(>lock, flags);
for (i = 0; i < host->n_ports; i++) {
struct ata_port *ap;
@@ -1778,7 +1779,7 @@ static irqreturn_t ahci_interrupt(int irq, void
*dev_instance)
handled = 1;
}
- spin_unlock(>lock);
+ spin_unlock_irqrestore(>lock, flags);
If this truly fixes the problem, then lockdep is definitely the problem
source.
There are plenty of drivers that do the same thing that ahci does, in
terms of interrupt handler locking... and I will definitely push back
on efforts to convert otherwise-100%-safe spin_lock() into
spin_lock_irqsave() just to quiet lockdep.
Very interesting email, thanks...
Jeff
--
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] de2104x: remove BUG_ON() when changing media type
Ondrej Zary wrote: When the chip dies (probably because of a bug somewhere in the driver), de_stop_rxtx() fails and changing the media type crashes the whole machine. Replace BUG_ON() in de_set_media() with a warning. Signed-off-by: Ondrej Zary <[EMAIL PROTECTED]> --- linux-2.6.24-orig/drivers/net/tulip/de2104x.c 2008-02-25 18:27:34.0 +0100 +++ linux-2.6.24-pentium/drivers/net/tulip/de2104x.c2008-02-25 18:34:56.0 +0100 @@ -910,7 +910,8 @@ unsigned media = de->media_type; u32 macmode = dr32(MacMode); - BUG_ON(de_is_running(de)); + if (de_is_running(de)) + printk(KERN_WARNING "%s: chip is running while changing media!\n", de->dev->name); Certainly a sane improvement... -- 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] de2104x: remove BUG_ON() when changing media type
Ondrej Zary wrote: When the chip dies (probably because of a bug somewhere in the driver), de_stop_rxtx() fails and changing the media type crashes the whole machine. Replace BUG_ON() in de_set_media() with a warning. Signed-off-by: Ondrej Zary [EMAIL PROTECTED] --- linux-2.6.24-orig/drivers/net/tulip/de2104x.c 2008-02-25 18:27:34.0 +0100 +++ linux-2.6.24-pentium/drivers/net/tulip/de2104x.c2008-02-25 18:34:56.0 +0100 @@ -910,7 +910,8 @@ unsigned media = de-media_type; u32 macmode = dr32(MacMode); - BUG_ON(de_is_running(de)); + if (de_is_running(de)) + printk(KERN_WARNING %s: chip is running while changing media!\n, de-dev-name); Certainly a sane improvement... -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git: kmap_atomic() WARN_ON()
Björn Steinbrink wrote:
On 2008.02.07 00:58:42 +0100, Thomas Gleixner wrote:
current mainline triggers:
WARNING: at /home/tglx/work/kernel/x86/linux-2.6/arch/x86/mm/highmem_32.c:52
kmap_atomic_prot+0xe5/0x19b()
Modules linked in: ahci(+) sata_sil libata sd_mod scsi_mod raid1 ext3 jbd
ehci_hcd ohci_hcd uhci_hcd
Pid: 0, comm: swapper Not tainted 2.6.24 #173
[c0126b60] warn_on_slowpath+0x41/0x51
[c011c5eb] ? __enqueue_entity+0x9c/0xa4
[c011c717] ? enqueue_entity+0x124/0x13b
[c011cedb] ? enqueue_task_fair+0x41/0x4c
[c032ce88] ? _spin_lock_irqsave+0x14/0x2e
[c012e885] ? lock_timer_base+0x1f/0x3e
[c011ad6d] kmap_atomic_prot+0xe5/0x19b
[c011ae37] kmap_atomic+0x14/0x16
[f88ea218] ata_scsi_rbuf_get+0x1e/0x2c [libata]
[f88ea821] atapi_qc_complete+0x23f/0x289 [libata]
[f88e3d00] __ata_qc_complete+0x8e/0x93 [libata]
[f88e3fc7] ata_qc_complete+0x115/0x128 [libata]
[f88e8d47] ata_qc_complete_multiple+0x86/0xa0 [libata]
[f8841a5d] ahci_interrupt+0x370/0x40d [ahci]
[c01512c6] handle_IRQ_event+0x21/0x48
[c01521ca] handle_edge_irq+0xc9/0x10a
[c0152101] ? handle_edge_irq+0x0/0x10a
[c0107518] do_IRQ+0x8b/0xb7
[c01055db] common_interrupt+0x23/0x28
[c032007b] ? init_chipset_cmd64x+0xb/0x93
[c010316e] ? mwait_idle_with_hints+0x39/0x3d
[c0103172] ? mwait_idle+0x0/0xf
[c010317f] mwait_idle+0xd/0xf
[c0103761] cpu_idle+0xb0/0xe4
[c031b509] rest_init+0x5d/0x5f
This is not a new problem. It was pointed out some time ago already,
but now the WARN_ON() finally made it into mainline :)
The fix is not obvious, as this code seems to be called from various
call sites.
Hm, do you have lockdep enabled? If not, does lockdep make this go away?
Because lockdep will set IRQF_DISABLED for all interrupt handlers, and
unless that flag is set, handle_IRQ_event will reenable interrupts while
the handler is running. And ahci_interrupt only uses a plain spin_lock,
so interrupts keep being enabled. The patch below should help with that.
Hmhm, maybe that also solves the deadlock you saw? Dunno...
I can't come up with an useful commit message right now, but I'll resend
in suitable form for submission if that thing actually works.
Björn
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 1db93b6..ae3dbc8 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1739,6 +1739,7 @@ static irqreturn_t ahci_interrupt(int irq, void
*dev_instance)
unsigned int i, handled = 0;
void __iomem *mmio;
u32 irq_stat, irq_ack = 0;
+ unsigned long flags;
VPRINTK(ENTER\n);
@@ -1751,7 +1752,7 @@ static irqreturn_t ahci_interrupt(int irq, void *dev_instance)
if (!irq_stat)
return IRQ_NONE;
- spin_lock(host-lock);
+ spin_lock_irqsave(host-lock, flags);
for (i = 0; i host-n_ports; i++) {
struct ata_port *ap;
@@ -1778,7 +1779,7 @@ static irqreturn_t ahci_interrupt(int irq, void
*dev_instance)
handled = 1;
}
- spin_unlock(host-lock);
+ spin_unlock_irqrestore(host-lock, flags);
If this truly fixes the problem, then lockdep is definitely the problem
source.
There are plenty of drivers that do the same thing that ahci does, in
terms of interrupt handler locking... and I will definitely push back
on efforts to convert otherwise-100%-safe spin_lock() into
spin_lock_irqsave() just to quiet lockdep.
Very interesting email, thanks...
Jeff
--
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: net: tx timeouts with skge, 8139too, dmfe drivers/NICs
Marin Mitov wrote: Hi all, I experience very rare freezes at heavy outbound traffic (sending ~4GB DVD image to another host(s) on the same LAN) using skge driver (NIC on the mobo) as well as (recently tested) using rtl8139 or dmfe NICs on the PCI bus. There is a single switch between them (tested with another one just to exclude a faulty switch). skge -- Marvell 88E8001 chip 8139too -- Realtek 8136B chip dmfe -- Davicom DM9102 chip Symptoms are similar: tx timeouts and no more net activity. KDE desktop works, computational programs - work, the machine is usable, but cannot ping, nor can be ping-ed anymore. rmmod modprobe the respective modules repairs the problem. Simple surfing/e-mailing from it do not trigger the problem. The machine is used as LTSP server for old PCs (as X terminals) (mostly outbound traffic) and is not usable as such due to this problem. The kernel is 2.6.24.2-SMP/x86_32 (PREEMPT or not - NO difference). As far as this happens with 3 different NICs/drivers could it be a problem in the (common for all of them) networking subsystem? A TX timeout (like hardware timeouts, in general) is a very generic behavior, with many causes. In general, when you see timeouts with varied hardware and drivers, you're almost always dealing with a problem with interrupt delivery, or a generic system problem, rather than bugs in the network stack or all three drivers. Jeff -- 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: new regression in 2.6.25-rc3: can't resume from suspend to ram, ata1 errors
Michael S. Tsirkin wrote: git bisect points at this commit: commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2. power_state: get rid of write-only variable in SATA Hello Pavel -- It looks like this not a write-only variable after all... Jeff -- 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: broken suspend in .2.6.25-rc3 on T61p (was Re: new regression in 2.6.25-rc3: no keyboard/lid acpi events on thinkpad T61p)
Pavel Machek wrote: commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2 Author: Pavel Machek [EMAIL PROTECTED] Date: Thu Feb 21 13:56:55 2008 +0100 power_state: get rid of write-only variable in SATA This is pretty unlikely to be it. Can you double check that this patch really breaks something? Quote... After reverting 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2 on top of 2.6.25-rc3 the kernel again resumes from suspend to ram. Seems pretty clear to me. Jeff -- 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/
[git patches] libata updates
(additional explanation for the revert is in the full changeset
description)
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/libata-core.c |5 -
drivers/ata/libata.h |1 -
2 files changed, 4 insertions(+), 2 deletions(-)
Adrian Bunk (1):
make atapi_dmadir static
Jeff Garzik (1):
Revert power_state: get rid of write-only variable in SATA
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index fbc2435..4fbcce7 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -113,7 +113,7 @@ int atapi_enabled = 1;
module_param(atapi_enabled, int, 0444);
MODULE_PARM_DESC(atapi_enabled, Enable discovery of ATAPI devices (0=off,
1=on));
-int atapi_dmadir = 0;
+static int atapi_dmadir = 0;
module_param(atapi_dmadir, int, 0444);
MODULE_PARM_DESC(atapi_dmadir, Enable ATAPI DMADIR bridge support (0=off,
1=on));
@@ -6567,6 +6567,8 @@ int ata_host_suspend(struct ata_host *host, pm_message_t
mesg)
ata_lpm_enable(host);
rc = ata_host_request_pm(host, mesg, 0, ATA_EHI_QUIET, 1);
+ if (rc == 0)
+ host-dev-power.power_state = mesg;
return rc;
}
@@ -6585,6 +6587,7 @@ void ata_host_resume(struct ata_host *host)
{
ata_host_request_pm(host, PMSG_ON, ATA_EH_SOFTRESET,
ATA_EHI_NO_AUTOPSY | ATA_EHI_QUIET, 0);
+ host-dev-power.power_state = PMSG_ON;
/* reenable link pm */
ata_lpm_disable(host);
diff --git a/drivers/ata/libata.h b/drivers/ata/libata.h
index 6036ded..aa884f7 100644
--- a/drivers/ata/libata.h
+++ b/drivers/ata/libata.h
@@ -56,7 +56,6 @@ enum {
extern unsigned int ata_print_id;
extern struct workqueue_struct *ata_aux_wq;
extern int atapi_enabled;
-extern int atapi_dmadir;
extern int atapi_passthru16;
extern int libata_fua;
extern int libata_noacpi;
--
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: [ugly patch] Save .15W-.5W by AHCI powersaving
Mark Lord wrote: Pavel Machek wrote: This is a patch (very ugly, assumes you have just one disk) to bring powersaving to AHCI. You need Alan's SCSI autosuspend (attached) patch as a base. It saves .5W compared to config with disk spinning, and even .15W compared to hdparm -y... on my thinkpad x60 anyway. .. There was a discussion of this here today. It makes good use of AHCI-specific features. Has it been tested with a Port-Multiplier yet? This is cool enough that we really ought to do a hardware-independent version, so that all SATA interfaces could benefit. Especially ata_piix, but others too. BTW we can also save power by allowing the user to choose to disable hotplugging support. Then we can power down PHYs that are not in use. That requires the addition of some policy controls, because it is user-specific whether or not to waste power waiting for a plug-in event. Jeff -- 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: GAK!!!! Re: PCI: AMD SATA IDE mode quirk
Alan Cox wrote:
Signed-off-by: Crane Cai [EMAIL PROTECTED]
Acked-by: Jeff Garzik [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
Vomitted-upon-by: Alan Cox [EMAIL PROTECTED]
- if ((pdev-class 8) == PCI_CLASS_STORAGE_IDE) {
- u8 tmp;
+ /* set sb600/sb700/sb800 sata to ahci mode */
+ u8 tmp;
+ pci_read_config_byte(pdev, PCI_CLASS_DEVICE, tmp);
+ if (tmp == 0x01) {
CLASS_DEVICE is cached in pdev-class so why not simply do:
if (pdev-class (1 8))
I agree. I [obviously] missed this when I ack'd, mainly ack'ing the
overall change.
BIOS certainly may modify that PCI config register, but that's before
the kernel boots. So, using pdev-class is fine.
Jeff
--
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] libata: Add MMIO support to pata_sil680
Tim Ellis wrote: On 15 Feb 2008, at 21:45, Benjamin Herrenschmidt wrote: On Fri, 2008-02-15 at 15:53 +, Alan Cox wrote: That's strange though. Somebody with knowledge of that HW (or specs) who can spot something ? Could it be an issue with timing ? I don't have HW access to this machine. If somebody could send one to me I could do more investigation. Ben, would an ssh access to such a machine and to a terminal server suffice? It says clearly in the code where to start. See the FIXME notes in both libata-sff and libata-core about MMIO. Neither the DMA transfer start or the probe SRST sequence are correct with MMIO posting and this hasn't been fixed as I pointed out was needed when I originally NAKked the change. Without those being fixed (especially SRST) on any device with heavy PCI posting of mmio your controller *wont work*. The dbdma start is mostly harmless (things don't get posted for -that- long), though I suppose it's worth fixing. Would reading back dmactl do in that case or do you foresee any kind of side effect ? (Maybe only doing it for MMIO ?) As for SRST, I'm not totally confident how safe it is to read back there while doing the reset sequence, so I'm tempted to really only do it for MMIO and use altstat rather than ctl/stat (the later tends to have side effects which we don't want here). What do you think ? The main problem from here is that I don't know whether we are using MMIO or PIO from libata-core. Maybe I can add a host flag indicate that such flushing is needed ? In the meantime, Guennadi, can you check if that patch helps for you (to see if that is indeed the problem): diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 004dae4..1451a52 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -3461,10 +3461,13 @@ static int ata_bus_softreset(struct ata_port *ap, unsigned int devmask, /* software reset. causes dev0 to be selected */ iowrite8(ap-ctl, ioaddr-ctl_addr); +ioread16(ioaddr-nsect_addr); udelay(20);/* FIXME: flush */ iowrite8(ap-ctl | ATA_SRST, ioaddr-ctl_addr); +ioread16(ioaddr-nsect_addr); udelay(20);/* FIXME: flush */ iowrite8(ap-ctl, ioaddr-ctl_addr); +ioread16(ioaddr-nsect_addr); /* wait a while before checking status */ ata_wait_after_reset(ap, deadline); diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c index 60cd4b1..81d5828 100644 --- a/drivers/ata/libata-sff.c +++ b/drivers/ata/libata-sff.c @@ -273,6 +273,7 @@ void ata_bmdma_start(struct ata_queued_cmd *qc) * FIXME: The posting of this write means I/O starts are * unneccessarily delayed for MMIO */ +ioread8(ap-ioaddr.bmdma_addr + ATA_DMA_CMD); } /** Cheers, Ben. Unfortunately this patch appears to give same result as in the original post. Guennadi and I are looking into arranging access to a device. Thanks! Yes. Alan loves to complain about lack of MMIO flush, but in practice this is rarely the source of problems such as the one you describe. But if its broken its broken, and we need to revert. Any luck getting benh access to the device? Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] net driver updates
Divy Le Ray wrote: From: Divy Le Ray [EMAIL PROTECTED] Date: Wed, 20 Feb 2008 21:57:08 -0800 The driver is cxgb3 here, it uses LLTX. That's extremely unfortunate, hopefully you can update it to use a model like tg3 and others use. LLTX is a lost cause for hardware device drivers, and in fact we'd like to remove it tree wide eventually. It sounds like I messed up. cxgb3 does not use LLTX - The Chelsio driver does, thus should be converted. So, it sounds like Krishna's patch is ok, because the race does not exist anymore in this driver? Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git: kmap_atomic() WARN_ON()
Welcome to test this... (attached, not tested nor even compiled, really)
Jeff
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 0562b0a..7b1f1ee 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -1694,12 +1694,17 @@ void ata_scsi_rbuf_fill(struct ata_scsi_args *args,
u8 *rbuf;
unsigned int buflen, rc;
struct scsi_cmnd *cmd = args-cmd;
+ unsigned long flags;
+
+ local_irq_save(flags);
buflen = ata_scsi_rbuf_get(cmd, rbuf);
memset(rbuf, 0, buflen);
rc = actor(args, rbuf, buflen);
ata_scsi_rbuf_put(cmd, rbuf);
+ local_irq_restore(flags);
+
if (rc == 0)
cmd-result = SAM_STAT_GOOD;
args-done(cmd);
@@ -2473,6 +2478,9 @@ static void atapi_qc_complete(struct ata_queued_cmd *qc)
if ((scsicmd[0] == INQUIRY) ((scsicmd[1] 0x03) == 0)) {
u8 *buf = NULL;
unsigned int buflen;
+ unsigned long flags;
+
+ local_irq_save(flags);
buflen = ata_scsi_rbuf_get(cmd, buf);
@@ -2490,6 +2498,8 @@ static void atapi_qc_complete(struct ata_queued_cmd *qc)
}
ata_scsi_rbuf_put(cmd, buf);
+
+ local_irq_restore(flags);
}
cmd-result = SAM_STAT_GOOD;
Re: [git patches] net driver updates
Marin Mitov wrote: On Tuesday 26 February 2008 12:59:04 am you wrote: Divy Le Ray wrote: From: Divy Le Ray [EMAIL PROTECTED] Date: Wed, 20 Feb 2008 21:57:08 -0800 The driver is cxgb3 here, it uses LLTX. That's extremely unfortunate, hopefully you can update it to use a model like tg3 and others use. LLTX is a lost cause for hardware device drivers, and in fact we'd like to remove it tree wide eventually. Just for info: loopback.c uses it too :-) Yes, we're all aware of this. Google for david miller loopback lltx for a few examples... Also, please do not strip CC's, that's quite annoying. Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sata-MV, Intergated Sata Device Support
Jon Li wrote:
Hello,
I am curious as to whether there are plans to add support for integrated
sata devices. I personally want to add support for a 60x1C0 based
device (pci:id = 0x5182). I think adding support should be relatively
simple, except for a few issues outlined below.
In the original mvSata.c (ver3.4) that has 0x5182 support, the config
space is as such:
case MV_SATA_DEVICE_ID_5182:
pAdapter-numberOfChannels = MV_SATA_5182_PORT_NUM;
pAdapter-numberOfUnits = 1;
pAdapter-portsPerUnit = 2;
pAdapter-sataAdapterGeneration = MV_SATA_GEN_IIE;
/*The integrated sata core chip based on 60x1 C0*/
pAdapter-chipIs60X1C0 = MV_TRUE;
pAdapter-hostInterface = MV_HOST_IF_INTEGRATED;
pAdapter-mainMaskOffset = 0x20024; /*the iobaseaddress is
0x6*/
pAdapter-mainCauseOffset = 0x20020;
break;
I have not yet figured out how all these values are defined in sata-mv.c
(ver 0.8). Specifically, where do I define numberOfChannels which
should equal 2, and numberOfUnits which obviously equals 1?
I have a current config space (not completed) for sata-mv.c which is:
{ /* chip_5182 */
.sht= mv_sht,
.flags = (MV_COMMON_FLAGS | MV_6XXX_FLAGS |
MV_FLAG_DUAL_HC),
.pio_mask = 0x1f, /* pio0-4 */
.udma_mask = 0x7f, /* udma0-6 */
.port_ops = mv6_ops,
},
I believe according to the new structure in sata-mv.c,
HC_MAIN_IRQ_CAUSE_OFS should equal 0x20020 and HC_MAIN_IRQ_MASK_OFS
should equal 0x20024 for the 0x5182 device.
My final question is how to implement the MV_HOST_IF_INTEGRATED flag?
Is this already implemented and renamed in sata-mv.c? Or do I need to
also add the routines?
I just wanted to point the current sata_mv hackers to this message from
April 2007...
Jeff
--
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: [RFC] Disk shock protection (revisited)
Elias Oltmanns wrote: The general idea: A daemon running in user space monitors input data from an accelerometer. When the daemon detects a critical condition, i.e., a sudden acceleration (for instance, laptop slides off the desk), it signals the kernel so the hard disk may be put into a (more) safe state. To this end, the kernel has to issue an idle immediate command with unload feature and stop the block layer queue afterwards. Once the daemon tells us that the imminent danger is over, the most important task for the kernel is to restart the block layer queue. See below for more details. Speaking specifically to that problem, it seems to me that you either want an mlock'd daemon, or just simply to keep everything in the kernel, for this specific solution. You don't want, for example, to swap out other apps, swap in the daemon, in order to handle a sudden acceleration. Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sata-MV, Intergated Sata Device Support
Mark Lord wrote:
Jeff Garzik wrote:
Jon Li wrote:
Hello,
I am curious as to whether there are plans to add support for integrated
sata devices. I personally want to add support for a 60x1C0 based
device (pci:id = 0x5182). I think adding support should be relatively
simple, except for a few issues outlined below.
In the original mvSata.c (ver3.4) that has 0x5182 support, the config
space is as such:
case MV_SATA_DEVICE_ID_5182:
pAdapter-numberOfChannels = MV_SATA_5182_PORT_NUM;
pAdapter-numberOfUnits = 1;
pAdapter-portsPerUnit = 2;
pAdapter-sataAdapterGeneration = MV_SATA_GEN_IIE;
/*The integrated sata core chip based on 60x1 C0*/
pAdapter-chipIs60X1C0 = MV_TRUE;
pAdapter-hostInterface = MV_HOST_IF_INTEGRATED;
pAdapter-mainMaskOffset = 0x20024; /*the iobaseaddress is
0x6*/
pAdapter-mainCauseOffset = 0x20020;
break;
I have not yet figured out how all these values are defined in sata-mv.c
(ver 0.8). Specifically, where do I define numberOfChannels which
should equal 2, and numberOfUnits which obviously equals 1?
I have a current config space (not completed) for sata-mv.c which is:
{ /* chip_5182 */
.sht= mv_sht,
.flags= (MV_COMMON_FLAGS | MV_6XXX_FLAGS |
MV_FLAG_DUAL_HC),
.pio_mask= 0x1f,/* pio0-4 */
.udma_mask= 0x7f,/* udma0-6 */
.port_ops= mv6_ops,
},
...
Saeed: isn't this what your SOC patches already implemented for us?
As near as I can tell, sata_mv now already has support for the 60x1C0.
Saeed's stuff didn't support PCI though, and Jon Li is definitely
talking about PCI...
Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] net driver updates
Divy Le Ray wrote: So, it sounds like Krishna's patch is ok, because the race does not exist anymore in this driver? The first part is right indeed, but the second part is breaking the current usage of txq_stopped and the logic that stops and restarts the Tx queue. I can submit a patch fixing it. Plese let me know what's more convenient for you. At this point, yes a fix (with a good patch description) would be preferred... Thanks, Jeff -- 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: Proposal for proper durable fsync() and fdatasync()
Jamie Lokier wrote: By durable, I mean that fsync() should actually commit writes to physical stable storage, Yes, it should. I was surprised that fsync() doesn't do this already. There was a lot of effort put into block I/O write barriers during 2.5, so that journalling filesystems can force correct write ordering, using disk flush cache commands. After all that effort, I was very surprised to notice that Linux 2.6.x doesn't use that capability to ensure fsync() flushes the disk cache onto stable storage. It's surprising you are surprised, given that this [lame] fsync behavior has remaining consistently lame throughout Linux's history. [snip huge long proposal] Rather than invent new APIs, we should fix the existing ones to _really_ flush data to physical media. Linux should default to SAFE data storage, and permit users to retain the older unsafe behavior via an option. It's completely ridiculous that we default to an unsafe fsync. And [anticipating a common response from others] it is completely irrelevant that POSIX fsync(2) permits Linux's current behavior. The current behavior is unsafe. Safety before performance -- ESPECIALLY when it comes to storing user data. Regards, Jeff (Linux ATA driver dude) -- 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: Compex FreedomLine 32 PnP-PCI2 broken with de2104x
Grant Grundler wrote: On Mon, Feb 18, 2008 at 05:40:42PM +0100, Ondrej Zary wrote: I think that de2104x driver should be removed (or at least its MODULE_DEVICE_TABLE) and MODULE_DEVICE_TABLE with only 21040 and 21041 PCI IDs added to de4x5. I can send a patch if this is acceptable. It's acceptable to me. Jeff? (jgarzik) NAK, sorry, for two reasons: 1) we don't delete otherwise clean, working drivers simply because of a bug triggered by unplugging a cable. 2) de4x5 needs to go away. Jeff -- 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: Compex FreedomLine 32 PnP-PCI2 broken with de2104x
Grant Grundler wrote: ISTR there was a time when tulip would compete with de4x5 for devices. tulip is the preferred driver. That's clearly no longer the case and perhaps both distro's need to revisit this. The only reason why de4x5 still exists is that the /tulip/ driver fails to work on a few chips like the 21142 (43?) shipped in various alpha boxen. de4x5 needs to go away, it's been unmaintained for ages, doesn't support any of the new hotplug APIs. de2104x is a "work in progress". That's why it's marked "EXPERIMENTAL" in the Kconfig file. It's not a work in progress, it works just fine for most people (the few that are left). Last I heard, there was a problem with non-twisted-pair stuff, but that's about it. 'experimental' is generally a poorly maintained marker. Jeff -- 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: Compex FreedomLine 32 PnP-PCI2 broken with de2104x
Grant Grundler wrote: ISTR there was a time when tulip would compete with de4x5 for devices. tulip is the preferred driver. That's clearly no longer the case and perhaps both distro's need to revisit this. The only reason why de4x5 still exists is that the /tulip/ driver fails to work on a few chips like the 21142 (43?) shipped in various alpha boxen. de4x5 needs to go away, it's been unmaintained for ages, doesn't support any of the new hotplug APIs. de2104x is a work in progress. That's why it's marked EXPERIMENTAL in the Kconfig file. It's not a work in progress, it works just fine for most people (the few that are left). Last I heard, there was a problem with non-twisted-pair stuff, but that's about it. 'experimental' is generally a poorly maintained marker. Jeff -- 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: Compex FreedomLine 32 PnP-PCI2 broken with de2104x
Grant Grundler wrote: On Mon, Feb 18, 2008 at 05:40:42PM +0100, Ondrej Zary wrote: I think that de2104x driver should be removed (or at least its MODULE_DEVICE_TABLE) and MODULE_DEVICE_TABLE with only 21040 and 21041 PCI IDs added to de4x5. I can send a patch if this is acceptable. It's acceptable to me. Jeff? (jgarzik) NAK, sorry, for two reasons: 1) we don't delete otherwise clean, working drivers simply because of a bug triggered by unplugging a cable. 2) de4x5 needs to go away. Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] net driver fixes
David Miller wrote: Jeff, I really don't want to pull that tree in. Please trust me as your upstream to handle merging issues, as needed. I trust you... Otherwise I wouldn't have volunteered to move my upstream from Linus to you :) My main issues/motivations were: * quite simply, just force of habit: I'm used to basing off of a recent Linus tree, to guarantee build testing against the latest. * worry about testing against a too-old tree, where non-networking fixes may have a relevant impact on my to-be-pushed netdrvr fixes. But in this case it's fair to say there are no such issues, and it was mainly just out of habit. So (as you saw in last email)... rebased and resend. Jeff -- 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/
[git patches] libata fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ahci.c| 23 +--
drivers/ata/libata-core.c | 16 ++--
drivers/ata/libata-pmp.c |4 ++--
drivers/ata/libata-scsi.c |3 ++-
drivers/ata/pata_atiixp.c |4 ++--
drivers/ata/sata_fsl.c|8 +---
include/linux/ata.h |5 +
include/linux/libata.h|1 +
8 files changed, 44 insertions(+), 20 deletions(-)
Alan Cox (1):
pata_atiixp: Use 255 sector limit
Anton Vorontsov (1):
sata_fsl: fix build with ATA_VERBOSE_DEBUG
Mark Lord (1):
libata-pmp: clear hob for pmp register accesses
Pavel Machek (1):
power_state: get rid of write-only variable in SATA
Randy Dunlap (1):
libata-core: fix kernel-doc warning
Shane Huang (1):
[libata] ahci: AMD SB700/SB800 SATA support 64bit DMA
Tejun Heo (1):
libata: automatically use DMADIR if drive/bridge requires it
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 6dd12f7..1db93b6 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -85,6 +85,7 @@ enum {
board_ahci_ign_iferr= 2,
board_ahci_sb600= 3,
board_ahci_mv = 4,
+ board_ahci_sb700= 5,
/* global controller registers */
HOST_CAP= 0x00, /* host capabilities */
@@ -442,6 +443,16 @@ static const struct ata_port_info ahci_port_info[] = {
.udma_mask = ATA_UDMA6,
.port_ops = _ops,
},
+ /* board_ahci_sb700 */
+ {
+ AHCI_HFLAGS (AHCI_HFLAG_IGN_SERR_INTERNAL |
+AHCI_HFLAG_NO_PMP),
+ .flags = AHCI_FLAG_COMMON,
+ .link_flags = AHCI_LFLAG_COMMON,
+ .pio_mask = 0x1f, /* pio0-4 */
+ .udma_mask = ATA_UDMA6,
+ .port_ops = _ops,
+ },
};
static const struct pci_device_id ahci_pci_tbl[] = {
@@ -484,12 +495,12 @@ static const struct pci_device_id ahci_pci_tbl[] = {
/* ATI */
{ PCI_VDEVICE(ATI, 0x4380), board_ahci_sb600 }, /* ATI SB600 */
- { PCI_VDEVICE(ATI, 0x4390), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4391), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4392), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4393), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4394), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4395), board_ahci_sb600 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4390), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4391), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4392), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4393), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4394), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4395), board_ahci_sb700 }, /* ATI SB700/800 */
/* VIA */
{ PCI_VDEVICE(VIA, 0x3349), board_ahci_vt8251 }, /* VIA VT8251 */
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4cf8662..fbc2435 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -153,7 +153,7 @@ MODULE_VERSION(DRV_VERSION);
/**
* ata_force_cbl - force cable type according to libata.force
- * @link: ATA link of interest
+ * @ap: ATA port of interest
*
* Force cable type according to libata.force and whine about it.
* The last entry which has matching port number is used, so it
@@ -2396,6 +2396,7 @@ int ata_dev_configure(struct ata_device *dev)
else if (dev->class == ATA_DEV_ATAPI) {
const char *cdb_intr_string = "";
const char *atapi_an_string = "";
+ const char *dma_dir_string = "";
u32 sntf;
rc = atapi_cdb_len(id);
@@ -2436,13 +2437,19 @@ int ata_dev_configure(struct ata_device *dev)
cdb_intr_string = ", CDB intr";
}
+ if (atapi_dmadir || atapi_id_dmadir(dev->id)) {
+ dev->flags |= ATA_DFLAG_DMADIR;
+ dma_dir_string = ", DMADIR";
+ }
+
/* print device info to dmesg */
if (ata_msg_drv(ap) && print_info)
ata_dev_printk(dev, KERN_INFO,
- "ATAPI: %s, %s, max %s%s%s\n",
+ "ATAPI: %s, %s, max %s%s%s%s\n",
modelbuf, fwrevbuf,
ata_mode_string(xfer_mask),
- cdb_intr_string, atapi_an_string);
+
Re: [PATCH 1/1] [SCSI] gdth: misc cleanups, preparation for ISA/EISA hotplug API
Christoph Hellwig wrote: On Sun, Feb 24, 2008 at 12:18:23AM -0500, Jeff Garzik wrote: hm. We'll see how it plays out... on the remove side, the above is exact what happens in gdth_remove_one() without my patch, thus consolidating two cases of the same code into one. There is a less-strong argument for doing the allocation that way, but it may turn out to be useful anyway once the ISA/EISA API conversion is complete. EISA ->remove has a different prototype from PCI ->remove from ISA ->remove, so gdth_remove_one will be split up eventually. Having the scsi_host_put duplicated in each shouldn't be too much of a problem :) We'll see what the final result is... you might turn out to be right. If people want to avoid merging this patch because of this issue, that's fine. Jeff -- 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: power_state: get rid of write-only variable in SATA
Pavel Machek wrote:
power_state is scheduled for removal, and libata uses it in write-only
mode. Remove it.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index b4985bc..a31572d 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6542,8 +6542,6 @@ int ata_host_suspend(struct ata_host *ho
ata_lpm_enable(host);
rc = ata_host_request_pm(host, mesg, 0, ATA_EHI_QUIET, 1);
- if (rc == 0)
- host->dev->power.power_state = mesg;
return rc;
}
@@ -6562,7 +6560,6 @@ void ata_host_resume(struct ata_host *ho
{
ata_host_request_pm(host, PMSG_ON, ATA_EH_SOFTRESET,
ATA_EHI_NO_AUTOPSY | ATA_EHI_QUIET, 0);
- host->dev->power.power_state = PMSG_ON;
applied
--
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/1] [SCSI] gdth: misc cleanups, preparation for ISA/EISA hotplug API
Christoph Hellwig wrote:
Eventually we shoud just kill the INT_COAL ifdefed code. It has never
been enabled and clutters up the driver quite badly.
Noted (queued)... fine by me, and makes life easier.
+#ifdef CONFIG_EISA
+ if ((ha->type == GDT_EISA) && (ha->ccb_phys))
+ pci_unmap_single(ha->pdev, ha->ccb_phys, sizeof(gdth_cmd_str),
+PCI_DMA_BIDIRECTIONAL);
+#endif /* CONFIG_EISA */
I don't think moving this into the common helper makes any sense, as
it's only ever done for the eisa adapter. Just keep it local there.
+#ifdef CONFIG_EISA
+ if (ha->type == GDT_EISA) {
+ ha->ccb_phys = pci_map_single(ha->pdev, >cmdext,
+ sizeof(gdth_cmd_str), PCI_DMA_BIDIRECTIONAL);
+ if (!ha->ccb_phys)
+ goto out_free;
+ }
+#endif /* CONFIG_EISA */
Same here.
hm. We'll see how it plays out... on the remove side, the above is
exact what happens in gdth_remove_one() without my patch, thus
consolidating two cases of the same code into one. There is a
less-strong argument for doing the allocation that way, but it may turn
out to be useful anyway once the ISA/EISA API conversion is complete.
Jeff
--
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] macb: Fix speed setting
Atsushi Nemoto wrote: Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by conversion to generic PHY layer in kernel 2.6.23. Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]> --- diff --git a/drivers/net/macb.c b/drivers/net/macb.c index 81bf005..1d210ed 100644 --- a/drivers/net/macb.c +++ b/drivers/net/macb.c @@ -148,7 +148,7 @@ static void macb_handle_link_change(struct net_device *dev) if (phydev->duplex) reg |= MACB_BIT(FD); - if (phydev->speed) + if (phydev->speed == SPEED_100) reg |= MACB_BIT(SPD); applied -- 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]via-rhine.c: Use-register-offset-definition-for-WOLcgClr
Laura Garcia wrote: Use register offset definition for WOLcgClr. This patch does not change the driver behaviour. Signed-off-by: Laura Garcia Liebana <[EMAIL PROTECTED]> modified: drivers/net/via-rhine.c --- drivers/net/via-rhine.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied, after making the following manual edits: - removed "modified: ..." line, that is redundant to the diffstat, and being before the "---" separator, it is included in the changelog by automated tools - removed all the silly dashes from the subject line. we want something readable, not a filename. -- 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/1] [SCSI] gdth: misc cleanups, preparation for ISA/EISA hotplug API
Several misc. cleanups:
- remove recently-noop'd 'reverse_scan' module parm
- remove pointless function prototypes
- remove ha->pccb, its value always == >cmdext
- move thrice-redundant DMA memory alloc and (in EISA's case, mapping)
into common functions gdth_ha_alloc(), gdth_ha_free()
- delete pointless zero-initializations of ha struct members, as these
are zeroed when ha is allocated (and never assigned any other value,
prior to the explicit zero initializations)
- consolidate thrice-repeated spinlock init
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
---
NOTE: Applies on top of my previous two gdth patches (PCI hotplug prep,
PCI hotplug convert).
drivers/scsi/gdth.c | 299 ++
drivers/scsi/gdth.h |1 -
2 files changed, 108 insertions(+), 192 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index ad9aff2..b17eb15 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -51,8 +51,6 @@
* reserve_list:h,b,t,l,h,b,t,l,... reserve particular drive(s) with
* h- controller no., b- channel no.,
* t- target ID, l- LUN
- * reverse_scan:Y reverse scan order for PCI controllers
- * reverse_scan:N scan PCI controllers like BIOS
* max_ids:xx - target ID count per channel (1..MAXID)
* rescan:Y rescan all channels/IDs
* rescan:N use all devices found until now
@@ -66,7 +64,7 @@
* force_dma32:Yuse only 32 bit DMA mode
* force_dma32:Nuse 64 bit DMA mode, if supported
*
- * The default values are: "gdth=disable:N,reserve_mode:1,reverse_scan:N,
+ * The default values are: "gdth=disable:N,reserve_mode:1,
* max_ids:127,rescan:N,hdr_channel:0,
* shared_access:Y,probe_eisa_isa:N,force_dma32:N".
* Here is another example: "gdth=reserve_list:0,1,2,0,0,1,3,0,rescan:Y".
@@ -77,7 +75,7 @@
* with ' ' and all ':' with '=' and you must use
* '1' in place of 'Y' and '0' in place of 'N'.
*
- * Default: "modprobe gdth disable=0 reserve_mode=1 reverse_scan=0
+ * Default: "modprobe gdth disable=0 reserve_mode=1
* max_ids=127 rescan=0 hdr_channel=0 shared_access=0
* probe_eisa_isa=0 force_dma32=0"
* The other example: "modprobe gdth reserve_list=0,1,2,0,0,1,3,0 rescan=1".
@@ -148,29 +146,13 @@ static int gdth_sync_event(gdth_ha_str *ha, int service,
unchar index,
static int gdth_async_event(gdth_ha_str *ha);
static void gdth_log_event(gdth_evt_data *dvr, char *buffer);
-static void gdth_putq(gdth_ha_str *ha, Scsi_Cmnd *scp, unchar priority);
-static void gdth_next(gdth_ha_str *ha);
static int gdth_fill_raw_cmd(gdth_ha_str *ha, Scsi_Cmnd *scp, unchar b);
static int gdth_special_cmd(gdth_ha_str *ha, Scsi_Cmnd *scp);
-static gdth_evt_str *gdth_store_event(gdth_ha_str *ha, ushort source,
- ushort idx, gdth_evt_data *evt);
static int gdth_read_event(gdth_ha_str *ha, int handle, gdth_evt_str *estr);
-static void gdth_readapp_event(gdth_ha_str *ha, unchar application,
- gdth_evt_str *estr);
-static void gdth_clear_events(void);
-static void gdth_copy_internal_data(gdth_ha_str *ha, Scsi_Cmnd *scp,
-char *buffer, ushort count, int to_buffer);
static int gdth_internal_cache_cmd(gdth_ha_str *ha, Scsi_Cmnd *scp);
static int gdth_fill_cache_cmd(gdth_ha_str *ha, Scsi_Cmnd *scp, ushort hdrive);
-static void gdth_enable_int(gdth_ha_str *ha);
-static int gdth_test_busy(gdth_ha_str *ha);
-static int gdth_get_cmd_index(gdth_ha_str *ha);
-static void gdth_release_event(gdth_ha_str *ha);
-static int gdth_wait(gdth_ha_str *ha, int index,ulong32 time);
-static int gdth_internal_cmd(gdth_ha_str *ha, unchar service, ushort opcode,
- ulong32 p1, ulong64 p2,ulong64
p3);
static int gdth_search_drives(gdth_ha_str *ha);
static int gdth_analyse_hdrive(gdth_ha_str *ha, ushort hdrive);
@@ -181,7 +163,6 @@ static int gdth_close(struct inode *inode, struct file
*filep);
static int gdth_ioctl(struct inode *inode, struct file *filep,
unsigned int cmd, unsigned long arg);
-static void gdth_flush(gdth_ha_str *ha);
static int gdth_halt(struct notifier_block *nb, ulong event, void *buf);
static int gdth_queuecommand(Scsi_Cmnd *scp,void (*done)(Scsi_Cmnd *));
static int __gdth_queuecommand(gdth_ha_str *ha, struct scsi_cmnd *scp,
@@ -336,8 +317,6 @@ static int reserve_list[MAX_RES_ARGS] =
{0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff};
-/* scan order for PCI controllers */
-static
lguest breaks i386 allmodconfig
The following make ARCH=i386 allmodconfig && \ make ARCH=i386 -sj5 on x86-64 produces the following build breakage at the post-build stage: [...] Root device is (9, 0) Setup is 12504 bytes (padded to 12800 bytes). System is 1883 kB Kernel: arch/x86/boot/bzImage is ready (#2) ERROR: "LGUEST_PAGES_guest_gdt_desc" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_gdt_desc" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_cr3" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_regs" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_idt_desc" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_guest_gdt" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_sp" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_regs_trapnum" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_guest_idt_desc" [drivers/lguest/lg.ko] undefined! [...] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] scsi fixes for 2.6.25-rc2
Andrew Morton wrote: On Sat, 23 Feb 2008 12:31:02 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]> wrote: On Sat, 23 Feb 2008, Jeff Garzik wrote: I know I am probably shooting myself in the foot here, since I am the original author of mvsas, but... Should we be adding new drivers during -rc? I'm personally of the opinion that a new driver that doesn't add anything but itself (ie no infrastructure changes etc) is fine. I'd rather have a new, rough driver that might work, than no driver at all, and it's not like it can cause a regression if you don't enable it. Yes, I too think that adding new standalone code in late -rc is OK. ACK, thanks! Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] scsi fixes for 2.6.25-rc2
Olof Johansson wrote: Hi, On Sat, Feb 23, 2008 at 09:13:33AM -0600, James Bottomley wrote: Jeff Garzik (1): mvsas: Add Marvell 6440 SAS/SATA driver [...] drivers/scsi/mvsas.c| 2981 I just noticed that the file permissions on that file are 755 in current git, that was probably not intentional? Definitely not intentional. They were 0644 in the original changeset (the one from me you highlighted), then the second changeset updating mvsas somehow changed the perms. Jeff -- 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] mvsas: fix build warning, clean prototypes
- Fix build 'make randconfig' build warning spotted by Toralf Foerster: drivers/scsi/mvsas.c: In function 'mvs_hexdump': drivers/scsi/mvsas.c:715: error: implicit declaration of function 'isalnum' - Remove unneeded prototypes (spotted by hch) Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> --- NOTE: A proper fix, as noted in initial review (and by hch), would be to convert this driver over to using lib/hexdump.c, to eliminate a hand-rolled hexdump function. drivers/scsi/mvsas.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/scsi/mvsas.c b/drivers/scsi/mvsas.c index 30e20e6..d4a6ac3 100755 --- a/drivers/scsi/mvsas.c +++ b/drivers/scsi/mvsas.c @@ -35,6 +35,7 @@ #include #include #include +#include #include #include @@ -632,15 +633,6 @@ static int mvs_phy_control(struct asd_sas_phy *sas_phy, enum phy_func func, void *funcdata); static u32 mvs_read_phy_ctl(struct mvs_info *mvi, u32 port); static void mvs_write_phy_ctl(struct mvs_info *mvi, u32 port, u32 val); -static u32 mvs_read_port(struct mvs_info *mvi, u32 off, u32 off2, u32 port); -static void mvs_write_port(struct mvs_info *mvi, u32 off, u32 off2, - u32 port, u32 val); -static u32 mvs_read_port_cfg_data(struct mvs_info *mvi, u32 port); -static void mvs_write_port_cfg_data(struct mvs_info *mvi, u32 port, u32 val); -static void mvs_write_port_cfg_addr(struct mvs_info *mvi, u32 port, u32 addr); -static u32 mvs_read_port_vsr_data(struct mvs_info *mvi, u32 port); -static void mvs_write_port_vsr_data(struct mvs_info *mvi, u32 port, u32 val); -static void mvs_write_port_vsr_addr(struct mvs_info *mvi, u32 port, u32 addr); static u32 mvs_read_port_irq_stat(struct mvs_info *mvi, u32 port); static void mvs_write_port_irq_stat(struct mvs_info *mvi, u32 port, u32 val); static void mvs_write_port_irq_mask(struct mvs_info *mvi, u32 port, u32 val); @@ -649,9 +641,6 @@ static u32 mvs_read_port_irq_mask(struct mvs_info *mvi, u32 port); static u32 mvs_is_phy_ready(struct mvs_info *mvi, int i); static void mvs_detect_porttype(struct mvs_info *mvi, int i); static void mvs_update_phyinfo(struct mvs_info *mvi, int i, int get_st); -static void mvs_free_reg_set(struct mvs_info *mvi, struct mvs_port *port); -static u8 mvs_assign_reg_set(struct mvs_info *mvi, struct mvs_port *port); -static u32 mvs_is_sig_fis_received(u32 irq_status); static int mvs_scan_finished(struct Scsi_Host *, unsigned long); static void mvs_scan_start(struct Scsi_Host *); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] scsi fixes for 2.6.25-rc2
Jeff Garzik wrote: On the net driver side of things, I have a few new net drivers that I have queued for 2.6.26, because they did not make the merge window. This is inconsistent with your apparently policy. s/apparently/apparent/ Sometimes my fingers don't type the words that come out of my brain :) Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] scsi fixes for 2.6.25-rc2
James Bottomley wrote: This is the latest crop of bug fixes plus one new driver: mvsas. We're [...] Jeff Garzik (1): mvsas: Add Marvell 6440 SAS/SATA driver [...] Ke Wei (1): mvsas: convert from rough draft to working driver I know I am probably shooting myself in the foot here, since I am the original author of mvsas, but... Should we be adding new drivers during -rc? On one hand, it's clear the addition does not break anything, and adds value for users. On the other hand, it's clearly not a bug fix, and -rc could easily get bloated with new drivers that didn't make the merge window. On the net driver side of things, I have a few new net drivers that I have queued for 2.6.26, because they did not make the merge window. This is inconsistent with your apparently policy. I would just prefer to have a clear and consistent policy here, regarding new drivers during -rc. Thanks, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] scsi fixes for 2.6.25-rc2
James Bottomley wrote: This is the latest crop of bug fixes plus one new driver: mvsas. We're [...] Jeff Garzik (1): mvsas: Add Marvell 6440 SAS/SATA driver [...] Ke Wei (1): mvsas: convert from rough draft to working driver I know I am probably shooting myself in the foot here, since I am the original author of mvsas, but... Should we be adding new drivers during -rc? On one hand, it's clear the addition does not break anything, and adds value for users. On the other hand, it's clearly not a bug fix, and -rc could easily get bloated with new drivers that didn't make the merge window. On the net driver side of things, I have a few new net drivers that I have queued for 2.6.26, because they did not make the merge window. This is inconsistent with your apparently policy. I would just prefer to have a clear and consistent policy here, regarding new drivers during -rc. Thanks, Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] scsi fixes for 2.6.25-rc2
Jeff Garzik wrote: On the net driver side of things, I have a few new net drivers that I have queued for 2.6.26, because they did not make the merge window. This is inconsistent with your apparently policy. s/apparently/apparent/ Sometimes my fingers don't type the words that come out of my brain :) Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] scsi fixes for 2.6.25-rc2
Olof Johansson wrote: Hi, On Sat, Feb 23, 2008 at 09:13:33AM -0600, James Bottomley wrote: Jeff Garzik (1): mvsas: Add Marvell 6440 SAS/SATA driver [...] drivers/scsi/mvsas.c| 2981 I just noticed that the file permissions on that file are 755 in current git, that was probably not intentional? Definitely not intentional. They were 0644 in the original changeset (the one from me you highlighted), then the second changeset updating mvsas somehow changed the perms. Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] scsi fixes for 2.6.25-rc2
Andrew Morton wrote: On Sat, 23 Feb 2008 12:31:02 -0800 (PST) Linus Torvalds [EMAIL PROTECTED] wrote: On Sat, 23 Feb 2008, Jeff Garzik wrote: I know I am probably shooting myself in the foot here, since I am the original author of mvsas, but... Should we be adding new drivers during -rc? I'm personally of the opinion that a new driver that doesn't add anything but itself (ie no infrastructure changes etc) is fine. I'd rather have a new, rough driver that might work, than no driver at all, and it's not like it can cause a regression if you don't enable it. Yes, I too think that adding new standalone code in late -rc is OK. ACK, thanks! Jeff -- 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/
lguest breaks i386 allmodconfig
The following make ARCH=i386 allmodconfig \ make ARCH=i386 -sj5 on x86-64 produces the following build breakage at the post-build stage: [...] Root device is (9, 0) Setup is 12504 bytes (padded to 12800 bytes). System is 1883 kB Kernel: arch/x86/boot/bzImage is ready (#2) ERROR: LGUEST_PAGES_guest_gdt_desc [drivers/lguest/lg.ko] undefined! ERROR: LGUEST_PAGES_host_gdt_desc [drivers/lguest/lg.ko] undefined! ERROR: LGUEST_PAGES_host_cr3 [drivers/lguest/lg.ko] undefined! ERROR: LGUEST_PAGES_regs [drivers/lguest/lg.ko] undefined! ERROR: LGUEST_PAGES_host_idt_desc [drivers/lguest/lg.ko] undefined! ERROR: LGUEST_PAGES_guest_gdt [drivers/lguest/lg.ko] undefined! ERROR: LGUEST_PAGES_host_sp [drivers/lguest/lg.ko] undefined! ERROR: LGUEST_PAGES_regs_trapnum [drivers/lguest/lg.ko] undefined! ERROR: LGUEST_PAGES_guest_idt_desc [drivers/lguest/lg.ko] undefined! [...] -- 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/1] [SCSI] gdth: misc cleanups, preparation for ISA/EISA hotplug API
Several misc. cleanups:
- remove recently-noop'd 'reverse_scan' module parm
- remove pointless function prototypes
- remove ha-pccb, its value always == ha-cmdext
- move thrice-redundant DMA memory alloc and (in EISA's case, mapping)
into common functions gdth_ha_alloc(), gdth_ha_free()
- delete pointless zero-initializations of ha struct members, as these
are zeroed when ha is allocated (and never assigned any other value,
prior to the explicit zero initializations)
- consolidate thrice-repeated spinlock init
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
---
NOTE: Applies on top of my previous two gdth patches (PCI hotplug prep,
PCI hotplug convert).
drivers/scsi/gdth.c | 299 ++
drivers/scsi/gdth.h |1 -
2 files changed, 108 insertions(+), 192 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index ad9aff2..b17eb15 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -51,8 +51,6 @@
* reserve_list:h,b,t,l,h,b,t,l,... reserve particular drive(s) with
* h- controller no., b- channel no.,
* t- target ID, l- LUN
- * reverse_scan:Y reverse scan order for PCI controllers
- * reverse_scan:N scan PCI controllers like BIOS
* max_ids:xx - target ID count per channel (1..MAXID)
* rescan:Y rescan all channels/IDs
* rescan:N use all devices found until now
@@ -66,7 +64,7 @@
* force_dma32:Yuse only 32 bit DMA mode
* force_dma32:Nuse 64 bit DMA mode, if supported
*
- * The default values are: gdth=disable:N,reserve_mode:1,reverse_scan:N,
+ * The default values are: gdth=disable:N,reserve_mode:1,
* max_ids:127,rescan:N,hdr_channel:0,
* shared_access:Y,probe_eisa_isa:N,force_dma32:N.
* Here is another example: gdth=reserve_list:0,1,2,0,0,1,3,0,rescan:Y.
@@ -77,7 +75,7 @@
* with ' ' and all ':' with '=' and you must use
* '1' in place of 'Y' and '0' in place of 'N'.
*
- * Default: modprobe gdth disable=0 reserve_mode=1 reverse_scan=0
+ * Default: modprobe gdth disable=0 reserve_mode=1
* max_ids=127 rescan=0 hdr_channel=0 shared_access=0
* probe_eisa_isa=0 force_dma32=0
* The other example: modprobe gdth reserve_list=0,1,2,0,0,1,3,0 rescan=1.
@@ -148,29 +146,13 @@ static int gdth_sync_event(gdth_ha_str *ha, int service,
unchar index,
static int gdth_async_event(gdth_ha_str *ha);
static void gdth_log_event(gdth_evt_data *dvr, char *buffer);
-static void gdth_putq(gdth_ha_str *ha, Scsi_Cmnd *scp, unchar priority);
-static void gdth_next(gdth_ha_str *ha);
static int gdth_fill_raw_cmd(gdth_ha_str *ha, Scsi_Cmnd *scp, unchar b);
static int gdth_special_cmd(gdth_ha_str *ha, Scsi_Cmnd *scp);
-static gdth_evt_str *gdth_store_event(gdth_ha_str *ha, ushort source,
- ushort idx, gdth_evt_data *evt);
static int gdth_read_event(gdth_ha_str *ha, int handle, gdth_evt_str *estr);
-static void gdth_readapp_event(gdth_ha_str *ha, unchar application,
- gdth_evt_str *estr);
-static void gdth_clear_events(void);
-static void gdth_copy_internal_data(gdth_ha_str *ha, Scsi_Cmnd *scp,
-char *buffer, ushort count, int to_buffer);
static int gdth_internal_cache_cmd(gdth_ha_str *ha, Scsi_Cmnd *scp);
static int gdth_fill_cache_cmd(gdth_ha_str *ha, Scsi_Cmnd *scp, ushort hdrive);
-static void gdth_enable_int(gdth_ha_str *ha);
-static int gdth_test_busy(gdth_ha_str *ha);
-static int gdth_get_cmd_index(gdth_ha_str *ha);
-static void gdth_release_event(gdth_ha_str *ha);
-static int gdth_wait(gdth_ha_str *ha, int index,ulong32 time);
-static int gdth_internal_cmd(gdth_ha_str *ha, unchar service, ushort opcode,
- ulong32 p1, ulong64 p2,ulong64
p3);
static int gdth_search_drives(gdth_ha_str *ha);
static int gdth_analyse_hdrive(gdth_ha_str *ha, ushort hdrive);
@@ -181,7 +163,6 @@ static int gdth_close(struct inode *inode, struct file
*filep);
static int gdth_ioctl(struct inode *inode, struct file *filep,
unsigned int cmd, unsigned long arg);
-static void gdth_flush(gdth_ha_str *ha);
static int gdth_halt(struct notifier_block *nb, ulong event, void *buf);
static int gdth_queuecommand(Scsi_Cmnd *scp,void (*done)(Scsi_Cmnd *));
static int __gdth_queuecommand(gdth_ha_str *ha, struct scsi_cmnd *scp,
@@ -336,8 +317,6 @@ static int reserve_list[MAX_RES_ARGS] =
{0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff};
-/* scan order for PCI controllers */
-static int reverse_scan = 0;
/* virtual channel for the host drives */
static
Re: [PATCH 1/2]via-rhine.c: Use-register-offset-definition-for-WOLcgClr
Laura Garcia wrote: Use register offset definition for WOLcgClr. This patch does not change the driver behaviour. Signed-off-by: Laura Garcia Liebana [EMAIL PROTECTED] modified: drivers/net/via-rhine.c --- drivers/net/via-rhine.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied, after making the following manual edits: - removed modified: ... line, that is redundant to the diffstat, and being before the --- separator, it is included in the changelog by automated tools - removed all the silly dashes from the subject line. we want something readable, not a filename. -- 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] macb: Fix speed setting
Atsushi Nemoto wrote: Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by conversion to generic PHY layer in kernel 2.6.23. Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED] --- diff --git a/drivers/net/macb.c b/drivers/net/macb.c index 81bf005..1d210ed 100644 --- a/drivers/net/macb.c +++ b/drivers/net/macb.c @@ -148,7 +148,7 @@ static void macb_handle_link_change(struct net_device *dev) if (phydev-duplex) reg |= MACB_BIT(FD); - if (phydev-speed) + if (phydev-speed == SPEED_100) reg |= MACB_BIT(SPD); applied -- 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/1] [SCSI] gdth: misc cleanups, preparation for ISA/EISA hotplug API
Christoph Hellwig wrote:
Eventually we shoud just kill the INT_COAL ifdefed code. It has never
been enabled and clutters up the driver quite badly.
Noted (queued)... fine by me, and makes life easier.
+#ifdef CONFIG_EISA
+ if ((ha-type == GDT_EISA) (ha-ccb_phys))
+ pci_unmap_single(ha-pdev, ha-ccb_phys, sizeof(gdth_cmd_str),
+PCI_DMA_BIDIRECTIONAL);
+#endif /* CONFIG_EISA */
I don't think moving this into the common helper makes any sense, as
it's only ever done for the eisa adapter. Just keep it local there.
+#ifdef CONFIG_EISA
+ if (ha-type == GDT_EISA) {
+ ha-ccb_phys = pci_map_single(ha-pdev, ha-cmdext,
+ sizeof(gdth_cmd_str), PCI_DMA_BIDIRECTIONAL);
+ if (!ha-ccb_phys)
+ goto out_free;
+ }
+#endif /* CONFIG_EISA */
Same here.
hm. We'll see how it plays out... on the remove side, the above is
exact what happens in gdth_remove_one() without my patch, thus
consolidating two cases of the same code into one. There is a
less-strong argument for doing the allocation that way, but it may turn
out to be useful anyway once the ISA/EISA API conversion is complete.
Jeff
--
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: power_state: get rid of write-only variable in SATA
Pavel Machek wrote:
power_state is scheduled for removal, and libata uses it in write-only
mode. Remove it.
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index b4985bc..a31572d 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6542,8 +6542,6 @@ int ata_host_suspend(struct ata_host *ho
ata_lpm_enable(host);
rc = ata_host_request_pm(host, mesg, 0, ATA_EHI_QUIET, 1);
- if (rc == 0)
- host-dev-power.power_state = mesg;
return rc;
}
@@ -6562,7 +6560,6 @@ void ata_host_resume(struct ata_host *ho
{
ata_host_request_pm(host, PMSG_ON, ATA_EH_SOFTRESET,
ATA_EHI_NO_AUTOPSY | ATA_EHI_QUIET, 0);
- host-dev-power.power_state = PMSG_ON;
applied
--
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/1] [SCSI] gdth: misc cleanups, preparation for ISA/EISA hotplug API
Christoph Hellwig wrote: On Sun, Feb 24, 2008 at 12:18:23AM -0500, Jeff Garzik wrote: hm. We'll see how it plays out... on the remove side, the above is exact what happens in gdth_remove_one() without my patch, thus consolidating two cases of the same code into one. There is a less-strong argument for doing the allocation that way, but it may turn out to be useful anyway once the ISA/EISA API conversion is complete. EISA -remove has a different prototype from PCI -remove from ISA -remove, so gdth_remove_one will be split up eventually. Having the scsi_host_put duplicated in each shouldn't be too much of a problem :) We'll see what the final result is... you might turn out to be right. If people want to avoid merging this patch because of this issue, that's fine. Jeff -- 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/
[git patches] libata fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ahci.c| 23 +--
drivers/ata/libata-core.c | 16 ++--
drivers/ata/libata-pmp.c |4 ++--
drivers/ata/libata-scsi.c |3 ++-
drivers/ata/pata_atiixp.c |4 ++--
drivers/ata/sata_fsl.c|8 +---
include/linux/ata.h |5 +
include/linux/libata.h|1 +
8 files changed, 44 insertions(+), 20 deletions(-)
Alan Cox (1):
pata_atiixp: Use 255 sector limit
Anton Vorontsov (1):
sata_fsl: fix build with ATA_VERBOSE_DEBUG
Mark Lord (1):
libata-pmp: clear hob for pmp register accesses
Pavel Machek (1):
power_state: get rid of write-only variable in SATA
Randy Dunlap (1):
libata-core: fix kernel-doc warning
Shane Huang (1):
[libata] ahci: AMD SB700/SB800 SATA support 64bit DMA
Tejun Heo (1):
libata: automatically use DMADIR if drive/bridge requires it
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 6dd12f7..1db93b6 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -85,6 +85,7 @@ enum {
board_ahci_ign_iferr= 2,
board_ahci_sb600= 3,
board_ahci_mv = 4,
+ board_ahci_sb700= 5,
/* global controller registers */
HOST_CAP= 0x00, /* host capabilities */
@@ -442,6 +443,16 @@ static const struct ata_port_info ahci_port_info[] = {
.udma_mask = ATA_UDMA6,
.port_ops = ahci_ops,
},
+ /* board_ahci_sb700 */
+ {
+ AHCI_HFLAGS (AHCI_HFLAG_IGN_SERR_INTERNAL |
+AHCI_HFLAG_NO_PMP),
+ .flags = AHCI_FLAG_COMMON,
+ .link_flags = AHCI_LFLAG_COMMON,
+ .pio_mask = 0x1f, /* pio0-4 */
+ .udma_mask = ATA_UDMA6,
+ .port_ops = ahci_ops,
+ },
};
static const struct pci_device_id ahci_pci_tbl[] = {
@@ -484,12 +495,12 @@ static const struct pci_device_id ahci_pci_tbl[] = {
/* ATI */
{ PCI_VDEVICE(ATI, 0x4380), board_ahci_sb600 }, /* ATI SB600 */
- { PCI_VDEVICE(ATI, 0x4390), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4391), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4392), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4393), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4394), board_ahci_sb600 }, /* ATI SB700/800 */
- { PCI_VDEVICE(ATI, 0x4395), board_ahci_sb600 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4390), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4391), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4392), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4393), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4394), board_ahci_sb700 }, /* ATI SB700/800 */
+ { PCI_VDEVICE(ATI, 0x4395), board_ahci_sb700 }, /* ATI SB700/800 */
/* VIA */
{ PCI_VDEVICE(VIA, 0x3349), board_ahci_vt8251 }, /* VIA VT8251 */
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4cf8662..fbc2435 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -153,7 +153,7 @@ MODULE_VERSION(DRV_VERSION);
/**
* ata_force_cbl - force cable type according to libata.force
- * @link: ATA link of interest
+ * @ap: ATA port of interest
*
* Force cable type according to libata.force and whine about it.
* The last entry which has matching port number is used, so it
@@ -2396,6 +2396,7 @@ int ata_dev_configure(struct ata_device *dev)
else if (dev-class == ATA_DEV_ATAPI) {
const char *cdb_intr_string = ;
const char *atapi_an_string = ;
+ const char *dma_dir_string = ;
u32 sntf;
rc = atapi_cdb_len(id);
@@ -2436,13 +2437,19 @@ int ata_dev_configure(struct ata_device *dev)
cdb_intr_string = , CDB intr;
}
+ if (atapi_dmadir || atapi_id_dmadir(dev-id)) {
+ dev-flags |= ATA_DFLAG_DMADIR;
+ dma_dir_string = , DMADIR;
+ }
+
/* print device info to dmesg */
if (ata_msg_drv(ap) print_info)
ata_dev_printk(dev, KERN_INFO,
- ATAPI: %s, %s, max %s%s%s\n,
+ ATAPI: %s, %s, max %s%s%s%s\n,
modelbuf, fwrevbuf,
ata_mode_string(xfer_mask),
- cdb_intr_string, atapi_an_string);
+ cdb_intr_string,
Re: [git patches] net driver fixes
David Miller wrote: Jeff, I really don't want to pull that tree in. Please trust me as your upstream to handle merging issues, as needed. I trust you... Otherwise I wouldn't have volunteered to move my upstream from Linus to you :) My main issues/motivations were: * quite simply, just force of habit: I'm used to basing off of a recent Linus tree, to guarantee buildboot testing against the latest. * worry about testing against a too-old tree, where non-networking fixes may have a relevant impact on my to-be-pushed netdrvr fixes. But in this case it's fair to say there are no such issues, and it was mainly just out of habit. So (as you saw in last email)... rebased and resend. Jeff -- 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: Question about your git habits
Daniel Barkalow wrote: I find that the sequence of changes I make is pretty much unrelated to the sequence of changes that end up in the project's history, because my changes as I make them involve writing a lot of stubs (so I can build) and then filling them out. It's beneficial to have version control on this so that, if I screw up filling out a stub, I can get back to where I was. Having made a complete series, I then generate a new series of commits, each of which does one thing, without any bugs that I've resolved, such that the net result is the end of the messy history, except with any debugging or useless stuff skipped. It's this series that gets merged into the project history, and I discard the other history. The real trick is that the early patches in a lot of series often refactor existing code in ways that are generally good and necessary for your eventual outcome, but which you'd never think of until you've written more of the series. That summarizes well how I do original development, too. Whether its a branch of an existing repo, or a newly cloned repo, when working on new code I will do a first pass, committing as I go to provide useful checkpoints. Once I reach a satisfactory state, I'll refactor the patches so that they make sense for upstream submission. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 + smartd = hang
Anders Eriksson wrote: Is smartd prepared to handle /dev/sdX style devices? Yes. You need to pass "-d ata" to smartd and smartctl, if your scripts are not already doing so. If this is the prefered driver these days, maybe it shouldn't be marked experimental in the menu anymore? It's not marked experimental. Jeff -- 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: Merging of completely unreviewed drivers
Ingo Molnar wrote: 2) you might know that Deja-Vu moment when you look at a new patch that has been submitted to lkml and you have a strange, weird "feeling" that there's something wrong about the patch. It's totally subconscious, and you take a closer look and a few seconds later you find a real bug in the code. That "feeling" i believe comes from a fundamental property of how human vision is connected to the human brain: pattern matching. Really good programmers have built a "library" of patterns of "good" and "bad" looking coding practices. If a patch or if a file has a clean _style_, bugs and deeper structural problems often stand out like a sore thumb. But if the [...] The best programmers are the ones who have a good eye for details - and that subconsciously extends to "style details" too. I've yet to see a _single_ example of a good, experienced kernel programmer who writes code that looks absolutely careless and sloppy, but which is top-notch otherwise. (Newbies will make style mistakes a lot more often - and for them checkpatch is a nice and easy experience at reading other people's code and trying to learn the style of the kernel.) [...] 4) there's a psychological effect as well: clean _looking_ code is more attractive to coders to improve upon. Once the code _looks_ clean (mechanically), the people with the real structural cleanups are not far away either. Code that just looks nice is simply more of a pleasure to work with and to improve, so there's a strong psychological relationship between the "small, seemingly unimportant details" cleanups and the real, structural cleanups. The above deserved to be quoted... just because I agree with all of it so strongly :) Bugs really do "hide" in ugly code, in part because my brain has been optimized to review clean code. Like everything else in life, one must strike a balance between picking style nits with someone's patch, and making honest criticisms of a patch because said patch is too "unclean" to be reviewed by anyone. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 + smartd = hang
Anders Eriksson wrote: Hi, Trying out 2.6.25-rc2 smartd always causes my box to hang. I can switch vt:s and the keyboard seems to work. Using sysrq-e I noticed a callpath open -> ext3 -> journals -> sync_buffer -> io_scheduel -> generic_unplig_device. I'd guess the open stems from smartd. Removing smartd from the startup, I'm now using rc2 fine... I got a nice jpg showing it as well. The sysrq-e output is probably just standard ext3 journalling unrelated to the problem... what does dmesg say? lspci? What's your hardware setup? Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 + smartd = hang
Anders Eriksson wrote: Hi, Trying out 2.6.25-rc2 smartd always causes my box to hang. I can switch vt:s and the keyboard seems to work. Using sysrq-e I noticed a callpath open - ext3 - journals - sync_buffer - io_scheduel - generic_unplig_device. I'd guess the open stems from smartd. Removing smartd from the startup, I'm now using rc2 fine... I got a nice jpg showing it as well. The sysrq-e output is probably just standard ext3 journalling unrelated to the problem... what does dmesg say? lspci? What's your hardware setup? Jeff -- 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: Merging of completely unreviewed drivers
Ingo Molnar wrote: 2) you might know that Deja-Vu moment when you look at a new patch that has been submitted to lkml and you have a strange, weird feeling that there's something wrong about the patch. It's totally subconscious, and you take a closer look and a few seconds later you find a real bug in the code. That feeling i believe comes from a fundamental property of how human vision is connected to the human brain: pattern matching. Really good programmers have built a library of patterns of good and bad looking coding practices. If a patch or if a file has a clean _style_, bugs and deeper structural problems often stand out like a sore thumb. But if the [...] The best programmers are the ones who have a good eye for details - and that subconsciously extends to style details too. I've yet to see a _single_ example of a good, experienced kernel programmer who writes code that looks absolutely careless and sloppy, but which is top-notch otherwise. (Newbies will make style mistakes a lot more often - and for them checkpatch is a nice and easy experience at reading other people's code and trying to learn the style of the kernel.) [...] 4) there's a psychological effect as well: clean _looking_ code is more attractive to coders to improve upon. Once the code _looks_ clean (mechanically), the people with the real structural cleanups are not far away either. Code that just looks nice is simply more of a pleasure to work with and to improve, so there's a strong psychological relationship between the small, seemingly unimportant details cleanups and the real, structural cleanups. The above deserved to be quoted... just because I agree with all of it so strongly :) Bugs really do hide in ugly code, in part because my brain has been optimized to review clean code. Like everything else in life, one must strike a balance between picking style nits with someone's patch, and making honest criticisms of a patch because said patch is too unclean to be reviewed by anyone. Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 + smartd = hang
Anders Eriksson wrote: Is smartd prepared to handle /dev/sdX style devices? Yes. You need to pass -d ata to smartd and smartctl, if your scripts are not already doing so. If this is the prefered driver these days, maybe it shouldn't be marked experimental in the menu anymore? It's not marked experimental. Jeff -- 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: Question about your git habits
Daniel Barkalow wrote: I find that the sequence of changes I make is pretty much unrelated to the sequence of changes that end up in the project's history, because my changes as I make them involve writing a lot of stubs (so I can build) and then filling them out. It's beneficial to have version control on this so that, if I screw up filling out a stub, I can get back to where I was. Having made a complete series, I then generate a new series of commits, each of which does one thing, without any bugs that I've resolved, such that the net result is the end of the messy history, except with any debugging or useless stuff skipped. It's this series that gets merged into the project history, and I discard the other history. The real trick is that the early patches in a lot of series often refactor existing code in ways that are generally good and necessary for your eventual outcome, but which you'd never think of until you've written more of the series. That summarizes well how I do original development, too. Whether its a branch of an existing repo, or a newly cloned repo, when working on new code I will do a first pass, committing as I go to provide useful checkpoints. Once I reach a satisfactory state, I'll refactor the patches so that they make sense for upstream submission. Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] XFS update for 2.6.25-rc3
Lachlan McIlroy wrote: Remove empty file fs/xfs/Makefile-linux-2.6. Already in the upstream kernel... commit 1803f3389b7ac9ed33ea561b3b94e22e2864a95d Author: Linus Torvalds <[EMAIL PROTECTED]> Date: Wed Feb 20 19:55:09 2008 -0800 Remove empty file remnants that were left in the tree by mistake Noted by various people (Sam, Jeff, Roland..) Commit 58b7983d15a422d9616bdc4e245d5c31dfaefbe2 intended to remove the xfs "Makefile-linux-2.6" file, but it was mistakenly still left in the tree as a empty file, and would cause git to correctly complain about a tracked file being removed after a "make distclean" (which removes empty files as garbage). And the asm-x86/desc_64.h file was supposed to be removed by commit c81c6ca45a69478c7877b729af1942d2b80ef582, but instead stayed around containing just a single newline. Get rid of them both properly. Signed-off-by: Linus Torvalds <[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: Merging of completely unreviewed drivers
Krzysztof Halasa wrote: Jeff Garzik <[EMAIL PROTECTED]> writes: If a driver is full of lines of length >80, that's a problem. I'm not sure. We all have more than 80-chars wide displays for years, don't we? The Every time this discussion comes up, people point out that it remains highly common to open multiple 80-column terminal windows, making the 80-column limit still highly relevant in modern times. The problem is [...] code which is too complex and which may sometimes have too many levels of indentation. Quite true. Jeff -- 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: power_state: get rid of write-only variable in SATA
Pavel Machek wrote:
power_state is scheduled for removal, and libata uses it in write-only
mode. Remove it.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index b4985bc..a31572d 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6542,8 +6542,6 @@ int ata_host_suspend(struct ata_host *ho
ata_lpm_enable(host);
rc = ata_host_request_pm(host, mesg, 0, ATA_EHI_QUIET, 1);
- if (rc == 0)
- host->dev->power.power_state = mesg;
return rc;
}
@@ -6562,7 +6560,6 @@ void ata_host_resume(struct ata_host *ho
{
ata_host_request_pm(host, PMSG_ON, ATA_EH_SOFTRESET,
ATA_EHI_NO_AUTOPSY | ATA_EHI_QUIET, 0);
- host->dev->power.power_state = PMSG_ON;
/* reenable link pm */
ata_lpm_disable(host);
libata uses it under the assumption that "other parts" of the system are
aware of this variable.
May I assume that the API has changed such that this is no longer necessary?
Jeff
--
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: power_state: get rid of write-only variable in SATA
Pavel Machek wrote:
power_state is scheduled for removal, and libata uses it in write-only
mode. Remove it.
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index b4985bc..a31572d 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6542,8 +6542,6 @@ int ata_host_suspend(struct ata_host *ho
ata_lpm_enable(host);
rc = ata_host_request_pm(host, mesg, 0, ATA_EHI_QUIET, 1);
- if (rc == 0)
- host-dev-power.power_state = mesg;
return rc;
}
@@ -6562,7 +6560,6 @@ void ata_host_resume(struct ata_host *ho
{
ata_host_request_pm(host, PMSG_ON, ATA_EH_SOFTRESET,
ATA_EHI_NO_AUTOPSY | ATA_EHI_QUIET, 0);
- host-dev-power.power_state = PMSG_ON;
/* reenable link pm */
ata_lpm_disable(host);
libata uses it under the assumption that other parts of the system are
aware of this variable.
May I assume that the API has changed such that this is no longer necessary?
Jeff
--
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: Merging of completely unreviewed drivers
Krzysztof Halasa wrote: Jeff Garzik [EMAIL PROTECTED] writes: If a driver is full of lines of length 80, that's a problem. I'm not sure. We all have more than 80-chars wide displays for years, don't we? The Every time this discussion comes up, people point out that it remains highly common to open multiple 80-column terminal windows, making the 80-column limit still highly relevant in modern times. The problem is [...] code which is too complex and which may sometimes have too many levels of indentation. Quite true. Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] XFS update for 2.6.25-rc3
Lachlan McIlroy wrote: Remove empty file fs/xfs/Makefile-linux-2.6. Already in the upstream kernel... commit 1803f3389b7ac9ed33ea561b3b94e22e2864a95d Author: Linus Torvalds [EMAIL PROTECTED] Date: Wed Feb 20 19:55:09 2008 -0800 Remove empty file remnants that were left in the tree by mistake Noted by various people (Sam, Jeff, Roland..) Commit 58b7983d15a422d9616bdc4e245d5c31dfaefbe2 intended to remove the xfs Makefile-linux-2.6 file, but it was mistakenly still left in the tree as a empty file, and would cause git to correctly complain about a tracked file being removed after a make distclean (which removes empty files as garbage). And the asm-x86/desc_64.h file was supposed to be removed by commit c81c6ca45a69478c7877b729af1942d2b80ef582, but instead stayed around containing just a single newline. Get rid of them both properly. Signed-off-by: Linus Torvalds [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: [git patches] net driver updates
Divy Le Ray wrote:
Jeff Garzik wrote:
Mostly fixes, a few cleanups (generally assisting fixes), and an
exception for PS3 wireless because it had been posted, reviewed and
acked for a while, just not committed.
Please pull from 'upstream-davem' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-davem
to receive the following updates:
drivers/net/cxgb3/sge.c | 35 +-
diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c
index 9ca8c66..979f3fc 100644
--- a/drivers/net/cxgb3/sge.c
+++ b/drivers/net/cxgb3/sge.c
@@ -1059,6 +1059,14 @@ static void write_tx_pkt_wr(struct adapter
*adap, struct sk_buff *skb,
htonl(V_WR_TID(q->token)));
}
+static inline void t3_stop_queue(struct net_device *dev, struct
sge_qset *qs,
+ struct sge_txq *q)
+{
+netif_stop_queue(dev);
+set_bit(TXQ_ETH, >txq_stopped);
+q->stops++;
+}
+
/**
*eth_xmit - add a packet to the Ethernet Tx queue
*@skb: the packet
@@ -1090,31 +1098,18 @@ int t3_eth_xmit(struct sk_buff *skb, struct
net_device *dev)
ndesc = calc_tx_descs(skb);
if (unlikely(credits < ndesc)) {
-if (!netif_queue_stopped(dev)) {
-netif_stop_queue(dev);
-set_bit(TXQ_ETH, >txq_stopped);
-q->stops++;
-dev_err(>pdev->dev,
-"%s: Tx ring %u full while queue awake!\n",
-dev->name, q->cntxt_id & 7);
-}
+t3_stop_queue(dev, qs, q);
+dev_err(>pdev->dev,
+"%s: Tx ring %u full while queue awake!\n",
+dev->name, q->cntxt_id & 7);
spin_unlock(>lock);
return NETDEV_TX_BUSY;
}
q->in_use += ndesc;
-if (unlikely(credits - ndesc < q->stop_thres)) {
-q->stops++;
-netif_stop_queue(dev);
-set_bit(TXQ_ETH, >txq_stopped);
-#if !USE_GTS
-if (should_restart_tx(q) &&
-test_and_clear_bit(TXQ_ETH, >txq_stopped)) {
-q->restarts++;
-netif_wake_queue(dev);
-}
-#endif
-}
+if (unlikely(credits - ndesc < q->stop_thres))
+if (USE_GTS || !should_restart_tx(q))
+t3_stop_queue(dev, qs, q);
gen = q->gen;
q->unacked += ndesc;
Hi Jeff,
I thought I had NAK'ed the patch modifying sge.c from Krishna Kumar.
Looking back at my answer at the time, I was obviously unclear.
Can you please revert the drivers/net/cxgb3sge.c change ?
Explain why, so I can include it in the changelog please...
Jeff
--
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: [bug] Re: [PATCH 4/12] riscom8: fix SMP brokenness
Ingo Molnar wrote:
* Jeff Garzik <[EMAIL PROTECTED]> wrote:
After analyzing the elements that save_flags/cli/sti/restore_flags
were protecting, convert their usages to a global spinlock (the
easiest and most obvious next-step). There were some usages of flags
being intentionally cached, because the code already knew the state of
interrupts. These have been taken into account.
This allows us to remove CONFIG_BROKEN_ON_SMP. Completely untested.
regression for sale :-) The above patch, after sitting in -mm for
approximately 3 months, just went upstream today via commit
d9afa43532adf8a31b93c4c7601f and promptly broke tonight's x86.git
randconfig qa run via tons of these messages:
[3.768431] BUG: scheduling while atomic: swapper/1/0x0002
[3.769430] 1 lock held by swapper/1:
[3.770437] #0: (riscom_lock){--..}, at: [<80389ceb>]
rc_release_drivers+0xe/0x33
[3.776430] Pid: 1, comm: swapper Not tainted 2.6.24 #14
[3.777428] [<801167d3>] __schedule_bug+0x6e/0x75
[3.779427] [<80756065>] schedule+0x35c/0x429
[3.781427] [<80103a0b>] ? restore_nocheck+0x12/0x15
[3.784427] [<80103a0b>] ? restore_nocheck+0x12/0x15
[3.786426] [<80756381>] schedule_timeout+0x69/0xa2
[3.788426] [<80758337>] ? _spin_unlock_irq+0x25/0x40
[3.790426] [<80755c0e>] wait_for_common+0x96/0x10d
[3.792425] [<80115edc>] ? default_wake_function+0x0/0xd
[3.794425] [<80755d07>] wait_for_completion+0x12/0x14
[3.796425] [<801282fe>] call_usermodehelper_exec+0x78/0x8c
[3.798424] [<8015a041>] ? slob_alloc+0xd8/0x1ad
[3.800424] [<80301640>] kobject_uevent_env+0x3ae/0x3c5
[3.802424] [<803ac361>] ? dev_uevent+0x0/0x25a
[3.804424] [<80301661>] kobject_uevent+0xa/0xc
[3.806423] [<803acc06>] device_del+0x139/0x15d
[3.808423] [<803acc58>] device_unregister+0x2e/0x3b
[3.810423] [<803acc8e>] device_destroy+0x29/0x2f
[3.812422] [<8035965f>] tty_unregister_device+0x18/0x1a
[3.814422] [<8035970b>] tty_unregister_driver+0xaa/0xf6
[3.816422] [<80389cf7>] rc_release_drivers+0x1a/0x33
[3.818421] [<80ac5e16>] riscom8_init_module+0x4ff/0x539
[3.820421] [<8012e76f>] ? ktime_get_ts+0x44/0x49
[3.822421] [<80aaf701>] kernel_init+0x9a/0x263
[3.824421] [<80ac5917>] ? riscom8_init_module+0x0/0x539
[3.827420] [<80aaf667>] ? kernel_init+0x0/0x263
[3.829420] [<8010455f>] kernel_thread_helper+0x7/0x18
[3.831419] ===
This is unfortunately very low on the priority stack. I was a bit
surprised when it went in, honestly, since I hadn't gotten any "it
works" test reports yet... but that's my fault for not keeping akpm up
to date.
We'll want to revert this for 2.6.25 release, if it doesn't get fixed up.
Jeff
--
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/
[git patches] libata fixes
Note: Tejun's change is a feature addition, but one that is IMO
important for debugging and serious-bug workarounds. It's
self-contained and should not affect anyone not using the new parm.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
Documentation/kernel-parameters.txt | 35
drivers/ata/libata-core.c | 380 ++-
drivers/ata/libata-eh.c |8 +-
drivers/ata/libata-scsi.c |2 +-
drivers/ata/libata.h|1 +
drivers/ata/pata_legacy.c | 44 ++--
drivers/ata/sata_mv.c |9 +-
include/linux/libata.h |2 +-
8 files changed, 448 insertions(+), 33 deletions(-)
Harvey Harrison (2):
ata: fix sparse warnings in pata_legacy.c
ata: fix sparse warning in libata.h
Martin Michlmayr (1):
sata_mv: Define module alias for platform device
Randy Dunlap (1):
libata: fix kernel-doc parameter warning
Saeed Bishara (2):
sata_mv: use hpriv->base instead of the host->iomap
sata_mv: remove iounmap in mv_platform_remove and use devm_iomap
Tejun Heo (1):
libata: implement libata.force module parameter
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 7278295..9a5b665 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -950,6 +950,41 @@ and is between 256 and 4096 characters. It is defined in
the file
when set.
Format:
+ libata.force= [LIBATA] Force configurations. The format is comma
+ separated list of "[ID:]VAL" where ID is
+ PORT[:DEVICE]. PORT and DEVICE are decimal numbers
+ matching port, link or device. Basically, it matches
+ the ATA ID string printed on console by libata. If
+ the whole ID part is omitted, the last PORT and DEVICE
+ values are used. If ID hasn't been specified yet, the
+ configuration applies to all ports, links and devices.
+
+ If only DEVICE is omitted, the parameter applies to
+ the port and all links and devices behind it. DEVICE
+ number of 0 either selects the first device or the
+ first fan-out link behind PMP device. It does not
+ select the host link. DEVICE number of 15 selects the
+ host link and device attached to it.
+
+ The VAL specifies the configuration to force. As long
+ as there's no ambiguity shortcut notation is allowed.
+ For example, both 1.5 and 1.5G would work for 1.5Gbps.
+ The following configurations can be forced.
+
+ * Cable type: 40c, 80c, short40c, unk, ign or sata.
+ Any ID with matching PORT is used.
+
+ * SATA link speed limit: 1.5Gbps or 3.0Gbps.
+
+ * Transfer mode: pio[0-7], mwdma[0-4] and udma[0-7].
+ udma[/][16,25,33,44,66,100,133] notation is also
+ allowed.
+
+ * [no]ncq: Turn on or off NCQ.
+
+ If there are multiple matching configurations changing
+ the same attribute, the last one is used.
+
load_ramdisk= [RAM] List of ramdisks to load from floppy
See Documentation/ramdisk.txt.
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index def3682..60d1bb5 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -87,6 +87,28 @@ static struct workqueue_struct *ata_wq;
struct workqueue_struct *ata_aux_wq;
+struct ata_force_param {
+ const char *name;
+ unsigned intcbl;
+ int spd_limit;
+ unsigned long xfer_mask;
+ unsigned inthorkage_on;
+ unsigned inthorkage_off;
+};
+
+struct ata_force_ent {
+ int port;
+ int device;
+ struct ata_force_param param;
+};
+
+static struct ata_force_ent *ata_force_tbl;
+static int ata_force_tbl_size;
+
+static char ata_force_param_buf[PAGE_SIZE] __initdata;
+module_param_string(force, ata_force_param_buf, sizeof(ata_force_param_buf),
0444);
+MODULE_PARM_DESC(force, "Force ATA configurations including cable type, link
speed and transfer mode (see Documentation/kernel-parameters.txt for details)");
+
int atapi_enabled = 1;
module_param(atapi_enabled, int, 0444);
MODULE_PARM_DESC(atapi_enabled, "Enable discovery of ATAPI devices (0=off,
1=on)");
@@ -130,6 +152,179 @@ MODULE_VERSION(DRV_VERSION);
/**
+ *
Re: [PATCH] ata: replace macro with static inline in libata.h
Harvey Harrison wrote:
Avoid ~70 sparse warnings like:
drivers/ata/pata_ali.c:176:14: warning: symbol '__x' shadows an earlier one
drivers/ata/pata_ali.c:176:14: originally declared here
Due to nesting min_t macro inside max_t macro which both use a __x
identifier internally.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
Andrew, here is a patch that drastically reduces the number of sparse
warnings in libata. Alan Cox has suggested a clamp_t macro be added
to kernel.h instead to avoid this issue. I don't believe Jeff Garzik
has given an opinion yet (other than not applying it when originally
sent this was 5/11 of the libata sparse warnings)
include/linux/libata.h |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/include/linux/libata.h b/include/linux/libata.h
index bc5a8d0..b5590fb 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -764,7 +764,14 @@ struct ata_timing {
unsigned short udma;/* t2CYCTYP/2 */
};
-#define FIT(v, vmin, vmax) max_t(short, min_t(short, v, vmax), vmin)
+static inline short FIT(short v, short vmin, short vmax)
+{
+ if (v >= vmax)
+ return vmax;
+ if (v <= vmin)
+ return vmin;
+ return v;
+}
I agree with Alan...
--
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] libata: Register for dock events when the drive is inside a dock station
Holger Macht wrote:
On Thu 14. Feb - 13:40:48, Holger Macht wrote:
If a device/bay is inside a docking station, we need to register for dock
events additionally to bay events. If a dock event occurs, the dock driver
will call the appropriate handler (ata_acpi_ap_notify() or
ata_acpi_dev_notify()) for us.
Signed-off-by: Holger Macht <[EMAIL PROTECTED]>
Updated patch which only includes the dock specific function if the dock
driver is actually compiled.
Signed-off-by: Holger Macht <[EMAIL PROTECTED]>
---
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 9e8ec19..5f16055 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -191,20 +191,33 @@ void ata_acpi_associate(struct ata_host *host)
else
ata_acpi_associate_ide_port(ap);
- if (ap->acpi_handle)
+ if (ap->acpi_handle) {
acpi_install_notify_handler (ap->acpi_handle,
ACPI_SYSTEM_NOTIFY,
ata_acpi_ap_notify,
ap);
+#ifdef CONFIG_ACPI_DOCK
+ /* we might be on a docking station */
+ register_hotplug_dock_device(ap->acpi_handle,
+ata_acpi_ap_notify, ap);
+#endif
+ }
for (j = 0; j < ata_link_max_devices(>link); j++) {
struct ata_device *dev = >link.device[j];
- if (dev->acpi_handle)
+ if (dev->acpi_handle) {
acpi_install_notify_handler (dev->acpi_handle,
ACPI_SYSTEM_NOTIFY,
ata_acpi_dev_notify,
dev);
+#ifdef CONFIG_ACPI_DOCK
+ /* we might be on a docking station */
+ register_hotplug_dock_device(ap->acpi_handle,
+
ata_acpi_dev_notify,
+ap);
+#endif
CONFIG_ACPI_DOCK is a tristate, so you might have CONFIG_ACPI_DOCK_MODULE...
--
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 11/11v2] ata: fix sparse warnings in pata_legacy.c
Harvey Harrison wrote: Use ld_qdi and ld_winbond to avoid shadowing static int variables qdi and winbond. The ld_ prefix refers to legacy_data. drivers/ata/pata_legacy.c:777:21: warning: symbol 'qdi' shadows an earlier one drivers/ata/pata_legacy.c:128:12: originally declared here drivers/ata/pata_legacy.c:811:21: warning: symbol 'qdi' shadows an earlier one drivers/ata/pata_legacy.c:128:12: originally declared here drivers/ata/pata_legacy.c:848:21: warning: symbol 'qdi' shadows an earlier one drivers/ata/pata_legacy.c:128:12: originally declared here drivers/ata/pata_legacy.c:882:21: warning: symbol 'qdi' shadows an earlier one drivers/ata/pata_legacy.c:128:12: originally declared here drivers/ata/pata_legacy.c:1040:21: warning: symbol 'winbond' shadows an earlier one drivers/ata/pata_legacy.c:129:12: originally declared here Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]> --- Alan Cox's suggestion of using a ld_ prefix incorporated. applied -- 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] Add PCI_DEVICE_TABLE macro
Greg KH wrote: On Mon, Feb 18, 2008 at 08:34:42AM +0100, Jonas Bonn wrote: And again, what does this buy us? Clarity and simplicity, I hope... there are a bunch of definitions scattered about the kernel that omit the __devinitdata modifier despite the documentation stating that it should always be there. The definition really should have been const, which wasn't possible before but has become so with the addition of the __devinitconst attribute. Furthermore, there are definitions that use "const" and __devinitdata, which is explicitly wrong but the compiler doesn't catch section mismatches if there's only one such one case in the module (which is often the case). Adding the __devinitconst modifier where there was nothing before buys us memory. Adding the const modifier gives the compiler a chance to do its thing. Changing __devinitdata to __devinitconst where it was wrong actually fixes some compiler errors in older (mid-release) kernels that were patched over by "removing" the section attribute altogether (which wastes memory). Adding the macro (Olof's idea, not mine) makes it pretty difficult to get this definition wrong... I'll do the rest of the cleanup, but I need to know whether it's better to use a macro like this, or to open code the definitions. I prefer the macro approach... Hope this makes some sense... Ok, yes it does, thanks for the explaination. Please, can you add this very good text to the changelog entry for the addition of the macro, and to the documentation somewhere? I'd be glad to take the patch if that was done. I would suggest having a DECLARE_ prefix in there, like other subsystems do... Jeff -- 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/
XFS makefile-2.6 lives on
In current upstream, fs/xfs/Makefile-linux-2.6 is zero bytes, which means 'make distclean' deletes, and git promptly (and properly) squawks about a working tree/index difference. Would somebody please delete this file? Thanks, Jeff -- 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/
[git patches] net driver fixes
Note: this is based off of Linus's latest commit
(5d9c4a7de64d398604a978d267a6987f1f4025b7), since all my previous
submissions are now upstream (thanks!).
Please pull from 'upstream-davem' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-davem
to receive the following updates:
MAINTAINERS| 11 +-
drivers/net/cs89x0.c | 12 +-
drivers/net/ehea/ehea.h| 34 +-
drivers/net/ehea/ehea_main.c | 281 +---
drivers/net/fs_enet/fs_enet-main.c |7 +-
drivers/net/gianfar.c | 14 +-
drivers/net/igb/igb_main.c | 15 +--
drivers/net/pcmcia/pcnet_cs.c | 10 +-
drivers/net/phy/mdio_bus.c |4 +-
drivers/net/sis190.c | 15 ++-
drivers/net/tlan.c | 64
drivers/net/tulip/uli526x.c| 12 ++-
drivers/net/virtio_net.c |2 +-
drivers/s390/net/claw.c| 39 +++---
14 files changed, 399 insertions(+), 121 deletions(-)
Adrian Bunk (1):
net/phy/mdio_bus.c: fix a check-after-use
Andy Gospodarek (1):
igb: fix legacy mode irq issue
Becky Bruce (1):
gianfar: don't pass NULL dev ptr to DMA ops
Bill Hayes (1):
igb: Fix panic with NICs with 1000BASE-SX PHY
Christian Borntraeger (1):
virtio_net: Fix oops on early interrupts - introduced by virtio reset code
Francois Romieu (1):
sis190: read the mac address from the eeprom first
Grant Grundler (2):
update TULIP MAINTAINERS
uli526x partially recognizing interface
Harvey Harrison (1):
tlan: add static to function definitions
Julia Lawall (1):
claw: make use of DIV_ROUND_UP
Komuro (1):
pcnet_cs: if AX88190-based card, printk "use axnet_cs instead" message.
Leonardo Potenza (1):
drivers/net/cs89x0.c: compilation warning fix
Scott Wood (1):
fs_enet: Don't call phy_mii_ioctl() in atomic context.
Thomas Klein (1):
ehea: add kdump support
diff --git a/MAINTAINERS b/MAINTAINERS
index 082d1ee..53b6e60 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3887,10 +3887,13 @@ M: [EMAIL PROTECTED]
L: linux-kernel@vger.kernel.org
S: Maintained
-TULIP NETWORK DRIVER
-L: [EMAIL PROTECTED]
-W: http://sourceforge.net/projects/tulip/
-S: Orphan
+TULIP NETWORK DRIVERS
+P: Grant Grundler
+M: [EMAIL PROTECTED]
+P: Kyle McMartin
+M: [EMAIL PROTECTED]
+L: [EMAIL PROTECTED]
+S: Maintained
TUN/TAP driver
P: Maxim Krasnyansky
diff --git a/drivers/net/cs89x0.c b/drivers/net/cs89x0.c
index 5717509..348371f 100644
--- a/drivers/net/cs89x0.c
+++ b/drivers/net/cs89x0.c
@@ -172,30 +172,30 @@ static char version[] __initdata =
them to system IRQ numbers. This mapping is card specific and is set to
the configuration of the Cirrus Eval board for this chip. */
#ifdef CONFIG_ARCH_CLPS7500
-static unsigned int netcard_portlist[] __initdata =
+static unsigned int netcard_portlist[] __used __initdata =
{ 0x80090303, 0x300, 0x320, 0x340, 0x360, 0x200, 0x220, 0x240, 0x260,
0x280, 0x2a0, 0x2c0, 0x2e0, 0};
static unsigned int cs8900_irq_map[] = {12,0,0,0};
#elif defined(CONFIG_SH_HICOSH4)
-static unsigned int netcard_portlist[] __initdata =
+static unsigned int netcard_portlist[] __used __initdata =
{ 0x0300, 0};
static unsigned int cs8900_irq_map[] = {1,0,0,0};
#elif defined(CONFIG_MACH_IXDP2351)
-static unsigned int netcard_portlist[] __initdata =
{IXDP2351_VIRT_CS8900_BASE, 0};
+static unsigned int netcard_portlist[] __used __initdata =
{IXDP2351_VIRT_CS8900_BASE, 0};
static unsigned int cs8900_irq_map[] = {IRQ_IXDP2351_CS8900, 0, 0, 0};
#include
#elif defined(CONFIG_ARCH_IXDP2X01)
#include
-static unsigned int netcard_portlist[] __initdata =
{IXDP2X01_CS8900_VIRT_BASE, 0};
+static unsigned int netcard_portlist[] __used __initdata =
{IXDP2X01_CS8900_VIRT_BASE, 0};
static unsigned int cs8900_irq_map[] = {IRQ_IXDP2X01_CS8900, 0, 0, 0};
#elif defined(CONFIG_ARCH_PNX010X)
#include
#include
#define CIRRUS_DEFAULT_BASEIO_ADDRESS(EXT_STATIC2_s0_BASE + 0x20)
/* = Physical address 0x4820 */
#define CIRRUS_DEFAULT_IRQ VH_INTC_INT_NUM_CASCADED_INTERRUPT_1 /* Event
inputs bank 1 - ID 35/bit 3 */
-static unsigned int netcard_portlist[] __initdata = {CIRRUS_DEFAULT_BASE, 0};
+static unsigned int netcard_portlist[] __used __initdata =
{CIRRUS_DEFAULT_BASE, 0};
static unsigned int cs8900_irq_map[] = {CIRRUS_DEFAULT_IRQ, 0, 0, 0};
#else
-static unsigned int netcard_portlist[] __initdata =
+static unsigned int netcard_portlist[] __used __initdata =
{ 0x300, 0x320, 0x340, 0x360, 0x200, 0x220, 0x240, 0x260, 0x280, 0x2a0,
0x2c0, 0x2e0, 0};
static unsigned int cs8900_irq_map[] = {10,11,12,5};
#endif
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 88fb53e..7c4ead3 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
Re: [2.6 patch] net/phy/mdio_bus.c: fix a check-after-use
Adrian Bunk wrote: This patch fixes a check-after-use spotted by the Coverity checker. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- 6beeb3ac577d74d72b2f91bd654eecb904c3c17e diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c index 6e9f619..963630c 100644 --- a/drivers/net/phy/mdio_bus.c +++ b/drivers/net/phy/mdio_bus.c @@ -49,13 +49,13 @@ int mdiobus_register(struct mii_bus *bus) int i; int err = 0; - mutex_init(>mdio_lock); - if (NULL == bus || NULL == bus->name || NULL == bus->read || NULL == bus->write) return -EINVAL; + mutex_init(>mdio_lock); + applied -- 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] tlan: add static to function definitions
Harvey Harrison wrote: The forward declarations were already marked static, make the definitions be static as well. Fixes the sparse warnings as well. drivers/net/tlan.c:1403:5: warning: symbol 'TLan_HandleInvalid' was not declared. Should it be static? drivers/net/tlan.c:1435:5: warning: symbol 'TLan_HandleTxEOF' was not declared. Should it be static? drivers/net/tlan.c:1521:5: warning: symbol 'TLan_HandleStatOverflow' was not declared. Should it be static? drivers/net/tlan.c:1557:5: warning: symbol 'TLan_HandleRxEOF' was not declared. Should it be static? drivers/net/tlan.c:1692:5: warning: symbol 'TLan_HandleDummy' was not declared. Should it be static? drivers/net/tlan.c:1722:5: warning: symbol 'TLan_HandleTxEOC' was not declared. Should it be static? drivers/net/tlan.c:1770:5: warning: symbol 'TLan_HandleStatusCheck' was not declared. Should it be static? drivers/net/tlan.c:1845:5: warning: symbol 'TLan_HandleRxEOC' was not declared. Should it be static? drivers/net/tlan.c:1905:6: warning: symbol 'TLan_Timer' was not declared. Should it be static? drivers/net/tlan.c:1986:6: warning: symbol 'TLan_ResetLists' was not declared. Should it be static? drivers/net/tlan.c:2046:6: warning: symbol 'TLan_FreeLists' was not declared. Should it be static? drivers/net/tlan.c:2095:6: warning: symbol 'TLan_PrintDio' was not declared. Should it be static? drivers/net/tlan.c:2130:6: warning: symbol 'TLan_PrintList' was not declared. Should it be static? drivers/net/tlan.c:2166:6: warning: symbol 'TLan_ReadAndClearStats' was not declared. Should it be static? drivers/net/tlan.c:2242:1: warning: symbol 'TLan_ResetAdapter' was not declared. Should it be static? drivers/net/tlan.c:2328:1: warning: symbol 'TLan_FinishReset' was not declared. Should it be static? drivers/net/tlan.c:2451:6: warning: symbol 'TLan_SetMac' was not declared. Should it be static? drivers/net/tlan.c:2493:6: warning: symbol 'TLan_PhyPrint' was not declared. Should it be static? drivers/net/tlan.c:2542:6: warning: symbol 'TLan_PhyDetect' was not declared. Should it be static? drivers/net/tlan.c:2589:6: warning: symbol 'TLan_PhyPowerDown' was not declared. Should it be static? drivers/net/tlan.c:2614:6: warning: symbol 'TLan_PhyPowerUp' was not declared. Should it be static? drivers/net/tlan.c:2635:6: warning: symbol 'TLan_PhyReset' was not declared. Should it be static? drivers/net/tlan.c:2663:6: warning: symbol 'TLan_PhyStartLink' was not declared. Should it be static? drivers/net/tlan.c:2750:6: warning: symbol 'TLan_PhyFinishAutoNeg' was not declared. Should it be static? drivers/net/tlan.c:2906:5: warning: symbol 'TLan_MiiReadReg' was not declared. Should it be static? drivers/net/tlan.c:2996:6: warning: symbol 'TLan_MiiSendData' was not declared. Should it be static? drivers/net/tlan.c:3038:6: warning: symbol 'TLan_MiiSync' was not declared. Should it be static? drivers/net/tlan.c:3077:6: warning: symbol 'TLan_MiiWriteReg' was not declared. Should it be static? drivers/net/tlan.c:3147:6: warning: symbol 'TLan_EeSendStart' was not declared. Should it be static? drivers/net/tlan.c:3187:5: warning: symbol 'TLan_EeSendByte' was not declared. Should it be static? drivers/net/tlan.c:3248:6: warning: symbol 'TLan_EeReceiveByte' was not declared. Should it be static? drivers/net/tlan.c:3306:5: warning: symbol 'TLan_EeReadByte' was not declared. Should it be static? Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]> --- Kept the style consistent with the rest of the file, checkpatch will complain. drivers/net/tlan.c | 64 ++-- 1 files changed, 32 insertions(+), 32 deletions(-) applied -- 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] drivers/net/cs89x0.c: compilation warning fix
Leonardo Potenza wrote: From: Leonardo Potenza <[EMAIL PROTECTED]> Suppress the warning message about the 'netcard_portlist' defined but not used. Signed-off-by: Leonardo Potenza <[EMAIL PROTECTED]> --- When building cs89x0 as a module, the following warning message is generated: drivers/net/cs89x0.c:198: warning: 'netcard_portlist' defined but not used Since the netcard_portlist is not so big, I just marked the array as __used. applied -- 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] ehea: add kdump support
Thomas Klein wrote: This patch adds kdump support to the ehea driver. As the firmware doesn't free resource handles automatically, the driver has to run an as simple as possible free resource function in case of a crash shutdown. The function iterates over two arrays freeing all resource handles which are stored there. The arrays are kept up-to-date during normal runtime. The crash handler fn is triggered by the recently introduced PPC crash shutdown reg/unreg functions. Signed-off-by: Thomas Klein <[EMAIL PROTECTED]> --- drivers/net/ehea/ehea.h | 34 +- drivers/net/ehea/ehea_main.c | 281 ++ 2 files changed, 290 insertions(+), 25 deletions(-) applied -- 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] ehea: add kdump support
Thomas Klein wrote: This patch adds kdump support to the ehea driver. As the firmware doesn't free resource handles automatically, the driver has to run an as simple as possible free resource function in case of a crash shutdown. The function iterates over two arrays freeing all resource handles which are stored there. The arrays are kept up-to-date during normal runtime. The crash handler fn is triggered by the recently introduced PPC crash shutdown reg/unreg functions. Signed-off-by: Thomas Klein [EMAIL PROTECTED] --- drivers/net/ehea/ehea.h | 34 +- drivers/net/ehea/ehea_main.c | 281 ++ 2 files changed, 290 insertions(+), 25 deletions(-) applied -- 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] drivers/net/cs89x0.c: compilation warning fix
Leonardo Potenza wrote: From: Leonardo Potenza [EMAIL PROTECTED] Suppress the warning message about the 'netcard_portlist' defined but not used. Signed-off-by: Leonardo Potenza [EMAIL PROTECTED] --- When building cs89x0 as a module, the following warning message is generated: drivers/net/cs89x0.c:198: warning: 'netcard_portlist' defined but not used Since the netcard_portlist is not so big, I just marked the array as __used. applied -- 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] tlan: add static to function definitions
Harvey Harrison wrote: The forward declarations were already marked static, make the definitions be static as well. Fixes the sparse warnings as well. drivers/net/tlan.c:1403:5: warning: symbol 'TLan_HandleInvalid' was not declared. Should it be static? drivers/net/tlan.c:1435:5: warning: symbol 'TLan_HandleTxEOF' was not declared. Should it be static? drivers/net/tlan.c:1521:5: warning: symbol 'TLan_HandleStatOverflow' was not declared. Should it be static? drivers/net/tlan.c:1557:5: warning: symbol 'TLan_HandleRxEOF' was not declared. Should it be static? drivers/net/tlan.c:1692:5: warning: symbol 'TLan_HandleDummy' was not declared. Should it be static? drivers/net/tlan.c:1722:5: warning: symbol 'TLan_HandleTxEOC' was not declared. Should it be static? drivers/net/tlan.c:1770:5: warning: symbol 'TLan_HandleStatusCheck' was not declared. Should it be static? drivers/net/tlan.c:1845:5: warning: symbol 'TLan_HandleRxEOC' was not declared. Should it be static? drivers/net/tlan.c:1905:6: warning: symbol 'TLan_Timer' was not declared. Should it be static? drivers/net/tlan.c:1986:6: warning: symbol 'TLan_ResetLists' was not declared. Should it be static? drivers/net/tlan.c:2046:6: warning: symbol 'TLan_FreeLists' was not declared. Should it be static? drivers/net/tlan.c:2095:6: warning: symbol 'TLan_PrintDio' was not declared. Should it be static? drivers/net/tlan.c:2130:6: warning: symbol 'TLan_PrintList' was not declared. Should it be static? drivers/net/tlan.c:2166:6: warning: symbol 'TLan_ReadAndClearStats' was not declared. Should it be static? drivers/net/tlan.c:2242:1: warning: symbol 'TLan_ResetAdapter' was not declared. Should it be static? drivers/net/tlan.c:2328:1: warning: symbol 'TLan_FinishReset' was not declared. Should it be static? drivers/net/tlan.c:2451:6: warning: symbol 'TLan_SetMac' was not declared. Should it be static? drivers/net/tlan.c:2493:6: warning: symbol 'TLan_PhyPrint' was not declared. Should it be static? drivers/net/tlan.c:2542:6: warning: symbol 'TLan_PhyDetect' was not declared. Should it be static? drivers/net/tlan.c:2589:6: warning: symbol 'TLan_PhyPowerDown' was not declared. Should it be static? drivers/net/tlan.c:2614:6: warning: symbol 'TLan_PhyPowerUp' was not declared. Should it be static? drivers/net/tlan.c:2635:6: warning: symbol 'TLan_PhyReset' was not declared. Should it be static? drivers/net/tlan.c:2663:6: warning: symbol 'TLan_PhyStartLink' was not declared. Should it be static? drivers/net/tlan.c:2750:6: warning: symbol 'TLan_PhyFinishAutoNeg' was not declared. Should it be static? drivers/net/tlan.c:2906:5: warning: symbol 'TLan_MiiReadReg' was not declared. Should it be static? drivers/net/tlan.c:2996:6: warning: symbol 'TLan_MiiSendData' was not declared. Should it be static? drivers/net/tlan.c:3038:6: warning: symbol 'TLan_MiiSync' was not declared. Should it be static? drivers/net/tlan.c:3077:6: warning: symbol 'TLan_MiiWriteReg' was not declared. Should it be static? drivers/net/tlan.c:3147:6: warning: symbol 'TLan_EeSendStart' was not declared. Should it be static? drivers/net/tlan.c:3187:5: warning: symbol 'TLan_EeSendByte' was not declared. Should it be static? drivers/net/tlan.c:3248:6: warning: symbol 'TLan_EeReceiveByte' was not declared. Should it be static? drivers/net/tlan.c:3306:5: warning: symbol 'TLan_EeReadByte' was not declared. Should it be static? Signed-off-by: Harvey Harrison [EMAIL PROTECTED] --- Kept the style consistent with the rest of the file, checkpatch will complain. drivers/net/tlan.c | 64 ++-- 1 files changed, 32 insertions(+), 32 deletions(-) applied -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] net/phy/mdio_bus.c: fix a check-after-use
Adrian Bunk wrote: This patch fixes a check-after-use spotted by the Coverity checker. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- 6beeb3ac577d74d72b2f91bd654eecb904c3c17e diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c index 6e9f619..963630c 100644 --- a/drivers/net/phy/mdio_bus.c +++ b/drivers/net/phy/mdio_bus.c @@ -49,13 +49,13 @@ int mdiobus_register(struct mii_bus *bus) int i; int err = 0; - mutex_init(bus-mdio_lock); - if (NULL == bus || NULL == bus-name || NULL == bus-read || NULL == bus-write) return -EINVAL; + mutex_init(bus-mdio_lock); + applied -- 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/
