linux-kernel - Re: [PATCH] led/led-class: Handle LEDs with the same name

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]

Date:	Wed, 18 Feb 2015 01:32:14 +0100
From:	Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>
To:	Bryan Wu <cooloney@...il.com>
Cc:	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

Hello Bryan

On Wed, Feb 18, 2015 at 12:59 AM, Bryan Wu <cooloney@...il.com> wrote:
>
> DT just describe the hardware, so if it's a different hardware, they
> should have different name.
> red0 for GPIO 0, red1 for GPIO 1 or choose other good name instead of 0 and 1.

I think I have not managed to explain myself properly.

We have a host computer. with 2 pcie slots. The host is described with
a DT that looks like:

&axi1 {

pci0{
  reg = < 0x20000000 0x10000000 >
}

pci1{
  reg = < 0x30000000 0x10000000 >
}
}

The user can connect anything to the pci slots. (pci0 and pci1)

Lets say that we have a type of add-on card. Described by this DT
overlay (card.dtb):

&pci {

gpio_0: gpio_0 {
#gpio-cells = <2>;
compatible = "xlnx,xps-gpio-1.00.a";
reg = < 0x30040000 010000 >;
};

/*Leds*/
leds {
reg = < 0x30040000 010000 >;
compatible = "gpio-leds";
red {
gpios = <&gpio_0 0 0>;
linux,default-trigger = "drop-qt5023_video0";
};
}

}

The user connects two of those cards to the system (at locations pci0 and pci1).

Then we have TWO gpios chip. Each of them have a led named red. When
the second gpio-led is probed we have an error. Everything else
(address offset, phandle, device renaming) is handled properly already
by the kernel.

On this system I cannot control card.dtb, or which type of cards will
the user connect to the system. The DT is generated in run-time based
on the hardware connected to the pci slots.

I humbly believe that the issue here is that the subsystem does not
protect ourselves against name collisions, because a month ago a
device tree was considered immutable and in full control of the system
designer, unfortunately this is not the case anymore.

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/