On Wed, Apr 08, 2015 at 02:38:32PM +0300, Dan Carpenter wrote: > 1) We can't apply this patch on its own so this way of breaking up the > patches doesn't work. yes, if the first patch is reverted for any reason all the others need to be reverted also. so then everything in one single patch? > > 2) I was thinking that all the ->attach() calls would have to succeed or > we would bail. Having some of them succeed and some fail doesn't seem > like it will simplify the driver code very much. But I can also see > your point. Hm... to clarify my point more here: any system might have more than one parallel port but the module might decide to use just one. so in that case attach will return 0 for the port that it wishes to use, for others it will be a error code. So in parport_register_driver if we get error codes in all the attach calls then we know that attach has definitely failed, but atleast one 0 means one attach call has succeeded, which will happen in case of staging/panel, net/plip... > > Minor comment: No need to preserve the error code if there are lots > which we miss. We may as well hard code an error code. But that's a > minor thing. Does this actually simplify the driver code? That's the > more important thing. i don't think this will simplify the driver code, but atleast now parport_register_driver() will not report success when we have actually failed. And as a result module_init will also fail which is supposed to be the actual behviour. regards sudip > > regards, > dan carpenter > -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
