lkml.org 
[lkml]   [2013]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] staging/comedi: Move comedi_pci_auto_unconfig to drivers.c
On 2013/01/24 09:30 PM, Peter Huewe wrote:
> Am Donnerstag, 24. Januar 2013, 11:02:35 schrieb Ian Abbott:
>> On 2013-01-22 23:03, Peter Huewe wrote:
>>> Since comedi_pci_auto_unconfig cannot be inlined anymore after
>>>
>>> staging/comedi: Use comedi_pci_auto_unconfig directly for
>>> pci_driver.remove
>>>
>>> is applied, it makes sense to move it drivers.c
>>>
>>> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
>>> ---
>>>
>
>> Embarassingly (for me) I submitted a patch to do the exact opposite
>> previously, but I've no problem doing it this way if it saves some code.
>
> Hi Ian,
> ;)

Hi.

> If you think it's cleaner the way it is currently we can leave it like that.
> Especially if you think some driver might actually do something in the remove
> function (in the future).

Well I was only using the inlined version to eliminate a function call
overhead, but your method eliminates a function call overhead in a
different way (for the majority of drivers whose remove function
consists solely of a call to comedi_pci_auto_unconfig()) and has the
benefit of removing lots of virtually identical function definitions.

If drivers want to do something else in the remove function, they still
have the option of doing that.

> However if we could also find a way to remove all the probe function stuff as
> well we should remove it.
> Most (comedi pci) drivers simply call comedi_pci_auto_config and not much more
> - but I'm currently not sure how to do this ;)

I can think of a couple of ways, but I don't like either of them. The
difficulty is passing through the comedi driver's context (the struct
comedi_driver) to the comedi core during the probe.

One way would be to use a variant of the module_comedi_pci_driver()
macro that also creates a probe function that just calls
comedi_pci_auto_config(), and define another macro to retrieve the name
of that function (for initializing the .probe entry). This only reduces
the number of source lines a little bit, not the amount of amount of
code generated, and is a little obfuscating.

Another way would be to point the driver_data of each struct
pci_device_id to the struct comedi_driver, and have a common probe
function that gets uses that information. That might eliminate one
small probe function from lots of modules, but makes the PCI device
table in those modules a lot uglier.

--
-=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-


\
 
 \ /
  Last update: 2013-01-25 14:21    [W:0.049 / U:24.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site