From: Dan Murphy <dmurphy@ti.com>
To: <ultracoolguy@tutanota.com>, Marek Behun <kabel@blackhole.sk>
Cc: Pavel <pavel@ucw.cz>, Linux Leds <linux-leds@vger.kernel.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] leds: lm3697: Fix out-of-bound access
Date: Tue, 6 Oct 2020 07:21:14 -0500 [thread overview]
Message-ID: <144aa75a-4369-cd81-d7dc-2354a9afd7c5@ti.com> (raw)
In-Reply-To: <MIxm3uX--3-2@tutanota.com>
All
On 10/6/20 6:59 AM, ultracoolguy@tutanota.com wrote:
> While I do agree with you that having the child nodes be led strings make more sense, would it be possible to have, for example, three strings controlled by the same label?
>
> Oct 6, 2020, 07:33 by kabel@blackhole.sk:
>
>> By the way I just realized that the DT binding in this driver seems
>> incorrect to me.
>>
>> The controller logically supports 3 LED strings, each having
>> configurable control bank.
There are two control banks. You can connect the HVLED outputs to either
control bank A or B there is no individual control of the LED strings.
>> But the DT binding supports 2 DT nodes, one for each control bank
>> (identified by the `reg` property) and then `led-sources` says which
>> string should be controlled by given bank.
>>
>> But taking in mind that DT should describe how devices are connected to
>> each other, I think the child nodes in the binding should instead
>> describe the 3 supported LED strings...
The outputs in this case are virtual outputs which are the banks (A and B).
Since the device is bank controlled the actual current sinks are not
defined thus making the the banks the actual outputs.
This is why the 'reg' property defines the control bank either A or B
and the led-sources indicates the strings associated with the control bank.
Dan
next prev parent reply other threads:[~2020-10-06 12:21 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-03 13:02 ultracoolguy
2020-10-03 13:56 ` Pavel Machek
2020-10-03 14:43 ` ultracoolguy
2020-10-05 12:13 ` Marek Behun
2020-10-05 13:50 ` Pavel Machek
2020-10-05 13:57 ` ultracoolguy
2020-10-05 14:33 ` Dan Murphy
2020-10-05 14:37 ` Dan Murphy
2020-10-05 14:38 ` ultracoolguy
2020-10-05 14:41 ` Dan Murphy
2020-10-05 15:35 ` ultracoolguy
2020-10-05 16:05 ` Pavel Machek
2020-10-05 16:48 ` Alexander Dahl
2020-10-05 17:14 ` ultracoolguy
2020-10-05 17:32 ` Pavel Machek
2020-10-05 18:29 ` ultracoolguy
2020-10-05 18:31 ` ultracoolguy
2020-10-05 18:39 ` Pavel Machek
2020-10-05 18:48 ` ultracoolguy
2020-10-06 7:33 ` Marek Behun
2020-10-06 11:59 ` ultracoolguy
2020-10-06 12:21 ` Dan Murphy [this message]
2020-10-06 14:41 ` Marek Behun
2020-10-06 14:57 ` Dan Murphy
2020-10-06 15:14 ` Marek Behun
2020-10-06 17:26 ` Pavel Machek
2020-10-05 15:59 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=144aa75a-4369-cd81-d7dc-2354a9afd7c5@ti.com \
--to=dmurphy@ti.com \
--cc=kabel@blackhole.sk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=ultracoolguy@tutanota.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®