From: Greg Kroah-Hartman <greg@kroah.com>
To: Hannes Weisbach <hannes_weisbach@gmx.net>
Cc: Arnd Bergmann <arnd@arndb.de>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] lp: implement proper detach function for parport_driver lp
Date: Wed, 19 Jun 2013 11:32:31 -0700 [thread overview]
Message-ID: <20130619183231.GA7684@kroah.com> (raw)
In-Reply-To: <1EA8660C-5E07-42FC-91D4-7924BE87D5D7@gmx.net>
On Wed, Jun 19, 2013 at 07:04:51PM +0200, Hannes Weisbach wrote:
> >> Signed-off-by: Hannes Weisbach <hannes_weisbach@gmx.net>
> >> ---
> >> Granted, for normal parport drivers this is usually not an issue,
> >> because the device does not go away. However, I am currently writing a
> >> Linux device driver for a USB to parallel port converter [0] and
> >> therefore need proper detaching. Additionally, the wrong ref count
> >> keeps me from simply rmmod my driver and insmod a new version while
> >> developing and testing.
> >
> > Really? We already have a usb to parallel port driver in the kernel
> > tree that seems to work just fine.
>
> > It's been there since the 2.3 kernel
> > days, so either it has the same problem, or your driver is doing
> > something odd.
>
> Do you mean the USB Printer class driver for pseudo parallel port
> adapters? They don't use the char/lp.c printer driver. (Or I didn't
> see it). I'm writing a driver for USB2LPT [0], which gives you a real
> /dev/parportN-device in user space, with which you can do all the
> bit-twiddling like with a real parallel port.
>
> Or do you mean USS720 (misc/uss720.c) and MOS7715 (serial/mos7720.c)
> drivers.
Yes, I mean these.
> They are doing what I am doing: translating whatever the
> user does on a /dev/parportN-node and sending device-specific commands
> over USB. When they do parport_announce_port(), lp.c should also be
> initialized and they should have the same problem.
Why hasn't anyone reported that problem then? Surely someone must use
these, they've been in the kernel tree for over a decade now.
> On second thought, my patch might not be optimal. lp.c stores
> instance-structs in an array of size 8. So after 8 re-plugs, lp.c
> will not instantiate any more printer devices. I think I better go
> all the way and replace that array with a list, to have a proper
> solution.
Proper solutions are always good :)
thanks,
greg k-h
next prev parent reply other threads:[~2013-06-19 18:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-01 20:02 [PATCH] lp: implement proper detach function for parport_driver lp Hannes Weisbach
2013-06-03 21:08 ` Greg Kroah-Hartman
2013-06-19 17:04 ` Hannes Weisbach
2013-06-19 18:32 ` Greg Kroah-Hartman [this message]
2013-06-20 8:25 ` Hannes Weisbach
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=20130619183231.GA7684@kroah.com \
--to=greg@kroah.com \
--cc=arnd@arndb.de \
--cc=hannes_weisbach@gmx.net \
--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.