If PCI boards are supported, use the module_comedi_pci_driver() macro
to register the module as a comedi driver and a PCI driver. Otherwise,
only ISA boards are supported to use the module_comedi_driver() macro
to register the module as a comedi driver.
Refactor the code a bit due to the use of the module_comedi_* macros.
Rename the comedi_driver and pci_driver variables as well as the pci
driver related functions for aesthetic reasons. This makes the skel
driver conform to the changes to the other comedi drivers.
Signed-off-by: H Hartley Sweeten <[email protected]>
Cc: Ian Abbott <[email protected]>
Cc: Frank Mori Hess <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/comedi/drivers/skel.c | 190 +++++++++++++++-------------------
1 file changed, 81 insertions(+), 109 deletions(-)
diff --git a/drivers/staging/comedi/drivers/skel.c b/drivers/staging/comedi/drivers/skel.c
index 6baac52..f9f1f5f 100644
--- a/drivers/staging/comedi/drivers/skel.c
+++ b/drivers/staging/comedi/drivers/skel.c
@@ -83,11 +83,7 @@ Configuration Options:
#define SKEL_START_AI_CONV 0
#define SKEL_AI_READ 0
-/*
- * Board descriptions for two imaginary boards. Describing the
- * boards in this way is optional, and completely driver-dependent.
- * Some drivers use arrays such as this, other do not.
- */
+/* Board specific information about the imaginary board */
struct skel_board {
const char *name;
int ai_chans;
@@ -95,34 +91,6 @@ struct skel_board {
int have_dio;
};
-static const struct skel_board skel_boards[] = {
- {
- .name = "skel-100",
- .ai_chans = 16,
- .ai_bits = 12,
- .have_dio = 1,
- },
- {
- .name = "skel-200",
- .ai_chans = 8,
- .ai_bits = 16,
- .have_dio = 0,
- },
-};
-
-/* This is used by modprobe to translate PCI IDs to drivers. Should
- * only be used for PCI and ISA-PnP devices */
-/* Please add your PCI vendor ID to comedidev.h, and it will be forwarded
- * upstream. */
-#define PCI_VENDOR_ID_SKEL 0xdafe
-static DEFINE_PCI_DEVICE_TABLE(skel_pci_table) = {
- { PCI_DEVICE(PCI_VENDOR_ID_SKEL, 0x0100) },
- { PCI_DEVICE(PCI_VENDOR_ID_SKEL, 0x0200) },
- { 0 }
-};
-
-MODULE_DEVICE_TABLE(pci, skel_pci_table);
-
/*
* Useful for shorthand access to the particular board structure
*/
@@ -149,42 +117,6 @@ struct skel_private {
*/
#define devpriv ((struct skel_private *)dev->private)
-/*
- * The struct comedi_driver structure tells the Comedi core module
- * which functions to call to configure/deconfigure (attach/detach)
- * the board, and also about the kernel module that contains
- * the device code.
- */
-static int skel_attach(struct comedi_device *dev, struct comedi_devconfig *it);
-static void skel_detach(struct comedi_device *dev);
-static struct comedi_driver driver_skel = {
- .driver_name = "dummy",
- .module = THIS_MODULE,
- .attach = skel_attach,
- .detach = skel_detach,
-/* It is not necessary to implement the following members if you are
- * writing a driver for a ISA PnP or PCI card */
- /* Most drivers will support multiple types of boards by
- * having an array of board structures. These were defined
- * in skel_boards[] above. Note that the element 'name'
- * was first in the structure -- Comedi uses this fact to
- * extract the name of the board without knowing any details
- * about the structure except for its length.
- * When a device is attached (by comedi_config), the name
- * of the device is given to Comedi, and Comedi tries to
- * match it by going through the list of board names. If
- * there is a match, the address of the pointer is put
- * into dev->board_ptr and driver->attach() is called.
- *
- * Note that these are not necessary if you can determine
- * the type of board in software. ISA PnP, PCI, and PCMCIA
- * devices are such boards.
- */
- .board_name = &skel_boards[0].name,
- .offset = sizeof(struct skel_board),
- .num_names = ARRAY_SIZE(skel_boards),
-};
-
static int skel_ai_rinsn(struct comedi_device *dev, struct comedi_subdevice *s,
struct comedi_insn *insn, unsigned int *data);
static int skel_ao_winsn(struct comedi_device *dev, struct comedi_subdevice *s,
@@ -611,57 +543,97 @@ static int skel_dio_insn_config(struct comedi_device *dev,
return insn->n;
}
+/*
+ * Board descriptions for two imaginary boards. Describing the
+ * boards in this way is optional, and completely driver-dependent.
+ * Some drivers use arrays such as this, other do not.
+ */
+static const struct skel_board skel_boards[] = {
+ {
+ .name = "skel-100",
+ .ai_chans = 16,
+ .ai_bits = 12,
+ .have_dio = 1,
+ }, {
+ .name = "skel-200",
+ .ai_chans = 8,
+ .ai_bits = 16,
+ .have_dio = 0,
+ },
+};
+
+/*
+ * The struct comedi_driver structure tells the Comedi core module
+ * which functions to call to configure/deconfigure (attach/detach)
+ * the board, and also about the kernel module that contains
+ * the device code.
+ */
+static struct comedi_driver skel_driver = {
+ .driver_name = "dummy",
+ .module = THIS_MODULE,
+ .attach = skel_attach,
+ .detach = skel_detach,
+ /*
+ * It is not necessary to implement the following members if
+ * you are writing a driver for a ISA PnP or PCI card
+ *
+ * Most drivers will support multiple types of boards by
+ * having an array of board structures. These were defined
+ * in skel_boards[] above. Note that the element 'name'
+ * was first in the structure -- Comedi uses this fact to
+ * extract the name of the board without knowing any details
+ * about the structure except for its length.
+ * When a device is attached (by comedi_config), the name
+ * of the device is given to Comedi, and Comedi tries to
+ * match it by going through the list of board names. If
+ * there is a match, the address of the pointer is put
+ * into dev->board_ptr and driver->attach() is called.
+ *
+ * Note that these are not necessary if you can determine
+ * the type of board in software. ISA PnP, PCI, and PCMCIA
+ * devices are such boards.
+ */
+ .board_name = &skel_boards[0].name,
+ .offset = sizeof(struct skel_board),
+ .num_names = ARRAY_SIZE(skel_boards),
+};
+
#ifdef CONFIG_COMEDI_PCI
-static int __devinit driver_skel_pci_probe(struct pci_dev *dev,
- const struct pci_device_id *ent)
+static int __devinit skel_pci_probe(struct pci_dev *dev,
+ const struct pci_device_id *ent)
{
- return comedi_pci_auto_config(dev, &driver_skel);
+ return comedi_pci_auto_config(dev, &skel_driver);
}
-static void __devexit driver_skel_pci_remove(struct pci_dev *dev)
+static void __devexit skel_pci_remove(struct pci_dev *dev)
{
comedi_pci_auto_unconfig(dev);
}
-static struct pci_driver driver_skel_pci_driver = {
- .id_table = skel_pci_table,
- .probe = &driver_skel_pci_probe,
- .remove = __devexit_p(&driver_skel_pci_remove)
+/*
+ * This is used by modprobe to translate PCI IDs to drivers.
+ * Should only be used for PCI and ISA-PnP devices
+ *
+ * Please add your PCI vendor ID to comedidev.h, and it will
+ * be forwarded upstream.
+ */
+#define PCI_VENDOR_ID_SKEL 0xdafe
+static DEFINE_PCI_DEVICE_TABLE(skel_pci_table) = {
+ { PCI_DEVICE(PCI_VENDOR_ID_SKEL, 0x0100) },
+ { PCI_DEVICE(PCI_VENDOR_ID_SKEL, 0x0200) },
+ { 0 }
};
+MODULE_DEVICE_TABLE(pci, skel_pci_table);
-static int __init driver_skel_init_module(void)
-{
- int retval;
-
- retval = comedi_driver_register(&driver_skel);
- if (retval < 0)
- return retval;
-
- driver_skel_pci_driver.name = (char *)driver_skel.driver_name;
- return pci_register_driver(&driver_skel_pci_driver);
-}
-
-static void __exit driver_skel_cleanup_module(void)
-{
- pci_unregister_driver(&driver_skel_pci_driver);
- comedi_driver_unregister(&driver_skel);
-}
-
-module_init(driver_skel_init_module);
-module_exit(driver_skel_cleanup_module);
+static struct pci_driver skel_pci_driver = {
+ .name = "dummy",
+ .id_table = skel_pci_table,
+ .probe = skel_pci_probe,
+ .remove = __devexit_p(skel_pci_remove),
+};
+module_comedi_pci_driver(skel_driver, skel_pci_driver);
#else
-static int __init driver_skel_init_module(void)
-{
- return comedi_driver_register(&driver_skel);
-}
-
-static void __exit driver_skel_cleanup_module(void)
-{
- comedi_driver_unregister(&driver_skel);
-}
-
-module_init(driver_skel_init_module);
-module_exit(driver_skel_cleanup_module);
+module_comedi_driver(skel_driver);
#endif
MODULE_AUTHOR("Comedi http://www.comedi.org");
--
1.7.11
On Wed, Jun 20, 2012 at 03:56:50PM -0700, H Hartley Sweeten wrote:
> If PCI boards are supported, use the module_comedi_pci_driver() macro
> to register the module as a comedi driver and a PCI driver. Otherwise,
> only ISA boards are supported to use the module_comedi_driver() macro
> to register the module as a comedi driver.
>
> Refactor the code a bit due to the use of the module_comedi_* macros.
>
> Rename the comedi_driver and pci_driver variables as well as the pci
> driver related functions for aesthetic reasons. This makes the skel
> driver conform to the changes to the other comedi drivers.
>
> Signed-off-by: H Hartley Sweeten <[email protected]>
> Cc: Ian Abbott <[email protected]>
> Cc: Frank Mori Hess <[email protected]>
This patch fails to apply:
patching file drivers/staging/comedi/drivers/skel.c
Hunk #4 FAILED at 543.
1 out of 4 hunks FAILED -- saving rejects to file drivers/staging/comedi/drivers/skel.c.rej
Care to rediff it and resend?
thanks,
greg k-h
On Wednesday, June 20, 2012 4:13 PM, Greg KH wrote:
> On Wed, Jun 20, 2012 at 03:56:50PM -0700, H Hartley Sweeten wrote:
>> If PCI boards are supported, use the module_comedi_pci_driver() macro
>> to register the module as a comedi driver and a PCI driver. Otherwise,
>> only ISA boards are supported to use the module_comedi_driver() macro
>> to register the module as a comedi driver.
>>
>> Refactor the code a bit due to the use of the module_comedi_* macros.
>>
>> Rename the comedi_driver and pci_driver variables as well as the pci
>> driver related functions for aesthetic reasons. This makes the skel
>> driver conform to the changes to the other comedi drivers.
>>
>> Signed-off-by: H Hartley Sweeten <[email protected]>
>> Cc: Ian Abbott <[email protected]>
>> Cc: Frank Mori Hess <[email protected]>
>
> This patch fails to apply:
>
> patching file drivers/staging/comedi/drivers/skel.c
> Hunk #4 FAILED at 543.
> 1 out of 4 hunks FAILED -- saving rejects to file drivers/staging/comedi/drivers/skel.c.rej
>
> Care to rediff it and resend?
Hmm. It was based on next-20120620 and created with git format-patch.
Do you have any other patches to that file in your staging tree that
have not reached the next tree yet?
Regardless, I have some other cleanup patches for that file. I'll
put them together as a series and repost it later.
Thanks,
Hartley
On Wed, Jun 20, 2012 at 06:16:52PM -0500, H Hartley Sweeten wrote:
> On Wednesday, June 20, 2012 4:13 PM, Greg KH wrote:
> > On Wed, Jun 20, 2012 at 03:56:50PM -0700, H Hartley Sweeten wrote:
> >> If PCI boards are supported, use the module_comedi_pci_driver() macro
> >> to register the module as a comedi driver and a PCI driver. Otherwise,
> >> only ISA boards are supported to use the module_comedi_driver() macro
> >> to register the module as a comedi driver.
> >>
> >> Refactor the code a bit due to the use of the module_comedi_* macros.
> >>
> >> Rename the comedi_driver and pci_driver variables as well as the pci
> >> driver related functions for aesthetic reasons. This makes the skel
> >> driver conform to the changes to the other comedi drivers.
> >>
> >> Signed-off-by: H Hartley Sweeten <[email protected]>
> >> Cc: Ian Abbott <[email protected]>
> >> Cc: Frank Mori Hess <[email protected]>
> >
> > This patch fails to apply:
> >
> > patching file drivers/staging/comedi/drivers/skel.c
> > Hunk #4 FAILED at 543.
> > 1 out of 4 hunks FAILED -- saving rejects to file drivers/staging/comedi/drivers/skel.c.rej
> >
> > Care to rediff it and resend?
>
> Hmm. It was based on next-20120620 and created with git format-patch.
>
> Do you have any other patches to that file in your staging tree that
> have not reached the next tree yet?
Possibly, depending on when -next was created, I did just apply a bunch
of other patches a few hours ago.
> Regardless, I have some other cleanup patches for that file. I'll
> put them together as a series and repost it later.
That would be great, thanks.
greg k-h
On Wednesday, June 20, 2012 4:24 PM, Greg KH wrote:
> On Wed, Jun 20, 2012 at 06:16:52PM -0500, H Hartley Sweeten wrote:
>> Hmm. It was based on next-20120620 and created with git format-patch.
>>
>> Do you have any other patches to that file in your staging tree that
>> have not reached the next tree yet?
>
> Possibly, depending on when -next was created, I did just apply a bunch
> of other patches a few hours ago.
>
>> Regardless, I have some other cleanup patches for that file. I'll
>> put them together as a series and repost it later.
>
> That would be great, thanks.
Not a problem.
Question.
Is there a way to do a 'git commit' with the diff generated using the
"patience diff" algorithm?
I have a patch that is really ugly when I do the git commit but looks
ok if I do a 'git diff --patience'.
Regards,
Hartley
On Wed, Jun 20, 2012 at 07:21:04PM -0500, H Hartley Sweeten wrote:
> On Wednesday, June 20, 2012 4:24 PM, Greg KH wrote:
> > On Wed, Jun 20, 2012 at 06:16:52PM -0500, H Hartley Sweeten wrote:
> >> Hmm. It was based on next-20120620 and created with git format-patch.
> >>
> >> Do you have any other patches to that file in your staging tree that
> >> have not reached the next tree yet?
> >
> > Possibly, depending on when -next was created, I did just apply a bunch
> > of other patches a few hours ago.
> >
> >> Regardless, I have some other cleanup patches for that file. I'll
> >> put them together as a series and repost it later.
> >
> > That would be great, thanks.
>
> Not a problem.
>
> Question.
>
> Is there a way to do a 'git commit' with the diff generated using the
> "patience diff" algorithm?
I have no idea what that is.
> I have a patch that is really ugly when I do the git commit but looks
> ok if I do a 'git diff --patience'.
It's ok, send it on, I'll figure it out :)
thanks,
greg k-h
On 2012-06-21 01:21, H Hartley Sweeten wrote:
> Question.
>
> Is there a way to do a 'git commit' with the diff generated using the
> "patience diff" algorithm?
>
> I have a patch that is really ugly when I do the git commit but looks
> ok if I do a 'git diff --patience'.
You can generate patches with the different diff algorithms, but I don't
think it makes any difference to what gets committed in the git
repository, or rather it doesn't make any difference when patches are
sent upstream from that intermediate repository as the diff will be
regenerated on the fly.
I guess your ugly patch is moving stuff around to avoid forward
declarations? Splitting it up into a number of steps seems to help in
that case.
--
-=( Ian Abbott @ MEV Ltd. E-mail: <[email protected]> )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-