From: Mark Hounschell <markh@compro.net>
To: Greg KH <gregkh@linuxfoundation.org>,
Daeseok Youn <daeseok.youn@gmail.com>
Cc: lidza.louina@gmail.com, devel@driverdev.osuosl.org,
driverdev-devel@linuxdriverproject.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 7/8 RESEND] staging: dgap: introduce dgap_cleanup_nodes()
Date: Wed, 16 Jul 2014 08:39:33 -0400 [thread overview]
Message-ID: <53C67285.4010008@compro.net> (raw)
In-Reply-To: <790027403.325559.1405438239093.JavaMail.root@mx2.compro.net>
On 07/15/2014 11:30 AM, Greg KH wrote:
> On Tue, Jul 15, 2014 at 06:14:25PM +0900, Daeseok Youn wrote:
>> When a configration file is parsed with dgap_parsefile(),
>> makes nodes for saving configrations for board.
>
> configuration files should not be parsed in the kernel at all. That
> logic should be removed as it should not be needed.
>
> Mark, can you verify that this is not needed with your hardware anymore?
>
As far as I can see it is still needed. If no config file, no devices
are created and configured. I had planned to remove that code such that
all the different cards supported are still supported. Even though I
only have 2 different types of cards. I Just haven't got to it yet. I
realize "configuration files should not be parsed in the kernel" and I'm
certainly not going to argue that. But the way it is, it allows user
land to define board order and even device node names (additional links
to the actual device). No matter where boards are installed and found by
the kernel, you have persistent naming. I guess all that can be done
with udev (well, sort of anyway).
There are also options in the config file that should be passed in as
module parameters
and I planned to do that part before messing with the config file code.
We also have this "DIGI_EXPANDERS_SUPPORTED" thingy. I have none of
these cards. These cards interrogate the expander to find out how many
ports there are. Then configure accordingly. Should we just remove all
that code and NOT support expanders since we don't currently have the
hardware to test?
I will update from your current git tree and test this week. I've been
swamped lately and unable to do much. I thought I'd be available to do
some more work but things come up as you know.
Regards
Mark
next prev parent reply other threads:[~2014-07-16 12:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-15 9:14 [PATCH 7/8 RESEND] staging: dgap: introduce dgap_cleanup_nodes() Daeseok Youn
2014-07-15 15:30 ` Greg KH
[not found] ` <790027403.325559.1405438239093.JavaMail.root@mx2.compro.net>
2014-07-16 12:39 ` Mark Hounschell [this message]
2014-07-16 13:17 ` Dan Carpenter
2014-07-16 23:59 ` DaeSeok Youn
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=53C67285.4010008@compro.net \
--to=markh@compro.net \
--cc=daeseok.youn@gmail.com \
--cc=devel@driverdev.osuosl.org \
--cc=driverdev-devel@linuxdriverproject.org \
--cc=gregkh@linuxfoundation.org \
--cc=lidza.louina@gmail.com \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox