From: Arnaud Giersch <arnaud.giersch@free.fr>
To: "Randy.Dunlap" <rdunlap@xenotime.net>
Cc: philb@gnu.org, tim@cyberelk.net, campbell@torque.net,
andrea@suse.de, linux-parport@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH][repost] parport: add parallel port support for SGI O2
Date: Tue, 10 Jan 2006 23:23:52 +0100 [thread overview]
Message-ID: <87hd8bhgcn.fsf@groumpf.homeip.net> (raw)
In-Reply-To: <20060109185611.14202427.rdunlap@xenotime.net> (Randy Dunlap's message of "Mon, 9 Jan 2006 18:56:11 -0800")
Mardi 10 janvier 2006, vers 03:56:11 (+0100), Randy.Dunlap a écrit:
> On Mon, 09 Jan 2006 21:47:56 +0100 Arnaud Giersch wrote:
>
>> diff -Naurp linux-2.6.15.orig/drivers/parport/parport_ip32.c linux-2.6.15/drivers/parport/parport_ip32.c
>> --- linux-2.6.15.orig/drivers/parport/parport_ip32.c 1970-01-01 01:00:00.000000000 +0100
>> +++ linux-2.6.15/drivers/parport/parport_ip32.c 2006-01-09 20:41:03.000000000 +0100
Hi Randy,
Thank you very much for your answer. I will make the corrections and
come back with an updated version of my code.
> I scanned over the driver. It seems to be in pretty good shape,
> but I have to wonder about the use of "volatile" and the
> barriers [wmb() and barrier()]. Are those really needed?
The "volatile" is needed for type consistency. For the memory
barriers, I was not sure and I preferred to take a safe bet. I will
try to investigate them further. Any help or pointer to documentation
would be appreciated. I have already read the documentation
distributed with the Linux source code, and the "Linux Device Drivers"
book by J. Corbet, A. Rubini, and G. Kroah-Hartman.
> Oh, and a really large inline function plus lots of smaller
> ones.
Ok, I will remove some "inline", and only keep them for the smaller
functions.
> Plus some comments below.
>> +static inline void parport_ip32_dma_setup_context(unsigned int limit)
>> +{
>> + if (down_trylock(&parport_ip32_dma.lock)) {
>> + /* Come back later please. The MACE keeps sending interrupts
>> + * when a context is invalid, so there is no problem with this
>> + * early return. */
>> + return;
>> + }
>> + if (parport_ip32_dma.left > 0) {
>> + volatile u64 __iomem *ctxreg = (parport_ip32_dma.ctx == 0)?
>> + &mace->perif.ctrl.parport.context_a:
>> + &mace->perif.ctrl.parport.context_b;
The "volatile" is here because mace->perif.ctrl.parport.context_a and
context_b are from type "volatile u64".
>> +/**
>> + * parport_ip32_interrupt - interrupt handler
>
> Needs function parameters in kernel-doc.
>> +/**
>> + * parport_ip32_init_state - for core parport code
>
> Missing params in kernel-doc.
>> +/**
>> + * parport_ip32_save_state - for core parport code
>
> Missing params in kernel-doc (or just don't make it look like
> kernel-doc).
Ok. Those are mostly functions whose parameters are dictated by an
external API. I didn't want to duplicate their documentation.
>> +/*--- EPP mode functions -----------------------------------------------*/
>
> Why are a lot of the short EPP functions not inline?
They are not inline because their only use is via pointers in struct
parport_operations.
>> + if (count > left) {
>> + count = left;
>> + }
>
> Style: one-line if's don't use braces.
Ok.
>> + return (len - left);
>
> Style: no parens on return unless needed.
Ok.
>> +/*--- Default parport operations ---------------------------------------*/
>> +
>> +static __initdata struct parport_operations parport_ip32_ops = {
>
> Are you sure that it's safe for this to be __initdata?
Yes it is. Its contents is copied in the parport_ip32_probe_port()
initialization function (see below).
>> +static __init struct parport *parport_ip32_probe_port(void)
>> +{
>> + struct parport_ip32_regs regs;
>> + struct parport_ip32_private *priv = NULL;
>> + struct parport_operations *ops = NULL;
>> + struct parport *p = NULL;
>> + int err;
>> +
>> + parport_ip32_make_isa_registers(®s, &mace->isa.parallel,
>> + &mace->isa.ecp1284, 8 /* regshift */);
>> +
>> + ops = kmalloc(sizeof(struct parport_operations), GFP_KERNEL);
>> + priv = kmalloc(sizeof(struct parport_ip32_private), GFP_KERNEL);
>> + p = parport_register_port(0, PARPORT_IRQ_NONE, PARPORT_DMA_NONE, ops);
>> + if (ops == NULL || priv == NULL || p == NULL) {
>> + err = -ENOMEM;
>> + goto fail;
>> + }
>> + p->base = MACE_BASE + offsetof(struct sgi_mace, isa.parallel);
>> + p->base_hi = MACE_BASE + offsetof(struct sgi_mace, isa.ecp1284);
>> + p->private_data = priv;
>> +
>> + *ops = parport_ip32_ops;
Here is the only use of parport_ip32_ops.
>> + return IS_ERR(this_port)? PTR_ERR(this_port): 0;
>
> Please use spaces before and after '?' and ':'.
Ok.
Arnaud
prev parent reply other threads:[~2006-01-10 22:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-09 20:47 Arnaud Giersch
2006-01-10 2:56 ` Randy.Dunlap
2006-01-10 22:23 ` Arnaud Giersch [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=87hd8bhgcn.fsf@groumpf.homeip.net \
--to=arnaud.giersch@free.fr \
--cc=andrea@suse.de \
--cc=campbell@torque.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parport@lists.infradead.org \
--cc=philb@gnu.org \
--cc=rdunlap@xenotime.net \
--cc=tim@cyberelk.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®