From: Jeff Garzik <jeff@garzik.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Auke Kok <auke-jan.h.kok@intel.com>,
Jaswinder Singh <jaswinderlinux@gmail.com>
Subject: Re: [PATCH] firmware: convert e100 driver to request_firmware()
Date: Sun, 15 Jun 2008 19:30:31 -0400 [thread overview]
Message-ID: <4855A617.90006@garzik.org> (raw)
In-Reply-To: <1213567775.26255.534.camel@pmac.infradead.org>
David Woodhouse wrote:
> On Sun, 2008-06-15 at 14:44 -0400, Jeff Garzik wrote:
>> Each driver is _intimately_ tied to its firmware, so it only increases
>> headaches by separating two pieces of a single, cohesive whole.
>
> On reflection, that argument _does_ make me inclined to modify my
> approach.
>
> The _only_ thing that lets us justify the inclusion of this firmware
> blob in the kernel in the first place is the rather tenuous claim that
> it is "mere aggregation on a volume of a storage or distribution medium"
> -- as if it's just some kind of coincidence that these two pieces of
> work happen to be shipped together.
>
> If they really are "intimately tied pieces of a single, cohesive whole",
> as you say, then the claim that it's "mere aggregation on a volume of a
> storage or distribution medium" loses whatever small amount of
> credibility it had in the first place, and we have no option but to
> remove the offending part immediately.
>
> Revised patch follows....
>
> drivers/net/Kconfig | 1
> drivers/net/e100.c | 281 +++++++++++++++-------------------------------------
> 2 files changed, 86 insertions(+), 196 deletions(-)
So, in response you separate them further? No thanks.
Put the data in drivers/net/e100.firmware. It makes no sense to have
two parallel driver hierarchies, one for C source and one for firmwares.
And IMO I would think the best first step for all such drivers would be
to add request_firmware() support _without_ touching the embedded
firmware. You are trying to stuff too much change into a single patch.
Such a step gets most of your driver modifications into the kernel with
the least headache and controversy, while adding the quite-useful
ability to have a driver load an external firmware instead of the
embedded one.
request_firmware() infrastructure addition is clearly a separate and
distinct change from moving/removing an embedded firmware.
Jeff
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
next prev parent reply other threads:[~2008-06-15 23:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-15 9:42 [PATCH] firmware: convert e100 driver to request_firmware() David Woodhouse
2008-06-15 17:50 ` Jeff Garzik
2008-06-15 17:51 ` David Woodhouse
2008-06-15 18:07 ` Jeff Garzik
2008-06-15 18:34 ` Jaswinder Singh
2008-06-15 18:42 ` David Woodhouse
2008-06-15 19:00 ` Jeff Garzik
2008-06-15 18:44 ` Jeff Garzik
2008-06-15 22:09 ` David Woodhouse
2008-06-15 23:30 ` Jeff Garzik [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-06-14 17:00 Jaswinder Singh
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=4855A617.90006@garzik.org \
--to=jeff@garzik.org \
--cc=auke-jan.h.kok@intel.com \
--cc=dwmw2@infradead.org \
--cc=e1000-devel@lists.sourceforge.net \
--cc=jaswinderlinux@gmail.com \
--cc=netdev@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 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.