public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Bastien Nocera <hadess@hadess.net>
Cc: BlueZ development <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH] Add rfkill plugin
Date: Wed, 29 Jul 2009 22:23:30 +0200	[thread overview]
Message-ID: <1248899010.28545.241.camel@violet> (raw)
In-Reply-To: <1248898544.28327.1539.camel@localhost.localdomain>

Hi Bastien,

> > > > The plugin allows us to restore the previous power state on
> > > > adapters when the killswitch on them has been unblocked.
> > > > 
> > > > Otherwise we end up with the adapter disabled when coming back from a
> > > > soft killswitch.
> > > 
> > > Just a note that __u32 causes failures with newer GCCs (not sure why),
> > > using uint32_t instead fixes the problem.
> > > 
> > > I'll send another patch when this one gets committed.
> > 
> > I didn't commit this patch, because it should be part of bluetoothd and
> > not a plugin 
> 
> You said you didn't mind:
> http://thread.gmane.org/gmane.linux.bluez.kernel/2981/focus=2986
> > Okay. Since we have built-in plugins, it makes no big difference.
> 
> > and as I mentioned before honor the RememberPowered setting
> > for system where other entities control that.
> 
> That's what that does:
> +       if (main_opts.remember_powered == FALSE)
> +               return 0;
>
> > However I did push a RFKILL skeleton that that all the lifting except
> > bringing the adapter up.
> 
> Which is pretty much the same as the code I sent, and the code in
> connman. What's the point of putting this in the core when it does the
> exact same as the plugin save for a level of indirection?

I changed my mind, because of the main_opts. We don't wanna export the
options in the long term. So using src/rfkill.c seems more logical at
this point of time.

> >  Hijacking the set_powered D-Bus command is the
> > wrong approach. We need a properly exported adapter_up() function for
> > this.
> 
> I believe I tried exporting adapter_up() but it didn't work.

Johan, Luiz, any reason why this would not work. What needs to be done
to bring up the adapter. Besides calling the ioctl() directly which we
don't wanna do anymore.

Regards

Marcel



  reply	other threads:[~2009-07-29 20:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-28 16:34 [PATCH] Add rfkill plugin Bastien Nocera
2009-07-28 20:06 ` Marcel Holtmann
2009-07-28 20:12   ` Bastien Nocera
2009-07-28 20:21     ` Marcel Holtmann
2009-07-29 15:13 ` Bastien Nocera
2009-07-29 19:49   ` Marcel Holtmann
2009-07-29 20:15     ` Bastien Nocera
2009-07-29 20:23       ` Marcel Holtmann [this message]
2009-07-29 20:40         ` Bastien Nocera
2009-07-29 21:44         ` Johan Hedberg
2009-07-29 21:45           ` Bastien Nocera
2009-07-30  2:10           ` Luiz Augusto von Dentz
2009-07-30  2:27             ` Marcel Holtmann
2009-07-30  2:30           ` Marcel Holtmann
2009-07-30 10:23             ` Johan Hedberg

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=1248899010.28545.241.camel@violet \
    --to=marcel@holtmann.org \
    --cc=hadess@hadess.net \
    --cc=linux-bluetooth@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