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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3466361.DVRahbqhfF@wuerfel>
Date:	Tue, 23 Feb 2016 16:06:55 +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 14:42:55 Marc Dietrich wrote:
> Am Dienstag, 23. Februar 2016, 14:17:17 CET schrieb Arnd Bergmann:
> > On Tuesday 23 February 2016 11:38:52 Marc Dietrich wrote:
> > > Am Dienstag, 23. Februar 2016, 11:31:40 CET schrieb Arnd Bergmann:
> > 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.
> 
> oh, that looks indeed interesting. The question is now if rfkill is a property 
> of a device or a subdevice itself. The latter one would only require addition 
> of device-tree instantiation of rfkill, while with the former one, the (or 
> all) usb driver(s) need to be modified to accept device tree properties, 
> especially gpios. The driver would then be responsible to add an rfkill 
> "device".
> 
> IMHO (and unfortunately), it's just a property (a way to specify the relevant 
> gpios), making the solution again hard to archive.

Does rfkill always have a separate device in the Linux driver model?

I would say that if we standardize on the property names, we can
have some generic helper code that does everything with one or
two function calls, similar to how we can read a mac address from
a DT node from ROM-less USB ethernet devices.

	Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ