Re: [GIT PULL]: firmware patches for building firmware into kernel

[Jaswinder Singh]

Hello Dave,

On Thu, 2008-08-07 at 22:59 -0400, David Dillow wrote:
> > 
> > Do you think we still need above comments ?
> 
> No, the comments will be unneeded, but you don't need an extra function
> to handle this, and I'm not real keen about the release_firmware_all()
> interface -- it doesn't match up with the get/put semantics of the
> reference count.
> 
> I don't like releasing the firmware before the pci_unregister_driver()
> call. I worry about ordering issues during cleanup, though I'll admit I
> have not yet researched if it will be a problem. In any event, if you're
> going to request it once per adapter in typhoon_init_one(), then it
> should be in the per-device struct, and released in
> typhoon_remove_one().
> 

Here is updated patch :

diff --git a/drivers/net/typhoon.c b/drivers/net/typhoon.c
index 2a26ba5..1638e87 100644
--- a/drivers/net/typhoon.c
+++ b/drivers/net/typhoon.c
@@ -2615,6 +2615,9 @@ typhoon_remove_one(struct pci_dev *pdev)
 	pci_set_power_state(pdev, PCI_D0);
 	pci_restore_state(pdev);
 	typhoon_reset(tp->ioaddr, NoWait);
+
+	release_firmware(typhoon_fw);
+
 	pci_iounmap(pdev, tp->ioaddr);
 	pci_free_consistent(pdev, sizeof(struct typhoon_shared),
 			    tp->shared, tp->shared_dma);
@@ -2645,8 +2648,6 @@ typhoon_init(void)
 static void __exit
 typhoon_cleanup(void)
 {
-	release_firmware_all(typhoon_fw);
-
 	pci_unregister_driver(&typhoon_driver);
 }
 


> Drop the typhoon patches, and once you fix the problems in the core,
> I'll respin the patch in a style I'm comfortable with. It will also need
> to be tested before it goes upstream.
> 

I can understand you are very worried about typhoon.
But this is only first version of patches. This will goto David
WoodHouse tree and he will again revise it.

And driver is yours you can change it as per your comfort, No one can
stop you or typhoon ;)

Thank you,

Jaswinder Singh.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/