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: <CAK5ve-L_gp7Gr6YxUdTRzzCSXJcchUmxELrDhETisAp0TBjeHg@mail.gmail.com>
Date:	Thu, 19 Feb 2015 11:12:42 -0800
From:	Bryan Wu <cooloney@...il.com>
To:	Ricardo Ribalda Delgado <ricardo.ribalda@...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

On Tue, Feb 17, 2015 at 10:55 PM, Ricardo Ribalda Delgado
<ricardo.ribalda@...il.com> wrote:
> 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?
>

Actually I'd like to see some meaningful unique name for each device
when we create.
But looks like there is no such way to find some unique properties
from device tree node.

> 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.
>

Yes, this is what I want. It's good to let the user know there are
multiple leds share the same name in DT. Sometime they made some
mistake in the DTS file.

Please update the patch, we can start to discuss the implementation, then.

Actually I think we don't need the temp_name and just use the "name".
And one more thing is device_find_child() will find child of the
parent. But in your 2 PCI card case, these 2 parents are different
then device_find_child() will return false twice even if your 2 red
leds have the same name.

I think the better solution is search the name in registered leds
device, if found name is the same, then add a number or something. And
move out this name processing code to a separated function.

Thanks,
-Bryan
--
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