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: <CAPybu_2zQ2mw45vdxp9-UyoVKmD8D5vZ4xLvCUhgkWu3-_GR0A@mail.gmail.com>
Date:	Wed, 18 Feb 2015 07:55:17 +0100
From:	Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>
To:	Bryan Wu <cooloney@...il.com>
Cc:	Rob Herring <robh+dt@...nel.org>,
	Richard Purdie <rpurdie@...ys.net>,
	Linux LED Subsystem <linux-leds@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] led/led-class: Handle LEDs with the same name

Hi

On Wed, Feb 18, 2015 at 2:36 AM, Bryan Wu <cooloney@...il.com> wrote:

>>
>
> I got it. In this case we need to give the leds device a unique name.
> Go back to your patch, you're adding 0, 1 at the end of the name of
> leds. It's better like GPIO I think you can pick up <reg> value of
> leds device node and put it in front of the name of leds. like
> /sys/class/leds/30040000.red and /sys/class/leds/40040000.red.

Hmmm.... That will not solve the issue for every device.

If I had a mmio, the gpio would be located at

/sys/devices/pci0000:00/0000:00:05.0/0000:01:00.0/30040000.gpio
and
/sys/devices/pci0000:00/0000:00:06.0/0000:01:00.0/30040000.gpio

Also it could be the case where the gpio is not memory mapped, then it
would be something like:

/sys/devices/pci0000:00/0000:00:05.0/0000:01:00.0/gpio
and
/sys/devices/pci0000:00/0000:00:06.0/0000:01:00.0/gpio

And at any case we should respect the old api, we can only rename the
second device, not the first one.

What is your concern about the initial proposal? What about NAME_dup0
instead of NAME_0?

We could throw a dev_info(), so the system developer will have a
chance to fix it (if he can) and the user to ignore it safely.


Thanks!


-- 
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ