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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F50FE1B.7090008@intel.com>
Date:	Fri, 02 Mar 2012 17:06:35 +0000
From:	Tadeusz Struk <tadeusz.struk@...el.com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
CC:	jbarnes@...tuousgeek.org, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org, linux-pci@...r.kernel.org,
	"Struk, Tadeusz" <tadeusz.struk@...el.com>
Subject: Re: [PATCH v2] Dynamically add and remove device specific reset functions

On 02/03/12 16:29, Bjorn Helgaas wrote:
> Where do you plan to add calls to pci_dev_specific_reset_add()?  In
> drivers?

Yes, I'm working on a driver for a device with SRIOV capability.
I'll call it from there.

> Did you consider adding a "reset" function pointer to struct
> pci_driver?  That might be more natural -- the reset function is right
> with all the other code that knows about the device, and there's no
> issue with looking up the correct reset function.
> With this patch, we sort of have two different ways to map
> vendor/device IDs to code: the usual pci_register_driver() approach,
> and this one using reset_list.  If pci_driver had a "reset" pointer,
> that would be used most of the time.  You might still need the
> reset_list for generic things, e.g., the reset_intel_generic_dev()
> function, but it would be a fallback.  It might look something like:
> 
>     struct pci_driver *drv = dev->driver;
> 
>     if (drv && drv->reset) {
>         drv->reset(dev);
>         return;
>     }
> 
>     list_for_each_entry(i, &reset_list, list) {
>         ...
> 

No, I didn't think about it.
This is good idea, but for me the pci_dev_specific_reset() works fine.

> In that case, you might not even need the ability to dynamically add
> things to the list, since the only things to add would be "generic"
> things that would be more static.
> 
> Perhaps this approach was previously discussed and discarded; if so, I
> missed it.
> 
> Bjorn

Do you want me to send another patch that fixes these minor issues you pointed out?
Thanks for you comments.
Tadeusz

--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.


--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ