From: Ian Abbott <abbotti@mev.co.uk>
To: Conrad Gomes <conrad.s.j.gomes@gmail.com>,
Greg KH <gregkh@linuxfoundation.org>
Cc: Ian Abbott <ian.abbott@mev.co.uk>,
"hsweeten@visionengravers.com" <hsweeten@visionengravers.com>,
"joe@perches.com" <joe@perches.com>,
"devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Staging: comedi: fix coding style issues in unioxx5.c
Date: Mon, 18 Nov 2013 10:40:41 +0000 [thread overview]
Message-ID: <5289EEA9.1000202@mev.co.uk> (raw)
In-Reply-To: <CALxff2GmatgMQF_2yQ9g=tZzh=J-5fKt89sFAU4oYq_FBJHNag@mail.gmail.com>
On 2013-11-17 03:42, Conrad Gomes wrote:
> Hi,
>
> No problem, I'll break this up and resend it.
>
> In order to use dev_info type functions I was planning on assigning the
> comedi device's struct device to the struct subdevice's class_dev as
> follows in comedi_alloc_subdevices as it appears that is is not used(I
> could be wrong):
>
> diff --git a/drivers/staging/comedi/drivers.c
> b/drivers/staging/comedi/drivers.c
> index 8f02bf6..e4c44ae 100644
> --- a/drivers/staging/comedi/drivers.c
> +++ b/drivers/staging/comedi/drivers.c
> @@ -90,6 +90,7 @@ int comedi_alloc_subdevices(struct comedi_device *dev,
> int num_subdevices)
> s->async_dma_dir = DMA_NONE;
> spin_lock_init(&s->spin_lock);
> s->minor = -1;
> + s->class_dev = dev->class_dev;
> }
> return 0;
> }
The class_dev member is assigned by comedi_alloc_subdevice_minor(s)
(which will be called if the subdevice supports asynchronous comedi
commands) and is kept around for the call to comedi_free_subdevice_minor(s).
The struct comedi_subdevice has a pointer back to the struct
comedi_device. The class_dev member in the struct comedi_device can be
used as the device pointer parameter of dev_info() etc.
> And adding a reference to the subdevice in the private data structure
> unioxx5_subd_priv in order to substitute pr_info with dev_info. If this
> is fine I'll remove all references of pr_info in the file:
>
> diff --git a/drivers/staging/comedi/drivers/unioxx5.c
> b/drivers/staging/comedi/drivers/unioxx5.c
> index 2b1ece8..bb8f5a4 100644
> --- a/drivers/staging/comedi/drivers/unioxx5.c
> +++ b/drivers/staging/comedi/drivers/unioxx5.c
> @@ -72,6 +72,7 @@ Devices: [Fastwel] UNIOxx-5 (unioxx5),
>
> /* 'private' structure for each subdevice */
> struct unioxx5_subd_priv {
> + struct comedi_subdevice *subdevice;
> int usp_iobase;
> /* 12 modules. each can be 70L or 73L */
> unsigned char usp_module_type[12];
> @@ -94,9 +95,10 @@ static int __unioxx5_define_chan_offset(int chan_num)
> static void __unioxx5_digital_config(struct unioxx5_subd_priv *usp,
> int mode)
> {
> int i, mask;
> + struct device *dev = usp->subdevice->class_dev;
>
> mask = (mode == ALL_2_OUTPUT) ? 0xFF : 0x00;
> - printk("COMEDI: mode = %d\n", mask);
> + dev_info(dev, "COMEDI: mode = %d\n", mask);
>
> outb(1, usp->usp_iobase + 0);
It would be better to change those functions to pass the pointer to the
struct comedi_subdevice instead of the pointer to the struct
unioxx5_subd_priv.
A variable or parameter named 'dev' in the comedi drivers is usually of
type struct comedi_device for consistency.
The message passed to dev_info() wouldn't need the "COMEDI:" prefix -
it's redundant.
Also, this particular message should be a dev_dbg() at best, and
probably better not to have it at all!
For the sake of example, the above function could start as follows:
static void __unioxx5_digital_config(struct comedi_subdevice *s, int mode)
{
struct unioxx5_subd_priv *usp = s->private;
struct device *csdev = s->device->class_dev;
int i, mask;
mask = (mode == ALL_2_OUTPUT) ? 0xFF : 0x00;
dev_dbg(csdev, "mode = %d\n", mask);
--
-=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
prev parent reply other threads:[~2013-11-18 10:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-01 12:31 [PATCH] Staging: comedi: fix coding style issues in unioxx5.c Conrad Gomes
2013-11-12 0:15 ` Greg KH
[not found] ` <CALxff2GmatgMQF_2yQ9g=tZzh=J-5fKt89sFAU4oYq_FBJHNag@mail.gmail.com>
2013-11-18 10:40 ` Ian Abbott [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5289EEA9.1000202@mev.co.uk \
--to=abbotti@mev.co.uk \
--cc=conrad.s.j.gomes@gmail.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=hsweeten@visionengravers.com \
--cc=ian.abbott@mev.co.uk \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.