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] [thread-next>] [day] [month] [year] [list]
Message-ID: <2463567.tt0f0ingYr@wuerfel>
Date:	Tue, 23 Feb 2016 14:17:17 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Marc Dietrich <marvin24@....de>
Cc:	Johannes Berg <johannes@...solutions.net>,
	Thierry Reding <thierry.reding@...il.com>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org,
	Alexandre Courbot <gnurou@...il.com>,
	Stephen Warren <swarren@...dotorg.org>
Subject: Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties with rfkill_gpio

On Tuesday 23 February 2016 11:38:52 Marc Dietrich wrote:
> Am Dienstag, 23. Februar 2016, 11:31:40 CET schrieb Arnd Bergmann:
> > On Tuesday 23 February 2016 11:15:31 Arnd Bergmann wrote:
> > > On Thursday 18 February 2016 21:04:49 Johannes Berg wrote:
> > > > On Tue, 2016-01-26 at 09:42 +0100, Johannes Berg wrote:
> > > Just for my curiosity: what is the difference between a rfkill-gpio
> > > device and a gpio-keys device with a KEY_RFKILL code?
> > > 
> > > arch/arm/boot/dts/bcm4708-netgear-r6250.dts and others seem to
> > > do the second approach in DT so they don't need to create the
> > > platform device.
> > 
> > I found the answer now (after discussing on IRC): just
> > for reference: KEY_RFKILL is for sending the event to the kernel
> > when a user presses the gpio butting, this rfkill-gpio turns
> > the devices on or off when after an RFKILL event is received.
> 
> yes, paz00 has no hw key. rfkill is triggered via software (rfkill) only. The 
> problem in the past was how to describe such a device in the device tree. 
> 
> Strictly speaking, there is no rfkill device hardware (just an interface). The 
> only hardware that exists is in our case is connected to a hard wired usb bus 
> (wifi dongle), which makes it complicated to attach a DT property or subdevice 
> to it. And a standalone device-tree entry for a non hardware device was 
> rejected in the past.
> 

Ah, so the problem of attaching DT properties to a USB device has recently
been solved, see subject "USB: core: let USB device know device node".

Would that work for you? With this, the USB driver can simply look at
the optional DT properties of the USB function to implement its rfkill
callbacks.

	Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ