Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753759Ab3IQUVP (ORCPT ); Tue, 17 Sep 2013 16:21:15 -0400 Received: from merlin.infradead.org ([205.233.59.134]:56341 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752921Ab3IQUVO (ORCPT ); Tue, 17 Sep 2013 16:21:14 -0400 Message-ID: <5238B9A7.6040002@kernel.dk> Date: Tue, 17 Sep 2013 14:20:55 -0600 From: Jens Axboe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Olof Johansson CC: Jeff Moyer , OS Engineering , "linux-kernel@vger.kernel.org" , Akhil Bhansali , Ramprasad Chinthekindi , Amit Phansalkar Subject: Re: [PATCH] block: Device driver for sTec's PCIe Kronos Card. References: <26D762E250385C4D8E9D6EC3C8E47DC11E6FCF20@sambx4.stec-inc.ad> <26D762E250385C4D8E9D6EC3C8E47DC11E6FE729@sambx4.stec-inc.ad> <5228913A.50807@kernel.dk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1698 Lines: 48 On 09/17/2013 01:04 PM, Olof Johansson wrote: > On Thu, Sep 5, 2013 at 7:12 AM, Jens Axboe wrote: >> On 09/05/2013 06:00 AM, Jeff Moyer wrote: >>> OS Engineering writes: >>> >>>> Hi Jeff, >>>> >>>> Thank you for reviewing the patch. >>> >>> No problem. Jens, any objection to queueing this up for 3.12? >> >> I'll give it a look-over, but usually I'm pretty lax when it comes to >> new drivers. So no, I'd be surprised if we can't queue this up for 3.12. > > I came across this driver because it was spewing a lot of really > trivial and easy to fix compiler warnings. Silly stuff such as > printing u32 with %lu. > > From a quick look at the code, several things are immediately apparent: > > First, checkpatch says, on the currently existing file in -next: > > total: 3 errors, 61 warnings, 5817 lines checked > > Code like this looks _really_ confused: > > barrier(); > val = readl(skdev->mem_map[1] + offset); > barrier(); > > There are also some crazy long functions that should be refactored, > such as skd_request_fn(). > > So, it looks like this driver needs a bunch of work before it's ready > to go in. Or, maybe it's better to submit it with a TODO list for the > staging tree instead? Not disagreeing with you, it definitely needs a bit of cleaning. And so far stec has not been very responsive in fixing those issues. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/