public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jarod Wilson <jwilson@redhat.com>
To: Stefan Bauer <stefan.bauer@cs.tu-chemnitz.de>,
	Janne Grunau <j@jannau.net>
Cc: linux-kernel@vger.kernel.org, Christoph Bartelmus <lirc@bartelmus.de>
Subject: Re: [PATCH 02/18] lirc serial port receiver/transmitter device driver
Date: Fri, 12 Sep 2008 12:24:33 -0400	[thread overview]
Message-ID: <200809121224.34345.jwilson@redhat.com> (raw)
In-Reply-To: <200809112149.25762.stefan.bauer@cs.tu-chemnitz.de>

On Thursday 11 September 2008 15:49:25 Stefan Bauer wrote:
> Jarod Wilson wrote:
[...]
> >> > +static inline unsigned int sinp(int offset)
> >> > +{
> >> > +#if defined(LIRC_ALLOW_MMAPPED_IO)
> >> > +	if (iommap != 0) {
> >> > +		/* the register is memory-mapped */
> >> > +		offset <<= ioshift;
> >> > +		return readb(io + offset);
> >> > +	}
> >> > +#endif
> >> > +	return inb(io + offset);
> >> > +}
> >>
> >> This all looks like a reimplementation of ioport_map() and the
> >> associated ioread*() and iowrite*() functions...?
> >
> > Probably. Will see about using those instead.

>From what I've been able to ascertain, reducing the above to...

static u8 sinp(int offset)
{
        if (iommap != 0)
                /* the register is memory-mapped */
                offset <<= ioshift;

        return inb(io + offset);
}

...should be sane. inb() either calls ioport_map() and ioread8() as needed, or 
defines inb() as readb() (or __raw_readb()) on platforms where its 
appropriate. (and similar for lirc_serial.c::soutp()).

> >> Nothing in this function does anything to assure itself that the port
> >> actually exists and is the right kind of hardware.  Maybe that can't
> >> really be done with this kind of device?
> >
> > We should probably try to make sure the port actually exists, but I don't
> > think there's a whole lot (if anything) we can do as far as verifying the
> > device itself.

I've borrowed the simple existence test from 
drivers/serial/8250.c::autoconfig(), which tries a few reads and writes from 
UART_IER. I think this is probably sufficient for verifying the port is legit.

Christoph B., you're definitely much more familiar with serial IR devices than 
I am... Is there any sort of test you can think of that we could use to try to 
verify the existence of an IR device hooked to the port? Or should we be happy 
we at least know there's a port and just assume the IR device is there?


> I just want to thank you very much for your work and give you my Tested-By.
> Todays git (b2e9c18a32423310a309f94ea5a659c4bb264378) works well here with
> lirc-0.8.3 userspace on a Pentium 3/i815-system.

Oh good! I haven't broken anything further w/my changes up to b2e9c18... ;) 
I've got another slew of updates to lirc_serial still pending though -- a few 
that I'm about to push, and at least one more chunk I still need to figure out 
(the hrtimers/rdtscl bits).

Continued testing would be much appreciated, since I still have no serial IR 
hardware myself (couldn't find the thingy that shipped with my Technisat card, 
but I do now have hardware on the way).

> But I've had a section mismatch in the lirc code, don't know if this is
> serious.
>
> WARNING: drivers/input/lirc/lirc_serial.o(.init.text+0x11e): Section
> mismatch in reference from the function init_module() to the
> function .exit.text:lirc_serial_exit()
> The function __init init_module() references
> a function __exit lirc_serial_exit().
> This is often seen when error handling in the init function
> uses functionality in the exit path.
> The fix is often to remove the __exit annotation of
> lirc_serial_exit() so it may be used outside an exit section.

Ah, I believe you're absolutely correct. Done.

-- 
Jarod Wilson
jarod@redhat.com


  reply	other threads:[~2008-09-12 16:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-11 19:49 [PATCH 02/18] lirc serial port receiver/transmitter device driver Stefan Bauer
2008-09-12 16:24 ` Jarod Wilson [this message]
2008-09-13  0:26   ` Janne Grunau
2008-09-13  8:41     ` Stefan Bauer
2008-09-15  3:55       ` Jarod Wilson
2008-09-15 18:20         ` Jarod Wilson
2008-09-16  4:08           ` Jarod Wilson
2008-09-18 14:00             ` Jarod Wilson
2008-09-19 18:05             ` Stefan Bauer
2008-09-19 18:26               ` Janne Grunau
2008-09-19 18:53                 ` Stefan Bauer
2008-09-19 19:24                   ` Janne Grunau
2008-09-20  0:10                   ` Janne Grunau
2008-09-26 19:42                     ` Stefan Bauer
2008-09-19 18:54                 ` Jarod Wilson
2008-09-19 19:12                   ` Stefan Bauer
2008-09-13  7:09   ` Christoph Bartelmus
  -- strict thread matches above, loose matches on Subject: below --
2008-09-09  4:05 [PATCH 0/18] linux infrared remote control drivers Jarod Wilson
2008-09-09  4:05 ` [PATCH 01/18] lirc core device driver infrastructure Jarod Wilson
2008-09-09  4:05   ` [PATCH 02/18] lirc serial port receiver/transmitter device driver Jarod Wilson
2008-09-09 16:14     ` Jonathan Corbet
2008-09-09 19:51       ` Stefan Lippers-Hollmann
2008-09-09 19:56         ` Jarod Wilson
2008-09-10 17:40       ` Jarod Wilson

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=200809121224.34345.jwilson@redhat.com \
    --to=jwilson@redhat.com \
    --cc=j@jannau.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lirc@bartelmus.de \
    --cc=stefan.bauer@cs.tu-chemnitz.de \
    /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