> On Wed, Dec 3, 2008 at 19:42, Vorobiev Dmitri <dmitri.vorobiev@xxxxxxxxx> > wrote: >>> On Wed, 2008-12-03 at 18:52 +0100, Kay Sievers wrote: >>>> On Wed, Dec 3, 2008 at 18:08, James Bottomley >>>> <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: >>>> > On Wed, 2008-12-03 at 18:24 +0200, Vorobiev Dmitri wrote: >>>> >> > This patch fixes the following compilation warning: >>>> >> > >>>> >> > CC [M] drivers/scsi/sgiwd93.o >>>> >> > drivers/scsi/sgiwd93.c:314: warning: initialization from >>>> incompatible >>>> >> > pointer type >>>> >> >>>> >> Any news about this one? I think this patch should go via >>>> linux-scsi, >>>> >> unless you would be insisting on pushing it via linux-mips, in >>>> which >>>> case >>>> >> I'll politely bug Ralf about it. :) >>>> > >>>> > Looks OK for the local change. >>>> > >>>> > Globally, having driver->remove and platform_driver->remove return >>>> int >>>> > instead of void looks wrong. Particularly when the only use cases >>>> are >>>> > in drivers/base/ and they all ignore the return code. >>>> > >>>> > Greg and Kay ... shouldn't we simply redefine the return values for >>>> the >>>> > remove methods in these structures to return void (and thus match >>>> the >>>> > use case)? >>>> >>>> Aren't there many many drivers across the tree, using the "int remove" >>>> version? >>> >>> Yes ... since it's a function prototype. >>> >>> However, if drivers/base simply discards the return, it's a trap we >>> shouldn't be setting. >> >> Hmmm, it does look like the return value is discarded, please see >> drivers/base/dd.c::__device_release_driver() for details. >> >> Does this not deserve a good cleanup? > > Sure, it might be. If you want to patch hundreds of files, send > patches to maintainers, patch drivers you can not even compile, we > could do that. > > We are already in the middle of a ~400 files "struct device" bus_id > conversion, and only very few maintainers respond to these patches. We > also never got any reply to the SCSI bus_id patch we sent weeks ago. > :) > > Even when it's "a good cleanup", with maintainers not responding, and > supporting it, it's a real pain to change things like this. But, if > you want to go ahead and do that, let us know. Well, I don't really want to look like a coward, but I guess this a good project for Kernel Janitors, and I'm Cc:ing their mailing list now. Dmitri -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
