Prev: [PATCH] raid/multipath error handling for faulty drives
Next: perf probe: Fix to use symtab only if no debuginfo
From: Oliver Neukum on 26 Apr 2010 08:10 Am Sonntag, 25. April 2010 12:37:10 schrieb Alessio Igor Bogani: > BKL is not needed here because necessary locking is already provided > by mutex sisusb->lock. Have you checked the fb layer doesn't need it? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alessio Igor Bogani on 26 Apr 2010 08:40 Dear Mr. Neukum, 2010/4/26 Oliver Neukum <oneukum(a)suse.de>: > Am Sonntag, 25. April 2010 12:37:10 schrieb Alessio Igor Bogani: >> BKL is not needed here because necessary locking is already provided >> by mutex sisusb->lock. > > Have you checked the fb layer doesn't need it? The _open and _release functions are already serialized with mutex in fb layer. So that mutex could be removed but in my opinion this job should be done in a separate patch (like I have done some time ago for nvidiafb driver). Now I would want suggest to remove BKL here only. Ciao, Alessio -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arnd Bergmann on 26 Apr 2010 09:20 On Monday 26 April 2010, Alessio Igor Bogani wrote: > 2010/4/26 Oliver Neukum <oneukum(a)suse.de>: > > Am Sonntag, 25. April 2010 12:37:10 schrieb Alessio Igor Bogani: > >> BKL is not needed here because necessary locking is already provided > >> by mutex sisusb->lock. > > > > Have you checked the fb layer doesn't need it? > > The _open and _release functions are already serialized with mutex in > fb layer. So that mutex could be removed but in my opinion this job > should be done in a separate patch (like I have done some time ago for > nvidiafb driver). Now I would want suggest to remove BKL here only. What about the BKL in the sisusb_ioctl()? It seems to follow the same logic, so I would think that you can simply remove the BKL from the module entirely, rather than only half of it. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alessio Igor Bogani on 26 Apr 2010 09:40 Dear Mr. Bergmann, 2010/4/26 Arnd Bergmann <arnd(a)arndb.de>: >> >> BKL is not needed here because necessary locking is already provided >> >> by mutex sisusb->lock. [...] > What about the BKL in the sisusb_ioctl()? It seems to follow the > same logic, so I would think that you can simply remove the BKL > from the module entirely, rather than only half of it. It is what effectively I'm trying to do! The first part of this work is already present in USB subsystem maintainer tree (aka greg) at: http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/usb/usb-sisusbvga-remove-the-bkl-from-ioctl.patch Ciao, Alessio -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arnd Bergmann on 26 Apr 2010 10:00
On Monday 26 April 2010, Alessio Igor Bogani wrote: > It is what effectively I'm trying to do! > > The first part of this work is already present in USB subsystem > maintainer tree (aka greg) at: > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/usb/usb-sisusbvga-remove-the-bkl-from-ioctl.patch > Ok, looks good then. I just wouldn't bother splitting the work into two patches if you want to do this for more drivers. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |