linux-kernel - Re: [linux-usb-devel] [FEATURE REQUEST] Transparent hot plugging of root file system on portable storage devices.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 6 Jan 2008 23:44:29 +0100
From:	Pavel Machek <pavel@....cz>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Oliver Neukum <oliver@...kum.org>,
	Raymano Garibaldi <raymano@...nos.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Denys Vlasenko <vda.linux@...glemail.com>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	USB development list <linux-usb-devel@...ts.sourceforge.net>
Subject: Re: [linux-usb-devel] [FEATURE REQUEST] Transparent hot plugging
	of root file system on portable storage devices.

On Sun 2008-01-06 17:26:17, Alan Stern wrote:
> On Sun, 6 Jan 2008, Oliver Neukum wrote:
> 
> > Am Sonntag 06 Januar 2008 schrieb Alan Stern:
> > > What about people who want to suspend to RAM instead of hibernating and
> > > _do_ want to unplug the USB device containing their root filesystem
> > > while the machine is asleep? 

Ok, I guess I'm lost here. That sounds like a nice way to do
self-leg-shooting. Are there such people?

> > >  In this case we will _know_ that the
> > > power session has been interrupted, but USB Persist won't activate
> > > because the host controller never lost power.
> > 
> > Would it be hard to force the persist feature on for a replugged device?
> 
> Right now the persist feature is enabled by a per-device boolean flag.  
> In theory the flag could accept 3 values: off, on if power was lost,
> or on for any resume transition.  This would not be a hard change.

But do we need it?

Did you progress on "usb-storage-autosuspend"?

Here are my hacks to try to get SATA to survive autosuspend;
unfortunately they do not work :-(.
									Pavel



diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 54f38c2..21e6709 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1808,8 +1808,22 @@ static void ahci_thaw(struct ata_port *a
 	writel(pp->intr_mask, port_mmio + PORT_IRQ_MASK);
 }
 
+struct pci_dev *my_pdev;
+
 static void ahci_error_handler(struct ata_port *ap)
 {
+	struct ata_host *host = ap->host;
+	int rc;
+	extern int slept;
+	
+	if (slept) {
+		printk("ahci_error_handler: Resuming...\n");
+		rc =ahci_pci_device_resume(my_pdev);
+		     printk("ahci: bad %d\n", rc);
+
+		printk("ahci_error_handler: Device resumed?\n");
+	}
+
 	if (!(ap->pflags & ATA_PFLAG_FROZEN)) {
 		/* restart engine */
 		ahci_stop_engine(ap);
@@ -1945,7 +1959,7 @@ static int ahci_pci_device_resume(struct
 	if (rc)
 		return rc;
 
-	if (pdev->dev.power.power_state.event == PM_EVENT_SUSPEND) {
+	if (1) {
 		rc = ahci_reset_controller(host);
 		if (rc)
 			return rc;
@@ -2179,6 +2193,7 @@ static void ahci_p5wdh_workaround(struct
 	}
 }
 
+
 static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 {
 	static int printed_version;
@@ -2190,6 +2205,7 @@ static int ahci_init_one(struct pci_dev 
 	int i, rc;
 
 	VPRINTK("ENTER\n");
+	my_pdev = pdev;
 
 	WARN_ON(ATA_MAX_QUEUE > AHCI_MAX_CMDS);
 
@@ -2283,8 +2299,11 @@ static int ahci_init_one(struct pci_dev 
 	ahci_print_info(host);
 
 	pci_set_master(pdev);
-	return ata_host_activate(host, pdev->irq, ahci_interrupt, IRQF_SHARED,
+
+	rc = ata_host_activate(host, pdev->irq, ahci_interrupt, IRQF_SHARED,
 				 &ahci_sht);
+	pci_save_state(pdev);
+	return rc;
 }
 
 static int __init ahci_init(void)

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/