Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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 -

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox