From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933077Ab3BSOux (ORCPT ); Tue, 19 Feb 2013 09:50:53 -0500 Received: from mail.skyhub.de ([78.46.96.112]:36817 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932971Ab3BSOus (ORCPT ); Tue, 19 Feb 2013 09:50:48 -0500 Date: Tue, 19 Feb 2013 15:50:43 +0100 From: Borislav Petkov To: Mauro Carvalho Chehab Cc: Felipe Balbi , Greg KH , Linux Kernel Mailing List , Steven Rostedt , Frederic Weisbecker , Ingo Molnar , JBottomley@parallels.com, linux-scsi@vger.kernel.org, davem@davemloft.net, netdev@vger.kernel.org, Doug Thompson , linux-edac@vger.kernel.org, rjw@sisk.pl, linux-pm@vger.kernel.org Subject: Re: SYSFS "errors" Message-ID: <20130219145043.GJ26623@pd.tnic> Mail-Followup-To: Borislav Petkov , Mauro Carvalho Chehab , Felipe Balbi , Greg KH , Linux Kernel Mailing List , Steven Rostedt , Frederic Weisbecker , Ingo Molnar , JBottomley@parallels.com, linux-scsi@vger.kernel.org, davem@davemloft.net, netdev@vger.kernel.org, Doug Thompson , linux-edac@vger.kernel.org, rjw@sisk.pl, linux-pm@vger.kernel.org References: <20130219114345.GA26623@pd.tnic> <20130219091610.2b746a30@redhat.com> <20130219123502.GD26623@pd.tnic> <20130219094640.2abf1a66@redhat.com> <20130219130626.GE26623@pd.tnic> <20130219131500.GW23197@arwen.pp.htv.fi> <20130219132853.GG26623@pd.tnic> <20130219133809.GA4390@arwen.pp.htv.fi> <20130219135056.GH26623@pd.tnic> <20130219113521.510db290@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130219113521.510db290@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 19, 2013 at 11:35:21AM -0300, Mauro Carvalho Chehab wrote: > That's covers everything but Hannes arguments. I don't think that > adding just one more device_create_file() on a driver that creates > dozens (or hundreds) of sys nodes, depending on the number of DIMMS > on the system would make it any worse. Right, those attributes are created once during EDAC core init and we haven't seen any issues so far so let's not address this just yet but make a mental note about the race condition possibility. > [PATCH EDAC] edac: only create sdram_scrub_rate where supported > > Currently, sdram_scrub_rate sysfs node is created even if the device > doesn't support get/set the scub rate. Change the logic to only > create this device node when the operation is supported. > > Reported-by: Felipe Balbi > Signed-off-by: Mauro Carvalho Chehab Acked-by: Borislav Petkov -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --