From: Baruch Siach <baruch@tkos.co.il>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] wf111: Add mdev dependency
Date: Wed, 12 Aug 2015 08:38:52 +0300 [thread overview]
Message-ID: <20150812053852.GI25261@tarshish> (raw)
In-Reply-To: <CAE21AQr13hYAsTkcD2_qRjSHme8aCHPDZDt2CWMeo8Fi4jptHw@mail.gmail.com>
Hi Charles,
On Wed, Aug 12, 2015 at 05:16:35PM +1200, Charles Manning wrote:
> >> On Tue, Aug 11, 2015 at 11:40 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> >> > On Tue, Aug 11, 2015 at 07:17:02PM +1200, Charles Manning wrote:
> >> >> wf111 really needs mdev
> >> Actually udev would work too.
> >
> > Recent kernels gained the ability to load firmware directly without any help
> > form userspace, so this is probably another option.
>
> Well not without rewriting the wf111 driver and the associated
> prebuilt "helper" binaries it comes with...
>
> The wf111 buildroot package unwraps a tarball from Bluegiga, does an
> out of tree build of the kernel modules then copies the modules +
> binaries into the file system tree.
>
> This isn't "pure" or anything like that, but it gets the job done....
>
> This is why there is quite a bit of "funkiness" to the wf111 package.
All that should be mentioned in the commit log.
> >> The wf111 driver set uses hotpug to perform the firmware patching
> >> (loading .xbv files).
> >>
> >> From what I have experienced, fw patching is required when you first
> >> fire up a new module and when you change modes (sta only vs ap).
> >
> > Since there are different ways to load the firmware we generally don't make
> > firmware or driver packages build depend on any specific firmware loading
> > mechanism.
>
> In general you are right, but I think this is a special case.
>
> wf111 driver + associated files is built out of tree by a special package.
>
> That package already has other dependencies that are nothing to do
> with the kernel. eg.BR2_TOOLCHAIN_USES_GLIBC because of those prebuilt
> binaries.
>
> The prebuilt binaries (and therefore the whole wf111 package) does not
> result in a functioning wf111 subsystem unless there is udev or mdev
> (I've only tested with mdev)., therefore let's be helpful and add the
> dependency.
I'm still not convinced. We use dependencies to express build time or run time
dependencies. I think the glibc dependency is appropriate, but a hotplug
mechanism is too broad.
Let's see what others think.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
next prev parent reply other threads:[~2015-08-12 5:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-11 7:17 [Buildroot] [PATCH] wf111: Add mdev dependency Charles Manning
2015-08-11 11:40 ` Baruch Siach
2015-08-11 20:11 ` Charles Manning
2015-08-12 4:38 ` Baruch Siach
2015-08-12 5:16 ` Charles Manning
2015-08-12 5:38 ` Baruch Siach [this message]
2015-08-12 5:56 ` Charles Manning
2015-08-12 22:54 ` Floris Bos
2015-08-12 10:29 ` Floris Bos
2015-08-12 20:49 ` Charles Manning
2015-08-12 21:47 ` Floris Bos
2015-08-18 20:28 ` Thomas Petazzoni
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=20150812053852.GI25261@tarshish \
--to=baruch@tkos.co.il \
--cc=buildroot@busybox.net \
/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.