[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B4CA666.1050505@imap.cc>
Date: Tue, 12 Jan 2010 17:42:14 +0100
From: Tilman Schmidt <tilman@...p.cc>
To: Greg KH <gregkh@...e.de>
CC: Stephen Rothwell <sfr@...b.auug.org.au>,
LKML <linux-kernel@...r.kernel.org>, netdev@...r.kernel.org,
Karsten Keil <isdn@...ux-pingi.de>,
isdn4linux@...tserv.isdn4linux.de
Subject: Re: Can we remove pci_find_device() yet?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 2010-01-11 21:01 schrieb Greg KH:
> On Mon, Jan 11, 2010 at 08:46:50PM +0100, Tilman Schmidt wrote:
>>
>> Just an idea - as a stopgap measure, couldn't pci_find_device() be made
>> a private function of the HiSax drivers? That way, the remainder of the
>> kernel won't be polluted by it anymore, and the PCI_LEGACY config option
>> can be dropped. Something like this quick and dirty hack:
>
> Close, but if you do this, please name the function
> hisax_find_pci_device() or something, and change the drivers to use it
Sorry, but no. That would drag me into the checkpatch.pl swamp,
a place I know well enough by now to avoid it whenever possible.
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.
So I'll drop that idea. If someone else wants to pick it up,
feel free to do so.
Regards,
Tilman
- --
Tilman Schmidt E-Mail: tilman@...p.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/
iEYEARECAAYFAktMpmYACgkQQ3+did9BuFuJKgCggRImZ3NOTmCJUpUktreervtz
fegAniAexJirz3p/AXPB6EpsCEJn3hPL
=QwUB
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists