netdev - Re: [PATCH] RFKILL: fix input layer initialisation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 23 Jun 2008 22:25:45 +0400
From:	Dmitry <dbaryshkov@...il.com>
To:	"Henrique de Moraes Holschuh" <hmh@....eng.br>
Cc:	netdev@...r.kernel.org,
	"Dmitry Torokhov" <dmitry.torokhov@...il.com>, IvDoorn@...il.com
Subject: Re: [PATCH] RFKILL: fix input layer initialisation

Hi,

2008/6/23, Henrique de Moraes Holschuh <hmh@....eng.br>:
> On Mon, 23 Jun 2008, Dmitry Torokhov wrote:
>  > On Mon, Jun 23, 2008 at 06:40:24PM +0400, Dmitry Baryshkov wrote:
>  > > On Mon, Jun 23, 2008 at 09:22:39AM -0400, Dmitry Torokhov wrote:
>  > > > Hi Dmitry,
>  > > >
>  > > > On Thu, Jun 19, 2008 at 03:28:41PM +0400, Dmitry Baryshkov wrote:
>  > > > > Initialise correctly last fields, so tasks can be actually executed
>  > > > >
>  > > > > Also move rfkill-input initialisation to subsys level so that it's
>  > > > > available before generic drivers probing occurs.
>  > > > >
>  > > >
>  > > > Rfkill-input is an implementation of default policy of handling
>  > > > wifi-related key presses, it is not mandatory and should not be
>  > > > required for a driver to operate, it may even not be present in the
>  > > > kernel and therefore module_init is the appropriate time for its
>  > > > initialization. We don't expect user to start pushing WIFI buttons
>  > > > while system just starting to boot up, do we?
>  > >
>  > > I do toggle the KEY_BLUETOOTH from the kernel driver early.
>  > > The preliminary patch can be found at
>  > > http://permalink.gmane.org/gmane.linux.ports.arm.kernel/43136
>  > >
>  > > The idea was to drive the bluetooth chip attached to the UART from the
>  > > uart pm hook.
>  >
>  > Is there an actual button there? If not you should not create input
>  > device. You probably need to talk to Henrique (CCed) about how
>  > properly integrate rfkill support.
>
>
> I'd be glad to help.  Torokhov got me in the loop because of an ongoing
>  rfkill enhancement and documentation enfort I am pushing for, that is being
>  fleshed out in linux-wireless.
>
>  Please describe to me *what* your driver needs to do.  As Torokhov said, it
>  is very weird that it would need rfkill-input for anything.  I know of no
>  valid use case to issue KEY_* input events except if you are a driver for
>  something that has a button/key that was pressed (i.e. a driver for an input
>  device)... and rfkill-input doesn't matter at all for these.
>
>  If your driver is issuing KEY_BLUETOOTH to sync state, that's a layering
>  violation, and lot allowed.  I may be able to help you fix it through the
>  patches being reviewed in linux-wireless.

Yes, probably that's the correct description :)
The driver is tracking the state of serial port and respectievly
powering the bt chip
up or down. I'll check the linux-wireless list.

>
>  If it is something else, I will try to help, but I need to understand the
>  details of what your driver is trying to accomplish, first.

Thank you for your help!

>
>  --
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>
>   Henrique Holschuh
>


-- 
With best wishes
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html