Re: [discuss] ide=reverse do we still need this?
On Wed, Feb 13, 2008 at 08:54:55AM +0100, Dirk GOUDERS wrote: Hi, I'm reworking the pci device list logic (we currently keep all PCI devices in 2 lists, which isn't the nicest, we should be able to get away with only 1 list.) The only bother I've found so far is the pci_get_device_reverse() function, it's used in 2 places, IDE and the calgary driver. I'm curious if we really still support the ide=reverse option? It's a config option that I don't think the distros still enable (SuSE does not). Is this still needed these days? In digging, we changed this option in 2.2.x from being called pci=reverse and no one else seems to miss it. Any thoughts? I remember vaguely that some years ago, we set up a box with four IDE disks as a RAID set. For that purpose, we added a PCI ATA100 controller so that each disk could act as a primary IDE device and we were only able to boot the system with the option ide=reverse. That box has been replaced by some other so I cannot verify it but as far as I remember it was a problem with disk numbering between BIOS, bootloader and/or kernel. Also, at that time we used lilo and I am not sure if grub would have done better. Hm, so, to summarize: - you needed this option many years ago to get a box to work properly - you don't need this today So, if the option went away, you would not be inconvenienced? thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [discuss] ide=reverse do we still need this?
Hm, so, to summarize: - you needed this option many years ago to get a box to work properly - you don't need this today I would summarize: - ide=reverse solved certain problems and I am not sure if there are users who still need this option So, if the option went away, you would not be inconvenienced? I remember that the disks of the old box are still in a drawer and today, I will try to reanimate the system and see if grub's ability to map drives helps to boot the system without ide=reverse. I'll report later. Dirk - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[libata-dev #upstream-fixes] pata_legacy: don't call ata_host_detach() after initialization failure
ata_host_detach() detaches an attached port and shouldn't be called on a port which hasn't been attached yet. pata_legacy incorrectly calls ata_host_detach() on unattached port after initialization failure causing oops. Fix it. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Alan Cox [EMAIL PROTECTED] Cc: Ingo Molnar [EMAIL PROTECTED] Cc: Arjan van de Ven [EMAIL PROTECTED] --- drivers/ata/pata_legacy.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c index 333dc15..7383f19 100644 --- a/drivers/ata/pata_legacy.c +++ b/drivers/ata/pata_legacy.c @@ -1278,8 +1278,6 @@ static __init int legacy_init_one(struct legacy_probe *probe) } } fail: - if (host) - ata_host_detach(host); platform_device_unregister(pdev); return ret; } - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHSET] printk: implement printk_header() and merging printk, take #3
Hello, all. This is the third take of implement-printk_header-and-mprintk patchset. Changes from the last take[L] are... * Now header is printed on every line of a multiline message. If the header ends with ':' followed by spaces. The colon is replaced with space from the second line. * s/mprintk/mprintk_flush/ and s/mprintk_add/mprintk/ as suggested. * mprintk_init_alloc() and mprintk_free() added to ease malloc'd buffer handling. No need to specify buffer size. Sizing is left to mprintk. This patchset aims to make printing multiline messages and assembling message piece-by-piece easier. In a nutshell, printk_header() lets you do the following atomically (against other messages). code: printk(KERN_INFO ata1.00: , line0\nline1\nline2\n); output: 6ata1.00: line0 6ata1.00 line1 6ata1.00 line2 And mprintk the following. code: DEFINE_MPRINTK(mp, 2 * 80); mprintk_set_header(mp, KERN_INFO ata%u.%2u: , 1, 0); mprintk_push(mp, ATA %d, 7); mprintk_push(mp, , %u sectors\n, 1024); mprintk(mp, everything seems dandy\n); output: 6ata1.00: ATA 7, 1024 sectors 6ata1.00 everything seems dandy For more info, please read Documentation/printk.txt which is created by the fourth patch. This patchset is on top of linux-2.6#master (96b5a46e2a72dc1829370c87053e0cd558d58bc0) + printk-fix-possible-printk-buffer-overrun [1] + printk-implement-printk_buf-overflow-warning [2] and contains the following patches. 0001-printk-keep-log-level-on-multiline-messages.patch 0002-printk-implement-v-printk_header.patch 0003-printk-implement-merging-printk.patch 0004-printk-add-Documentation-printk.txt.patch 0005-libata-make-libata-use-printk_header-and-mprintk.patch Documentation/00-INDEX |2 Documentation/printk.txt| 724 drivers/ata/libata-core.c | 204 +++- drivers/ata/libata-eh.c | 182 +-- drivers/ata/libata-pmp.c|5 drivers/ata/libata-scsi.c |6 drivers/ata/sata_inic162x.c |2 drivers/ata/sata_nv.c |4 include/linux/kernel.h | 85 + include/linux/libata.h | 35 +- kernel/printk.c | 435 -- 11 files changed, 1453 insertions(+), 231 deletions(-) If this gets acked, I think it's best to push it through libata-dev as libata is the first user. Thanks. -- tejun [L] http://thread.gmane.org/gmane.linux.ide/27317 [1] http://article.gmane.org/gmane.linux.kernel/639018 [2] http://article.gmane.org/gmane.linux.kernel/639029 - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] printk: keep log level on multiline messages
When printing multiline messages, printk() resets log level to
default_message_loglevel after the first line. This changes log level
unexpectedly when printing multiline messages.
For example, libata error messages are printed like the following.
3ata8.00: cmd 60/01:00:e0:71:02/00:00:00:00:00/40 tag 0 ncq 512 in
4 res 40/00:34:de:71:02/00:00:00:00:00/40 Emask 0x10 (ATA bus error)
This patch makes printk use the log level of the last line if the
current line doesn't specify log level explicitly.
While at it, separate out is_loglevel() test. This will be used by
later changes.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
kernel/printk.c | 50 +++---
1 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/kernel/printk.c b/kernel/printk.c
index 419cd47..2317ec8 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -614,6 +614,11 @@ asmlinkage int printk(const char *fmt, ...)
return r;
}
+static int is_loglevel(const char *p)
+{
+ return p[0] == '' p[1] = '0' p[1] = '7' p[2] == '';
+}
+
asmlinkage int vprintk(const char *fmt, va_list args)
{
/* cpu currently holding logbuf_lock */
@@ -625,10 +630,11 @@ asmlinkage int vprintk(const char *fmt, va_list args)
static int log_level_unknown = 1;
static char printk_buf[PRINTK_BUF_LEN + sizeof(overflow_tag) - 1];
+ int last_lv = default_message_loglevel;
unsigned long flags;
int printed_len = 0;
int this_cpu;
- char *p;
+ const char *p;
boot_delay_msec();
@@ -682,47 +688,37 @@ asmlinkage int vprintk(const char *fmt, va_list args)
for (p = printk_buf; *p; p++) {
if (log_level_unknown) {
/* log_level_unknown signals the start of a new line */
+ int lv = last_lv;
+
+ if (is_loglevel(p)) {
+ lv = p[1] - '0';
+ p += 3;
+ printed_len -= 3;
+ }
+
+ emit_log_char('');
+ emit_log_char(lv + '0');
+ emit_log_char('');
+ printed_len += 3;
+
if (printk_time) {
- int loglev_char;
char tbuf[50], *tp;
unsigned tlen;
unsigned long long t;
unsigned long nanosec_rem;
- /*
-* force the log level token to be
-* before the time output.
-*/
- if (p[0] == '' p[1] ='0'
- p[1] = '7' p[2] == '') {
- loglev_char = p[1];
- p += 3;
- printed_len -= 3;
- } else {
- loglev_char = default_message_loglevel
- + '0';
- }
t = cpu_clock(printk_cpu);
nanosec_rem = do_div(t, 10);
- tlen = sprintf(tbuf,
- %c[%5lu.%06lu] ,
- loglev_char,
+ tlen = sprintf(tbuf, [%5lu.%06lu] ,
(unsigned long)t,
nanosec_rem/1000);
for (tp = tbuf; tp tbuf + tlen; tp++)
emit_log_char(*tp);
printed_len += tlen;
- } else {
- if (p[0] != '' || p[1] '0' ||
- p[1] '7' || p[2] != '') {
- emit_log_char('');
- emit_log_char(default_message_loglevel
- + '0');
- emit_log_char('');
- printed_len += 3;
- }
}
+
+ last_lv = lv;
log_level_unknown = 0;
if (!*p)
break;
--
1.5.2.4
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] printk: implement merging printk
There often are times printk messages need to be assembled piece by
piece and it's usually done using one of the following methods.
* Calling printk() on partial message segments. This used to be quite
common but has a problem - the message can break up if someone else
prints something in the middle.
* Prepping a temp buffer and build message piece-by-piece using
snprintf(). This is the most generic solution but corner case
handling can be tedious and on overflow messages can be lost and
such overflows would go unnoticed if overflow detection isn't
properly done.
* Collect all the partial data and perform printk() once with all the
parameters. This is often combined with the second. This usually
works but printing messages can become non-trivial programming
problem and can get quite tedious if the message format varies
depending on data.
None of the above is quite satisfactory. This patch implement merging
printk - mprintk to deal with this problem. It's basically a helper
to construct message piece-by-piece into the specified buffer. The
caller still has to care about buffer size and how the buffer is
allocated but mprintk makes it easier.
* DEFINE_MPRINTK() macro makes it easy to define a mprintk instance
with on-stack buffer. Malloc'd buffer can also be used.
* Message is never lost. On buffer overflow, all queued and to be
queued messages are printed followed by warning message and stack
dump. The warning message and stack dump are printed only once per
mprintk instance. The caller also doesn't have to handle buffer
malloc failure. If buffer is initialized to NULL, mprintk simply
bypasses the messages to printk().
* Has good support for multiline messages. A mprintk instance can
have header associated with it and the header can have log level.
Header log level is used if a partial message doesn't specify log
level explicitly. When log level is specified explicitly in a
partial message, the log level is applied to the partial message
only.
A simple example.
DEFINE_MPRINTK(mp, 2 * 80);
mprintk_set_header(mp, KERN_DEBUG ata%u.%2u: , 1, 0);
mprintk_push(mp, ATA %d, 7);
mprintk_push(mp, , %u sectors\n, 1024);
mprintk(mp, everything seems dandy\n);
Which will be printed like the following as a single message.
7ata1.00: ATA 7, 1024 sectors
7ata1.00 everything seems dandy
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
include/linux/kernel.h | 73
kernel/printk.c| 300 +++-
2 files changed, 370 insertions(+), 3 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index d885208..a9cbda8 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -177,6 +177,27 @@ struct pid;
extern struct pid *session_of_pgrp(struct pid *pgrp);
#ifdef CONFIG_PRINTK
+struct mprintk {
+ char*buf;
+ char*body;
+ char*cur;
+ char*end;
+ unsigned intflags;
+};
+
+#define MPRINTK_INITIALIZER(_buf, _size) \
+ { \
+ .buf= _buf, \
+ .body = _buf, \
+ .cur= _buf, \
+ .end= _buf + _size, \
+ .flags = 0 \
+ }
+
+#define DEFINE_MPRINTK(name, size) \
+ char __##name##_buf[size]; \
+ struct mprintk name = MPRINTK_INITIALIZER(__##name##_buf, size)
+
asmlinkage int vprintk_header(const char *header, const char *fmt, va_list
args)
__attribute__ ((format (printf, 2, 0)));
asmlinkage int printk_header(const char *header, const char * fmt, ...)
@@ -185,6 +206,26 @@ asmlinkage int vprintk(const char *fmt, va_list args)
__attribute__ ((format (printf, 1, 0)));
asmlinkage int printk(const char * fmt, ...)
__attribute__ ((format (printf, 1, 2))) __cold;
+
+static inline void mprintk_init(struct mprintk *mp, char *buf, size_t size)
+{
+ *mp = (struct mprintk)MPRINTK_INITIALIZER(buf, size);
+}
+extern void mprintk_init_alloc(struct mprintk *mp, gfp_t gfp);
+extern void mprintk_free(struct mprintk *mp);
+extern int vmprintk(struct mprintk *mp, const char *fmt, va_list args)
+ __attribute__ ((format (printf, 2, 0)));
+extern int vmprintk_set_header(struct mprintk *mp, const char *fmt, va_list
args)
+ __attribute__ ((format (printf, 2, 0)));
+extern int vmprintk_flush(struct mprintk *mp, const char *fmt, va_list args)
+ __attribute__ ((format (printf, 2, 0)));
+extern int mprintk(struct mprintk *mp, const char *fmt, ...)
+ __attribute__ ((format (printf, 2, 3)));
+extern int
Re: Subject: [PATCH 1/3] Let scsi_cmnd-cmnd use request-cmd buffer
On Tue, Feb 12 2008 at 21:41 +0200, James Bottomley [EMAIL PROTECTED] wrote: On Sun, 2008-02-10 at 21:05 +0200, Boaz Harrosh wrote: - struct scsi_cmnd had a 16 bytes command buffer of its own. This is an unnecessary duplication and copy of request's cmd. It is probably left overs from the time that scsi_cmnd could function without a request attached. So clean that up. - Once above is done, few places, apart from scsi-ml, needed adjustments due to changing the data type of scsi_cmnd-cmnd. - Lots of drivers still use MAX_COMMAND_SIZE. So I have left that #define but equate it to BLK_MAX_CDB. The way I see it and is reflected in the patch below is. MAX_COMMAND_SIZE - means: The longest fixed-length (*) SCSI CDB as per the SCSI standard and is not related to the implementation. BLK_MAX_CDB. - The allocated space at the request level (*)fixed-length here means commands that their size can be determined by their opcode and the CDB does not carry a length specifier, like the VARIABLE_LENGTH_CMD(0x7f) command. This is actually not exactly true and the SCSI standard also defines extended commands and vendor specific commands that can be bigger than 16 bytes. The kernel will support these using the same infrastructure used for VARLEN CDB's. So in effect MAX_COMMAND_SIZE means the maximum size command scsi-ml supports without specifying a cmd_len by ULD's When we do this, what happens to the minority of drivers that need the command in DMAable memory ... or have you audited them all and we can now dump the DMA pool allocation for SCSI commands? James Am I right in assuming that I only need to audited the drivers that have .unchecked_isa_dma set? I will redo this audit again, and report back. Boaz - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libata-dev #upstream-fixes] pata_legacy: don't call ata_host_detach() after initialization failure
* Tejun Heo [EMAIL PROTECTED] wrote: ata_host_detach() detaches an attached port and shouldn't be called on a port which hasn't been attached yet. pata_legacy incorrectly calls ata_host_detach() on unattached port after initialization failure causing oops. Fix it. thanks, i'll try this! Ingo - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pci_get_device_reverse(), why does Calgary need this?
On Tue, Feb 12, 2008 at 04:16:38PM -0800, Greg KH wrote: Why does the calgary driver need this? Can we just use pci_get_device() instead? Why do you need to walk the device list backwards? Do you get false positives going forward? It's not strictly needed, we used it for symmetry. Feel free to nuke it and walk the list forward. Cheers, Muli - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
On Tue, Feb 12, 2008 at 01:30:03PM +0100, Gabriel Paubert wrote: On Tue, Feb 12, 2008 at 12:49:05PM +0100, Gabriel Paubert wrote: On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote: On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote: - couple of fixes and preparatory patches - rework of PowerMac media-bay support ([un]register IDE devices instead of [un]registering IDE interface) [ it is the main reason for spamming PPC ML ] Interesting... I was thinking about doing a full remove of the device at a higher level instead but I suppose what you propose is easier. Well, I have serious problem on a Pegasos which appeared some time between 2.6.24 and 2.6.25-rc1: at boot I get an infinite string of hdb: empty DMA table? I'm trying to bisect it right now. Argh, the first bisect point ended up with timeouts on hdb... Flagged as bad, to try to see when the problems started, but I suspect that there are several. Well, it's worse than this. After 7 or 8 bisections (all flagged bad) the symptoms changed: the system boots up to the point where it does not recognize LVM volumes. So there are at least 3 bugs: 1) the timeout on interrupts (only seen on hdb) 2) the empty DMA table messages (seen on hda and hdb) 3) the inability to see logical volumes (pvs does not find them, they are back when rebooting into 2.6.24). This is the apparently the earliest introduced bug (no problems with the disks with that version). I am away from that machine until next Tuesday. IIRC the last git bisect was something like 160 revisions left. Gabriel Gabriel ___ Linuxppc-dev mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-dev - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
--- On Tue, 2/12/08, James Bottomley [EMAIL PROTECTED] wrote: I apologize for taking so long to review this patch. I obviously agree wholeheartedly with Luben. The problem I ran into while trying to design an enclosure management interface for the SATA devices is that there is all this vendor defined stuff. For example, for the AHCI LED protocol, the only defined LED is 'activity'. For LED2 and LED3 it is up to hardware vendors to define these. For SGPIO there's all kinds of ways for hw vendors to customize. I felt that it was going to be a maintainance nightmare to have to keep track of various vendors enclosure implementations in the ahci driver, and that it'd be better to just have user space libraries take care of that. Plus, that way a vendor doesn't have to get a patch into the kernel to get their new spiffy wizzy bang blinky lights working (think of how long it takes something to even get into a vendor kernel, which is what these guys care about...). So I'm still not sold on having an enclosure abstraction in the kernel - at least for the SATA controllers. Correct me if I'm wrong, but didn't the original AHCI enclosure patch expose activity LEDs via sysfs? I'm not saying there aren't a lot of non standard pieces that need to be activated by direct commands or other user activated protocol. I am saying there are a lot of standard pieces that we could do with showing in a uniform manner. Which is already the case without the SES kernel bloat. Case in point, the excellent user-space application lsscsi would clearly show which device is SES. And the excellent user-space application sg_ses could control an SES device. The pieces I think are absolutely standard are 1. Actual enclosure presence (is this device in an enclosure) lsscsi 2. Activity LED, this seems to be a feature of every enclosure. So that means that it needs a kernel representation? If this indeed were the case, for every feature of every type of device (not only SCSI) then the kernel itself would be insurmountably big. I also think the following are reasonably standard (based on the fact that most enclosure standards recommend but don't require this): 3. Locate LED (for locating the device). Even if you only have an activity LED, this is usually done by flashing the activity LED in a well defined pattern. 4. Fault. this is the least standardised of the lot, but does seem to be present in about every enclosure implementation. All I've done is standardise these four pieces ... the services actually take into account that it might not be possible to do certain of these (like fault). And none of this means that it needs a kernel representation. 1. You're not standardizing any known, in-practice, kernel representation, that is already in practice and thusly needs a kernel representation. 2. The kernel itself is not using nor needing this representation in order to function properly (the kernel). Leaving control of SES devices to user-space makes both the kernel and the vendors happy. All the kernel needs to do is expose the SES device to user-space as it currently does. It makes it so much easier both to vendors and to the kernel to stay out of unnecessary representations. Vendors may choose to distribute their own applications to control their hardware, as long as the kernel exposes an SES device and provides functionality, as opposed to policy of any kind. Luben - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
sil3114 corruptions (was: Re: [PATCH 3/3] faster workaround)
Hello Tejun, On Tuesday 23 October 2007 10:08:01 you wrote: Jeff Garzik wrote: Alan Cox wrote: 2) Once we identified, over time, the set of drives affected by this 3112 quirk (aka drives that didn't fully comply to SATA spec), the debugging of corruption cases largely shifted to the standard routine: update the BIOS, replace the cables/RAM/power/mainboard/slot/etc. to be certain of problem location. Except for the continued series of later SI + Nvidia chipset (mostly) pattern which seems unanswered but also being later chips I assume unrelated to this problem. The SIL_FLAG_MOD15WRITE flag is set in sil_port_info[] is set according to the best info we have from SiI, which indicates that 3114 and 3512 do not have the same problem as the 3112. I don't think this data corruption problem w/ sil3114 is related to m15w. m15w workaround slows down things quite a bit and is likely to hide problems on PCI bus side. There are reports of data corruption with 3114 on nvidia (most common), via and now amd chipsets. There's one on intel too but IIRC wasn't too definite. According to a user, freebsd didn't have data corruption problem on the same hardware. I copied PCI FIFO setup code (ours is broken BTW) but it didn't fix the problem. I'll try to reproduce the problem locally and hunt it down. the problem just came up here again, as you and Jeff already guessed also with the the workaround patches. I guess you didn't find time to look into it yet? Is there anything I can do? What would you have done after reproducing it? Thanks, Bernd -- Bernd Schubert Q-Leap Networks GmbH - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sil3114 corruptions (was: Re: [PATCH 3/3] faster workaround)
Bernd Schubert wrote: Hello Tejun, On Tuesday 23 October 2007 10:08:01 you wrote: Jeff Garzik wrote: Alan Cox wrote: 2) Once we identified, over time, the set of drives affected by this 3112 quirk (aka drives that didn't fully comply to SATA spec), the debugging of corruption cases largely shifted to the standard routine: update the BIOS, replace the cables/RAM/power/mainboard/slot/etc. to be certain of problem location. Except for the continued series of later SI + Nvidia chipset (mostly) pattern which seems unanswered but also being later chips I assume unrelated to this problem. The SIL_FLAG_MOD15WRITE flag is set in sil_port_info[] is set according to the best info we have from SiI, which indicates that 3114 and 3512 do not have the same problem as the 3112. I don't think this data corruption problem w/ sil3114 is related to m15w. m15w workaround slows down things quite a bit and is likely to hide problems on PCI bus side. There are reports of data corruption with 3114 on nvidia (most common), via and now amd chipsets. There's one on intel too but IIRC wasn't too definite. According to a user, freebsd didn't have data corruption problem on the same hardware. I copied PCI FIFO setup code (ours is broken BTW) but it didn't fix the problem. I'll try to reproduce the problem locally and hunt it down. the problem just came up here again, as you and Jeff already guessed also with the the workaround patches. I guess you didn't find time to look into it yet? Is there anything I can do? What would you have done after reproducing it? Jeff, any progress on testing? -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
--- On Tue, 2/12/08, James Bottomley [EMAIL PROTECTED] wrote: I understand what you are trying to do - I guess I just doubt the value you've added by doing this. I think that there's going to be so much customization that system vendors will want to add, that they are going to wind up adding a custom library regardless, so standardising those few things won't buy us anything. It depends ... if you actually have a use for the customisations, yes. If you just want the basics of who (what's in the enclousure), what (activity) and where (locate) then I think it solves your problem almost entirely. If the kernel doesn't solve it entirely, then it is better off without the kernel bloat. In fact vendors would distribute their own user-space application(s) to provide a consistent and complete solution(s) of their product(s) to their customer(s). This could also be achieved via sg_ses, which can also control custom vendor pages if the encodings are known by the customer (which they would be if they purchased the product). So, entirely as a straw horse, tell me what else your enclosures provide that I haven't listed in the four points. You shouldn't insist on this. It should already be clear to you this direction isn't the vendor's preference. The SES standards too provide a huge range of things that no-one ever seems to implement (temperature, power, fan speeds etc). Vendors do use temperature, power and fan speeds and in fact more features, some of them completely custom for their product, since they end up writing the SES device server of the enclosure themselves (for their product). This kind of control and representation is better left to user-space. The kernel neither needs to represent it nor know about it, since it is itself not using nor controlling it. I think the users of enclosures fall int these categories This statement (above) really means that the numbers below are but merely the speculation of one person. 85% just want to know where their device actually is (i.e. that sdc is in enclosure slot 5) 50% like watching the activity lights 30% want to be able to have a visual locate function 20% want a visual failure indication (the other 80% rely on some OS notification instead) When you add up the overlapping needs, you get about 90% of people happy with the basics that the enclosure services provide. 90% doesn't make it a necessary requirement for the kernel to have this, as well as the fact that the kernel is neither needing this to function properly, nor using it. Could there be more ... sure; should there be more ... I don't think so ... that's what value add the user libraries can provide. should there be more ... I don't think so This decision isn't yours to make. In fact such a decision is never made by one person only. This decision is made by 1) the industry, 2) the customers and 3) vendors by the pricing of their product(s). Luben - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PCI subsystem: AMD SATA IDE mode quirk
Cai, Crane wrote:
Hi Jeff,
Sorry to diturb you. However, it is a long time for me to submit this patch. Can you tell me when this patch can be upsteamed to the kernel tree?
Thanks,
Crane
-Original Message-
From: Jeff Garzik [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 02, 2008 2:20 PM
To: Cai, Crane
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Linux IDE mailing
list
Subject: Re: [PATCH] PCI subsystem: AMD SATA IDE mode quirk
Cai, Crane wrote:
From: Crane Cai [EMAIL PROTECTED]
PCI: modify SATA IDE mode quirk
When initialize and resume, SB600/700/800 need to set SATA mode
correctly.
Signed-off-by: Crane Cai [EMAIL PROTECTED]
--- a/drivers/pci/quirks.c 2007-09-24 14:16:32.0 -0400
+++ b/drivers/pci/quirks.c 2008-02-02 11:23:47.0 -0500
@@ -859,12 +859,13 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IN
DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82454NX,quirk_disable_pxb );
-static void __devinit quirk_sb600_sata(struct pci_dev *pdev)
+static void __devinit quirk_amd_ide_mode(struct pci_dev *pdev)
{
- /* set sb600 sata to ahci mode */
- 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) {
pci_read_config_byte(pdev, 0x40, tmp);
pci_write_config_byte(pdev, 0x40, tmp|1);
pci_write_config_byte(pdev, 0x9, 1); @@ -872,10 +873,13 @@ static
void __devinit quirk_sb600_sata(s
pci_write_config_byte(pdev, 0x40, tmp);
pdev-class = PCI_CLASS_STORAGE_SATA_AHCI;
+ printk(KERN_INFO PCI: set SATA to AHCI mode\n);
}
}
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_sb600_sata);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP700_SATA, quirk_sb600_sata);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_amd_ide_mode);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_amd_ide_mode);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP700_SATA, quirk_amd_ide_mode);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP700_SATA, quirk_amd_ide_mode);
ACK
In the future, please also CC linux-ide@vger.kernel.org, as that's where the
ATA folks hang out :)
Greg Kroah-Hartman (cc'd) needs to pick up your patch, since it is in
the PCI side of the house...
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ide=reverse do we still need this?
On 13-02-08 05:44, Greg KH wrote: While details escape me somewhat again at the monment, a few months ago I was playing around with a PCI Promise IDE controller and needed ide=reverse to save me from having to switch disks around to still have a bootable system. Or some such. Not too clear anymore, but I remember it saved the day. You couldn't just change the boot disk in grub? Or use an initramfs and /dev/disk/by-id/ to keep any future moves stable? No. The thing is that you need these kinds of hacks while messing with old systems, building and stripping them, often in recovery type of situations. As said (same as the other person I saw reacting) details of what was most decidedly needed last time around escape me at the moment, but ide=reverse is the kind of hack that saves one hours of unscrewing computer cases and switching disks around while building stuff, making quick tests, doing recovery... If it must go for the greater architectural good, so be it, but it's the type of thing that's used specifically in the situations where you don't have stable, well arranged (or known!) setups to begin with. Rene. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ide=reverse do we still need this?
On Wed, 2008-02-13 at 13:06 +0100, Rene Herman wrote: On 13-02-08 05:44, Greg KH wrote: While details escape me somewhat again at the monment, a few months ago I was playing around with a PCI Promise IDE controller and needed ide=reverse to save me from having to switch disks around to still have a bootable system. Or some such. Not too clear anymore, but I remember it saved the day. You couldn't just change the boot disk in grub? Or use an initramfs and /dev/disk/by-id/ to keep any future moves stable? No. The thing is that you need these kinds of hacks while messing with old systems, building and stripping them, often in recovery type of situations. As said (same as the other person I saw reacting) details of what was most decidedly needed last time around escape me at the moment, but ide=reverse is the kind of hack that saves one hours of unscrewing computer cases and switching disks around while building stuff, making quick tests, doing recovery... If it must go for the greater architectural good, so be it, but it's the type of thing that's used specifically in the situations where you don't have stable, well arranged (or known!) setups to begin with. I might be off the deep end, but isn't this what Documentation/feature-removal-schedule.txt is for? cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part
Re: [PATCH 09/18] ide: rework PowerMac media-bay support
Hi, On Wednesday 13 February 2008, Michael Ellerman wrote: On Fri, 2008-02-08 at 01:45 +0100, Bartlomiej Zolnierkiewicz wrote: Rework PowerMac media-bay support in such way that instead of un/registering the IDE interface we un/register IDE devices: * Add ide_port_scan() helper for probing+registerering devices on a port. * Rename ide_port_unregister_devices() to __ide_port_unregister_devices(). * Add ide_port_unregister_devices() helper for unregistering devices on a port. * Add 'ide_hwif_t *cd_port' to 'struct media_bay_info', pass 'hwif' instead of hwif-index to media_bay_set_ide_infos() and use it to setup 'cd_port'. * Use ide_port_unregister_devices() instead of ide_unregister() and ide_port_scan() instead of ide_register_hw() in media_bay_step(). * Unexport ide_register_hw() and make it static. Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] --- drivers/ide/ide-probe.c| 18 ++ drivers/ide/ide.c | 22 -- drivers/ide/ppc/pmac.c |3 ++- drivers/macintosh/mediabay.c | 17 +++-- include/asm-powerpc/mediabay.h |4 +++- include/linux/ide.h|6 ++ 6 files changed, 48 insertions(+), 22 deletions(-) Index: b/include/asm-powerpc/mediabay.h === --- a/include/asm-powerpc/mediabay.h +++ b/include/asm-powerpc/mediabay.h @@ -22,10 +22,12 @@ int check_media_bay(struct device_node * /* Number of bays in the machine or 0 */ extern int media_bay_count; +#ifdef CONFIG_BLK_DEV_IDE_PMAC Does adding: #include linux/ide.h after ifdef help? int check_media_bay_by_base(unsigned long base, int what); /* called by IDE PMAC host driver to register IDE controller for media bay */ int media_bay_set_ide_infos(struct device_node *which_bay, unsigned long base, - int irq, int index); + int irq, ide_hwif_t *hwif); +#endif #endif /* __KERNEL__ */ #endif /* _PPC_MEDIABAY_H */ This hunk breaks pmac32_defconfig for me. include2/asm/mediabay.h:29: error: syntax error before 'ide_hwif_t' make[3]: *** [arch/powerpc/platforms/powermac/setup.o] Error 1 make[2]: *** [arch/powerpc/platforms/powermac] Error 2 make[1]: *** [arch/powerpc/platforms] Error 2 make: *** [sub-make] Error 2 cheers - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pci_get_device_reverse(), why does Calgary need this?
On Wednesday 13 February 2008, Greg KH wrote: On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox wrote: Why does the calgary driver need this? Can we just use pci_get_device() instead? Why do you need to walk the device list backwards? Do you get false positives going forward? It doesn't look to be performance critical so the driver can pci_get_device until the end and use the final hit anyway. That would make more sense. IDE reverse is more problematic but nobody seems to use it. I've seen two posters say they use it. I'm wondering what it is really solving if they use it, and why if it's really needed, scsi never had to implement such a hack... It is no longer solving anything, just adds more pain. ;) [ The option comes from 2.2.x (so long before LABEL=/ and /dev/disk/by-id/ became popular). Some off-board controllers integrated on motherboards used to appear before on-board IDE on PCI bus so this option was meant to preserve the legacy ordering. ] Since it is valid only when Probe IDE PCI devices in the PCI bus order (DEPRECATED) config option is used it is already on its way out (though marking it as obsoleted would make it more explicit). I think that removing ide=reverse in 2.6.26 would be OK... Thanks, Bart - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-mm1 and 2.6.24-git13 kernel panic's while bootup at ide_device_add_all
On Tuesday, 5 of February 2008, Kamalesh Babulal wrote:
Hi,
The kernel bootup panics with the 2.6.24-mm1 and 2.6.24-git13 kernel
while defconfig compiled in for x86_64 (Intel(R) Xeon) box
Is that still happening or has it been fixed?
Rafael
BUG: unable to handle kernel paging request at ffb0
IP: [80413642] init_irq+0x188/0x444
PGD 203067 PUD 204067 PMD 0
Oops: [1] SMP
CPU 2
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.24 #1
RIP: 0010:[80413642] [80413642] init_irq+0x188/0x444
RSP: 0018:81022f093e00 EFLAGS: 00010287
RAX: ff90 RBX: 808a9100 RCX:
RDX: RSI: 81022fc039c0 RDI: 8074dd00
RBP: 81022f093e30 R08: 808af880 R09: 0002
R10: 0001 R11: 810bed60 R12: 808b0400
R13: 808b0410 R14: R15:
FS: () GS:81022f0883c0() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: ffb0 CR3: 00201000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process swapper (pid: 1, threadinfo 81022f092000, task 81022f0797d0)
Stack: 81022f093e30 808a9100 808a9120
ffed 81022f093eb0 80414425
81022f093ec0 8074e920 0246
Call Trace:
[80414425] ide_device_add_all+0xb27/0xe1b
[807d2884] ide_generic_init+0x3a/0x3e
[807b473b] kernel_init+0x175/0x2e7
[8020bff8] child_rip+0xa/0x12
[80372350] ? acpi_ds_init_one_object+0x0/0x88
[807b45c6] ? kernel_init+0x0/0x2e7
[8020bfee] ? child_rip+0x0/0x12
Code: 89 03 49 8b 45 18 48 89 18 48 39 1b 75 04 0f 0b eb fe fe 05 51 51 38 00
fb eb 5b 48 8b 83 28 07 00 00 83 ca ff 48 83 e8 70 74 0e 48 8b 40 20 48 8b
80 88 00 00 00 8b 50 04 48 8b 3d 79 ff 2f 00
RIP [80413642] init_irq+0x188/0x444
RSP 81022f093e00
CR2: ffb0
---[ end trace 9010a4c8c4ba608a ]---
(gdb) p init_irq
$1 = {int (ide_hwif_t *)} 0x804134ba init_irq
(gdb) p/x 0x804134ba+0x188
$2 = 0x80413642
(gdb) l *0x80413642
0x80413642 is in init_irq (include/linux/ide.h:1311).
1306print_hex_dump(KERN_INFO, , DUMP_PREFIX_NONE, 16, 2, id,
512, 0);
1307}
1308
1309static inline int hwif_to_node(ide_hwif_t *hwif)
1310{
1311struct pci_dev *dev = to_pci_dev(hwif-dev);
1312return dev ? pcibus_to_node(dev-bus) : -1;
1313}
1314
1315static inline ide_drive_t *ide_get_paired_drive(ide_drive_t *drive)
(gdb)
(gdb) p ide_device_add_all
$1 = {int (u8 *, const struct ide_port_info *)} 0x804138fe
ide_device_add_all
(gdb) p/x 0x804138fe
$2 = 0x804138fe
(gdb) l *0x804138fe
0x804138fe is in ide_device_add_all (drivers/ide/ide-probe.c:1372).
1367hwif-cbl = hwif-cable_detect(hwif);
1368}
1369}
1370
1371int ide_device_add_all(u8 *idx, const struct ide_port_info *d)
1372{
1373ide_hwif_t *hwif, *mate = NULL;
1374int i, rc = 0;
1375
1376for (i = 0; i MAX_HWIFS; i++) {
(gdb)
--
Premature optimization is the root of all evil. - Donald Knuth
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ide=reverse do we still need this?
On 13-02-08 13:16, Michael Ellerman wrote: On Wed, 2008-02-13 at 13:06 +0100, Rene Herman wrote: On 13-02-08 05:44, Greg KH wrote: While details escape me somewhat again at the monment, a few months ago I was playing around with a PCI Promise IDE controller and needed ide=reverse to save me from having to switch disks around to still have a bootable system. Or some such. Not too clear anymore, but I remember it saved the day. You couldn't just change the boot disk in grub? Or use an initramfs and /dev/disk/by-id/ to keep any future moves stable? No. The thing is that you need these kinds of hacks while messing with old systems, building and stripping them, often in recovery type of situations. As said (same as the other person I saw reacting) details of what was most decidedly needed last time around escape me at the moment, but ide=reverse is the kind of hack that saves one hours of unscrewing computer cases and switching disks around while building stuff, making quick tests, doing recovery... If it must go for the greater architectural good, so be it, but it's the type of thing that's used specifically in the situations where you don't have stable, well arranged (or known!) setups to begin with. I might be off the deep end, but isn't this what Documentation/feature-removal-schedule.txt is for? Documentation/feature-removal-schedule.txt is for asking/discussing whether or not features should be removed? No, I don't think so. It seems to be a schedule of when to remove features. Rene. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ide=reverse do we still need this?
On 13-02-08 13:06, Rene Herman wrote: On 13-02-08 05:44, Greg KH wrote: While details escape me somewhat again at the monment, a few months ago I was playing around with a PCI Promise IDE controller and needed ide=reverse to save me from having to switch disks around to still have a bootable system. Or some such. Not too clear anymore, but I remember it saved the day. You couldn't just change the boot disk in grub? Or use an initramfs and /dev/disk/by-id/ to keep any future moves stable? No. The thing is that you need these kinds of hacks while messing with old systems, building and stripping them, often in recovery type of situations. As said (same as the other person I saw reacting) details of what was most decidedly needed last time around escape me at the moment, but ide=reverse is the kind of hack that saves one hours of unscrewing computer cases and switching disks around while building stuff, making quick tests, doing recovery... If it must go for the greater architectural good, so be it, but it's the type of thing that's used specifically in the situations where you don't have stable, well arranged (or known!) setups to begin with. Allow me to add that the demise of drivers/ide itself is an argument for just shooting the thing if it helps clean up the API. Next year when I'm messing with that Promise controller again, the machine might very well be running a kernel using PATA instead of IDE anyway... Rene. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ide-floppy: use rq-cmd for preparing and sending packet cmds to the drive
On Tue, Feb 12, 2008 at 10:39:22PM +0100, Bartlomiej Zolnierkiewicz wrote:
Hi Bart,
I think that this _really_ should be done _after_ unifying ATAPI handling [*].
Otherwise you will be making some of the same changes to the _three_ copies
of (more or less) identical code and more importantly we will have to delay
unification after _all_ drivers are converted to rq-cmd[] (+ lets not forget
that I'll have more changes to review ;).
(*) please take a closer look at *_issue_pc(), *_transfer_pc() and *_pc_intr()
in ide-{floppy,tape,scsi} (the useful hint is that after making these
functions free of references to device driver specific objects/functions
we can use drive-media == ide_{floppy,tape,scsi} checks for handling
not yet fully unified / media type specific code).
I started working on probably the easiest unification we could do: unify all the
pc-flags defines and move them in a header where all drivers can use them. This
raises an architectural design question: The way i see it, the generic ATAPI
handling
is going to be sort of serving functionality to the drivers using ATAPI. Do
we want
all this functionality to go to ide.{h,c} or we want specific atapi.{h,c} files
that
contain only this unified functionality, or whatever else. In general, how is
this
generic layer going to be distributed among headers/.c files and what do we
want there?
/me tends to think that special headers/files, small and easy to manage and
modular, have more advantages in this case but this is just me. After we've
decided on that, the rest of the issues will resolve by themselves/get easier to
tackle.
Thanks.
--
Regards/Gruß,
Boris.
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-mm1 and 2.6.24-git13 kernel panic's while bootup at ide_device_add_all
Rafael J. Wysocki wrote:
On Tuesday, 5 of February 2008, Kamalesh Babulal wrote:
Hi,
The kernel bootup panics with the 2.6.24-mm1 and 2.6.24-git13 kernel
while defconfig compiled in for x86_64 (Intel(R) Xeon) box
Is that still happening or has it been fixed?
Rafael
The panic is solved by the patch http://lkml.org/lkml/2008/2/11/350
but the kernel is not boot because of the panic
(http://lkml.org/lkml/2008/2/12/91)
Creating root device.
Mounting root filesystem.
mount: could not find filesystem
Kernel panic - not syncing: Attempted to kill init!
BUG: unable to handle kernel paging request at ffb0
IP: [80413642] init_irq+0x188/0x444
PGD 203067 PUD 204067 PMD 0
Oops: [1] SMP
CPU 2
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.24 #1
RIP: 0010:[80413642] [80413642] init_irq+0x188/0x444
RSP: 0018:81022f093e00 EFLAGS: 00010287
RAX: ff90 RBX: 808a9100 RCX:
RDX: RSI: 81022fc039c0 RDI: 8074dd00
RBP: 81022f093e30 R08: 808af880 R09: 0002
R10: 0001 R11: 810bed60 R12: 808b0400
R13: 808b0410 R14: R15:
FS: () GS:81022f0883c0() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: ffb0 CR3: 00201000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process swapper (pid: 1, threadinfo 81022f092000, task 81022f0797d0)
Stack: 81022f093e30 808a9100 808a9120
ffed 81022f093eb0 80414425
81022f093ec0 8074e920 0246
Call Trace:
[80414425] ide_device_add_all+0xb27/0xe1b
[807d2884] ide_generic_init+0x3a/0x3e
[807b473b] kernel_init+0x175/0x2e7
[8020bff8] child_rip+0xa/0x12
[80372350] ? acpi_ds_init_one_object+0x0/0x88
[807b45c6] ? kernel_init+0x0/0x2e7
[8020bfee] ? child_rip+0x0/0x12
Code: 89 03 49 8b 45 18 48 89 18 48 39 1b 75 04 0f 0b eb fe fe 05 51 51 38
00 fb eb 5b 48 8b 83 28 07 00 00 83 ca ff 48 83 e8 70 74 0e 48 8b 40 20 48
8b 80 88 00 00 00 8b 50 04 48 8b 3d 79 ff 2f 00
RIP [80413642] init_irq+0x188/0x444
RSP 81022f093e00
CR2: ffb0
---[ end trace 9010a4c8c4ba608a ]---
(gdb) p init_irq
$1 = {int (ide_hwif_t *)} 0x804134ba init_irq
(gdb) p/x 0x804134ba+0x188
$2 = 0x80413642
(gdb) l *0x80413642
0x80413642 is in init_irq (include/linux/ide.h:1311).
1306print_hex_dump(KERN_INFO, , DUMP_PREFIX_NONE, 16, 2, id,
512, 0);
1307}
1308
1309static inline int hwif_to_node(ide_hwif_t *hwif)
1310{
1311struct pci_dev *dev = to_pci_dev(hwif-dev);
1312return dev ? pcibus_to_node(dev-bus) : -1;
1313}
1314
1315static inline ide_drive_t *ide_get_paired_drive(ide_drive_t *drive)
(gdb)
(gdb) p ide_device_add_all
$1 = {int (u8 *, const struct ide_port_info *)} 0x804138fe
ide_device_add_all
(gdb) p/x 0x804138fe
$2 = 0x804138fe
(gdb) l *0x804138fe
0x804138fe is in ide_device_add_all (drivers/ide/ide-probe.c:1372).
1367hwif-cbl = hwif-cable_detect(hwif);
1368}
1369}
1370
1371int ide_device_add_all(u8 *idx, const struct ide_port_info *d)
1372{
1373ide_hwif_t *hwif, *mate = NULL;
1374int i, rc = 0;
1375
1376for (i = 0; i MAX_HWIFS; i++) {
(gdb)
--
Thanks Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ide-floppy: use rq-cmd for preparing and sending packet cmds to the drive
Hi,
On Wednesday 13 February 2008, Borislav Petkov wrote:
On Tue, Feb 12, 2008 at 10:39:22PM +0100, Bartlomiej Zolnierkiewicz wrote:
Hi Bart,
I think that this _really_ should be done _after_ unifying ATAPI handling
[*].
Otherwise you will be making some of the same changes to the _three_ copies
of (more or less) identical code and more importantly we will have to delay
unification after _all_ drivers are converted to rq-cmd[] (+ lets not
forget
that I'll have more changes to review ;).
(*) please take a closer look at *_issue_pc(), *_transfer_pc() and
*_pc_intr()
in ide-{floppy,tape,scsi} (the useful hint is that after making these
functions free of references to device driver specific objects/functions
we can use drive-media == ide_{floppy,tape,scsi} checks for handling
not yet fully unified / media type specific code).
I started working on probably the easiest unification we could do: unify all
the
pc-flags defines and move them in a header where all drivers can use them.
This
Yep.
raises an architectural design question: The way i see it, the generic ATAPI
handling
is going to be sort of serving functionality to the drivers using ATAPI. Do
we want
all this functionality to go to ide.{h,c} or we want specific atapi.{h,c}
files that
contain only this unified functionality, or whatever else. In general, how is
this
generic layer going to be distributed among headers/.c files and what do we
want there?
/me tends to think that special headers/files, small and easy to manage and
modular, have more advantages in this case but this is just me. After we've
decided on that, the rest of the issues will resolve by themselves/get easier
to
tackle.
I think that:
drivers/ide/ide-atapi.c
include/linux/ide.h
should be fine for now...
Moving code around is trivial so we can always fixup before pushing upstream.
Thanks,
Bart
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
The keep-it-in-user-space arguments seem fairly compelling to me. Especially as we've pushed whole i/o subsystems out to user space (iscsi, stgt, talked about fcoe, a lot of dm control, etc). The functionality seems to align with Doug's sg/lsscsi utility chain as well. Granted, the new utility would have to be designed in such as way that it can incorporate vendor hardware handlers. But, if James has a somewhat common implementation already for a kernel implementation, I'm sure that can be the starting point for lsscsi. So, the main question I believe is being asked is: - Do we need to represent this via the object/sysfs tree or can an outside utility be depended upon to show it ? Note that I am not supporting: Vendors may choose to distribute their own applications. For this to become truly useful, there needs to be a common tool/method that presents common features in a common manner, regardless of whether it is in kernel or not. -- james s Luben Tuikov wrote: Which is already the case without the SES kernel bloat. Case in point, the excellent user-space application lsscsi would clearly show which device is SES. And the excellent user-space application sg_ses could control an SES device. The pieces I think are absolutely standard are 1. Actual enclosure presence (is this device in an enclosure) lsscsi 2. Activity LED, this seems to be a feature of every enclosure. So that means that it needs a kernel representation? If this indeed were the case, for every feature of every type of device (not only SCSI) then the kernel itself would be insurmountably big. I also think the following are reasonably standard (based on the fact that most enclosure standards recommend but don't require this): 3. Locate LED (for locating the device). Even if you only have an activity LED, this is usually done by flashing the activity LED in a well defined pattern. 4. Fault. this is the least standardised of the lot, but does seem to be present in about every enclosure implementation. All I've done is standardise these four pieces ... the services actually take into account that it might not be possible to do certain of these (like fault). And none of this means that it needs a kernel representation. 1. You're not standardizing any known, in-practice, kernel representation, that is already in practice and thusly needs a kernel representation. 2. The kernel itself is not using nor needing this representation in order to function properly (the kernel). Leaving control of SES devices to user-space makes both the kernel and the vendors happy. All the kernel needs to do is expose the SES device to user-space as it currently does. It makes it so much easier both to vendors and to the kernel to stay out of unnecessary representations. Vendors may choose to distribute their own applications to control their hardware, as long as the kernel exposes an SES device and provides functionality, as opposed to policy of any kind. Luben - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
James Bottomley wrote: I don't disagree with that, but the fact is that there isn't such a tool. It's also a fact that the enterprise is reasonably unhappy with the lack of an enclosure management infrastructure, since it's something they got on all the other unix systems. I don't disagree. I think a minimal infrastructure in-kernel does just about everything the enterprise wants ... and since it's stateless, they can always use direct connect tools in addition. However, I'm happy to be proven wrong ... anyone on this thread is welcome to come up with a userland enclosure infrastructure. Once it does everything the in-kernel one does (which is really about the minimal possible set), I'll be glad to erase the in-kernel one. yeah, but... putting something new in, only to pull it later, is a bad paradigm for adding new mgmt interfaces. Believe me, I've felt users pain in the reverse flow : driver-specific stuff that then has to migrate to upstream interfaces, complicated by different pull points by different distros. You can migrate a management interface, but can you really remove/pull one out ? Isn't it better to let the lack of an interface give motivation to create the right interface, once the right way is determined - which is what I thought we were discussing ?or is this simply that there is no motivation until something exists, that people don't like, thus they become motivated ? -- james s - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ide=reverse do we still need this?
On Tue, Feb 12, 2008 at 08:43:04PM -0800, Greg KH wrote: Can't you just boot with /dev/disk/by-id/ and an initramfs to not have to worry about such a thing in the future? Can comebody remind me what the initramfs is for in that situation, please ? From the little I've noticed, I thought the /dev/disk/by-id part went into fstab ? At the moment, I just build the things I think I need in to the kernel on that box, without modules. Anyway, I'll try to find time to read my notes to see if I can identify what happened/when, and to take the box down again so I can try to confirm exactly what the problem is, if it still exists. I certainly won't be taking it down until I've written my weekly backups to tape at the weekend, so maybe not before next week. Have you tried the PATA drivers instead of IDE to see if this solves the moves around issue? If they work, then you would not need the command line option at all. My previous kernel was 2.18-series, I think at that time they were still under development. This box handles the backups for my various desktop boxes, which is why I'm very conservative about changing it. I guess the drivers are stable now, I'll maybe give that a go (depending on time). Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
On Wed, 2008-02-13 at 09:08 -0500, James Smart wrote: The keep-it-in-user-space arguments seem fairly compelling to me. Especially as we've pushed whole i/o subsystems out to user space (iscsi, stgt, talked about fcoe, a lot of dm control, etc). And to me too. The functionality seems to align with Doug's sg/lsscsi utility chain as well. Granted, the new utility would have to be designed in such as way that it can incorporate vendor hardware handlers. But, if James has a somewhat common implementation already for a kernel implementation, I'm sure that can be the starting point for lsscsi. So, the main question I believe is being asked is: - Do we need to represent this via the object/sysfs tree or can an outside utility be depended upon to show it ? Note that I am not supporting: Vendors may choose to distribute their own applications. For this to become truly useful, there needs to be a common tool/method that presents common features in a common manner, regardless of whether it is in kernel or not. I don't disagree with that, but the fact is that there isn't such a tool. It's also a fact that the enterprise is reasonably unhappy with the lack of an enclosure management infrastructure, since it's something they got on all the other unix systems. I think a minimal infrastructure in-kernel does just about everything the enterprise wants ... and since it's stateless, they can always use direct connect tools in addition. However, I'm happy to be proven wrong ... anyone on this thread is welcome to come up with a userland enclosure infrastructure. Once it does everything the in-kernel one does (which is really about the minimal possible set), I'll be glad to erase the in-kernel one. James - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
James Bottomley wrote: ... I wouldn't have bothered except that I could see ad-hoc in-kernel sysfs solutions beginning to appear. If this is true, and if no one quickly volunteers to do the utility, then I agree with what you are doing. -- james s - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
On Wed, 2008-02-13 at 11:22 -0500, James Smart wrote: James Bottomley wrote: I don't disagree with that, but the fact is that there isn't such a tool. It's also a fact that the enterprise is reasonably unhappy with the lack of an enclosure management infrastructure, since it's something they got on all the other unix systems. I don't disagree. I think a minimal infrastructure in-kernel does just about everything the enterprise wants ... and since it's stateless, they can always use direct connect tools in addition. However, I'm happy to be proven wrong ... anyone on this thread is welcome to come up with a userland enclosure infrastructure. Once it does everything the in-kernel one does (which is really about the minimal possible set), I'll be glad to erase the in-kernel one. yeah, but... putting something new in, only to pull it later, is a bad paradigm for adding new mgmt interfaces. Believe me, I've felt users pain in the reverse flow : driver-specific stuff that then has to migrate to upstream interfaces, complicated by different pull points by different distros. You can migrate a management interface, but can you really remove/pull one out ? That depends on the result. I agree that migration will be a pain, so I suppose I set the bar a bit low; the user tool needs to be a bit more compelling; plus I'll manage the interface transition ... if there is one; there's no such tool yet. Isn't it better to let the lack of an interface give motivation to create the right interface, once the right way is determined - which is what I thought we were discussing ?or is this simply that there is no motivation until something exists, that people don't like, thus they become motivated ? Well ... I did learn the latter from Andrew, so I thought I'd try it. It's certainly true that the enclosure problem has been an issue for over a decade, so there doesn't seem to be anything motivating anyone to solve it. I wouldn't have bothered except that I could see ad-hoc in-kernel sysfs solutions beginning to appear. At least this way they can all present a unified interface. James - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH #upstream] libata: implement libata.force module parameter
Tejun Heo wrote: This patch implements libata.force module parameter which can selectively override ATA port, link and device configurations including cable type, SATA PHY SPD limit, transfer mode and NCQ. ... + 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 .. Mmm.. not a NAK, but is there also a way to set/change these on the fly? I ask because, on my 4-core test system here, libata enumerates the ports differently depending upon whether I boot with a 32-bit kernel or a 64-bit kernel. Major PITA, that, and it's just the kind of thing that spoils fixed PORT:DEVICE module parameters, too. Now mind you, it's more likely the PCI layer that does the reverse order thing, but the end result is that my drives/ports are numbered differently depending upon which kernel I happen to boot with. ?? - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ide-scsi: do non-atomic pc-flags testing
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
drivers/scsi/ide-scsi.c | 27 ++-
1 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/ide-scsi.c b/drivers/scsi/ide-scsi.c
index d46c81c..93c3fc2 100644
--- a/drivers/scsi/ide-scsi.c
+++ b/drivers/scsi/ide-scsi.c
@@ -311,10 +311,10 @@ static int idescsi_end_request (ide_drive_t *drive, int
uptodate, int nrsecs)
pc = opc;
rq = pc-rq;
pc-scsi_cmd-result = (CHECK_CONDITION 1) |
- ((test_bit(PC_FLAG_TIMEDOUT, pc-flags) ?
+ (((pc-flags PC_FLAG_TIMEDOUT) ?
DID_TIME_OUT :
DID_OK) 16);
- } else if (test_bit(PC_FLAG_TIMEDOUT, pc-flags)) {
+ } else if (pc-flags PC_FLAG_TIMEDOUT) {
if (log)
printk (KERN_WARNING ide-scsi: %s: timed out for
%lu\n,
drive-name,
pc-scsi_cmd-serial_number);
@@ -356,7 +356,7 @@ static int idescsi_expiry(ide_drive_t *drive)
#if IDESCSI_DEBUG_LOG
printk(KERN_WARNING idescsi_expiry called for %lu at %lu\n,
pc-scsi_cmd-serial_number, jiffies);
#endif
- set_bit(PC_FLAG_TIMEDOUT, pc-flags);
+ pc-flags |= PC_FLAG_TIMEDOUT;
return 0; /* we do not want the
ide subsystem to retry */
}
@@ -378,7 +378,7 @@ static ide_startstop_t idescsi_pc_intr (ide_drive_t *drive)
printk (KERN_INFO ide-scsi: Reached idescsi_pc_intr interrupt
handler\n);
#endif /* IDESCSI_DEBUG_LOG */
- if (test_bit(PC_FLAG_TIMEDOUT, pc-flags)) {
+ if (pc-flags PC_FLAG_TIMEDOUT) {
#if IDESCSI_DEBUG_LOG
printk(KERN_WARNING idescsi_pc_intr: got timed out packet %lu
at %lu\n,
pc-scsi_cmd-serial_number, jiffies);
@@ -387,7 +387,8 @@ static ide_startstop_t idescsi_pc_intr (ide_drive_t *drive)
idescsi_end_request (drive, 1, 0);
return ide_stopped;
}
- if (test_and_clear_bit(PC_FLAG_DMA_IN_PROGRESS, pc-flags)) {
+ if (pc-flags PC_FLAG_DMA_IN_PROGRESS) {
+ pc-flags = ~PC_FLAG_DMA_IN_PROGRESS;
#if IDESCSI_DEBUG_LOG
printk (ide-scsi: %s: DMA complete\n, drive-name);
#endif /* IDESCSI_DEBUG_LOG */
@@ -426,7 +427,7 @@ static ide_startstop_t idescsi_pc_intr (ide_drive_t *drive)
- discarding data\n);
temp = pc-buf_size - pc-xferred;
if (temp) {
- clear_bit(PC_FLAG_WRITING, pc-flags);
+ pc-flags = ~PC_FLAG_WRITING;
if (pc-sg)
idescsi_input_buffers(drive, pc,
temp);
@@ -448,14 +449,14 @@ static ide_startstop_t idescsi_pc_intr (ide_drive_t
*drive)
}
}
if (ireason IO) {
- clear_bit(PC_FLAG_WRITING, pc-flags);
+ pc-flags = ~PC_FLAG_WRITING;
if (pc-sg)
idescsi_input_buffers(drive, pc, bcount);
else
hwif-atapi_input_bytes(drive, pc-cur_pos,
bcount);
} else {
- set_bit(PC_FLAG_WRITING, pc-flags);
+ pc-flags |= PC_FLAG_WRITING;
if (pc-sg)
idescsi_output_buffers(drive, pc, bcount);
else
@@ -495,8 +496,8 @@ static ide_startstop_t idescsi_transfer_pc(ide_drive_t
*drive)
ide_set_handler(drive, idescsi_pc_intr, get_timeout(pc),
idescsi_expiry);
/* Send the actual packet */
drive-hwif-atapi_output_bytes(drive, scsi-pc-c, 12);
- if (test_bit(PC_FLAG_DMA_OK, pc-flags)) {
- set_bit(PC_FLAG_DMA_IN_PROGRESS, pc-flags);
+ if (pc-flags PC_FLAG_DMA_OK) {
+ pc-flags |= PC_FLAG_DMA_IN_PROGRESS;
hwif-dma_start(drive);
}
return ide_started;
@@ -506,10 +507,10 @@ static inline int idescsi_set_direction(struct
ide_atapi_pc *pc)
{
switch (pc-c[0]) {
case READ_6: case READ_10: case READ_12:
- clear_bit(PC_FLAG_WRITING, pc-flags);
+ pc-flags = ~PC_FLAG_WRITING;
return 0;
case WRITE_6: case WRITE_10: case WRITE_12:
- set_bit(PC_FLAG_WRITING, pc-flags);
+ pc-flags |= PC_FLAG_WRITING;
return 0;
default:
return 1;
@@ -566,7 +567,7 @@ static ide_startstop_t idescsi_issue_pc(ide_drive_t *drive,
ide_pktcmd_tf_load(drive, IDE_TFLAG_NO_SELECT_MASK, bcount,
[PATCH 1/2] ide: use generic ATAPI packet command flags in ide-{floppy,tape,scsi}
This is done in one single patch in order not to cause git breakage.
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
drivers/ide/ide-floppy.c | 14 --
drivers/ide/ide-tape.c | 16
drivers/scsi/ide-scsi.c | 36 +++-
include/linux/ide.h | 15 +++
4 files changed, 30 insertions(+), 51 deletions(-)
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index bf1ef60..5f133df 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -78,20 +78,6 @@
*/
#define IDEFLOPPY_PC_STACK (10 + IDEFLOPPY_MAX_PC_RETRIES)
-/* Packet command flag bits. */
-enum {
- /* 1 when we prefer to use DMA if possible */
- PC_FLAG_DMA_RECOMMENDED = (1 0),
- /* 1 while DMA in progress */
- PC_FLAG_DMA_IN_PROGRESS = (1 1),
- /* 1 when encountered problem during DMA */
- PC_FLAG_DMA_ERROR = (1 2),
- /* Data direction */
- PC_FLAG_WRITING = (1 3),
- /* Suppress error reporting */
- PC_FLAG_SUPPRESS_ERROR = (1 4),
-};
-
/* format capacities descriptor codes */
#define CAPACITY_INVALID 0x00
#define CAPACITY_UNFORMATTED 0x01
diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
index 3a10208..3f9fbd8 100644
--- a/drivers/ide/ide-tape.c
+++ b/drivers/ide/ide-tape.c
@@ -181,22 +181,6 @@ struct idetape_bh {
char *b_data;
};
-/* Packet command flag bits. */
-enum {
- /* Set when an error is considered normal - We won't retry */
- PC_FLAG_ABORT = (1 0),
- /* 1 When polling for DSC on a media access command */
- PC_FLAG_WAIT_FOR_DSC= (1 1),
- /* 1 when we prefer to use DMA if possible */
- PC_FLAG_DMA_RECOMMENDED = (1 2),
- /* 1 while DMA in progress */
- PC_FLAG_DMA_IN_PROGRESS = (1 3),
- /* 1 when encountered problem during DMA */
- PC_FLAG_DMA_ERROR = (1 4),
- /* Data direction */
- PC_FLAG_WRITING = (1 5),
-};
-
/* Tape door status */
#define DOOR_UNLOCKED 0
#define DOOR_LOCKED1
diff --git a/drivers/scsi/ide-scsi.c b/drivers/scsi/ide-scsi.c
index 5ec421c..d46c81c 100644
--- a/drivers/scsi/ide-scsi.c
+++ b/drivers/scsi/ide-scsi.c
@@ -61,14 +61,6 @@
#define IDESCSI_DEBUG_LOG 0
/*
- * Packet command status bits.
- */
-#define PC_DMA_IN_PROGRESS 0 /* 1 while DMA in progress */
-#define PC_WRITING 1 /* Data direction */
-#define PC_TIMEDOUT3 /* command timed out */
-#define PC_DMA_OK 4 /* Use DMA */
-
-/*
* SCSI command transformation layer
*/
#define IDESCSI_SG_TRANSFORM 1 /* /dev/sg transformation */
@@ -319,8 +311,10 @@ static int idescsi_end_request (ide_drive_t *drive, int
uptodate, int nrsecs)
pc = opc;
rq = pc-rq;
pc-scsi_cmd-result = (CHECK_CONDITION 1) |
- ((test_bit(PC_TIMEDOUT,
pc-flags)?DID_TIME_OUT:DID_OK) 16);
- } else if (test_bit(PC_TIMEDOUT, pc-flags)) {
+ ((test_bit(PC_FLAG_TIMEDOUT, pc-flags) ?
+ DID_TIME_OUT :
+ DID_OK) 16);
+ } else if (test_bit(PC_FLAG_TIMEDOUT, pc-flags)) {
if (log)
printk (KERN_WARNING ide-scsi: %s: timed out for
%lu\n,
drive-name,
pc-scsi_cmd-serial_number);
@@ -362,7 +356,7 @@ static int idescsi_expiry(ide_drive_t *drive)
#if IDESCSI_DEBUG_LOG
printk(KERN_WARNING idescsi_expiry called for %lu at %lu\n,
pc-scsi_cmd-serial_number, jiffies);
#endif
- set_bit(PC_TIMEDOUT, pc-flags);
+ set_bit(PC_FLAG_TIMEDOUT, pc-flags);
return 0; /* we do not want the
ide subsystem to retry */
}
@@ -384,7 +378,7 @@ static ide_startstop_t idescsi_pc_intr (ide_drive_t *drive)
printk (KERN_INFO ide-scsi: Reached idescsi_pc_intr interrupt
handler\n);
#endif /* IDESCSI_DEBUG_LOG */
- if (test_bit(PC_TIMEDOUT, pc-flags)){
+ if (test_bit(PC_FLAG_TIMEDOUT, pc-flags)) {
#if IDESCSI_DEBUG_LOG
printk(KERN_WARNING idescsi_pc_intr: got timed out packet %lu
at %lu\n,
pc-scsi_cmd-serial_number, jiffies);
@@ -393,7 +387,7 @@ static ide_startstop_t idescsi_pc_intr (ide_drive_t *drive)
idescsi_end_request (drive, 1, 0);
return ide_stopped;
}
- if (test_and_clear_bit (PC_DMA_IN_PROGRESS, pc-flags)) {
+ if (test_and_clear_bit(PC_FLAG_DMA_IN_PROGRESS, pc-flags)) {
#if IDESCSI_DEBUG_LOG
printk (ide-scsi: %s: DMA complete\n, drive-name);
#endif /* IDESCSI_DEBUG_LOG */
@@ -432,7 +426,7 @@ static ide_startstop_t idescsi_pc_intr
Re: [PATCH 1/2] ide: use generic ATAPI packet command flags in ide-{floppy,tape,scsi}
On Feb 13, 2008 5:18 PM, Borislav Petkov [EMAIL PROTECTED] wrote: This is done in one single patch in order not to cause git breakage. Signed-off-by: Borislav Petkov [EMAIL PROTECTED] Looks good but could you please reorder patches and move PC_* - PC_FLAG * rename in ide-scsi to the patch removing atomic bitops from ide-scsi? Thanks, Bart - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pci_get_device_reverse(), why does Calgary need this?
On Wed, Feb 13, 2008 at 09:32:03AM -0800, Greg KH wrote: Is there some reason you aren't using the real PCI driver api here and registering a pci driver for these devices? That would take the whole loop over all pci devices logic out of the code entirely. I recall we had a reason, but I no longer recall what it was. Some reason the real PCI driver API didn't fit at the time. If someone were to whip up a working patch, I'd happily apply it. Feel free to nuke it and walk the list forward. So something like the patch below would be fine? Yep, looks good. Acked-by: Muli Ben-Yehuda [EMAIL PROTECTED] Cheers, Muli - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pci_get_device_reverse(), why does Calgary need this?
On Wed, Feb 13, 2008 at 01:34:12PM +0100, Bartlomiej Zolnierkiewicz wrote: On Wednesday 13 February 2008, Greg KH wrote: On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox wrote: Why does the calgary driver need this? Can we just use pci_get_device() instead? Why do you need to walk the device list backwards? Do you get false positives going forward? It doesn't look to be performance critical so the driver can pci_get_device until the end and use the final hit anyway. That would make more sense. IDE reverse is more problematic but nobody seems to use it. I've seen two posters say they use it. I'm wondering what it is really solving if they use it, and why if it's really needed, scsi never had to implement such a hack... It is no longer solving anything, just adds more pain. ;) [ The option comes from 2.2.x (so long before LABEL=/ and /dev/disk/by-id/ became popular). Some off-board controllers integrated on motherboards used to appear before on-board IDE on PCI bus so this option was meant to preserve the legacy ordering. ] Since it is valid only when Probe IDE PCI devices in the PCI bus order (DEPRECATED) config option is used it is already on its way out (though marking it as obsoleted would make it more explicit). I think that removing ide=reverse in 2.6.26 would be OK... Great, thanks for your blessing. I'll make up a patch and send it to you for approval. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ide: use generic ATAPI packet command flags in ide-{floppy,tape}
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
drivers/ide/ide-floppy.c | 14 --
drivers/ide/ide-tape.c | 16
include/linux/ide.h | 15 +++
3 files changed, 15 insertions(+), 30 deletions(-)
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index bf1ef60..5f133df 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -78,20 +78,6 @@
*/
#define IDEFLOPPY_PC_STACK (10 + IDEFLOPPY_MAX_PC_RETRIES)
-/* Packet command flag bits. */
-enum {
- /* 1 when we prefer to use DMA if possible */
- PC_FLAG_DMA_RECOMMENDED = (1 0),
- /* 1 while DMA in progress */
- PC_FLAG_DMA_IN_PROGRESS = (1 1),
- /* 1 when encountered problem during DMA */
- PC_FLAG_DMA_ERROR = (1 2),
- /* Data direction */
- PC_FLAG_WRITING = (1 3),
- /* Suppress error reporting */
- PC_FLAG_SUPPRESS_ERROR = (1 4),
-};
-
/* format capacities descriptor codes */
#define CAPACITY_INVALID 0x00
#define CAPACITY_UNFORMATTED 0x01
diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
index 3a10208..3f9fbd8 100644
--- a/drivers/ide/ide-tape.c
+++ b/drivers/ide/ide-tape.c
@@ -181,22 +181,6 @@ struct idetape_bh {
char *b_data;
};
-/* Packet command flag bits. */
-enum {
- /* Set when an error is considered normal - We won't retry */
- PC_FLAG_ABORT = (1 0),
- /* 1 When polling for DSC on a media access command */
- PC_FLAG_WAIT_FOR_DSC= (1 1),
- /* 1 when we prefer to use DMA if possible */
- PC_FLAG_DMA_RECOMMENDED = (1 2),
- /* 1 while DMA in progress */
- PC_FLAG_DMA_IN_PROGRESS = (1 3),
- /* 1 when encountered problem during DMA */
- PC_FLAG_DMA_ERROR = (1 4),
- /* Data direction */
- PC_FLAG_WRITING = (1 5),
-};
-
/* Tape door status */
#define DOOR_UNLOCKED 0
#define DOOR_LOCKED1
diff --git a/include/linux/ide.h b/include/linux/ide.h
index 509d806..0e5f09b 100644
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -629,6 +629,21 @@ typedef struct ide_settings_s {
int ide_add_setting(ide_drive_t *, const char *, int, int, int, int, int, int,
void *, ide_procset_t *set);
+/* ATAPI packet command flags */
+enum {
+ /* set when an error is considered normal - no retry (ide-tape) */
+ PC_FLAG_ABORT = (1 0),
+ PC_FLAG_SUPPRESS_ERROR = (1 1),
+ PC_FLAG_WAIT_FOR_DSC= (1 2),
+ PC_FLAG_DMA_OK = (1 3),
+ PC_FLAG_DMA_RECOMMENDED = (1 4),
+ PC_FLAG_DMA_IN_PROGRESS = (1 5),
+ PC_FLAG_DMA_ERROR = (1 6),
+ PC_FLAG_WRITING = (1 7),
+ /* command timed out */
+ PC_FLAG_TIMEDOUT= (1 8),
+};
+
struct ide_atapi_pc {
/* actual packet bytes */
u8 c[12];
--
1.5.3.7
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ide-scsi: do non-atomic pc-flags testing
...also, convert ide-scsi to using the generic pc-flags defines.
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
---
drivers/scsi/ide-scsi.c | 37 -
1 files changed, 16 insertions(+), 21 deletions(-)
diff --git a/drivers/scsi/ide-scsi.c b/drivers/scsi/ide-scsi.c
index 5ec421c..93c3fc2 100644
--- a/drivers/scsi/ide-scsi.c
+++ b/drivers/scsi/ide-scsi.c
@@ -61,14 +61,6 @@
#define IDESCSI_DEBUG_LOG 0
/*
- * Packet command status bits.
- */
-#define PC_DMA_IN_PROGRESS 0 /* 1 while DMA in progress */
-#define PC_WRITING 1 /* Data direction */
-#define PC_TIMEDOUT3 /* command timed out */
-#define PC_DMA_OK 4 /* Use DMA */
-
-/*
* SCSI command transformation layer
*/
#define IDESCSI_SG_TRANSFORM 1 /* /dev/sg transformation */
@@ -319,8 +311,10 @@ static int idescsi_end_request (ide_drive_t *drive, int
uptodate, int nrsecs)
pc = opc;
rq = pc-rq;
pc-scsi_cmd-result = (CHECK_CONDITION 1) |
- ((test_bit(PC_TIMEDOUT,
pc-flags)?DID_TIME_OUT:DID_OK) 16);
- } else if (test_bit(PC_TIMEDOUT, pc-flags)) {
+ (((pc-flags PC_FLAG_TIMEDOUT) ?
+ DID_TIME_OUT :
+ DID_OK) 16);
+ } else if (pc-flags PC_FLAG_TIMEDOUT) {
if (log)
printk (KERN_WARNING ide-scsi: %s: timed out for
%lu\n,
drive-name,
pc-scsi_cmd-serial_number);
@@ -362,7 +356,7 @@ static int idescsi_expiry(ide_drive_t *drive)
#if IDESCSI_DEBUG_LOG
printk(KERN_WARNING idescsi_expiry called for %lu at %lu\n,
pc-scsi_cmd-serial_number, jiffies);
#endif
- set_bit(PC_TIMEDOUT, pc-flags);
+ pc-flags |= PC_FLAG_TIMEDOUT;
return 0; /* we do not want the
ide subsystem to retry */
}
@@ -384,7 +378,7 @@ static ide_startstop_t idescsi_pc_intr (ide_drive_t *drive)
printk (KERN_INFO ide-scsi: Reached idescsi_pc_intr interrupt
handler\n);
#endif /* IDESCSI_DEBUG_LOG */
- if (test_bit(PC_TIMEDOUT, pc-flags)){
+ if (pc-flags PC_FLAG_TIMEDOUT) {
#if IDESCSI_DEBUG_LOG
printk(KERN_WARNING idescsi_pc_intr: got timed out packet %lu
at %lu\n,
pc-scsi_cmd-serial_number, jiffies);
@@ -393,7 +387,8 @@ static ide_startstop_t idescsi_pc_intr (ide_drive_t *drive)
idescsi_end_request (drive, 1, 0);
return ide_stopped;
}
- if (test_and_clear_bit (PC_DMA_IN_PROGRESS, pc-flags)) {
+ if (pc-flags PC_FLAG_DMA_IN_PROGRESS) {
+ pc-flags = ~PC_FLAG_DMA_IN_PROGRESS;
#if IDESCSI_DEBUG_LOG
printk (ide-scsi: %s: DMA complete\n, drive-name);
#endif /* IDESCSI_DEBUG_LOG */
@@ -432,7 +427,7 @@ static ide_startstop_t idescsi_pc_intr (ide_drive_t *drive)
- discarding data\n);
temp = pc-buf_size - pc-xferred;
if (temp) {
- clear_bit(PC_WRITING, pc-flags);
+ pc-flags = ~PC_FLAG_WRITING;
if (pc-sg)
idescsi_input_buffers(drive, pc,
temp);
@@ -454,14 +449,14 @@ static ide_startstop_t idescsi_pc_intr (ide_drive_t
*drive)
}
}
if (ireason IO) {
- clear_bit(PC_WRITING, pc-flags);
+ pc-flags = ~PC_FLAG_WRITING;
if (pc-sg)
idescsi_input_buffers(drive, pc, bcount);
else
hwif-atapi_input_bytes(drive, pc-cur_pos,
bcount);
} else {
- set_bit(PC_WRITING, pc-flags);
+ pc-flags |= PC_FLAG_WRITING;
if (pc-sg)
idescsi_output_buffers(drive, pc, bcount);
else
@@ -501,8 +496,8 @@ static ide_startstop_t idescsi_transfer_pc(ide_drive_t
*drive)
ide_set_handler(drive, idescsi_pc_intr, get_timeout(pc),
idescsi_expiry);
/* Send the actual packet */
drive-hwif-atapi_output_bytes(drive, scsi-pc-c, 12);
- if (test_bit (PC_DMA_OK, pc-flags)) {
- set_bit (PC_DMA_IN_PROGRESS, pc-flags);
+ if (pc-flags PC_FLAG_DMA_OK) {
+ pc-flags |= PC_FLAG_DMA_IN_PROGRESS;
hwif-dma_start(drive);
}
return ide_started;
@@ -512,10 +507,10 @@ static inline int idescsi_set_direction(struct
ide_atapi_pc *pc)
{
switch (pc-c[0]) {
case READ_6: case
[PATCH 1/2] sata_mv: use hpriv-base instead of the host-iomap
this fixes crash bug as the iomap table is not valid for integrated controllers. Signed-off-by: Saeed Bishara [EMAIL PROTECTED] --- drivers/ata/sata_mv.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c index 04b5717..9c9a5b0 100644 --- a/drivers/ata/sata_mv.c +++ b/drivers/ata/sata_mv.c @@ -870,7 +870,7 @@ static void mv_start_dma(struct ata_port *ap, void __iomem *port_mmio, struct mv_host_priv *hpriv = ap-host-private_data; int hard_port = mv_hardport_from_port(ap-port_no); void __iomem *hc_mmio = mv_hc_base_from_port( - ap-host-iomap[MV_PRIMARY_BAR], hard_port); + mv_host_base(ap-host), hard_port); u32 hc_irq_cause, ipending; /* clear EDMA event indicators, if any */ -- 1.5.2.5 - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
On Wed, 2008-02-13 at 09:45 -0800, Kristen Carlson Accardi wrote: I don't think I'm arguing whether or not your solution may work, what I am arguing is really a more philosophical point. Not can we do it this way, but should we do it way. I am of the opinion that management belongs in userspace. I also am of the opinion that if you can successfully accomplish something in user space, you should. I also believe that even if you provide this basic interface, all system vendors are going to provide libraries on top of that to customize it, so you've not added much value to just a simple message passing interface. I'm not necessarily arguing against that. However, what you're providing is slightly more than just a userspace tap into the enclosure. You're adding a file to display and control the enclosure state (sw_activity). This constitutes an ad-hoc sysfs interface. I'm not telling you not to do it, but I am pleading that if we have to have all these sysfs interfaces, lets at least do it in a uniform way. Enclosures are such nasty beasts, that even the job of getting a tap into them is problematic, so if we have a different tap infrastructure for every different enclosure type and connection it's still going to be pretty unmanageable to a userspace interface. So, I'm happy to defer to Jeff's judgement call here - I just want to do what's right for our customers and get an enclosure management interface for SATA exposed, preferrably in time for the 2.6.26 merge window. If he prefers your design, I'll disagree, but commit to his decision and try to get this to work for SATA. If he'd rather see something along the lines of what I proposed, then since it is 100% self contained in the SATA subsystem, it shouldn't impact whatever you want to do in the SCSI subsystem. James - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
On Tue, 12 Feb 2008 13:28:15 -0600 James Bottomley [EMAIL PROTECTED] wrote: On Tue, 2008-02-12 at 11:07 -0800, Kristen Carlson Accardi wrote: I understand what you are trying to do - I guess I just doubt the value you've added by doing this. I think that there's going to be so much customization that system vendors will want to add, that they are going to wind up adding a custom library regardless, so standardising those few things won't buy us anything. It depends ... if you actually have a use for the customisations, yes. If you just want the basics of who (what's in the enclousure), what (activity) and where (locate) then I think it solves your problem almost entirely. So, entirely as a straw horse, tell me what else your enclosures provide that I haven't listed in the four points. The SES standards too provide a huge range of things that no-one ever seems to implement (temperature, power, fan speeds etc). I think the users of enclosures fall int these categories 85% just want to know where their device actually is (i.e. that sdc is in enclosure slot 5) 50% like watching the activity lights 30% want to be able to have a visual locate function 20% want a visual failure indication (the other 80% rely on some OS notification instead) When you add up the overlapping needs, you get about 90% of people happy with the basics that the enclosure services provide. Could there be more ... sure; should there be more ... I don't think so ... that's what value add the user libraries can provide. James I don't think I'm arguing whether or not your solution may work, what I am arguing is really a more philosophical point. Not can we do it this way, but should we do it way. I am of the opinion that management belongs in userspace. I also am of the opinion that if you can successfully accomplish something in user space, you should. I also believe that even if you provide this basic interface, all system vendors are going to provide libraries on top of that to customize it, so you've not added much value to just a simple message passing interface. So, I'm happy to defer to Jeff's judgement call here - I just want to do what's right for our customers and get an enclosure management interface for SATA exposed, preferrably in time for the 2.6.26 merge window. If he prefers your design, I'll disagree, but commit to his decision and try to get this to work for SATA. If he'd rather see something along the lines of what I proposed, then since it is 100% self contained in the SATA subsystem, it shouldn't impact whatever you want to do in the SCSI subsystem. Jeff? - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pci_get_device_reverse(), why does Calgary need this?
On Wed, Feb 13, 2008 at 07:47:11PM +0200, Muli Ben-Yehuda wrote: On Wed, Feb 13, 2008 at 09:32:03AM -0800, Greg KH wrote: Is there some reason you aren't using the real PCI driver api here and registering a pci driver for these devices? That would take the whole loop over all pci devices logic out of the code entirely. I recall we had a reason, but I no longer recall what it was. Some reason the real PCI driver API didn't fit at the time. If someone were to whip up a working patch, I'd happily apply it. at the time? It's been in place since the 2.2 days :) Is the problem that other drivers also want access to this PCI device for some reason? I'll whip up a patch for you to test with in a bit... Feel free to nuke it and walk the list forward. So something like the patch below would be fine? Yep, looks good. Acked-by: Muli Ben-Yehuda [EMAIL PROTECTED] thanks for reviewing this. greg k-h - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pci_get_device_reverse(), why does Calgary need this?
On Wed, Feb 13, 2008 at 09:28:24AM -0800, Greg KH wrote:
On Wed, Feb 13, 2008 at 01:34:12PM +0100, Bartlomiej Zolnierkiewicz wrote:
On Wednesday 13 February 2008, Greg KH wrote:
On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox wrote:
Why does the calgary driver need this? Can we just use
pci_get_device()
instead? Why do you need to walk the device list backwards? Do you
get
false positives going forward?
It doesn't look to be performance critical so the driver can
pci_get_device until the end and use the final hit anyway.
That would make more sense.
IDE reverse is more problematic but nobody seems to use it.
I've seen two posters say they use it. I'm wondering what it is really
solving if they use it, and why if it's really needed, scsi never had to
implement such a hack...
It is no longer solving anything, just adds more pain. ;)
[ The option comes from 2.2.x (so long before LABEL=/ and /dev/disk/by-id/
became popular). Some off-board controllers integrated on motherboards
used to appear before on-board IDE on PCI bus so this option was meant
to preserve the legacy ordering. ]
Since it is valid only when Probe IDE PCI devices in the PCI bus order
(DEPRECATED) config option is used it is already on its way out (though
marking it as obsoleted would make it more explicit).
I think that removing ide=reverse in 2.6.26 would be OK...
Great, thanks for your blessing. I'll make up a patch and send it to
you for approval.
How does the patch below look? I didn't want to remove the whole config
option, as there is more to the logic than just the reverse order
stuff there.
If you don't mind, can I take this through the PCI tree so as to allow
the removal of this pci function afterwards?
thanks,
greg k-h
From: Greg Kroah-Hartman [EMAIL PROTECTED]
Subject: IDE: remove ide=reverse IDE core
This option is obsolete and can be removed safely.
It allows us to remove the pci_get_device_reverse() function from the
PCI core.
Cc: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
drivers/ide/ide-scan-pci.c |9 ++---
drivers/ide/ide.c | 12
include/linux/ide.h|1 -
3 files changed, 2 insertions(+), 20 deletions(-)
--- a/drivers/ide/ide-scan-pci.c
+++ b/drivers/ide/ide-scan-pci.c
@@ -88,13 +88,8 @@ static int __init ide_scan_pcibus(void)
struct list_head *l, *n;
pre_init = 0;
- if (!ide_scan_direction)
- while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev)))
- ide_scan_pcidev(dev);
- else
- while ((dev = pci_get_device_reverse(PCI_ANY_ID, PCI_ANY_ID,
-dev)))
- ide_scan_pcidev(dev);
+ while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev)))
+ ide_scan_pcidev(dev);
/*
* Hand the drivers over to the PCI layer now we
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -92,10 +92,6 @@ static int system_bus_speed; /* holds wh
DEFINE_MUTEX(ide_cfg_mtx);
__cacheline_aligned_in_smp DEFINE_SPINLOCK(ide_lock);
-#ifdef CONFIG_IDEPCI_PCIBUS_ORDER
-int ide_scan_direction; /* THIS was formerly 2.2.x pci=reverse */
-#endif
-
int noautodma = 0;
#ifdef CONFIG_BLK_DEV_IDEACPI
@@ -1227,14 +1223,6 @@ static int __init ide_setup(char *s)
goto obsolete_option;
}
-#ifdef CONFIG_IDEPCI_PCIBUS_ORDER
- if (!strcmp(s, ide=reverse)) {
- ide_scan_direction = 1;
- printk( : Enabled support for IDE inverse scan order.\n);
- return 1;
- }
-#endif
-
#ifdef CONFIG_BLK_DEV_IDEACPI
if (!strcmp(s, ide=noacpi)) {
//printk( : Disable IDE ACPI support.\n);
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -988,7 +988,6 @@ extern void do_ide_request(struct reques
void ide_init_disk(struct gendisk *, ide_drive_t *);
#ifdef CONFIG_IDEPCI_PCIBUS_ORDER
-extern int ide_scan_direction;
extern int __ide_pci_register_driver(struct pci_driver *driver, struct module
*owner, const char *mod_name);
#define ide_pci_register_driver(d) __ide_pci_register_driver(d, THIS_MODULE,
KBUILD_MODNAME)
#else
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata/sata_sil24 cache alignment problem?
Alan Cox [EMAIL PROTECTED] wrote:
Has anyone else reported a problem like this? It requires
non-coherent DMA, and a lack of a cache invalidate instruction, and
one of the drivers that has this problem (it looks like sata_qstor
does too, I haven't looked at others), so maybe that doesn't cover
any other architectures.
Nobody has, not even PA-RISC which is normally guaranteed to make life
miserable in the caching area but I agree entirely with your diagnosis
and that buffer should indeed be marked cache aligned
I can provide a patch if you're interested.
Please do.
Here it is. I'd appreciate it if someone could sanity check where I'm
freeing the buffer. It works, but I don't know the code well enough
to know if this covers all cases.
I'm counting on kmalloc to return a cache aligned buffer. I found
some reason to think it does, but I don't remember offhand what that
reason was, or if it's configurable per-architecture. The buffer has
to be both physically and virtually contiguous, I was tempted to just
allocate a page and waste some space but we've got 64K pages, so I'm a
bit more sensitive about that.
*** drivers/scsi/libata-core.c 2008-02-13 13:34:32.141489000 -0500
--- drivers/scsi/libata-core.c.orig 2008-02-13 13:29:35.62036 -0500
***
*** 5335,5369
}
host = scsi_host_alloc(ent-sht, sizeof(struct ata_port));
if (!host)
return NULL;
host-transportt = ata_scsi_transport_template;
ap = ata_shost_to_port(host);
- ap-sector_buf = kmalloc(ATA_SECT_SIZE, GFP_KERNEL);
- if (!ap-sector_buf)
- goto err_out;
-
ata_host_init(ap, host, host_set, ent, port_no);
rc = ap-ops-port_start(ap);
if (rc)
goto err_out;
return ap;
err_out:
- if (ap-sector_buf)
- kfree(ap-sector_buf);
scsi_host_put(host);
return NULL;
}
/**
*ata_device_add - Register hardware device with ATA and SCSI layers
*@ent: Probe information describing hardware device to be registered
*
*This function processes the information provided in the probe
*information struct @ent, allocates the necessary ATA and SCSI
--- 5335,5363
***
*** 5602,5645
*Unregister all objects associated with this host set. Free those
*objects.
*
*LOCKING:
*Inherited from calling layer (may sleep).
*/
void ata_host_set_remove(struct ata_host_set *host_set)
{
unsigned int i;
- u8 *sector_buf;
for (i = 0; i host_set-n_ports; i++)
ata_port_detach(host_set-ports[i]);
free_irq(host_set-irq, host_set);
for (i = 0; i host_set-n_ports; i++) {
struct ata_port *ap = host_set-ports[i];
ata_scsi_release(ap-host);
if ((ap-flags ATA_FLAG_NO_LEGACY) == 0) {
struct ata_ioports *ioaddr = ap-ioaddr;
if (ioaddr-cmd_addr == 0x1f0)
release_region(0x1f0, 8);
else if (ioaddr-cmd_addr == 0x170)
release_region(0x170, 8);
}
- sector_buf = ap-sector_buf;
scsi_host_put(ap-host);
- kfree(sector_buf);
}
if (host_set-ops-host_stop)
host_set-ops-host_stop(host_set);
kfree(host_set);
}
/**
*ata_scsi_release - SCSI layer callback hook for host unload
--- 5596,5636
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata/sata_sil24 cache alignment problem?
Alan Cox [EMAIL PROTECTED] wrote:
Has anyone else reported a problem like this? It requires
non-coherent DMA, and a lack of a cache invalidate instruction, and
one of the drivers that has this problem (it looks like sata_qstor
does too, I haven't looked at others), so maybe that doesn't cover
any other architectures.
Nobody has, not even PA-RISC which is normally guaranteed to make life
miserable in the caching area but I agree entirely with your diagnosis
and that buffer should indeed be marked cache aligned
I can provide a patch if you're interested.
Please do.
Oops, sorry, I left a file out of that diff. Here it is again...
*** drivers/scsi/libata-core.c 2008-02-13 13:34:32.141489000 -0500
--- drivers/scsi/libata-core.c.orig 2008-02-13 13:29:35.62036 -0500
***
*** 5335,5369
}
host = scsi_host_alloc(ent-sht, sizeof(struct ata_port));
if (!host)
return NULL;
host-transportt = ata_scsi_transport_template;
ap = ata_shost_to_port(host);
- ap-sector_buf = kmalloc(ATA_SECT_SIZE, GFP_KERNEL);
- if (!ap-sector_buf)
- goto err_out;
-
ata_host_init(ap, host, host_set, ent, port_no);
rc = ap-ops-port_start(ap);
if (rc)
goto err_out;
return ap;
err_out:
- if (ap-sector_buf)
- kfree(ap-sector_buf);
scsi_host_put(host);
return NULL;
}
/**
*ata_device_add - Register hardware device with ATA and SCSI layers
*@ent: Probe information describing hardware device to be registered
*
*This function processes the information provided in the probe
*information struct @ent, allocates the necessary ATA and SCSI
--- 5335,5363
***
*** 5602,5645
*Unregister all objects associated with this host set. Free those
*objects.
*
*LOCKING:
*Inherited from calling layer (may sleep).
*/
void ata_host_set_remove(struct ata_host_set *host_set)
{
unsigned int i;
- u8 *sector_buf;
for (i = 0; i host_set-n_ports; i++)
ata_port_detach(host_set-ports[i]);
free_irq(host_set-irq, host_set);
for (i = 0; i host_set-n_ports; i++) {
struct ata_port *ap = host_set-ports[i];
ata_scsi_release(ap-host);
if ((ap-flags ATA_FLAG_NO_LEGACY) == 0) {
struct ata_ioports *ioaddr = ap-ioaddr;
if (ioaddr-cmd_addr == 0x1f0)
release_region(0x1f0, 8);
else if (ioaddr-cmd_addr == 0x170)
release_region(0x170, 8);
}
- sector_buf = ap-sector_buf;
scsi_host_put(ap-host);
- kfree(sector_buf);
}
if (host_set-ops-host_stop)
host_set-ops-host_stop(host_set);
kfree(host_set);
}
/**
*ata_scsi_release - SCSI layer callback hook for host unload
--- 5596,5636
*** include/linux/libata.h 2008-02-13 10:51:39.151202000 -0500
--- include/linux/libata.h.orig 2008-02-13 13:50:26.531572000 -0500
***
*** 550,570
u32 msg_enable;
struct list_headeh_done_q;
wait_queue_head_t eh_wait_q;
pm_message_tpm_mesg;
int *pm_result;
void*private_data;
! u8 *sector_buf; /* owned by EH */
};
struct ata_port_operations {
void (*port_disable) (struct ata_port *);
void (*dev_config) (struct ata_port *, struct ata_device *);
void (*set_piomode) (struct ata_port *, struct ata_device *);
void (*set_dmamode) (struct ata_port *, struct ata_device *);
unsigned long (*mode_filter) (const struct ata_port *, struct
ata_device *, unsigned long);
--- 550,570
u32 msg_enable;
struct list_headeh_done_q;
wait_queue_head_t eh_wait_q;
pm_message_tpm_mesg;
int *pm_result;
void*private_data;
! u8 sector_buf[ATA_SECT_SIZE]; /* owned by EH */
};
struct ata_port_operations {
void (*port_disable) (struct ata_port *);
void (*dev_config) (struct ata_port *, struct ata_device *);
void (*set_piomode) (struct ata_port *, struct ata_device *);
void (*set_dmamode) (struct ata_port *, struct ata_device *);
unsigned long (*mode_filter) (const struct ata_port *, struct
ata_device *, unsigned long);
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
[PATCH 2/2] sata_mv: remove iounmap in mv_platform_remove
this will fix crash bug when doing rmmod to the driver, this is because the
port_stop function get called later and it could access the device's registers.
Signed-off-by: Saeed Bishara [EMAIL PROTECTED]
---
drivers/ata/sata_mv.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 9c9a5b0..c61e666 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -2983,11 +2983,8 @@ static int __devexit mv_platform_remove(struct
platform_device *pdev)
{
struct device *dev = pdev-dev;
struct ata_host *host = dev_get_drvdata(dev);
- struct mv_host_priv *hpriv = host-private_data;
- void __iomem *base = hpriv-base;
ata_host_detach(host);
- iounmap(base);
return 0;
}
--
1.5.2.5
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] sata_mv: remove iounmap in mv_platform_remove
Saeed Bishara wrote:
this will fix crash bug when doing rmmod to the driver, this is because the
port_stop function get called later and it could access the device's registers.
Signed-off-by: Saeed Bishara [EMAIL PROTECTED]
---
drivers/ata/sata_mv.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 9c9a5b0..c61e666 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -2983,11 +2983,8 @@ static int __devexit mv_platform_remove(struct
platform_device *pdev)
{
struct device *dev = pdev-dev;
struct ata_host *host = dev_get_drvdata(dev);
- struct mv_host_priv *hpriv = host-private_data;
- void __iomem *base = hpriv-base;
ata_host_detach(host);
- iounmap(base);
return 0;
}
..
Where does the iounmap() now get done instead of that place?
--
Mark Lord
Real-Time Remedies Inc.
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [discuss] ide=reverse do we still need this?
Hm, so, to summarize: - you needed this option many years ago to get a box to work properly - you don't need this today So, if the option went away, you would not be inconvenienced? After having reanimated the old system and after comments of other persons I would not be inconvenienced if the option went away. The system indeed did not boot correctly without that option, because the disks appeared in a wrong order. On the other hand, I was able to (re)install bootloaders (grub as well as lilo) and after that did not need the option any more. Unfortunately, after that I was not able to reproduce the initial situation where the option was needed. Dirk - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata/sata_sil24 cache alignment problem?
O I'm counting on kmalloc to return a cache aligned buffer. I found some reason to think it does, but I don't remember offhand what that Its defined to reason was, or if it's configurable per-architecture. The buffer has to be both physically and virtually contiguous, I was tempted to just allocate a page and waste some space but we've got 64K pages, so I'm a bit more sensitive about that. Ok I was expecting a different approach if you mark the field with the magic cacheline_aligned tag after it (ie int foo blah_aligned;) the compiler should align it all for you , which is probably cleaner if it works. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [discuss] ide=reverse do we still need this?
On Wed, Feb 13, 2008 at 09:00:15PM +0100, Dirk GOUDERS wrote: Hm, so, to summarize: - you needed this option many years ago to get a box to work properly - you don't need this today So, if the option went away, you would not be inconvenienced? After having reanimated the old system and after comments of other persons I would not be inconvenienced if the option went away. The system indeed did not boot correctly without that option, because the disks appeared in a wrong order. On the other hand, I was able to (re)install bootloaders (grub as well as lilo) and after that did not need the option any more. Unfortunately, after that I was not able to reproduce the initial situation where the option was needed. Great, thanks a lot for testing this, and letting us know. greg k-h - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata/sata_sil24 cache alignment problem?
Alan Cox [EMAIL PROTECTED] wrote:
O I'm counting on kmalloc to return a cache aligned buffer. I found
some reason to think it does, but I don't remember offhand what that
Its defined to
reason was, or if it's configurable per-architecture. The buffer has
to be both physically and virtually contiguous, I was tempted to just
allocate a page and waste some space but we've got 64K pages, so I'm a
bit more sensitive about that.
Ok I was expecting a different approach if you mark the field with the
magic cacheline_aligned tag after it (ie int foo blah_aligned;)
the compiler should align it all for you , which is probably cleaner if
it works.
I hadn't considered that approach due to the way the ata_port is allocated:
libata-core.c:
host = scsi_host_alloc(ent-sht, sizeof(struct ata_port));
hosts.c:
struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int
privsize)
{
shost = kzalloc(sizeof(struct Scsi_Host) + privsize, gfp_mask);
}
The ata_port allocation is tacked onto the end of the Scsi_Host
allocation, so the start of ata_port will only be cache aligned if the
end of the Scsi_Host struct is, although that would be easy enough to
fix since it's currently aligned to an unsigned long boundary.
I like that approach better, since it's clearer what the intent is,
and it's easier. Is there any other way that the ata_port struct
might be used that would invalidate this? This one issue is the
extent of my knowledge of libata.
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ide-floppy: merge callbacks
commit d1f1f84f413ab00cb2fec48170d022fcd900e214
Author: Borislav Petkov [EMAIL PROTECTED]
Date: Wed Feb 13 20:26:56 2008 +0100
ide-floppy: merge callbacks
The appropriate functionality of the callback is established through
querying
the ATAPI packet command in pc-c[0].
While at it, simplify if (floppy-failed_pc)-branch to be found in the
original
idefloppy_request_sense_callback().
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 5f133df..1365310 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -313,50 +313,39 @@ static struct request
*idefloppy_next_rq_storage(ide_drive_t *drive)
return (floppy-rq_stack[floppy-rq_stack_index++]);
}
-static void idefloppy_request_sense_callback(ide_drive_t *drive)
+static void ide_floppy_callback(ide_drive_t *drive)
{
idefloppy_floppy_t *floppy = drive-driver_data;
- u8 *buf = floppy-pc-buf;
debug_log(Reached %s\n, __func__);
- if (!floppy-pc-error) {
- floppy-sense_key = buf[2] 0x0F;
- floppy-asc = buf[12];
- floppy-ascq = buf[13];
- floppy-progress_indication = buf[15] 0x80 ?
- (u16)get_unaligned((u16 *)buf[16]) : 0x1;
+ if (floppy-pc-c[0] == GPCMD_REQUEST_SENSE) {
+ u8 *buf = floppy-pc-buf;
- if (floppy-failed_pc)
- debug_log(pc = %x, sense key = %x, asc = %x,
-ascq = %x\n,
- floppy-failed_pc-c[0],
- floppy-sense_key,
- floppy-asc,
- floppy-ascq);
- else
- debug_log(sense key = %x, asc = %x, ascq = %x\n,
- floppy-sense_key,
- floppy-asc,
- floppy-ascq);
-
-
- idefloppy_end_request(drive, 1, 0);
- } else {
- printk(KERN_ERR Error in REQUEST SENSE itself - Aborting
-request!\n);
- idefloppy_end_request(drive, 0, 0);
- }
-}
+ if (!floppy-pc-error) {
+ floppy-sense_key = buf[2] 0x0F;
+ floppy-asc = buf[12];
+ floppy-ascq = buf[13];
+ floppy-progress_indication = buf[15] 0x80 ?
+ (u16)get_unaligned((u16 *)buf[16]) : 0x1;
-/* General packet command callback function. */
-static void idefloppy_pc_callback(ide_drive_t *drive)
-{
- idefloppy_floppy_t *floppy = drive-driver_data;
+ if (floppy-failed_pc)
+ debug_log(pc = %x, , floppy-failed_pc-c[0]);
- debug_log(Reached %s\n, __func__);
+ debug_log(sense key = %x, asc = %x, ascq = %x\n,
+ floppy-sense_key, floppy-asc, floppy-ascq);
- idefloppy_end_request(drive, floppy-pc-error ? 0 : 1, 0);
+ idefloppy_end_request(drive, 1, 0);
+ } else {
+ printk(KERN_ERR Error in REQUEST SENSE itself -
+ Aborting request!\n);
+ idefloppy_end_request(drive, 0, 0);
+ }
+ } else if (floppy-pc-c[0] == GPCMD_READ_10 ||
+ floppy-pc-c[0] == GPCMD_WRITE_10)
+ idefloppy_end_request(drive, 1, 0);
+ else
+ idefloppy_end_request(drive, floppy-pc-error ? 0 : 1, 0);
}
static void idefloppy_init_pc(struct ide_atapi_pc *pc)
@@ -367,7 +356,7 @@ static void idefloppy_init_pc(struct ide_atapi_pc *pc)
pc-req_xfer = 0;
pc-buf = pc-pc_buf;
pc-buf_size = IDEFLOPPY_PC_BUFFER_SIZE;
- pc-idefloppy_callback = idefloppy_pc_callback;
+ pc-idefloppy_callback = ide_floppy_callback;
}
static void idefloppy_create_request_sense_cmd(struct ide_atapi_pc *pc)
@@ -376,7 +365,6 @@ static void idefloppy_create_request_sense_cmd(struct
ide_atapi_pc *pc)
pc-c[0] = GPCMD_REQUEST_SENSE;
pc-c[4] = 255;
pc-req_xfer = 18;
- pc-idefloppy_callback = idefloppy_request_sense_callback;
}
/*
@@ -697,14 +685,6 @@ static ide_startstop_t idefloppy_issue_pc(ide_drive_t
*drive,
}
}
-static void idefloppy_rw_callback(ide_drive_t *drive)
-{
- debug_log(Reached %s\n, __func__);
-
- idefloppy_end_request(drive, 1, 0);
- return;
-}
-
static void idefloppy_create_prevent_cmd(struct ide_atapi_pc *pc, int prevent)
{
debug_log(creating prevent removal command, prevent = %d\n, prevent);
@@ -799,7 +779,6 @@ static void idefloppy_create_rw_cmd(idefloppy_floppy_t
*floppy,
Re: [PATCH 1/2] ide: use generic ATAPI packet command flags in ide-{floppy,tape}
On Wednesday 13 February 2008, Borislav Petkov wrote: Signed-off-by: Borislav Petkov [EMAIL PROTECTED] applied - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ide-scsi: do non-atomic pc-flags testing
On Wednesday 13 February 2008, Borislav Petkov wrote: ...also, convert ide-scsi to using the generic pc-flags defines. Signed-off-by: Borislav Petkov [EMAIL PROTECTED] applied - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ide-floppy: merge callbacks
On Wednesday 13 February 2008, Borislav Petkov wrote:
commit d1f1f84f413ab00cb2fec48170d022fcd900e214
Author: Borislav Petkov [EMAIL PROTECTED]
Date: Wed Feb 13 20:26:56 2008 +0100
ide-floppy: merge callbacks
The appropriate functionality of the callback is established through
querying
the ATAPI packet command in pc-c[0].
While at it, simplify if (floppy-failed_pc)-branch to be found in the
original
idefloppy_request_sense_callback().
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 5f133df..1365310 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -313,50 +313,39 @@ static struct request
*idefloppy_next_rq_storage(ide_drive_t *drive)
return (floppy-rq_stack[floppy-rq_stack_index++]);
}
-static void idefloppy_request_sense_callback(ide_drive_t *drive)
+static void ide_floppy_callback(ide_drive_t *drive)
{
idefloppy_floppy_t *floppy = drive-driver_data;
- u8 *buf = floppy-pc-buf;
debug_log(Reached %s\n, __func__);
- if (!floppy-pc-error) {
- floppy-sense_key = buf[2] 0x0F;
- floppy-asc = buf[12];
- floppy-ascq = buf[13];
- floppy-progress_indication = buf[15] 0x80 ?
- (u16)get_unaligned((u16 *)buf[16]) : 0x1;
+ if (floppy-pc-c[0] == GPCMD_REQUEST_SENSE) {
+ u8 *buf = floppy-pc-buf;
- if (floppy-failed_pc)
- debug_log(pc = %x, sense key = %x, asc = %x,
- ascq = %x\n,
- floppy-failed_pc-c[0],
- floppy-sense_key,
- floppy-asc,
- floppy-ascq);
- else
- debug_log(sense key = %x, asc = %x, ascq = %x\n,
- floppy-sense_key,
- floppy-asc,
- floppy-ascq);
-
-
- idefloppy_end_request(drive, 1, 0);
- } else {
- printk(KERN_ERR Error in REQUEST SENSE itself - Aborting
- request!\n);
- idefloppy_end_request(drive, 0, 0);
- }
-}
+ if (!floppy-pc-error) {
+ floppy-sense_key = buf[2] 0x0F;
+ floppy-asc = buf[12];
+ floppy-ascq = buf[13];
+ floppy-progress_indication = buf[15] 0x80 ?
+ (u16)get_unaligned((u16 *)buf[16]) : 0x1;
-/* General packet command callback function. */
-static void idefloppy_pc_callback(ide_drive_t *drive)
-{
- idefloppy_floppy_t *floppy = drive-driver_data;
+ if (floppy-failed_pc)
+ debug_log(pc = %x, , floppy-failed_pc-c[0]);
- debug_log(Reached %s\n, __func__);
+ debug_log(sense key = %x, asc = %x, ascq = %x\n,
+ floppy-sense_key, floppy-asc, floppy-ascq);
- idefloppy_end_request(drive, floppy-pc-error ? 0 : 1, 0);
+ idefloppy_end_request(drive, 1, 0);
+ } else {
+ printk(KERN_ERR Error in REQUEST SENSE itself -
+ Aborting request!\n);
+ idefloppy_end_request(drive, 0, 0);
+ }
+ } else if (floppy-pc-c[0] == GPCMD_READ_10 ||
+ floppy-pc-c[0] == GPCMD_WRITE_10)
+ idefloppy_end_request(drive, 1, 0);
+ else
+ idefloppy_end_request(drive, floppy-pc-error ? 0 : 1, 0);
}
static void idefloppy_init_pc(struct ide_atapi_pc *pc)
@@ -367,7 +356,7 @@ static void idefloppy_init_pc(struct ide_atapi_pc *pc)
pc-req_xfer = 0;
pc-buf = pc-pc_buf;
pc-buf_size = IDEFLOPPY_PC_BUFFER_SIZE;
- pc-idefloppy_callback = idefloppy_pc_callback;
+ pc-idefloppy_callback = ide_floppy_callback;
}
static void idefloppy_create_request_sense_cmd(struct ide_atapi_pc *pc)
@@ -376,7 +365,6 @@ static void idefloppy_create_request_sense_cmd(struct
ide_atapi_pc *pc)
pc-c[0] = GPCMD_REQUEST_SENSE;
pc-c[4] = 255;
pc-req_xfer = 18;
- pc-idefloppy_callback = idefloppy_request_sense_callback;
}
/*
@@ -697,14 +685,6 @@ static ide_startstop_t idefloppy_issue_pc(ide_drive_t
*drive,
}
}
-static void idefloppy_rw_callback(ide_drive_t *drive)
-{
- debug_log(Reached %s\n, __func__);
-
- idefloppy_end_request(drive, 1, 0);
- return;
-}
-
static void idefloppy_create_prevent_cmd(struct ide_atapi_pc *pc, int
prevent)
{
debug_log(creating prevent removal command, prevent = %d\n, prevent);
@@ -799,7 +779,6 @@ static void idefloppy_create_rw_cmd(idefloppy_floppy_t
Re: pci_get_device_reverse(), why does Calgary need this?
On Wednesday 13 February 2008, Greg KH wrote:
On Wed, Feb 13, 2008 at 09:28:24AM -0800, Greg KH wrote:
On Wed, Feb 13, 2008 at 01:34:12PM +0100, Bartlomiej Zolnierkiewicz wrote:
On Wednesday 13 February 2008, Greg KH wrote:
On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox wrote:
Why does the calgary driver need this? Can we just use
pci_get_device()
instead? Why do you need to walk the device list backwards? Do
you get
false positives going forward?
It doesn't look to be performance critical so the driver can
pci_get_device until the end and use the final hit anyway.
That would make more sense.
IDE reverse is more problematic but nobody seems to use it.
I've seen two posters say they use it. I'm wondering what it is really
solving if they use it, and why if it's really needed, scsi never had to
implement such a hack...
It is no longer solving anything, just adds more pain. ;)
[ The option comes from 2.2.x (so long before LABEL=/ and /dev/disk/by-id/
became popular). Some off-board controllers integrated on
motherboards
used to appear before on-board IDE on PCI bus so this option was meant
to preserve the legacy ordering. ]
Since it is valid only when Probe IDE PCI devices in the PCI bus order
(DEPRECATED) config option is used it is already on its way out (though
marking it as obsoleted would make it more explicit).
I think that removing ide=reverse in 2.6.26 would be OK...
Great, thanks for your blessing. I'll make up a patch and send it to
you for approval.
How does the patch below look? I didn't want to remove the whole config
option, as there is more to the logic than just the reverse order
stuff there.
looks fine,
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
If you don't mind, can I take this through the PCI tree so as to allow
the removal of this pci function afterwards?
[...]
great, could you also:
- rebase it on top of the patch below
- forward the patch below to Linus for 2.6.25
?
From: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Subject: [PATCH] ide: mark ide=reverse option as obsolete
- it is valid only if Probe IDE PCI devices in the PCI bus order
(DEPRECATED) config option is used
- Greg needs to remove pci_get_device_reverse() for PCI core changes
Cc: Greg Kroah-Hartman [EMAIL PROTECTED]
Cc: Alan Cox [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ide/ide.c
===
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -1038,7 +1038,7 @@ static int __init ide_setup(char *s)
if (!strcmp(s, ide=reverse)) {
ide_scan_direction = 1;
printk( : Enabled support for IDE inverse scan order.\n);
- return 1;
+ goto obsolete_option;
}
#endif
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9962] New: 2.6.26-git0: IDE oops during boot
http://bugzilla.kernel.org/show_bug.cgi?id=9962 Summary: 2.6.26-git0: IDE oops during boot Product: IO/Storage Version: 2.5 KernelVersion: 2.6.25-git0 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: IDE AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] OtherBugsDependingO 9832 nThis: Regression: 1 Subject : 2.6.26-git0: IDE oops during boot Submitter : Kamalesh Babulal [EMAIL PROTECTED] Date: 2008-02-12 14:34 References : http://lkml.org/lkml/2008/2/12/91 Handled-By : Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] This entry is being used for tracking a regression from 2.6.24. Please don't close it until the problem is fixed in the mainline. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.26-git0: IDE oops during boot
Hi,
On Tuesday 12 February 2008, Kamalesh Babulal wrote:
Bartlomiej Zolnierkiewicz wrote:
Hi,
On Monday 11 February 2008, Kamalesh Babulal wrote:
Nish Aravamudan wrote:
On 2/7/08, Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:
On Thursday 07 February 2008, Kamalesh Babulal wrote:
Bartlomiej Zolnierkiewicz wrote:
Hi,
On Wednesday 06 February 2008, Pavel Machek wrote:
On Wed 2008-02-06 11:53:34, Pavel Machek wrote:
Hi!
Trying to boot 2.6.25-git0 (few days old), I get
BUG: unable to handle kernel paging request at ..ffb0
IP at init_irq+0x42e
init_irq? hmm...
Call trace:
ide_device_add_all
this comes from ide-generic
(Generic IDE host driver)
ide_generic_init
kernel_init
child_rip
vgacon_cursor
kernel_init
child_rip
Excerpt from config:
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
Disabling CONFIG_IDE made my machine boot, as it was using libata
anyway.
Kamalesh/Pavel:
Could you try latest git and see if the OOPS is still there?
[ Yeah, I'm unable to reproduce it. :( ]
Thanks,
Bart
Hi Bart,
The panic is reproducible with the 2.6.24-git16 kernel, the call trace
is
similar to the previous one
Thanks, I again reviewed ide-probe.c changes but nothing seems wrong...
Could you please bisect it down to the guilty commit?
Kamalesh, were you able to bisect this down? I just got hit by the
same panic on a 4-way x86_64, with 2.6.24-git22.
Thanks,
Nish
Hi Nish,
I tried bisecting and the guilty patch seems to be
36501650ec45b1db308c3b51886044863be2d762 is first bad commit
commit 36501650ec45b1db308c3b51886044863be2d762
Author: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Date: Fri Feb 1 23:09:31 2008 +0100
ide: keep pointer to struct device instead of struct pci_dev in
ide_hwif_t
the gdb output, also points to the changes made by the guilty patch
(gdb) p ide_device_add_all
$1 = {int (u8 *, const struct ide_port_info *)} 0x804176ac
ide_device_add_all
(gdb) p/x 0x804176ac+0xb60
$2 = 0x8041820c
(gdb) l *0x8041820c
0x8041820c is in ide_device_add_all (drivers/ide/ide-probe.c:1249).
1244goto out;
1245}
1246
1247sg_init_table(hwif-sg_table, hwif-sg_max_nents);
1248
1249if (init_irq(hwif) == 0)
1250goto done;
1251
1252old_irq = hwif-irq;
1253/*
(gdb)
(gdb) p init_irq
$1 = {int (ide_hwif_t *)} 0x8041721f init_irq
(gdb) p/x 0x8041721f+0x1a4
$2 = 0x804173c3
(gdb) l *0x804173c3
0x804173c3 is in init_irq (include/asm/pci.h:101).
96 /* Returns the node based on pci bus */
97 static inline int __pcibus_to_node(struct pci_bus *bus)
98 {
99 struct pci_sysdata *sd = bus-sysdata;
100
101 return sd-node;
102 }
103
104 static inline cpumask_t __pcibus_to_cpumask(struct pci_bus *bus)
105 {
(gdb)
Thanks for the detailed analysis and sorry for the bug.
I think that this may has been just fixed by Andi's recent hwif_to_node()
fix (patch below, it is in Linus' tree already), could please verify this?
commit 1f07e988290fc45932f5028c9e2a862c37a57336
Author: Andi Kleen [EMAIL PROTECTED]
Date: Mon Feb 11 01:35:20 2008 +0100
Prevent IDE boot ops on NUMA system
Without this patch a Opteron test system here oopses at boot with
current git.
Calling to_pci_dev() on a NULL pointer gives a negative value so the
following NULL pointer check never triggers and then an illegal address
is referenced. Check the unadjusted original device pointer for NULL
instead.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
diff --git a/include/linux/ide.h b/include/linux/ide.h
index 23fad89..a3b69c1 100644
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -1295,7 +1295,7 @@ static inline void ide_dump_identify(u8 *id)
static inline int hwif_to_node(ide_hwif_t *hwif)
{
struct pci_dev *dev = to_pci_dev(hwif-dev);
- return dev ? pcibus_to_node(dev-bus) : -1;
+ return hwif-dev ? pcibus_to_node(dev-bus) : -1;
}
static inline ide_drive_t *ide_get_paired_drive(ide_drive_t *drive)
Hi Bart,
Thanks !! the patch solves the kernel panic but when after applying the
patch,kernel is not
able to mount the filesystem and panics, am i not sure what is likely causing
the panic.
Is
- the commit 36501650ec45b1db308c3b51886044863be2d762 with Andi's fix applied
or
- the commit f6fb786d6dcdd7d730e4fba620b071796f487e1b
(the one before commit 36501650ec45b1db308c3b51886044863be2d762)
working for you?
Creating root device.
Mounting root filesystem.
mount: could not find filesystem
Kernel panic - not syncing: Attempted to kill init!
Is
[Bug 9962] 2.6.26-git0: IDE oops during boot
http://bugzilla.kernel.org/show_bug.cgi?id=9962 --- Comment #2 from [EMAIL PROTECTED] 2008-02-13 15:02 --- As stated above, the Bugzilla entry is for tracking the regression. If you think it should be reassigned, please let me know and I'll do that. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9962] 2.6.26-git0: IDE oops during boot
http://bugzilla.kernel.org/show_bug.cgi?id=9962 --- Comment #1 from [EMAIL PROTECTED] 2008-02-13 14:38 --- What makes you think that it is actually an IDE problem? The initial problem (which Andi fixed) was with *ide_generic* oopsing and could be just work-arounded by disabling ide_generic (like reported by Pavel). Asking Kamalesh to provide dmesg output instead would be far more useful than opening this bugzilla entry... -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ide=reverse do we still need this?
On Wed, 2008-02-13 at 13:46 +0100, Rene Herman wrote: On 13-02-08 13:16, Michael Ellerman wrote: On Wed, 2008-02-13 at 13:06 +0100, Rene Herman wrote: On 13-02-08 05:44, Greg KH wrote: While details escape me somewhat again at the monment, a few months ago I was playing around with a PCI Promise IDE controller and needed ide=reverse to save me from having to switch disks around to still have a bootable system. Or some such. Not too clear anymore, but I remember it saved the day. You couldn't just change the boot disk in grub? Or use an initramfs and /dev/disk/by-id/ to keep any future moves stable? No. The thing is that you need these kinds of hacks while messing with old systems, building and stripping them, often in recovery type of situations. As said (same as the other person I saw reacting) details of what was most decidedly needed last time around escape me at the moment, but ide=reverse is the kind of hack that saves one hours of unscrewing computer cases and switching disks around while building stuff, making quick tests, doing recovery... If it must go for the greater architectural good, so be it, but it's the type of thing that's used specifically in the situations where you don't have stable, well arranged (or known!) setups to begin with. I might be off the deep end, but isn't this what Documentation/feature-removal-schedule.txt is for? Documentation/feature-removal-schedule.txt is for asking/discussing whether or not features should be removed? No, I don't think so. It seems to be a schedule of when to remove features. Well it's sort of both I think. It's a schedule, but if enough people complain that something's being removed then it can be reconsidered before it's removed. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part
Re: [PATCH] SCSI: fix data corruption caused by ses
On Tue, 2008-02-12 at 23:10 -0800, Yinghai Lu wrote:
if (type_ptr[0] != ENCLOSURE_COMPONENT_DEVICE
type_ptr[0] != ENCLOSURE_COMPONENT_ARRAY_DEVICE)
- continue;
+ goto next;
+
ecomp = enclosure_component_register(edev,
components++,
type_ptr[0],
name);
+
+ if (desc_ptr !IS_ERR(ecomp) addl_desc_ptr)
+ ses_process_descriptor(ecomp,
+addl_desc_ptr);
+ next:
if (desc_ptr) {
desc_ptr += len;
- if (!IS_ERR(ecomp))
- ses_process_descriptor(ecomp,
-addl_desc_ptr);
if (addl_desc_ptr)
addl_desc_ptr += addl_desc_ptr[1] + 2;
Everything looks fine, thanks, except this piece.
That
if (x)
goto next;
...
next:
Needs to be
if (!x) {
...
}
I've fixed it up below. (I suppose the same thing goes for the
no_page10: label as well).
James
---
From: Yinghai Lu [EMAIL PROTECTED]
Date: Tue, 12 Feb 2008 23:10:22 -0800
Subject: [SCSI] ses: fix data corruption
one system: initrd get courrupted:
RAMDISK: Compressed image found at block 0
RAMDISK: incomplete write (-28 != 2048) 134217728
crc error
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 388k freed
init_special_inode: bogus i_mode (17)
Warning: unable to open an initial console.
init_special_inode: bogus i_mode (17)
init_special_inode: bogus i_mode (17)
Kernel panic - not syncing: No init found. Try passing init= option to kernel.
bisected to
commit 9927c68864e9c39cc317b4f559309ba29e642168
Author: James Bottomley [EMAIL PROTECTED]
Date: Sun Feb 3 15:48:56 2008 -0600
[SCSI] ses: add new Enclosure ULD
changes:
1. change char to unsigned char to avoid type change later.
2. preserve len for page1
3. need to move desc_ptr even the entry is not
enclosure_component_device/raid. so keep desc_ptr on right
position
4. also record page7 len, and double check if desc_ptr out of boundary
before touch.
Signed-off-by: Yinghai Lu [EMAIL PROTECTED]
Signed-off-by: James Bottomley [EMAIL PROTECTED]
---
drivers/scsi/ses.c | 75 ---
1 files changed, 41 insertions(+), 34 deletions(-)
diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
index a57fed4..614879e 100644
--- a/drivers/scsi/ses.c
+++ b/drivers/scsi/ses.c
@@ -33,9 +33,9 @@
#include scsi/scsi_host.h
struct ses_device {
- char *page1;
- char *page2;
- char *page10;
+ unsigned char *page1;
+ unsigned char *page2;
+ unsigned char *page10;
short page1_len;
short page2_len;
short page10_len;
@@ -67,7 +67,7 @@ static int ses_probe(struct device *dev)
static int ses_recv_diag(struct scsi_device *sdev, int page_code,
void *buf, int bufflen)
{
- char cmd[] = {
+ unsigned char cmd[] = {
RECEIVE_DIAGNOSTIC,
1, /* Set PCV bit */
page_code,
@@ -85,7 +85,7 @@ static int ses_send_diag(struct scsi_device *sdev, int
page_code,
{
u32 result;
- char cmd[] = {
+ unsigned char cmd[] = {
SEND_DIAGNOSTIC,
0x10, /* Set PF bit */
0,
@@ -104,13 +104,13 @@ static int ses_send_diag(struct scsi_device *sdev, int
page_code,
static int ses_set_page2_descriptor(struct enclosure_device *edev,
struct enclosure_component *ecomp,
- char *desc)
+ unsigned char *desc)
{
int i, j, count = 0, descriptor = ecomp-number;
struct scsi_device *sdev = to_scsi_device(edev-cdev.dev);
struct ses_device *ses_dev = edev-scratch;
- char *type_ptr = ses_dev-page1 + 12 + ses_dev-page1[11];
- char *desc_ptr = ses_dev-page2 + 8;
+ unsigned char *type_ptr = ses_dev-page1 + 12 + ses_dev-page1[11];
+ unsigned char *desc_ptr = ses_dev-page2 + 8;
/* Clear everything */
memset(desc_ptr, 0, ses_dev-page2_len - 8);
@@ -133,14 +133,14 @@ static int ses_set_page2_descriptor(struct
enclosure_device *edev,
return ses_send_diag(sdev, 2, ses_dev-page2, ses_dev-page2_len);
}
-static char *ses_get_page2_descriptor(struct enclosure_device *edev,
+static unsigned char *ses_get_page2_descriptor(struct enclosure_device *edev,
struct enclosure_component
Re: IDE cdrom problem with PLEXTOR DVDR PX-608AL
Am Dienstag, 12. Februar 2008 schrieb Borislav Petkov: On Tue, Feb 12, 2008 at 10:26:17AM +0100, Hans-Peter Jansen wrote: Hi, I suffer from unreliable cdrom operations (failing DAE and burn sessions) with the openSUSE 2.6.18.8-0.7-bigsmp kernel. Hi, can please you test this with a more recent kernel. Yours is almost ancient - from Sep. 2006. Sure, sorry. Here we go: Feb 14 00:18:18 kernel: hde: cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to recover by ending request. Feb 14 00:27:27 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to recover by ending request. ~ uname -a Linux xrated 2.6.24.1-35-pae #1 SMP 2008/02/12 01:00:18 UTC i686 athlon i386 GNU/Linux Thanks for caring, Pete - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pci_get_device_reverse(), why does Calgary need this?
On Wed, Feb 13, 2008 at 11:20:36PM +0100, Bartlomiej Zolnierkiewicz wrote: On Wednesday 13 February 2008, Greg KH wrote: On Wed, Feb 13, 2008 at 09:28:24AM -0800, Greg KH wrote: On Wed, Feb 13, 2008 at 01:34:12PM +0100, Bartlomiej Zolnierkiewicz wrote: On Wednesday 13 February 2008, Greg KH wrote: On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox wrote: Why does the calgary driver need this? Can we just use pci_get_device() instead? Why do you need to walk the device list backwards? Do you get false positives going forward? It doesn't look to be performance critical so the driver can pci_get_device until the end and use the final hit anyway. That would make more sense. IDE reverse is more problematic but nobody seems to use it. I've seen two posters say they use it. I'm wondering what it is really solving if they use it, and why if it's really needed, scsi never had to implement such a hack... It is no longer solving anything, just adds more pain. ;) [ The option comes from 2.2.x (so long before LABEL=/ and /dev/disk/by-id/ became popular). Some off-board controllers integrated on motherboards used to appear before on-board IDE on PCI bus so this option was meant to preserve the legacy ordering. ] Since it is valid only when Probe IDE PCI devices in the PCI bus order (DEPRECATED) config option is used it is already on its way out (though marking it as obsoleted would make it more explicit). I think that removing ide=reverse in 2.6.26 would be OK... Great, thanks for your blessing. I'll make up a patch and send it to you for approval. How does the patch below look? I didn't want to remove the whole config option, as there is more to the logic than just the reverse order stuff there. looks fine, Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] Thanks. If you don't mind, can I take this through the PCI tree so as to allow the removal of this pci function afterwards? [...] great, could you also: - rebase it on top of the patch below - forward the patch below to Linus for 2.6.25 Sure, you want this to go in for .25, but not the one I just posted removing this option, correct? That should wait for .26? thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pci_get_device_reverse(), why does Calgary need this?
On Thursday 14 February 2008, Greg KH wrote: On Wed, Feb 13, 2008 at 11:20:36PM +0100, Bartlomiej Zolnierkiewicz wrote: On Wednesday 13 February 2008, Greg KH wrote: On Wed, Feb 13, 2008 at 09:28:24AM -0800, Greg KH wrote: On Wed, Feb 13, 2008 at 01:34:12PM +0100, Bartlomiej Zolnierkiewicz wrote: On Wednesday 13 February 2008, Greg KH wrote: On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox wrote: Why does the calgary driver need this? Can we just use pci_get_device() instead? Why do you need to walk the device list backwards? Do you get false positives going forward? It doesn't look to be performance critical so the driver can pci_get_device until the end and use the final hit anyway. That would make more sense. IDE reverse is more problematic but nobody seems to use it. I've seen two posters say they use it. I'm wondering what it is really solving if they use it, and why if it's really needed, scsi never had to implement such a hack... It is no longer solving anything, just adds more pain. ;) [ The option comes from 2.2.x (so long before LABEL=/ and /dev/disk/by-id/ became popular). Some off-board controllers integrated on motherboards used to appear before on-board IDE on PCI bus so this option was meant to preserve the legacy ordering. ] Since it is valid only when Probe IDE PCI devices in the PCI bus order (DEPRECATED) config option is used it is already on its way out (though marking it as obsoleted would make it more explicit). I think that removing ide=reverse in 2.6.26 would be OK... Great, thanks for your blessing. I'll make up a patch and send it to you for approval. How does the patch below look? I didn't want to remove the whole config option, as there is more to the logic than just the reverse order stuff there. looks fine, Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] Thanks. If you don't mind, can I take this through the PCI tree so as to allow the removal of this pci function afterwards? [...] great, could you also: - rebase it on top of the patch below - forward the patch below to Linus for 2.6.25 Sure, you want this to go in for .25, but not the one I just posted removing this option, correct? That should wait for .26? Yes, lets give people the final call before actually removing this option (unless of course there is some urgent reason for removing it in .25). Thanks, Bart - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET] printk: implement printk_header() and merging printk, take #3
On Wed, 13 Feb 2008 18:09:28 +0900 Tejun Heo [EMAIL PROTECTED] wrote: This is the third take of implement-printk_header-and-mprintk patchset. Changes from the last take[L] are... * Now header is printed on every line of a multiline message. If the header ends with ':' followed by spaces. The colon is replaced with space from the second line. * s/mprintk/mprintk_flush/ and s/mprintk_add/mprintk/ as suggested. * mprintk_init_alloc() and mprintk_free() added to ease malloc'd buffer handling. No need to specify buffer size. Sizing is left to mprintk. This patchset aims to make printing multiline messages and assembling message piece-by-piece easier. In a nutshell, printk_header() lets you do the following atomically (against other messages). code: printk(KERN_INFO ata1.00: , line0\nline1\nline2\n); output: 6ata1.00: line0 6ata1.00 line1 6ata1.00 line2 That seems sensible. And mprintk the following. code: DEFINE_MPRINTK(mp, 2 * 80); mprintk_set_header(mp, KERN_INFO ata%u.%2u: , 1, 0); mprintk_push(mp, ATA %d, 7); mprintk_push(mp, , %u sectors\n, 1024); mprintk(mp, everything seems dandy\n); output: 6ata1.00: ATA 7, 1024 sectors 6ata1.00 everything seems dandy And that looks like an awful lot of fuss. Is it really worth doing? - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9962] 2.6.26-git0: IDE oops during boot
http://bugzilla.kernel.org/show_bug.cgi?id=9962 --- Comment #3 from [EMAIL PROTECTED] 2008-02-13 15:58 --- Yes, it should be reassigned to under investigation department. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] SCSI: fix data corruption caused by ses v2
one system: initrd get courrupted:
RAMDISK: Compressed image found at block 0
RAMDISK: incomplete write (-28 != 2048) 134217728
crc error
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 388k freed
init_special_inode: bogus i_mode (17)
Warning: unable to open an initial console.
init_special_inode: bogus i_mode (17)
init_special_inode: bogus i_mode (17)
Kernel panic - not syncing: No init found. Try passing init= option to kernel.
bisected to
commit 9927c68864e9c39cc317b4f559309ba29e642168
Author: James Bottomley [EMAIL PROTECTED]
Date: Sun Feb 3 15:48:56 2008 -0600
[SCSI] ses: add new Enclosure ULD
changes:
1. change char to unsigned char to avoid type change later.
2. preserve len for page1
3. need to move desc_ptr even the entry is not enclosure_component_device/raid.
so keep desc_ptr on right position
4. record page7 len, and double check if desc_ptr out of boundary before touch.
5. fix typo in subenclosure checking: should use hdr_buf instead.
Signed-off-by: Yinghai Lu [EMAIL PROTECTED]
Index: linux-2.6/drivers/scsi/ses.c
===
--- linux-2.6.orig/drivers/scsi/ses.c
+++ linux-2.6/drivers/scsi/ses.c
@@ -33,9 +33,9 @@
#include scsi/scsi_host.h
struct ses_device {
- char *page1;
- char *page2;
- char *page10;
+ unsigned char *page1;
+ unsigned char *page2;
+ unsigned char *page10;
short page1_len;
short page2_len;
short page10_len;
@@ -67,7 +66,7 @@ static int ses_probe(struct device *dev)
static int ses_recv_diag(struct scsi_device *sdev, int page_code,
void *buf, int bufflen)
{
- char cmd[] = {
+ unsigned char cmd[] = {
RECEIVE_DIAGNOSTIC,
1, /* Set PCV bit */
page_code,
@@ -85,7 +84,7 @@ static int ses_send_diag(struct scsi_dev
{
u32 result;
- char cmd[] = {
+ unsigned char cmd[] = {
SEND_DIAGNOSTIC,
0x10, /* Set PF bit */
0,
@@ -104,13 +103,13 @@ static int ses_send_diag(struct scsi_dev
static int ses_set_page2_descriptor(struct enclosure_device *edev,
struct enclosure_component *ecomp,
- char *desc)
+ unsigned char *desc)
{
int i, j, count = 0, descriptor = ecomp-number;
struct scsi_device *sdev = to_scsi_device(edev-cdev.dev);
struct ses_device *ses_dev = edev-scratch;
- char *type_ptr = ses_dev-page1 + 12 + ses_dev-page1[11];
- char *desc_ptr = ses_dev-page2 + 8;
+ unsigned char *type_ptr = ses_dev-page1 + 12 + ses_dev-page1[11];
+ unsigned char *desc_ptr = ses_dev-page2 + 8;
/* Clear everything */
memset(desc_ptr, 0, ses_dev-page2_len - 8);
@@ -133,14 +132,14 @@ static int ses_set_page2_descriptor(stru
return ses_send_diag(sdev, 2, ses_dev-page2, ses_dev-page2_len);
}
-static char *ses_get_page2_descriptor(struct enclosure_device *edev,
+static unsigned char *ses_get_page2_descriptor(struct enclosure_device *edev,
struct enclosure_component *ecomp)
{
int i, j, count = 0, descriptor = ecomp-number;
struct scsi_device *sdev = to_scsi_device(edev-cdev.dev);
struct ses_device *ses_dev = edev-scratch;
- char *type_ptr = ses_dev-page1 + 12 + ses_dev-page1[11];
- char *desc_ptr = ses_dev-page2 + 8;
+ unsigned char *type_ptr = ses_dev-page1 + 12 + ses_dev-page1[11];
+ unsigned char *desc_ptr = ses_dev-page2 + 8;
ses_recv_diag(sdev, 2, ses_dev-page2, ses_dev-page2_len);
@@ -160,17 +159,18 @@ static char *ses_get_page2_descriptor(st
static void ses_get_fault(struct enclosure_device *edev,
struct enclosure_component *ecomp)
{
- char *desc;
+ unsigned char *desc;
desc = ses_get_page2_descriptor(edev, ecomp);
- ecomp-fault = (desc[3] 0x60) 4;
+ if (desc)
+ ecomp-fault = (desc[3] 0x60) 4;
}
static int ses_set_fault(struct enclosure_device *edev,
struct enclosure_component *ecomp,
enum enclosure_component_setting val)
{
- char desc[4] = {0 };
+ unsigned char desc[4] = {0 };
switch (val) {
case ENCLOSURE_SETTING_DISABLED:
@@ -190,26 +190,28 @@ static int ses_set_fault(struct enclosur
static void ses_get_status(struct enclosure_device *edev,
struct enclosure_component *ecomp)
{
- char *desc;
+ unsigned char *desc;
desc = ses_get_page2_descriptor(edev, ecomp);
- ecomp-status = (desc[0] 0x0f);
+ if (desc)
+ ecomp-status = (desc[0] 0x0f);
}
static void ses_get_locate(struct enclosure_device *edev,
struct
Re: [PATCH #upstream] libata: implement libata.force module parameter
Mark Lord wrote: Tejun Heo wrote: This patch implements libata.force module parameter which can selectively override ATA port, link and device configurations including cable type, SATA PHY SPD limit, transfer mode and NCQ. ... +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 .. Mmm.. not a NAK, but is there also a way to set/change these on the fly? What do you mean by 'on the fly'? While the system is running? If so, I think that should be done through other interfaces - pass through, sysfs, etc... I ask because, on my 4-core test system here, libata enumerates the ports differently depending upon whether I boot with a 32-bit kernel or a 64-bit kernel. Major PITA, that, and it's just the kind of thing that spoils fixed PORT:DEVICE module parameters, too. Now mind you, it's more likely the PCI layer that does the reverse order thing, but the end result is that my drives/ports are numbered differently depending upon which kernel I happen to boot with. Heck... That's ugly. libata.force is mainly conceived as debugging / installation helper, so using fixed PORT is good enough but maybe allowing bus_id as PORT is useful? Something like [00:1f.2]:00? -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/11] ide/ppc: remove PPC specific IDE hacks
Previous patchset adding warm-plug support allows the removal of PPC specific IDE hacks (500 LOC gone)... [ Ben, please take a look when you have some time, thanks! ] diffstat: arch/powerpc/kernel/setup_32.c |8 -- arch/powerpc/platforms/powermac/pci.c | 22 --- arch/powerpc/platforms/powermac/pmac.h |5 - arch/powerpc/platforms/powermac/setup.c |8 -- arch/ppc/configs/sandpoint_defconfig|2 arch/ppc/kernel/ppc_ksyms.c |5 - arch/ppc/kernel/setup.c |2 arch/ppc/platforms/4xx/bamboo.c |1 arch/ppc/platforms/4xx/ebony.c |1 arch/ppc/platforms/4xx/luan.c |1 arch/ppc/platforms/4xx/ocotea.c |1 arch/ppc/platforms/4xx/taishan.c|1 arch/ppc/platforms/4xx/yucca.c |1 arch/ppc/platforms/chestnut.c |1 arch/ppc/platforms/cpci690.c|1 arch/ppc/platforms/ev64260.c|1 arch/ppc/platforms/hdpu.c | 36 --- arch/ppc/platforms/lopec.c | 85 arch/ppc/platforms/mvme5100.c |1 arch/ppc/platforms/powerpmc250.c|1 arch/ppc/platforms/pplus.c | 58 --- arch/ppc/platforms/prep_setup.c | 38 arch/ppc/platforms/prpmc750.c |1 arch/ppc/platforms/prpmc800.c |1 arch/ppc/platforms/radstone_ppc7d.c |1 arch/ppc/platforms/residual.c |1 arch/ppc/platforms/sandpoint.c | 94 --- arch/ppc/platforms/sandpoint.h |3 arch/ppc/platforms/spruce.c |1 arch/ppc/syslib/m8xx_setup.c|6 - arch/ppc/syslib/ppc4xx_setup.c | 23 --- drivers/ide/ide.c |6 - drivers/ide/pci/sl82c105.c |6 + drivers/ide/ppc/mpc8xx.c| 86 +++- drivers/ide/ppc/pmac.c | 97 +++- include/asm-powerpc/ide.h | 47 ++- 36 files changed, 72 insertions(+), 581 deletions(-) - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/11] ide-pmac: remove dead code
Remove unused pmac_ide_{check_base,get_irq}() and pmac_find_ide_boot(),
then remove no longer needed ide_majors[] and pmac_ide_count.
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ppc/pmac.c | 47 ---
1 file changed, 47 deletions(-)
Index: b/drivers/ide/ppc/pmac.c
===
--- a/drivers/ide/ppc/pmac.c
+++ b/drivers/ide/ppc/pmac.c
@@ -80,7 +80,6 @@ typedef struct pmac_ide_hwif {
} pmac_ide_hwif_t;
static pmac_ide_hwif_t pmac_ide[MAX_HWIFS];
-static int pmac_ide_count;
enum {
controller_ohare, /* OHare based */
@@ -893,52 +892,6 @@ pmac_ide_get_base(int index)
return pmac_ide[index].regbase;
}
-int
-pmac_ide_check_base(unsigned long base)
-{
- int ix;
-
- for (ix = 0; ix MAX_HWIFS; ++ix)
- if (base == pmac_ide[ix].regbase)
- return ix;
- return -1;
-}
-
-int
-pmac_ide_get_irq(unsigned long base)
-{
- int ix;
-
- for (ix = 0; ix MAX_HWIFS; ++ix)
- if (base == pmac_ide[ix].regbase)
- return pmac_ide[ix].irq;
- return 0;
-}
-
-static int ide_majors[] = { 3, 22, 33, 34, 56, 57 };
-
-dev_t __init
-pmac_find_ide_boot(char *bootdevice, int n)
-{
- int i;
-
- /*
-* Look through the list of IDE interfaces for this one.
-*/
- for (i = 0; i pmac_ide_count; ++i) {
- char *name;
- if (!pmac_ide[i].node || !pmac_ide[i].node-full_name)
- continue;
- name = pmac_ide[i].node-full_name;
- if (memcmp(name, bootdevice, n) == 0 name[n] == 0) {
- /* XXX should cope with the 2nd drive as well... */
- return MKDEV(ide_majors[i], 0);
- }
- }
-
- return 0;
-}
-
/* Suspend call back, should be called after the child devices
* have actually been suspended
*/
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/11] ppc/hdpu: remove dead IDE code
Also remove now not needed linux/ide.h include.
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
arch/ppc/platforms/hdpu.c | 36
1 file changed, 36 deletions(-)
Index: b/arch/ppc/platforms/hdpu.c
===
--- a/arch/ppc/platforms/hdpu.c
+++ b/arch/ppc/platforms/hdpu.c
@@ -16,7 +16,6 @@
#include linux/pci.h
#include linux/delay.h
#include linux/irq.h
-#include linux/ide.h
#include linux/seq_file.h
#include linux/platform_device.h
@@ -604,41 +603,6 @@ static void parse_bootinfo(unsigned long
}
}
-#if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE)
-static void
-hdpu_ide_request_region(ide_ioreg_t from, unsigned int extent, const char
*name)
-{
- request_region(from, extent, name);
- return;
-}
-
-static void hdpu_ide_release_region(ide_ioreg_t from, unsigned int extent)
-{
- release_region(from, extent);
- return;
-}
-
-static void __init
-hdpu_ide_pci_init_hwif_ports(hw_regs_t * hw, ide_ioreg_t data_port,
-ide_ioreg_t ctrl_port, int *irq)
-{
- struct pci_dev *dev;
-
- pci_for_each_dev(dev) {
- if (((dev-class 8) == PCI_CLASS_STORAGE_IDE) ||
- ((dev-class 8) == PCI_CLASS_STORAGE_RAID)) {
- hw-irq = dev-irq;
-
- if (irq != NULL) {
- *irq = dev-irq;
- }
- }
- }
-
- return;
-}
-#endif
-
void hdpu_heartbeat(void)
{
if (mv64x60_read(bh, MV64x60_GPP_VALUE) (1 5))
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/11] ppc/ppc4xx: remove ppc_ide_md hooks
There are no default IDE ports on PPC4xx so ppc4xx_ide_init_hwif_ports() is
unnecessary, remove it. Also remove no longer needed linux/ide.h include.
There should be no functional changes caused by this patch.
Cc: Josh Boyer [EMAIL PROTECTED]
Cc: Matt Porter [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
arch/ppc/syslib/ppc4xx_setup.c | 23 ---
1 file changed, 23 deletions(-)
Index: b/arch/ppc/syslib/ppc4xx_setup.c
===
--- a/arch/ppc/syslib/ppc4xx_setup.c
+++ b/arch/ppc/syslib/ppc4xx_setup.c
@@ -24,7 +24,6 @@
#include linux/pci.h
#include linux/rtc.h
#include linux/console.h
-#include linux/ide.h
#include linux/serial_reg.h
#include linux/seq_file.h
@@ -189,24 +188,6 @@ ppc4xx_calibrate_decr(void)
mtspr(SPRN_PIT, tb_ticks_per_jiffy);
}
-/*
- * IDE stuff.
- * should be generic for every IDE PCI chipset
- */
-#if defined(CONFIG_PCI) defined(CONFIG_IDE)
-static void
-ppc4xx_ide_init_hwif_ports(hw_regs_t * hw, unsigned long data_port,
- unsigned long ctrl_port, int *irq)
-{
- int i;
-
- for (i = IDE_DATA_OFFSET; i = IDE_STATUS_OFFSET; ++i)
- hw-io_ports[i] = data_port + i - IDE_DATA_OFFSET;
-
- hw-io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
-}
-#endif /* defined(CONFIG_PCI) defined(CONFIG_IDE) */
-
TODC_ALLOC();
/*
@@ -271,10 +252,6 @@ ppc4xx_init(unsigned long r3, unsigned l
#ifdef CONFIG_SERIAL_TEXT_DEBUG
ppc_md.progress = gen550_progress;
#endif
-
-#if defined(CONFIG_PCI) defined(CONFIG_IDE)
- ppc_ide_md.ide_init_hwif = ppc4xx_ide_init_hwif_ports;
-#endif /* defined(CONFIG_PCI) defined(CONFIG_IDE) */
}
/* Called from machine_check_exception */
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/11] ppc/pmac: remove ppc_ide_md hooks
* Add pmac_ide_init_ports() helper and use it instead of
pmac_ide_init_hwif_ports().
* Remove ppc_ide_md hooks - no need for them
(IDE pmac host driver takes care of all this setup).
* Then remove no longer needed linux/ide.h include
from arch/powerpc/platforms/powermac/pmac.h.
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
arch/powerpc/platforms/powermac/pmac.h |5 ---
arch/powerpc/platforms/powermac/setup.c |8 -
drivers/ide/ppc/pmac.c | 50 +++-
3 files changed, 11 insertions(+), 52 deletions(-)
Index: b/arch/powerpc/platforms/powermac/pmac.h
===
--- a/arch/powerpc/platforms/powermac/pmac.h
+++ b/arch/powerpc/platforms/powermac/pmac.h
@@ -2,7 +2,6 @@
#define __PMAC_H__
#include linux/pci.h
-#include linux/ide.h
#include linux/irq.h
/*
@@ -35,10 +34,6 @@ extern void pmac_check_ht_link(void);
extern void pmac_setup_smp(void);
-extern unsigned long pmac_ide_get_base(int index);
-extern void pmac_ide_init_hwif_ports(hw_regs_t *hw,
- unsigned long data_port, unsigned long ctrl_port, int *irq);
-
extern int pmac_nvram_init(void);
extern void pmac_pic_init(void);
Index: b/arch/powerpc/platforms/powermac/setup.c
===
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -574,14 +574,6 @@ static int __init pmac_probe(void)
ISA_DMA_THRESHOLD = ~0L;
DMA_MODE_READ = 1;
DMA_MODE_WRITE = 2;
-
-#if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE)
-#ifdef CONFIG_BLK_DEV_IDE_PMAC
-ppc_ide_md.ide_init_hwif = pmac_ide_init_hwif_ports;
-ppc_ide_md.default_io_base = pmac_ide_get_base;
-#endif /* CONFIG_BLK_DEV_IDE_PMAC */
-#endif /* defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE) */
-
#endif /* CONFIG_PPC32 */
#ifdef CONFIG_PMAC_SMU
Index: b/drivers/ide/ppc/pmac.c
===
--- a/drivers/ide/ppc/pmac.c
+++ b/drivers/ide/ppc/pmac.c
@@ -418,37 +418,6 @@ static void pmac_ide_kauai_selectproc(id
#endif /* CONFIG_BLK_DEV_IDEDMA_PMAC */
-/*
- * N.B. this can't be an initfunc, because the media-bay task can
- * call ide_[un]register at any time.
- */
-void
-pmac_ide_init_hwif_ports(hw_regs_t *hw,
- unsigned long data_port, unsigned long ctrl_port,
- int *irq)
-{
- int i, ix;
-
- if (data_port == 0)
- return;
-
- for (ix = 0; ix MAX_HWIFS; ++ix)
- if (data_port == pmac_ide[ix].regbase)
- break;
-
- if (ix = MAX_HWIFS)
- return; /* not an IDE PMAC interface */
-
- for (i = 0; i 8; ++i)
- hw-io_ports[i] = data_port + i * 0x10;
- hw-io_ports[8] = data_port + 0x160;
-
- if (irq != NULL)
- *irq = pmac_ide[ix].irq;
-
- hw-dev = pmac_ide[ix].mdev-ofdev.dev;
-}
-
#define PMAC_IDE_REG(x) \
((void __iomem *)((drive)-hwif-io_ports[IDE_DATA_OFFSET] + (x)))
@@ -886,12 +855,6 @@ sanitize_timings(pmac_ide_hwif_t *pmif)
pmif-timings[2] = pmif-timings[3] = value2;
}
-unsigned long
-pmac_ide_get_base(int index)
-{
- return pmac_ide[index].regbase;
-}
-
/* Suspend call back, should be called after the child devices
* have actually been suspended
*/
@@ -1108,6 +1071,15 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
return 0;
}
+static void __devinit pmac_ide_init_ports(hw_regs_t *hw, unsigned long base)
+{
+ int i;
+
+ for (i = 0; i 8; ++i)
+ hw-io_ports[i] = base + i * 0x10;
+ hw-io_ports[8] = base + 0x160;
+}
+
/*
* Attach to a macio probed interface
*/
@@ -1181,7 +1153,7 @@ pmac_ide_macio_attach(struct macio_dev *
dev_set_drvdata(mdev-ofdev.dev, hwif);
memset(hw, 0, sizeof(hw));
- pmac_ide_init_hwif_ports(hw, pmif-regbase, 0, NULL);
+ pmac_ide_init_ports(hw, pmif-regbase);
hw.irq = irq;
hw.dev = mdev-ofdev.dev;
@@ -1295,7 +1267,7 @@ pmac_ide_pci_attach(struct pci_dev *pdev
pci_set_drvdata(pdev, hwif);
memset(hw, 0, sizeof(hw));
- pmac_ide_init_hwif_ports(hw, pmif-regbase, 0, NULL);
+ pmac_ide_init_ports(hw, pmif-regbase);
hw.irq = pdev-irq;
hw.dev = pdev-dev;
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/11] ppc: don't include linux/ide.h
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED] Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] --- arch/ppc/platforms/4xx/bamboo.c |1 - arch/ppc/platforms/4xx/ebony.c |1 - arch/ppc/platforms/4xx/luan.c |1 - arch/ppc/platforms/4xx/ocotea.c |1 - arch/ppc/platforms/4xx/taishan.c|1 - arch/ppc/platforms/4xx/yucca.c |1 - arch/ppc/platforms/chestnut.c |1 - arch/ppc/platforms/cpci690.c|1 - arch/ppc/platforms/ev64260.c|1 - arch/ppc/platforms/mvme5100.c |1 - arch/ppc/platforms/powerpmc250.c|1 - arch/ppc/platforms/prpmc750.c |1 - arch/ppc/platforms/prpmc800.c |1 - arch/ppc/platforms/radstone_ppc7d.c |1 - arch/ppc/platforms/residual.c |1 - arch/ppc/platforms/spruce.c |1 - 16 files changed, 16 deletions(-) Index: b/arch/ppc/platforms/4xx/bamboo.c === --- a/arch/ppc/platforms/4xx/bamboo.c +++ b/arch/ppc/platforms/4xx/bamboo.c @@ -22,7 +22,6 @@ #include linux/blkdev.h #include linux/console.h #include linux/delay.h -#include linux/ide.h #include linux/initrd.h #include linux/seq_file.h #include linux/root_dev.h Index: b/arch/ppc/platforms/4xx/ebony.c === --- a/arch/ppc/platforms/4xx/ebony.c +++ b/arch/ppc/platforms/4xx/ebony.c @@ -25,7 +25,6 @@ #include linux/blkdev.h #include linux/console.h #include linux/delay.h -#include linux/ide.h #include linux/initrd.h #include linux/seq_file.h #include linux/root_dev.h Index: b/arch/ppc/platforms/4xx/luan.c === --- a/arch/ppc/platforms/4xx/luan.c +++ b/arch/ppc/platforms/4xx/luan.c @@ -23,7 +23,6 @@ #include linux/blkdev.h #include linux/console.h #include linux/delay.h -#include linux/ide.h #include linux/initrd.h #include linux/seq_file.h #include linux/root_dev.h Index: b/arch/ppc/platforms/4xx/ocotea.c === --- a/arch/ppc/platforms/4xx/ocotea.c +++ b/arch/ppc/platforms/4xx/ocotea.c @@ -23,7 +23,6 @@ #include linux/blkdev.h #include linux/console.h #include linux/delay.h -#include linux/ide.h #include linux/initrd.h #include linux/seq_file.h #include linux/root_dev.h Index: b/arch/ppc/platforms/4xx/taishan.c === --- a/arch/ppc/platforms/4xx/taishan.c +++ b/arch/ppc/platforms/4xx/taishan.c @@ -23,7 +23,6 @@ #include linux/blkdev.h #include linux/console.h #include linux/delay.h -#include linux/ide.h #include linux/initrd.h #include linux/seq_file.h #include linux/root_dev.h Index: b/arch/ppc/platforms/4xx/yucca.c === --- a/arch/ppc/platforms/4xx/yucca.c +++ b/arch/ppc/platforms/4xx/yucca.c @@ -24,7 +24,6 @@ #include linux/blkdev.h #include linux/console.h #include linux/delay.h -#include linux/ide.h #include linux/initrd.h #include linux/seq_file.h #include linux/root_dev.h Index: b/arch/ppc/platforms/chestnut.c === --- a/arch/ppc/platforms/chestnut.c +++ b/arch/ppc/platforms/chestnut.c @@ -22,7 +22,6 @@ #include linux/initrd.h #include linux/delay.h #include linux/seq_file.h -#include linux/ide.h #include linux/serial.h #include linux/serial_core.h #include linux/serial_8250.h Index: b/arch/ppc/platforms/cpci690.c === --- a/arch/ppc/platforms/cpci690.c +++ b/arch/ppc/platforms/cpci690.c @@ -10,7 +10,6 @@ */ #include linux/delay.h #include linux/pci.h -#include linux/ide.h #include linux/irq.h #include linux/fs.h #include linux/seq_file.h Index: b/arch/ppc/platforms/ev64260.c === --- a/arch/ppc/platforms/ev64260.c +++ b/arch/ppc/platforms/ev64260.c @@ -23,7 +23,6 @@ #include linux/delay.h #include linux/pci.h -#include linux/ide.h #include linux/irq.h #include linux/fs.h #include linux/seq_file.h Index: b/arch/ppc/platforms/mvme5100.c === --- a/arch/ppc/platforms/mvme5100.c +++ b/arch/ppc/platforms/mvme5100.c @@ -17,7 +17,6 @@ #include linux/initrd.h #include linux/console.h #include linux/delay.h -#include linux/ide.h #include linux/seq_file.h #include linux/kdev_t.h #include linux/root_dev.h Index: b/arch/ppc/platforms/powerpmc250.c === --- a/arch/ppc/platforms/powerpmc250.c +++ b/arch/ppc/platforms/powerpmc250.c @@ -25,7 +25,6 @@ #include linux/delay.h #include linux/slab.h #include linux/seq_file.h -#include linux/ide.h #include linux/root_dev.h #include asm/byteorder.h Index: b/arch/ppc/platforms/prpmc750.c
[PATCH 09/11] ppc: remove ppc_ide_md
* Add special cases for pplus and prep to ide_default_{irq,io_base}()
(+ FIXMEs about the need to use IDE platform host driver instead).
* Remove no longer needed ppc_ide_md and struct ide_machdep_calls.
* Then remove linux/ide.h include from:
- arch/powerpc/kernel/setup_32.c
- arch/ppc/kernel/ppc_ksyms.c
- arch/ppc/kernel/setup.c
- arch/ppc/platforms/pplus.c
- arch/ppc/platforms/prep_setup.c
There should be no functional changes caused by this patch.
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
arch/powerpc/kernel/setup_32.c |8 --
arch/ppc/kernel/ppc_ksyms.c |5
arch/ppc/kernel/setup.c |2 -
arch/ppc/platforms/pplus.c | 35 -
arch/ppc/platforms/prep_setup.c | 38
drivers/ide/ide.c |4 ---
include/asm-powerpc/ide.h | 47 +++-
7 files changed, 32 insertions(+), 107 deletions(-)
Index: b/arch/powerpc/kernel/setup_32.c
===
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -10,9 +10,6 @@
#include linux/reboot.h
#include linux/delay.h
#include linux/initrd.h
-#if defined(CONFIG_IDE) || defined(CONFIG_IDE_MODULE)
-#include linux/ide.h
-#endif
#include linux/tty.h
#include linux/bootmem.h
#include linux/seq_file.h
@@ -51,11 +48,6 @@
extern void bootx_init(unsigned long r4, unsigned long phys);
-#if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE)
-struct ide_machdep_calls ppc_ide_md;
-EXPORT_SYMBOL(ppc_ide_md);
-#endif
-
int boot_cpuid;
EXPORT_SYMBOL_GPL(boot_cpuid);
int boot_cpuid_phys;
Index: b/arch/ppc/kernel/ppc_ksyms.c
===
--- a/arch/ppc/kernel/ppc_ksyms.c
+++ b/arch/ppc/kernel/ppc_ksyms.c
@@ -12,7 +12,6 @@
#include linux/irq.h
#include linux/pci.h
#include linux/delay.h
-#include linux/ide.h
#include linux/pm.h
#include linux/bitops.h
@@ -124,10 +123,6 @@ EXPORT_SYMBOL(__ioremap);
EXPORT_SYMBOL(iounmap);
EXPORT_SYMBOL(ioremap_bot);/* aka VMALLOC_END */
-#if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE)
-EXPORT_SYMBOL(ppc_ide_md);
-#endif
-
#ifdef CONFIG_PCI
EXPORT_SYMBOL(isa_io_base);
EXPORT_SYMBOL(isa_mem_base);
Index: b/arch/ppc/kernel/setup.c
===
--- a/arch/ppc/kernel/setup.c
+++ b/arch/ppc/kernel/setup.c
@@ -10,7 +10,6 @@
#include linux/reboot.h
#include linux/delay.h
#include linux/initrd.h
-#include linux/ide.h
#include linux/screen_info.h
#include linux/bootmem.h
#include linux/seq_file.h
@@ -57,7 +56,6 @@ extern void ppc6xx_idle(void);
extern void power4_idle(void);
extern boot_infos_t *boot_infos;
-struct ide_machdep_calls ppc_ide_md;
/* Used with the BI_MEMSIZE bootinfo parameter to store the memory
size value reported by the boot loader. */
Index: b/arch/ppc/platforms/pplus.c
===
--- a/arch/ppc/platforms/pplus.c
+++ b/arch/ppc/platforms/pplus.c
@@ -19,7 +19,6 @@
#include linux/ioport.h
#include linux/console.h
#include linux/pci.h
-#include linux/ide.h
#include linux/seq_file.h
#include linux/root_dev.h
@@ -668,35 +667,6 @@ static void __init pplus_init_IRQ(void)
ppc_md.progress(init_irq: exit, 0);
}
-#if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE)
-/*
- * IDE stuff.
- */
-static int pplus_ide_default_irq(unsigned long base)
-{
- switch (base) {
- case 0x1f0:
- return 14;
- case 0x170:
- return 15;
- default:
- return 0;
- }
-}
-
-static unsigned long pplus_ide_default_io_base(int index)
-{
- switch (index) {
- case 0:
- return 0x1f0;
- case 1:
- return 0x170;
- default:
- return 0;
- }
-}
-#endif
-
#ifdef CONFIG_SMP
/* PowerPlus (MTX) support */
static int __init smp_pplus_probe(void)
@@ -862,11 +832,6 @@ platform_init(unsigned long r3, unsigned
ppc_md.find_end_of_memory = pplus_find_end_of_memory;
ppc_md.setup_io_mappings = pplus_map_io;
-#if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE)
- ppc_ide_md.default_irq = pplus_ide_default_irq;
- ppc_ide_md.default_io_base = pplus_ide_default_io_base;
-#endif
-
#ifdef CONFIG_SERIAL_TEXT_DEBUG
ppc_md.progress = gen550_progress;
#endif /* CONFIG_SERIAL_TEXT_DEBUG */
Index: b/arch/ppc/platforms/prep_setup.c
===
--- a/arch/ppc/platforms/prep_setup.c
+++ b/arch/ppc/platforms/prep_setup.c
@@ -33,7 +33,6 @@
#include linux/console.h
#include linux/timex.h
#include linux/pci.h
-#include linux/ide.h
#include
[Bug 9962] mount: could not find filesystem
http://bugzilla.kernel.org/show_bug.cgi?id=9962 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] ||bugs.osdl.org -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/11] ppc/sandpoint: remove ppc_ide_md hooks
* Add IDE_HFLAG_FORCE_LEGACY_IRQS host flag for Motorola-Sandpoint platform
to sl82c105 host driver.
* Disable ide_generic host driver in arch/ppc/configs/sandpoint_defconfig
and enable sl82c105 one.
* Remove ppc_ide_md hooks from arch/ppc/platforms/sandpoint.c - no need for
them (sl82c105 host driver takes care of all this setup).
* Then remove no longer needed linux/ide.h include.
* Also update arch/ppc/platforms/sandpoint.h.
Unfortunately (unlike lopec's case) sl82c105 host driver was not enabled
in defconfing so there is a funcionality change.
[ Not a big deal since sl82c105 is superior over ide_generic. ]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
arch/ppc/configs/sandpoint_defconfig |2
arch/ppc/platforms/sandpoint.c | 94 ---
arch/ppc/platforms/sandpoint.h |3 -
drivers/ide/pci/sl82c105.c |2
4 files changed, 2 insertions(+), 99 deletions(-)
Index: b/arch/ppc/configs/sandpoint_defconfig
===
--- a/arch/ppc/configs/sandpoint_defconfig
+++ b/arch/ppc/configs/sandpoint_defconfig
@@ -189,7 +189,7 @@ CONFIG_IDE_TASKFILE_IO=y
#
# IDE chipset support/bugfixes
#
-CONFIG_IDE_GENERIC=y
+CONFIG_BLK_DEV_SL82C105=y
# CONFIG_BLK_DEV_IDEPCI is not set
# CONFIG_BLK_DEV_IDEDMA is not set
# CONFIG_IDEDMA_AUTO is not set
Index: b/arch/ppc/platforms/sandpoint.c
===
--- a/arch/ppc/platforms/sandpoint.c
+++ b/arch/ppc/platforms/sandpoint.c
@@ -71,7 +71,6 @@
#include linux/initrd.h
#include linux/console.h
#include linux/delay.h
-#include linux/ide.h
#include linux/seq_file.h
#include linux/root_dev.h
#include linux/serial.h
@@ -559,93 +558,6 @@ sandpoint_show_cpuinfo(struct seq_file *
return 0;
}
-#if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE)
-/*
- * IDE support.
- */
-static int sandpoint_ide_ports_known = 0;
-static unsigned long sandpoint_ide_regbase[MAX_HWIFS];
-static unsigned long sandpoint_ide_ctl_regbase[MAX_HWIFS];
-static unsigned long sandpoint_idedma_regbase;
-
-static void
-sandpoint_ide_probe(void)
-{
- struct pci_dev *pdev = pci_get_device(PCI_VENDOR_ID_WINBOND,
- PCI_DEVICE_ID_WINBOND_82C105, NULL);
-
- if (pdev) {
- sandpoint_ide_regbase[0]=pdev-resource[0].start;
- sandpoint_ide_regbase[1]=pdev-resource[2].start;
- sandpoint_ide_ctl_regbase[0]=pdev-resource[1].start;
- sandpoint_ide_ctl_regbase[1]=pdev-resource[3].start;
- sandpoint_idedma_regbase=pdev-resource[4].start;
- pci_dev_put(pdev);
- }
-
- sandpoint_ide_ports_known = 1;
-}
-
-static int
-sandpoint_ide_default_irq(unsigned long base)
-{
- if (sandpoint_ide_ports_known == 0)
- sandpoint_ide_probe();
-
- if (base == sandpoint_ide_regbase[0])
- return SANDPOINT_IDE_INT0;
- else if (base == sandpoint_ide_regbase[1])
- return SANDPOINT_IDE_INT1;
- else
- return 0;
-}
-
-static unsigned long
-sandpoint_ide_default_io_base(int index)
-{
- if (sandpoint_ide_ports_known == 0)
- sandpoint_ide_probe();
-
- return sandpoint_ide_regbase[index];
-}
-
-static void __init
-sandpoint_ide_init_hwif_ports(hw_regs_t *hw, unsigned long data_port,
- unsigned long ctrl_port, int *irq)
-{
- unsigned long reg = data_port;
- uintalt_status_base;
- int i;
-
- for (i = IDE_DATA_OFFSET; i = IDE_STATUS_OFFSET; i++) {
- hw-io_ports[i] = reg++;
- }
-
- if (data_port == sandpoint_ide_regbase[0]) {
- alt_status_base = sandpoint_ide_ctl_regbase[0] + 2;
- hw-irq = 14;
- }
- else if (data_port == sandpoint_ide_regbase[1]) {
- alt_status_base = sandpoint_ide_ctl_regbase[1] + 2;
- hw-irq = 15;
- }
- else {
- alt_status_base = 0;
- hw-irq = 0;
- }
-
- if (ctrl_port) {
- hw-io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
- } else {
- hw-io_ports[IDE_CONTROL_OFFSET] = alt_status_base;
- }
-
- if (irq != NULL) {
- *irq = hw-irq;
- }
-}
-#endif
-
/*
* Set BAT 3 to map 0xf800 to end of physical memory space 1-to-1.
*/
@@ -736,10 +648,4 @@ platform_init(unsigned long r3, unsigned
#ifdef CONFIG_SERIAL_TEXT_DEBUG
ppc_md.progress = gen550_progress;
#endif
-
-#if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE)
- ppc_ide_md.default_irq = sandpoint_ide_default_irq;
- ppc_ide_md.default_io_base = sandpoint_ide_default_io_base;
- ppc_ide_md.ide_init_hwif = sandpoint_ide_init_hwif_ports;
-#endif
}
Index:
[PATCH 06/11] ppc/lopec: remove ppc_ide_md hooks
* Add IDE_HFLAG_FORCE_LEGACY_IRQS host flag for Motorola-LoPEC platform
to sl82c105 host driver.
* Remove ppc_ide_md hooks from arch/ppc/platforms/lopec.c - no need for
them (sl82c105 host driver takes care of all this setup).
* Then remove no longer needed linux/ide.h include.
Looking at arch/ppc/configs/lopec_defconfig:
...
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
# CONFIG_IDEPCI_SHARE_IRQ is not set
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_SL82C105=y
...
there should be no functional changes unless somebody preferred to disable
sl82c105 host driver and use only ide_generic one (but why would anybody
want to do such thing :-).
PS It seems that lopec_defconfig hasn't been updated for ages but if somebody
is going to do it please look into disabling IDE_GENERIC and BLK_DEV_GENERIC
config options. Thanks.
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
arch/ppc/platforms/lopec.c | 85 -
drivers/ide/pci/sl82c105.c |4 ++
2 files changed, 4 insertions(+), 85 deletions(-)
Index: b/arch/ppc/platforms/lopec.c
===
--- a/arch/ppc/platforms/lopec.c
+++ b/arch/ppc/platforms/lopec.c
@@ -15,7 +15,6 @@
#include linux/pci_ids.h
#include linux/ioport.h
#include linux/init.h
-#include linux/ide.h
#include linux/seq_file.h
#include linux/initrd.h
#include linux/console.h
@@ -168,85 +167,6 @@ lopec_power_off(void)
lopec_halt();
}
-#if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE)
-int lopec_ide_ports_known = 0;
-static unsigned long lopec_ide_regbase[MAX_HWIFS];
-static unsigned long lopec_ide_ctl_regbase[MAX_HWIFS];
-static unsigned long lopec_idedma_regbase;
-
-static void
-lopec_ide_probe(void)
-{
- struct pci_dev *dev = pci_get_device(PCI_VENDOR_ID_WINBOND,
- PCI_DEVICE_ID_WINBOND_82C105,
- NULL);
- lopec_ide_ports_known = 1;
-
- if (dev) {
- lopec_ide_regbase[0] = dev-resource[0].start;
- lopec_ide_regbase[1] = dev-resource[2].start;
- lopec_ide_ctl_regbase[0] = dev-resource[1].start;
- lopec_ide_ctl_regbase[1] = dev-resource[3].start;
- lopec_idedma_regbase = dev-resource[4].start;
- pci_dev_put(dev);
- }
-}
-
-static int
-lopec_ide_default_irq(unsigned long base)
-{
- if (lopec_ide_ports_known == 0)
- lopec_ide_probe();
-
- if (base == lopec_ide_regbase[0])
- return 14;
- else if (base == lopec_ide_regbase[1])
- return 15;
- else
- return 0;
-}
-
-static unsigned long
-lopec_ide_default_io_base(int index)
-{
- if (lopec_ide_ports_known == 0)
- lopec_ide_probe();
- return lopec_ide_regbase[index];
-}
-
-static void __init
-lopec_ide_init_hwif_ports(hw_regs_t *hw, unsigned long data,
- unsigned long ctl, int *irq)
-{
- unsigned long reg = data;
- uint alt_status_base;
- int i;
-
- for (i = IDE_DATA_OFFSET; i = IDE_STATUS_OFFSET; i++)
- hw-io_ports[i] = reg++;
-
- if (data == lopec_ide_regbase[0]) {
- alt_status_base = lopec_ide_ctl_regbase[0] + 2;
- hw-irq = 14;
- } else if (data == lopec_ide_regbase[1]) {
- alt_status_base = lopec_ide_ctl_regbase[1] + 2;
- hw-irq = 15;
- } else {
- alt_status_base = 0;
- hw-irq = 0;
- }
-
- if (ctl)
- hw-io_ports[IDE_CONTROL_OFFSET] = ctl;
- else
- hw-io_ports[IDE_CONTROL_OFFSET] = alt_status_base;
-
- if (irq != NULL)
- *irq = hw-irq;
-
-}
-#endif /* BLK_DEV_IDE */
-
static void __init
lopec_init_IRQ(void)
{
@@ -384,11 +304,6 @@ platform_init(unsigned long r3, unsigned
ppc_md.nvram_read_val = todc_direct_read_val;
ppc_md.nvram_write_val = todc_direct_write_val;
-#if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE)
- ppc_ide_md.default_irq = lopec_ide_default_irq;
- ppc_ide_md.default_io_base = lopec_ide_default_io_base;
- ppc_ide_md.ide_init_hwif = lopec_ide_init_hwif_ports;
-#endif
#ifdef CONFIG_SERIAL_TEXT_DEBUG
ppc_md.progress = gen550_progress;
#endif
Index: b/drivers/ide/pci/sl82c105.c
===
--- a/drivers/ide/pci/sl82c105.c
+++ b/drivers/ide/pci/sl82c105.c
@@ -328,6 +328,10 @@ static const struct ide_port_info sl82c1
.enablebits = {{0x40,0x01,0x01}, {0x40,0x10,0x10}},
.host_flags = IDE_HFLAG_IO_32BIT |
IDE_HFLAG_UNMASK_IRQS |
+/* FIXME: check for Compatibility mode in generic IDE PCI
[Bug 9962] 2.6.26-git0: IDE oops during boot
http://bugzilla.kernel.org/show_bug.cgi?id=9962 --- Comment #4 from [EMAIL PROTECTED] 2008-02-13 16:09 --- Also the bug summary is totally wrong now since IDE OOPS has been already fixed, the problem now is: Creating root device. Mounting root filesystem. mount: could not find filesystem Kernel panic - not syncing: Attempted to kill init! but hopefully we will know more soon. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/11] ppc/mpc8xx: remove ppc_ide_md hooks
* Initialize IDE ports in mpc8xx_ide_probe().
* Remove m8xx_ide_init() and ppc_ide_md hooks - no need for them
(IDE mpc8xx host driver takes care of all this setup).
* Remove needless 'if (irq)' and 'if (data_port = MAX_HWIFS)' checks
from m8xx_ide_init_hwif_ports().
* Remove 'ctrl_port' and 'irq' arguments from m8xx_ide_init_hwif_ports().
* Rename m8xx_ide_init_hwif_ports() to m8xx_ide_init_ports().
* Add __init tag to m8xx_ide_init_ports().
This patch fixes hwif-irq always being overriden to 0 (== auto-probe, is
this even working on PPC?) because of ide_init_default_irq() call in ide.c.
There should be no other functional changes.
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
arch/ppc/syslib/m8xx_setup.c |6 ---
drivers/ide/ppc/mpc8xx.c | 86 +++
2 files changed, 22 insertions(+), 70 deletions(-)
Index: b/arch/ppc/syslib/m8xx_setup.c
===
--- a/arch/ppc/syslib/m8xx_setup.c
+++ b/arch/ppc/syslib/m8xx_setup.c
@@ -87,8 +87,6 @@ void m8xx_calibrate_decr(void);
unsigned char __res[sizeof(bd_t)];
-extern void m8xx_ide_init(void);
-
extern unsigned long find_available_memory(void);
extern void m8xx_cpm_reset(void);
extern void m8xx_wdt_handler_install(bd_t *bp);
@@ -474,8 +472,4 @@ platform_init(unsigned long r3, unsigned
ppc_md.find_end_of_memory = m8xx_find_end_of_memory;
ppc_md.setup_io_mappings= m8xx_map_io;
-
-#if defined(CONFIG_BLK_DEV_MPC8xx_IDE)
- m8xx_ide_init();
-#endif
}
Index: b/drivers/ide/ppc/mpc8xx.c
===
--- a/drivers/ide/ppc/mpc8xx.c
+++ b/drivers/ide/ppc/mpc8xx.c
@@ -99,32 +99,6 @@ static int _slot_ = -1; /* will be rea
/* Make clock cycles and always round up */
#define PCMCIA_MK_CLKS( t, T ) (( (t) * ((T)/100) + 999U ) / 1000U )
-
-
-/*
- * IDE stuff.
- */
-static int
-m8xx_ide_default_irq(unsigned long base)
-{
-#ifdef CONFIG_BLK_DEV_MPC8xx_IDE
- if (base = MAX_HWIFS)
- return 0;
-
- printk([%d] m8xx_ide_default_irq %d\n,__LINE__,ioport_dsc[base].irq);
-
- return (ioport_dsc[base].irq);
-#else
-return 9;
-#endif
-}
-
-static unsigned long
-m8xx_ide_default_io_base(int index)
-{
-return index;
-}
-
#define M8XX_PCMCIA_CD2(slot) (0x1000 (slot 4))
#define M8XX_PCMCIA_CD1(slot) (0x0800 (slot 4))
@@ -149,12 +123,11 @@ static int pcmcia_schlvl = PCMCIA_SCHLVL
*/
/*
- * m8xx_ide_init_hwif_ports for a direct IDE interface _using_
+ * m8xx_ide_init_ports() for a direct IDE interface _using_
+ * MPC8xx's internal PCMCIA interface
*/
#if defined(CONFIG_IDE_8xx_PCCARD) || defined(CONFIG_IDE_8xx_DIRECT)
-static void
-m8xx_ide_init_hwif_ports(hw_regs_t *hw, unsigned long data_port,
- unsigned long ctrl_port, int *irq)
+static void __init m8xx_ide_init_ports(hw_regs_t *hw, unsigned long data_port)
{
unsigned long *p = hw-io_ports;
int i;
@@ -173,8 +146,6 @@ m8xx_ide_init_hwif_ports(hw_regs_t *hw,
unsigned long base;
*p = 0;
- if (irq)
- *irq = 0;
pcmp = (pcmconf8xx_t *)immap_t *)IMAP_ADDR)-im_pcmcia));
@@ -248,9 +219,6 @@ m8xx_ide_init_hwif_ports(hw_regs_t *hw,
}
}
- if (data_port = MAX_HWIFS)
- return;
-
if (_slot_ == -1) {
printk (PCMCIA slot has not been defined! Using A as
default\n);
_slot_ = 0;
@@ -292,11 +260,13 @@ m8xx_ide_init_hwif_ports(hw_regs_t *hw,
*p++ = base + ioport_dsc[data_port].reg_off[i];
}
- if (irq) {
+ hw-irq = ioport_dsc[data_port].irq;
+ hw-ack_intr = (ide_ack_intr_t *)ide_interrupt_ack;
+
#ifdef CONFIG_IDE_8xx_PCCARD
+ {
unsigned int reg;
- *irq = ioport_dsc[data_port].irq;
if (_slot_)
pgcrx = ((immap_t *) IMAP_ADDR)-im_pcmcia.pcmc_pgcrb;
else
@@ -306,14 +276,11 @@ m8xx_ide_init_hwif_ports(hw_regs_t *hw,
reg |= mk_int_int_mask (pcmcia_schlvl) 24;
reg |= mk_int_int_mask (pcmcia_schlvl) 16;
*pgcrx = reg;
-#else /* direct connected IDE drive, i.e. external IRQ, not the PCMCIA irq */
- *irq = ioport_dsc[data_port].irq;
-#endif /* CONFIG_IDE_8xx_PCCARD */
}
+#endif /* CONFIG_IDE_8xx_PCCARD */
ide_hwifs[data_port].pio_mask = ATA_PIO4;
ide_hwifs[data_port].set_pio_mode = m8xx_ide_set_pio_mode;
- ide_hwifs[data_port].ack_intr = (ide_ack_intr_t *)ide_interrupt_ack;
/* Enable Harddisk Interrupt,
* and make it edge sensitive
@@ -329,16 +296,15 @@ m8xx_ide_init_hwif_ports(hw_regs_t *hw,
/* Enable falling edge irq */
pcmp-pcmc_per = 0x10
[Bug 9962] mount: could not find filesystem
http://bugzilla.kernel.org/show_bug.cgi?id=9962 [EMAIL PROTECTED] changed: What|Removed |Added Component|IDE |Other Product|IO/Storage |Other Summary|2.6.26-git0: IDE oops during|mount: could not find |boot|filesystem -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/11] ppc/pplus: remove ppc_ide_md.ide_init_hwif hook
* Call ide_init_default_irq() for pplus in init_ide_data().
* Remove no longer needed pplus_ide_init_hwif_ports().
There should be no functional changes caused by this patch.
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
arch/ppc/platforms/pplus.c | 23 ---
drivers/ide/ide.c |2 +-
2 files changed, 1 insertion(+), 24 deletions(-)
Index: b/arch/ppc/platforms/pplus.c
===
--- a/arch/ppc/platforms/pplus.c
+++ b/arch/ppc/platforms/pplus.c
@@ -695,28 +695,6 @@ static unsigned long pplus_ide_default_i
return 0;
}
}
-
-static void __init
-pplus_ide_init_hwif_ports(hw_regs_t * hw, unsigned long data_port,
- unsigned long ctrl_port, int *irq)
-{
- unsigned long reg = data_port;
- int i;
-
- for (i = IDE_DATA_OFFSET; i = IDE_STATUS_OFFSET; i++) {
- hw-io_ports[i] = reg;
- reg += 1;
- }
-
- if (ctrl_port)
- hw-io_ports[IDE_CONTROL_OFFSET] = ctrl_port;
- else
- hw-io_ports[IDE_CONTROL_OFFSET] =
- hw-io_ports[IDE_DATA_OFFSET] + 0x206;
-
- if (irq != NULL)
- *irq = pplus_ide_default_irq(data_port);
-}
#endif
#ifdef CONFIG_SMP
@@ -887,7 +865,6 @@ platform_init(unsigned long r3, unsigned
#if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE)
ppc_ide_md.default_irq = pplus_ide_default_irq;
ppc_ide_md.default_io_base = pplus_ide_default_io_base;
- ppc_ide_md.ide_init_hwif = pplus_ide_init_hwif_ports;
#endif
#ifdef CONFIG_SERIAL_TEXT_DEBUG
Index: b/drivers/ide/ide.c
===
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -214,7 +214,7 @@ static void __init init_ide_data (void)
memcpy(hwif-io_ports, hw.io_ports, sizeof(hw.io_ports));
#endif
hwif-noprobe = !hwif-io_ports[IDE_DATA_OFFSET];
-#if !defined(CONFIG_PPC32) || !defined(CONFIG_PCI)
+#if !defined(CONFIG_PPC32) || defined(CONFIG_PPLUS) || !defined(CONFIG_PCI)
hwif-irq =
ide_init_default_irq(hwif-io_ports[IDE_DATA_OFFSET]);
#endif
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/11] ppc/pmac: remove no longer needed IDE quirk
IDE PMAC host driver and all IDE PCI host drivers use pci_enable_device()
nowadays so the following quirk in pmac_pcibios_after_init() can be removed.
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
arch/powerpc/platforms/powermac/pci.c | 22 --
1 file changed, 22 deletions(-)
Index: b/arch/powerpc/platforms/powermac/pci.c
===
--- a/arch/powerpc/platforms/powermac/pci.c
+++ b/arch/powerpc/platforms/powermac/pci.c
@@ -1144,28 +1144,6 @@ void __init pmac_pcibios_after_init(void
{
struct device_node* nd;
-#ifdef CONFIG_BLK_DEV_IDE
- struct pci_dev *dev = NULL;
-
- /* OF fails to initialize IDE controllers on macs
-* (and maybe other machines)
-*
-* Ideally, this should be moved to the IDE layer, but we need
-* to check specifically with Andre Hedrick how to do it cleanly
-* since the common IDE code seem to care about the fact that the
-* BIOS may have disabled a controller.
-*
-* -- BenH
-*/
- for_each_pci_dev(dev) {
- if ((dev-class 16) != PCI_BASE_CLASS_STORAGE)
- continue;
- if (pci_enable_device(dev))
- printk(KERN_WARNING
- pci: Failed to enable %s\n, pci_name(dev));
- }
-#endif /* CONFIG_BLK_DEV_IDE */
-
for_each_node_by_name(nd, firewire) {
if (nd-parent (of_device_is_compatible(nd, pci106b,18) ||
of_device_is_compatible(nd, pci106b,30) ||
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata/sata_sil24 cache alignment problem?
I hadn't considered that approach due to the way the ata_port is allocated:
libata-core.c:
host = scsi_host_alloc(ent-sht, sizeof(struct ata_port));
hosts.c:
struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int
privsize)
{
shost = kzalloc(sizeof(struct Scsi_Host) + privsize, gfp_mask);
}
The ata_port allocation is tacked onto the end of the Scsi_Host
allocation, so the start of ata_port will only be cache aligned if the
end of the Scsi_Host struct is, although that would be easy enough to
fix since it's currently aligned to an unsigned long boundary.
You are right.
I like that approach better, since it's clearer what the intent is,
and it's easier. Is there any other way that the ata_port struct
might be used that would invalidate this?
I can't think of one. The object lifetime is right - the ata_port is
created before the port buffer is used and destroyed after it is finished
(obviously or embedding it in the struct wouldn't work either)
Alan
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET] printk: implement printk_header() and merging printk, take #3
Andrew Morton wrote: And mprintk the following. code: DEFINE_MPRINTK(mp, 2 * 80); mprintk_set_header(mp, KERN_INFO ata%u.%2u: , 1, 0); mprintk_push(mp, ATA %d, 7); mprintk_push(mp, , %u sectors\n, 1024); mprintk(mp, everything seems dandy\n); output: 6ata1.00: ATA 7, 1024 sectors 6ata1.00 everything seems dandy And that looks like an awful lot of fuss. Is it really worth doing? In the above example, s/mprintk(/mprintk_flush(/ and s/mprintk_push(/mprintk(/ Can you please take a look at ata_eh_link_report() in drivers/ata/libata-eh.c? Currently, it has some problems. * All that it wants to do is printing some messages but it's awfully complex with temp bufs and super-long printk calls containing optional %s's. * status / error decode print outs are printed separately from cmd/res making it difficult to tell how they are grouped. Putting them together would require allocating another temp buf(s) and adding extra %s's to cmd/res printout. * For timeouts, result TF isn't available and thus res printout is misleading. res shouldn't be printed after timeouts. This would require allocating yest another temp buf and separating out res printing into separate snprintf. I was trying to do this and got fed up with all the tricks in the function. The only sane way out is to build messages piece-by-piece into a buffer and print it at once. The eh message is gigantic and I needed to allocate the buffer elsewhere than stack. ata_eh_link_report() fortunately has fixed place for that - ap-sector_buf - but let's assume there was no such buffer for the discussion. I'm still not too sure whether it's wise to use sector_buf for message building anyway. The only way is to malloc the buffer. Once the buffer is available, building message using snprintf is a bit cumbersome but is okay. The problem is that malloc can fail. To handle that case, we basically need to do if (buf) printed += snprintf(buf + printed, len - printed, ...); else printk(...); which is very cumbersome, so we need a wrapper around the above. As the wrapper needs to control when the message goes out, a flush function is necessary too. Combine those with overflow handling - mprintk. Similar problem exists for ata_dev_configure() in drivers/ata/libata-core.c although it's a bit better there. Please take a look at the fifth patch. It doesn't remove a lot of lines but it streamlines both functions significantly. For ata_dev_configure(), message reporting becomes what the function does secondarily while configuring the device, not something it's structured around. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET] printk: implement printk_header() and merging printk, take #3
On Thu, 14 Feb 2008 09:40:51 +0900 Tejun Heo [EMAIL PROTECTED] wrote: Can you please take a look at ata_eh_link_report() in drivers/ata/libata-eh.c? I did. Punishment? Currently, it has some problems. Yes, and the patches do clean that up. ho hum. What tends to happen with this sort of thing is that fi we merge it, it ends up getting used more often than one expected... If you stand back and squint at it, there are quite a few places where we do this sort of thing: allocate a buffer, squirt characters into it, reallocating and/or flushing as we proceed. All sysfs and procfs read-side code, for a start... - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET] printk: implement printk_header() and merging printk, take #3
Hello, Andrew Morton wrote: On Thu, 14 Feb 2008 09:40:51 +0900 Tejun Heo [EMAIL PROTECTED] wrote: Can you please take a look at ata_eh_link_report() in drivers/ata/libata-eh.c? I did. Punishment? Heh.. :-) Currently, it has some problems. Yes, and the patches do clean that up. Yeap, it does. ho hum. What tends to happen with this sort of thing is that fi we merge it, it ends up getting used more often than one expected... Hmmm... Okay. mprintk being printk, I'm not too sure how it can go over usual expectations but well, yeah, that actually is my expectation. If you stand back and squint at it, there are quite a few places where we do this sort of thing: allocate a buffer, squirt characters into it, reallocating and/or flushing as we proceed. All sysfs and procfs read-side code, for a start... printk is a special case, I think. It's the primary logging/debugging method which can't fail and as it's mostly interpreted by human beings (and developers in problematic cases), it has different maneuvering room on errors - ie. it's far better to print messages w/o header or proper log level than failing to print, which is quite different requirements from other components. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pata_scc.c: add thaw ops
Akira Iguchi wrote: This patch adds default thaw ops and fixes the freeze/thaw inconsistency. Signed-off-by: Kou Ishizaki [EMAIL PROTECTED] Signed-off-by: Akira Iguchi [EMAIL PROTECTED] Acked-by: Tejun Heo [EMAIL PROTECTED] -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata/sata_sil24 cache alignment problem?
Alan Cox wrote:
I hadn't considered that approach due to the way the ata_port is allocated:
libata-core.c:
host = scsi_host_alloc(ent-sht, sizeof(struct ata_port));
hosts.c:
struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int
privsize)
{
shost = kzalloc(sizeof(struct Scsi_Host) + privsize, gfp_mask);
}
The ata_port allocation is tacked onto the end of the Scsi_Host
allocation, so the start of ata_port will only be cache aligned if the
end of the Scsi_Host struct is, although that would be easy enough to
fix since it's currently aligned to an unsigned long boundary.
You are right.
For recent kernels, ata_port is allocated separately so
cacheline_aligned should be enough.
I like that approach better, since it's clearer what the intent is,
But, yeah, allocating separately is probably safer.
and it's easier. Is there any other way that the ata_port struct
might be used that would invalidate this?
I can't think of one. The object lifetime is right - the ata_port is
created before the port buffer is used and destroyed after it is finished
(obviously or embedding it in the struct wouldn't work either)
I'll prep a patch for the current kernel. Hmmm... This means that any
DMA buffer should be aligned to cacheline. Block layer DMA alignment
helpers should probably take this into consideration and we better add
warnings to dma map functions. This only affects DMA-to-memory, right?
Thanks.
--
tejun
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pci_get_device_reverse(), why does Calgary need this?
On Thu, Feb 14, 2008 at 01:02:55AM +0100, Bartlomiej Zolnierkiewicz wrote: On Thursday 14 February 2008, Greg KH wrote: On Wed, Feb 13, 2008 at 11:20:36PM +0100, Bartlomiej Zolnierkiewicz wrote: On Wednesday 13 February 2008, Greg KH wrote: On Wed, Feb 13, 2008 at 09:28:24AM -0800, Greg KH wrote: On Wed, Feb 13, 2008 at 01:34:12PM +0100, Bartlomiej Zolnierkiewicz wrote: On Wednesday 13 February 2008, Greg KH wrote: On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox wrote: Why does the calgary driver need this? Can we just use pci_get_device() instead? Why do you need to walk the device list backwards? Do you get false positives going forward? It doesn't look to be performance critical so the driver can pci_get_device until the end and use the final hit anyway. That would make more sense. IDE reverse is more problematic but nobody seems to use it. I've seen two posters say they use it. I'm wondering what it is really solving if they use it, and why if it's really needed, scsi never had to implement such a hack... It is no longer solving anything, just adds more pain. ;) [ The option comes from 2.2.x (so long before LABEL=/ and /dev/disk/by-id/ became popular). Some off-board controllers integrated on motherboards used to appear before on-board IDE on PCI bus so this option was meant to preserve the legacy ordering. ] Since it is valid only when Probe IDE PCI devices in the PCI bus order (DEPRECATED) config option is used it is already on its way out (though marking it as obsoleted would make it more explicit). I think that removing ide=reverse in 2.6.26 would be OK... Great, thanks for your blessing. I'll make up a patch and send it to you for approval. How does the patch below look? I didn't want to remove the whole config option, as there is more to the logic than just the reverse order stuff there. looks fine, Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] Thanks. If you don't mind, can I take this through the PCI tree so as to allow the removal of this pci function afterwards? [...] great, could you also: - rebase it on top of the patch below - forward the patch below to Linus for 2.6.25 Sure, you want this to go in for .25, but not the one I just posted removing this option, correct? That should wait for .26? Yes, lets give people the final call before actually removing this option (unless of course there is some urgent reason for removing it in .25). No, no rush from me, I'll queue this up and send it to Linus in my next batch. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/11] ata: fix sparse warning in ata_piix.c
drivers/ata/ata_piix.c:1655:8: warning: symbol 'rc' shadows an earlier one
drivers/ata/ata_piix.c:1616:6: originally declared here
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
drivers/ata/ata_piix.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 9c2515f..752e7d2 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -1652,7 +1652,7 @@ static int __devinit piix_init_one(struct pci_dev *pdev,
u8 tmp;
pci_read_config_byte(pdev, PIIX_SCC, tmp);
if (tmp == PIIX_AHCI_DEVICE) {
- int rc = piix_disable_ahci(pdev);
+ rc = piix_disable_ahci(pdev);
if (rc)
return rc;
}
--
1.5.4.1.1278.gc75be
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/11] ata: fix sparse warning in sata_via.c
drivers/ata/sata_via.c:336:2: warning: returning void-valued expression
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
drivers/ata/sata_via.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/sata_via.c b/drivers/ata/sata_via.c
index 30caa03..0d03f44 100644
--- a/drivers/ata/sata_via.c
+++ b/drivers/ata/sata_via.c
@@ -333,8 +333,8 @@ static int vt6420_prereset(struct ata_link *link, unsigned
long deadline)
static void vt6420_error_handler(struct ata_port *ap)
{
- return ata_bmdma_drive_eh(ap, vt6420_prereset, ata_std_softreset,
- NULL, ata_std_postreset);
+ ata_bmdma_drive_eh(ap, vt6420_prereset, ata_std_softreset, NULL,
+ ata_std_postreset);
}
static int vt6421_pata_cable_detect(struct ata_port *ap)
--
1.5.4.1.1278.gc75be
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/11] ata: fix sparse warnings in sata_mv.c
pp is never used again in this function, no need to declare a
new one.
drivers/ata/sata_mv.c:1545:24: warning: symbol 'pp' shadows an earlier one
drivers/ata/sata_mv.c:1501:22: originally declared here
drivers/ata/sata_mv.c:1553:24: warning: symbol 'pp' shadows an earlier one
drivers/ata/sata_mv.c:1501:22: originally declared here
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
drivers/ata/sata_mv.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 04b5717..2ecd44d 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -1542,7 +1542,7 @@ static void mv_err_intr(struct ata_port *ap, struct
ata_queued_cmd *qc)
eh_freeze_mask = EDMA_EH_FREEZE_5;
if (edma_err_cause EDMA_ERR_SELF_DIS_5) {
- struct mv_port_priv *pp = ap-private_data;
+ pp = ap-private_data;
pp-pp_flags = ~MV_PP_FLAG_EDMA_EN;
ata_ehi_push_desc(ehi, EDMA self-disable);
}
@@ -1550,7 +1550,7 @@ static void mv_err_intr(struct ata_port *ap, struct
ata_queued_cmd *qc)
eh_freeze_mask = EDMA_EH_FREEZE;
if (edma_err_cause EDMA_ERR_SELF_DIS) {
- struct mv_port_priv *pp = ap-private_data;
+ pp = ap-private_data;
pp-pp_flags = ~MV_PP_FLAG_EDMA_EN;
ata_ehi_push_desc(ehi, EDMA self-disable);
}
--
1.5.4.1.1278.gc75be
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/11] ata: replace macro with static inline in libata.h
Avoid a metric ton of 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]
---
include/linux/libata.h |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/include/linux/libata.h b/include/linux/libata.h
index bc5a8d0..2845983 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -764,7 +764,11 @@ 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)
+{
+ short tmp = min_t(short, v, vmax);
+ return max_t(short, tmp, vmin);
+}
extern const unsigned long sata_deb_timing_normal[];
extern const unsigned long sata_deb_timing_hotplug[];
--
1.5.4.1.1278.gc75be
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/11] ata: sparse fixes for pata_amd.c
drop return statement.
drivers/ata/pata_amd.c:149:2: warning: returning void-valued expression
Commit ce54d1616302117fa98513ae916bbe1c02ea pata_amd: update mode selection
for NV PATAs
added the initializer for nv_mode_filter but missed deleting the previously
set mode_filter
drivers/ata/pata_amd.c:509:3: warning: Initializer entry defined twice
drivers/ata/pata_amd.c:521:3: also defined here
drivers/ata/pata_amd.c:544:3: warning: Initializer entry defined twice
drivers/ata/pata_amd.c:556:3: also defined here
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
drivers/ata/pata_amd.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/ata/pata_amd.c b/drivers/ata/pata_amd.c
index ea567e2..4b8d9b5 100644
--- a/drivers/ata/pata_amd.c
+++ b/drivers/ata/pata_amd.c
@@ -146,9 +146,8 @@ static int amd_pre_reset(struct ata_link *link, unsigned
long deadline)
static void amd_error_handler(struct ata_port *ap)
{
- return ata_bmdma_drive_eh(ap, amd_pre_reset,
- ata_std_softreset, NULL,
- ata_std_postreset);
+ ata_bmdma_drive_eh(ap, amd_pre_reset, ata_std_softreset, NULL,
+ ata_std_postreset);
}
static int amd_cable_detect(struct ata_port *ap)
@@ -506,7 +505,6 @@ static struct ata_port_operations amd133_port_ops = {
static struct ata_port_operations nv100_port_ops = {
.set_piomode= nv100_set_piomode,
.set_dmamode= nv100_set_dmamode,
- .mode_filter= ata_pci_default_filter,
.tf_load= ata_tf_load,
.tf_read= ata_tf_read,
.check_status = ata_check_status,
@@ -541,7 +539,6 @@ static struct ata_port_operations nv100_port_ops = {
static struct ata_port_operations nv133_port_ops = {
.set_piomode= nv133_set_piomode,
.set_dmamode= nv133_set_dmamode,
- .mode_filter= ata_pci_default_filter,
.tf_load= ata_tf_load,
.tf_read= ata_tf_read,
.check_status = ata_check_status,
--
1.5.4.1.1278.gc75be
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/11] ata: fix sparse warning in pata_cs5536.c
Everybody passes in a u32...why fight it.
drivers/ata/pata_cs5536.c:124:26: warning: incorrect type in argument 3
(different signedness)
drivers/ata/pata_cs5536.c:124:26:expected int *val
drivers/ata/pata_cs5536.c:124:26:got unsigned int *noident
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
drivers/ata/pata_cs5536.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/pata_cs5536.c b/drivers/ata/pata_cs5536.c
index d753e56..c71505e 100644
--- a/drivers/ata/pata_cs5536.c
+++ b/drivers/ata/pata_cs5536.c
@@ -85,7 +85,7 @@ static const u8 pci_reg[4] = {
PCI_IDE_CFG, PCI_IDE_DTC, PCI_IDE_CAST, PCI_IDE_ETC,
};
-static inline int cs5536_read(struct pci_dev *pdev, int reg, int *val)
+static inline int cs5536_read(struct pci_dev *pdev, int reg, u32 *val)
{
if (unlikely(use_msr)) {
u32 dummy;
--
1.5.4.1.1278.gc75be
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/11] ata: fix sparse warning in pata_jmicron.c
drivers/ata/pata_jmicron.c:118:2: warning: returning void-valued expression
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
drivers/ata/pata_jmicron.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c
index 5b8174d..00d 100644
--- a/drivers/ata/pata_jmicron.c
+++ b/drivers/ata/pata_jmicron.c
@@ -115,7 +115,8 @@ static int jmicron_pre_reset(struct ata_link *link,
unsigned long deadline)
static void jmicron_error_handler(struct ata_port *ap)
{
- return ata_bmdma_drive_eh(ap, jmicron_pre_reset, ata_std_softreset,
NULL, ata_std_postreset);
+ ata_bmdma_drive_eh(ap, jmicron_pre_reset, ata_std_softreset, NULL,
+ ata_std_postreset);
}
/* No PIO or DMA methods needed for this device */
--
1.5.4.1.1278.gc75be
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/11] ata: fix sparse warning in pata_marvell.c
drivers/ata/pata_marvell.c:88:2: warning: returning void-valued expression
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
drivers/ata/pata_marvell.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/pata_marvell.c b/drivers/ata/pata_marvell.c
index 9afc8a3..a81f25d 100644
--- a/drivers/ata/pata_marvell.c
+++ b/drivers/ata/pata_marvell.c
@@ -85,8 +85,8 @@ static int marvell_cable_detect(struct ata_port *ap)
static void marvell_error_handler(struct ata_port *ap)
{
- return ata_bmdma_drive_eh(ap, marvell_pre_reset, ata_std_softreset,
- NULL, ata_std_postreset);
+ ata_bmdma_drive_eh(ap, marvell_pre_reset, ata_std_softreset, NULL,
+ ata_std_postreset);
}
/* No PIO or DMA methods needed for this device */
--
1.5.4.1.1278.gc75be
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
