From: Borislav Petkov <bp@alien8.de>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>, Tejun Heo <tj@kernel.org>
Cc: Doug Thompson <dougthompson@xmission.com>,
linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org,
Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
Olof Johansson <olof@lixom.net>,
Arjan van de Ven <arjan@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Luis R . Rodriguez" <mcgrof@suse.com>
Subject: Re: [PATCH 3/3] EDAC: amd64_edac: decide if driver can load successfully early.
Date: Thu, 19 Mar 2015 17:23:02 +0100 [thread overview]
Message-ID: <20150319162301.GH11715@pd.tnic> (raw)
In-Reply-To: <20150319161226.GC30732@dtor-ws>
On Thu, Mar 19, 2015 at 09:12:26AM -0700, Dmitry Torokhov wrote:
> By the same token it only makes sense to load e1000e when I have e1000e
> device loaded, but we allow it to load anyway. Or psmouse. Or pretty
> much any other drivers (sans some platform code). The fact is that we
> for long time have separated module loading and driver binding. Loading
> driver even without the devices is standard behavior.
FWIW, I always hated that.
> Does anyone look at the loaded modules to see if functionality is
> available? They should look if any devices are actually bound to the
> driver (in sysfs). I mean, even without the changes I can unbind the
> edac driver from northbridge via sysfs thus disabling error decoding and
> "mislead" people.
Yeah yeah, do people listen to what we say how something should be used
properly and not use it the way they feel like? Of course not!
But enough wasting time fruitlessly, I think I have an idea:
How about I go and iterate over all NBs (northbridges) on the system and
check whether at least one has ECC enabled so that the driver can load?
And do that in the init function.
If I detect at least one NB which is ok, I can then continue and do
pci_register_driver(). If there are no suitable NBs, I return an error
and don't even touch PCI.
Would that be something which would work for what you're trying to
achieve?
If yes, I could give it a try but it won't happen like immediately. For
the time being, we could use the PROBE_FORCE_SYNCHRONOUS thing.
While doing that, I could take a look at Dmitry's cleanups too.
Yes, no?
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
next prev parent reply other threads:[~2015-03-19 16:24 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-19 0:49 [RFC/RFT] amd64_edac: avoid doing post-probe setup Dmitry Torokhov
2015-03-19 0:49 ` [PATCH 1/3] EDAC: amd64: stop allocating ecc settings separately Dmitry Torokhov
2015-03-19 0:49 ` [PATCH 2/3] EDAC: amd64_edac: clean up remove_one_instance() Dmitry Torokhov
2015-03-19 0:49 ` [PATCH 3/3] EDAC: amd64_edac: decide if driver can load successfully early Dmitry Torokhov
2015-03-19 9:40 ` Borislav Petkov
2015-03-19 15:29 ` Tejun Heo
2015-03-19 15:35 ` Borislav Petkov
2015-03-19 15:52 ` Dmitry Torokhov
2015-03-19 15:59 ` Borislav Petkov
2015-03-19 16:12 ` Dmitry Torokhov
2015-03-19 16:23 ` Borislav Petkov [this message]
2015-03-19 16:33 ` Tejun Heo
2015-03-19 16:45 ` Borislav Petkov
2015-03-19 16:49 ` Tejun Heo
2015-03-19 16:56 ` Borislav Petkov
2015-03-19 17:03 ` Tejun Heo
2015-03-19 17:04 ` Borislav Petkov
2015-03-19 17:10 ` Tejun Heo
2015-03-19 17:15 ` Tejun Heo
2015-03-19 17:27 ` Borislav Petkov
2015-03-19 17:47 ` Tejun Heo
2015-03-19 17:54 ` Borislav Petkov
2015-03-19 18:05 ` Tejun Heo
2015-03-19 16:52 ` Dmitry Torokhov
2015-03-19 17:09 ` Tejun Heo
2015-03-19 15:55 ` Tejun Heo
2015-03-19 16:01 ` Borislav Petkov
2015-03-19 16:12 ` Tejun Heo
2015-03-19 16:57 ` Dmitry Torokhov
2015-03-19 17:22 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150319162301.GH11715@pd.tnic \
--to=bp@alien8.de \
--cc=arjan@linux.intel.com \
--cc=dmitry.torokhov@gmail.com \
--cc=dougthompson@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@suse.com \
--cc=mchehab@osg.samsung.com \
--cc=olof@lixom.net \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.