On Fri, Jul 31, 2015 at 01:43:06PM -0700, Dmitry Torokhov wrote: > On Fri, Jul 31, 2015 at 01:36:18PM -0700, Greg KH wrote: > > On Fri, Jul 31, 2015 at 11:04:26PM +0530, Sudip Mukherjee wrote: > > > On Fri, Jul 31, 2015 at 09:54:27AM -0700, Dmitry Torokhov wrote: > > > > On Fri, Jul 31, 2015 at 03:45:25PM +0530, Sudip Mukherjee wrote: > > > > > On Thu, Jul 30, 2015 at 09:53:23AM -0700, Dmitry Torokhov wrote: > > > > > > Hi Sudip, > > > > > Hi Dmitry, > > > > > > > > > > > > On Thu, Jul 30, 2015 at 07:36:34PM +0530, Sudip Mukherjee wrote: <snip> > > > > > > > > No, unfortunately I do not. > > > > > > > > Since neither of us can test the change what is the benefit of doing the > > > > conversion? What will be gained by doing it? Are there plans for parport > > > > subsystem to remove the old style initialization? > > > Yes, that is the plan. Well, if you are not comfortable with introducing > > > attach and detach functions then this can be done in another way where > > > there will be very minimum change in the code. But I will prefer to have > > > attach and detach then it can take advantage of the hotplug feature. > > > Adding Greg in To: list for his comments. > > > > Converting to the "new" api is the end goal here, no need to keep the > > old one around anymore. > > OK, then I guess we can do the conversion right (dropping db9_base > module-global) and see if anyone screams at us. I am working on it now to remove db9_base. But in the detach callback we will get struct parport * and from parport to get a pardevice we need to get it from port->physport->devices. Since it is having PARPORT_FLAG_EXCL it is ok, but should we really depend on and work with the internal data structures of the parport rather than working with the exported api? regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
