Prev: [PATCH] drivers/net/skfp/skfddi.c: use %pMF to show MAC address
Next: elf coredump: Add extended numbering support
From: Greg KH on 12 Jan 2010 16:30
On Tue, Jan 12, 2010 at 08:53:25PM +0000, Ben Hutchings wrote:
> > How do I do that properly, in terms of PCI API?
>
> One of our older controllers had a similar design error in that the two
> functions would sometimes have to be reset together. The way we look
> for the second function is:
>
> dev = pci_dev_get(dev1);
> while ((dev = pci_get_device(vendor_id, device_id, dev))) {
> if (dev->bus == dev1->bus &&
> dev->devfn == dev1->devfn + 1) {
> dev2 = dev;
> break;
> }
> }
>
> I assume this is 'properly' since no-one has told me otherwise.

As of right now, yes, this is the "correct" way to do this.

I need to dig up the "let multiple drivers bind to a single device"
patch set to make this not necessary in the future.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Tilman Schmidt on 13 Jan 2010 04:10
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 2010-01-12 18:39 schrieb Greg KH:
> On Tue, Jan 12, 2010 at 05:42:14PM +0100, Tilman Schmidt wrote:
[...]
>> Many of the calls to pci_find_device() have checkpatch problems
>> which of course do not go away by just substituting another
>> function name, so I would be obliged to restructure all those
>> call sites by hand for the sake of "not introducing new code
>> with checkpatch problems". BTDT.
>
> No you would not, don't be crazy. Modfying a single line to rename a
> function from one thing to another could never be decreed as a "don't
> add bad code". And if someone says it is, well, you just found someone
> who doesn't know what they are doing :)

Ok. I do hope you are right, and my extrapolation from past
experience was wrong.

> Please continue with this idea, it's sane, and valid.

Alright, will do. Patch will follow later today, SCJ. Let's see
what the checkpatch police will say.

Regards,
Tilman

- --
Tilman Schmidt E-Mail: tilman(a)imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge�ffnet mindestens haltbar bis: (siehe R�ckseite)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktNjCQACgkQQ3+did9BuFsmMwCfReQ/mHQUApkpRWJZIG16PmvI
vO4Anj/A4kSwddg+RZV2Uj5LVUNlsBD3
=LxhW
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Krzysztof Halasa on 13 Jan 2010 10:10
Greg KH <gregkh(a)suse.de> writes:

>> One of our older controllers had a similar design error in that the two
>> functions would sometimes have to be reset together. The way we look
>> for the second function is:
>>
>> dev = pci_dev_get(dev1);
>> while ((dev = pci_get_device(vendor_id, device_id, dev))) {
>> if (dev->bus == dev1->bus &&
>> dev->devfn == dev1->devfn + 1) {
>> dev2 = dev;
>> break;
>> }
>> }
>>
>> I assume this is 'properly' since no-one has told me otherwise.
>
> As of right now, yes, this is the "correct" way to do this.
>
> I need to dig up the "let multiple drivers bind to a single device"
> patch set to make this not necessary in the future.

Ben and Greg, thanks.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 14 Jan 2010 05:20
Greg KH <gregkh(a)suse.de> writes:
>
> Close, but if you do this, please name the function
> hisax_find_pci_device() or something, and change the drivers to use it
> instead. Also put a big fat warning in the function that calling this
> is unsafe for any PCI hotplug type machine.

It would be better to enforce this constraint at runtime.

e.g. set some global variable that forbids device removal
and warn in the kernel log. In theory this could be also
done per device, but I guess that would be more effort.

Of course it cannot prevent the user from really removing
a device, but at least the pci_dev could stay around.

-Andi
--
ak(a)linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 14 Jan 2010 06:00
> e.g. set some global variable that forbids device removal
> and warn in the kernel log. In theory this could be also
> done per device, but I guess that would be more effort.

There is a simpler way to do that, which is to just leak a reference in
the hisax_find_pci_device hack. The pci_dev won't be going anywhere then.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: [PATCH] drivers/net/skfp/skfddi.c: use %pMF to show MAC address
Next: elf coredump: Add extended numbering support