While working with a very simple demo parallel port interrupt driver, I found
that request_region() will successfully return, regardless of whether or not
the pnp calls have been made to activite the parallel port on a pnp system.
The driver worked by just calling request_region() on another system, but on
my laptop it wouldn't work unless I made the pnp activation calls before
hand. The confusion came because the io range got assigned to my module,
showed up in /proc/ioports, etc. So it appeared to be properly configured,
but all the inb() calls returned 0xff.
I know have something working, but just wanted to ask if it is considered
correct behavior for request_region() to succeed on an io range pertaining to
a device that needs to be initialized by the pnp system and hasn't been.
--
Darren Hart
IBM Linux Technology Center
Realtime Linux Team
On 2006-10-26, Darren Hart <[email protected]> wrote:
> While working with a very simple demo parallel port interrupt driver, I found
> that request_region() will successfully return, regardless of whether or not
> the pnp calls have been made to activite the parallel port on a pnp system.
>
> The driver worked by just calling request_region() on another system, but on
> my laptop it wouldn't work unless I made the pnp activation calls before
> hand. The confusion came because the io range got assigned to my module,
> showed up in /proc/ioports, etc. So it appeared to be properly configured,
> but all the inb() calls returned 0xff.
>
> I know have something working, but just wanted to ask if it is considered
"now"?
> correct behavior for request_region() to succeed on an io range pertaining to
> a device that needs to be initialized by the pnp system and hasn't been.
I know that legacy parallel port must work regadless of any parport
modules, using /dev/port and BIOS setup for EPP/ECP etc.
If you really want to be answered, try to address message (or cc) to
e-mails mentioned in
- `linux/MAINTAINERS.*PARALLEL PORT*'
- `linux/drivers/parport/parport_pc.c'
____