Menu
▾
▴
acpi-devel
|
From: Matthew G. <mj...@sr...> - 2005-12-08 03:02:57
|
Hi!
The included patch does three things:
1) It adds basic support for binding SCSI and SATA devices to ACPI
device handles. At the moment this is limited to hosts, and in practice
it's probably limited to SATA ones (ACPI doesn't spec how SCSI devices
should appear in the DSDT, so I'm guessing that in general they don't).
Given a host, you can DEVICE_ACPI_HANDLE(dev) it to get the handle to
the ACPI device - this should be handy for implementing suspend
functions, since the methods should be in a standard location underneath
this.
Support for binding the devices hasn't been implemented yet. I'm not
entire sure where they should be bound (the target, presumably?), and I
haven't actually got it to work...
2) It adds support for attaching notification events to the host. These
can be host-driver specific (they're just part of the host template).
Whenever the hardware generates an event on that bus, the host will be
called. I've added one of these to ata_piix (since that's what I have),
which should really be implemented in the host and only call the generic
one when appropriate. But still.
3) Adds a generic libata notification handler that currently treats all
notifications as drive removal/insertion. It then calls Lukasz
Kosewski's hotplug code to remove/add the drive as appropriate.
Most laptops generate ACPI notifications requesting bus rescans whenever
a bay drive is inserted or removed. This handles the event
appropriately. On my Dell d610, removing or plugging the drive results
in it appearing or disappearing from /proc/scsi/scsi as appropriate.
Patch:
diff -u drivers/scsi/ata_piix.c /tmp/drivers/scsi/ata_piix.c
--- drivers/scsi/ata_piix.c 2005-12-05 14:30:58 +0000
+++ /tmp/drivers/scsi/ata_piix.c 2005-12-08 02:16:59 +0000
@@ -148,6 +148,7 @@
.ordered_flush = 1,
.resume = ata_scsi_device_resume,
.suspend = ata_scsi_device_suspend,
+ .acpi_notify = ata_acpi_notify,
};
static const struct ata_port_operations piix_pata_ops = {
diff -u drivers/scsi/libata-core.c /tmp/drivers/scsi/libata-core.c
--- drivers/scsi/libata-core.c 2005-12-08 02:27:02 +0000
+++ /tmp/drivers/scsi/libata-core.c 2005-12-08 02:16:50 +0000
@@ -50,6 +50,7 @@
#include <linux/workqueue.h>
#include <linux/jiffies.h>
#include <linux/scatterlist.h>
+#include <linux/acpi.h>
#include <scsi/scsi.h>
#include "scsi_priv.h"
#include <scsi/scsi_cmnd.h>
@@ -75,9 +76,11 @@
unsigned int *xfer_shift_out);
static void __ata_qc_complete(struct ata_queued_cmd *qc);
static void ata_pio_error(struct ata_port *ap);
+static int ata_bus_probe(struct ata_port *ap);
static unsigned int ata_unique_id = 1;
static struct workqueue_struct *ata_wq;
+static struct workqueue_struct *ata_hotplug_wq;
int atapi_enabled = 1;
module_param(atapi_enabled, int, 0444);
@@ -88,6 +91,17 @@
MODULE_LICENSE("GPL");
MODULE_VERSION(DRV_VERSION);
+void ata_acpi_notify(acpi_handle device, u32 type, void *data) {
+ struct device *dev = acpi_get_physical_device(device);
+ struct Scsi_Host *shost = dev_to_shost(dev);
+ struct ata_port *ap = (struct ata_port *) &shost->hostdata[0];
+
+ if (!ata_bus_probe(ap))
+ ata_hotplug_plug(ap);
+ else
+ ata_hotplug_unplug(ap);
+}
+
/**
* ata_tf_load_pio - send taskfile registers to host controller
* @ap: Port to which output is sent
diff -u drivers/scsi/scsi.c /tmp/drivers/scsi/scsi.c
--- drivers/scsi/scsi.c 2005-12-04 16:48:07 +0000
+++ /tmp/drivers/scsi/scsi.c 2005-12-08 02:16:28 +0000
@@ -55,6 +55,7 @@
#include <linux/interrupt.h>
#include <linux/notifier.h>
#include <linux/cpu.h>
+#include <linux/acpi.h>
#include <scsi/scsi.h>
#include <scsi/scsi_cmnd.h>
@@ -1305,6 +1306,48 @@
#define unregister_scsi_cpu()
#endif /* CONFIG_HOTPLUG_CPU */
+#ifdef CONFIG_ACPI
+static int scsi_acpi_find_device(struct device *dev, acpi_handle *handle)
+{
+ return -ENODEV;
+}
+
+void ata_acpi_notify(acpi_handle handle, u32 type, void *data);
+
+static int scsi_acpi_find_channel(struct device *dev, acpi_handle *handle)
+{
+ int i;
+ struct Scsi_Host *shost;
+
+ if (sscanf(dev->bus_id, "host%u", &i) != 1) {
+ return -ENODEV;
+ }
+
+ *handle = acpi_get_child(DEVICE_ACPI_HANDLE(dev->parent), (acpi_integer) i);
+ if (!*handle)
+ return -ENODEV;
+
+ shost = dev_to_shost(dev);
+
+ if (shost->hostt->acpi_notify) {
+ acpi_install_notify_handler(*handle, ACPI_ALL_NOTIFY, &ata_acpi_notify, (void *)i);
+ }
+
+ return 0;
+}
+
+static struct acpi_bus_type scsi_acpi_bus = {
+ .bus = &scsi_bus_type,
+ .find_bridge = scsi_acpi_find_channel,
+ .find_device = scsi_acpi_find_device,
+};
+
+static __init int scsi_acpi_register(void)
+{
+ return register_acpi_bus_type(&scsi_acpi_bus);
+}
+#endif /* CONFIG_ACPI */
+
MODULE_DESCRIPTION("SCSI core");
MODULE_LICENSE("GPL");
@@ -1333,6 +1376,11 @@
error = scsi_sysfs_register();
if (error)
goto cleanup_sysctl;
+#ifdef CONFIG_ACPI
+ error = scsi_acpi_register();
+ if (error)
+ goto cleanup_sysfs;
+#endif
for (i = 0; i < NR_CPUS; i++)
INIT_LIST_HEAD(&per_cpu(scsi_done_q, i));
@@ -1343,6 +1391,8 @@
printk(KERN_NOTICE "SCSI subsystem initialized\n");
return 0;
+cleanup_sysfs:
+ scsi_sysfs_unregister();
cleanup_sysctl:
scsi_exit_sysctl();
cleanup_hosts:
--- include/linux/libata.h 2005-12-05 14:32:50 +0000
+++ /tmp/include/linux/libata.h 2005-12-08 02:35:59 +0000
@@ -453,7 +468,9 @@
extern int ata_scsi_device_suspend(struct scsi_device *);
extern int ata_device_resume(struct ata_port *, struct ata_device *);
extern int ata_device_suspend(struct ata_port *, struct ata_device *);
-
+#ifdef CONFIG_ACPI
+extern void ata_acpi_notify(acpi_handle device, u32 type, void *data);
+#endif
/*
* Default driver ops implementations
*/
diff -u include/linux/libata.h /tmp/include/linux/libata.h
--- include/linux/libata.h 2005-12-05 14:32:50 +0000
+++ /tmp/include/linux/libata.h 2005-12-08 02:10:03 +0000
@@ -448,12 +463,16 @@
extern int ata_scsi_error(struct Scsi_Host *host);
extern int ata_scsi_release(struct Scsi_Host *host);
extern unsigned int ata_host_intr(struct ata_port *ap, struct ata_queued_cmd *qc);
+extern void ata_hotplug_unplug(struct ata_port *ap);
+extern void ata_hotplug_plug(struct ata_port *ap);
extern int ata_ratelimit(void);
extern int ata_scsi_device_resume(struct scsi_device *);
extern int ata_scsi_device_suspend(struct scsi_device *);
extern int ata_device_resume(struct ata_port *, struct ata_device *);
extern int ata_device_suspend(struct ata_port *, struct ata_device *);
-
+#ifdef CONFIG_ACPI
+extern void ata_acpi_notify(acpi_handle device, u32 type, void *data);
+#endif
/*
* Default driver ops implementations
*/
diff -u include/scsi/scsi_host.h /tmp/include/scsi/scsi_host.h
--- include/scsi/scsi_host.h 2005-11-14 14:57:13 +0000
+++ /tmp/include/scsi/scsi_host.h 2005-12-08 02:12:14 +0000
@@ -5,6 +5,7 @@
#include <linux/list.h>
#include <linux/types.h>
#include <linux/workqueue.h>
+#include <linux/acpi.h>
struct block_device;
struct completion;
@@ -300,6 +301,13 @@
*/
int (*resume)(struct scsi_device *);
int (*suspend)(struct scsi_device *);
+
+#ifdef CONFIG_ACPI
+ /*
+ * ACPI notification handler
+ */
+ void (*acpi_notify)(acpi_handle device, u32 type, void *data);
+#endif
/*
* Name of proc directory
--
Matthew Garrett | mj...@sr...
|
|
From: Christoph H. <hc...@in...> - 2005-12-08 09:15:53
|
On Thu, Dec 08, 2005 at 03:02:42AM +0000, Matthew Garrett wrote: > Hi! > > The included patch does three things: > > 1) It adds basic support for binding SCSI and SATA devices to ACPI > device handles. At the moment this is limited to hosts, and in practice > it's probably limited to SATA ones (ACPI doesn't spec how SCSI devices > should appear in the DSDT, so I'm guessing that in general they don't). > Given a host, you can DEVICE_ACPI_HANDLE(dev) it to get the handle to > the ACPI device - this should be handy for implementing suspend > functions, since the methods should be in a standard location underneath > this. NACK. ACPI-specific hacks do not have any business at all in the scsi layer. |
|
From: Matthew G. <mj...@sr...> - 2005-12-08 13:27:31
|
On Thu, Dec 08, 2005 at 09:15:42AM +0000, Christoph Hellwig wrote: > NACK. ACPI-specific hacks do not have any business at all in the scsi layer. Ok. What's the right layer to do this? The current ACPI/anything else glue depends on specific knowledge about the bus concerned, and needs callbacks registered before devices are added to that bus. Doing it in the sata layer would have the potential for unhappiness on mixed sata/scsi machines. -- Matthew Garrett | mj...@sr... |
|
From: Christoph H. <hc...@in...> - 2005-12-08 13:33:26
|
On Thu, Dec 08, 2005 at 01:26:57PM +0000, Matthew Garrett wrote: > On Thu, Dec 08, 2005 at 09:15:42AM +0000, Christoph Hellwig wrote: > > > NACK. ACPI-specific hacks do not have any business at all in the scsi layer. > > Ok. What's the right layer to do this? The current ACPI/anything else > glue depends on specific knowledge about the bus concerned, and needs > callbacks registered before devices are added to that bus. Doing it in > the sata layer would have the potential for unhappiness on mixed > sata/scsi machines. Don't do it at all. We don't need to fuck up every layer and driver for intels braindamage. |
|
From: Matthew G. <mj...@sr...> - 2005-12-08 13:40:03
|
On Thu, Dec 08, 2005 at 01:33:08PM +0000, Christoph Hellwig wrote: > Don't do it at all. We don't need to fuck up every layer and driver for > intels braindamage. Doing SATA suspend/resume properly on x86 depends on knowing the ACPI object that corresponds to a host or target. It's also the only way to support hotswap on this hardware[1], since there's no way for userspace to know which device a notification refers to. [1] ie, most laptops sold nowadays -- Matthew Garrett | mj...@sr... |
|
From: Christoph H. <hc...@in...> - 2005-12-08 13:44:54
|
On Thu, Dec 08, 2005 at 01:39:45PM +0000, Matthew Garrett wrote: > On Thu, Dec 08, 2005 at 01:33:08PM +0000, Christoph Hellwig wrote: > > > Don't do it at all. We don't need to fuck up every layer and driver for > > intels braindamage. > > Doing SATA suspend/resume properly on x86 depends on knowing the ACPI > object that corresponds to a host or target. It's also the only way to > support hotswap on this hardware[1], since there's no way for userspace > to know which device a notification refers to. Well, bad luck for people buying such broken hardware. Maybe you can trick Jeff into adding junk like that to libata, but it surely doesn't have any business in the scsi layer. Why oh why do our chipset friends at intel have to fuck up everything they can? I wish they'd learn a lesson or two from their cpu collegues. |
|
From: Erik S. <er...@sl...> - 2005-12-08 17:18:56
Attachments:
smime.p7s
|
On Thu, 2005-12-08 at 13:44 +0000, Christoph Hellwig wrote: > On Thu, Dec 08, 2005 at 01:39:45PM +0000, Matthew Garrett wrote: > > On Thu, Dec 08, 2005 at 01:33:08PM +0000, Christoph Hellwig wrote: > >=20 > > > Don't do it at all. We don't need to fuck up every layer and driver = for > > > intels braindamage. > >=20 > > Doing SATA suspend/resume properly on x86 depends on knowing the ACPI=20 > > object that corresponds to a host or target. It's also the only way to=20 > > support hotswap on this hardware[1], since there's no way for userspace= =20 > > to know which device a notification refers to. >=20 > Well, bad luck for people buying such broken hardware. Maybe you can tri= ck > Jeff into adding junk like that to libata, but it surely doesn't have any > business in the scsi layer. 'guess You're not interested in having suspend/resume actually work on laptops (or other PC's). That's your prerogative but imho it's a bit narrow-minded to withhold this functionality from other people who actually would like to have this working, just because you happen to not like ACPI. |
|
From: Jeff G. <jg...@po...> - 2005-12-08 20:44:02
|
Erik Slagter wrote: > 'guess You're not interested in having suspend/resume actually work on > laptops (or other PC's). That's your prerogative but imho it's a bit > narrow-minded to withhold this functionality from other people who > actually would like to have this working, just because you happen to not > like ACPI. It works just fine on laptops, with Jens' suspend/resume patch. Jeff |
|
From: Dominic I. <do...@ij...> - 2005-12-08 21:03:50
|
Quoting Jeff Garzik <jg...@po...>: > Erik Slagter wrote: > > 'guess You're not interested in having suspend/resume actually work on > > laptops (or other PC's). That's your prerogative but imho it's a bit > > narrow-minded to withhold this functionality from other people who > > actually would like to have this working, just because you happen to not > > like ACPI. > > It works just fine on laptops, with Jens' suspend/resume patch. not on my fujitsu sonoma/ih6 based laptop it doesn't. in my travels trying to fix this problem it appears there are many others it doesnt work for either. suspend/resume is incredibly important for day-to-day practical use of a laptop, particularly using linux. the sole reason i still have a windows partition is because suspend doesnt work in linux and i'm sick of firing everything up again 3 times a day. thank you very much to all on this list who are pursuing a solution sensibly and not making unhelpful blanket statements against the most widely used laptop chipset maker - *particularly* when they are actively contributing to development on this list. we (laptop users) dont care about religious standpoints, we just want it to work. dom > > Jeff > > > - > To unsubscribe from this list: send the line "unsubscribe linux-ide" in > the body of a message to maj...@vg... > More majordomo info at http://vger.kernel.org/majordomo-info.html ------------------------------------------ This message was penned by the hand of Dom |
|
From: Jeff G. <jg...@po...> - 2005-12-08 21:09:29
|
Dominic Ijichi wrote: > Quoting Jeff Garzik <jg...@po...>: > > >>Erik Slagter wrote: >> >>>'guess You're not interested in having suspend/resume actually work on >>>laptops (or other PC's). That's your prerogative but imho it's a bit >>>narrow-minded to withhold this functionality from other people who >>>actually would like to have this working, just because you happen to not >>>like ACPI. >> >>It works just fine on laptops, with Jens' suspend/resume patch. > > > not on my fujitsu sonoma/ih6 based laptop it doesn't. in my travels trying to > fix this problem it appears there are many others it doesnt work for either. > suspend/resume is incredibly important for day-to-day practical use of a laptop, > particularly using linux. the sole reason i still have a windows partition is > because suspend doesnt work in linux and i'm sick of firing everything up again > 3 times a day. > > thank you very much to all on this list who are pursuing a solution sensibly and > not making unhelpful blanket statements against the most widely used laptop > chipset maker - *particularly* when they are actively contributing to > development on this list. we (laptop users) dont care about religious > standpoints, we just want it to work. I've personally tested it on fuji ich5 and ich6 laptops. What model do you have? What kernel version did you test? When did you apply the suspend/resume patch? Jeff |
|
From: Dominic I. <do...@ij...> - 2005-12-08 21:34:30
|
Quoting Jeff Garzik <jg...@po...>: > Dominic Ijichi wrote: > > Quoting Jeff Garzik <jg...@po...>: > > > > > >>Erik Slagter wrote: > >> > >>>'guess You're not interested in having suspend/resume actually work on > >>>laptops (or other PC's). That's your prerogative but imho it's a bit > >>>narrow-minded to withhold this functionality from other people who > >>>actually would like to have this working, just because you happen to not > >>>like ACPI. > >> > >>It works just fine on laptops, with Jens' suspend/resume patch. > > > > > > not on my fujitsu sonoma/ih6 based laptop it doesn't. in my travels trying > to > > fix this problem it appears there are many others it doesnt work for > either. > > suspend/resume is incredibly important for day-to-day practical use of a > laptop, > > particularly using linux. the sole reason i still have a windows partition > is > > because suspend doesnt work in linux and i'm sick of firing everything up > again > > 3 times a day. > > > > thank you very much to all on this list who are pursuing a solution > sensibly and > > not making unhelpful blanket statements against the most widely used laptop > > chipset maker - *particularly* when they are actively contributing to > > development on this list. we (laptop users) dont care about religious > > standpoints, we just want it to work. > > I've personally tested it on fuji ich5 and ich6 laptops. What model do > you have? What kernel version did you test? When did you apply the > suspend/resume patch? N3510, 60gb sata model. 2.6.14,2.6.15-rc[1..5], with and without mm patches, and various suspend patches sent to me by people on the linux-ide list. in particular, Jens Axboe's libata_suspend.patch and Randy Dunlap's patches here: http://www.xenotime.net/linux/SATA/2.6.15-rc/, plus patches from your site: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/. every permutation and combination tried! all with same result - laptop resumes but hangs on first disk access. cheers dom ------------------------------------------ This message was penned by the hand of Dom |
|
From: Randy D. <ran...@li...> - 2005-12-08 21:28:39
|
On Thu, 08 Dec 2005 15:43:44 -0500 Jeff Garzik <jg...@po...> wrote: > Erik Slagter wrote: > > 'guess You're not interested in having suspend/resume actually work on > > laptops (or other PC's). That's your prerogative but imho it's a bit > > narrow-minded to withhold this functionality from other people who > > actually would like to have this working, just because you happen to not > > like ACPI. > > It works just fine on laptops, with Jens' suspend/resume patch. I have seen a few other people report that SATA suspend/resume works when using Jens's patch. However, this is done without the benefit of what the additional ACPI methods provide thru _GTF and writing those taskfiles, such as: - enabling write cache - enabling device power management - freezing the security password so even when it "works," those people may be missing some performance benefits or power savings or security. In any case, I'm glad to see some discussion of this. --- ~Randy |
|
From: Erik S. <er...@sl...> - 2005-12-09 09:45:33
Attachments:
smime.p7s
|
On Thu, 2005-12-08 at 13:31 -0800, Randy Dunlap wrote: > > It works just fine on laptops, with Jens' suspend/resume patch. >=20 > I have seen a few other people report that SATA suspend/resume > works when using Jens's patch. However, this is done without > the benefit of what the additional ACPI methods provide thru > _GTF and writing those taskfiles, such as: > - enabling write cache > - enabling device power management > - freezing the security password >=20 > so even when it "works," those people may be missing some > performance benefits or power savings or security. >=20 > In any case, I'm glad to see some discussion of this. IMHO available infrastructure (and hardware abstraction!) should be used instead of being stubborn and pretend we know everything about any hardware. Of course this all to a certain degree (=3D=3D as long as no DRM is involved). |
|
From: Jens A. <ax...@su...> - 2005-12-09 10:38:25
|
On Fri, Dec 09 2005, Erik Slagter wrote: > On Thu, 2005-12-08 at 13:31 -0800, Randy Dunlap wrote: > > > > It works just fine on laptops, with Jens' suspend/resume patch. > > > > I have seen a few other people report that SATA suspend/resume > > works when using Jens's patch. However, this is done without > > the benefit of what the additional ACPI methods provide thru > > _GTF and writing those taskfiles, such as: > > - enabling write cache > > - enabling device power management > > - freezing the security password > > > > so even when it "works," those people may be missing some > > performance benefits or power savings or security. > > > > In any case, I'm glad to see some discussion of this. > > IMHO available infrastructure (and hardware abstraction!) should be used > instead of being stubborn and pretend we know everything about any > hardware. It's not about being stubborn, it's about maintaining and working on a clean design. The developers have to do that, not the users. So forgive people for being a little cautious about shuffling all sorts of ACPI into the scsi core and/or drivers. We always need to think long term here. Users don't care about the maintainability and cleanliness of the code, they really just want it to work. Which is perfectly understandable. -- Jens Axboe |
|
From: Erik S. <er...@sl...> - 2005-12-09 10:45:56
Attachments:
smime.p7s
|
On Fri, 2005-12-09 at 11:39 +0100, Jens Axboe wrote: > > IMHO available infrastructure (and hardware abstraction!) should be use= d > > instead of being stubborn and pretend we know everything about any > > hardware. >=20 > It's not about being stubborn, it's about maintaining and working on a > clean design. The developers have to do that, not the users. So forgive > people for being a little cautious about shuffling all sorts of ACPI > into the scsi core and/or drivers. We always need to think long term > here. >=20 > Users don't care about the maintainability and cleanliness of the code, > they really just want it to work. Which is perfectly understandable. I perfectly understand that, what I do object against, is rejecting a concept (like this) totally because the developers(?) do not like the mechanism that's used (although ACPI is used everywhere else in the kernel). At least there might be some discussion where this sort of code belongs to make the design clean and easily maintainable, instead of instantly completely rejecting the concept, because OP simply doesn't like acpi. |
|
From: Jeff G. <jg...@po...> - 2005-12-09 11:28:16
|
Erik Slagter wrote: > On Fri, 2005-12-09 at 11:39 +0100, Jens Axboe wrote: > > >>>IMHO available infrastructure (and hardware abstraction!) should be used >>>instead of being stubborn and pretend we know everything about any >>>hardware. >> >>It's not about being stubborn, it's about maintaining and working on a >>clean design. The developers have to do that, not the users. So forgive >>people for being a little cautious about shuffling all sorts of ACPI >>into the scsi core and/or drivers. We always need to think long term >>here. >> >>Users don't care about the maintainability and cleanliness of the code, >>they really just want it to work. Which is perfectly understandable. > > > I perfectly understand that, what I do object against, is rejecting a > concept (like this) totally because the developers(?) do not like the > mechanism that's used (although ACPI is used everywhere else in the > kernel). At least there might be some discussion where this sort of code > belongs to make the design clean and easily maintainable, instead of > instantly completely rejecting the concept, because OP simply doesn't > like acpi. Framing the discussion in terms of "like" and "dislike" proves you understand nothing about the issues -- and lacking that understanding, you feel its best to insult people. libata suspend/resume needs to work on platforms without ACPI, such as ppc64. libata reset needs to work even when BIOS is not present at all. And by definition, anything that is done in ACPI can be done in the driver. The only thing libata cannot know is BIOS defaults. Anything else libata doesn't know is a driver bug. We already know there are a ton of settings that should be saved/restored, which is not done now. Until that code is added to libata, talk of ACPI is premature. Further, even the premature patch was obviously unacceptable, because you don't patch ACPI code directly into libata and SCSI. That's the wrong approach. Jeff |
|
From: Erik S. <er...@sl...> - 2005-12-09 11:35:37
Attachments:
smime.p7s
|
On Fri, 2005-12-09 at 06:27 -0500, Jeff Garzik wrote: > > I perfectly understand that, what I do object against, is rejecting a > > concept (like this) totally because the developers(?) do not like the > > mechanism that's used (although ACPI is used everywhere else in the > > kernel). At least there might be some discussion where this sort of cod= e > > belongs to make the design clean and easily maintainable, instead of > > instantly completely rejecting the concept, because OP simply doesn't > > like acpi. >=20 > Framing the discussion in terms of "like" and "dislike" proves you=20 > understand nothing about the issues -- and lacking that understanding,=20 > you feel its best to insult people. >=20 > libata suspend/resume needs to work on platforms without ACPI, such as=20 > ppc64. libata reset needs to work even when BIOS is not present at all.=20 > And by definition, anything that is done in ACPI can be done in the=20 > driver. >=20 > The only thing libata cannot know is BIOS defaults. Anything else=20 > libata doesn't know is a driver bug. We already know there are a ton of=20 > settings that should be saved/restored, which is not done now. Until=20 > that code is added to libata, talk of ACPI is premature. Further, even=20 > the premature patch was obviously unacceptable, because you don't patch=20 > ACPI code directly into libata and SCSI. That's the wrong approach. I case this (still) isn't clear, I am addressing the attitude of "It's ACPI so it's not going to be used, period". About the exact technical implementation, I do not have an opinion, because I don't have the knowledge. BTW I try to not actually insult people (as others here seems to like to do). If someone really feels offended, my apologies. I cannot hide some irritation though. |
|
From: Christoph H. <hc...@in...> - 2005-12-09 11:40:31
|
On Fri, Dec 09, 2005 at 12:35:27PM +0100, Erik Slagter wrote: > I case this (still) isn't clear, I am addressing the attitude of "It's > ACPI so it's not going to be used, period". We're not gonna patch support for any braindead firmware interface into the scsi midlayer (and trust me, there's a shitload more of them than just acpi). Now please sod off. |
|
From: Jens A. <ax...@su...> - 2005-12-09 11:45:23
|
On Fri, Dec 09 2005, Erik Slagter wrote: > I case this (still) isn't clear, I am addressing the attitude of "It's > ACPI so it's not going to be used, period". The problem seems to be that you are misunderstanding the 'attitude', which was mainly based on the initial patch sent out which stuffs acpi directly in everywhere. That seems to be a good trigger for curt/direct replies. -- Jens Axboe |
|
From: Erik S. <er...@sl...> - 2005-12-09 12:01:44
Attachments:
smime.p7s
|
On Fri, 2005-12-09 at 12:46 +0100, Jens Axboe wrote: > On Fri, Dec 09 2005, Erik Slagter wrote: > > I case this (still) isn't clear, I am addressing the attitude of "It's > > ACPI so it's not going to be used, period". >=20 > The problem seems to be that you are misunderstanding the 'attitude', > which was mainly based on the initial patch sent out which stuffs acpi > directly in everywhere. That seems to be a good trigger for curt/direct > replies. This is the post I object to: [http://marc.theaimsgroup.com/?l=3Dlinux-scsi&m=3D113404894931377&w=3D2] >> Ok. What's the right layer to do this? The current ACPI/anything >> else glue depends on specific knowledge about the bus concerned, and >> needs callbacks registered before devices are added to that bus. >> Doing it in the sata layer would have the potential for unhappiness >> on mixed sata/scsi machines. > Don't do it at all. We don't need to fuck up every layer and driver for > intels braindamage. |
|
From: Jens A. <ax...@su...> - 2005-12-09 12:06:07
|
On Fri, Dec 09 2005, Erik Slagter wrote: > On Fri, 2005-12-09 at 12:46 +0100, Jens Axboe wrote: > > On Fri, Dec 09 2005, Erik Slagter wrote: > > > I case this (still) isn't clear, I am addressing the attitude of "It's > > > ACPI so it's not going to be used, period". > > > > The problem seems to be that you are misunderstanding the 'attitude', > > which was mainly based on the initial patch sent out which stuffs acpi > > directly in everywhere. That seems to be a good trigger for curt/direct > > replies. > > This is the post I object to: > [http://marc.theaimsgroup.com/?l=linux-scsi&m=113404894931377&w=2] I would imagine, and that is what I'm explaining to you. Can we please just let this die? Thanks. -- Jens Axboe |
|
From: Douglas G. <do...@to...> - 2005-12-10 02:17:42
|
Jeff Garzik wrote: > Erik Slagter wrote: > >> On Fri, 2005-12-09 at 11:39 +0100, Jens Axboe wrote: >> >> >>>> IMHO available infrastructure (and hardware abstraction!) should be >>>> used >>>> instead of being stubborn and pretend we know everything about any >>>> hardware. >>> >>> >>> It's not about being stubborn, it's about maintaining and working on a >>> clean design. The developers have to do that, not the users. So forgive >>> people for being a little cautious about shuffling all sorts of ACPI >>> into the scsi core and/or drivers. We always need to think long term >>> here. >>> >>> Users don't care about the maintainability and cleanliness of the code, >>> they really just want it to work. Which is perfectly understandable. >> >> >> >> I perfectly understand that, what I do object against, is rejecting a >> concept (like this) totally because the developers(?) do not like the >> mechanism that's used (although ACPI is used everywhere else in the >> kernel). At least there might be some discussion where this sort of code >> belongs to make the design clean and easily maintainable, instead of >> instantly completely rejecting the concept, because OP simply doesn't >> like acpi. > > > Framing the discussion in terms of "like" and "dislike" proves you > understand nothing about the issues -- and lacking that understanding, > you feel its best to insult people. Jeff, Point of order. My email record of this thread indicates that it was Christoph Hellwig: http://marc.theaimsgroup.com/?l=linux-scsi&m=113404894931377&w=2 who initially lowered the tone. Just to prove that was not an aberration he followed that up with this email: http://marc.theaimsgroup.com/?l=linux-scsi&m=113404957727924&w=2 and there are several others. Given Christoph's posts I find those of Matthew Garrett and Erik Slagter pretty well considered and I fail to see what warranted the "you feel its best to insult people" line above. I used to think that SCSI was the most maligned part of the linux kernel, but that no longer seems to be the case. Can ACPI be really that bad ... Doug Gilbert > libata suspend/resume needs to work on platforms without ACPI, such as > ppc64. libata reset needs to work even when BIOS is not present at all. > And by definition, anything that is done in ACPI can be done in the > driver. > > The only thing libata cannot know is BIOS defaults. Anything else > libata doesn't know is a driver bug. We already know there are a ton of > settings that should be saved/restored, which is not done now. Until > that code is added to libata, talk of ACPI is premature. Further, even > the premature patch was obviously unacceptable, because you don't patch > ACPI code directly into libata and SCSI. That's the wrong approach. > > Jeff > > > - > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to maj...@vg... > More majordomo info at http://vger.kernel.org/majordomo-info.html > |
|
From: Matthew W. <ma...@wi...> - 2005-12-14 20:52:29
|
On Sat, Dec 10, 2005 at 12:19:01PM +1000, Douglas Gilbert wrote: > I used to think that SCSI was the most maligned part of the > linux kernel, but that no longer seems to be the case. > Can ACPI be really that bad ... Yes. |
|
From: Jens A. <ax...@su...> - 2005-12-09 11:29:34
|
On Fri, Dec 09 2005, Erik Slagter wrote: > On Fri, 2005-12-09 at 11:39 +0100, Jens Axboe wrote: > > > > IMHO available infrastructure (and hardware abstraction!) should be used > > > instead of being stubborn and pretend we know everything about any > > > hardware. > > > > It's not about being stubborn, it's about maintaining and working on a > > clean design. The developers have to do that, not the users. So forgive > > people for being a little cautious about shuffling all sorts of ACPI > > into the scsi core and/or drivers. We always need to think long term > > here. > > > > Users don't care about the maintainability and cleanliness of the code, > > they really just want it to work. Which is perfectly understandable. > > I perfectly understand that, what I do object against, is rejecting a > concept (like this) totally because the developers(?) do not like the > mechanism that's used (although ACPI is used everywhere else in the > kernel). At least there might be some discussion where this sort of code > belongs to make the design clean and easily maintainable, instead of > instantly completely rejecting the concept, because OP simply doesn't > like acpi. Not to put words in anyones mouth, but the rejection is mainly based on the concept of stuffing acpi directly into the SCSI core where it clearly doesn't belong. I don't think anyone is against utilizing ACPI (if useful/required) for suspend+resume as a concept, even if lots of people have reservations on ACPI in generel. -- Jens Axboe |
|
From: Mark L. <li...@rt...> - 2005-12-09 03:28:48
|
Jeff Garzik wrote: > Erik Slagter wrote: > >> 'guess You're not interested in having suspend/resume actually work on >> laptops (or other PC's). That's your prerogative but imho it's a bit >> narrow-minded to withhold this functionality from other people who >> actually would like to have this working, just because you happen to not >> like ACPI. > > > It works just fine on laptops, with Jens' suspend/resume patch. > > Jeff No. I use it on my two modern laptops with great success, but only with *certain* hard disks. When I replace the ultra modern 100GB drive in my machine with a slightly older 30GB drive, suspend/resume no longer work. No other changes. Other users have reported similar experiences to me. We really REALLY need libata to get fixed for this stuff. Cheers |
Thanks for helping keep SourceForge clean.
X